Distribuovaný tréning v roku 2026: DDP, FSDP2, DeepSpeed, Megatron a päť osí paralelizmu

Akonáhle máte v jednom stroji viac než jednu GPU, musíte sa rozhodnúť. Distribuovanému tréningu dnes dominujú štyri open-source stacky — PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed a NVIDIA Megatron-Core — ku ktorým pribudol TorchTitan ako nová referencia pre natívny PyTorch tréning vo veľkom meradle. Každý z nich rieši iný problém. Zlá voľba stojí týždne: buď sa model nezmestí a zistíte to v 30. kroku pádom pre nedostatok pamäte, alebo ste prekomplikovali riešenie pre workload, ktorý by DDP zvládol s desatinou vývojárskej práce.

Tento článok je pohľadom kupujúceho a architekta na distribuovaný tréning. Prechádza päť osí paralelizmu, štyri (dnes päť) frameworkov, ktoré ich kombinujú, a recepty, ktoré na hardvéri triedy Kentino naozaj fungujú — predovšetkým 4× a 8× RTX 5090, 4090 a RTX Pro 6000 Blackwell na hostiteľoch s AMD EPYC, s PCIe Gen5 a bežným Ethernetom alebo InfiniBandom medzi uzlami. Pointu uvádzame rovno na začiatku, aby ju zvyšok článku nemusel stále dokazovať: väčšina zákazníkov Kentino modely dolaďuje, nie predtrénuje, a FSDP2 na jedinom 8-GPU uzle pokryje 90 % potrieb fine-tuningu. Megatron-Core a 3D paralelizmus sa oplatia až vtedy, keď trénujete od nuly nad hranicou 30B — a to je oveľa užší klub, než naznačuje marketing.

Päť osí

Každý moderný framework pre distribuovaný tréning skladá nejakú podmnožinu tých istých piatich osí paralelizmu. Nie sú to alternatívy — recepty pre veľké modely kombinujú tri až štyri naraz. Prečítajte si stĺpec o komunikácii; v ňom je celá podstata.

DP kričí raz za krok. TP kričí dvakrát na každú vrstvu. PP šepká raz za stupeň. SP/CP kričí raz za blok pozornosti, no v inom rozmere. EP robí all-to-all len na vrstvách aktívnych pre MoE. Práve tento jediný stĺpec rozhoduje, kde ktorá os žije — vnútri rýchleho stroja, alebo naprieč pomalšou sieťou.

„3D paralelizmus“, ktorý sa spomína v každom blogu NVIDIA, je DP × TP × PP. Pridajte SP a EP a máte 4D či 5D, čo je skôr hra s označením než architektonická zmena. Podstatné je rozloženie: TP vnútri uzla (kde je priepustnosť lacná), PP medzi uzlami (kde je drahá) a DP navrchu pre škálovanie priepustnosti. SP zapadá vedľa TP; EP sa týka len MoE.

Krížové odkazy: priepustnosť vnútri uzla pri tenzorovom paralelizme rozoberáme v K07, penalizáciu NVLink verzus PCIe v N03 a prepojenie medzi uzlami v N08.

DDP — keď sa model zmestí a chcete len vyššiu priepustnosť

PyTorch DDP (DistributedDataParallel) je najstaršou, najjednoduchšou a stále správnou odpoveďou, keď sa model zmestí na jednu GPU. Každý rank drží plnú kópiu modelu aj stavu optimalizátora. V každom kroku si každý rank spraví vlastný dopredný a spätný prechod a výpočet gradientov na vlastnej mikrodávke. Potom jediný all-reduce sčíta gradienty naprieč rankmi a všetci aplikujú rovnakú aktualizáciu.

DDP v PyTorchi 2.x je to isté DDP, aké bolo vždy, s dvoma zlepšeniami, ktoré stoja za zmienku: robustnejšou cestou static_graph=True pre grafy priateľské ku kompilátoru a tesnejšou integráciou s torch.compile. Komunikačný vzor sa nemení — jeden all-reduce na krok, prekryv so spätným prechodom a lineárne škálovanie, kým nezačne dominovať samotný all-reduce.

Kedy je DDP správnou odpoveďou:

