nemo-mbridge-perf-moe-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	分发器选择通常不是首要因素；从 alltoall 或 DeepEP 开始
中等规模 EP	DeepEP 往往开始显现优势
大规模 EP	在 NVL72 系统上，HybridEP 通常是最佳目标

模型系列模式

工作负载	常见最佳路径	备注
大规模 DSV3	GB200 或 GB300 上使用 HybridEP，H100 上使用 DeepEP	EP 和 PP 都增大时，分发器选择的影响也会增大
Qwen3 235B	H100 上使用 DeepEP，GB200 上使用 HybridEP	HybridEP 在 GB200 上通常更快，且往往占用更少内存
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 s，预热后的平均吞吐为 132.9 TFLOP/s/GPU，最终损失为 11.44050，峰值最大已分配内存为 61.351 GB。DeepEP 和 HybridEP 在导出的配置中 选择了请求的 flex 后端，但由于未安装对应的软件包，在首次迭代前就失败了。这 验证了可用性门槛；它并非 H100 上 flex 分发器的吞吐量排名。

GB200 或 GB300 上的 DSV3

整体趋势比追踪表中的任何单行结果都更重要：

• 普通 alltoall 通常是保守的基线
• 当 EP 通信变得明显时，DeepEP 会提升基线表现
• 在 NVL72 系统上，HybridEP 会进一步提升表现，尤其是在 CUDA graphs、路由优化和 CPU 侧清理已完成之后

实践中，经过完整的分发器和内核栈调优后，整个技术栈的 MFU 通常会从未调优基线的 “十几个百分点”提升到“十几至二十出头”。

GB200 上的 Qwen3 235B

对于 Qwen3 235B，实际中通常按以下顺序选择：

1. 初次启动时使用 alltoall
2. 如果希望使用熟悉且经过调优的路径，则使用 DeepEP
3. 要在 GB200 上获得最强的稳定态结果，则使用 HybridEP

在此工作负载下，HybridEP 通常比 alltoall 略快，并且往往有明显更充足的内存余量。

GB200 上的 Qwen3-Next

这一系列模型很好地提醒我们，调度器的优势取决于工作负载：

• 在 BF16 下，alltoall 和 HybridEP 的表现可能很接近
• 在 FP8 或内存受限的场景下，HybridEP 往往表现更好
• 流水线布局和分组 GEMM 的改动，其影响可能几乎不亚于调度器本身

调优参数

DeepEP

设置 moe_token_dispatcher_type="flex" 和 moe_flex_dispatcher_backend="deepep" 即可选择 DeepEP。

--moe-deepep-num-sms 20

调整分配给 DeepEP 通信内核的 SM 数量（默认值为 20）。 最佳值取决于工作负载和 EP 度数。 首先确认 DeepEP 软件包可以在目标容器中导入；如果缺少该软件包，模型构建阶段就会失败，无法获取任何调度器计时数据。

HybridEP

设置 moe_token_dispatcher_type="flex" 和 moe_flex_dispatcher_backend="hybridep" 即可选择 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 图	在采用无丢弃 MoE 时，最适合与 attn moe_router moe_preprocess 搭配使用
EP 重叠	后端调优后，如果调度器耗时仍然明显，则有帮助
FP8	往往会提升通信和主机开销的相对重要性
CPU 亲和性	在 GB200 或 GB300 上，其影响可能不亚于调度器选择
流水线布局	不佳的 PP 或 VPP 布局可能抵消调度器带来的收益

何时使用各方案

alltoall

• 初次验证正确性
• 小规模 EP 配置
• 调试通信性能回退

DeepEP

• Hopper 或 B200 部署
• 在性能分析中可以明显看到跨节点 EP
• 希望先使用成熟的中间方案，再测试 HybridEP

HybridEP

• GB200 或 GB300 NVL72 系统
• 较大的 EP 度数
• 除吞吐量外，内存余量也很重要

注意事项

1. 不要在不同的软件栈上比较调度器：容器、路由模式、PP 布局和 CUDA 图范围带来的影响，可能与调度器本身不相上下。

2. HybridEP 对拓扑敏感：在其设计目标硬件之外，它并非普遍适用的优选方案。

3. 两个调度器都需要调优 SM 数量：默认的 moe_deepep_num_sms（20）和 moe_hybridep_num_sms（16）是合理的起点，但很少是最优值。

4. 强制均衡与无丢弃并非可互换的基准设置：比较调度器后端时，应固定路由模式。

5. 不同模型的内存与吞吐量权衡可能不同：Qwen3 风格的运行可能不像 DSV3 那样有明显的速度提升，但 HybridEP 仍可能因增加内存余量而值得采用。

6. 后端导入失败不代表性能数据：如果容器中缺少 DeepEP 或 HybridEP，不要将其失败的作业与已完成的 alltoall 作业进行比较。先修复环境，再使用相同的软件栈重新运行。