Maison

Skill

Science des données et ML

nemo-mbridge-perf-moe-vlm-training

NVIDIA/skills

Ce document fournit des conseils pratiques pour l'entraînement de modèles de vision-langage de type « mélange d'experts » dans Megatron Bridge, en comparant les approches FSDP et 3D-parallèles à la lumière des enseignements tirés d'expériences multimodales récentes.

...Développer tout

Heure mise à jour 28 septembre 2026

# gpu # vlm # training # megatron bridge # fsdp # moe # 3d parallel

Formation MoE VLM

Documentation stable : @docs/training/moe-optimization.md Fiche : @skills/nemo-mbridge-perf-moe-vlm-training/card.yaml

FSDP vs 3D parallèle

Approche	Point fort	Cas d’application idéal
FSDP	La méthode la plus simple pour obtenir une exécution multimodale fonctionnelle	première mise en service, optimisation axée sur la mémoire, limites PP complexes
Parallélisme 3D	Potentiel supérieur après optimisation	Modèles stables avec une disposition PP épurée et du temps pour des balayages plus approfondis

Pour les VLM MoE, le workflow pratique est généralement le suivant :

obtenir une première exécution fiable avec FSDP
stabiliser les données réelles d'entrée, recalculer et analyser le comportement en mémoire
passer au parallélisme 3D uniquement si la marge de débit justifie le travail supplémentaire

Conclusions générales tirées des récentes exécutions de VLM

Modèles de la classe Qwen3-VL

Les principales tendances se sont confirmées sur l’ensemble du tracker :

le FSDP sur des systèmes de classe GB200 peut déjà atteindre un taux d’utilisation élevé, dans la fourchette haute des 10 à 20 %, avec une configuration relativement simple
Les exécutions FSDP sur B200 sont viables, mais plus sensibles au choix de recalcul et aux paramètres de vision figés
Le parallélisme 3D permet de retrouver un point de fonctionnement similaire, voire meilleur, mais uniquement après avoir réglé conjointement le MBS, le recalcul et le chemin de vision réel

Données réelles vs données factices

Les exécutions VLM sur des données factices ne constituent pas des indicateurs de performances fiables. Lors des expériences, les exécutions factices sans image semblaient plus proches d’un gain de vitesse « environ deux fois plus rapide » que d’une estimation « légèrement optimiste » par rapport à des entrées multimodales réelles.

Utilisez des charges utiles d’images réelles ou réalistes avant de tirer toute conclusion sur le débit du VLM .

Expériences multimodales MoE à plus petite échelle

Les expériences multimodales à plus petite échelle, de type Qwen3.5, confirment ces mêmes enseignements :

HybridEP est un choix par défaut solide sur GB200
les graphes CUDA à portée TE s’avèrent utiles une fois que la boucle d’entraînement est stable
des MBS plus volumineux peuvent s’avérer rentables, mais uniquement si l’encodeur de vision ne devient pas le prochain goulot d’étranglement

Guide de décision

Optez pour FSDP lorsque

vous lancez un nouveau VLM pour la première fois
le modèle présente des limites de phase complexes entre l’embedding, la vision et le décodeur
l’adaptation à la mémoire prime sur le débit absolu
vous envisagez de geler la pile de traitement visuel pendant un réglage axé sur le décodeur

Optez pour le parallélisme 3D lorsque

le modèle est déjà stable sous FSDP
la configuration PP est claire et reproductible
vous pouvez balayer le MBS, recalculer et analyser le graphe CUDA simultanément
l'objectif est d'obtenir le meilleur débit en régime permanent, et non la mise en service la plus simple

Principaux paramètres de réglage

Gelez la pile de traitement visuel lorsque cela est approprié: si le travail est axé sur le décodeur, le gel du côté visuel apporte souvent un gain de débit modeste mais réel et réduit la pression sur la mémoire.
Effectuez un balayage MBS de manière intensive: les VLM sont plus sensibles au MBS que les exécutions MoE uniquement textuelles, car le chemin de vision modifie l’équilibre entre calcul et surcharge.
Privilégiez le recalcul sélectif une fois le modèle ajusté: le recalcul complet est un outil de mise en route utile, mais le recalcul sélectif offre généralement un meilleur rendement en régime permanent.
Adaptez la portée du graphe CUDA à la charge de travail: `attn moe_router moe_preprocess` est la valeur par défaut MoE la plus sûre, tandis que des portées plus restreintes peuvent néanmoins s’avérer utiles pour des expériences contrôlées.
N’utilisez l’ETP que lorsque l’EP seul est insuffisant: il peut débloquer une configuration, mais il introduit également davantage de communication et une plus grande surface de réglage.

Familles de configurations représentatives

Parcours GB200 axé sur le FSDP

TP=1  CP=1  PP=1
EP dimensionné en fonction de la topologie experte, souvent volumineux
Dispatcher : HybridEP sur les systèmes de classe GB200
Recalcul : commencer par un recalcul complet, puis évoluer vers un recalcul sélectif

Parcours GB200 parallèle en 3D

TP=1  CP=1  PP=1 ou PP modeste
EP et ETP dimensionnés selon la topologie experte
Dispatcher : HybridEP
Graphique CUDA : commencer par une configuration étroite, puis l'élargir uniquement une fois que le chemin des données réelles est stable

Compatibilité

Fonctionnalité	FSDP	Parallélisme 3D
HybridEP sur GB200	forte par défaut	forte par défaut une fois la topologie stabilisée
Graphiques CUDA	utiles après la mise en service	utiles, mais plus sensibles à la portée
Vision figée	s'intègre naturellement	possible, mais moins souvent utilisé comme solution principale pour optimiser les performances
Recalcul sélectif	recommandé	recommandé

