Megatron Distributed Training On 16 RTX PRO 6000 GPUs

This is a standalone technical writeup about building and testing a >Megatron distributed training setup across a 2-node, 16-GPU RTX PRO >6000 Blackwell cluster.

The goal was not to produce a final high-quality model. The goal was to understand the infrastructure layer that makes larger training possible: model import, distributed launch, parallelism layout, forward/backward correctness, checkpointing, resharding, and failure modes.

Scope

The focus was training infrastructure, not final model quality.

Quality depends on data, recipes, hyperparameters, evals, token budget, and repeated ablations. These tests focused on whether the distributed training stack works:

• launch
• model construction
• checkpoint import
• checkpoint resharding
• forward/backward
• gradient reduction
• no NaNs/skips
• checkpoint save
• repeatable config recording

In other words, the question was:

Can a model be converted, split across GPUs, trained for a few steps, synchronized correctly, saved, and then used as a base for longer continued-pretraining or supervised fine-tuning runs?

Hardware / Cluster

• 2 nodes.
• 8x RTX PRO 6000 Blackwell GPUs per node.
• 16 GPUs total.
• Each node used node-local NVMe storage for datasets, checkpoints, and logs.
• Private internode networking was used for NCCL/distributed training.
• Most larger model smoke tests were run on one free 8-GPU node.
• The public WikiText 5D run used both nodes and all 16 GPUs.

Stack

• Megatron-LM: training runtime, launch scripts, model-parallel groups, distributed optimizer, and checkpoint flow.
• Megatron-Bridge: Hugging Face to Megatron conversion, model providers, recipes, and training entrypoints.
• Megatron-Core: tensor, pipeline, context, expert, and sequence-parallel primitives used by the models.
• Transformer Engine: optimized transformer kernels, FP8 paths, attention kernels, and communication overlap.
• NCCL: GPU collectives for tensor parallelism, data parallelism, expert routing, and multinode communication.
• Torch distributed checkpointing: sharded checkpoint save/load and resharding across different layouts.
• Hugging Face integration: public model/tokenizer download and checkpoint import.
• BF16, FP8, and MXFP8 precision paths.

How The Pieces Fit Together

The stack has three main layers:

1. Model source format

Public model checkpoints usually start as Hugging Face snapshots. That format is convenient for inference and ecosystem compatibility, but it is not the same layout Megatron uses for distributed training.

1. Conversion and model provider layer

Megatron-Bridge maps the Hugging Face model into Megatron's model-provider and checkpoint format. This is where architecture-specific details matter: MoE routing, expert layout, attention variants, Mamba blocks, tokenizer files, precision config, and the target parallelism layout.

1. Distributed training layer

Megatron-LM/Megatron-Core then train the model using explicit parallel groups. The same model can be loaded with different runtime layouts, such as TP=2, PP=2, or EP=4, as long as the model architecture and checkpoint layout support it.

The practical flow looked like this:

Hugging Face model/tokenizer
        |
        v
Megatron-Bridge import / model provider
        |
        v
Megatron-format checkpoint
        |
        v
Megatron distributed launch
        |
        v
train -> validate -> save checkpoint -> inspect logs

How A Megatron Run Works

A useful Megatron smoke run is more than "the script started." The minimum proof is:

1. The distributed process group initializes across all ranks.
2. The model builds with the requested TP, PP, CP, DP, EP, ETP, EDP, and SP layout.
3. The dataset and tokenizer paths resolve on every participating node.
4. A forward pass runs without backend or shape errors.
5. Backward pass and gradient synchronization complete.
6. No NaNs or skipped iterations appear.
7. A checkpoint is written in the expected distributed layout.
8. Validation/test can run when enabled.

This is why short runs are still valuable. They test the infrastructure contract before spending time on long training.

How Megatron-Bridge Was Used

Megatron-Bridge was useful because the experiments involved public Hugging Face models, but the training target was Megatron. Bridge handled the important middle layer:

• Load public model configuration and tokenizer assets.
• Map Hugging Face parameters into Megatron parameter names and tensor layouts.
• Create a Megatron-compatible checkpoint.
• Support runtime resharding when the training layout differs from the import layout.
• Provide model-specific recipes and providers for architectures like DeepSeek MoE and Nemotron hybrid models.

The practical learning: conversion is not a side task. For large-model training, conversion and checkpoint layout are part of the training system.

Parallelism Mental Model

Megatron is useful because it exposes several parallelism axes directly:

