Cursor 的 warp decode：翻转 MoE 推理并行轴，Blackwell 小批量吞吐提升 1.84 倍

Cursor 最近公布了一项名为 warp decode 的 MoE 推理优化方案。在 Blackwell GPU 的小批量自回归解码场景中，他们将计算组织方式从"围绕专家"改为"围绕输出"，在 B200 上实现了 1.84 倍的吞吐提升。

同时，去掉中间激活量化后，输出与 FP32 参考值的接近程度提升了 1.4 倍。性能和精度同时改善，在 kernel 优化领域并不多见。

传统路径的问题

MoE（Mixture of Experts）模型的工作方式是：每个 token 通过路由机制被分配到一小部分专家网络（比如从 128 个专家中选 8 个），然后由这些专家完成计算。

这个思路天然适合"围绕专家"来组织计算——先把每个专家需要的 token 收集起来，各自算完，再组装回去。在 prefill 和大批量推理中，这种方式很高效，因为每个专家上的工作量足以摊薄数据搬移的开销。

但到了自回归解码阶段，每次只生成一个 token，问题就暴露了。传统路径的 8 个阶段里，有 5 个纯粹在做数据布局整理——填充、分发、收集、归约——本身不产生任何计算结果。对单 token 场景，这些"簿记"开销无法被摊薄，成了主要瓶颈。

warp decode 的思路

warp decode 翻转了并行性轴：每个 warp（32 条并行线程组成的 GPU 执行单元）不再分配给某个专家，而是对应一个输出值。

每个 warp 从内存中流式读取所需权重，把 8 个路由专家的结果汇总到一个持续累加的寄存器中，最后写出一个标量。由于 warp 之间完全独立，不需要共享内存暂存、跨 warp 同步或中间缓冲区，整个 MoE 计算层被压缩为两个 kernel：moe_gate_up_3d_batched 和 moe_down_3d_batched。

具体收益包括：

• 去掉填充开销。 传统路径需要把每个专家的 token 列表填充到 2 的幂或 128 字节边界。warp decode 不按专家划分批次，这个问题直接消失。
• 去掉中间写入和归约。 传统路径中每个专家算完要把中间结果写入显存，再单独跑归约。warp decode 的每个专家贡献在 warp 内直接累加，中间结果不落内存。
• 省掉两个缓冲区。 传统路径需要激活收集缓冲区和每专家输出缓冲区（8 专家 × 2048 隐藏维度 × 2 bytes = 32 KB/token）。warp decode 在 32 条 warp lane 上直接汇总，每个 token 减少 32 KB 以上的中间缓冲区传输，释放的 L2 缓存容量留给权重数据。

实测数据

Cursor 在内部推理系统上，基于 NVIDIA B200 运行 Qwen-3 风格模型测试：

• 吞吐量提升 1.84 倍，在不同上下文长度分组中表现一致，说明这是纯粹的生成阶段改进
• B=32 时持续带宽达到 3.95 TB/s，约为 B200 测得峰值 6.8 TB/s 的 58%
• 输出与 FP32 参考值的接近程度提升 1.4 倍——激活保持 BF16、累加器保持 FP32，避免了中间量化引入的舍入误差
• 与 reference 实现对比，最小余弦相似度 > 0.999996，最大绝对差异为 0.001953

边界与适用场景

warp decode 并非对传统方案的全面替代。Cursor 明确指出，在 prefill 和大批量推理中，专家中心的打包方式仍然更优——因为许多 token 共享同一个专家，整理数据的成本可以被足够的实际计算摊薄。

warp decode 的优势集中在小批量 decode 场景，这正是大多数 API 服务在长文本生成时频繁面对的情况。对 Cursor 自身的 Composer 模型训练和迭代而言，这项优化直接缩短了研究闭环——模型改得更快、发得更多。

观察与延伸

MoE 模型近两年在开源大模型中快速普及，但推理端的工程优化一直落后于模型设计本身。大部分框架沿用的仍是"专家中心"的执行范式，对 decode 阶段的低效问题缺乏针对性处理。warp decode 提供了一个思路：当工作负载的特征（单 token、低批量）不再匹配计算组织的默认假设时，翻转并行轴可能比在现有流水线上做局部优化更有效。

对提供 MoE 模型 API 服务的厂商来说，这类针对 decode 的专项优化会直接反映在长文本生成的响应速度和成本上，值得持续关注。

来源：Cursor Blog