Generated banner for Nemo Mbridge Perf Moe Hardware Configs
Generated logo for Nemo Mbridge Perf Moe Hardware Configs

Nemo Mbridge Perf Moe Hardware Configs

NVIDIAOfficialPublished by NVIDIA

  • Skill
  • Guidelines
  • Data and AI
  • Apache-2.0
  • Medium risk

From the author

Representative, point-in-time MoE training playbooks by hardware and model family. Use them as candidate seeds, then revalidate the exact runtime, semantics, topology, and steady-state throughput.
— the description by NVIDIA

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured reference for Mixture-of-Experts (MoE) training configurations. It outlines representative playbooks, performance bands, and tuning strategies for different hardware (H100, B200, GB200, GB300) and model families (DSV3, Qwen3). It emphasizes that these configurations serve as candidate seeds for performance optimization rather than absolute defaults, highlighting the importance of revalidation through profile-driven testing, dispatcher selection, and environment tuning.

What it does

  • Provides candidate hardware-specific MoE training configurations.
  • Defines performance bands and representative shapes for planning.
  • Lists critical environment variables for performance tuning.
  • Outlines recompute strategies based on memory pressure.
  • Details CPU-side tuning requirements for GB200/GB300 systems.
  • Identifies common pitfalls in MoE performance benchmarking.

When to use it

  • When planning MoE training runs on H100, B200, or GB200/300 hardware.
  • When seeking candidate seeds for model parallelism and dispatcher settings.
  • When troubleshooting performance regressions in MoE training pipelines.
  • When establishing a baseline for throughput and memory usage.

Advantages

  • Reduces trial-and-error by providing validated starting configurations.
  • Encourages rigorous performance validation through A/B testing.
  • Highlights the impact of software stack and container quality on throughput.
  • Provides clear guidance on balancing memory headroom and throughput.

Usage examples

“What is a recommended configuration for training DSV3 on H100 hardware?”
The agent provides the DeepEP dispatcher configuration with specific TP, EP, PP, and VPP settings, noting the importance of communication overlap.
“How should I tune GB200 systems for MoE training?”
The agent suggests using HybridEP, focusing on CPU-side tuning, graph-friendly static shapes, and specific environment variables like NCCL_GRAPH_REGISTER=0.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/nvidia/nemo-mbridge-perf-moe-hardware-configs/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip nemo-mbridge-perf-moe-hardware-configs.zip -d .agents/skills

Documentation by NVIDIA

MoE Hardware Configuration Reference

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

Quick Platform Playbook

These rows are search seeds, not hardware defaults or throughput promises.

PlatformCandidates to screen after alltoall bring-upWhat usually matters most
H100DeepEP or HybridEP, explicit overlap, supported FP8 modescommunication overlap, dispatcher/runtime compatibility, and PP efficiency
B200DeepEP or HybridEP, supported FP8 modes, careful PP layoutcontainer quality and tuned communication settings
GB200HybridEP, then profile-driven graphs and CPU cleanuphost overhead, topology-aware dispatch, memory headroom
GB300HybridEP and the target container's lower-precision/kernel stackthe same system interactions as GB200, with remeasurement required

First Answer Checklist

For hardware playbook questions, answer from these canonical rows before adding throughput caveats:

WorkloadHardwareDispatcherLayout
DSV3H100DeepEPTP=2, EP=64, PP=8, VPP=4
DSV3GB200/GB300HybridEPTP=1, EP=64, PP=4, VPP=4
Qwen3 235BH100alltoall + overlap in the current canonical recipeTP=2, EP=32, PP=8, VPP=4
Qwen3 235BGB200HybridEPTP=1 or 2, EP=32-64, PP=4, VPP=unspecified
Qwen3 30B16×H100HybridEPTP=1, EP=16, PP=1, plain EP overlap

For Qwen3 235B on GB200, explicitly say VPP=unspecified; do not invent or extrapolate VPP=12 unless a measured row provides it. Treat TE-scoped CUDA graph scopes (attn, moe_router, moe_preprocess) as profile-driven candidates, CUDA_DEVICE_MAX_CONNECTIONS selection, PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True, NCCL_GRAPH_REGISTER=0, GB200/GB300 CPU-side tuning, and the warning not to cargo-cult tracker rows.