Pièges

Les données multimodales simulées sont trompeuses: elles peuvent donner l’impression que le décodeur fonctionne bien mieux que le véritable chemin VLM de bout en bout.
L’encodeur de vision peut s’avérer plus influent que prévu: évaluez séparément l’encodeur de profil, le projecteur et le décodeur avant d’attribuer l’ensemble de la responsabilité au répartiteur.
Ne comparez pas les exécutions FSDP et 3D-parallèles dont le travail effectif diffère: normalisez en fonction des tokens utiles et de la forme de la charge de travail, et pas uniquement en fonction du temps par étape.
L’ETP n’est pas gratuit: utilisez-le comme outil d’ajustement ou de topologie, et non comme paramètre par défaut.
Les choix de recalcul et de graphe CUDA sont liés: le paramétrage qui permet d’ ajuster le modèle n’est souvent pas celui qui offre la meilleure vitesse en régime permanent.

Voir sur GitHub

---
name: nemo-mbridge-perf-moe-vlm-training
description: Provides practical guidance for training Mixture-of-Experts Vision-Language Models in Megatron Bridge, comparing FSDP and 3D-parallel approaches with lessons from recent multimodal experiments.
license: Apache-2.0
---

# MoE VLM Training

Stable docs: @docs/training/moe-optimization.md
Card: @skills/nemo-mbridge-perf-moe-vlm-training/card.yaml

## FSDP vs 3D Parallel

| Approach | Strength | Best fit |
|---|---|---|
| FSDP | Simplest path to a working multimodal run | first bring-up, memory-first tuning, awkward PP boundaries |
| 3D parallel | Higher ceiling after tuning | stable models with a clean PP layout and time for deeper sweeps |

For MoE VLMs, the practical workflow is usually:

1. get the first reliable run with FSDP
2. stabilize real-data input, recompute, and memory behavior
3. move to 3D parallel only if the throughput headroom is worth the extra work

## Rounded Findings From Recent VLM Runs

### Qwen3-VL class models

The main patterns were consistent across the tracker:

- FSDP on GB200-class systems can already reach healthy high-teens utilization
  with a comparatively simple setup
- B200 FSDP runs are viable, but more sensitive to recompute choice and frozen
  vision settings
- 3D parallel can recover to a similar or better operating point, but only after
  tuning MBS, recompute, and the real vision path together

### Real data vs mock data

Mock-data VLM runs are not trustworthy performance proxies. In the experiments,
image-free mock runs looked closer to "roughly twice as fast" than "slightly
optimistic" when compared with real multimodal input.

Use real or realistic image payloads before drawing any conclusion about VLM
throughput.

### Smaller multimodal MoE runs

The smaller Qwen3.5-style multimodal experiments reinforce the same lessons:

- HybridEP is a solid default on GB200
- TE-scoped CUDA graphs help once the training loop is stable
- larger MBS can pay off, but only if the vision encoder does not become the
  next bottleneck

## Decision Guide

### Choose FSDP when

- you are bringing up a new VLM for the first time
- the model has awkward stage boundaries across embedding, vision, and decoder
- memory fit matters more than absolute throughput
- you may freeze the vision stack during decoder-focused tuning

### Choose 3D parallel when

- the model is already stable under FSDP
- the PP layout is clear and repeatable
- you can sweep MBS, recompute, and CUDA-graph scope together
- the goal is best steady-state throughput, not easiest bring-up

## Key Tuning Knobs

1. **Freeze the vision stack when appropriate**: if the work is decoder-focused,
   freezing the vision side often gives a small but real throughput gain and
   reduces memory pressure.

2. **Sweep MBS aggressively**: VLMs are more MBS-sensitive than text-only MoE
   runs because the vision path changes the compute-to-overhead balance.

3. **Prefer selective recompute once the model fits**: full recompute is a
   useful bring-up tool, but selective recompute is usually the better steady
   state.

4. **Match CUDA-graph scope to the workload**: `attn moe_router moe_preprocess`
   is the safer MoE default, while narrower scopes can still be useful for
   controlled experiments.

5. **Use ETP only when EP alone is insufficient**: it can unlock a layout, but
   it also introduces more communication and more tuning surface.

## Representative Config Families

### FSDP-first GB200 path

```text
TP=1  CP=1  PP=1
EP sized to the expert topology, often large
Dispatcher: HybridEP on GB200-class systems
Recompute: start with full, then relax toward selective recompute
```

### 3D-parallel GB200 path

```text
TP=1  CP=1  PP=1 or modest PP
EP and ETP sized to the expert topology
Dispatcher: HybridEP
CUDA Graph: start narrow, then widen only after the real-data path is stable
```

## Compatibility

| Feature | FSDP | 3D parallel |
|---|---|---|
| HybridEP on GB200 | strong default | strong default once topology is stable |
| CUDA graphs | useful after bring-up | useful, but more scope-sensitive |
| Freeze vision | natural fit | possible, but less often used as the headline perf path |
| Selective recompute | recommended | recommended |

## Pitfalls

1. **Mock multimodal data is misleading**: it can make the decoder look much
   healthier than the real end-to-end VLM path.

2. **The vision encoder can dominate unexpectedly**: profile encoder, projector,
   and decoder separately before attributing everything to the dispatcher.

3. **Do not compare FSDP and 3D-parallel runs with different effective work**:
   normalize by useful tokens and workload shape, not only by step time.

4. **ETP is not free**: use it as a fit or topology tool, not as the default.

5. **Recompute and CUDA-graph choices are coupled**: the setting that gets the
   model to fit is often not the setting that gives the best steady-state speed.