LLMs schalen met Multi-GPU- en Multi-Node-parallelisme

Viacheslav Dubrov

2025-05-04 · Bijgewerkt 2026-07-15 · 9 min · Modelengineering · AI-infrastructuur

Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Workloads met grote modellen gaan om verschillende redenen verder dan één GPU. Een training job kan zonder geheugen komen voor optimizer state. Een andere kan tegen de limiet aanlopen door activations bij lange sequences. Een model dat wel past, haalt mogelijk nog steeds de throughput-doelstelling niet. Elk probleem vereist een andere partitionering en een ander communicatiepatroon.

Dit is een praktische rondleiding langs de belangrijkste parallelismestrategieën en de onderliggende beperkingen, gebaseerd op de Ultra-Scale Playbook van Hugging Face. Het doel is te laten zien wat elke verdeling oplevert, welke communicatie ervoor nodig is en wanneer combinaties noodzakelijk worden.

TL;DR. Replicated data parallelism verhoogt de training throughput wanneer één replica past. Fully sharded data parallelism partitioneert model state, maar voegt parameter all-gathers en gradient reduce-scatters toe. Tensor-, pipeline-, context- en expert-parallelisme verdelen respectievelijk layer-math, depth, sequence en mixture-of-experts (MoE)-layers. Combineer ze pas nadat je hebt vastgesteld welke memory- of communication-constraint bepalend is.

Deze guide gaat ervan uit dat je vertrouwd bent met backpropagation, Transformer-layers en een standaard PyTorch training loop.

Begin met twee memory budgets

Training en inference hebben niet dezelfde footprint.

training peak ≈ parameters
              + gradients
              + optimizer state
              + saved activations
              + temporary buffers
              + communication buffers
              + allocator headroom

inference peak ≈ resident weights
               + key/value (KV) cache
               + runtime workspace
               + communication buffers
               + allocator headroom

Een model met 70 miljard parameters heeft alleen al voor BF16 weights een decimale ondergrens van 140 GB. Dat zegt weinig over training, waarbij gradients, optimizer state, master weights en activations de footprint kunnen domineren. Ook voor serving is dit geen volledige sizing: daar zijn cache policy, sequence length, batch concurrency en quantization bepalend.

Profile de exacte architecture, precision, sequence length, micro-batch, optimizer, checkpointing policy en runtime. Leg peak allocated en reserved memory, tokens per second, tijd in kernels en tijd die zichtbaar is in collectives vast.

Elke parallelismedimensie brengt een trade-off met zich mee

Stel voor elke strategie de volgende vragen: welke tensor-dimensie wordt gesplitst, welke state wordt gerepliceerd en welke collective komt op het kritieke pad?

Memory relief is geen vaste multiplier. Dit hangt af van de sharding degree, wat gerepliceerd blijft, tijdelijke unsharded state, activation policy, padding, imbalance en buffers.

Replicated data parallelism: throughput zonder extra capacity

Replicated data parallelism, meestal distributed data parallel genoemd, houdt op elke rank een volledige training replica aan. De DistributedDataParallel-documentatie van PyTorch beschrijft dit replica- en gradient-synchronisatiemodel. Elke rank verwerkt een andere micro-batch en gradients worden gesynchroniseerd vóór de optimizer step.

Gebruik dit wanneer de volledige training state met voldoende headroom past en de global batch kan groeien of gradient accumulation kan worden aangepast. De belangrijkste voordelen zijn eenvoudige semantics en een volwassen implementatie die backward computation overlapt met bucketed gradient reduction.

Extra ranks kunnen nadelig zijn wanneer de local batch te klein wordt. Dat geldt ook wanneer het netwerk de all-reduce niet kan verbergen of input delivery stagneert. De gewenste optimization batch schaalt mogelijk niet mee.

Fully sharded data parallelism: state memory in ruil voor collectives

Fully sharded data parallelism slaat shards van parameters, gradients en optimizer state op over een group. Het ZeRO-paper beschrijft dit state-shardingpatroon en de FSDP2 API van PyTorch implementeert het. De parameters van een layer worden voor de computation ge-all-gatherd en kunnen daarna opnieuw worden geshard. Gradients worden via reduce-scatter teruggestuurd naar de owners.

De huidige PyTorch-documentatie onderscheidt de fully_shard API in fully sharded data parallelism version 2 (FSDP2) van de oudere FullyShardedDataParallel-wrapper. FSDP2 groepeert communicatie op basis van de modules waarop fully_shard wordt toegepast en adviseert bottom-up application, zodat layer groups communicatie en computation kunnen overlappen.

from torch.distributed.fsdp import fully_shard
from torch.optim import AdamW

