AREX Feed Article
Cursor 放出 MoK：NVL72 训练提速 2.37 倍
2026 年 8 月 4 日，Cursor 在官方博客和 X 上宣布开源 Mixture-of-Kittens（MoK），一个为 NVL72 系统从头构建的 MoE 训练 megakernel。MoK 将混合专家层中所有的 GPU 间通信和浮点计算融合进单个完全确定性内核，在 GB300 NVL72 上跑 MXFP8 前向传播时，吞吐量比最强公开基线高出 2.37 倍。
端到端训练实测中，512 块 GPU 的每秒 token 数从 760.9 提升到 1,070.2，提速 41%。这个 kernel 已经在 Cursor 自家 Composer 模型的生产训练中驱动了数万块 GPU。
MoK 发布在 上，Apache 2.0 协议。需要 NVIDIA Blackwell SM100 或 SM103 GPU（即 GB200 或 GB300 NVL72 机架），CUDA 13.0+，PyTorch 2.10+。
51 万次围观，社区最先盯上的不是速度，是硬件门槛
Cursor 的在三天内累积了超过 51 万次浏览、6,088 个赞和 466 次转发。但转发中反复出现的一个话题是 MoK 的硬件要求，而非 2.37 倍提速。
"Your GeForce rig and PyTorch project can stop refreshing GitHub,"Windows Forum 在推文中写道。MoK 只跑在 Blackwell 机架上，消费级 GPU 根本沾不上边。另一位用户 @gnotnuk 则调侃命名："cursor named their new open source kernel 'Mixture-of-Kittens.' we have fully abandoned serious naming in this industry and i respect it."
日本用户 @hfujikawa77（1.1 万关注者）给出了更直接的判断："AI 基础设施的差异化，不再只是秘藏起来，而是在标准化和采用上抢地盘的局面越来越多了。"
中文社区同样迅速跟进。@yibie 在 8 月 7 日发布长推详细拆解了 MoK 的性能数据和技术架构；博士生 @vintcessun 点出工程上的关键细节：5 个可调超参在 SM、显存和通信之间做"显式交易"。
分布式训练项目 Templar（@tplr_ai，1.3 万关注者）的评论指向了更底层的意义："训练 kernel 优化是大规模分布式训练中被低估的瓶颈。当你在多个节点上训练时，每一个效率提升都会叠加。"
一个代码编辑器，怎么会去写 GPU 内核？
Cursor 以 AI 编程工具的身份被开发者熟知，但过去两年它在训练基础设施上的投入很少被外界注意到。
MoK 的坦承，随着 Composer（Cursor 的 agentic coding 模型）的训练和推理规模不断扩大，MoE 层一直是最大瓶颈。"取决于工作负载和训练配置，它可能消耗超过一半的端到端训练时间。"
过去一年，Cursor 自己写了 MXFP8 和 NVFP4 训练 kernel，还开发了用于 MoE 推理的 "warp decode" 方案。但这些都只优化了计算侧，默认 GPU 间通信由其他组件处理。在 Cursor 的生产负载中，通信成了真正的卡点。
转折点来自迁移到 GB300 NVL72。一台 NVL72 是 72 块 GPU 通过 NVLink 互联的单域机架，天然适合细粒度的计算-通信重叠。但 GB300 内置的 Grace CPU 相对 GPU 太慢。Cursor 团队发现，GPU streams 很容易追上 CPU 侧的工作，导致 GPU 在那段时间完全空闲，因此必须尽可能砍掉 CPU-GPU 同步。
博客末尾鸣谢了 Chris Ré、Sasha Rush、Less Wright、Chen Lu 和 Nathan Wang 审阅了该文。署名作者为 Stuart H. Sul、Nash Brown、Henry Wildermuth、William Lin 和 Federico Cassano，均来自 Cursor Research。
pull 代替 push，ring buffer 踢掉 CPU：三个决定性的设计选择
MoK 的技术方案围绕三个核心决策展开。
第一，用 pull 做 dispatch，用 push 做 combine。现有方案如 DeepEP 普遍采用 push 方式分发 token。Cursor 的微基准测试发现，push 在单方向上的总字节数确实更少，但 NVLink 有独立的双向通道，要达到标称的 1.8 TB/s 带宽，流量必须双方向同时跑满。在专家负载不均衡的实际场景下，pull 方式的 NVLink 带宽利用率比 push 高出 29%。
更关键的差异在信令开销。push 方式下，一个 rank 在启动 expert-grouped GEMM 之前，必须等待最多 71 个对等 GPU 的完成信号并执行内存栅栏，实测延迟约 103 微秒。pull 方式下，每个 rank 发出加载请求后数据到达即可立即使用，无需跨 GPU 同步，延迟仅 18 微秒，差距约 5.8 倍。MoK 在前向采用 pull dispatch 加 push combine，反向采用 pull reverse-combine 加 push reverse-dispatch。一整张调度表同时服务四个通信操作，只消耗不到 3% 的 MoE 总运行时间。
第二，ring token buffer 彻底消除 CPU-GPU 同步。MoE 层不知道每个 rank 会收到多少 token，路由结果是动态的。传统方案要么丢弃超出固定缓冲区的 token，要么把每 rank 的 token 计数发回 CPU 让 CPU 分配精确大小的缓冲区。前者损害训练质量，后者在 Grace CPU 慢的 GB300 上行不通。
MoK 用一个固定大小的环形缓冲区（macrobatch）代替，以 minibatch 粒度循环使用。前向 pass 中 dispatch 填充槽位、combine 清空槽位，跨 macrobatch 边界做 dispatch-combine 交替，缓冲区一空就立即复用。反向 pass 以反向顺序遍历 macrobatch，最大化减少前向激活重算。
第三，minibatch 粒度不在两端，而在中间。Comet 的做法是极致细粒度，发够一次矩阵乘加指令的 token 就启动计算。DeepEP 是粗粒度，一次发数千甚至数万 token 再统一计算。Cursor 发现最优解在中间且依赖工作负载：太细则 tensor core 无法充分饱和，太粗则 GPU 等待首轮数据的时间太长。
MoK 将 minibatch size 暴露为可调参数，建议选择能让每个 expert-grouped GEMM 至少填满两轮 SM wave 的值。以 Kimi 2.5（Composer 2.5 的基座模型）shape 为例，256 个 SM 的 Blackwell GPU 上，最低有效 minibatch 约为 2,368 token。
MoK 提供 BF16 和 MXFP8 两种精度模式。MXFP8 下权重预量化，激活量化融合进 dispatch all-to-all、expert-grouped GEMM 和 SwiGLU。Router 权重梯度采用 SonicMoE 风格的计算方式，融合进 SwiGLU backward 以避免额外内存搬移。内核通过 Blackwell 的 Cluster Launch Control 调度，机架间 RDMA 通信不必在 megakernel 完成后才能开始。
Apache 2.0 开源，但 NVL72 俱乐部门槛不低
MoK 的开源协议是 Apache 2.0，没有附加商业限制。但硬件要求将实际用户限定在一个很小的圈子里：拥有或租用 GB200/GB300 NVL72 机架的前沿实验室、融资充裕的模型创业公司、GPU 新云厂商和国家计算中心。单节点团队和 8 卡工作站被排除在外。
这不是疏忽。MoK 的设计前提是 72 GPU 的单 NVLink 域、双向 NVLink 利用率优化、避开慢速 Grace CPU，每一项都紧耦合到 NVL72 架构上。"为 NVL72 从第一性原理构建"在博客中反复出现。
在此之前，大模型训练基础设施的优化主要由两类玩家推动：NVIDIA 自己（HybridEP + Megatron 是官方推荐的 NVL72 方案），以及像 DeepSeek 这样拥有大规模集群的前沿实验室（DeepEP 即为其产物）。Cursor 以一家应用层公司的身份进入这个赛道并开源方案，让"应用层公司做底层 infra"这条路变得可复现。
@spotTheGap 的评论捕捉到了这一点："Open-sourcing the training kernel is the real flex. Product wrappers fade. Shipping production MoE infra others can actually run is how you pull the field forward."@KenHendricksJr 则更简洁地写道："The harness company just became a training infra company."
这不是一次开源秀
Cursor 开源 MoK，不是一个 IDE 公司随手发了个玩具 kernel。
MoK 已经在 Cursor 的生产环境中驱动 Composer 训练、跑在数万块 GPU 上、端到端实测提速 41%。Apache 2.0 协议意味着任何有 NVL72 机架的组织都可以复现这套效率。但这也是门槛所在：能真正用上的人不多，而能用上的人恰好是 Cursor 在模型能力竞赛中最直接的对手。
Cursor 的博客最后一段提到，随着能写出高性能 kernel 的 AI 模型出现，"去年写 megakernel 还需要一层简化的抽象框架，今年我们不需要了。在 agent 的帮助下，我们用一个小团队从零完成了分布式 MoE megakernel。"开源 MoK，也是这个过程的一部分：过去手写的单算子 kernel 如今几乎全由 AI 完成，megakernel 级别的复杂度也开始被 agent 辅助攻克。