nemo-mbridge-multi-node-slurm
Convert single-node scripts to multi-node Slurm sbatch jobs and debug common multi-node failures. Covers srun-native vs uv run torch.distributed approaches, container setup, NCCL timeouts, OOM sizing for MoE models, and interactive allocation.
Security Assessment
About nemo-mbridge-multi-node-slurm
Multi-Node Slurm is an NVIDIA instruction skill for converting single-node training scripts into multi-node Slurm sbatch jobs for Megatron Bridge (NeMo), and for debugging the common failures that appear at multi-node scale. It solves the practical pain of getting distributed training launches right: how to structure sbatch headers, spawn processes, mount containers, and diagnose NCCL and launch errors.
The skill lays out two launch approaches with a clear recommendation. The preferred srun-native shape uses `--ntasks-per-node=8` and a direct `srun ... uv run python <script>` launch, relying on Megatron Bridge to auto-derive RANK, WORLD_SIZE, LOCAL_RANK, MASTER_ADDR, and MASTER_PORT from SLURM environment variables during initialize.py. The legacy `uv run torch.distributed` approach keeps `--ntasks-per-node=1` and lets torchrun spawn per-node processes, with explicit warnings about EADDRINUSE port collisions if misconfigured. It covers Enroot container setup, a two-phase srun pattern (warm the uv cache once, then launch on all ranks), shared-filesystem requirements for repo/data/logs/HF_HOME/UV_CACHE_DIR/NEMO_HOME, interactive salloc+srun allocation, and a first-log NCCL-timeout triage checklist (grep for real errors, find the first failed rank, check ncclUniqueId/timeout). It also gives strong security-conscious guidance: keep credentials like HF_TOKEN, GH_TOKEN, and WANDB_API_KEY out of sbatch templates and logs, provide them through the scheduler environment or a restricted secrets file, and never hardcode token values.
Target users are ML engineers and researchers scaling Megatron Bridge training to multiple nodes on Slurm clusters, or investigating a commit that caused a multi-node failure. It is documentation-and-template guidance; any commands shown are standard cluster training operations.
FAQ
What problem does this skill solve?
It helps convert single-node Megatron Bridge training scripts into multi-node Slurm sbatch jobs with Enroot containers, and it triages common multi-node failures like NCCL timeouts and launch errors.
Which launch approach does it recommend?
The srun-native approach (--ntasks-per-node=8, direct srun launch), because Bridge auto-derives distributed environment variables from SLURM and it avoids TRAIN_CMD shell-escaping issues. A legacy torch.distributed approach with --ntasks-per-node=1 is documented for scripts that need torchrun.
How should credentials be handled?
The skill instructs keeping tokens like HF_TOKEN, GH_TOKEN, and WANDB_API_KEY out of sbatch templates and logs, supplying them via the scheduler environment or a restricted secrets file, and never hardcoding token values in the script body.
Why must NEMO_HOME be on shared storage?
For multi-node SFT/PEFT jobs, packed-sequence data prepared on node 0 must be visible to the other nodes, so NEMO_HOME must not use the container-local default (/root/.cache/nemo).
How does it approach NCCL timeout debugging?
It prescribes first-log checks before speculating: grep for real errors while filtering warning noise, inspect Failures: to find the first failed rank and node, and grep for ncclUniqueId, timeout, or a rank-0 crash.
Install nemo-mbridge-multi-node-slurm
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
nvidia/skills