Unit 8 · AI infrastructure · Lesson 3 of 10
Data, tensor and pipeline parallelism and collectives
Builds on
Step 1: Learn the ideas
- Collectives: all-reduce, all-gather, reduce-scatter, broadcast; ring versus tree algorithms
- Data parallelism with gradient all-reduce, DDP buckets and overlap with backward
- ZeRO stages and FSDP: sharding optimizer state, gradients and parameters
- Tensor (intra-layer) parallelism for attention and MLP blocks
- Pipeline (inter-layer) parallelism: micro-batches, bubbles, one-forward-one-backward and interleaved schedules
- Topology: NVLink/NVSwitch inside a node versus InfiniBand or Ethernet across nodes
- Synchronization, stragglers and per-rank load balance
- Combining dimensions; sequence/context and expert parallelism at awareness level
Why it matters
When a model or its batch no longer fits on one GPU, or one GPU is too slow, the work must be split. The split fixes per-GPU memory, how much data crosses which links, and how long devices sit idle. Interviewers expect you to choose a layout from memory and communication arithmetic and to explain what goes wrong at scale: stragglers, bubbles and unhidden communication.
Core ideas
Collectives. All-reduce leaves every rank with the sum of all inputs; reduce-scatter leaves each rank with the sum of one shard; all-gather leaves every rank with all shards; all-reduce equals reduce-scatter followed by all-gather. In ring all-reduce over n ranks on S bytes, each rank sends and receives about 2(n−1)/n × S bytes, nearly independent of n, so it is bandwidth-optimal; but it takes 2(n−1) sequential steps, so latency grows with n. Tree and hierarchical algorithms cut latency-bound steps for small messages and many ranks; NCCL picks algorithms by message size and topology. Benchmarks report bus bandwidth, which rescales by 2(n−1)/n so the number is comparable to link bandwidth.
Data parallelism. Each rank holds a full replica, processes different data, and averages gradients with all-reduce before the optimizer step. PyTorch DDP groups gradients into buckets and starts a bucket's all-reduce as soon as its gradients are ready, overlapping communication with the rest of backward. Per-GPU memory does not shrink, and communication per step is proportional to model size, independent of batch size.
Sharded data parallelism (ZeRO, FSDP). Remove replicated model states: stage 1 shards optimizer state, stage 2 also gradients (reduce-scatter replaces all-reduce), stage 3 or full sharding as in FSDP also parameters, which are all-gathered layer by layer just before use in forward and backward and freed afterwards. Per-GPU model state drops roughly by the data-parallel degree. The ZeRO analysis shows stages 1 and 2 move about the same volume as plain data parallelism, while sharding parameters adds about half again because they are gathered in both passes.
Tensor parallelism. Split individual weight matrices. In a Megatron-style MLP the first linear layer is split by columns and the second by rows, so each block needs one all-reduce in forward and one in backward; attention is split by heads. These collectives sit inside every layer on the critical path, so tensor parallelism normally stays within a node on NVLink or NVSwitch.
Pipeline parallelism. Assign consecutive layers to stages on different devices and split the batch into m micro-batches. With p stages, a simple schedule leaves each device idle for about p − 1 micro-batch slots out of m + p − 1, so the bubble shrinks as m grows relative to p. One-forward-one-backward schedules keep that bubble but bound in-flight activations to about p micro-batches; interleaved schedules shrink the bubble further at the cost of more communication. Stages exchange only boundary activations, so pipelines can span nodes, but stages must be balanced.
Topology and layout. Bandwidth inside a node is much higher than across nodes. A common layout puts tensor parallelism inside a node, pipeline stages across nodes, and data parallelism or FSDP outermost. Sequence/context parallelism and expert parallelism add dimensions for long contexts and mixture-of-experts models.
Stragglers. Synchronous training waits for the slowest rank at every collective. A slow data loader, thermal throttling, a degraded link or an unbalanced stage stretches every step for everyone. Compare per-rank step times and time spent waiting inside collectives before tuning anything else.
Common misconceptions
- "Data parallelism reduces per-GPU memory." Plain DDP replicates full model states; only sharding or model parallelism reduces them.
- "Ring all-reduce sends more data per GPU as GPUs are added." Per-GPU volume stays near 2S; the step count and exposure to the slowest link grow.
- "FSDP is model parallelism." It is data parallelism with sharded storage; each rank still computes whole layers on its own data after gathering parameters.
- "Pipeline parallelism is free with enough layers." Bubbles, stage imbalance and stored activations cost throughput and memory, and it needs many micro-batches.
- "Tensor parallelism scales across nodes like data parallelism." Its per-layer collectives on the critical path make slow inter-node links the bottleneck.
How to approach it
Answer layout questions in a fixed order: memory per GPU for each option, communication volume per step and on which links, idle time (bubbles, waiting), then operational concerns such as checkpointing and failures. At graduate level, explain DDP and the collectives precisely. At mid level, compute ZeRO memory and the pipeline bubble. At senior level, design a layout for a given cluster and say how you would verify it with collective benchmarks and traces.
Suggested order
- 1Read the NCCL collective operations page and draw inputs and outputs of all-reduce, reduce-scatter and all-gather for four ranks.
- 2Derive ring all-reduce traffic per rank, then read the nccl-tests performance note on algorithm versus bus bandwidth.
- 3Work through the PyTorch DDP tutorial with several processes (the gloo backend on CPU is enough to learn the API).
- 4Read the data-parallel and ZeRO sections of the Ultra-Scale Playbook and the FSDP2 tutorial, and write per-GPU memory for DDP and each ZeRO stage.
- 5Read the tensor- and pipeline-parallelism sections of the Ultra-Scale Playbook, then the bubble analysis and interleaved schedule in the Megatron-LM cluster-training paper.
- 6Design a layout for a model and cluster you choose (GPUs per node, link types) and justify each dimension in writing.
Step 2: Check off what you can do
Tap each one you can genuinely do or explain. Each earns 10 XP.
Step 3: Go deeper
PyTorch: Getting Started with Distributed Data ParallelStart here
PyTorch tutorialsHands-on data parallelism: process groups, one process per device and gradient all-reduce during backward.
Open(opens in a new tab)Link responded, 5 Oct 2026The Ultra-Scale Playbook: Training LLMs on GPU ClustersStart here
Hugging Face (nanotron team)One coherent walkthrough of data, ZeRO, tensor, sequence/context and pipeline parallelism with memory and communication reasoning.
Open(opens in a new tab)Link responded, 5 Oct 2026PyTorch: Getting Started with Fully Sharded Data Parallel (FSDP2)
PyTorch tutorialsSharded data parallelism in practice: all-gather before use, reshard after use, reduce-scatter of gradients and prefetching.
Open(opens in a new tab)Link responded, 5 Oct 2026Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM
arXivPipeline bubble analysis, interleaved schedules and how tensor, pipeline and data parallelism compose on a real cluster.
Open(opens in a new tab)Link responded, 5 Oct 2026NCCL User Guide: Collective Operations
NVIDIA DocumentationExact semantics of collectives and how to read collective bandwidth benchmarks.
Open(opens in a new tab)Link responded, 5 Oct 2026
Step 4: Practice
Implement data-parallel training in the CS336 systems assignment or from the DDP tutorial, then compare step time for one, two and (if available) more GPUs. Measure all-reduce bus bandwidth with nccl-tests, use it to predict DDP communication time per step, and check the prediction in a profiler trace. Without multi-GPU hardware, do the arithmetic (ZeRO memory per stage, pipeline bubble for several stage and micro-batch counts) and run the code on CPU processes to learn the APIs.
- Stanford CS336 assignments (tokenizer and transformer, systems, scaling, data, alignment)Open(opens in a new tab)Not attemptedStanford CS336
- Data-parallel scaling and collective bandwidth measurementsOpen(opens in a new tab)Not attemptedSelf-directed (nccl-tests, PyTorch DDP and FSDP)
- Profile a training step and attribute its timeOpen(opens in a new tab)Not attemptedSelf-directed (PyTorch profiler)
Record attempts on each problem’s page (+15 XP, +10 more when solved on your own).
Step 5: Test yourself
Answer each one out loud or on paper before you finish the lesson.
- Question 1Why is all-reduce equivalent to reduce-scatter followed by all-gather, and why does that matter for ZeRO?
- Question 2What does DDP overlap with the backward pass, and what limits that overlap?
- Question 3Why does sharding parameters add communication compared with ZeRO stage 2?
- Question 4Why is tensor parallelism usually confined to one node?
- Question 5How does the number of micro-batches affect the pipeline bubble and activation memory?
- Question 6A job scales well to 8 GPUs and poorly to 64. What would you measure first?
You’re done when you can
- Derive per-rank traffic for ring all-reduce and explain why it is bandwidth-optimal but latency-sensitive.
- Compute per-GPU model-state memory under DDP and ZeRO stages 1 to 3 for a model size and data-parallel degree you choose.
- Compute the pipeline bubble for given stage and micro-batch counts and name two ways to reduce its cost.
- Propose and justify a tensor, pipeline and data-parallel layout for a stated cluster topology.
- Run a multi-process DDP script and point to where gradient communication happens in its timeline.


