vLLM 与英伟达借智能体编写 CuTe DSL 内核，Kimi K3 在 GB300 上批大小 1 解码达 842 token/s（原版 1.73 倍），并提出智能体优化代码的「快速通道」审查流程

这件事意味着什么

【要点】

vLLM 博客 10 月 16 日发文（作者为 NVIDIA 的 Benjamin Chislett），10 月 18 日 @vllm_project 在 X 上正式推送：团队借助编码智能体，为 Kimi K3（2.8T 参数 MoE）在 NVIDIA GB300 上写了一条统一的 CuTe DSL 解码路径，把注意力、MoE 与跨卡通信融合在一起，每层从原版 vLLM 的 23 个内核、130 微秒压到 13 个内核、69 微秒。

16 卡 GB300、TP16、批大小 1、开 DSpark 投机解码（合成接受长度 6）时解码 842 token/s，原版同设置 488，约 1.73 倍；不开投机解码，TP16 在批大小 1–64 上提速 1.62–1.92 倍，TP8 为 1.31–1.58 倍。AgentX 编码智能体负载上并发 1 的 P90 交互速度为每用户 403.2 token/s，此前 223.7。该路径为可选开关（decode_backend: latency_specialized）。

文章同时提出「快速通道」模型优化 RFC：智能体写出的推理代码已多到人工逐行审不过来，因此改为把改动隔离在模型代码内、限定适用硬件与负载但不砍生产必需功能、用内核测试加模型评测系统验证正确性、让贡献者先在自己的 GPU 上跑标准评测。审计中曾发现编译器把激活读取挪到同步等待之前，MRCR、AIME25 等长上下文评测也揪出了单测复现不了的数值问题。下一步用同样方法优化 DeepSeek-V4.1-Flash、Meta Muse Spark Open（早期每用户超 950 token/s）和 GLM-5.3。

【可核验】

vLLM 原文：https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel

vLLM 官方 X：https://x.com/vllm_project/status/2111637219647840611

对照：7 月首发支持时 TP16 批大小 1 为 118 token/s，开 DSpark 为 370（https://vllm.ai/blog/2026-07-27-k3）

【我们的判断】

一、重点不只是一个数字。智能体已经能写高难度 GPU 内核，瓶颈转到了审查和维护。vLLM 把审查前移给自动化验证，并靠隔离控制风险，这和 Anthropic 披露的 Claude Code 团队审查流程方向一致。

二、口径要看清：842 token/s 用的是合成接受长度，真实场景通常更低；AgentX 的约 1.8 倍是 16 卡优化版对比此前 8 卡的结果，不是同等硬件。这些都是自测数字，尚无独立复现。

三、它和 AMD MI355X 那篇（e/906）同一天发出，NVIDIA 和 AMD 都拿中国开源模型 Kimi K3 当推理性能擂台，部署者宜把两篇放在一起对照口径。