英伟达用 AI 写的一万二千行，没人逐行审

硬件没换，模型没换，制程也没等下一代。速度还是快了。

一、发生了什么

10 月 16 日，vLLM 官方博客发了一篇技术复盘，署名作者是英伟达 CentML 的工程师 Benjamin Chislett。他做的事是：用大约一万二千行 CuTe DSL 代码写成一个融合内核，把月之暗面 Kimi K3 的推理速度拉上去。

按 SemiAnalysis 的测算，在同样的 GB300 NVL72 机器上，K3 达到每人每秒 423 个 token，提升 1.68 倍。vLLM 原文给的口径是：单批次下超过每秒 840 个 token，多种配置下解码吞吐提升 1.5 到 2 倍。需要说明的是，这些数字来自不同测法，不能混着比。

为什么这事难。K3 有 2.8 万亿参数，896 个专家，每次推理只激活其中 16 个。这种稀疏结构在训练时省算力，在推理时是工程噩梦：一个 token 走一遍前向，要在多张卡之间来回搬运数据，通信次数上百。瓶颈不在算力峰值，在数据怎么流动。

融合内核的思路就是把原本分散的注意力、路由、专家计算、通信合成一个大核，减少启动开销和显存往返。硬件不变，变的是数据在硬件上的走法。

二、跟你有什么关系

做推理服务的人，这是一份可以直接抄的作业。同样的卡，同样的模型，靠软件层拿到的 1.5 倍以上，比等下一代芯片现实得多。

用 API 的人，短期感知不到，中长期会体现在价格上。解码单位成本降下来，服务商的定价空间才会松动。

做工程管理的人，这篇博客最该读的不是性能数字，是里面那句自述：agent 帮忙产出的优化代码，已经快过团队评审和维护的速度。他们为此改了流程——发布快速通道机制，要求变更隔离、范围限定、系统性验证正确性，并把验证规模做大。人的角色从逐行看代码，变成看设计、看证据。

三、怎么判断

1. 分清测法。单批次吞吐、每用户速度、整体吞吐是三回事，看别人报数字先问是怎么测的。
2. 先测再换。拿你们的真实请求分布跑一遍，融合内核在长上下文、高并发下的表现未必一样。
3. 建立最小验证集。至少覆盖正确性、边界输入、性能回归三类，改内核必须有对应测试。
4. 把 AI 生成的改动切成小块。一次改一处，出问题能定位；一大坨提交，回滚都难。
5. 留一条退路。保留原始路径的开关，新路径出问题能一键切回。

四、三个别信的说法

「1.68 倍是官方数据。」 官方原文给的是 1.5 到 2 倍的区间，1.68 是第三方机构按特定配置测算的结果。引用时把出处带上。

「代码全是 AI 写的，人没参与。」 主导和架构设计是人类工程师，AI 承担的是内核编写、算子融合、通信重叠、参数调优这些最耗人的部分。说成"全自动"会误导后来者。

「人类不审代码了，风险没人管。」 恰恰相反，他们做的是把审查从行级升到设计级，同时用系统化验证兜底。审计里就抓到过一类问题：编译器把激活读取提到了同步等待之前，功能测试照样过，要专门查才能发现。

五、一句话结论

算力竞争正在分成两条线：造更强的芯片，和让现有芯片少搬数据。后一条，靠的是人加 agent 的工程能力。

信息来源

• 钛媒体：英伟达一万二千行代码优化 Kimi K3（2026 年 10 月 30 日）

功能与价格以官方公告为准。本文写于 2026 年 10 月 31 日。