2025-05-04 · Bijgewerkt 2026-07-15

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Schalen van grote taalmodellen Models: Meerdere GPU- en meerdere-nodestrategieën die in de praktijk standhouden

Grote model werklasten gaan om verschillende redenen verder dan één GPU. Een trainingsopdracht kan op raken door de grootte van de optimizer-state, een andere door lange sequenties activations, en zelfs een model die past, kan nog steeds zijn throughput doel niet bereiken. Elk probleem vereist een andere manier van partitioneren en communiceren.

Dit is een praktische uitleg van de belangrijkste strategieën voor parallelisme en de beperkingen die eraan ten grondslag liggen, gebaseerd op de inzichten van Hugging Face. Playbook voor ultra-schaaloplossingen. Het doel is om aan te tonen wat elke splitsing oplevert, wat deze overbrengt, en wanneer combinaties noodzakelijk worden.

Kort samengevat. Gerepliceerde data-paralleliteit zorgt voor training van throughput wanneer één replica voldoende is. Volledig gesharde data-paralleliteit verdeelt de model-toestand, maar vereist daarnaast operationen als parameter-all-gather en gradient-reduce-scatter. Tensor-, pipeline-, context- en expert-paralleliteit verdelen de wiskundige berekeningen per laag, de diepte, de sequenties en de MoE-experts. Combineer deze benaderingen pas nadat de beperkingen met betrekking tot geheugengebruik of communicatie zijn vastgesteld.

Deze handleiding gaat ervan uit dat u vertrouwd bent met backpropagatie, Transformer-lagen en een standaard PyTorch trainingscyclus.

Begin met twee geheugenbudgetten

Training en inference hebben niet dezelfde resourceverbruik.

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

inference peak ≈ resident weights
               + KV cache
               + runtime workspace
               + communication buffers
               + allocator headroom

Een model met 70 miljard parameters en model heeft al alleen voor de BF16 weights een decimaal lager minimum van 140 GB. Dit getal zegt weinig over het trainingsproces, waar gradienten, de staat van de optimizer, de master weights en activations een dominante rol kunnen spelen. Het geeft evenmin een indicatie van de omvang van serving, waar cachebeleid, sequentielengte, batch-concurrentie en quantization belangrijk zijn.

Profiel de exacte architectuur, nauwkeurigheid, sequentielengte, micro-batches, optimizer, beleid voor checkpointing, en runtime. Noteer het maximale toegewezen en gereserveerde geheugen, tokens per seconde, de tijd die verloopt in kernels, en de tijd die wordt blootgesteld binnen collectieve omgevingen.

Distributieve schaling begint met een gedetailleerde evaluatie van bottleneck

Elke parallelle dimensie brengt een compromis met zich mee

De relevante vraag is niet “Welke techniek is het beste?” maar “Welke dimensie van de tensor wordt opgesplitst, welke toestand wordt gerepliceerd, en welk collectief komt op de kritische pad te staan?”

Strategie	Splitsen	Primair ontlasten	Gecreëerde communicatiekanalen
Gerepliceerde dataparalleliteit	batch	training throughput	gradient all-reduce
Volledig geschaard data-parallelisme	parameters, gradients en de toestand van de optimizer binnen een DP-groep	model – toestandsgeheugen	parameter all-gather, gradient reduce-scatter
Tensorparalleliteit	matrix of attention-dimensies binnen lagen	laag weights en activations	collectieven binnen transformer-blokken
Pipeline paralleliteit	laaggroepen	model diepte en staat per fase	punt-naar-punt activations in combinatie met planningbellen
Contextueel parallelisme	sequentiedimensie	langere-sequentie activation geheugen	uitwisseling van key/value of attention binnen de sequentiegroep
Expertparallelisme	MoE experts en gerouteerde processen tokens	Expertcapaciteit per rang	token dispatchen en combineren, meestal op een all-to-all-manier