• Celý model + stavy optimalizátora + aktivácie sa zmestia na jednu GPU. Pri optimalizátoroch typu Adam s FP32 master váhami platí orientačné pravidlo zhruba 16 bajtov na parameter pamäte len pre trénovateľný stav (4 bajty váhy, 4 bajty gradienty, 8 bajtov optimalizátor) plus aktivácie. Model s 8B parametrami = 128 GB stavu, čo sa na jednu RTX Pro 6000 Blackwell (96 GB) zmestí len pri zmiešanej presnosti a BF16 master váhach. Pod 8B parametrov je DDP na jedinej 5090 pohodlné; nad touto hranicou sa pozrite na FSDP2.
• Chcete maximálnu priepustnosť, nie maximálnu veľkosť modelu. DDP má zo všetkých dátovo paralelných prístupov najnižší pomer komunikácie k výpočtu, pretože gradienty sa redukujú raz za krok, až po celej lokálnej spätnej práci.
• Robíte rollouty pre posilňované učenie, LoRA alebo akékoľvek nastavenie, kde každý rank drží malý trénovateľný adaptér nad zmrazenými základnými váhami.

Kedy je DDP zlou voľbou: model sa nezmestí. Riešením nie je „menšia dávka“. Riešením je FSDP2.

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

A to je celý launcher. DDP je nudná predvoľba, na ktorú všetci zabúdajú — a pre správny workload je tým najrýchlejším, čo môžete spustiť.

FSDP2 — nová predvoľba pre všetko, na čo DDP nestačí

FSDP (Fully Sharded Data Parallel) rozdeľuje parametre modelu, gradienty aj stavy optimalizátora naprieč dátovo paralelnou skupinou. Každá GPU uchováva 1/N parametrov. Pri doprednom prechode si rank all-gatherom stiahne vrstvu, ktorú práve potrebuje, vykoná výpočet a zozbierané váhy zahodí. Pamäť klesá zhruba N-násobne oproti DDP; komunikácia rastie, pretože každá vrstva sa zbiera a zbiera znova.

Príbehom roka 2025 je FSDP2. Pôvodné FSDP (FSDP1) balilo skupiny parametrov do jediného FlatParameter, čo robilo uvažovanie o správaní jednotlivých parametrov — čiastočné zmrazovanie, zmiešané dátové typy, nastavenia optimalizátora po parametroch — bolestivým alebo priam nemožným. FSDP2 prepísalo vnútro na základe DTensoru: každý tenzor zostáva skutočným torch.Tensor, ktorý je len rozdelený pozdĺž svojho dim-0 naprieč rankmi. Používateľské API sa zmenilo z FSDP(model, ...) na fully_shard(model, ...).

Čo FSDP2 oproti FSDP1 reálne prináša — podľa publikovaných benchmarkov aj našich vlastných behov:

• ~7 % nižšia spotreba pamäte GPU na Llama 2 7B pri rovnakej konfigurácii, pretože FSDP2 sa vyhýba vzoru record_stream, ktorý pamäť pridržiaval pesimisticky.
• ~1.5 % vyššia priepustnosť pri rovnakých podmienkach a až 50 % zrýchlenie priepustnosti v kombinácii s torch.compile a torchao float8 tréningom na hardvéri triedy Hopper.
• Shardované state dicty, ktoré sa rýchlo načítajú a čisto preshardujú medzi rôznymi rozloženiami paralelizmu — formát checkpointov FSDP1 bol povestne ťažko pretvárateľný medzi tréningom a inferenciou.
• Čiastočné zmrazovanie parametrov bez akrobacie, čo je dôležité pri LoRA a tréningu adaptérov.

FSDP1 je od PyTorchu 2.11 zastarané. Nové projekty by mali používať fully_shard. Starý wrapper FullyShardedDataParallel síce stále existuje pre kompatibilitu, no je na ceste k odstráneniu.

FSDP2 ponúka aj dve shardovacie stratégie, ktoré rozhodujú o tom, kde model žije:

• Full shard. Parametre plne rozdelené naprieč všetkými rankmi (predvoľba FSDP1). Najnižšia pamäť, najvyššia komunikácia.
• Hybrid shard. Parametre rozdelené vnútri uzla a replikované medzi uzlami. Vnútri uzla ide komunikácia cez PCIe/NVLink (rýchle). Medzi uzlami prechádza pomalou sieťou len all-reduce gradientov. Toto je ideálne nastavenie pre 2 až 4 uzly na 100/200 Gbps Ethernete/IB.

Kedy je FSDP2 správnou odpoveďou (typický prípad Kentino):

• Fine-tuning 8B–70B na jednom 8-GPU uzle. Full shard, BF16, zapnutý gradient checkpointing, torch.compile. Hotovo.
• Fine-tuning 70B–405B naprieč 2 až 4 uzlami. Hybrid shard s full shardom vnútri každého uzla a replikáciou medzi nimi.
• Čokoľvek s LoRA / QLoRA — práca FSDP2 s jednotlivými parametrami tu FSDP1 jednoznačne prekonáva.

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)

