Systems / Distributed
verifiedData Parallelism
The simplest way to use many accelerators is to put a full copy of the model on each, give each a different slice of the batch, and average the gradients before stepping. Every copy stays identical, so the result is one large-batch update computed in parallel.
An all-reduce of the gradients every step. It scales until the communication stops overlapping with computation, or until the effective batch passes the point where more examples stop helping. It also requires the whole model and its optimizer state to fit on one device, which is the constraint sharding exists to remove.
Each of N workers computes ∇L sub B sub i over |B|/N examples; an all-reduce produces the mean. Communication per step is Θ(P) for P parameters regardless of N with ring all-reduce, so the cost is bandwidth-bound rather than worker-count-bound.
workers holds 50% of the budget; rest holds the remaining 50%.
Share of step time spent communicating gradients against computing them. Drag the worker count to watch communication grow into the bottleneck.
Reviewed by opendroid · 2026-08-04
- arXiv:2006.15704 — PyTorch Distributed: Experiences on Accelerating Data Parallel Training