# Apply bottom-up: each block becomes a communication group.
for block in model.transformer.blocks:
    fully_shard(block)

# Shard remaining root parameters such as embeddings and output projection.
fully_shard(model)

# Construct the optimizer after parameters have become sharded distributed tensors (DTensors).
optimizer = AdamW(model.parameters(), lr=learning_rate)

Dit is een structurele schets, geen complete launcher. Device meshes, mixed precision, checkpointing, initialization, optimizer state en distributed checkpoints moeten aansluiten op de training stack.

Sharding is aantrekkelijk wanneer model state de bepalende constraint is en layer computation voldoende collective traffic kan verbergen. Het kan een slechte trade-off zijn voor kleine modellen, trage links, kleine layers of layouts waarbij de shard group een ongeschikte topology boundary overschrijdt.

Tensor parallelism: partitioneer de layer-math

Tensor parallelism partitioneert linear algebra binnen een layer. Voorbeelden zijn column-parallel en row-parallel projections. De parallelism guide van NVIDIA documenteert deze layer-level split. Partiële resultaten vereisen collectives binnen Transformer-blocks, waardoor latency en bandwidth herhaaldelijk van belang zijn tijdens de forward- en backward-pass.

Gebruik dit wanneer een layer of de bijbehorende activations niet past, of wanneer de matmuls groot genoeg zijn om partitioned kernels sneller te laten zijn dan één rank. Plaats de tensor-parallel group in het snelste beschikbare communication domain en meet vervolgens. Een hoge tensor-parallel degree kan elke local matrix zo klein maken dat de kernel efficiency daalt terwijl de collective overhead toeneemt.

Sequence parallelism wordt vaak gecombineerd met tensor parallelism om replicatie van bepaalde activation-work te voorkomen. Dit is iets anders dan context parallelism over de volledige input sequence van het model.

Pipeline parallelism: partitioneer depth en schedule-tijd

Pipeline parallelism plaatst verschillende groepen layers op verschillende stages en stuurt activations daartussen. Micro-batches houden de stages gelijktijdig actief. Het GPipe-paper gebruikt deze schedule voor zeer grote neural networks.

Het vermindert de model state per stage en kan de hoeveelheid communicatie over een tragere boundary verlagen ten opzichte van per-layer tensor collectives. De kosten zijn bubbles, activation transfers, stage imbalance, complexere scheduling en moeilijker recovery en checkpointing.

Voor een eenvoudige gebalanceerde GPipe-style schedule met p stages en m micro-batches is de geïdealiseerde forward bubble fraction ongeveer:

(p - 1) / (m + p - 1)

Real schedules kunnen one-forward/one-backward-, interleaving- of zero-bubble-varianten gebruiken, en ongelijke layer costs kunnen de formule domineren. Kies stage boundaries op basis van gemeten tijd en memory, niet op basis van gelijke aantallen layers.

Context parallelism: partitioneer activations bij lange sequences

Context parallelism verdeelt de sequence-dimensie. De context-parallelismdocumentatie van NVIDIA beschrijft de sequence split en de key/value-exchange die voor attention nodig is. Elke rank beheert een sequence shard, terwijl attention de benodigde informatie uitwisselt om de semantics van de volledige context te behouden. Implementaties kunnen point-to-point rings, all-gather, all-to-all of hiërarchische combinaties gebruiken.

Dit reduceert activation memory voor training met lange context, maar repliceert weights binnen de context group en introduceert attention communication. Het voordeel hangt af van het attention type, causal masking, sequence length, recomputation en de manier waarop context groups worden gecombineerd met tensor- en data-parallel groups.

Selecteer dit niet op basis van een universele drempel van 8K, 32K of 100K. Profile activation memory en attention communication voor de daadwerkelijke architecture.

Expert parallelism: alleen voor een MoE-architecture

Expert parallelism verdeelt experts in mixture-of-experts-layers. De parallelism guide van NVIDIA documenteert deze expert placement en de combinatie met andere parallelismedimensies. De router stuurt token representations naar geselecteerde experts en combineert hun resultaten. Per token rekenen alleen de geselecteerde experts, maar de totale expert weights vereisen nog steeds storage en serving placement.

Expert parallelism is geen optimization switch voor een dense model. Het maakt deel uit van een MoE-architecture. Aandachtspunten zijn load balance, capacity limits, token all-to-all, dropped of padded tokens, auxiliary losses en failure skew. Track tokens per expert, routing entropy, capacity overflow, communication time en quality per route.

Stel een layout samen op basis van de topology

Training systems voor grote dense models zonder expert-parallel group gebruiken vaak een product van de groottes van de data-parallel (DP)-, tensor-parallel (TP)-, pipeline-parallel (PP)- en context-parallel (CP)-groups:

