10月16日，英伟达把针对 Kimi K3 的一整套推理优化合入了开源引擎 vLLM。网上流传最广的说法是"提速 1.68 倍"——这个数字出自调研机构 SemiAnalysis 的解读：按每用户吞吐计，K3 在 GB300 NVL72 上达到 423 tokens/s。 而同一篇 vLLM 官方博客主打的口径是单请求解码从 488 提升到 842 tokens/s，提速 1.73 倍。 同一个引擎、同一天合并的代码，两个数字并不矛盾，它们分别站在不同的测试口径上；而对更关心"我的 AI 对话框什么时候变快"的打工人来说，这两个数字离真实办公体验都还有明确的一段距离。微博vLLM官方博客
英伟达这次做的不是调参，是重写内核
这项优化的思路，是把 K3 在 vLLM 里几乎整个解码路径——注意力、MoE（专家混合）、跨卡通信——替换成用 CuTe DSL 为 GB300 定制的执行内核。官方博文给了一组直观对比：原生 vLLM 跑一层需要 130 微秒、23 个内核，优化后同一层只要 69 微秒、13 个内核。 据 SemiAnalysis 的说法，这套 Megakernel 包含约 1.2 万行代码，主要由英伟达工程师借助 AI 编程代理编写完成——用 AI 写引擎、再让引擎更快跑 AI，本身就是这次披露里最受技术圈讨论的部分。 K3 是月之暗面 7 月中旬发布的 2.8 万亿参数模型，原生支持视觉、百万 token 上下文，7 月底开源权重时 vLLM、英伟达、AMD 就做过 Day-0 适配。vLLM官方博客微博vLLM官方博客
1.73 倍站在什么条件下
1.73 倍对应的是最理想的实验室口径：batch 为 1（只测一个请求）、输入 1 个 token、输出 1000 个 token 的合成负载、开启 DSpark 投机解码（草拟 7 个 token、固定接受长度 6），且只统计解码输出、不含输入处理——博文也注明这是 AL=6 受控基准下的结果，而非真实会话的常态负载。vLLM官方博客
把公开的结果表摆开，规律很清晰：关掉投机解码后，16 卡口径的提速在 1.62～1.92 倍之间随批量浮动，8 卡口径降到 1.31～1.58 倍，并发越高、加速比越向区间下沿收敛。SemiAnalysis 的 423 tokens/s/用户、1.68 倍，则是按"每用户每秒 token"计算的另一种口径，数值比 842 的实验室极限值低。此外还有一项常被引用的"1.8 倍"（AgentX 负载下 P90 交互速度 403.2 对比 223.7 tokens/s/用户），但它的基线跑在 8 张 GB300 上、优化后跑在 16 张上，硬件规模不对等，不能直接读成纯软件提速。 越接近真实使用，倍数越小于 headline 数字——这是理解这次优化的基本坐标。vLLM官方博客
K3 最被吐槽的恰恰是"慢"，但体感瓶颈不止解码
这轮优化之所以迅速引发讨论，是因为它打在 K3 发布三个月来最集中的痛点上：慢。ArtificialAnalysis 的多维评测判断其智能领先、但速度明显偏慢、价格尤其昂贵、回答冗长，这套评测被 B 站多个实测视频反复引用。 此前 K3 的体验吐槽里，“2分钟任务拖半小时”"199额度一天用完"是最典型的负面样本。 办公场景又恰恰是 K3 被用得最重的地方：社区里热度最高的用法集中在文档密集任务——用百万上下文啃几十页的报告、跑本地 Agent “Kimi Work”（官方教程笔记点赞近 1400）、生成可编辑 PPT。 能力口碑和速度体感之间的落差，正是这次机房提速被寄予期待的原因。哔哩哔哩抖音小红书
但打工人的等待链条里，解码吞吐只占一环：大文档的输入处理、高峰排队、长上下文"无声截断"的抱怨，优化都不会直接解决——这套内核加快的是"写"，不解决"读"和"排不上队"。
从机房提速到体感变快，还差两个确认
普通用户真正吃到这轮红利，需要盯两个信号。其一是 Kimi 官方是否把官网、App 的服务栈升级到合入该优化的版本——博客确认的只是开源引擎侧合并，C 端何时生效尚无时间表；其二是算力成本下降是否传导到价格和额度：K3 已在 9 月下旬登陆 AWS、采用按调用量分成的模式，云厂商侧部署是这项优化到达用户的另一条路径，但成本让利目前只是可能性，不是已发生的事实。 还要留意，这套内核是为 GB300 级别集群定制的特化路径，大量仍用旧卡或其他引擎的服务商未必同步受益。"机房提速 1.68 倍"到"你的文档生成快了三分之一"之间，隔着一条尚待走完的链路。第一财经
