vLLM 公布 Kimi K3 服务优化，称 B300 基准吞吐达到 v0.27.1 的 2.2～2.8 倍

9 月 17 日，vLLM 的官方 X 账号发帖称，Kimi K3 在 vLLM 上的服务（serving）达到 vLLM v0.27.1 的 2.2～2.8 倍吞吐，结果来自其 B300 基准。帖文把优化工作拆成调度（scheduling）、KDA 状态处理（KDA state handling）与 MoE（混合专家）内核三部分，附上基准结果、复现命令与深潜博客链接，并致谢 vLLM 社区。

数字来自 9 月 13 日发布的。它给出的测试口径是：8K 输入/1K 输出的负载、TP8、8 个 token 的 DSpark 投机解码，并发 1、4、16，对比的起点是 vLLM v0.27.1、终点是 9 月 13 日主干提交 82a85dc1，测试节点为 NVIDIA B300（CUDA 13.3）。三个并发档下，吞吐从 83.3、166.7、258.3 tok/s 升到 183.3、416.7、725.0 tok/s，相当于提升 120.0%、150.0%、180.6%；平均延迟从 12.37、23.67、55.90 秒降到 5.30、10.50、22.17 秒，降幅为 57.2%、55.6%、60.3%；平均首 token 时间（TTFT）从 2,262.9、2,314.9、7,601.1 ms 降到 376.3、640.5、1,121.0 ms，降幅为 83.4%、72.3%、85.3%。

测试口径与复现命令

博客把这轮工作定位为 Day-0 支持之后的又一次全栈优化：Day-0 只是让 Kimi K3 在 vLLM 上跑起来；要高效服务，KDA 循环状态、LatentMoE、MXFP4 专家内核、投机解码与 TP/PP 各自暴露出不同瓶颈，调度器限制与小张量拷贝可能与大型 GEMM 一样重要。

基准用 guidellm 运行，以合成文本请求按并发 1、4、16 三档测量，每次运行的时长上限为 150 秒。服务端以 vllm serve moonshotai/Kimi-K3 启动，开启 TP8（tensor-parallel-size 8）与 fastsafetensors 加载，并挂上 RedHatAI/Kimi-K3-speculator.dspark 投机解码配置（8 个投机 token）。博客特别注明：两次运行都关闭了前缀缓存，因为 v0.27.1 存在一个后来才修复的 Kimi K3 前缀缓存问题。

这些数字出自 vLLM 在自己 B300 节点上运行的基准测试，属发布方口径；博客给出的模型、环境、命令与配置，则是按同一口径核对的入口。

调度：自适应 token 预算

博客指出，请求数少的时候，max_num_batched_tokens 的很大一部分额度没有被用上。引入自适应的调度 token 预算；同一批改动里还有一项配置调整，把高显存 GPU 档的默认上限从 8,192 提到 16,384。

在 max_num_seqs=1024、max_num_batched_tokens=8192、K=8 的设置下，无论实际请求数是 1、32 还是 128，旧逻辑每次只调度 1,024 个 token；新逻辑把这三个档位分别放大到 8,185、7,968、7,296，只有请求数达到 1,024 时，新旧数值才同为 1,024。博客的解释是，这样单个请求不会再被拆成多次前向调用。单看这项改动，在这组 8K/1K 负载上 TTFT 下降 55%～65%、吞吐最多提升 41.5%。

KDA 状态处理：ReplaySSM、前缀检查点与零拷贝批次

第一处改动针对投机解码的状态开销：过去每个投机位置都要写一份 KDA 循环状态，以便在 token 被拒绝时回滚，T 个投机位置意味着每步多出 T 次状态写入。博客把替代方案称为 ReplaySSM：缓存最近的 SSM（状态空间模型）输入，在提交时重建被接受的状态，回滚只需要移动一个缓冲区指针。在 Model Runner V2 上为 Kimi K3 落地了这一机制：一个 Triton kernel 在 align 模式下同时提交被接受的状态与下一个前缀缓存边界。博客称，在同样的 46.48 GiB 缓存预算下，TP8 的有效容量提升 10.97%，且没有精度损失。

