Training at Scale

Layer 1 · Intuition

Training at Scale

Why a 70B-parameter model can't be trained on one GPU, and the four different ways of cutting the job into pieces that fit.

7 min read40 XP

Listen to this lesson

Podcast-style walkthrough · ~7 min

No recording yet · generated on first play

H100 memory

80 GB

70B model, bf16 weights

140 GB

+ gradients (bf16)

140 GB

+ Adam states (fp32)

560 GB

One copy of a 70B model to train, not just run, needs ~840 GB. No single GPU is close.

Inference is memory-light: you need the weights and a KV cache. Training is memory-heavy: you need the weights, the gradients, and the optimizer's running statistics — for Adam, two extra copies of every parameter in fp32. That arithmetic alone rules out a single accelerator for any model bigger than a few billion parameters, long before you even ask how long training would take on one chip.

Distributed training is the set of techniques for splitting a training job — the data, the model, or both — across many accelerators that communicate over a network. There isn't one way to split it; there are four orthogonal axes, and real large-model training runs combine several of them at once.

Split the data

  • Every GPU holds a full copy of the model
  • Each processes a different batch slice
  • Gradients are averaged across GPUs
  • Called data parallelism / DDP

Split the model

  • No single GPU holds the whole model
  • Layers, tensors, or sequences are sharded
  • Activations/results must be exchanged
  • Called tensor / pipeline / sequence parallelism
Data parallelism scales throughput; model parallelism scales what fits in memory at all.
Each replica trains on its own data shard, then gradients are synchronized before the next step.

The four axes, at a glance

  • Data parallel (DP/DDP) — replicate the whole model on every GPU; split the batch. Simple, scales throughput, but every GPU must still fit the whole model.
  • ZeRO / FSDP — data parallel, but shard the *optimizer states, gradients, and even weights* across GPUs instead of replicating them. Same math, dramatically less memory per GPU.
  • Tensor parallel (TP) — split individual weight matrices across GPUs, so a single matmul runs as a set of smaller matmuls that exchange partial results. Needed when even one layer doesn't fit.
  • Pipeline parallel (PP) — put different *layers* on different GPUs, and stream micro-batches through the resulting assembly line.

Why this isn't just 'buy more GPUs'

GPUs that never talk to each other don't help: if replica A finishes its gradient and replica B is still computing, A either waits or drifts out of sync. The entire discipline of distributed training is about designing the split so that (a) everything needed fits in memory and (b) the unavoidable communication overlaps with computation instead of blocking it. A cluster of 10,000 GPUs badly configured can train slower, per dollar, than 1,000 well-configured ones.

  1. Fits on 1 GPU

    Just train

    no distribution needed

  2. Fits on 1 node (8 GPUs)

    Data parallel / ZeRO

    NVLink is fast enough

  3. Needs many nodes

    + Tensor + Pipeline parallel

    3D parallelism

  4. Frontier scale

    + Sequence/context parallel

    long-context, thousands of GPUs

Which techniques you need is a direct function of how far the model overflows a single GPU.

The rest of this star works through each axis mechanically, then implements a real FSDP training loop, then derives the memory and communication math that explains *why* the industry converged on this particular toolbox.

Check your understanding

4 questions · answer all to submit

  1. 1.Why does training a model require dramatically more memory per GPU than serving it for inference?

  2. 2.What is the core difference between data parallelism and model parallelism (tensor or pipeline)?

  3. 3.Why does a well-designed 1,000-GPU cluster sometimes outperform a poorly configured 10,000-GPU cluster on the same job?

  4. 4.At the scale of a multi-week run on thousands of GPUs, how should hardware failure be treated?