vLLM 宣布 Kimi K3 在 GB300 NVL72 上实现 batch 1 解码 842 tokens/s

北京时间 10 月 18 日上午，发帖宣布：Kimi K3 在 NVIDIA GB300 NVL72 上的解码（decode，生成阶段逐 token 输出的过程）在 batch 1 下达到 842 tokens/s。帖文称，成绩来自一条统一的 CuTe DSL decode 路径——它把 attention、MoE（混合专家）与通信融合为定制内核——在若干受测配置中带来 1.5～2 倍的解码吞吐提升，并在 SemiAnalysis 的 AgentX 负载上取得最高 1.8 倍的 P90 交互性（按每用户 tokens/s 计）提升；帖文同时称这项工作与 NVIDIA 团队合作完成。

vLLM 自述是一个高吞吐、显存高效的 LLM 推理服务引擎（）。842 tokens/s 的完整口径写在 10 月 16 日发布的 write-up（长文）《》里：帖文以 GB300 NVL72 指代测试平台，write-up 与 PR 给出的具体配置是 16 张 GB300 GPU（TP16，16 卡张量并行，全部处于单一 NVLink 域）、DSpark DL7（7 个 draft token 的投机解码设置）、合成接受长度 6（synthetic AL=6）、输入长度 ISL=1、输出长度 OSL=1,000、batch size 1；同样设置下原版（stock）vLLM 为 488 tokens/s，提速 1.73 倍。这些数字目前均为 vLLM 一方口径。不过与只公布一个数字不同，write-up 给出了内核实现、正确性评测和跨 batch size、上下文长度、并行配置的基准矩阵，代码以提交——PR 描述自述这是 NVIDIA 开发的 Kimi K3 GB300 专用实现，write-up 的致谢名单中也包括 NVIDIA 的 Rohan Varma 与 Alex Steiner。

DSpark 的换算方式与不带投机解码的扫描

DSpark 是本次测试所用的投机解码（speculative decoding）方案，配 7 个 draft token；「合成接受长度 6」指受控基准把接受长度固定为 6，PR 里给出的换算式是：解码 tokens/s = 每秒解码步数 × 接受长度 × batch size。write-up 说明，TPS 度量的是整个 TP 组的聚合解码吞吐，不含 prefill（预填充）。

不开投机解码时的扫描覆盖了 batch 1～64，write-up 给出的结果如下（吞吐为整个 TP 组合计）：

batch size	TP8 tokens/s	TP8 提速	TP16 tokens/s	TP16 提速
1	193.3	1.58×	256.4	1.88×
2	317.8	1.50×	436.7	1.92×
4	540.6	1.55×	702.5	1.81×
8	820.1	1.45×	1,157.9	1.79×
16	1,274.8	1.43×	1,758.3	1.71×
32	1,702.6	1.33×	2,550.9	1.64×
64	2,375.9	1.31×	3,606.1	1.62×

增益并非处处落在 1.5～2 倍区间：TP8 在 batch 16～64 时为 1.31～1.43 倍，TP16 同区间为 1.62～1.71 倍。PR 中的同一 DSpark 配置记为 838 对 489 tokens/s（1.71 倍），与博客的 842 对 488 略有出入；PR 还给出跨 ISL 8k、32k、100k 的解码步时矩阵（TP8 为全量数据，TP16 为部分数据，另有 100k 下的 TP8+DCP8）。

这条路径的适用边界写得很具体：面向 NVIDIA Blackwell GPU、8 或 16 卡、解码 batch 1～64，可选 decode 上下文并行（DCP）处理长上下文，DCP 的做法是把键值缓存（KV cache）分片到各卡；所有 GPU 位于单一 NVLink 域并支持 multicast。初始硬件验证覆盖 GB300 的 TP8/TP16、最多 64 的解码 batch、多种 draft 长度的投机解码，以及单 NVLink 域内的 DCP 配置。

每层从 23 个内核减到 13 个，130 微秒降到 69 微秒

Nsight Systems 的内核追踪（TP16、batch 8、rank 0）显示：一个 KDA 层加一个 MoE 块，原版 vLLM 用时 130 微秒、启动 23 个内核；专用 decode 用时 69 微秒、13 个内核——单层耗时几乎减半，内核数量少了四成多。

write-up 把改动归为四类。其一，按负载调内核形状：attention 输入投影在 batch 1～2 用专用小矩阵内核，更大的 batch 改用 split-K 内核，把矩阵乘分摊到更多 GPU worker；KDA 换上按 batch size 与每卡注意力头数调度的优化 CuTe DSL decode 内核；长上下文由 DCP 把 KV cache 分片到各卡，调好的融合内核把部分结果与 v-proj、门控合并。

其二，让计算与通信重叠：attention 输出投影直接接到 all-reduce（全归约）和后续的 attention-残差计算，内核把部分结果写进 NVLink 可访问的缓冲区，接收方合并后继续计算；一些小 batch 配置把生产者与消费者融进同一个内核，数据交换以免栅栏（fence-less）方式进行、开销很小；更大的 batch 切换为两阶段归约，先合并各自负责的部分再分发，减少卡间数据搬运。