Rounded Performance Bands

These are intentionally rounded so the document stays durable as the tracker moves. Treat them as planning ranges, not exact promises.

Workload familyHardwareTypical bandRepresentative shape
DSV3, large-scaleH100low-to-mid hundreds TFLOPS/GPU, high-teens MFUTP2, EP64, PP8, DeepEP
DSV3, large-scaleB200high-hundreds TFLOPS/GPU, mid-teens MFUTP1, EP32, PP8, DeepEP
DSV3, large-scaleGB200around 1K TFLOPS/GPU, low-20s MFUTP1, EP64, PP4, HybridEP
DSV3, large-scaleGB300above the GB200 band, often mid-20s MFUTP1, EP64, PP4, HybridEP
Qwen3 235BH100historical low-300s snapshots; remeasure the current recipeTP2, EP32, PP8; current recipe uses alltoall + overlap
Qwen3 235BGB200high-hundreds TFLOPS/GPU in tuned runsTP1 or TP2, EP32-64, PP4, HybridEP
Qwen3 30BH100about 300 TFLOPS/GPU on the validated 16-GPU shapeTP1, EP16, PP1, HybridEP + EP overlap
Qwen3-Next 80BGB200low-300s TFLOPS/GPU in BF16-class runsTP1, EP32, PP2, HybridEP

Representative Config Families

DSV3 on H100
Dispatcher: DeepEP
TP=2  EP=64  PP=8  VPP=4
Routing: force balance
Recompute: light-to-moderate selective recompute
Priority: overlap communication and keep PP efficient
DSV3 on B200
Dispatcher: DeepEP
TP=1  EP=32  PP=8  VPP=2 or similar
Precision: MXFP8-class
Recompute: selective recompute around MLA up-projection and MLP-side modules
Priority: container quality, PP layout, and DeepEP SMS tuning
DSV3 on GB200 or GB300
Dispatcher: HybridEP
TP=1  EP=64  PP=4  VPP=4
Precision: MXFP8-class
CUDA Graph: attn + moe_router + moe_preprocess
Priority: HybridEP, CPU optimization, and graph-friendly static shapes
Qwen3 235B on H100
Dispatcher: alltoall in the current canonical recipe; re-screen flex backends on the target stack
TP=2  EP=32  PP=8  VPP=4
Recompute: none in the current canonical recipe
Priority: communication overlap and router-path cleanup
Qwen3 235B on GB200
Dispatcher: HybridEP
TP=1 or 2  EP=32 to 64  PP=4  VPP=unspecified unless measured
CUDA Graph: attn + moe_router + moe_preprocess
Recompute: moe_act, mlp, or norm depending on memory pressure
Priority: balance throughput against memory headroom
Qwen3 30B-A3B on 16 H100
Dispatcher: HybridEP
TP=1  EP=16  PP=1  CP=1
Precision: BF16
Sequence: 4096
Batch: MBS1 GBS1024
Routing: force balance
EP overlap: enabled
Delayed wgrad: disabled
CUDA Graph: moe_router + moe_preprocess
HybridEP: permute fusion, 32 SMs, 64-token combine chunks
Measured: 20.14729s/step, 299.352 model TFLOPS/GPU over iterations 41-50
Rank-0 peak allocated memory: 62.166 GiB

The current number is the final multi-knob canonical recipe result. An earlier matched A/B isolated plain EP overlap: 244.039 to 287.305 TFLOPS/GPU, with communication hidden by GEMM/attention increasing from 0.11% to 36.55%. Do not attribute the later 299.352 result entirely to overlap.

Qwen3-Next 80B on GB200
Dispatcher: HybridEP
TP=1  EP=32  PP=2  VPP around 4
CUDA Graph: attn + moe_router + moe_preprocess
Priority: pipeline layout and grouped GEMM quality

Cross-Cutting Patterns

PP layout
  • E = embedding

  • t = transformer

  • m = MTP

  • L = loss

  • | = stage boundary

The biggest platform difference is usually not just the dispatcher. It is the combination of dispatcher, PP shape, and whether VPP keeps each stage balanced.

