Kimi K3 在 vLLM 中的性能优化
vLLM 已针对 Kimi K3 实现了一系列全面的性能优化，实现了高达 2.8 倍的吞吐量提升，并将首字延迟 (TTFT) 降低了高达 85%。这些改进是通过解决整个推理栈中的瓶颈实现的，包括 KDA 循环状态、LatentMoE、MXFP4 专家内核以及投机采样 (speculative decoding)。
服务性能提升
在 B300 节点 (CUDA 13.3) 上使用 8K/1K 工作负载、TP8 和 8 个 token 的 DSpark 投机采样进行测试，将 vLLM v0.27.1 与 9 月 13 日的主分支提交 (82a85dc1) 进行对比，结果显示出显著的提升。
| 并发度 | v0.27.1 平均延迟 (s) | 0913 main 平均延迟 (s) | v0.27.1 吞吐量 (tok/s) | 0913 main 吞吐量 (tok/s) | v0.27.1 平均 TTFT (ms) | 0913 main 平均 TTFT (ms) |
|---|---|---|---|---|---|---|
| 1 | 12.37 | 5.30 (−57.2%) | 83.3 | 183.3 (+120.0%) | 2262.9 | 376.3 (−83.4%) |
| 4 | 23.67 | 10.50 (−55.6%) | 166.7 | 416.7 (+150.0%) | 2314.9 | 640.5 (−72.3%) |
| 16 | 55.90 | 22.17 (−60.3%) | 258.3 | 725.0 (+180.6%) | 7601.1 | 1121.0 (−85.3%) |
关键技术优化
自适应调度预算
为了防止低请求数导致 max_num_batched_tokens 未被充分利用，vLLM 引入了自适应调度 token 预算。该策略确保在请求数较少时，单个请求不会被拆分到多个前向调用中，从而在 8K/1K 工作负载下将 TTFT 降低了 55%–65%，并将吞吐量提升了高达 41.5%。
内部 KDA 前缀检查点
此前，Mamba 风格的前缀缓存拆分需要对短后缀进行第二次全模型传递。vLLM 现在支持在单个 prefill 阶段内进行检查点导出。对于 8K 输入，这允许一次 FlashKDA 调用即可处理所有 8,000 个 token 并在同一个循环内于 token 7,680 处导出检查点状态，从而避免了对 attention、MoE、routing 和 TP collectives 的第二次传递。这使 TTFT 降低了 9%–25%。
零拷贝混合 KDA 批处理
包含投机采样和非投机采样 token 的混合批次此前每层都需要多次 index_select 和 index_copy_ 操作。vLLM 实现了连续的零拷贝切片和直接输出写入，这在并发度为 4 和 16 时将吞吐量提升了 5.2%–7.7%。
延迟 MXFP4 最终化
通过将 MXFP4 top-k 最终化融合进 latent-tail 内核，vLLM 减少了一次内核启动，并避免了写入和重读中间张量，从而将端到端延迟降低了约 5%。
高级内存与状态管理
用于状态重建的 ReplaySSM
投机采样通常需要在每个 draft position 处写入 KDA 循环状态以允许回滚。ReplaySSM 通过缓冲最近的 SSM 输入并在仅在提交点重建已接受的状态，优化了这一过程。对于在 Model Runner V2 上的 Kimi K3，这在 TP8 下将有效缓存容量提升了 10.97%，且未影响准确性。
Prefill/Decode 分离与混合状态卸载
vLLM 现在支持 Kimi K3 的 PD 分离与缓存卸载，这需要转移 MLA KV 和 KDA 状态。由于 KDA 状态是按 head 和 dimension 拆分的，且 Mamba align 块表可以具有稀疏性和可变性，vLLM 利用 Mooncake 来存储由调度器选择的边界状态，并将其固定 (pin) 直到每个 rank 上的异步写入完成。
Decode Context Parallelism (DCP)
由于张量并行 (TP) 会在每个 rank 上复制 MLA latent KV，因此它无法增加 KV-cache 容量。Decode Context Parallelism (DCP) 则沿序列维度拆分 KV-cache。对于 Kimi K3 的融合 MLA 路径，DCP 使用 Symmetric-memory A2A 进行输出/LSE 归约，并使用 NVLS multicast 进行查询收集。
在 120k-token 工作负载下（114k 共享前缀，6k 后缀，400 输出 token），KV-cache 容量从 1.93M 增加到了 19.75M token，而并发度 1 时的 TPOT p50 从 13.8 ms 降低到了 10.5 ms。
更广泛的实施实施工作
性能提升是内存布局、序列与流水线并行、KDA prefill 以及针对小批量 GPU 路径的优化工作的综合结果。这包括了 DeepEPv2 与 DeepGEMM MXFP4 以及序列并行 GEMM 路径的集成，详见 GitHub issue #50587。