Kimi K3 在 vLLM 上提速：能当依据的是同卡不开投机的 1.3 到 1.9 倍，842 和 1.8 倍各有前提

开源推理框架开始合入由编程智能体协助写成、上万行的模型专用解码代码，速度数字也随之多出了好几种口径。

先给结论：英伟达为 Kimi K3 写的这条 vLLM 专用解码路径，能当部署依据的是同卡、同并行、不开投机解码时的 1.3 到 1.9 倍，而且批次越大，提速越小。博客开篇最醒目的 842 词元每秒，建立在人为设定的投机接受长度上；「交互速度 1.8 倍」比的是 16 张卡对 8 张卡。这三个数都不假，只是回答的问题不同。

发生了什么

据 vLLM 官方博客（10 月 16 日，作者为英伟达工程师 Benjamin Chislett，数字为作者自测，按企业宣称读），这项工作在英伟达 GB300 上为 Kimi K3 重写了几乎整条解码路径，注意力、MoE 与多卡通信都换成定制的 CuTe DSL 内核；每层耗时从 130 微秒、23 个内核降到 69 微秒、13 个内核。博客开头写明，这些内核是「智能体协助开发」的。

据 GitHub 上的 PR #61867，代码已于北京时间 10 月 16 日上午合入主干，新增 12,805 行、涉及 50 个文件；PR 描述称改动全部限定在 Kimi K3 的英伟达专用目录里；默认不启用，要手动打开 latency_specialized 解码后端。支持范围写得很窄：GB300 上的 8 卡或 16 卡张量并行、不开投机时批次不超过 64、投机草稿 3 到 7 个词元。

10 月 18 日，据 IT之家转述 SemiAnalysis 的文章，这项优化让 Kimi K3 在 GB300 NVL72 上达到每用户每秒 423 个词元，「对比相同硬件」提升 1.68 倍，内核约 1.2 万行。我们没有打开 SemiAnalysis 原文，这组数按媒体报道处理。

三个数，三个前提

842 词元每秒。 博客写明，这是 16 卡、批次 1、输入 1 个词元、输出约 1000 个词元、投机草稿 7 个、合成接受长度 6 时的解码吞吐，不含预填充；同设置下原版 vLLM 是 488，约 1.73 倍。合成接受长度 6 的意思是：假设每轮草稿平均有 6 个被接受。真实请求的接受率要看内容。PR 里另一组测试把合成接受长度降到 3.78、输入换成 3.2 万词元的混合提示词，16 卡批次 1 的解码吞吐是每秒 483 个，不到 842 的六成。

交互速度 1.8 倍。 博客称在模拟编程智能体流量的 AgentX 负载上，P90 交互速度从每用户每秒 223.7 个词元升到 403.2 个。同一段写明，优化版跑在 16 张 GB300 上，对照的是此前 8 张 GB300 的结果。卡数翻倍本身就会提高单用户速度，1.8 倍里有多少来自代码、多少来自多出来的 8 张卡，博客没有拆开。

不开投机的 1.3 到 1.9 倍。 这是最干净的一组：同卡、同并行、无投机。博客表格里，8 卡时批次 1 是 1.58 倍，批次 64 降到 1.31 倍；16 卡时批次 1 是 1.88 倍，批次 64 是 1.62 倍。PR 还给了一个更贴近生产的口径：输入 3.2 万词元、开启投机与上下文并行时，8 卡批次 1 的纯解码提速 1.50 倍，但把同时在跑的其他请求的预填充算进去，输出吞吐只快 1.32 倍；批次 2 时是 1.49 倍对 1.16 倍。

为什么重要

分析推断：这项优化的收益集中在低并发、要求单用户速度的一端，而这一端恰恰是每个词元最贵的地方。依据是 InferenceX 10 月 18 日的 Kimi K3 实测页（第三方评测）：同样在 GB300 NVL72 上，每用户每秒 50 个词元时每卡吞吐 17,872 个、按大型云厂商自有成本折合每百万词元 0.036 美元；把单用户速度提到 200，每卡吞吐降到 3,416 个、成本升到 0.19 美元，约 5 倍。编程智能体一轮要连续写几千个词元，等待时间直接决定一个任务跑多久，所以低并发提速对它最有意义；但决定大规模服务单价的高并发区间，正是提速最小的地方。InferenceX 页面没有写明这些运行是否启用了这条新路径，两者不能直接相乘。

另一件变化在代码之外。博客承认「智能体优化出来的推理代码，产出速度已经超过了我们的审核和维护流程」，并提出把模型专用优化隔离在模型目录内、限定硬件与批次范围、用系统化评测验证正确性。它举的例子很具体：审计发现编译器把激活值的读取挪到了同步等待之前；长上下文与长输出评测（MRCR、AIME25）暴露了单独测内核时复现不出来的数值问题。RFC #61698 说得更直白：AI 工具让写一个 PR 几乎不花钱，审一个 PR 的成本却没变。它提议由提交者用自己的 GPU 跑标准评测镜像，把证据附在 PR 上。

最强反方

最有力的反驳是：拆口径是吹毛求疵。842 和 1.8 倍都在原文里写明了前提，没有人隐瞒；而 1.3 到 1.9 倍本身已经是很大的提升，对部署方来说，同一批 GB300 平白多出三到九成的解码速度，是实打实的。至于高并发收益小，本来就不是这条路径的目标，它的名字就叫「低延迟专用」。

我们部分让步：原文确实写明了条件，问题出在转述环节，IT之家的标题里只剩下 1.68 倍。但我们坚持论点，原因有二：其一，对要算成本的读者，批次 64 时 1.31 倍和批次 1 时 1.88 倍是两种不同的决策依据；其二，这条路径只支持 GB300 单个 NVLink 域内的 8 卡或 16 卡，用其他 GPU 的团队拿不到这部分提速。

我们不知道什么

• SemiAnalysis 的 423 与 1.68 倍用的是什么并发、上下文长度和对照配置，为什么与博客的 403.2 和 1.8 倍不一致；我们只看到了 IT之家的转述。
• 真实编程智能体流量下的投机接受长度是多少，842 在生产里能剩下多少。
• 这上万行代码里，智能体写了多少、人改了多少，博客与 PR 都没有给出比例。
• PR 的正确性评测显示与原版的差距大多在约一个标准误之内，但 32k 输出上限下优化版被截断的样本略多，作者自己也写了原因不明。

接下来看什么

一是 InferenceX 等第三方测试是否单独标出这条专用路径的结果。二是博客预告的 DeepSeek V4.1 Flash（PR #61868）与 GLM 5.3 同类优化落地后，是否沿用同样的口径披露。三是 RFC #61698 是否被采纳：如果「提交者自带评测证据」成为惯例，智能体写的性能代码进入主流框架的速度会更快，审核瓶颈也会更清楚地写在纸面上。