Axis	What It Splits	Why It Matters
TP	Dense tensor operations inside layers	Reduces per-GPU memory and compute for large matrix operations
PP	Model layers across pipeline stages	Lets different GPUs hold different layer blocks
CP	Long sequence/context tokens	Enables longer-context training by splitting the token axis
DP	Data batches over replicated model groups	Improves throughput while synchronizing gradients
EP	MoE experts across GPUs	Prevents every GPU from storing every expert
ETP	Weights inside each expert	Helps when individual experts are too large
EDP	Expert-parallel groups over data	Adds data-parallel throughput for expert groups
SP	Temporary activations inside tensor-parallel groups	Saves activation memory; does not add a new world-size dimension

The important point is that these axes are not just multiplication. A mathematically valid world size can still fail because of layer counts, attention backend support, kernel availability, memory pressure, or checkpoint layout.

For example:

• PP=2 failed on DeepSeek-V2-Lite until uneven pipeline splitting was used, because the model has 27 layers.
• CP=2 worked on the custom MoE GPT and Nemotron paths, but DeepSeek-V2-Lite's MLA attention path hit a backend issue.
• SP helped memory with TP, but it did not add a new rank dimension.

Checkpointing And Resharding

Checkpointing is part of the infrastructure test. A run that finishes forward/backward but cannot save is not a complete distributed training proof.

Two checkpoint ideas mattered:

• Import checkpoint: the Megatron-format checkpoint created from a public Hugging Face model.
• Runtime checkpoint: the checkpoint written after distributed training with a specific parallelism layout.

Megatron can reshard between layouts, but the surrounding storage and metadata still need to be clean. The 16-GPU public WikiText run proved fresh train/save/eval. Resume from a temporary node-local checkpoint layout still needs cleanup because it timed out after metadata load.

Glossary

Term	Meaning
CPT	Continued pretraining: next-token training on text data
SFT	Supervised fine-tuning: prompt/response style training
Smoke test	Short run to prove launch, distributed communication, forward/backward, checkpoint save, and basic stability
MoE	Mixture of Experts: model layers route tokens to selected expert networks
Checkpoint resharding	Loading/saving checkpoints across different tensor, pipeline, expert, or data-parallel layouts

Why Megatron For This Work

FSDP is useful for many dense-model and fine-tuning jobs. Megatron was the better target here because the goal was explicit topology control:

• TP: tensor parallelism, splitting dense tensor operations.
• PP: pipeline parallelism, splitting layers across stages.
• CP: context parallelism, splitting long sequence/context tokens.
• DP: data parallelism, replicating model groups across data batches.
• EP: expert parallelism, distributing MoE experts across GPUs.
• ETP: expert tensor parallelism, sharding weights inside each expert.
• EDP: expert data parallelism, replicating expert-parallel groups.
• SP: sequence parallelism, reducing activation memory inside TP groups.

For MoE and hybrid models, the bottleneck is not only parameter memory. It can be dense weights, routed experts, sequence length, optimizer state, checkpoint layout, or communication. Megatron exposes those axes directly.

Experiments Run