Het verlichten van het geheugengebruik is geen vaste vermenigvuldiger. Het hangt af van de graden van sharding, wat nog wordt gerepliceerd, de tijdelijke, niet-gesharded toestand, de activation-policy, de padding, de onevenwichtigheden en de buffers.

Gerepliceerde dataparalleliteit: throughput zonder capaciteit

Geparallele training met gerepliceerde gegevens

Distributed data parallelism zorgt ervoor dat er op elke node een volledige trainingssnapshot wordt bewaard. Elke node verwerkt een andere micro-batch, en de gradients worden gesynchroniseerd voordat de optimizer wordt gebruikt.

Gebruik het wanneer de volledige trainingsstate past met voldoende ruimte en wanneer de globale batch kan groeien of de accumulatie van gradients kan worden aangepast. De belangrijkste voordelen zijn de eenvoudige semantiek en de goed ontwikkelde samenwerking tussen de teruggaande berekening en de gefaseerde vermindering van gradients.

Het toevoegen van rangen kan schadelijk zijn wanneer de lokale batch te klein wordt, het netwerk de all-reduce-operatie niet kan verbergen, de levering van invoer vertraagt, of wanneer de gewenste optimalisatierbatch niet schaalbaar is.

Volledig gesharded data-parallelisme: toestandsgeheugen voor collectieven

Volledig gesharded data-parallelle uitvoering

Volledig gesharded data-parallelisme slaat de shards van parameters, gradients en optimizers op binnen een groep. De parameters van een laag worden voor berekeningen verzameld via all-gather en mogen daarna opnieuw worden gesharded; gradients worden vervolgens via reduce-scatter teruggestuurd naar hun respectieve eigenaren.

De huidige documentatie van PyTorch onderscheidt de kenmerken van FSDP2 fully_shard API uit de oudere versie FullyShardedDataParallel wrapper. FSDP2 groepeert de communicatie op basis van de modules waartoe fully_shard Er wordt een bottom-up benadering toegepast en wordt aanbevolen om deze te gebruiken, zodat lagen groepen kunnen vormen die communicatie en berekening met elkaar overlappen.

from torch.distributed.fsdp import fully_shard


# 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 DTensors.
optimizer = AdamW(model.parameters(), lr=learning_rate)

Dit is een structurele schets, geen volledige launcher. De device-meshstructuren, gemengde precisie, checkpointing, initialisatie, de toestand van de optimizer en de gedistribueerde checkpoints moeten overeenkomen met de trainingsomgeving.

Sharding is a aantrekkelijke optie wanneer de model-toestand de bindende beperking vormt en de berekeningen op de verschillende lagen voldoende van het collectieve verkeer kunnen afleiden. Het kan echter een slechte keuze zijn voor kleine models-, trage verbindingen, zeer kleine lagen, of lay-outs waarbij de groep shards zich bevindt aan de verkeerde topologische grens.

Tensorparalleliteit: wiskunde van de partitionlaag

Partition van de tensorparallellaag

Tensorparallelisme verdeelt de lineaire algebra binnen een laag – bijvoorbeeld kolomparallelle en rijparallelle projecties. Gedeeltelijke resultaten vereisen collectieve operaties binnen transformerblokken, waardoor latency en bandbreedte herhaaldelijk van belang zijn tijdens zowel de voorwaartse als de teruggaande berekeningen.

Gebruik deze methode wanneer een laag of diens activations niet past, of wanneer de matmuls groot genoeg zijn zodat een gepartitioneerde kernels betere prestaties levert dan één enkele rank. Stel de tensor-parallelle groep in op het snelste beschikbare communicatiekanaal en meet vervolgens de resultaten. Een hoge orde kan elke lokale matrix verkleinen, totdat de kernel-efficiëntie daalt terwijl de collectieve overhead toeneemt.

