Distribueret træning i 2026: DDP, FSDP2, DeepSpeed, Megatron og parallelismens fem akser

Når du har mere end én GPU i en boks, har du et valg at træffe. Fire open source-stakke dominerer distribueret træning i dag - PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed ​​og NVIDIA Megatron-Core - sammen med TorchTitan som den nye reference til native PyTorch-træning i stor skala. Hver enkelt løser et forskelligt problem. At vælge den forkerte spilder uger: enten passer modellen ikke, og du finder ud af det i trin 30 med et hukommelsesnedbrud, eller også har du overkonstrueret til en arbejdsbyrde, som DDP ville have håndteret på en tiendedel af den tekniske tid.

Denne artikel er køber-og-arkitektens syn på distribueret træning. Den gennemgår de fem parallelismeakser, de fire (nu fem) frameworks, der kombinerer dem, og de opskrifter, der rent faktisk fungerer på Kentino-klasse hardware - primært 4× og 8× RTX 5090, 4090 og RTX Pro 6000 Blackwell på AMD EPYC-værter, med PCIe Gen5 og standard Ethernet eller InfiniBand mellem noder. Den ærlige pointe er øverst, så resten af ​​artiklen behøver ikke at blive ved med at bevise den: de fleste Kentino-kunder finjusterer, ikke fortræner, og FSDP2 på en enkelt 8-GPU-node håndterer 90% af finjusteringsbehovene. Megatron-Core og 3D-parallelisme tjener kun deres plads, når man fortræner fra bunden over 30B-skalaen, og det er en meget mindre klub, end markedsføringen antyder.

De fem akser

Ethvert moderne distribueret træningsframework består af en delmængde af de samme fem parallelismeakser. De er ikke alternativer – store modelopskrifter kombinerer tre eller fire på én gang. Læs kommunikationskolonnen ned; det er hele spillet.

DP råber én gang pr. skridt. TP råber to gange pr. lagPP hvisker én gang pr. fase. SP/CP råber én gang pr. opmærksomhedsblok, men langs en anden dimension. EP gør kun alt-til-alle på de MoE-aktive lag. Den enkelte kolonne bestemmer, hvor hver akse befinder sig - inde i en hurtig boks eller på tværs af et langsommere struktur.

Den "3D-parallelisme", der optræder i alle NVIDIA-blogs, er DP × TP × PPTilføj SP og EP, og det bliver 4D eller 5D, hvilket er et notationsspil mere end en arkitektonisk ændring. Det, der betyder noget, er layoutet: TP inde i noden (hvor båndbredden er billig), PP mellem noderne (hvor båndbredden er dyr), DP ovenpå for at skalere gennemløbshastigheden. SP integreres sammen med TP; EP gælder kun for MoE.

Krydsreferencer: tensor-parallel intra-node båndbredde udpakkes i K07, NVLink-versus-PCIe-straffen i N03og stoffet mellem knuderne i N08.

DDP — når modellen passer, og du bare ønsker mere gennemløb

PyTorch DDP (DistributedDataParallel) er det ældste, enkleste og stadig korrekte svar, når modellen passer på én GPU. Hver rang indeholder en fuld kopi af modellen og optimeringstilstanden. Hvert trin, hver rang udfører sin egen fremadrettede, bagudrettede og gradientberegning på sin egen mikrobatch. Derefter summerer en enkelt all-reduce gradienterne på tværs af ranger, og alle anvender den samme opdatering.

DDP i PyTorch 2.x er den samme DDP, som den altid har været, med to forbedringer, der er værd at bemærke: en mere robust static_graph=True vej til compilervenlige grafer og tættere integration med torch.compileKommunikationsmønsteret er uændret — én all-reduce pr. trin, overlap med baglæns, skaler lineært indtil all-reduce dominerer.

Når DDP er det rigtige svar:

• Den fulde model + optimeringstilstande + aktiveringer passer på én GPU. For Adam-lignende optimeringsværktøjer på FP32-mastervægte er tommelfingerreglen cirka 16 bytes pr. parameter hukommelse alene til den træningsbare tilstand (4 bytes vægte, 4 bytes gradienter, 8 bytes optimizer) plus aktiveringer. En 8B-model = 128 GB tilstand, hvilket kun passer til ét RTX Pro 6000 Blackwell (96 GB) med blandet præcision og BF16 mastervægte. Under 8B-parametrene er DDP komfortabel på et enkelt 5090; over det, se på FSDP2.
• Du ønsker maksimal gennemløbshastighed, ikke maksimal modelstørrelse. DDP har det laveste kommunikations-til-beregningsforhold af alle dataparallelle tilgange, fordi gradienter reduceres. engang pr. trin, efter alt det lokale baglæns arbejde.
• Du udfører udrulninger af forstærkningslæring, LoRA eller enhver anden opsætning, hvor hver rang har en lille træningsbar adapter oven på frosne basisvægte.

