共计 1356 个字符，预计需要花费 4 分钟才能阅读完成。
多数报道只关注 Kimi K3 提速 1.68 倍, 却忽略 vLLM 博客关键警示:AI 生成推理代码已快到人类来不及逐行审查。英伟达工程师借助 …
导语:多数报道只记住了“Kimi K3 提速 1.68 倍”。但 vLLM 在 2026 年 10 月 16 日发布的技术复盘里, 还写着一句更值得琢磨的话: 智能体优化的推理代码, 正在快过人类团队的审查与维护流程。
📌 芯片没换, 变的是数据怎么走
这篇复盘由英伟达 CentML 工程师 Benjamin Chislett 署名。他做的事是用约 1.2 万行 CuTe DSL 编写的 Megakernel, 把月之暗面 2.8 万亿参数的 Kimi K3 推理速度大幅拉高。据 SemiAnalysis 测算, 在相同的 GB300 NVL72 硬件上,K3 达到 423 tok/s/user, 提升 1.68 倍;vLLM 博客给出的数据是 batch 1 下超过 840 tokens/s, 多种配置下解码吞吐提升 1.5—2 倍。
没有换卡, 没有等下一代芯片。
🔍 K3 难在哪: 瓶颈不在算力, 在数据搬运
Kimi K3 采用 Stable LatentMoE 架构,896 个专家每次只激活 16 个。这种极端稀疏在训练端是“少激活撬动大容量”的利器, 到推理端却成了工程噩梦: 单次前向的 HBM 带宽需求约 1.5TB, 触发超过 120 次 All-to-All 通信, 计算单元大部分时间在等数据。
传统推理引擎把解码拆成注意力、MoE 路由、专家计算、通信等一串独立内核,每次启动都有开销 , 每次交接都要过显存。Megakernel 的思路是算子融合——合成一个高度融合的超级内核, 减少启动次数、合并访存、让计算与通信尽量重叠。 硬件没变、模型没变, 变的是数据在硬件上的走法。
💡 真正的信号: 代码写得太快, 人来不及逐行审
比 1.68 倍更值得注意的,是博客里那句“Agent-optimized inference code is outpacing our review and maintenance workflow”。团队明确使用了智能体辅助开发, 让 AI 参与最硬的环节: 复杂 GPU 内核编写、跨算子融合、通信重叠、不同 batch 与 GPU 配置下的调优。
📊 从“审代码”转向“设计验证边界”
- 隔离变更: 让每次改动的边界清晰可控;
- 限定范围: 避免优化扩散到难以验证的区域;
- 系统化验证正确性: 用流程替代肉眼扫描;
- 扩大验证规模: 以覆盖面换确定性。
审计中曾发现编译器把激活读取提前到了同步等待之前, 修复方式是限制该加载类型。这类错误能通过简单的功能测试, 需要针对性排查才会暴露。
🚀 看点: 算力竞争的维度正在分裂
当制程红利放缓,单卡峰值性能的追赶以年为单位计算,“让已有硬件跑出更高有效算力”正在成为回报率更高的路径。SemiAnalysis 创始人迪伦曾判断, 性能提升不能单靠硬件堆砌, 模型架构、软件栈与底层硬件的深度协同才是效率跃迁的突破口。
另一层微妙关系在于: 英伟达正在为月之暗面、DeepSeek 等中国模型做优化,相当于卖铲子的人顺手帮你磨铲子——既拉动硬件销售, 也证明自己在管制框架下仍是绕不开的一环。
🧭 总结
“来不及审”提出的问题,目前没有标准答案: 当 AI 开始优化 AI, 且优化的速度快过人类理解的速度,“人在回路中”还守不守得住?vLLM 给出的务实回答是——接受看不懂每一行代码的现实, 然后用流程兜底。
