7 月 21 日，英伟达公布了 GB300 NVL72 训练 DeepSeek-V3 的最新成绩：在 256 张 GPU 上，单卡性能达到 1,648 TFLOPS。不到两周后，Cursor 开源了 Mixture-of-Kittens（简称 MoK），它没有继续追求更快的矩阵乘法，而是直接重写了 MoE（混合专家）的执行方式，把 token 调度、跨 GPU 通信和专家计算整合进同一个 GPU 内核。这一举动看似反直觉，因为 GB300 NVL72 已将 72 张 GPU 放入同一 NVLink Domain，整机架 NVLink 总带宽高达 130 TB/s，理论上 GPU 间数据传输已足够快。然而，在大规模 MoE 训练中，通信依然成为拖累专家计算的关键瓶颈。

MoE 模型通过 Router 为每个 token 动态选择专家，而专家分布在不同的 GPU 上。一次前向传播至少需要两轮跨卡通信：Dispatch 将 token 送到专家所在 GPU，Combine 将计算结果送回原位置。训练时反向传播还需额外两轮通信。问题在于，Router 每一步产生的数据分布都不同，系统需要先统计每个专家的 token 数量，再决定其在目标 GPU 的存放位置，并尽量将同一专家的数据连续排列，以便 Grouped GEMM 高效利用 Tensor Core。通信结束后，目标 GPU 还需确认远端写入完成，且专家负载不均导致部分 GPU 提前结束仍需等待。因此，所谓的“通信”阶段实际混合了数据搬运、布局生成、同步和负载失衡等多个环节。130 TB/s 只是整机架峰值带宽，并不代表每次动态、零碎的 MoE 通信都能跑满这些链路。

Cursor 的 MoK 设计核心之一是改变前向 Dispatch 的通信方向，从传统的 Push 改为 Pull。传统 Push 模式中，源 GPU 主动将 token 写入目标 GPU，但需要协调多发送方之间的目标地址，且同一专家的 token 需连续排列，否则后续 GEMM 需重新整理。Pull 模式则让保存专家的目标 GPU 主动读取所需 token，只需知道 token 在源 GPU 的位置，本地存放由自己安排，省去了多发送方之间的地址协调，且收到的数据可直接按本地专家排好。虽然 Pull 并未减少数据传输量——在 Cursor 的微基准中，同一 256×256 BF16 数据块，Push 移动约 159.6 KB，Pull 反而达 172.0 KB（因需额外发送请求）——但 Pull 能同时利用 NVLink 两个方向的独立通道，在专家负载不均衡的测试中，最高可提升 29% 的 NVLink 利用率。更关键的是同步延迟：Push 完成后目标 GPU 需等待其他 GPU 的完成信号，在 Expert Parallel 规模大时，一个 rank 最多可能涉及另外 71 个 peer；而 Pull 由本地 GPU 发起读取，数据回来即可使用。Cursor 的多节点微基准显示，signaling 延迟从 Push 的约 103 微秒降至 Pull 的 18 微秒。

MoK 并非全部采用 Pull，而是前向使用 Pull Dispatch、Push Combine，反向使用 Pull Reverse-Combine 和 Push Reverse-Dispatch。这是因为 Dispatch 阶段需要将多来源 token 重组为专家输入，Pull 更省协调；而 Combine 阶段结果归属明确，直接 Push 更简单。此外，MoK 将通信与专家计算整合进同一个 Megakernel，将 GPU 的 SM 分为两部分：一部分负责 Dispatch、Combine 和状态管理，另一部分执行 Expert FFN。通信侧通过 GPU 本地计数器通知计算侧，计算完成后再通知通信侧传回结果。这种方式可显式控制通信和计算各自占用的 SM 数量，避免多个 CUDA Stream 竞争资源。关键参数 minibatch（一次交给专家计算的 token 数）需平衡：太大则首批计算等待久，太小则专家 GEMM 任务不足导致 SM 空闲。Cursor 用 wave 判断边界，希望 minibatch 至少形成两个完整 wave。在 Hidden Size 7168、专家中间维度 2048 的 Kimi 2.5 形状上，minibatch 至少需约 2368 个 token；512 token 时前向耗时 5.981 ms，增至 2560 token 后降至 3.425 ms，继续增加无明显改善。

MoE 的另一挑战是 Router 跑完前无法预知每张 GPU 的 token 数量。若按最坏情况准备 buffer 会浪费显存，若先数 token 再让 CPU 分配空间则 GPU 需等待。MoK 采用固定大小的 Ring Token Buffer：空间先装 Dispatch 进来的 token，专家算完、Combine 传走结果后立即复用，前一个 macrobatch 的 Combine 可与下一个 macrobatch 的 Dispatch 同时进行。Ring Buffer 充当缓冲层，通信快时数据积累，计算快时等待下一批 token，整个过程由 GPU 状态推进，无需 CPU 每轮介入。此外，MoK 将 MXFP8 activation 的量化嵌入 Dispatch、Grouped GEMM 和 SwiGLU 数据路径，省去独立量化 kernel 及中间结果在 HBM 的来回读写。

Cursor 的 benchmark 测的是完整 MoE 层，包括 Schedule、Dispatch、Expert FFN、Combine 和加权合并，对比对象包括 NCCL + PyTorch、DeepEP、TransformerEngine 以及 HybridEP + Megatron。在 GB300 NVL72 上，相比每种场景最快的公开基线，MoK 的 MXFP8 前向最高提升 2.37 倍，反向最高提升 1.78 倍；BF16 前向和反向最高分别提升 1.92 倍和 1.58 倍。更关键的是端到端训练：Cursor 原生产方案已用 DeepEP，在 512 张 GB300 GPU 上换成 MoK 后，单卡吞吐从每秒 760.9 个 token 提高到 1070.2 个，提升约 41%。不过，Cursor 未公开完整逐项消融，无法准确归因 2.37 倍中各部分的贡献，但 Pull 对 NVLink 利用率和 signaling 延迟的改善可单独确认，其余收益来自整套执行方式的组合。

MoK 对硬件依赖较强，面向 Blackwell 和 NVL72 这类高速 NVLink Domain，Pull 的远端读取和细粒度交错依赖 GPU 间低延迟访问彼此显存。模型的 Hidden Size、Top-k、专家规模变化时，合适的 minibatch 和通信 SM 数量也需调整。这反映出在 GB300 这一代，单纯追求 GEMM TFLOPS 和 All-to-All GB/s 已不足以解释全部性能，token 到达时间、布局生成、计算启动时机、SM 分配和 buffer 释放等执行细节开始直接决定训练速度。一个拥有 130 TB/s NVLink 带宽的机架，仍需要为 MoE 重写 GPU 内核，原因在于链路虽快，但省下的是 GPU 等待数据的时间。

Cursor 重写 GPU 内核的行为，标志着 AI 竞争进入“全栈主权”的新阶段。过去应用层与底层分工明确，但如今竞争已到“去中间商化”阶段，Cursor 因“不得不做”而深入内核。DeepSeek 开启了工程榨取的新纪元，Cursor 则把这一趋势带到应用层。这种趋势可能重塑 AI 公司的定价权：决定估值的或许不再是拥有多少 token，而是代码离显存和寄存器有多近。无法穿透底层黑盒的 AI 公司，可能面临“平庸税”的困境。