⚙️ 系统优化 · 内核开源
把 MoE 通信延迟从 103μs 压到 18μs：Cursor 开源 GPU 内核 MoK
NVIDIA 公布 GB300 NVL72 训练成绩不到两周，Cursor 开源了 MoK（Mixture-of-Kittens）。它重写了一层 MoE 的执行方式，把 token 调度、跨 GPU 通信与专家计算合并进同一个 GPU 内核。多节点微基准中，signaling 延迟从约 103μs 降到 18μs；512 卡端到端训练吞吐提升约 41%。
来源：综合公开信息•
事件时间 2026-08•
全文约 4 分钟读完
#Cursor
#MoK
#MoE
#GPU内核
#AI基础设施
103μs → 18μs
signaling 延迟 · 多节点微基准
2.37×
MXFP8 前向最高提升
+41%
512 卡端到端吞吐提升
⚡ 30 秒速览
- 事件：Cursor 开源 MoK——把 MoE 的 token 调度、跨 GPU 通信与专家计算塞进同一个 GPU 内核，改变执行方式，而非继续堆矩阵乘法。
- 关键杠杆：前向 Dispatch 从 Push 改为 Pull。目标 GPU 主动读取 token，省掉多发送方之间的目标地址协调。
- 硬数据：signaling 延迟 103μs→18μs；MXFP8 前向最高 2.37×；512 卡端到端吞吐 760.9→1070.2 tokens/s（+41%）。
- 三个机制：Pull 通信、Megakernel SM 分区、Ring Token Buffer，组合成一条连续的 MoE 流水线。
- 必须看清的边界：强依赖 Blackwell 与 NVL72 高速 NVLink；官方未公开完整逐项消融，2.37× 的内部构成无法精确归因。
- 深层信号：应用层公司开始重写 GPU 内核——AI 竞争正在进入「全栈主权」阶段。
01硬件已经足够快，为什么还要重写内核？
7 月 21 日，NVIDIA 公布 GB300 NVL72 训练 DeepSeek-V3 的最新成绩：256 张 GPU 上，单卡性能达到 1,648 TFLOPS。
不到两周，Cursor 开源了 MoK。它没有继续折腾更快的矩阵乘法，而是直接重写了一层 MoE 的执行方式。
这件事，有点反直觉。
NVL72 把 72 张 GPU 放进同一个 NVLink Domain，整机架 NVLink 总带宽达到 130 TB/s。按这个规格，GPU 之间传数据应该早已不是瓶颈。但在大规模 MoE 训练里，通信依然会拖住专家计算。
问题出在 MoE 的数据流。
惯性认知
硬件堆料已经足够猛：130 TB/s 机架带宽、1,648 TFLOPS 单卡，跨卡传输不该是瓶颈。
真实瓶颈
MoE 通信高度碎片化：Router 每步重新决定 token 去向，token 跨卡搬运、等待、重排，执行细节开始直接决定训练速度。
如何阅读：左侧是「硬件够快」的直觉，右侧是 MoE 实际运行时的瓶颈。两者之间的落差，正是 MoK 要补的窟窿。
要理解 MoK 的设计为什么有效，得先看清一层 MoE 到底在什么地方交了「通信税」。
02MoE 的「通信税」：一次前向，两轮跨卡
普通稠密 FFN 里，token 经过哪些权重基本固定。MoE 加入 Router 后，每个 token 临时选择几个专家；当采用 Expert Parallel 时，专家又被拆到很多 GPU 上。
于是，一次前向传播至少发生两轮跨卡通信：
Router 决策→Dispatch 送 token→Grouped GEMM→Combine 送回
训练还有反向传播，对应再执行两轮反方向通信。麻烦在于，Router 每一步给出的数据分布都不同——某个专家这一步可能收到很多 token，下一步又很少。系统要先数清每个专家有多少 token、决定放在目标 GPU 的什么位置、把同一专家的数据尽量排在一起。
2一次前向的跨卡通信轮次
71单 rank 最多涉及的 peer 数
130TB/s · NVL72 机架峰值带宽
4单个「通信」阶段混杂的事件数
如何阅读：「通信」不是一次单纯搬运，而是数据搬运、布局生成、完成同步、负载均衡的叠加。130 TB/s 是峰值，不代表每次动态、零碎的 MoE 通信都能跑满链路。
通信结束也不能立刻开算——目标 GPU 要确认远端写入全部完成；专家负载不均时，部分 GPU 早早结束，还得等最忙的专家收尾。
DeepEP 已经让数据搬运很快了。但一层 MoE 仍要在 Dispatch、Grouped GEMM、Combine 之间不断交接，这里出现一个很实际的矛盾：
等 token 到齐再算，矩阵大，Tensor Core 舒服，但启动晚；token 到一点算一点，重叠更早，但矩阵小，喂不饱 SM。怎么办？
03三个关键设计：Pull、Megakernel、Ring Buffer
MoK 后面的设计，基本都在处理这个「节奏」问题。它没有只用一种技巧，而是把三件事组合到了一起。
① Pull 取代 Push：目标 GPU 自己去读Push → Pull
- 传统 Push：源 GPU 手里有 token，主动写进目标 GPU。麻烦出在目标地址——每个发送方都得提前知道自己写到哪一段、不能互相覆盖，同一专家的 token 最好还要连续排列。
- MoK 的 Pull：保存专家的目标 GPU 自己去读取所需 token。只要知道 token 位于源 GPU 的什么位置，本地存放在哪儿由自己安排，收到的数据可直接按本地专家排好。
- 数据没少传：同一个 256×256 BF16 数据块，Push 在 NVLink 上移动约 159.6 KB，Pull 反而达到 172.0 KB——因为读取要额外发送请求。
- 赢在节奏：NVLink 双向独立通道被同时利用；专家负载不均衡测试中利用率最高 +29%，多节点 signaling 延迟从 103μs → 18μs。
MoK 没有所有地方都用 Pull：前向是 Pull Dispatch + Push Combine；反向是 Pull Reverse-Combine + Push Reverse-Dispatch。Dispatch 需要把多来源 token 重组为专家输入，Pull 更省协调；Combine 时结果该回哪个 token 已很清楚，直接 Push 更简单。
② Megakernel：SM 分区，通信计算商量着来同一内核
- SM 分两组：一组负责 Dispatch、Combine 和状态管理，另一组专门执行 Expert FFN。
- 本地计数器通知：通信侧拿到一批完整 token，通过 GPU 内部计数通知计算侧；计算完成，再通知通信侧把结果传回去。
- 关键参数 minibatch：一次交给专家计算多少 token。太大，第一批计算等很久；太小，专家 GEMM 拆出的任务数不够，很多 SM 闲着。
- 用 wave 判断边界：一个完整 wave 即所有计算 SM 都分到了工作。MoK 希望一个 minibatch 至少形成两个完整 wave——Kimi 2.5 形状下（Hidden 7168、专家中间 2048）至少约 2368 token。512 token 时前向 5.981ms；2560 token 时降到 3.425ms。
通信切得更碎并不会一直变快。真正高效的重叠，需要让通信尽早交出数据，同时不能把 GEMM 切得太小。
③ Ring Token Buffer：不让 CPU 进来打断环形复用
- 问题先摆出来：Router 跑完之前，没人知道每张 GPU 最后会收到多少 token。按最坏情况准备 buffer，浪费显存；先数完再让 CPU 分配，GPU 又得停下来等 CPU。
- 解法：固定大小 Ring Token Buffer。Dispatch 进来的 token 装入环形空间，专家算完、Combine 把结果传走后，空间立即给下一批 token 复用。
- 流水线：前一个 macrobatch 的 Combine 与下一个 macrobatch 的 Dispatch 可以同时进行。
- 顺带优化：MXFP8 activation 量化被塞进 Dispatch、Grouped GEMM、SwiGLU 的数据路径，省掉独立量化 kernel，也少一次中间结果在 HBM 里的来回读写。
Ring Buffer 在这里像一个缓冲层：通信暂时跑快了，数据就在里面积累；计算消耗得快，就等下一批 token 到达。整个过程靠 GPU 上的状态推进，不需要 CPU 每一轮都进来做决定。
04实测：前向最高 2.37 倍，端到端 +41%
Cursor 的基准测的是完整 MoE 层——Schedule、Dispatch、Expert FFN、Combine、最后的加权合并全部在内。对比对象包括 NCCL + PyTorch、DeepEP、TransformerEngine 以及 HybridEP + Megatron。
如何阅读：以 2.37× 为满宽基准，其余倍数按比例缩放。注意这是「相对每种场景最快的公开基线」的提升幅度，并非统一基线下的直接对比。
更关键的是端到端训练。Cursor 此前的生产方案已经用上了 DeepEP——在 512 张 GB300 GPU 上换成 MoK 后：
760.9
tokens/s · DeepEP 基线
→
1070.2
tokens/s · MoK
+41%
如何阅读：单卡吞吐对比。512 张 GB300 GPU，同一生产方案，仅替换 MoE 执行内核。
05诚实的边界：这不是万能内核
这组结果很有说服力，但也要看清边界。Cursor 没有公开完整的逐项消融——无法精确说 2.37 倍里有多少来自 Pull、多少来自 Megakernel、多少来自 Ring Buffer。可以单独确认的是 Pull 对 NVLink 利用率和 signaling 延迟的改善，其余收益来自整套机制组合后的效果。
MoK 对硬件的依赖也很强。它面向 Blackwell 和 NVL72 这样的高速 NVLink Domain——Pull 的远端读取、通信与计算的细粒度交错，都建立在 GPU 之间能够低延迟访问彼此显存的基础上。
模型一变，参数就要重调。Hidden Size、Top-k、专家规模不同，合适的 minibatch 和通信 SM 数量也会跟着变。
换句话说：这不是一个开箱即用的通用内核，而是一套需要调参的精密流水线。
但恰恰是这一点，让 MoK 有了样本意义。
编辑核心判断
一个拥有 130 TB/s NVLink 带宽的机架，最后仍然需要为 MoE 重写 GPU 内核——原因很简单：链路已经很快，接下来要省的是 GPU 等数据的时间。Cursor 把重写内核从「可选优化」变成了「必须掌握的底层能力」。当应用层公司开始定义算子，AI 竞争进入「全栈主权」阶段：决定一家 AI 公司估值的，不再是它拥有多少 token，而是它的代码离显存与寄存器到底有多近。