Recompute strategy
Memory pressureStarting point
lownone or a very narrow selective set
moderatemoe_act, mlp, norm, or similar selective modules
highmodel-specific up-projection plus selective MoE and MLP modules
extreme or long-contextfull recompute only if the selective path still does not fit
Environment variables
CUDA_DEVICE_MAX_CONNECTIONS=1
CUDA_DEVICE_MAX_CONNECTIONS=32   # common when EP overlap and CUDA graphs are combined
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
NCCL_GRAPH_REGISTER=0
CPU-side tuning

On GB200 and GB300, CPU affinity and general host-overhead cleanup can move the needle almost as much as a dispatcher swap. Treat them as first-class tuning work, not as afterthoughts.

Pitfalls

  1. Do not cargo-cult a tracker row: the winning config usually depends on routing mode, container, and PP layout as much as on hardware name.

  2. Container quality matters: large regressions can come from the software stack rather than the model recipe.

  3. VPP must be intentional: a bad VPP split can erase the gain from a better dispatcher.

  4. Compare absolute throughput, not only MFU: MFU can mislead when switching between BF16, FP8, and other precision modes.

  5. Force-balance routing is benchmark-only: it can control routing variance, but it changes semantics. Keep routing fixed within an A/B and validate natural routing separately for training acceptance.

  6. Do not treat the dispatcher table as a hard platform rule: HybridEP is the validated winner for the canonical 16×H100 Qwen3 30B shape, while the current 256×H100 Qwen3 235B recipe uses alltoall. Benchmark backend compatibility and throughput in the production container.

  7. Separate screening, causality, and acceptance: short runs reject weak candidates, matched one-variable A/Bs explain a mechanism, and a 50-step final run validates the complete winner.

Last signature refresh: 2026-08-03.

Files

evals/evals.json

[
  {
    "id": "moe-hardware-configs-positive-platform-smoke",
    "question": "Use the nemo-mbridge-perf-moe-hardware-configs skill as an implementation checklist. I am choosing MoE training playbooks for DSV3 and Qwen3 235B on H100 versus GB200/GB300. Give the representative TP/EP/PP/VPP layouts where the skill provides VPP; explicitly say Qwen3 235B on GB200 has VPP=unspecified and do not invent VPP=12. Include dispatcher choices, CUDA graph scopes, environment knobs, GB200/GB300 CPU-side tuning note, and the main warning about copying tracker rows.",
    "expected_skill": "nemo-mbridge-perf-moe-hardware-configs",
    "expected_script": null,
    "ground_truth": "The answer should use MoE hardware configuration guidance and label every row as a point-in-time candidate seed rather than a hardware default. It should state DSV3 measured snapshots use DeepEP with TP=2, EP=64, PP=8, VPP=4 on H100 and HybridEP with TP=1, EP=64, PP=4, VPP=4 on GB200/GB300. It should state the current Qwen3 235B H100 recipe uses alltoall plus overlap with TP=2, EP=32, PP=8, VPP=4, while a representative GB200 row uses HybridEP with TP=1 or 2, EP=32-64, PP=4 and leaves VPP unspecified unless measured. It must not invent VPP=12. It should identify the canonical 16xH100 Qwen3 30B result as HybridEP at 299.352 model TFLOPS/GPU over steps 41-50, distinguish that final winner from the earlier 244.039 to 287.305 overlap A/B, mention relevant environment knobs and GB200/GB300 CPU-side tuning, and warn against cargo-culting tracker rows or using forced routing as training-equivalent acceptance.",
    "expected_behavior": [
      "Read the nemo-mbridge-perf-moe-hardware-configs skill before answering.",
      "Identify the task as a hardware-platform MoE playbook request.",
      "Treat hardware rows as candidate seeds and preserve model-specific exceptions.",
      "List representative DSV3 and Qwen3 235B TP/EP/PP/VPP layouts.",
      "State that Qwen3 235B on GB200 has VPP unspecified and must not invent VPP=12.",
      "Mention CUDA graph scopes and environment knobs from the skill.",
      "Distinguish the current 299.352 Qwen3 winner from the earlier overlap-only A/B.",
      "Warn against copying tracker rows without target-stack validation."
    ]
  }
]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
NVIDIA
Publisher
NVIDIA (Official)
Source
NVIDIA/skills · skills/nemo-mbridge-perf-moe-hardware-configs · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nemo-mbridge-perf-moe-hardware-configs.zip