Generated banner for Nemo Mbridge Perf Moe Comm Overlap
Generated logo for Nemo Mbridge Perf Moe Comm Overlap

Nemo Mbridge Perf Moe Comm Overlap

NVIDIAOfficialPublished by NVIDIA

  • Skill
  • Tool integration
  • Software development
  • Apache-2.0
  • Medium risk

From the author

MoE expert-parallel communication overlap in Megatron Bridge. Covers dispatch/combine overlap, flex dispatcher backends, and expert wgrad scheduling.
— the description by NVIDIA

AutoGineer summary

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

This skill provides guidance on enabling and tuning communication overlap for MoE expert-parallel workloads within the Megatron Bridge framework. It covers the activation of dispatch and combine overlap, the use of flex dispatcher backends, and expert weight gradient (wgrad) scheduling. The documentation emphasizes that this optimization is intended for mature training runs where the dispatcher, routing, and recompute plans are already stable, as it helps hide communication latency by overlapping it with compute operations.

What it does

  • Enables MoE expert-parallel communication overlap to hide latency.
  • Configures delayed wgrad compute for additional overlap potential.
  • Provides instructions for activating the flex dispatcher backend.
  • Outlines prerequisites including EP size, dispatcher type, and precision requirements.
  • Offers guidance on validating performance gains using Nsight Systems profiling.
  • Identifies configuration conflicts, such as with shared expert overlap.

When to use it

  • When expert-parallel size is greater than 1.
  • When token dispatch or combine time is identified as a bottleneck in performance profiles.
  • When the training run is stable and you are tuning for higher throughput.
  • When you need to isolate performance gains from communication overlap in MoE models.

Advantages

  • Reduces exposed communication time by overlapping it with compute.
  • Can significantly decrease step time and increase model TFLOPS/GPU.
  • Provides clear metrics for validating performance improvements.
  • Includes specific guidance on avoiding common pitfalls like shared expert overlap conflicts.

Usage examples

“How do I enable MoE communication overlap in my Megatron Bridge configuration?”
Set cfg.comm_overlap.overlap_moe_expert_parallel_comm = True and ensure shared expert overlap is disabled.
“What are the prerequisites for using MoE communication overlap?”
You need expert_model_parallel_size > 1, num_moe_experts > 1, a compatible dispatcher type (alltoall or flex), and BF16 or FP16 precision.

Install

  1. Download the skill as a ZIP:

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

    mkdir -p .agents/skills && unzip nemo-mbridge-perf-moe-comm-overlap.zip -d .agents/skills

Documentation by NVIDIA

MoE Communication Overlap

For the higher-level overview, see:

  • @docs/training/communication-overlap.md

  • @skills/nemo-mbridge-perf-moe-comm-overlap/card.yaml

Quick Decision

Use MoE communication overlap when:

  • EP > 1

  • token dispatch or combine time is visible in the profile

  • the run is already correct and you are now tuning throughput

Avoid turning it on as an early bring-up step. It is easier to validate after the dispatcher, routing mode, and recompute plan are already stable.

Enablement

cfg.comm_overlap.overlap_moe_expert_parallel_comm = True

# Optional: delayed wgrad for additional overlap
cfg.comm_overlap.delay_wgrad_compute = True

# IMPORTANT: disable shared expert overlap when using dispatch overlap
cfg.model.moe_shared_expert_overlap = False
Prerequisites
  • expert_model_parallel_size > 1

  • num_moe_experts > 1

  • moe_token_dispatcher_type must be "alltoall" or "flex"

  • Precision: BF16 or FP16

  • If PP is used, VPP (virtual_pipeline_model_parallel_size) must be set (non-None)

Flex dispatcher activation

Setting moe_flex_dispatcher_backend alone does not activate flex dispatch. You must also set moe_token_dispatcher_type = "flex".

Recompute And CUDA Graph Interaction

  • Full recompute is not a good companion for the overlap path.

  • delay_wgrad_compute adds further constraints if CUDA-graph scopes include attention or MoE-router work.

  • In practice, selective recompute is the safer pairing when overlap is enabled.

Measured Evidence

HybridEP production-shape validation

A 2026-07-25 controlled Qwen3 30B-A3B pretraining comparison used 16 H100 GPUs, BF16, sequence length 4096, TP=1, PP=1, CP=1, EP=16, MBS=1, GBS=1024, forced-balanced routing, HybridEP, and Transformer Engine CUDA-graph scopes moe_router and moe_preprocess. The only performance change was plain EP overlap; delayed wgrad stayed disabled.

