option
MaisonMaison Skill Science des données et ML nemo-mbridge-perf-moe-long-context

nemo-mbridge-perf-moe-long-context

NVIDIA/skills NVIDIA/skills

Ce document fournit des recommandations pour l'entraînement de modèles de type « Mixture-of-Experts » avec des fenêtres de contexte longues. Il aborde notamment le dimensionnement du parallélisme contextuel, le recalcul sélectif, le choix des répartiteurs, ainsi que des modèles pratiques issus d'expériences récentes.

...Développer tout
3
Heure mise à jour 28 septembre 2026

Entraînement MoE à long contexte

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

Quels changements dans le cadre des contextes longs ?

Dès que la longueur de la séquence dépasse largement le régime de l’ordre de 4K, la mémoire d’attention et la résidence d’activation deviennent les contraintes dominantes. Pour les modèles MoE, cela signifie généralement qu’il faut combiner :

  • le parallélisme contextuel
  • recalcul sélectif
  • précision réduite
  • déchargement du CPU pour l'état de l'optimiseur
  • un répartiteur et une disposition PP qui ne gaspillent pas le budget DP restant, plus restreint

Modèles de mise à l'échelle arrondis

DSV3 sur H100

Les exécutions à long contexte du DSV3 montrent un schéma stable :

  • le recalcul sélectif fonctionne mieux que le recalcul complet dès lors que l’on dépasse les contextes les plus courts
  • le débit reste dans une fourchette assez étroite, des contextes de longueur moyenne aux très longs, si le CP est augmenté de manière appropriée
  • le compromis passe de l’« adaptation à la mémoire » à la « faisabilité en nombre de GPU » à mesure que le CP augmente

En d’autres termes, un contexte long n’entraîne pas immédiatement une chute du taux d’utilisation si la disposition est bien choisie, mais il épuise très rapidement le budget DP.

Qwen3-Next sur GB200

Qwen3-Next se comporte davantage comme un modèle de taille moyenne sensible à la mémoire :

  • 8 Ko et 32 Ko restent viables avec un CP modéré
  • 64K est possible, mais la baisse de débit est perceptible et la mémoire devient beaucoup plus limitée
  • les améliorations apportées à la disposition du pipeline et aux GEMM groupées ont presque autant d’importance que le CP

Qwen3 235B sur GB200

Qwen3 235B montre qu'un contexte long peut encore être efficace sur les systèmes NVL72 lorsque le TP, le CP et l'HybridEP sont coordonnés. Les meilleures configurations de classe 128K ne sont pas seulement des recettes « adaptées » ; elles peuvent rester très efficaces si le routage, le parallélisme et le recalcul sont équilibrés.

Règles empiriques pour le dimensionnement du CP

  1. Commencez par une cible de fragment de 4 Ko: une bonne première estimation est CP ~= seq_len / 4096, puis arrondissez à une configuration pratique de type « puissance de deux ».

  2. Maintenez le DP actif si possible: la scalabilité des contextes longs devient fragile dès que le CP, l’EP, le TP et le PP, combinés, réduisent le DP à son minimum.

  3. Privilégiez le recalcul sélectif: recalculez des modules tels que up_proj, norm, moe, moe_act ou mlp avant d’en arriver à un recalcul complet.

  4. Évitez les recalculs gourmands en SDPA avec des contextes très longs: le recalcul des composants internes de l’attention peut ajouter beaucoup de travail pour un gain de mémoire moindre que le recalcul de modules plus petits côté MoE et MLP.

  5. Utilisez TP comme levier supplémentaire sur les systèmes NVL72: les exécutions sur GB200 et GB300 peuvent parfois échanger une partie de CP contre TP tout en restant efficaces.

  6. Partez du principe que le GBS devra être réduit: à mesure que le CP augmente et que le DP diminue, vous devrez peut-être réduire la taille globale des lots ou accepter un GA plus élevé.

Familles de configurations représentatives

DSV3 à 128K sur H100

TP=1  CP=32  EP=32  PP=8  VPP=4
Précision : classe FP8
Dispatcher : DeepEP
Recalcul : up_proj, norm, moe, mlp
Aide mémoire supplémentaire : déchargement du processeur par l’optimiseur

DSV3 à 256K sur H100

TP=1  CP=64  EP=32  PP=8  EDP=2  VPP=4
Précision : classe FP8
Dispatcher : DeepEP
Recalcul : up_proj, norm, moe, mlp
Aide mémoire supplémentaire : déchargement du CPU par l’optimiseur

Qwen3 235B à 128K sur GB200

TP=4  CP=4  EP=32  PP=4  VPP=12
Précision : BF16 ou MXFP8
Dispatcher : HybridEP
Recalcul : moe_act, norm
Graphique CUDA : attn + moe_router + moe_preprocess

Conseils sur le recalcul et le graphe CUDA

Pour l’entraînement MoE à contexte long :

  • commencez par un recalcul sélectif
  • n'ajoutez des graphes CUDA qu'une fois que les formes et le chemin de routage sont stables
  • maintenez la longueur de séquence et le MBS fixes lorsque vous utilisez des graphes CUDA
  • si l'exécution dépend de lots très dynamiques, privilégiez l'exécution « eager »

Références utiles :

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

Pièges

  1. Le CP ne remplace ni l’EP ni le PP: il ajoute une dimension supplémentaire ; il ne fait pas disparaître les autres.

  2. Une bonne base de référence 4K peut tout de même s’avérer médiocre pour les contextes longs: le mode de routage, le choix de recalcul et la stratégie de déchargement doivent souvent être modifiés.

  3. La faisabilité en termes de nombre de GPU devient la véritable contrainte: un contexte très long peut sembler convenir dans une recette unique, puis devenir impossible une fois que l’EP et le PP sont ajoutés de manière cohérente à l’ensemble du modèle.

  4. Les graphes CUDA nécessitent des formes statiques: les lots de longueur variable et les stratégies de remplissage opportunistes peuvent rompre le chemin de manière silencieuse.

  5. La prise en charge des conteneurs et des noyaux revêt davantage d’importance à partir de 128K+: les chemins à long contexte ont tendance à s’appuyer davantage sur des noyaux plus récents et des corrections de bogues que ne le fait la mise en route à court contexte.

Voir sur 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.

Tous les fichiers

1 fichiers

Installer nemo-mbridge-perf-moe-long-context

Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.

Télécharger le ZIP

Clonez le dépôt et copiez les fichiers de compétence dans votre projet.

git clone https://github.com/NVIDIA/skills/tree/main/skills/nemo-mbridge-perf-moe-long-context # Copy SKILL.md to your .claude/skills/ directory

Copier Copier
Configuration rapide: Copiez le dossier de la compétence dans .claude/skills/ Claude détectera automatiquement la compétence et l'utilisera
Dépôt NVIDIA/skills

Compétences similaires

web-search
Heure mise à jour 29 juin 2026
webapp-testing
Heure mise à jour 29 juin 2026
lark-base
Heure mise à jour 5 juillet 2026
agentmail
Heure mise à jour 29 juin 2026
OR