Når DDP er forkert: modellen passer ikke. Løsningen er ikke "mindre batch". Løsningen er FSDP2.

torchrun --standalone --nproc-per-node=8 train.py

Det er hele launcheren. DDP er den kedelige standard, som alle glemmer, og med den rette arbejdsbyrde er det den hurtigste ting, du kan køre.

FSDP2 — den nye standard for alt, hvad DDP ikke kan håndtere

FSDP (Fully Sharded Data Parallel) sharderer modelparametrene, gradienterne og optimeringstilstandene på tværs af den dataparallelle gruppe. Hver GPU gemmer 1/N af parametrene. For at udføre et fremadrettet gennemløb samler rangen det lag, den i øjeblikket har brug for, kører beregningen og kasserer de indsamlede vægte. Hukommelsen falder omtrent N gange sammenlignet med DDP; kommunikationen øges, fordi hvert lag samles og samles igen.

Historien om 2025 er FSDP2Den oprindelige FSDP (FSDP1) pakkede grupper af parametre ind i en enkelt FlatParameter, hvilket gjorde det smertefuldt eller umuligt at ræsonnere om adfærd pr. parameter - delvis frysning, blandede dtyper, parametervise optimeringsindstillinger - FSDP2 omskrev de interne elementer oven på DTensor: hver tensor forbliver en reel torch.Tensor der tilfældigvis er shardet langs dens dim-0 på tværs af ranger. Den brugervendte API er ændret fra FSDP(model, ...) til fully_shard(model, ...).

Hvad FSDP2 rent faktisk leverer i forhold til FSDP1, ud fra de offentliggjorte benchmarks og vores egne tests:

• ~7% lavere GPU-hukommelse på Llama 2 7B ved samme konfiguration, fordi FSDP2 undgår record_stream mønster, der fastholdt hukommelsen pessimistisk.
• ~1.5% gennemløbsgevinst ved paritet, og op til 50% hastighedsforøgelse af gennemløbshastighed når det kombineres med torch.compile og torchao float8-træning på Hopper-klasse hardware.
• Shardede tilstandsdiktater, der indlæses hurtigt og gen-shardes rent på tværs af forskellige parallelismelayouts — FSDP1-checkpointformatet var berømt for at være svært at omforme mellem træning og inferens.
• Delvis parameterfrysning uden akrobatik, hvilket er vigtigt for LoRA og adaptertræning.

FSDP1 er udfaset fra PyTorch 2.11Nyt arbejde bør bruge fully_shardDen gamle FullyShardedDataParallel wrapper findes stadig af kompatibilitetshensyn, men er på vej til at blive fjernet.

FSDP2 afslører også to sharding-strategier, der bestemmer, hvor modellen befinder sig:

• Fuld skår. Parametre fuldt shardet på tværs af alle ranger (FSDP1-standarden). Laveste hukommelse, højeste kommunikation.
• Hybrid skår. Parametre sharded inden for en knude og replikeres på tværs af noder. Inde i en node foregår kommunikationen via PCIe/NVLink (hurtig). Mellem noder er det kun gradienten all-reduce, der krydser den langsomme struktur. Dette er det optimale punkt for 2-4 noder på 100/200 Gbps Ethernet/IB.

Når FSDP2 er det rigtige svar (det modale Kentino-tilfælde):

• 8B-70B finjustering på én 8-GPU node. Fuld shard, BF16, gradient checkpointing aktiveret, torch.compile. Færdig.
• 70B-405B finjustering på tværs af 2-4 noder. Hybrid shard med fuld shard inde i hver node, replikeret på tværs.
• Alt LoRA / QLoRA — FSDP2's håndtering af partielle parametre slår FSDP1 her fuldstændigt.

from torch.distributed.fsdp import fully_shard, MixedPrecisionPolicy

mp = MixedPrecisionPolicy(param_dtype=torch.bfloat16, reduce_dtype=torch.float32)
for block in model.transformer_blocks:
    fully_shard(block, mp_policy=mp)
fully_shard(model, mp_policy=mp)