Spúšťa sa rovnako ako DDP, cez torchrun. Mení sa len wrapper.

DeepSpeed a úrovne ZeRO — stále tu sú, už nie sú predvoľbou

DeepSpeed je stack pre distribuovaný tréning od Microsoftu. Preslávil sa technológiou ZeRO (Zero Redundancy Optimizer), ktorá prišla roky pred FSDP a zadefinovala moderný prístup „rozdeľ všetko“.

ZeRO-3 je architektonicky ekvivalentom FSDP full shard. Riešia ten istý problém tými istými komunikačnými primitívami.

Realita rokov 2025 – 2026: FSDP2 zobralo DeepSpeedu prvenstvo v scenári hustých LLM. Natívne v PyTorchi, bez ďalšieho balíka, integrované s torch.compile, pričom ten istý recept sa prenáša naprieč Hugging Face Transformers, Accelerate aj TorchTitanom. Interné benchmarky od Lightning a Hugging Face ukazujú, že FSDP full shard beží v niektorých nastaveniach 2–5× rýchlejšie na iteráciu než ZeRO-3, hoci DeepSpeed získava späť pôdu pri veľmi veľkých modeloch (10B+), kde sú jeho cesty odkladania do CPU a NVMe stále naozaj užitočné.

DeepSpeed stojí za pozornosť z troch dôvodov:

1. Odkladanie ZeRO-Infinity. Ak musíte doladiť model, ktorý sa nezmestí ani do úhrnnej pamäte GPU — povedzme základ 405B na stroji so 4× RTX Pro 6000 Blackwell — DeepSpeed dokáže odložiť parametre do CPU RAM (lacné, pomalé) a na NVMe (lacnejšie, oveľa pomalšie). FSDP má odkladanie do CPU tiež, no NVMe cesta DeepSpeedu je vyzretejšia. Užitočné pre situáciu „mám jeden stroj a tvrdohlavý model“; nie je to správna odpoveď, ak si môžete prenajať alebo kúpiť druhý uzol.
2. Sekvenčný paralelizmus DeepSpeed-Ulysses. Komunikačne efektívna schéma sekvenčného paralelizmu, ktorá pre pozornosť používa all-to-all namiesto ring all-gather. Preukázaná na kontextoch do 1M tokenov na 64 kusoch A100 a v publikovaných prácach z roku 2025 na tréningu Llama-8B s kontextom 15M tokenov na 32 kusoch H100. Ak sa zameriavate špecificky na tréning s veľmi dlhým kontextom, Ulysses je pri niektorých tvaroch stále pred implementáciou kontextového paralelizmu v Megatrone.
3. DeepSpeed-MoE. Tréning mixture-of-experts s expertným paralelizmom. Pre fine-tuning menej dôležité, veľmi dôležité, ak predtrénujete MoE.

Pre väčšinu fine-tuningu u zákazníkov Kentino je správnou voľbou FSDP2 — pokiaľ nemáte konkrétny dôvod siahnuť po DeepSpeede (dlhý kontext, odkladanie do CPU/NVMe, predtrénovanie MoE). Zotrvačnosť ekosystému smeruje jednoznačne k FSDP2.

Megatron-LM, Megatron-Core, NeMo — kde býva ťažká technika

Megatron začal v roku 2019 ako článok NVIDIA o tenzorovo paralelnom Transformeri. Dnes má táto rodina tri vrstvy:

• Megatron-LM — pôvodná výskumná kódová základňa. Stále sa používa, stále sa aktualizuje.
• Megatron-Core — modulárna knižnica. Skladateľné stavebné bloky pre TP/PP/DP/EP/CP, zmiešanú presnosť (FP16/BF16/FP8/FP4) a referenčné architektúry transformerov. To, čo reálne integrujete.
• NVIDIA NeMo — kompletný framework postavený na Megatron-Core. Recepty, dátové pipeline, alignment, nasadenie.

Megatron-Core je framework, ktorý víťazí na úplnej špičke, a to práve preto, že implementuje tenzorový, pipeline, sekvenčný, kontextový aj expertný paralelizmus v jednej skladateľnej mriežke. Keď trénujete hustý model s 405B parametrami na 512 a viac GPU, kombinácii aspoň troch z nich sa nevyhnete — a Megatron-Core je najnasadzovanejšou a najlepšie otestovanou kombináciou.