Sequentiële paralleliteit wordt vaak gecombineerd met tensorparalleliteit om herhaling van bepaalde activation-werkzaamheden te voorkomen; dit verschilt van contextuele paralleliteit die zich uitstrekt over de volledige invoerserie van de model.

Pipeline Parallelisme: diepte van de partitionering en planningstijd

Pipeline parallele stappen en micro-batches

Pipeline Parallelisme plaatst verschillende lagen in aparte stadia en stuurt activations tussen deze stadia heen en weer. Micro-batches zorgen ervoor dat de stadia gelijktijdig kunnen werken.

Het verlicht de toestand per fase van model en kan het volume aan communicatie dat een langzamere grens overschrijdt, verminderen ten opzichte van per-laagse tensorcollectieve operaties. De bijbehorende kosten omvatten ‘bubbles’, activation-overdrachten, onevenwicht tussen fasen, een complexere planning, en moeilijkere herstel- en checkpointprocedures.

Voor een eenvoudige, gebalanceerde GPipe-achtige planning met p fasen en m Micro-batches: de geïdealiseerde forward bubble fractie is ongeveer:

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

In werkelijke planningsmodellen kunnen varianten worden gebruikt zoals one-forward/one-backward, interleaving of zero-bubble, en ongelijke kosten per laag kunnen de formule sterk beïnvloeden. Kies de grenzen tussen fasen op basis van gemeten tijd en geheugenverbruik, in plaats van een gelijk aantal lagen.

Contextparallelisme: verdeling van lange sequenties activations

Contextueel parallelle attention-uitwisseling

Parallelisme in de context zorgt voor een distributie van de sequentiële dimensie. Elke node beheert een deel van de sequentie, terwijl attention de benodigde informatie uitwisselt om de semantiek op basis van de volledige context te behouden. Implementaties kunnen hiervoor point-to-point rings, all-gather, all-to-all of hiërarchische combinaties gebruiken.

Het vermindert het geheugenverbruik voor activation bij training op lange contexten, maar zorgt ervoor dat weights binnen de contextgroep wordt gerepliceerd en introduceert daarbij attention-vormige communicatie. Het voordeel hangt af van het type attention, de toepassing van causaal maskeren, de sequentielengte, de noodzaak tot herberekening, en de manier waarop contextgroepen worden gecombineerd met tensor- en data-parallelle groepen.

Selecteer het niet op basis van een universele drempelwaarde van 8K, 32K of 100K. Analyseer de geheugenverbruikken van activation en de communicatiepatronen van attention voor de specifieke architectuur.

Expertparallelisme: uitsluitend voor een MoE-architectuur

Expert-parallelle token routing

Expertparallelisme verdeelt experts over de lagen van het mixture-of-experts-model. De router stuurt token-representaties naar geselecteerde experts en combineert hun resultaten. Alleen de geselecteerde experts voeren berekeningen uit voor elke token, maar de totale hoeveelheid experts weights vereist nog steeds opslagruimte en een geschikte serving-plaatsing.

Dit is geen optimalisatieschakelaar voor een dichte model. Het maakt deel uit van een MoE-architectuur en zorgt voor lastverdeling, capaciteit, token-all-to-all communicatie, het wegvallen of opvullen van tokens-gegevens, bijkomende verliezen en een oneven verdeling van fouten. Houd bij welke tokens-waarden per expert voorkomen, de routing-entropie, capaciteitsoverschrijdingen, communicatietijden en de kwaliteit per route.

Maak een lay-out op basis van de topologie

Grote trainingsystemen combineren dimensies. De totale wereldgrootte volgt doorgaans een product zoals:

world size = DP × TP × PP × CP

Expert parallelism kan dimensies op verschillende manieren delen of opvouwen, dus controleer eerst welk type mesh door framework wordt ondersteund in plaats van blindelings te vermenigvuldigen.

Bouw de lay-out in deze volgorde:

Teken de communicatiedomeinen: verbindingen van GPU naar GPU, switches, NUMA-grenzen, het node-netwerk, oversubscripção en opslagpaden.
Plaats frequente groepen die gevoelig zijn voor latency, meestal TP’s, in het snelste geschikte domein.
Kies FSDP of gerepliceerde DP-groepen uit de resterende capaciteit en bandbreedte.
Voeg PP toe wanneer die nuttig is voor diepe plaatsing of verkeer tussen domeinen, waarbij rekening wordt gehouden met de gemeten verwerkingstijd en geheugengebruik.
Voeg CP alleen toe vanwege sequentiebeperkingen, en EP alleen vanwege de experttopologie van model.
Controleer of de aantallen heads, verborgen dimensies, lagen, experts, batches en sequenties deelbaar zijn voor het gekozen mesh-model.
Er bestaan Benchmark verschillende geldige mesh-modellen; heuristieken die rekening houden met de topologie kiezen de kandidaten, niet de beste optie.

Twee clusters met dezelfde GPU-aantal kunnen verschillende lay-outs kiezen, omdat de bandbreedte van de verbindingen, de hiërarchie van switches, de CPU-koppeling en het netwerkconcurrentieprobleem verschillen.

Training en serving vereisen afzonderlijke beslissingen

Inference bevat doorgaans geen gradients of optimizer-status, waardoor trainingsconfiguraties in FSDP-stijl niet automatisch worden overgenomen.

Voor serving, vraag:

Past één replica binnen de limieten voor weights, KV cache, het werkgebied en de gewenste gelijktijdigheid?
Wordt throughput beter bediend door meer onafhankelijke replicas of door het opdelen van één replica?
Vermindert TP de per-rank weight-waarden en de cachebelasting voldoende om de communicatie tussen lagen te compenseren?
Wordt PP efficiënt ondersteund voor de model en de verzoekscheduler?
Hoe beïnvloeden prefill en decode op verschillende manieren de rekenkracht, geheugenbandbreedte en interconnect?
Wat gebeurt er met de tail latency wanneer verzoeken verschillende prompt- en uitvoerlengtes hebben?

Benchmark de volledige server die is uitgerust met een scheduler, quantization, contextverdeling, een batchbeheerstrategie en een model voor verkeerspatronen. Het trainen van tokens per seconde kan de serving tijd tot de eerste token of de tijdsintervallen tussen token latency niet voorspellen.

Meet een schaalbare lay-out op eerlijke manier

Voor elke kandidaat, noteer:

model, code, runtime, kernels, en topologische identiteit
globale en lokale batchverwerking, sequentiële distributie en token-telling
maximale geheugengebruik per categorie, indien beschikbaar
nuttige tokens per seconde en model-FLOP-utilisatie wanneer consistent wordt berekend
blootgestelde tijd bij all-reduce, all-gather, reduce-scatter, all-to-all en point-to-point-operaties
invoervertragingen, checkpoint-tijd, herstartgedrag en distributie van achterblijvende elementen
trainingsverlies of serving-uitvoerpariteit ten opzichte van de baseline

Vergelijk bewust zwakke en sterke schaling. Bij zwakke schaling neemt de totale werklast toe naarmate het aantal rangen toeneemt; bij sterke schaling blijft de totale werklast constant. Een percentage dat ‘schalingsefficiëntie’ wordt genoemd, heeft geen betekenis zonder die deler en referentieniveau.

Conclusie

Parallelisme is een afbeelding van een gemeten bottleneck naar een dimensie van een tensor en een communicatiepatroon. Replicatie, sharding, laagverdeling, staging, sequentieverdeling en expert routing verlichten elk een andere beperking en leiden tot een ander fallemodel.

Evalueer de werklast, teken de topologie, genereer geldige meshstructuren en analyseer deze. De optimale opstelling is die waarbij voldoende headroom blijft en de communicatie tussen componenten voor de daadwerkelijk uitgevoerde taak zo veel mogelijk wordt beperkt.