Lanceret på samme måde som DDP, via torchrunIndpakningen er det eneste, der ændrer sig.

DeepSpeed ​​og ZeRO-niveauerne — stadig der, ikke længere standardniveauet

DeepSpeed ​​er Microsofts distribuerede træningsstak. Dens berømmelse var Nul (Zero Redundancy Optimizer), som ankom år før FSDP og definerede den moderne shard-everything-tilgang.

ZeRO-3 er arkitektonisk ækvivalent med FSDP full-shard. De løser det samme problem med de samme kommunikationsprimitiver.

Virkeligheden i 2025-2026: FSDP2 har spist DeepSpeeds frokost på dense-LLM use case-et. PyTorch native, ingen ekstra pakke, integreret med torch.compile, den samme opskrift overføres på tværs af Hugging Face Transformers, Accelerate og TorchTitan. Interne benchmarks fra Lightning og Hugging Face viser, at FSDP full-shard kører 2-5 gange hurtigere pr. iteration end ZeRO-3 i nogle opsætninger, selvom DeepSpeed ​​kæmper med at komme i baggrunden på meget store modeller (10B+), hvor dens CPU-offload og NVMe-offload-stier stadig er virkelig nyttige.

DeepSpeed ​​er fortsat værd at kende til af tre grunde:

1. ZeRO-Infinity aflastning. Hvis du skal finjustere en model, der slet ikke passer ind i den samlede GPU-hukommelse – f.eks. en 405B-base på en 4× RTX Pro 6000 Blackwell-boks – kan DeepSpeed ​​aflaste parametre til CPU RAM (billigt, langsomt) og til NVMe (billigere, meget langsommere). FSDP har også CPU-aflastning, men DeepSpeeds NVMe-sti er mere moden. Nyttig til "Jeg har én maskine og en stædig model"; ikke det rigtige svar, hvis du kan leje eller købe en anden node.
2. DeepSpeed-Ulysses sekvensparallelisme. En kommunikationseffektiv sekvens-parallel ordning, der bruger alle-til-alle i stedet for ring-all-gather for opmærksomhed. Demonstreret op til 1M-token kontekster på 64 A100'ere og træning af Llama-8B med 15M tokens kontekst på 32 H100'ere i publiceret arbejde fra 2025. Hvis du specifikt jagter meget lang konteksttræning, er Ulysses stadig foran Megatron kontekst-parallel implementeringen for nogle former.
3. DeepSpeed-MoE. Ekspertblanding med parallel ekspertuddannelse. Mindre relevant til finjustering, meget relevant, hvis du forbereder MoE-uddannelsen.

For størstedelen af ​​Kentino-kunders finjustering er det rigtige valg FSDP2, medmindre du har en specifik grund til at række ud efter DeepSpeed ​​(lang kontekst, CPU/NVMe-offload, MoE-forudtræning). Økosystemets momentum er utvetydigt i retning af FSDP2.

Megatron-LM, Megatron-Core, NeMo — hvor det tunge jern lever

Megatron startede som NVIDIAs tensor-parallelle Transformer-papir i 2019. I dag har familien tre lag:

• Megatron-LM — den originale forskningskodebase. Stadig i brug; stadig opdateret.
• Megatron-kerne — den modulære biblioteksversion. Komponérbare byggeklodser til TP/PP/DP/EP/CP, blandet præcision (FP16/BF16/FP8/FP4) og referencetransformerarkitekturer. Det, du rent faktisk integrerer.
• NVIDIA NeMo — det komplette framework bygget på Megatron-Core. Opskrifter, datapipelines, justering, implementering.

Megatron-Core er det framework, der vinder i den allerbedste ende, især fordi det implementerer tensorparallelisme, pipelineparallelisme, sekvensparallelisme, kontekstparallelisme og ekspertparallelisme i ét komponerbart mesh. Når du træner en 405B tæt model på 512+ GPU'er, kan du ikke undgå at kombinere mindst tre af disse, og Megatron-Core er den mest implementerede og mest testede kombination.

Megatron-parallelitetsvejledningen for 2026, fra NVIDIAs egen dokumentation, stemmer overens med hardwarevirkeligheden:

Den tabel fortæller dig, hvorfor Megatron eksisterer. Det er rammeværket, hvis forfattere lever med den båndbreddematematik, vi beskriver i N03 og K07, og dens opskrifter er tilpasset det.