第二处是内部 KDA 前缀检查点。此前的 Mamba 风格前缀缓存会在最后一个可缓存块边界切开预填充，有时要为很短的尾部再补一次全模型前向。把检查点导出放进同一次预填充：对 8K 输入，一次 FlashKDA 调用处理全部 8,000 个 token，并在同一次循环里于第 7,680 个 token 处导出检查点状态，省掉了第二次穿过注意力、MoE、路由和 TP 集合通信的前向，TTFT 下降 9%～25%。后续改动把部分前缀命中与投机解码也纳入了这条路径。

第三处是零拷贝混合批次。混合投机与非投机的批次里，每层 KDA 此前要做六次 index_select 和两次 index_copy_；改用连续的零拷贝切片，并把结果直接写进输出。并发 4 与 16 时吞吐提升 5.2%～7.7%；批大小为 1 时没有变化。

MoE 内核：MXFP4 延迟终结与 LatentMoE

博客列举的瓶颈里包括 LatentMoE 与 MXFP4 专家内核。在 MoE 这一侧，博文详细展开的是 MXFP4 延迟终结（deferred MXFP4 finalization）：把 MXFP4 的 top-k 终结步骤并进 latent-tail 内核，省下一次内核启动，也避免中间张量写回后再读出，端到端延迟下降约 5%。另一处修复调整了初始化顺序，使这条延迟终结路径能在权重加载前启用。

更宽的一轮：DCP 与预填充/解码分离

博客还记录了范围更大的一轮改动。Decode context parallelism（解码上下文并行，DCP）针对的问题是：TP 会在每个 rank 上复制 MLA 的 latent KV，所以增加 TP rank 并不会增加 KV 缓存容量；DCP 把 KV 沿序列维度切开，适合长共享前缀的 agentic 负载。为 Kimi K3 的融合 MLA 路径实现 DCP：对称内存 A2A 负责输出/LSE 归约，NVLS multicast 收集 query，multimem 收集分块上下文的 KV，query 分片直接写进消费端的最终缓冲区；在 4×GB200 上，query 交换延迟下降 10.4%～29.9%。在一个 12 万 token 的工作负载（11.4 万共享前缀、6,000 后缀，输出 400 token）上，KV 缓存容量从 193 万 token 升到 1,975 万 token，并发 1 时 TPOT（每输出 token 耗时）p50 从 13.8 ms 降到 10.5 ms，并发 2 时从 16.2 ms 降到 11.8 ms；GSM8K 上 DCP8 得分为 96.97%，TP8 为 96.21%，无请求错误。

预填充/解码分离与缓存卸载要同时搬运 MLA KV 与 KDA 状态：MLA KV 在各 TP rank 上复制，KDA 状态按头与维度分片。博客提到，Mooncake 相关改动会保存调度器选中的边界状态，并在所有 rank 的异步写完成前固定它们；只有能恢复 KDA 状态的连接器，才能处理每组各自不同的前缀命中。

署名、致谢与算力赞助

博客的 8 名署名作者分别来自 Red Hat、Huawei、Inferact 与 NVIDIA，其中 4 人来自 Inferact；文末致谢评审者、CI 维护者、基准负责人与硬件团队。在社区贡献方面，博客点名 Robert Shaw 与 Summer Yang 加入了 DeepEPv2 与 DeepGEMM 的 MXFP4 路径以及 DCP 支持，Thien Tran 开发了 sequence-parallel GEMM 路径，Nick Hill 与 Xiaolong Xu 优化了 KDA prefill。算力方面，博客感谢 Novita AI 为其中一部分优化赞助算力，称很高兴为这些优化提供了算力支持；在 9 月 18 日的帖文中则称，这轮优化由其与 Red Hat AI、NVIDIA AI、Huawei 共同主导（co-led），涵盖调度、KDA 状态处理与定制 MoE 内核。

这轮优化的完整 PR 清单挂在 GitHub issue 上；该 issue 创建于 7 月 31 日，目前仍处于打开状态。

参考链接

（vLLM 官方帖文，2026-09-17）
（vLLM 博客，2026-09-13）
（自适应调度 token 预算）
（Kimi K3 状态恢复路径）
（内部 prefill 检查点）
（KDA 混合批次零拷贝）
（MXFP4 top-k 终结并入 latent tail）
（Kimi K3 DCP 支持）
（Novita AI 回应，2026-09-18）
（Inferact 帖文，2026-09-18）
（Kimi K3 Performance Optimization 跟踪 issue）