Odporúčania Megatronu k paralelizmu pre rok 2026, priamo z dokumentácie NVIDIA, sedia s realitou hardvéru:

Tá tabuľka vám povie, prečo Megatron existuje. Je to framework, ktorého autori žijú s matematikou priepustnosti, ktorú opisujeme v N03 a K07, a jeho recepty sú na ňu vyladené.

Kedy je Megatron zbytočne ťažký kaliber: pri akomkoľvek fine-tuningu na jednom uzle, pri každom modeli, ktorý sa zmestí do pamäte priateľskej k FSDP2, a pri každom workloade, kde TP nepotrebujete. Mašinéria TP v Megatrone je naozaj rýchlejšia než vlastnoručné TP na PCIe, no TP na PCIe je aj tak pomalé — pozrite si čísla v K07. Sila Megatronu je na hardvéri SXM, ktorý Kentino nestavia.

Kedy je Megatron správnou odpoveďou: pri predtrénovaní hustých modelov 70B–405B+ na prenajatom alebo vlastnom hardvéri triedy NVLink, alebo pri budovaní produkčnej tréningovej infraštruktúry pre výskumné laboratórium. Ak ste to vy, s najväčšou pravdepodobnosťou už ste v ekosystéme NeMo.

TorchTitan — nová referencia

TorchTitan je referenčný projekt Meta pre veľkoobjemový tréning natívne v PyTorchi, prijatý na ICLR 2025 a dnes de facto príklad toho, „ako má v roku 2026 vyzerať recept TP × PP × FSDP2 × CP“. Nevymýšľa nový paralelizmus — skladá stavebné bloky, ktoré PyTorch už obsahuje (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) do čistého štvorrozmerného paralelného tréningového skriptu s asynchrónnym shardovaným checkpointingom, torch.compile a float8.

Prečo je dôležitý, aj keď ho priamo nepoužijete:

• Je kanonickým príkladom toho, ako sa FSDP2 skladá s TP a PP bez frameworku tretej strany.
• Tie isté API sú súčasťou bežného PyTorchu. Nie je v tom žiadna mágia.
• AMD koncom roka 2025 vydalo optimalizovaný fork TorchTitanu pre ROCm; partnerstvo s Lightning AI oznámené v októbri 2025 umožňuje spúšťať recepty TorchTitanu na Lightning Studios.

Pre zákazníkov triedy Kentino je TorchTitan skôr referenciou na čítanie než frameworkom na nasadenie. Ak robíte fine-tuning, Accelerate alebo Axolotl nad FSDP2 sú ergonomickejšie. Ak predtrénujete v skromnejšom meradle (8–64 GPU) na bežnom hardvéri, TorchTitan je konkurencieschopný voči NeMo a prevádzkovo oveľa ľahší.

Matica frameworkov

Accelerate a Axolotl nie sú samostatné stratégie paralelizmu — iba obaľujú backendy uvedené vyššie. Väčšina zákazníkov Kentino robiacich fine-tuning skončí pri Axolotli nad FSDP2 bez toho, aby nad tým premýšľala, a to je správne.

Komunikačný rozpočet — prečo vám sieť obmedzuje model

Krížový odkaz: N08 prechádza matematiku RDMA a uplinkov; toto je pohľad špecifický pre tréning.

Pri dátovom paralelizme (DDP alebo FSDP) je komunikácia medzi rankmi na jeden krok zhruba úmerná počtu parametrov (gradienty na redukciu). Pri tenzorovom paralelizme je úmerná veľkosti aktivácií × počtu vrstiev — na krok je to o rády viac.

Orientačný objem gradientov pre jeden krok pri BF16:

Samotný all-reduce pri 70B trvá na sieti s 200 Gbps 5.6 sekundy. Ak váš dopredný a spätný výpočet v jednom kroku trvá tiež 5 sekúnd, už ste na 50 % limitovaní komunikáciou; ak výpočet trvá 2 sekundy, viac než 70 % času čakáte na sieť. Práve preto 100 GbE dusí tréning modelov 70B+ a potrebujete 400 GbE / NDR IB. Výpočtový výkon stále rastie; sieť s ním musí držať krok, inak GPU zaháľajú.

FSDP2 časť z toho skryje prekryvom (zbieranie ďalšej vrstvy začne už počas výpočtu tej aktuálnej). Hybrid shard skryje ešte viac tým, že all-reduce gradientov drží vnútri rýchlej siete v uzle a medzi uzlami redukuje len replikované gradienty. Čísla vyššie sú najhorším scenárom pre full shard FSDP naprieč uzlami bez prekryvu.