world size = DP × TP × PP × CP

Wanneer expert parallelism (EP) een onafhankelijke group is, berekent de parallelism guide van NVIDIA het totaal als:

total GPUs = TP × PP × CP × EP × DP

Gebruik de door het framework ondersteunde mesh in plaats van niet-ondersteunde configuraties met elkaar te vermenigvuldigen.

Bouw de layout in deze volgorde op:

1. Breng communication domains in kaart: GPU-to-GPU-links, switches, non-uniform memory access (NUMA)-boundaries, node fabric, oversubscription en storage path.
2. Plaats frequente latency-sensitive collectives, meestal TP, in het snelste geschikte domain.
3. Kies FSDP- of replicated DP-groups op basis van resterende capacity en bandwidth.
4. Voeg PP toe wanneer placement op basis van depth of verkeer over domains voordelen biedt; balanceer gemeten stage time en memory.
5. Voeg CP alleen toe vanwege de sequence constraint en expert parallelism (EP) alleen voor de expert topology van het model.
6. Controleer de divisibility van heads, hidden dimensions, layers, experts, batch en sequence voor de kandidaat-mesh.
7. Benchmark meerdere geldige meshes. Topology-aware heuristics selecteren kandidaten, geen winnaars.

Twee clusters met hetzelfde aantal GPUs kunnen verschillende layouts prefereren, omdat link bandwidth, switch hierarchy, CPU attachment en network contention verschillen.

Training en serving vereisen afzonderlijke beslissingen

Inference gebruikt doorgaans geen gradients of optimizer state, waardoor FSDP-style training layouts niet automatisch overdraagbaar zijn.

Stel voor serving de volgende vragen:

• Past één replica met weights, KV cache, workspace en de beoogde concurrency?
• Is throughput beter gebaat bij meer onafhankelijke replicas of bij het sharden van één replica?
• Reduceert TP de druk op weights en cache per rank voldoende om de communicatie per layer te compenseren?
• Wordt PP efficiënt ondersteund voor het model en de request scheduler?
• Hoe belasten prefill en decode computation, memory bandwidth en interconnect op verschillende manieren?
• Wat gebeurt er met tail latency wanneer requests verschillende prompt- en outputlengtes hebben?

Benchmark de complete server met de scheduler, quantization, context distribution, batching policy en traffic shape. Training tokens per second kunnen serving time to first token of inter-token latency niet voorspellen.

Meet een scaling-layout eerlijk

Leg voor elke kandidaat het volgende vast:

• model-, code-, runtime-, kernel- en topology-identiteit
• global en local batch, sequence distribution en token count
• peak memory per categorie, waar beschikbaar
• useful tokens per second en model floating-point operation (FLOP) utilization wanneer deze consistent wordt berekend
• blootgestelde tijd in all-reduce-, all-gather-, reduce-scatter-, all-to-all- en point-to-point-operaties
• input stalls, checkpoint time, restart behavior en de verdeling van stragglers
• training loss of parity van serving outputs ten opzichte van de baseline

Vergelijk weak en strong scaling bewust. Strong scaling houdt het totale werk constant terwijl het aantal ranks toeneemt. Weak scaling houdt het werk per rank constant, waardoor het totale werk toeneemt met het aantal ranks. Een percentage met het label “scaling efficiency” is betekenisloos zonder die denominator en baseline.

Conclusie

Parallelism is een mapping van een gemeten bottleneck naar een tensor-dimensie en een communicatiepatroon. Replication, sharding, layer partitioning, staging, sequence partitioning en expert routing verlichten elk een andere constraint en veroorzaken elk een andere failure mode.

Breng de workload en topology in kaart, genereer geldige meshes en profile ze. De winnende layout is de layout die met voldoende headroom past en de exposed communication voor de job die je daadwerkelijk draait minimaliseert.

Referenties

• PyTorch FSDP2 fully_shard-documentatie - Sharding van parameters op moduleniveau, all-gathers, reduce-scatters en DTensor-gedrag.
• PyTorch DistributedDataParallel-documentatie - Training van gerepliceerde modellen met gesynchroniseerde gradients.
• NVIDIA Megatron Core parallelism strategies - Data-, tensor-, pipeline-, context-, expert- en fully sharded-strategiedimensies.
• Hugging Face Ultra-Scale Playbook - Interactief overzicht van grootschalige model parallelism.
• DeepSpeed ZeRO-paper - Sharding van optimizer states, gradients en parameters om memorygebruik te verminderen.
• GPipe-paper - Pipeline training met micro-batches en staged execution.
• NERSC parallelism-documentatie - Definities van strong en weak scaling op basis van vast totaal werk of vast werk per rank.