Kimi K3解码不再逐行手写：智能体改写的CuTe DSL路径在16块GB300上跑到842 tokens/s

Kimi K3的解码执行不再由大量独立算子拼成，而是一条用CuTe DSL编写的融合路径，覆盖注意力、MoE和跨GPU通信。 原生vLLM在这些环节分别启动算子，路由器打分与隐输入投影在每块GPU上重复计算，注意力输出投影与全归约也分开执行。 在16块GB300、DSpark七个草稿词、合成接受长度6、批大小为1的设定下，聚合解码吞吐为842 tokens/s，是同规格投机解码下原生vLLM的1.73倍。

实现按批大小切换内核形态，并把计算与通信叠在一起。 小批量与大矩阵乘法的资源利用方式不同，通信等待期间GPU原本处于空闲。 注意力输入投影在批1至2用专用小矩阵内核、更大批量用split-K内核；注意力输出投影直接融合进全归约，小批量把生产者与消费者合成一个内核，大批量改为两阶段归约以减少GPU间数据移动。

MoE部分把原本每块GPU都做的路由打分与隐输入投影拆分到各张量并行rank上，再合并成一次矩阵乘法。 此前每块GPU都完整计算路由分数和隐输入投影，专家执行前存在重复计算、重复权重读取和多余内核启动。 共享专家放在独立流上，与路由或被路由专家计算重叠，调度控制各操作的GPU资源占用；小批量下另用侧流预取下一步权重以提高缓存命中率。

这套优化被放进一条可验证的贡献流程，而不是只交出一份加速比。 逐行人工审查每个内核、排查潜在问题并测试所有支持配置耗时很长，而跳过审查又有发布带缺陷代码的风险。 流程要求改动限制在模型代码内、明确支持的硬件与负载、同时跑内核测试与模型评测；审计中曾发现编译器把激活读取移到同步等待之前，修复方式是把该读取限制为静态权重。

已展示的范围是NVIDIA GB300上TP8与TP16、解码批大小至64、带不同草稿长度的投机解码，以及单个NVLink域内的解码上下文并行；吞吐数字为整个张量并行组的聚合解码吞吐，不含预填充。AgentX的1.8倍P90交互性对比是16块GB300的优化实现与8块GB300的早期vLLM结果相比。隔离约束有意排除了输入准备、采样和KV缓存管理这类共享组件的优化。

审计发现的编译器重排问题说明简单功能检查可能漏掉同步错误；长上下文与长生成评测暴露的注意力与通信数值问题，在固定启动时序的独立内核测试中无法复现。AgentX对比两侧GPU数量不同，文中未给出同硬件条件下的对照。快速通道流程仍是提案，其验证与维护负担能否随贡献增加而受控尚待观察。