Hvor Megatron er overkill: enhver finjustering af en enkelt node, enhver model, der passer i FSDP2-venlig hukommelse, enhver arbejdsbelastning, hvor du ikke har brug for TP. Megatrons TP-maskineri er virkelig hurtigere end DIY TP på PCIe, men TP på PCIe er stadig langsomt - se K07-tallene. Megatrons styrke ligger i SXM-hardware, som Kentino ikke bygger.

Hvor Megatron er det rigtige svar: forberedelse af 70B-405B+ kompakte modeller på lejet eller ejet NVLink-klasse hardware, eller opbygning af produktionstræningsinfrastruktur til et forskningslaboratorium. Hvis det er dig, er du sandsynligvis allerede i NeMo-økosystemet.

TorchTitan — den nye reference

TorchTitan er Metas PyTorch-native reference til storskala træning, accepteret på ICLR 2025 og nu de facto-eksemplet på "hvordan skal en TP × PP × FSDP2 × CP-opskrift se ud i 2026?". Den opfinder ikke ny parallelisme - den udgør de byggesten, som PyTorch allerede leverer (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) til et rent, firedimensionelt parallelt træningsscript med asynkron sharded checkpointing, torch.compile, og flyde8.

Hvorfor det er vigtigt, selvom du ikke bruger det direkte:

• Det er kanonisk eksempel af hvordan FSDP2 komponeres med TP og PP uden et tredjepartsframework.
• De samme API'er leveres på lager i PyTorch. Der er intet magi.
• AMD udsendte en optimeret TorchTitan-fork til ROCm i slutningen af ​​2025; Lightning AI-partnerskabet, der blev annonceret i oktober 2025, gør TorchTitan-opskrifter kørelige på Lightning Studios.