CaseSteady windowStep timeModel TFLOPS/GPU
EP overlap offiterations 5-2024.7138s244.039
EP overlap on, search runiterations 5-2021.0725s286.208
EP overlap on, independent validationiterations 41-5020.9920s287.305

The independent result reduced step time by 15.059% and increased throughput by 17.729% over the reproduced baseline. Loss remained finite, no iterations were skipped or NaN, and rank-0 peak allocated memory was 62.166 GiB.

A same-method rank-0 Nsight Systems comparison captured 463,348 kernels in each case:

Profile metricOverlap offOverlap on
Communication concurrent with GEMM/attention9.079ms3,958.997ms
Communication time hidden by compute0.11%36.55%
GPU-active interval union22.821s21.221s
HybridEP dispatch-with-permute NVTX4.253s1.767s
HybridEP metadata-preprocess NVTX3.109s0.670s

This is direct evidence that the gain came from hiding exposed HybridEP dispatch/combine work, not from changing the dispatcher, routing, graph scopes, batch shape, or parallel layout.

Correctness-first alltoall smoke

A 2026-05-18 current-main H100 x16 smoke on Qwen3 30B-A3B mock pretraining used EP=16, alltoall, global batch size 1024, CUDA graphs disabled, and moe_permute_fusion=false because the PyTorch 25.11 / TE / Triton stack failed in Transformer Engine fused permutation in prior bring-up.

Results were directional rather than release-grade:

  • no EP overlap: 41.25s steady-state mean over iterations 3-8

  • EP overlap: 31.31s steady-state mean over iterations 3-8

  • EP overlap plus delay_wgrad_compute: 31.20s steady-state mean over iterations 3-8

Treat this as evidence that EP overlap can help an inter-node alltoall MoE shape when communication is exposed. It is not proof that delayed wgrad is a separate win, and it does not validate the fused permutation path. An earlier 2026-05-16 short smoke on the same shape showed the same pattern.

Code Anchors

  • Overlap validation: src/megatron/bridge/training/comm_overlap.py

  • Flex dispatcher backend: src/megatron/bridge/training/flex_dispatcher_backend.py

  • Config: src/megatron/bridge/training/config.py

  • Unit tests: tests/unit_tests/training/test_comm_overlap.py

  • DeepEP tests: tests/unit_tests/training/test_deepep.py

Pitfalls

  1. Shared expert overlap conflict: moe_shared_expert_overlap and overlap_moe_expert_parallel_comm can conflict. Disable shared expert overlap when using the dispatch overlap path.

  2. PP without VPP: MoE overlap requires VPP when pipeline parallelism is active. Without it, the overlap scheduling cannot interleave correctly.

  3. Flex != backend flag: moe_flex_dispatcher_backend="deepep" alone does nothing if moe_token_dispatcher_type is still "alltoall".

  4. Conservative recipe defaults: Most public recipes leave MoE overlap disabled. You need to explicitly enable it via overrides.

  5. Performance gains are workload-dependent: overlap helps most when dispatch communication is already a visible slice of step time. It is not guaranteed to help every small or lightly loaded EP run.

  6. Summed kernel time is not wall time: concurrent kernels can run longer because they contend for SMs or bandwidth, so overlap may increase summed per-stream kernel duration while reducing the exposed interval union and end-to-end step time.

Verification

Look for overlap-related log messages during initialization. The comm overlap validation in comm_overlap.py will raise if prerequisites are not met, so a clean startup confirms the feature is active.

For a short performance-harness smoke, keep the command shape explicit and vary only one overlap knob at a time:

uv run python scripts/performance/run_script.py \
  -m qwen \
  -mr qwen3_30b_a3b \
  --task pretrain \
  -g h100 \
  -c bf16 \
  -ng 16 \
  -gn 8 \
  --max_steps 8 \
  --cuda_graph_impl none \
  --moe_flex_dispatcher_backend None \
  --moe_a2a_overlap false \
  --tokenizer_type NullTokenizer \
  comm_overlap.overlap_moe_expert_parallel_comm=true \
  comm_overlap.delay_wgrad_compute=false \
  model.moe_shared_expert_overlap=false

If fused MoE permutation fails during bring-up, add model.moe_permute_fusion=false to separate overlap timing from runtime-stack validation, then retest with the matched production container.

