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	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 グラフスコープ（moe_router、 moe_preprocess）を使用しました。また、実行コンテナで Triton JIT の互換性に問題があったため、model.moe_permute_fusion=false を設定しました。alltoall フォールバックはウォームアップ後に 5 ステップを完了し、平均ステップ時間は 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 グラフ、ルーティングの改善、CPU 側のクリーンアップがすでに整っている場合に効果的です

実際には、スタック全体のディスパッチャーとカーネルをチューニングすると、未調整のベースラインでの「MFU が低い 10％台」程度から、「MFU が高い 10％台から 20％台前半」程度へと改善することがよくあります。

GB200 での Qwen3 235B

Qwen3 235B では、実用上の順序は通常次のとおりです。

1. 初回の起動には alltoall
2. 実績のある調整済みの経路を使いたい場合は DeepEP
3. 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

パフォーマンスベンチマークでは、強制バランスルーティングがより安全なデフォルトです。大規模なベンチマークでは通常 dropless ルーティングよりも優れた性能を示し、ディスパッチャーバックエンド間で結果を比較しやすくなります。

主な相互作用

機能	相互作用
CUDA グラフ	dropless 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. 強制バランスと dropless は互換性のあるベースラインではありません: ディスパッチャーバックエンドを比較する際はルーティングモードを固定してください。

5. メモリとスループットはモデルによって異なるトレードオフを示すことがあります: Qwen3 スタイルの実行では DSV3 よりも速度差が小さく見えるかもしれませんが、それでもメモリの余裕のために HybridEP を正当化できます。

6. バックエンドのインポート失敗はパフォーマンスデータではありません: DeepEP または HybridEP がコンテナに存在しない場合、その失敗したジョブを完了した alltoall ジョブと比較しないでください。まず環境を修正し、その後同じスタックで再実行してください。