| 名称 | nemo-mbridge-perf-moe-dispatcher-selection |
| 描述 | 为硬件、EP 度和优化阶段选择合适的 MoE 令牌分发器（alltoall、DeepEP 或 HybridEP）。总结了 DSV3、Qwen3、Qwen3-Next 和 VLM 项目中的经验模式。 |
| 开源协议 | Apache-2.0 when_to_use: 选择 MoE 令牌分发器，或将 MoE 回归或崩溃追溯到分发器配置变更；关键词包括’which dispatcher’, ‘alltoall vs DeepEP’, ‘HybridEP’, ‘MoE dispatcher’, ‘flex backend’, ‘EP dispatcher selection’。 |
MoE 分发器选择指南
稳定文档：@docs/training/moe-optimization.md 卡片：@skills/nemo-mbridge-perf-moe-dispatcher-selection/card.yaml
快速决策
按硬件选择
| 硬件 | 首选 | 原因 |
|---|---|---|
| H100 | DeepEP（如果已安装运行时包） | 在 Hopper 上进行跨节点 EP 的强默认选择 |
| B200 | DeepEP（如果已安装运行时包） | 除非有平台特定的 HybridEP 路径可用，否则是不错的首选 |
| GB200 / GB300 NVL72 | HybridEP（如果已安装运行时包） | 最适合 NVLink 域感知分发，且内存压力更低 |
| 未知或首次搭建 | alltoall |
最容易实现正确性和调试 |
按 EP 度（EP 规模）选择
| EP 规模 | 指导建议 |
|---|---|
| 小 EP | 分发器选择通常是次要因素；从 alltoall 或 DeepEP 开始 |
| 中 EP | DeepEP 通常变得有价值 |
| 大 EP | HybridEP 通常是 NVL72 系统上的最佳目标 |
模型系列模式
| 工作负载 | 常见最佳路径 | 备注 |
|---|---|---|
| 大规模 DSV3 | GB200/GB300 上使用 HybridEP，H100 上使用 DeepEP | 随着 EP 和 PP 都增加，分发器选择变得更加重要 |
| Qwen3 235B | H100 上使用 DeepEP，GB200 上使用 HybridEP | 在 GB200 上 HybridEP 通常胜出，且内存占用通常更少 |
| Qwen3 30B | DeepEP | 较小的模型仍然受益，但绝对差距较小 |
| Qwen3-Next | BF16 下竞争激烈，FP8 或内存紧张场景下 HybridEP 更强 | 提醒我们要实际测试而非臆断 |
| MoE 视觉语言模型（VLM） | 从简单开始，然后在 GB200 级系统上测试 HybridEP | 视觉工作负载对内存和主机开销都很敏感 |
全面的实证摘要
后端可用性检查
在容器环境确认所选后端包可用之前，不要解读任何分发器计时数据。--moe_flex_dispatcher_backend None 选择标准的 alltoall 分发器，而 deepep 和 hybridep 则选择 moe_token_dispatcher_type="flex"，并在模型构建时要求安装相应的运行时包。如果缺少 DeepEP 或 HybridEP，请将导入失败记录为环境限制，并将 alltoall 作为该次运行中唯一经过正确性验证的备选方案。
H100 上的 Qwen3 30B A3B
2026-05-17 在 H100 上进行了一次短暂的冒烟测试，使用 Qwen3 30B A3B BF16、16 张 GPU、EP=16、配置中的 Transformer Engine CUDA graph 作用域（moe_router、moe_preprocess），并因运行容器中的 Triton JIT 兼容性问题而设置了 model.moe_permute_fusion=false。alltoall 备选方案完成了五个步骤，预热后平均每步时间为 45.65 秒，预热后平均每 GPU 达 132.9 TFLOP/s，最终损失为 11.44050，峰值最大分配内存为 61.351 GB。DeepEP 和 HybridEP 在导出的配置中选择了所请求的 flex 后端，但因为未安装相应包而在第一次迭代前失败。这证实了可用性门控；它并不是 H100 上 flex 分发器的吞吐量排名。
GB200 或 GB300 上的 DSV3
总体趋势比跟踪表中的任何单一行都更重要：
- 普通的
alltoall通常是保守的基线 - 一旦 EP 通信变得显著，DeepEP 就能改进该基线
- 在 NVL72 系统上，HybridEP 还能进一步提升，尤其是在 CUDA graphs、路由优化和 CPU 端清理已经就绪之后
在实践中，经过完整的分发器和内核栈调优后，计算栈通常从“十几低位 MFU”的未调优基线，进入“十几高位到二十出头 MFU”的水平。
GB200 上的 Qwen3 235B
对于 Qwen3 235B，实际的顺序通常是：
- 使用
alltoall进行初始搭建 - 如果你想要一条熟悉的调优路径，使用 DeepEP
- 在 GB200 上使用 HybridEP 以获得最强的稳态结果
在此工作负载上，HybridEP 通常比 alltoall 略有优势，并且往往拥有更好的内存余量。
GB200 上的 Qwen3-Next
该模型系列很好地提醒我们，分发器的优势是与工作负载相关的：
- 在 BF16 下，
alltoall和 HybridEP 可能非常接近 - 在 FP8 或内存受限的设置下，HybridEP 往往表现更好
- 流水线布局和分组 GEMM 的变化可能与分发器本身几乎同等重要
调优参数
DeepEP
DeepEP 通过设置 moe_token_dispatcher_type="flex" 和 moe_flex_dispatcher_backend="deepep" 来选择。
--moe-deepep-num-sms 20
调整分配给 DeepEP 通信内核的 SM 数量（默认 20）。最佳值取决于工作负载和 EP 度。首先确认目标容器中能够导入 DeepEP 包；如果缺少该包，会在模型构建期间失败，此时任何分发器计时数据都还不可用。
HybridEP
HybridEP 通过设置 moe_token_dispatcher_type="flex" 和 moe_flex_dispatcher_backend="hybridep" 来选择。
--moe-hybridep-num-sms 16
调整分配给 HybridEP 通信的 SM 数量（默认 16）。性能测试工具对 HybridEP 工作负载使用 32。针对目标硬件在 16 到 32 之间扫描。设置 NUM_OF_HYBRID_EP_RANKS_PER_NVLINK_DOMAIN 以匹配部署的 NVLink 域大小。如果与实际拓扑不匹配，性能会下降，有时甚至会出现正确性问题。
首先确认目标容器中能够导入 HybridEP 包；如果缺少该包，会在模型构建期间失败，此时任何分发器计时数据都还不可用。
路由模式
--moe-router-force-load-balancing
对于性能基准测试，强制均衡路由是更安全的默认选项。在大规模基准测试中，它通常优于“无丢失”路由，并且使结果在不同分发器后端之间更具可比性。
关键交互
| 特性 | 交互影响 |
|---|---|
| CUDA graphs | 在无丢失 MoE 上与 attn moe_router moe_preprocess 配合最佳 |
| EP 重叠 | 在后端调优后仍有分发器时间可见时有帮助 |
| FP8 | 通常会提高通信和主机开销的相对重要性 |
| CPU 亲和性 | 在 GB200 或 GB300 上可能与分发器选择同样重要 |
| 流水线布局 | 糟糕的 PP 或 VPP 布局会抵消分发器带来的收益 |
各自的使用时机
alltoall
- 首次进行正确性搭建
- 小规模 EP 配置
- 调试通信性能回退问题
DeepEP
- Hopper 或 B200 部署
- profile 中跨节点 EP 清晰可见
- 在测试 HybridEP 之前想要一个成熟的中间步骤
HybridEP
- GB200 或 GB300 NVL72 系统
- 大 EP 度
- 除了吞吐量之外，内存余量也很重要
常见陷阱
-
不要在不同技术栈上比较分发器：容器、路由模式、PP 布局和 CUDA-graph 作用域对结果的影响可能与分发器本身一样大。
-
HybridEP 对拓扑敏感：在它设计的硬件之外，它并不是普遍优势。
-
两种分发器都需要 SM 调优：默认的
moe_deepep_num_sms(20) 和moe_hybridep_num_sms(16) 是合理的起点，但很少是最优值。 -
强制均衡和无丢失路由不是可互换的基线：在比较分发器后端时，保持路由模式固定。
-
内存和吞吐量在不同模型上的权衡不同：Qwen3 类运行可能比 DSV3 显示出更小的速度差异，但仍可能因内存余量而选择 HybridEP。
-
后端导入失败不是性能数据：如果容器中缺少 DeepEP 或 HybridEP，不要将它的失败任务与已完成的
alltoall任务进行比较。先修复环境，然后重跑相同技术栈。