Guide de sélection du dispatcher MoE

Docs stables : @docs/training/moe-optimization.md Card : @skills/nemo-mbridge-perf-moe-dispatcher-selection/card.yaml

Décision rapide

Par matériel

Par degré EP

Motifs par famille de modèles

Résumé des preuves arrondies

Porte de disponibilité du backend

N'interprétez pas le timing d'un dispatcher tant que le conteneur n'a pas prouvé que le package backend sélectionné est disponible. --moe_flex_dispatcher_backend None sélectionne le dispatcher alltoall standard, tandis que deepep et hybridep sélectionnent moe_token_dispatcher_type="flex" et nécessitent ensuite leurs packages runtime correspondants au moment de la construction du modèle. Si DeepEP ou HybridEP manque, enregistrez l'échec d'import comme une limitation d'environnement et traitez alltoall comme le seul fallback de correction mesuré pour cette exécution.

Qwen3 30B A3B sur H100

Une courte exécution smoke H100 du 2026-05-17 a utilisé Qwen3 30B A3B BF16, 16 GPU, EP=16, les portées CUDA graph de Transformer Engine de la recette (moe_router, moe_preprocess), et model.moe_permute_fusion=false en raison d'un problème de compatibilité Triton JIT dans le conteneur d'exécution. Les dispatchers alltoall fallback ont complété cinq étapes avec un temps de step moyen de 45,65 s après warmup, 132,9 TFLOP/s/GPU moyen après warmup, perte finale 11,44050, et 61,351 GB de mémoire allouée maximale de pic. DeepEP et HybridEP ont sélectionné le backend flex demandé dans les configs dumpées mais ont échoué avant la première itération parce que les packages n'étaient pas installés. Ceci confirme la porte de disponibilité ; ce n'est pas un classement de débit pour les dispatchers flex sur H100.

DSV3 sur GB200 ou GB300

La tendance générale est plus importante que n'importe quelle ligne unique du tracker :

• l'alltoall simple est généralement la ligne de base conservative
• DeepEP améliore cette ligne de base une fois que la communication EP devient visible
• HybridEP ajoute une autre étape sur les systèmes NVL72, en particulier après que les graphes CUDA, les améliorations de routage et le nettoyage côté CPU soient déjà en place

En pratique, la pile passe souvent de plus ou moins le territoire « MFU en bas de teens » avec une ligne de base désaccordée au territoire « MFU de high-teens à low-20s » après que l'ensemble du dispatcher et de la pile de kernel soient accordés.

Qwen3 235B sur GB200

Pour Qwen3 235B, l'ordre pratique est généralement :

1. alltoall pour le démarrage initial
2. DeepEP si vous voulez un chemin accordé familier
3. HybridEP pour le résultat steady-state le plus fort sur GB200

HybridEP est généralement modestement plus rapide que alltoall sur cette charge de travail et a souvent une marge mémoire notablement meilleure.

Qwen3-Next sur GB200

Cette famille est un bon rappel que les gains du dispatcher dépendent de la charge de travail :

• en BF16, alltoall et HybridEP peuvent être proches
• en FP8 ou dans des paramètres contraints en mémoire, HybridEP tend à être meilleur
• la disposition du pipeline et les changements de grouped-GEMM peuvent importer presque autant que le dispatcher lui-même

Paramètres d'accordage

DeepEP

DeepEP est sélectionné en définissant moe_token_dispatcher_type="flex" et moe_flex_dispatcher_backend="deepep".

--moe-deepep-num-sms 20

Accordez le nombre de SM alloués aux kernels de communication DeepEP (par défaut 20). La valeur optimale dépend de la charge de travail et du degré EP. Confirmez d'abord que le package DeepEP s'importe dans le conteneur cible ; un package manquant échoue lors de la construction du modèle, avant tout timing de dispatcher.

HybridEP

HybridEP est sélectionné en définissant moe_token_dispatcher_type="flex" et moe_flex_dispatcher_backend="hybridep".

--moe-hybridep-num-sms 16

Accordez le nombre de SM alloués à la communication HybridEP (par défaut 16). Le harnais de performance utilise 32 pour les charges de travail HybridEP. Balayez entre 16 et 32 pour le matériel cible. Définissez NUM_OF_HYBRID_EP_RANKS_PER_NVLINK_DOMAIN pour correspondre à la taille du domaine NVLink du déploiement. S'il ne correspond pas à la topologie réelle, les performances et parfois la correction en souffriront. Confirmez d'abord que le package HybridEP s'importe dans le conteneur cible ; un package manquant échoue lors de la construction du modèle, avant tout timing de dispatcher.

Mode routage

--moe-router-force-load-balancing

Pour les benchmarks de performance, le routage force-balance est le défaut le plus sûr. Il surpasse généralement le routage dropless dans les benchmarks à grande échelle et rend les résultats plus comparables entre les backends de dispatcher.

Interactions clés

Quand utiliser chacun

alltoall

• premier démarrage de correction
• petites configurations EP
• débogage des régressions de communication

DeepEP

• déploiements Hopper ou B200
• l'EP cross-node est clairement visible dans les profils
• vous voulez une étape intermédiaire mature avant de tester HybridEP

HybridEP

• systèmes GB200 ou GB300 NVL72
• grands degrés EP
• la marge mémoire importe en plus du débit

Pièges

1. Ne comparez pas les dispatchers sur des piles différentes : le conteneur, le mode routage, la disposition PP et la portée du graphe CUDA peuvent déplacer le résultat autant que le dispatcher.

2. HybridEP est sensible à la topologie : ce n'est pas une victoire universelle en dehors du matériel pour lequel il a été conçu.

3. Les deux dispatchers ont besoin d'accordage SM : les valeurs par défaut moe_deepep_num_sms (20) et moe_hybridep_num_sms (16) sont des points de départ raisonnables mais rarement optimaux.

4. Force-balance et dropless ne sont pas des lignes de base interchangeables : gardez le mode routage fixe lors de la comparaison des backends de dispatcher.

5. La mémoire et le débit peuvent faire des compromis différemment par modèle : les exécutions de style Qwen3 peuvent montrer un delta de vitesse plus petit que DSV3, mais justifient toujours HybridEP pour la marge mémoire.

6. Les échecs d'import du backend ne sont pas des données de performance : si DeepEP ou HybridEP manque du conteneur, ne comparez pas son travail échoué à un travail alltoall complété. Corrigez d'abord l'environnement, puis relancez la même pile.