Pri tenzorovom paralelizme sa komunikácia na token škáluje so skrytým rozmerom a počtom vrstiev. Čísla v K07 ukazujú prečo: ~80 MB na vygenerovaný token počas dekódovania, ~300 GB na prefill pri 70B a dávke 32. Toto je režim, v ktorom je PCIe (reálne 50 GB/s) zhruba 14× pomalšie než NVLink (reálne 700+ GB/s) a v ktorom predtrénovanie hustého modelu 70B+ na PCIe jednoducho nefunguje s prijateľnou efektivitou.

Reálne recepty

Fine-tuning Llamy 8B, jeden 8-GPU uzol — FSDP2

Hardvér: 8× RTX 5090 alebo 8× RTX Pro 6000 Blackwell, hostiteľ s EPYC, sieť medzi uzlami netreba.

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

Očakávanie: ~2000 tok/s v súčte pri BF16, pohodlne sa zmestí aj s KV a aktiváciami, full shard FSDP2 cez PCIe Gen5 zvláda all-reduce gradientov vnútri stroja. Takto zároveň vyzerá 90 % fine-tuningových úloh u zákazníkov Kentino.

Fine-tuning Llamy 70B, 2× 8-GPU uzol — FSDP2 hybrid shard

Hardvér: 2× 8× RTX Pro 6000 Blackwell, 200 Gbps IB alebo 100 GbE RoCE medzi uzlami.

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 drží full shard vnútri každého 8-GPU uzla a replikuje ho medzi dvoma uzlami. Sieť medzi uzlami prenáša len reduce-scatter replikovaných gradientov — zhruba 70 GB na krok pri BF16, ~3 s na 200 Gbps IB. Prekryv väčšinu z toho skryje. Na 100 GbE stojí ten istý krok ~5–6 s a GPU začínajú vykazovať nečinnosť; recept stále funguje, len je epocha pomalšia.

Predtrénovanie 405B, 8× 8-GPU uzol — Megatron-Core 3D

Hardvér: 8× 8-GPU uzol s NVLink/SXM, 400 Gbps NDR IB. Kentino ho nestavia — uvádzame pre úplnosť.

# 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 rankov na repliku; 8 nodes × 8 GPUs = 64 GPUs celkovo, teda presne jedna replika. Na škálovanie na viac replík kvôli vyššej priepustnosti prenásobte hodnotou DP. Práve tu sa Megatron vypláca. Ten istý model by na samotnom FSDP2 strávil väčšinu času komunikáciou medzi rankmi; 3D rozloženie umiestni najťažšiu komunikáciu (TP) do domény NVLink.

Úprimný pohľad pre zákazníkov Kentino

Väčšina zákazníkov Kentino nepredtrénuje. Dolaďujú základné modely s otvorenými váhami — Llama, Qwen, Mistral, občas Gemma — na svojich doménových dátach, niekedy pomocou LoRA či QLoRA, inokedy plným fine-tuningom. Pre takúto prácu je voľba frameworku takáto:

• Jeden model, ktorý sa pri BF16 aj so stavom optimalizátora zmestí na jednu GPU. Použite DDP. Kópie replikujte kvôli priepustnosti.
• Jeden model, ktorý sa na jednu GPU nezmestí, ale v súčte sa zmestí na jeden 8-GPU uzol. Použite FSDP2 full shard. Pokrýva fine-tuning 8B–70B.
• Jeden model, ktorý sa v súčte zmestí na dva 8-GPU uzly. Použite FSDP2 hybrid shard. Fine-tuning 70B–200B.
• Model väčší než to, alebo predtrénovanie od nuly. Toto je rozhovor, do ktorého patrí Megatron-Core, hardvér SXM a NDR IB. Úložisko a správcovskú vrstvu postavíme, no GPU sa na túto fázu zvyčajne prenajímajú.

Tých 10 % zákazníkov, ktorí naozaj potrebujú tesne prepojený tréning na viacerých uzloch, sú väčšinou výskumné laboratóriá s financovanými programami predtrénovania — a vedia, čo potrebujú, ešte skôr, než zavolajú. Zvyšným 90 % by sa klaster predávať nemal; mal by sa im predať jeden dobre naprojektovaný 8-GPU uzol so správnou prípravou siete pre budúci druhý uzol, pričom sieťové vybavenie zostane ako položka priority P2.

---

Toto je súčasť Kentino Wiki, referenčnej série o výpočtovom výkone pre AI, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy uvítame na info@kentino.com.