EP 的 all-to-all 为什么是瓶颈？
NCCL EP、ShortcutMoE、MegaMoE 各做了什么？
先弄清楚：每个概念是什么
- EP 的 all-to-all
- 每个 MoE 层两次。dispatch 把 token 发到 expert 所在的卡，combine 把结果发回来。基础见 MoE 与 Expert Parallel。
- Critical path
- expert FFN 要等 dispatch，下一层要等 combine。通信没完，计算只能等。
- Dispatcher backend
- 实现 dispatch 和 combine 的那层库，现在有 NCCL EP、DeepEP v2、HybridEP 三个。
- Receive buffer
- 每张卡接收 token 的 buffer，收到多少由 router 决定，每步都不一样。
看图：all-to-all 期间 GPU 在干什么
30 秒回答
In expert parallelism every MoE layer runs two all-to-alls: dispatch sends tokens to their experts' GPUs, and combine brings the results back. Both sit on the critical path, so the GPU idles while they run. Megatron attacks this three ways. NCCL EP is a new backend whose static mode keeps a fixed receive budget, so it stays CUDA-graph capturable. ShortcutMoE runs attention on a side stream to overlap the all-to-all. MegaMoE fuses dispatch, expert compute and combine into one kernel. Most of this is experimental, and three backends still coexist.
三个方向各做了什么
| 方向 | 做了什么 | 限制（出处） |
|---|---|---|
| 换 backend NCCL EP | dispatch 和 combine 做进 NCCL，有 eager 和 static 两种 mode | 0.19.0 首次加入；MXFP8 communication 标 experimental（0.20.0） |
| Overlap ShortcutMoE | attention 放到 side stream，和 all-to-all 同时跑 | 训练不支持 CUDA Graph（0.20.0）；要改模型结构 |
| 融合 kernel MegaMoE | dispatch、expert 计算、combine 合成一个 megakernel，少停顿，少 launch（见 kernel fusion） | MoK 实现要求 EP group 在一个 NVLink domain 内，TP1/ETP1，EP ∈ {1, 4, 8, 16, 32, 64}（状态页，10-22） |
0.20.0 新加了 experimental 的 DeepEP v2。Megatron-Bridge 0.7.0 把 GB300 的 MoE perf recipe 默认换成 NCCL EP，同一条写着 HybridEP 的 "deprecation and full migration are deferred"。NeMo-RL 0.8.0 的 MoE perf recipe 则换成了 HybridEP，所以不要说 HybridEP 已被弃用。
NCCL EP 的 eager 和 static
| Mode | 怎么选中 | Receive buffer | CUDA Graph |
|---|---|---|---|
| eager | 不设 moe_expert_rank_capacity_factor | 每步按实际收到的 token 数来定 | PR 没说能 capture |
| static | 设了它 | 固定 budget | 能 capture |
static mode 打开 NCCL EP 的 drop-on-overflow 策略，并在 GPU 上累计超出量和 peak，不溢出就不用 sync。溢出之后把 budget 扩到这个 peak，重建一次 EP context，再重放这一步。release notes 的 eager mode 和 full-iteration graph mode 就是 PR 的 eager 和 static，这是按 PR 描述推断的。
ShortcutMoE 的数字怎么读
普通 MoE 里 dispatch 要等本层 attention 算完。ScMoE 论文让 routed expert 经 shortcut 处理前一层的 representation，dispatch 就不用等。Megatron 的 PR 把 attention 放到 side stream 上和 all-to-all 重叠，一般做法见 overlap。
PR 自报 overlap efficiency 82%–95%，四个模型是 Nano 94%、Super 93%、Ultra 95%、Nemotron 4 candidate 82%。同一张表里 throughput 的 speedup 是 4.7%–12.1%，比图 1 的上限小得多。PR 没有给 overlap efficiency 的定义，也没写硬件。
必答点
- all-to-all 在 critical path 上，一层两次，期间 GPU 空等
- NCCL EP：eager 每步定 receive buffer；static 固定 budget，能被 CUDA Graph capture，溢出就扩 budget 重放
- ShortcutMoE：attention 在 side stream 上和 all-to-all 重叠；82%–95% 是 PR 自报
- MegaMoE：一个 megakernel；MoK 要求 EP group 在一个 NVLink domain 内
- 三个 backend 并存，引用时说版本
追问
MegaMoE 有哪几个实现？
状态页列了两个。MoK（Mixture-of-Kittens）是 Cursor 开源的 CUDA C++ 实现，已集成进 MCore，支持 full-iteration CUDA Graph。NVIDIA 的 CuTeDSL 版经 cuDNN Frontend 和 Transformer Engine 接入，MCore 一侧的 PR 还是 draft。
MegaMoE 快了多少？
状态页的 DeepSeek V4 Pro 表（256×GB300、MXFP8、THD 4K）是 786.86 → 849.81 TFLOPS/GPU，+8.00%。这一行同时去掉了一部分 recompute 和 offload，也改了 CUDA Graph 的范围，不全是 kernel 融合带来的。
NCCL EP、DeepEP v2、HybridEP 怎么选？
没有官方结论。DeepEP v2 的 PR #5153 贴了三者的延迟对比图，但说明结果只供参考。Q4 roadmap 还列着 NCCL EP 对 DeepEP v2 的 benchmark。
来源core 0.20.0 release notes（NCCL EP 两种 mode、ShortcutMoE、DeepEP v2）· core 0.19.0 release notes（NCCL EP 首次加入、Quantile Balancing）· PR #6229（eager 和 static、溢出处理）· PR #6959（overlap efficiency 表）· ScMoE 论文（shortcut 接到哪）· MegaMoE 状态页 #8427 · Megatron-Bridge 0.7.0（HybridEP 的 deprecation 推迟）· NeMo-RL 0.8.0 · PR #5349、PR #5153 · Q4 roadmap #9232 · PyTorch Conference 2026 session 简介（NCCL-EP 把 dispatch 和 combine 做进 NCCL）· ml-八股 06 第零节 · 全部原话见 更新笔记 3.2 节