Hogar

Skill

Ciencia de datos y aprendizaje automático

nemo-mbridge-perf-moe-long-context

NVIDIA/skills

Ofrece orientación para el entrenamiento de modelos de «mezcla de expertos» con ventanas de contexto largas, y abarca el dimensionamiento del paralelismo de contexto, el recálculo selectivo, las opciones de distribuidor y los patrones prácticos extraídos de experimentos recientes.

...Expandir todo

Tiempo actualizado 28 de septiembre de 2026

# nvidia # training # context parallelism # gb200 # h100 # long context # mixture of experts # selective recomputation

Entrenamiento de contexto largo con MoE

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

¿Qué cambia con contextos largos?

Una vez que la longitud de la secuencia supera con creces el régimen de la clase de 4K, la memoria de atención y la residencia de activación se convierten en las restricciones dominantes. Para los modelos MoE, eso suele significar que se necesita alguna combinación de:

paralelismo de contexto
recálculo selectivo
menor precisión
descarga de la CPU para el estado del optimizador
un despachador y una disposición PP que no desperdicien el reducido presupuesto de DP restante

Patrones de escalado redondeados

DSV3 en H100

Las ejecuciones de contexto largo de DSV3 muestran un patrón estable:

el recálculo selectivo funciona mejor que el recálculo completo una vez superados los contextos más cortos
el rendimiento se mantiene en una banda bastante estrecha desde los contextos de longitud media hasta los muy largos si se aumenta el CP adecuadamente
el equilibrio pasa de «ajuste de memoria» a «viabilidad del número de GPU» a medida que crece el CP

En otras palabras, un contexto largo no reduce inmediatamente la utilización si la disposición se elige bien, pero sí consume el presupuesto de DP muy rápidamente.

Qwen3-Next en GB200

Qwen3-Next se comporta más bien como un modelo de escala media sensible a la memoria:

8K y 32K siguen siendo viables con un CP moderado
64K es posible, pero la caída del rendimiento es notable y la memoria se vuelve mucho más escasa
las mejoras en el diseño de la canalización y en las GEMM agrupadas son casi tan importantes como el CP

Qwen3 235B en GB200

Qwen3 235B demuestra que el contexto largo puede seguir siendo eficiente en sistemas NVL72 cuando se coordinan TP, CP y HybridEP. Las mejores configuraciones de la clase de 128K no son meras «recetas de ajuste»; pueden seguir siendo muy eficientes si se equilibran el enrutamiento, el paralelismo y el recálculo.

Reglas generales para el dimensionamiento de CP

Empieza con un objetivo de fragmento de 4K: una buena estimación inicial es CP ~= seq_len / 4096, y luego redondea a una disposición práctica que sea una potencia de dos.
Mantén el DP activo si es posible: el escalado de contexto largo se vuelve frágil una vez que CP, EP, TP y PP juntos reducen el DP al mínimo.
Da prioridad al recálculo selectivo: recalcula módulos como up_proj, norm, moe, moe_act o mlp antes de recurrir al recálculo completo.
Evita el recálculo intensivo en SDPA con contextos muy largos: el recálculo de los componentes internos de la atención puede suponer mucho trabajo a cambio de un beneficio de memoria menor que el recálculo de módulos más pequeños del lado de MoE y MLP.
Utiliza TP como otra palanca en los sistemas NVL72: las ejecuciones en GB200 y GB300 pueden a veces sacrificar algo de CP a cambio de TP sin dejar de ser eficientes.
Asume que será necesario reducir el GBS: a medida que aumenta el CP y disminuye el DP, es posible que tengas que reducir el tamaño de lote global o aceptar un GA más alto.

Familias de configuraciones representativas

DSV3 a 128K en H100

TP=1  CP=32  EP=32  PP=8  VPP=4
Precisión: clase FP8
Despachador: DeepEP
Recálculo: up_proj, norm, moe, mlp
Ayuda adicional de memoria: descarga de la CPU del optimizador

DSV3 a 256K en H100

TP=1  CP=64  EP=32  PP=8  EDP=2  VPP=4
Precisión: clase FP8
Distribuidor: DeepEP
Recálculo: up_proj, norm, moe, mlp
Ayuda de memoria adicional: descarga de la CPU por el optimizador

Qwen3 235B a 128K en GB200

TP=4  CP=4  EP=32  PP=4  VPP=12
Precisión: BF16 o MXFP8
Distribuidor: HybridEP
Recálculo: moe_act, norm
Grafo CUDA: attn + moe_router + moe_preprocess

Orientación sobre el recálculo y el gráfico CUDA

Para el entrenamiento de MoE con contexto largo:

empieza con un recálculo selectivo
añade gráficos CUDA solo cuando las formas y la ruta de enrutamiento sean estables
mantén fijas la longitud de la secuencia y el MBS cuando utilices gráficos CUDA
si la ejecución depende de lotes muy dinámicos, es preferible la ejecución anticipada

Referencias útiles:

@docs/training/activation-recomputation.md
@skills/nemo-mbridge-perf-cuda-graphs/SKILL.md

Puntos a tener en cuenta

