先说结论：这1.68倍说的是每个用户的出字速度——优化后，2.8万亿参数的Kimi K3在GB300 NVL72系统上达到每用户每秒423个token，是此前的1.68倍。数据出自调研机构SemiAnalysis的发文，10月18日被国内媒体转载。提速的源头，是英伟达上游合入开源推理引擎vLLM的新解码路径，10月16日经PR #61867合并，需要你主动打开才生效。IT之家微博知乎
按英伟达官方博客的纯decode测试，数字更具体：16张GB300上开启DSpark投机解码（合成接受长度6），单请求输出速度从原版vLLM的488 token/s提升到842 token/s，正好1.73倍。vLLM官方博客
并发数才是这轮优化真正的分水岭。就算不用投机解码，各batch档位也普遍有明显提速，但收益随并发升高而收窄：TP16在batch 16到64区间剩1.62至1.71倍，TP8的8卡配置是1.31至1.43倍。换句话说，并发越低、提速越猛，这套路径是为"一个人等一个回答"的交互场景定制的。vLLM官方博客
在回放真实coding agent流量的AgentX负载上，官方博客给出的P90交互速度从223.7 token/s/user提升到403.2，但它同时注明前者用16张GB300、对比的是上一代8张的结果，这1.8倍不能全部记作本轮优化的功劳。vLLM官方博客
提速的关键不是把数学算得更快，而是少让GPU在缝隙里等。原版vLLM每层要启动23个kernel、耗时130微秒；新的专用路径用CuTe DSL把注意力、跨卡通信和MoE融合重组后，只剩13个kernel、69微秒。研究这次PR的知乎工程师把原理概括得更直白：把原本分散在一层里的操作重新组织，同时尽量让GPU计算、跨卡通信和权重读取同时进行。vLLM官方博客知乎
折算到工作流上：同样按842对488 token/s计算，生成100万输出token的时间从大约34分钟缩短到20分钟，省下14分钟左右；跑整夜的批量agent任务，每1000万输出token大约省2.4小时。但这笔账只有自建部署Kimi K3的人才算得起——新路径只在8张或16张同NVLink域的GB300上启用，且decode batch最高到64。而且这些是纯decode数字，真实长输入、prefill混跑的负载里，最终输出吞吐的提升还会再打折扣。vLLM官方博客知乎
这不是Kimi K3第一次被"榨干"。9月中旬，vLLM社区的优化系列就把K3的端到端吞吐抬高了2.2至2.8倍、延迟降了56%至60%，用的还是B300。这轮的方法论已经开始复制，DeepSeek-V4.1-Flash将在PR #61868中沿用同一套设计。而推理层的军备竞赛早就不只在英伟达的卡上：vLLM原班团队创办的Inferact，上一周刚把K3的92个MoE层写进同一个megakernel，在16颗谷歌TPU上跑出709 token/s的单用户输出。vLLM官方博客vLLM官方博客新智元
所以"你的AI工作流能省几小时"的诚实答案是：自建GB300集群跑K3的用户，交互场景近2倍的decode提速今天就能拿；而用Kimi App或API的绝大多数人，这1.68倍还停在论文和PR里。值得盯的信号是月之暗面和云厂商何时把这批opt-in优化默认打开并部署到面向普通用户的服务器上——跑分变成你等待时间的缩短，缺的就是这一步。
