Nemo Mbridge Perf Moe Comm Overlap
NVIDIAOfficialPublished by NVIDIA
- Skill
- Tool integration
- Software development
- Apache-2.0
- Medium risk
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/nemo-mbridge-perf-moe-comm-overlap/downloadUnzip 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 > 1token 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 = FalsePrerequisites
expert_model_parallel_size > 1num_moe_experts > 1moe_token_dispatcher_typemust 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_computeadds 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.
| Case | Steady window | Step time | Model TFLOPS/GPU |
|---|---|---|---|
| EP overlap off | iterations 5-20 | 24.7138s | 244.039 |
| EP overlap on, search run | iterations 5-20 | 21.0725s | 286.208 |
| EP overlap on, independent validation | iterations 41-50 | 20.9920s | 287.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 metric | Overlap off | Overlap on |
|---|---|---|
| Communication concurrent with GEMM/attention | 9.079ms | 3,958.997ms |
| Communication time hidden by compute | 0.11% | 36.55% |
| GPU-active interval union | 22.821s | 21.221s |
| HybridEP dispatch-with-permute NVTX | 4.253s | 1.767s |
| HybridEP metadata-preprocess NVTX | 3.109s | 0.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.pyFlex dispatcher backend:
src/megatron/bridge/training/flex_dispatcher_backend.pyConfig:
src/megatron/bridge/training/config.pyUnit tests:
tests/unit_tests/training/test_comm_overlap.pyDeepEP tests:
tests/unit_tests/training/test_deepep.py
Pitfalls
Shared expert overlap conflict:
moe_shared_expert_overlapandoverlap_moe_expert_parallel_commcan conflict. Disable shared expert overlap when using the dispatch overlap path.PP without VPP: MoE overlap requires VPP when pipeline parallelism is active. Without it, the overlap scheduling cannot interleave correctly.
Flex != backend flag:
moe_flex_dispatcher_backend="deepep"alone does nothing ifmoe_token_dispatcher_typeis still"alltoall".Conservative recipe defaults: Most public recipes leave MoE overlap disabled. You need to explicitly enable it via overrides.
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.
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=falseIf 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:
Keep dispatcher, routing, CUDA graphs, batch shape, parallelism, and runtime fixed.
Toggle only
overlap_moe_expert_parallel_comm; keepdelay_wgrad_compute=falsefor the first isolation.Compare communication and compute interval unions and their intersection, not only summed kernel durations.
Report steady step time, model TFLOPS/GPU, loss finiteness, skipped/NaN iterations, and peak allocated memory.
Last signature refresh: 2026-08-03.
Files
- ATTRIBUTION.mdAdded by AutoGineer867 B
- BENCHMARK.md4.8 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md7.3 KiB
- card.yaml3.3 KiB
- evals/evals.json1.6 KiB
- skill-card.md4.3 KiB
- skill.oms.sig4.7 KiB
evals/evals.json
[
{
"id": "moe-comm-overlap-positive-dispatch-combine-smoke",
"question": "Use the nemo-mbridge-perf-moe-comm-overlap skill. Give the exact MoE dispatch/combine overlap knobs, PP/VPP and flex-dispatcher constraints, and the measured inter-node alltoall baseline numbers from the skill.",
"expected_skill": "nemo-mbridge-perf-moe-comm-overlap",
"expected_script": null,
"ground_truth": "The answer should use the MoE communication overlap skill. It should set cfg.comm_overlap.overlap_moe_expert_parallel_comm=True, optionally cfg.comm_overlap.delay_wgrad_compute=True after basic overlap is stable, and cfg.model.moe_shared_expert_overlap=False. It should require num_moe_experts>1, moe_token_dispatcher_type of alltoall or flex, and VPP when PP is active. It should state moe_flex_dispatcher_backend alone is insufficient unless moe_token_dispatcher_type=\"flex\" is set. It should say full recompute is not a good companion, selective recompute is safer, and delayed wgrad adds CUDA-graph constraints. It should include the measured EP=16 alltoall example: no overlap 41.25s, EP overlap 31.31s, EP overlap plus delay_wgrad_compute 31.20s over iterations 3-8.",
"expected_behavior": [
"Read the nemo-mbridge-perf-moe-comm-overlap skill before answering.",
"Identify MoE expert communication overlap as the target feature.",
"List overlap_moe_expert_parallel_comm, delay_wgrad_compute, and moe_shared_expert_overlap.",
"Mention PP requires VPP and flex requires moe_token_dispatcher_type=flex.",
"Mention recompute and CUDA graph interactions.",
"Quote the 41.25s, 31.31s, and 31.20s timing comparison."
]
}
]
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