For performance validation, use an unprofiled steady window as the acceptance metric. Use a matched Nsight A/B to establish causality:

  1. Keep dispatcher, routing, CUDA graphs, batch shape, parallelism, and runtime fixed.

  2. Toggle only overlap_moe_expert_parallel_comm; keep delay_wgrad_compute=false for the first isolation.

  3. Compare communication and compute interval unions and their intersection, not only summed kernel durations.

  4. Report steady step time, model TFLOPS/GPU, loss finiteness, skipped/NaN iterations, and peak allocated memory.

Last signature refresh: 2026-08-03.

Files

card.yaml

title: moe_comm_overlap
validated_on: "2026-07-25"
summary: >
  Megatron-Bridge supports MoE expert-parallel communication overlap through
  overlap_moe_expert_parallel_comm, with optional delayed expert wgrad
  scheduling. A controlled Qwen3 30B-A3B HybridEP run on 16 H100 GPUs measured
  a 15.059% step-time reduction and 17.729% throughput increase from plain EP
  overlap with delayed wgrad disabled.
validation_status:
  moe_overlap_validation:
    - code_verified
  flex_dispatcher_activation:
    - code_verified
  deepep_hybridep_helper_behavior:
    - code_verified
  end_to_end_recipe_smoke:
    - measured
  qwen3_30b_hybridep_h100:
    - measured
  matched_nsys_ab:
    - measured
feature_meaning:
  moe_overlap: >
    Overlap of expert-parallel token dispatch communication with expert compute.
  delay_wgrad_compute: >
    Delayed expert weight-gradient scheduling layered on top of MoE overlap.
  flex_dispatcher: >
    Dispatcher mode used for DeepEP or HybridEP style backends.
recommended_path:
  comm_overlap.overlap_moe_expert_parallel_comm: true_for_moe_tuning
  comm_overlap.delay_wgrad_compute: false_for_first_isolation
  model.moe_shared_expert_overlap: false_when_overlap_is_enabled
measured_result:
  model: Qwen3 30B-A3B
  hardware: "16×H100"
  precision: BF16
  shape: "seq4096 TP1 PP1 CP1 EP16 MBS1 GBS1024"
  dispatcher: HybridEP
  routing: force_balance
  cuda_graph_scopes: "moe_router, moe_preprocess"
  baseline_step_time_ms: 24713.800
  baseline_model_tflops_per_gpu: 244.039
  overlap_step_time_ms: 20992.030
  overlap_model_tflops_per_gpu: 287.305
  step_time_reduction_percent: 15.059
  throughput_gain_percent: 17.729
  rank0_peak_allocated_gib: 62.166
  skipped_iterations: 0
  nan_iterations: 0
profile_result:
  captured_kernels_per_case: 463348
  comm_compute_overlap_off_ms: 9.079
  comm_compute_overlap_on_ms: 3958.997
  comm_hidden_off_percent: 0.11
  comm_hidden_on_percent: 36.55
  gpu_active_union_off_ms: 22820.667
  gpu_active_union_on_ms: 21221.363
known_constraints:
  - expert_model_parallel_size must be greater than 1.
  - num_moe_experts must be greater than 1.
  - moe_token_dispatcher_type must be alltoall or flex.
  - Precision must be BF16 or FP16.
  - If pipeline parallelism is used, virtual pipeline parallelism is required for the overlap path.
known_limitations:
  - Setting moe_flex_dispatcher_backend alone does not activate flex dispatch.
  - Public recipes are often conservative and leave MoE overlap disabled by default.
  - The measured gain is workload-specific and should not be generalized across model, dispatcher, topology, or batch changes.
  - Summed per-stream kernel time is not a wall-time metric when kernels overlap.
evidence:
  - docs/training/communication-overlap.md
  - examples/model_verification_cards/qwen3-30b-a3b/card.yaml
  - src/megatron/bridge/perf_recipes/qwen/h100/qwen3_moe.py
  - docs/parallelisms.md
  - src/megatron/bridge/training/comm_overlap.py
  - src/megatron/bridge/training/flex_dispatcher_backend.py
  - src/megatron/bridge/training/config.py
  - tests/unit_tests/training/test_comm_overlap.py
  - tests/unit_tests/training/test_deepep.py
follow_up_validation:
  - Add a positive Bridge functional smoke for overlap_moe_expert_parallel_comm.
  - Repeat the matched profile method on another model family and topology.

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.

Needs: Needs Python, Needs Node.js

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-comm-overlap · 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 or NVIDIA.

Download ZIP

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