CP no sustituye a EP ni a PP: añade otra dimensión; no hace que las demás desaparezcan.
Una buena línea de base 4K puede seguir siendo una mala línea de base para contextos largos: el modo de enrutamiento, la elección de la recálculo y la estrategia de descarga a menudo deben modificarse.
La viabilidad en función del número de GPU se convierte en la verdadera limitación: un contexto muy largo puede parecer adecuado en una única receta, pero volverse imposible una vez que se añaden EP y PP de forma honesta en todo el modelo.
Los gráficos CUDA necesitan formas estáticas: los lotes de longitud variable y las estrategias de relleno oportunistas pueden romper la ruta de forma silenciosa.
La compatibilidad con contenedores y kernels cobra mayor importancia a partir de 128K+: las rutas de contexto largo tienden a depender de kernels más recientes y de correcciones de errores en mayor medida que la puesta en marcha de contexto corto.

Ver en GitHub

---
name: nemo-mbridge-perf-moe-long-context
description: Provides guidance for training Mixture-of-Experts models with long context windows, covering context parallelism sizing, selective recomputation, dispatcher choices, and practical patterns from recent experiments.
license: Apache-2.0
---

# MoE Long-Context Training

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

## What Changes At Long Context

Once sequence length moves well past the 4K-class regime, attention memory and
activation residency become the dominant constraints. For MoE models, that
usually means you need some combination of:

- context parallelism
- selective recompute
- lower precision
- CPU offload for optimizer state
- a dispatcher and PP layout that do not waste the smaller remaining DP budget

## Rounded Scaling Patterns

### DSV3 on H100

The DSV3 long-context runs show a stable pattern:

- selective recompute works better than full recompute once you move past the
  shortest contexts
- throughput stays in a fairly narrow band from mid-length through very long
  contexts if CP is increased appropriately
- the trade shifts from "memory fit" to "GPU-count feasibility" as CP grows

In other words, long context does not immediately collapse utilization if the
layout is chosen well, but it does consume the DP budget very quickly.

### Qwen3-Next on GB200

Qwen3-Next behaves more like a memory-sensitive medium-scale model:

- 8K and 32K remain practical with moderate CP
- 64K is possible, but the throughput drop is noticeable and memory becomes
  much tighter
- pipeline layout and grouped-GEMM improvements matter almost as much as CP

### Qwen3 235B on GB200

Qwen3 235B shows that long context can still be efficient on NVL72 systems when
TP, CP, and HybridEP are coordinated. The best 128K-class configurations are
not just "fit-only" recipes; they can remain highly efficient if routing,
parallelism, and recompute are balanced.

## CP Sizing Rules Of Thumb

1. **Start from a 4K shard target**: a good first guess is
   `CP ~= seq_len / 4096`, then round to a practical power-of-two layout.

2. **Keep DP alive if possible**: long-context scaling becomes brittle once CP,
   EP, TP, and PP together squeeze DP down to the floor.

3. **Prefer selective recompute**: recompute modules such as `up_proj`, `norm`,
   `moe`, `moe_act`, or `mlp` before reaching for full recompute.

4. **Avoid SDPA-heavy recompute at very long context**: recomputing attention
   internals can add a lot of work for less memory benefit than recomputing
   smaller MoE and MLP-side modules.

5. **Use TP as another lever on NVL72 systems**: GB200 and GB300 runs can
   sometimes trade some CP for TP while still staying efficient.

6. **Assume GBS will need to shrink**: as CP rises and DP falls, you may need
   to reduce global batch size or accept higher GA.

## Representative Config Families

### DSV3 at 128K on H100

```text
TP=1  CP=32  EP=32  PP=8  VPP=4
Precision: FP8-class
Dispatcher: DeepEP
Recompute: up_proj, norm, moe, mlp
Extra memory help: optimizer CPU offload
```

### DSV3 at 256K on H100

```text
TP=1  CP=64  EP=32  PP=8  EDP=2  VPP=4
Precision: FP8-class
Dispatcher: DeepEP
Recompute: up_proj, norm, moe, mlp
Extra memory help: optimizer CPU offload
```

### Qwen3 235B at 128K on GB200

```text
TP=4  CP=4  EP=32  PP=4  VPP=12
Precision: BF16 or MXFP8
Dispatcher: HybridEP
Recompute: moe_act, norm
CUDA Graph: attn + moe_router + moe_preprocess
```

## Recompute And CUDA Graph Guidance

For long-context MoE training:

- start with selective recompute
- add CUDA graphs only after the shapes and routing path are stable
- keep sequence length and MBS fixed when using CUDA graphs
- if the run depends on highly dynamic batches, prefer eager execution

Useful references:

- @docs/training/activation-recomputation.md
- @skills/nemo-mbridge-perf-cuda-graphs/SKILL.md

## Pitfalls

1. **CP does not replace EP or PP**: it adds another dimension; it does not make
   the others disappear.

2. **A good 4K baseline can still be a bad long-context baseline**: routing mode,
   recompute choice, and offload strategy often need to change.

3. **GPU-count feasibility becomes the real constraint**: very long context can
   look fine in a single recipe, then become impossible once EP and PP are added
   honestly across the full model.

4. **CUDA graphs need static shapes**: variable-length batches and opportunistic
   padding strategies can silently break the path.

5. **Container and kernel support matters more at 128K+**: long-context paths
   tend to rely on newer kernels and bug fixes than short-context bring-up does.