Référence de configuration du matériel MoE

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

Playbook rapide par plateforme

Plateforme	Stratégie MoE typique	Ce qui compte généralement le plus
H100	DeepEP + PP plus fort + TP modéré	chevauchement de communication et efficacité PP
B200	DeepEP + MXFP8 + disposition PP soignée	qualité du conteneur et paramètres de comm ajustés
GB200	HybridEP + graphes CUDA partiels + nettoyage CPU	surcharge hôte, dispatch aware de la topologie, espace mémoire
GB300	HybridEP + FP8 et pile kernel plus récents	même playbook GB200, généralement avec un plafond supérieur

Bandes de performance arrondies

Ces chiffres sont intentionnellement arrondis pour que le document reste durable au fil du temps. Traitez-les comme des plages de planification, non comme des promesses exactes.

Famille de charge	Matériel	Plage typique	Shape représentative
DSV3, grande échelle	H100	centaines basses à moyennes TFLOPS/GPU, MFU dans les dix-sept à dix-neuf	TP2, EP64, PP8, DeepEP
DSV3, grande échelle	B200	centaines hautes TFLOPS/GPU, MFU dans les quinze-dix-neuf	TP1, EP32, PP8, DeepEP
DSV3, grande échelle	GB200	environ 1K TFLOPS/GPU, MFU basse-20	TP1, EP64, PP4, HybridEP
DSV3, grande échelle	GB300	au-dessus de la plage GB200, souvent MFU moyenne-20	TP1, EP64, PP4, HybridEP
Qwen3 235B	H100	centaines basses TFLOPS/GPU, environ 30% MFU	TP2, EP32, PP8, DeepEP
Qwen3 235B	GB200	centaines hautes TFLOPS/GPU dans les runs ajustées	TP1 ou TP2, EP32-64, PP4, HybridEP
Qwen3 30B	H100	centaines basses TFLOPS/GPU	TP1, EP8, PP1, DeepEP
Qwen3-Next 80B	GB200	centaines basses TFLOPS/GPU dans les runs classe BF16	TP1, EP32, PP2, HybridEP

Familles de config représentatives

DSV3 sur H100

Dispatcher: DeepEP
TP=2  EP=64  PP=8  VPP=4
Routing: force balance
Recompute: selective recompute léger à modéré
Priority: chevauchement de communication et maintenir l'efficacité PP

DSV3 sur B200

Dispatcher: DeepEP
TP=1  EP=32  PP=8  VPP=2 ou similaire
Precision: classe MXFP8
Recompute: selective recompute autour de la projection MLA et des modules côté MLP
Priority: qualité du conteneur, disposition PP et tuning SMS DeepEP

DSV3 sur GB200 ou GB300

Dispatcher: HybridEP
TP=1  EP=64  PP=4  VPP=4
Precision: classe MXFP8
CUDA Graph: attn + moe_router + moe_preprocess
Priority: HybridEP, optimisation CPU et shapes statiques amies des graphes

Qwen3 235B sur H100

Dispatcher: DeepEP
TP=2  EP=32  PP=8  VPP=4
Recompute: selective recompute norm et activation-side
Priority: chevauchement de communication et nettoyage du chemin router

Qwen3 235B sur GB200

Dispatcher: HybridEP
TP=1 ou 2  EP=32 à 64  PP=4
CUDA Graph: attn + moe_router + moe_preprocess
Recompute: moe_act, mlp, ou norm selon la pression mémoire
Priority: équilibre débit vs espace mémoire

Qwen3-Next 80B sur GB200

Dispatcher: HybridEP
TP=1  EP=32  PP=2  VPP environ 4
CUDA Graph: attn + moe_router + moe_preprocess
Priority: disposition pipeline et qualité grouped GEMM

Patterns transversaux

Disposition PP

E = embedding
t = transformer
m = MTP
L = loss
| = limite de stage

La plus grande différence entre plateformes n'est habituellement pas seulement le dispatcher. C'est la combinaison du dispatcher, de la shape PP et du maintien de l'équilibre VPP à chaque stage.

Stratégie de recompute

Pression mémoire	Point de départ
basse	aucun ou un ensemble sélectif très étroit
modérée	`moe_act`, `mlp`, `norm` ou modules sélectifs similaires
haute	up-projection spécifique au modèle plus modules MoE et MLP sélectifs
extrême ou contexte long	recompute complet seulement si le chemin sélectif ne passe toujours pas

Variables d'environnement

CUDA_DEVICE_MAX_CONNECTIONS=1
CUDA_DEVICE_MAX_CONNECTIONS=32   # courant quand overlap EP et graphes CUDA sont combinés
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
NCCL_GRAPH_REGISTER=0

Tuning côté CPU

Sur GB200 et GB300, l'affinité CPU et le nettoyage général de la surcharge hôte peuvent faire bouger l'aiguille presque autant qu'un changement de dispatcher. Traitez-les comme du travail de tuning de première classe, non comme des arrière-pensées.

Pièges

Ne copiez pas une ligne du tracker en aveugle : la config gagnante dépend généralement du mode de routing, du conteneur et de la disposition PP autant que du nom du matériel.
La qualité du conteneur compte : des régressions importantes peuvent venir de la pile logicielle plutôt que de la recette du modèle.
VPP doit être intentionnel : un mauvais split VPP peut effacer le gain d'un meilleur dispatcher.
Comparez le débit absolu, pas seulement le MFU : le MFU peut induire en erreur quand on bascule entre BF16, FP8 et d'autres modes de précision.
Le routing force-balance est le défaut de benchmark plus sûr : gardez le mode de routing fixe quand vous comparez le matériel ou les piles de dispatcher.