其三，改 MoE 调度：基线在每张 GPU 上重复计算完整的 router（路由模块）打分与 latent 输入投影，新实现把这两步切分到各 TP rank、再并为一次矩阵乘，经 NVLink 交换结果；共享专家在单独的 stream（执行流）上运行，与路由或专家计算重叠，资源配比经过调优以避免争用。

其四，权重预取：小 batch 推理常受显存带宽限制，而通信阶段用不满带宽，于是在旁路 stream 上跑一个专用内核，趁通信进行时预取下一步要用的权重，提高缓存命中率。

Agent 写内核快过人工评审，vLLM 给快车道定规矩

write-up 开头交代了动机：coding agent 已经能在模型优化的一些最难环节派上用场——写复杂 GPU 内核、做跨算子融合、把计算与通信重叠、跨 batch size 与 GPU 配置调优——但 agent 产出优化的速度超过了 vLLM 的评审与维护流程。逐行理解每个内核、排查隐患、测遍所有支持配置，是非常耗时的工作；跳过这步，就可能把带 bug 的软件送上生产。

为此提出的定了四条原则：把改动隔离在模型自己的代码里；限定支持的硬件与负载范围、但保住生产必需特性——全上下文服务、温度采样、结构化输出属于一等特性，不能被「优化掉」；系统化验证正确性；在所有受影响的配置上广泛核查性能，MoE 测试要用真实 prompt（提示词），纯 decode 结果要与 prefill、decode 混合的负载分开。Kimi K3 是这套流程下的第一个贡献。

正确性环节出过真问题：审计发现编译器把激活值读取挪到了同步等待之前，修复方式是限制该类读取只用于静态权重；MRCR、AIME25 等长上下文、长生成评测暴露出 attention 与通信内核的数值问题，这些问题在用 mock 输入、启动时序一致的独立内核测试中无法复现。PR 描述称，AIME25、GPQA-Diamond 与 MRCR v2 的分数与原版在约一个标准误内一致，含与不含投机解码两种口径都成立；评测表中还列有 GSM8k 的对照结果。PR 评论区，用户 dllehr-amd 留言（英文，此处为译文）：「我不会假装读完了所有 CuTe DSL 代码，但实现很干净，和我们之前讨论的一致。干得漂亮。」

为了让验证不把维护者压垮，配套的提议提供标准评测镜像，让贡献者先在自己的 GPU 上跑出可复现的结果包、挂到 GitHub PR 上，再申请维护者时间；不同评测分层与社区共享算力用来扩大覆盖、减轻项目资助 CI 的压力。

AgentX 的交互性对比：优化侧 16 卡，基线 8 卡

AgentX 是 SemiAnalysis 的基准负载，回放真实 coding-agent 会话的流量模式——长上下文、多轮对话、工具调用停顿、并行子 agent、KV 缓存复用——同时把私有内容替换成合成文本（）。write-up 报告：并发 1 下，优化后的 P90 交互性为 403.2 tokens/s/user，对比 223.7，即 1.8 倍。

这个数字有一个 write-up 自己写明的前提：优化侧跑在 16 张 GB300 上，基线是早前 vLLM 在 8 张 GB300 上的成绩；图表脚注还注明，各数据点的部署配置不同，总吞吐同时计入输入与输出 token。卡数不对齐，意味着 1.8 倍不能直接读成同规模部署下的净增益。

DeepSeek-V4.1-Flash 跟进同一模式，GLM5.3 在后续计划中

DeepSeek-V4.1-Flash 的沿用 K3 的设计模式，在同一个 opt-in 开关 decode_backend: latency_specialized 之后：支持最多 64 个并发请求，prefill 与混合批次无缝回退到默认实现，支持投机解码。它不追单点热点，而是在每个子层边界融合 all-reduce 与 mHC、用为低延迟构建的 CuTe DSL 内核替代大 batch 的 MoE 与 GEMM（通用矩阵乘）、对 indexer 的工作去重并分片，并把原版 vLLM 在 CPU 上逐步执行的每步操作改成 CUDA graph 回放。

write-up 还预告了两个后续：Meta 的 Muse Spark Open 发布后两天内，vLLM 的早期结果已超过每用户 950 tokens/s（K=7、AL=6）；GLM5.3 也将获得一套类似的低并发 decode 延迟优化机制，细节与成绩在后续文章中公布。

博客发布当天（10 月 16 日），PR #61867 刚触发新一轮 Buildkite CI（#95284）。fast-track 与 BYO-GPU 两份 RFC 都还是提案，评测镜像、可复现结果包与分层评测尚未落地；在更多贡献者能在自己的 GPU 上复现这组数字之前，这条以 agent 辅助方式开发的内核路径，全部证据都在 PR #61867 的评测表和它的 CI 记录里。

参考链接

vLLM 官方 X 帖文（2026-10-18）：
@vllm_project 账号主页：
vLLM 博客 write-up《Hyper Optimizing Kimi K3 in vLLM: Moving Fast and Responsibly》（2026-10-16）：
vLLM PR #61867（Kimi K3 Specialized Decode）：
fast-track model optimization RFC（issue #59665）：
Bring-Your-Own-GPU 评测 RFC（issue #61698）：
SemiAnalysis AgentX 方法页：
vLLM PR #61868（DeepSeek-V4.1-Flash）：