Data Parallelism › Scaling Behaviour
Language AI HandbookAll chapters Data Parallelism › Scaling BehaviourOne section · Sections in this chapter7 / 12 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
Understanding how DDP scales is essential for planning distributed training runs. Ideal scaling and real-world scaling differ in important ways, and knowing these differences prevents unpleasant surprises when you provision hardware.
Ideal Linear Scaling
In the ideal case, adding GPUs gives you an -fold speedup. With batch size per GPU, each training step processes total samples. Since one step on GPUs takes the same wall-clock time as one step on 1 GPU (assuming communication is free), you process times as many samples per unit time. Training runs times faster.
This ideal scaling holds when:
- Communication time is negligible compared to compute time
- The workload divides evenly among GPUs (no load imbalance)
- All GPUs complete their local computation at the same time (no stragglers)
- Data loading keeps up with GPU throughput
For large models with many parameters, condition 1 often approximately holds because compute time scales with model size while communication volume also scales with model size but at a lower constant factor (ring all-reduce transfers only bytes per rank regardless of ). A 7B model has 14 GB of BF16 gradients but requires several hundred milliseconds of compute per step, so the communication-to-compute ratio can be small on fast interconnects.
Amdahl's Law and Communication Overhead
In practice, some fraction of each training step is inherently serial or requires synchronization. Amdahl's Law captures this fundamental limit: if fraction of the work can be parallelized and fraction is serial, the maximum speedup from processors is:
where:
- is the speedup with GPUs relative to 1 GPU
- is the fraction of total time that scales with more GPUs (the parallelizable part)
- is the serial fraction (overhead from synchronization, data loading, communication, and other fixed costs)
As , the speedup approaches . Even with a serial fraction of just 5%, the maximum possible speedup is 20x regardless of how many GPUs you add. At 10% serial fraction, the ceiling drops to 10x. These limits are strict: no amount of engineering can overcome them without reducing the serial fraction.
For DDP, the main non-parallelizable overhead is the all-reduce communication that cannot be fully overlapped with compute. The communication time for ring all-reduce is approximately:
where:
- is the gradient tensor size in bytes
- is the available link bandwidth per GPU in bytes per second (this is bidirectional bandwidth; NCCL can use both send and receive channels simultaneously)
- The factor approaches 2 as grows large (both reduce-scatter and all-gather phases each transfer approximately bytes per rank)
This communication time is independent of for large , because ring all-reduce is bandwidth-optimal. The implication is that DDP scales very well within a single node (NVLink bandwidth is high, so communication is fast) but scales less well across nodes (InfiniBand bandwidth is lower). Each additional node adds another cross-node communication hop, and if the cross-node bandwidth is already saturated, scaling efficiency degrades.
The Linear Scaling Rule
When scaling DDP to more GPUs, you should also scale the global learning rate. The standard practice, established by Goyal et al. (2017) in their ImageNet training paper and confirmed for language models by many subsequent works, is the linear scaling rule:
where:
- is the learning rate for 1-GPU training with local batch size
- is the learning rate for -GPU training with global batch size
The intuition is this: with times as many samples per update step, each gradient estimate is times less noisy (by the central limit theorem, the variance of a mean over samples is times the variance of a single sample). Lower gradient noise means each update step is more reliable, so you can afford to take times larger steps. Taking larger steps means you cover the same loss landscape in fewer steps, maintaining equivalent training dynamics.
The linear scaling rule works well for batch sizes up to a few thousand examples. For very large batch sizes (beyond 8,000 to 16,000 for typical language model training), learning rate scaling alone is insufficient. At these scales, the gradient noise is so low that each update consumes nearly all of the useful curvature information available in the loss landscape in a single step, and you enter the "large batch regime" where additional batch size no longer reduces the number of steps needed proportionally. Research by McCandlish et al. (2018) on the "critical batch size" formalized this regime.
Learning rate warmup is also essential when scaling to large batch sizes. Rather than jumping immediately to the scaled learning rate , you linearly increase the learning rate from a small initial value (or zero) to over the first few thousand training steps. This warmup period prevents instability at the start of training when the optimizer's first and second moment estimates (in Adam/AdamW) have not yet converged and the model is far from any sensible initialization.