Model / Task	Run name	Config	Precision	Iters	Seq	Result
Public WikiText 5D continued pretraining	Public WikiText 5D	dense TP=2 PP=2 CP=2 DP=2, expert ETP=1 EP=4 EDP=2, PP=2	BF16 + TE + FlashAttention	20	-	passed train/save/eval on 16 GPUs
DeepSeek-V2-Lite import	deepseek_v2_lite_ep8_import	TP=1 PP=1 EP=8 ETP=1	import	-	-	passed
DeepSeek-V2-Lite continued pretraining	deepseek_v2_lite_ep8_bf16_smoke	TP=1 PP=1 EP=8 CP=1	BF16	4	512	passed
DeepSeek-V2-Lite continued pretraining	deepseek_v2_lite_ep8_fp8_smoke	TP=1 PP=1 EP=8 CP=1	FP8 delayed	4	512	passed
DeepSeek-V2-Lite continued pretraining	deepseek_v2_lite_tp2_ep4_sp_fp8_smoke	TP=2 PP=1 EP=4 CP=1 SP=on	FP8 delayed	2	512	passed
DeepSeek-V2-Lite continued pretraining	deepseek_v2_lite_tp4_ep2_sp_fp8_smoke	TP=4 PP=1 EP=2 CP=1 SP=on	FP8 delayed	2	512	passed
DeepSeek-V2-Lite continued pretraining	deepseek_v2_lite_tp2_pp2_ep2_uneven_sp_fp8_smoke	TP=2 PP=2 EP=2 CP=1 SP=on	FP8 delayed	2	512	passed
DeepSeek-V2-Lite supervised fine-tuning	sft_deepseek_v2_lite_ep8_smoke_20260701_retry1	TP=1 PP=1 EP=8 CP=1	BF16	2	512	passed
DeepSeek-V2-Lite supervised fine-tuning	sft_deepseek_v2_lite_tp2_pp2_ep2_uneven_sp_smoke_20260701	TP=2 PP=2 EP=2 CP=1 SP=on	BF16	2	512	passed
DeepSeek-V2-Lite continued pretraining	cpt_deepseek_v2_lite_tp2_pp2_ep2_uneven_sp_bf16_20260701	TP=2 PP=2 EP=2 CP=1 SP=on	BF16	2	512	passed
Custom MoE GPT continued pretraining	cpt_wikitext_tp2_cp2_ep4_edp2_smoke_20260701	dense TP=2 PP=1 CP=2 DP=2, expert ETP=1 EP=4 EDP=2	BF16	2	-	passed train/save/validation/test
Nemotron-3-Nano continued pretraining	nemotron_3_nano_ep8_bf16_smoke_20260701_retry2	TP=1 PP=1 EP=8 ETP=1 CP=1	BF16	2	512	passed
Nemotron-3-Nano continued pretraining	nemotron_3_nano_tp2_ep4_sp_bf16_smoke_20260701_retry1	TP=2 PP=1 EP=4 ETP=1 CP=1 SP=on	BF16	1	256	passed
Nemotron-3-Nano continued pretraining	nemotron_3_nano_pp2_ep4_bf16_smoke_20260701	TP=1 PP=2 EP=4 ETP=1 CP=1	BF16	1	256	passed
Nemotron-3-Nano continued pretraining	nemotron_3_nano_pp2_cp2_ep4_bf16_smoke_20260701	TP=1 PP=2 EP=4 ETP=1 CP=2	BF16	1	256	passed
Nemotron-3-Nano continued pretraining	nemotron_3_nano_pp2_ep2_etp2_bf16_smoke_20260701	TP=1 PP=2 EP=2 ETP=2 CP=1	BF16	1	256	passed

Runtime Observations From Training Logs

These are rank-0 memory observations from the training logs. They are not full performance benchmarks, but they show why different parallelism layouts mattered.

Model / Layout	Logged Rank-0 Memory	What It Showed
DeepSeek-V2-Lite EP=8 BF16	about 42.6-43.2 GB reserved	EP-only baseline fit comfortably on one 8-GPU node
DeepSeek-V2-Lite TP=2 PP=2 EP=2 SP BF16/FP8	about 37-41 GB reserved depending precision/config	uneven PP plus TP/EP gave better memory shape than the EP-only layout
Nemotron-3-Nano EP=8 BF16	about 82.9-85.9 GB reserved	the hybrid Mamba/MoE model fit, but used much more memory
Nemotron-3-Nano PP=2 EP=4 BF16	about 73.5 GB reserved	pipeline parallelism gave useful memory headroom
Nemotron-3-Nano TP=2 EP=4 SP BF16	about 98.7 GB reserved	this configuration worked but was too tight to treat as a comfortable production layout

The strongest practical lesson was that PP was not just a throughput knob. For the hybrid Nemotron model, PP=2 was a major memory tool. It made some layouts much more comfortable than pure TP+EP.

Model Notes And Learnings

Public WikiText 16-GPU 5D Run

• Dataset: Hugging Face Salesforce/wikitext, config wikitext-2-raw-v1.
• Tokenizer files: local Qwen3 tokenizer files from Qwen/Qwen3-30B-A3B.
• Nodes: 2.
• Total GPUs: 16.
• Dense dimensions: TP=2, PP=2, CP=2, DP=2.
• Expert dimensions: ETP=1, EP=4, EDP=2, with PP=2.
• Experts: 128 total, 32 local experts per EP shard.
• Control model: 4 layers, hidden size 256, FFN 512, 8 attention heads, 2 query groups.
• Precision/path: BF16, Transformer Engine, FlashAttention.
• Result:
  • trained iterations 1 through 20
  • saved checkpoints at iterations 10 and 20
  • ran validation/test
  • memory stayed small, under about 0.9 GB reserved on shown ranks
• Important caveat: fresh train/save/eval worked; resume from the node-local checkpoint layout hit a post-load NCCL timeout and remains unresolved.

DeepSeek-V2-Lite

• HF model: deepseek-ai/DeepSeek-V2-Lite
• Imported checkpoint: internal Megatron-format checkpoint created from the public Hugging Face snapshot.
• Snapshot/checkpoint size: about 30G
• Public scale:
  • Total parameters: 16B
  • Activated parameters per token: 2.4B