For kunder i Kentino-klassen er TorchTitan en reference, man skal læse, mere end et framework, der skal implementeres. Hvis du finjusterer, er Accelerate eller Axolotl frem for FSDP2 mere ergonomisk. Hvis du fortræner i moderat skala (8-64 GPU'er) på almindelig hardware, er TorchTitan konkurrencedygtig med NeMo og meget mindre operationelt tung.

Rammematricen

Accelerate og Axolotl er ikke separate parallelismestrategier — de omslutter ovenstående backends. De fleste Kentino-finjusteringskunder vil ende med at bruge Axolotl frem for FSDP2 uden at tænke over det, og det er korrekt.

Kommunikationsbudgettet — hvorfor dit netværk begrænser modellen

Krydsreference: N08 gennemgår RDMA og uplink-matematikken; dette er den træningsspecifikke visning.

For parallelle data (DDP eller FSDP) er kommunikationen mellem ranger pr. trin nogenlunde proportional med parameterantal (gradienter at reducere). For parallelle tensorer er den proportional med aktiveringsstørrelse × lagantal — størrelsesordener større pr. trin.

Tommelfingerregel for gradientvolumen for et enkelt trin ved BF16:

Alene 70B all-reduce tager 5.6 sekunder på en 200 Gbps fabric. Hvis din forward+back beregning på ét trin også er 5 sekunder, er du allerede 50% kommunikationsbundet; hvis beregningen er 2 sekunder, er du 70%+ inaktiv på netværket. Derfor drosler 100 GbE træning med 70B+, og du har brug for 400 GbE / NDR IB. Beregningshastigheden bliver ved med at blive hurtigere; netværket skal følge med, ellers går GPU'erne i dvale.

FSDP2 skjuler noget af dette med overlap (begynd at samle det næste lag, mens du beregner strømmen). Hybrid shard skjuler mere ved at beholde gradient all-reduce inde i den hurtige intra-node-struktur og kun reduktion af replikerede gradienter på tværs af noder. Ovenstående tal er worst-case for fuld-shard FSDP på ​​tværs af noder uden overlap.

For parallelle tensorer skaleres kommunikationen pr. token med skjult størrelse og lagantal. Tallene i K07 Vis hvorfor: ~80 MB pr. genereret token under afkodning, ~300 GB pr. præfill på 70B ved batch 32. Dette er det regime, hvor PCIe (50 GB/s realistisk) er cirka 14 gange langsommere end NVLink (700+ GB/s realistisk), og hvor prætræning af en 70B+ tæt model på PCIe simpelthen ikke fungerer med acceptabel effektivitet.

Ægte opskrifter

8B Llama finjustering, én 8-GPU node — FSDP2

Hardware: 8× RTX 5090 eller 8× RTX Pro 6000 Blackwell, EPYC-vært, intet behov for intern node-stof.

torchrun --standalone --nproc-per-node=8 \
  finetune.py \
    --model meta-llama/Llama-3.1-8B \
    --batch-size 1 --grad-accum 16 --seq-len 4096 \
    --bf16 --fsdp full_shard --fsdp-reshard-after-forward \
    --gradient-checkpointing --torch-compile

Forventet: ~2000 tok/s samlet ved BF16, passer komfortabelt med KV/aktiveringer, full-shard FSDP2 over PCIe Gen5 håndterer gradient all-reduce inde i boksen. Det er også sådan, 90% af Kentino finjusteringsjobs ser ud.

70B Llama finjustering, 2× 8-GPU noder — FSDP2 hybrid shard

Hardware: 2× 8× RTX Pro 6000 Blackwell, 200 Gbps IB eller 100 GbE RoCE mellem noder.

torchrun --nnodes=2 --nproc-per-node=8 \
  --rdzv-backend=c10d --rdzv-endpoint=node0:29500 \
  finetune.py \
    --model meta-llama/Llama-3.3-70B \
    --batch-size 1 --grad-accum 32 --seq-len 4096 \
    --bf16 --fsdp hybrid_shard \
    --gradient-checkpointing --torch-compile \
    --activation-cpu-offload

Hybrid shard holder hele sharden inde i hver 8-GPU-node og replikerer på tværs af de 2 noder. Inter-node-strukturen bærer kun den reducerede spredning af replikerede gradienter - cirka 70 GB/trin ved BF16, ~3 s på 200 Gbps IB. Overlapning skjuler det meste af det. Ved 100 GbE koster det samme trin ~5-6 s, og GPU'erne begynder at vise inaktiv tid; opskriften fungerer stadig, bare langsommere pr. epoch.

405B-forudtræning, 8× 8-GPU-noder — Megatron-Core 3D

Hardware: 8× 8-GPU NVLink/SXM-noder, 400 Gbps NDR IB. Ikke bygget af Kentino — for fuldstændighedens skyld.

# Megatron-Core launcher (abbreviated)
torchrun --nnodes=8 --nproc-per-node=8 \
  pretrain_gpt.py \
    --tensor-model-parallel-size 8 \
    --pipeline-model-parallel-size 8 \
    --sequence-parallel \
    --context-parallel-size 1 \
    --num-layers 126 --hidden-size 16384 --num-attention-heads 128 \
    --seq-length 8192 --micro-batch-size 1 --global-batch-size 2048 \
    --bf16 --use-flash-attn --transformer-impl transformer_engine

TP=8 × PP=8 = 64 rang pr. replika; 8 nodes × 8 GPUs = 64 GPUs i alt, præcis én replika. For at skalere til flere replikaer for højere gennemløb, gang med DPDet er her, Megatron tjener sin plads. Den samme model alene på FSDP2 ville bruge det meste af sin tid på kommunikation mellem rang; 3D-layoutet placerer den tungeste kommunikation (TP) inden for NVLink-domænet.

Ærlig vurdering af Kentino-kunder

De fleste Kentino-kunder forbereder sig ikke på forhåndstræning. De finjusterer open-weight basismodeller — Llama, Qwen, Mistral, nogle gange Gemma — på deres domænedata, lejlighedsvis med LoRA eller QLoRA, lejlighedsvis fuld finjustering. Til det arbejde er valget af rammeværk:

• En model, der passer til én GPU på BF16, med optimeringstilstand. Brug DDP. Replikér kopier for at opnå gennemløbshastighed.
• En model, der ikke passer på én GPU, men passer samlet på én 8-GPU-node. Brug FSDP2 fuld shard. Dette dækker finjusteringer på 8B-70B.
• Én model, der passer samlet på tværs af to 8-GPU-noder. Brug FSDP2 hybrid shard. Finjusteringer på 70B–200B.
• En model større end det, eller foruddannelse fra bunden. Det er i denne fase, at Megatron-Core, SXM-hardware og NDR IB hører hjemme. Vi vil bygge storage- og administrationsplanet, men GPU'erne lejes normalt til den fase.

De 10% af kunderne, der reelt har brug for tæt koblet træning med flere noder, er for det meste forskningslaboratorier med finansierede forberedende træningsprogrammer, og de ved, hvad de har brug for, før de ringer. De andre 90% bør ikke sælges en klynge – de bør sælges én velspecificeret 8-GPU-node med den rigtige fabric-stub til en fremtidig anden node, og netværksudstyret bør forblive som en P2-linjepost.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.