Hogar

Skill

Ciencia de datos y aprendizaje automático

nemo-mbridge-perf-moe-vlm-training

NVIDIA/skills

Ofrece orientación práctica para el entrenamiento de modelos de visión y lenguaje basados en una mezcla de expertos en Megatron Bridge, comparando los enfoques FSDP y 3D-paralelo con las conclusiones extraídas de experimentos multimodales recientes.

...Expandir todo

Tiempo actualizado 28 de septiembre de 2026

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

Formación sobre VLM de MoE

Documentación estable: @docs/training/moe-optimization.md Ficha: @skills/nemo-mbridge-perf-moe-vlm-training/card.yaml

FSDP frente a paralelo 3D

Enfoque	Ventajas	Apto para
FSDP	La forma más sencilla de conseguir una ejecución multimodal que funcione	primera puesta en marcha, ajuste «memory-first», límites de PP complicados
Paralelismo 3D	Mayor potencial tras el ajuste	Modelos estables con una disposición de PP clara y tiempo para barridos más exhaustivos

Para los VLM de MoE, el flujo de trabajo habitual suele ser:

obtener la primera ejecución fiable con FSDP
estabilizar la entrada de datos reales, volver a calcular y analizar el comportamiento de la memoria
pasar al paralelo 3D solo si el margen de rendimiento compensa el trabajo adicional

Conclusiones generales de ejecuciones recientes de VLM

Modelos de la clase Qwen3-VL

Los patrones principales fueron consistentes en todo el rastreador:

El FSDP en sistemas de la clase GB200 ya puede alcanzar una buena tasa de utilización, en la franja alta de los 10-19 % con una configuración relativamente sencilla
Las ejecuciones de FSDP en B200 son viables, pero más sensibles a la elección del recálculo y a la configuración fija de visión
El paralelismo 3D puede recuperar un punto de funcionamiento similar o mejor, pero solo tras ajustar conjuntamente el MBS, el recálculo y la ruta de visión real

Datos reales frente a datos simulados

Las ejecuciones de VLM con datos simulados no son indicadores fiables del rendimiento. En los experimentos, las ejecuciones simuladas sin imágenes parecían más cercanas a «aproximadamente el doble de rápidas» que a «ligeramente optimistas» en comparación con la entrada multimodal real.

Utiliza cargas útiles de imágenes reales o realistas antes de sacar cualquier conclusión sobre el rendimiento del VLM.

Ejecuciones MoE multimodales a menor escala

Los experimentos multimodales más reducidos, al estilo de Qwen3.5, refuerzan las mismas conclusiones:

HybridEP es una opción predeterminada sólida en GB200
los gráficos CUDA con ámbito TE ayudan una vez que el bucle de entrenamiento se estabiliza
Un MBS más grande puede dar sus frutos, pero solo si el codificador de visión no se convierte en el siguiente cuello de botella

Guía de decisión

Elige FSDP cuando

vayas a poner en marcha un nuevo VLM por primera vez
el modelo tenga límites de etapa complicados entre la incrustación, la visión y el decodificador
el ajuste de la memoria sea más importante que el rendimiento absoluto
pueda congelar la pila de visión durante el ajuste centrado en el decodificador

Elige el paralelismo 3D cuando

el modelo ya sea estable bajo FSDP
la disposición del PP sea clara y repetible
se pueda realizar un barrido de MBS, volver a calcular y analizar el gráfico de CUDA al mismo tiempo
el objetivo sea el máximo rendimiento en estado estacionario, no la puesta en marcha más sencilla

Parámetros clave de ajuste

Congela la pila de visión cuando sea oportuno: si el trabajo se centra en el decodificador, congelar la parte de visión suele proporcionar una ganancia de rendimiento pequeña pero real y reduce la presión sobre la memoria.
Realiza barridos de MBS de forma agresiva: los VLM son más sensibles al MBS que las ejecuciones de MoE solo con texto, ya que la ruta de visión altera el equilibrio entre computación y sobrecarga.
Da prioridad al recálculo selectivo una vez que el modelo se adapta: el recálculo completo es una herramienta útil para la puesta en marcha, pero el recálculo selectivo suele ofrecer un mejor rendimiento en estado estable.
Adapta el alcance del gráfico CUDA a la carga de trabajo: «attn moe_router moe_preprocess» es la configuración predeterminada más segura de MoE, aunque los alcances más limitados pueden seguir siendo útiles para experimentos controlados.
Utiliza ETP solo cuando EP por sí solo resulte insuficiente: puede desbloquear un diseño, pero también introduce más comunicación y más superficie de ajuste.

Familias de configuraciones representativas

Ruta «FSDP-first» en GB200

TP=1  CP=1  PP=1
EP dimensionado según la topología experta, a menudo grande
Distribuidor: HybridEP en sistemas de clase GB200
Recálculo: comenzar con recálculo completo y luego pasar a recálculo selectivo

Ruta GB200 en paralelo 3D

TP=1  CP=1  PP=1 o PP moderado
EP y ETP dimensionados según la topología de experto
Distribuidor: HybridEP
Grafo CUDA: comenzar con un ancho reducido y ampliarlo solo cuando la ruta de datos reales sea estable

Compatibilidad

Característica	FSDP	Paralelo en 3D
HybridEP en GB200	ajuste predeterminado fuerte	ajuste predeterminado fuerte una vez que la topología sea estable
Gráficos CUDA	útiles tras la puesta en marcha	útiles, pero más sensibles al ámbito
Freeze Vision	encaja de forma natural	posible, pero se utiliza con menos frecuencia como vía principal para el rendimiento
Recálculo selectivo	recomendado	recomendado

Inconvenientes

Los datos multimodales simulados pueden inducir a error: pueden hacer que el decodificador parezca mucho más eficaz que la ruta VLM de extremo a extremo real.
El codificador de visión puede tener un peso mayor de lo esperado: analiza por separado el codificador, el proyector y el decodificador antes de atribuirlo todo al distribuidor.
No compares ejecuciones FSDP y 3D-paralelas con trabajo efectivo diferente: normaliza por tokens útiles y forma de la carga de trabajo, no solo por tiempo de paso.
El ETP no es gratuito: utilízalo como herramienta de ajuste o topología, no como valor predeterminado.
Las opciones de recálculo y de grafos CUDA están relacionadas: la configuración que consigue que el modelo se ajuste a menudo no es la que ofrece la mejor velocidad en estado estacionario.

Ver en 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.