• Important fix: PP=2 needs uneven layer split because the model has 27 layers.
  • FIRST_PP_LAYERS=14
  • LAST_PP_LAYERS=13
• What this validated: checkpoint import, BF16, FP8 delayed scaling, expert parallelism, tensor parallelism, sequence parallelism, supervised fine-tuning flow, and continued-pretraining flow.

Nemotron-3-Nano

• Model/recipe: nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16
• Architecture: Mamba2-Transformer Hybrid Mixture of Experts.
• HF tokenizer/small files: local copy of the public Hugging Face model assets.
• Public scale:
  • Total parameters: 30B
  • Activated parameters per token: about 3B
• Mamba fast path was disabled because causal-conv1d was not installed.
• TP=2 needed UB_SKIPMC=1 due Transformer Engine CUDA multicast overlap.
• What this validated: Megatron training on a Mamba2-Transformer Hybrid MoE architecture across EP, TP, PP, CP, and ETP combinations.

DeepSeek-V4-Flash

• Target: deepseek-ai/DeepSeek-V4-Flash
• Probe checkpoint: internal Megatron-format development checkpoint.
• Result: reached distributed Megatron setup but did not fit full training on one 8x96 GB node.
• What this validated: launch, config construction, distributed setup, and MXFP8 path exploration before hitting the expected memory wall.

Issues Faced And Fixes

Area	Issue	Fix / Status
Optional imports	Bridge recipe imports pulled optional packages like diffusers, nvidia_resiliency_ext, megatron.energon	Used narrower recipe loading and small stubs where safe
Python helper build	Dataset helper could pick the wrong Python environment	Added launcher shim so helper builds use the intended virtual environment and pybind11 include
Checkpoint import	Needed HF to Megatron import before training	DeepSeek-V2-Lite import passed
Checkpoint resharding	Runtime TP/PP differed from imported checkpoint	Megatron resharding worked for passing DeepSeek-V2-Lite runs
Multinode dataset cache	GPTDataset cache files existed on one node but not the other	Staged dataset/tokenizer under identical absolute paths on both nodes and built local cache on each node
Multinode checkpoint resume	Fresh 16-GPU train/save/eval worked, but resume from temporary node-local checkpoint layout timed out after metadata load	Treat resume as unresolved; likely needs shared/synced persistent checkpoint view and clean tracker metadata
Pipeline layers	DeepSeek-V2-Lite has 27 layers	Used uneven PP: 14/13
Context parallelism	DeepSeek-V2-Lite CP=2 failed in MLA attention path	CP validated on custom MoE GPT and Nemotron; DeepSeek MLA remains blocked
Mamba fast path	Missing causal-conv1d	Disabled memory-efficient Mamba path; fallback worked
TE TP overlap	CUDA multicast unsupported for Nemotron TP run	UB_SKIPMC=1 fixed it
Memory	DeepSeek-V4-Flash full training did not fit one node	Needs more GPUs, more parallelism, PEFT/freezing, or smaller model
Memory	Nemotron TP=2 EP=4 was tight	Passed, but not a comfortable production config

What Was Proven

Axis	Status
TP	Proven on DeepSeek-V2-Lite and Nemotron-3-Nano
PP	Proven on DeepSeek-V2-Lite and Nemotron-3-Nano
CP	Proven on 16-GPU public WikiText, custom MoE GPT, and Nemotron-3-Nano
DP	Proven explicitly in the 16-GPU public WikiText run and custom MoE GPT
EP	Proven across 16-GPU public WikiText, DeepSeek-V2-Lite, custom MoE GPT, and Nemotron-3-Nano
ETP	Proven on Nemotron-3-Nano
EDP	Proven on 16-GPU public WikiText and custom MoE GPT
SP	Proven on TP configs

Takeaways

Megatron is valuable because it makes training topology explicit. The work moved from "can I launch a model?" to "can I control how a large model is split, trained, checkpointed, and debugged?"

The main practical lessons:

• Megatron-Bridge conversion and checkpoint layout are part of the training system.
• A distributed training proof should include checkpoint save, not only forward/backward.
• MoE models need separate reasoning about dense weights, routed experts, expert routing, and optimizer state.
• Context parallelism is model-path dependent; it can work in one architecture and fail in another backend path.
• Pipeline parallelism is not only for throughput. It can be the cleanest way to create memory headroom.
• Short smoke runs are useful when they validate the full infrastructure path and expose the next bottleneck.