Guide de sélection du Dispatcher MoE
Docs stables : @docs/training/moe-optimization.md Card : @skills/perf-moe-dispatcher-selection/card.yaml
Décision rapide
Par matériel
| Matériel | Premier choix | Raison |
|---|---|---|
| H100 | DeepEP | Option par défaut solide pour l'EP cross-node sur Hopper |
| B200 | DeepEP | Bon premier choix sauf si un chemin HybridEP spécifique à la plateforme est disponible |
| GB200 / GB300 NVL72 | HybridEP | Meilleur ajustement pour le dispatch aware du domaine NVLink et une pression mémoire réduite |
| Inconnu ou premier démarrage | alltoall |
Chemin le plus simple pour la correction et le débogage |
Par degré EP
| Taille EP | Recommandation |
|---|---|
| Petit EP | Le choix du dispatcher est généralement un facteur secondaire ; commencez par alltoall ou DeepEP |
| EP moyen | DeepEP devient souvent pertinent |
| Grand EP | HybridEP est généralement la meilleure cible sur les systèmes NVL72 |
Modèles de famille de modèles
| Charge de travail | Chemin optimal courant | Notes |
|---|---|---|
| DSV3 à grande échelle | HybridEP sur GB200 ou GB300, DeepEP sur H100 | Le choix du dispatcher compte davantage quand EP et PP se développent |
| Qwen3 235B | DeepEP sur H100, HybridEP sur GB200 | HybridEP gagne généralement sur GB200 et utilise souvent moins de mémoire |
| Qwen3 30B | DeepEP | Les modèles plus petits en bénéficient aussi, mais l'écart absolu est moindre |
| Qwen3-Next | Course serrée en BF16, HybridEP plus fort en FP8 ou lors de runs limités en mémoire | Bonne raison de tester plutôt que d'assumer |
| VLM MoE | Commencez simple, puis testez HybridEP sur les systèmes de classe GB200 | Les charges de travail vision sont sensibles à la fois à la mémoire et aux frais de host |
Résumé des preuves arrondies
DSV3 sur GB200 ou GB300
La tendance générale est plus importante que n'importe quelle ligne du tracker :
- le simple
alltoallest généralement la baseline conservatrice - DeepEP améliore cette baseline une fois que la communication EP devient visible
- HybridEP ajoute une autre étape sur les systèmes NVL72, notamment après les graphes CUDA, les améliorations de routage et le nettoyage côté CPU
En pratique, la stack passe souvent de très approximativement « bas des teens MFU » avec une baseline non optimisée vers « haut des teens à bas des 20s MFU » après le full tuning du dispatcher et de la stack kernel.
Qwen3 235B sur GB200
Pour Qwen3 235B, l'ordre pratique est généralement :
alltoallpour le premier démarrage- DeepEP si vous voulez un chemin tuné familier
- HybridEP pour le meilleur résultat en régime permanent sur GB200
HybridEP est généralement modestement plus rapide que alltoall sur cette charge de travail et a souvent
notablement plus de marge mémoire.
Qwen3-Next sur GB200
Cette famille est un bon rappel que les gains du dispatcher dépendent de la charge de travail :
- en BF16,
alltoallet HybridEP peuvent être proches - en FP8 ou dans les configurations limitées en mémoire, HybridEP tend à sembler mieux
- la disposition du pipeline et les changements grouped-GEMM peuvent compter presque autant que le dispatcher lui-même
Paramètres de tuning
DeepEP
DeepEP est sélectionné en définissant
moe_token_dispatcher_type="flex" et moe_flex_dispatcher_backend="deepep".
--moe-deepep-num-sms 20Ajustez le nombre de SM alloué aux kernels de communication DeepEP (défaut 20). La valeur optimale dépend de la charge de travail et du degré EP.
HybridEP
HybridEP est sélectionné en définissant
moe_token_dispatcher_type="flex" et moe_flex_dispatcher_backend="hybridep".
--moe-hybridep-num-sms 16Ajustez le nombre de SM alloué à la communication HybridEP (défaut 16). Le
harness de performance utilise 32 pour les charges de travail HybridEP. Explorez les valeurs 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 de
le déploiement. S'il ne correspond pas à la topologie réelle, les performances et
parfois la correction en souffriront.
Mode de routage
--moe-router-force-load-balancingPour le benchmarking de performance, le force-balance routing est la default plus sûre. Il surperforme généralement le dropless routing dans les benchmarks à grande échelle et rend les résultats plus comparables entre les backends du dispatcher.
Interactions clés
| Fonctionnalité | Interaction |
|---|---|
| Graphes CUDA | Mieux couplés avec attn moe_router moe_preprocess sur MoE dropless |
| Chevauchement EP | Aide quand le temps du dispatcher est encore visible après le tuning du backend |
| FP8 | Augmente souvent l'importance relative de la communication et des frais de host |
| Affinité CPU | Peut compter autant que le choix du dispatcher sur GB200 ou GB300 |
| Disposition du pipeline | Une mauvaise disposition PP ou VPP peut effacer les gains du dispatcher |
Quand utiliser chacun
alltoall
- premier démarrage de correction
- configurations petit EP
- débogage des régressions de communication
DeepEP
- déploiements Hopper ou B200
- l'EP cross-node est clairement visible dans les profiles
- 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 compte en plus du throughput
Pièges
-
Ne comparez pas les dispatchers sur des stacks différentes : conteneur, mode de routage, disposition PP et portée des graphes CUDA peuvent bouger le résultat autant que le dispatcher.
-
HybridEP est sensible à la topologie : ce n'est pas une victoire universelle en dehors du matériel pour lequel il a été conçu.
-
Les deux dispatchers ont besoin d'un tuning SM : les défauts
moe_deepep_num_sms(20) etmoe_hybridep_num_sms(16) sont des points de départ raisonnables mais rarement optimaux. -
Force-balance et dropless ne sont pas des baselines interchangeables : gardez le mode de routage fixe quand vous comparez les backends du dispatcher.
-
La mémoire et le throughput peuvent se compenser différemment selon le modèle : les runs de style Qwen3 peuvent montrer un delta de vitesse plus petit que DSV3, mais justifier quand même HybridEP pour la marge mémoire.