10 月 16 日，英伟达工程师把一项针对 Kimi K3 的推理优化合并进了推理框架 vLLM 上游，这份 PR 自称让 K3 在 GB300 上实现了 1.5–2 倍解码提速。 10 月 18 日上午，调研机构 SemiAnalysis 发布测算，2.8 万亿参数的 Kimi K3 在 GB300 NVL72 上达到每用户每秒 423 个 token、性能提升 1.68 倍，IT之家当天转述后把话题推上热榜。 英伟达官方博客没有给出单一倍数，而是列出多项测试配置下解码吞吐提升 1.5–2 倍的区间。两种说法都成立——1.68 倍是 SemiAnalysis 评测体系里“同一块硬件、新旧两版 vLLM”的端到端对比，官方数字则按 batch、投机开关等条件逐项标注。差异的根源在条件，而条件，恰恰是这件事里最值钱的部分。GitHub微博
提速的不是芯片，是一层的执行方式
K3 每生成一个 token，每一层都要依次经过注意力计算、跨卡归约、MoE 路由、专家计算等步骤。原版 vLLM 每层要启动 23 个 kernel、耗时约 130 微秒，新优化把这层活重写为 13 个 kernel、约 69 微秒。 做法有四种：按 batch 大小挑专用 kernel——小矩阵用定制实现，大 batch 换成 split-K 分摊计算；把注意力输出投影直接与跨卡 all-reduce 融合，结果放进 NVLink 可访问缓冲区，接收端不等齐就继续算；MoE 的路由分数拆到各 TP rank 分摊，共享专家放独立 stream 与路由重叠执行；通信空档期用旁路 stream 预取下一步权重、拉高缓存命中率。打个比方，不是车跑得更快了，而是把红灯等待和变道绕路省掉了。vLLM官方博客
边界也要说清：这条路径需要显式开启 `decode_backend: latency_specialized` 才会生效，官方验证范围只覆盖 GB300 上的 TP8/TP16、解码 batch 不超过 64。GitHub
842 tok/s 是极限条件的峰值，真实负载要打折
传播中最亮眼的“842 tokens/s”有三个前提：batch=1、开启 DSpark 投机解码、并人为设定平均每步接受 6 个 token；它的对比对象是同配置原版 vLLM 的 488 tokens/s，于是得出 1.73 倍。 换成更接近真实的负载，收益明显收缩：32K 输入、混合 prefill 的场景下，纯解码提升仍有 1.36–1.75 倍，但把其他请求的 prefill 算进去，端到端输出就打了折扣——PR 里对此写得很直白。 关闭投机解码时，TP16 在 batch 16–64 区间仍有 1.62–1.71 倍提升，且 batch 越大、比例越低。 并发越低、解码越重，这套优化的收益越大；高并发的批量服务里，收益占比会缩水。 至于博客提到的 AgentX 智能体负载“1.8 倍”（每用户 P90 交互性 403.2 对 223.7 tokens/s），是 16 卡新方案对比此前 8 卡基线，属于跨配置比较，不能当同规模增益读。知乎GitHubvLLM官方博客
好消息是提速没有牺牲答案质量：AIME25、GPQA-Diamond、MRCR 长文检索三项评测显示，优化路径的成绩与原版相差基本在一个标准误以内，长上下文场景也做了逐 token 数值校验。
比数字更值得注意的信号：kernel 是 AI 写的，而且写得比人审得快
这篇官方博客的副标题叫“Moving Fast and Responsibly”，正文里英伟达罕见地承认了一个流程危机：agent 生成优化代码的速度，已经超过人工逐行审查和维护的吞吐，省略审查又可能把有缺陷的代码放上生产。 解法不是少优化，而是改规则——把模型专属优化走“fast-track”通道：改动限制在模型自己的目录里、明确支持的硬件和工作负载边界、提交方（包括 agent）必须先自行跑完正确性与全配置性能验证，人类评审从设计层面而非逐行把关。相关 RFC 已经提出，Kimi K3 是按新模式落地的第一单；同一套模板已经用到 DeepSeek-V4.1-Flash 的优化 PR（#61868）上。被改变的首先是推理优化的生产速度，其次才轮到每个模型的 token/s。vLLM官方博客
战局生变的地方：三路人马在同一时间围着同一个 K3 拆算子
为什么是 K3？官方口径里，它是一个 2.8 万亿参数模型，基于 KDA 混合线性注意力机制和注意力残差技术构建，拥有 100 万 token 上下文窗口，是全球首个开源的 3 万亿级别模型。 今年 7 月 16 日发布后，这种架构在低并发解码时受内存读取和 kernel 启动开销拖累最重，是推理优化难度最高的模型之一，也因此成了各家硬件证明协同设计能力最合适的试金石。知乎
于是同一时间窗口里出现了三幕：英伟达把 K3 列为 specialized decode 路线的首发模型；稍早一周，vLLM 原班人马创立的 Inferact 开源了 TPU Megakernels，把 K3 的 92 个 MoE 层写进同一个程序扔到 16 颗谷歌 TPU v7 上跑，开投机解码单用户 709 tokens/s，压过 16 块 GB200 上原版 vLLM 的 452——而 TPU v7 的纸面显存带宽（7380GB/s）还低于 GB200（8000GB/s），赢在写法不在参数。 同期 AICC2026 上，浪潮信息用 128 颗本土芯片的元脑 SD200 Ultra 超节点跑同一个 K3，把 token 生成时延压到 5.85 毫秒，其“超级算子”有一大块是让 K3 自己写出来的。算力竞争的重心正在从“谁的卡多”挪向“谁能榨干每张卡里的工程余量”，而一款中国开源模型同时成了英伟达、谷歌、国产芯片三条路线的标靶和标杆——这才是“战局生变”更准确的写法。微博
这件事对不同用户意味着什么
在 GB300 上自建 K3 推理服务、且以低并发解码为主（例如编程智能体、长文档单用户会话）的团队，现在多了一个可选项：升级到包含该 PR 的 vLLM 版本并打开开关即可，代价是要接受它暂不覆盖高并发和混合批次的回退路径。其余用户不必把 1.68x 读成“K3 全线快了一倍”。往后看两个信号就够：fast-track RFC 能否落地，决定这类优化能以多快速度复制到其他模型；各家下一轮 Megakernel 的对比对象，是否还会像 AgentX 那样跨硬件配置比。看提速新闻时先问三件事——开没开投机解码、batch 是多少、算没算 prefill——基本就不会被任何一个“倍”字带偏。
