Distribuovaný trénink v roce 2026: DDP, FSDP2, DeepSpeed, Megatron a pět os paralelismu

Jakmile máte v jedné skříni více než jednu GPU, musíte se rozhodnout. Distribuovanému trénování dnes dominují čtyři open-source stacky — PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed a NVIDIA Megatron-Core — a nově se k nim přidává TorchTitan jako referenční řešení pro rozsáhlé trénování nativně v PyTorchi. Každý z nich řeší jiný problém. Špatná volba vás stojí týdny: buď se model nevejde a zjistíte to u kroku 30 pádem kvůli nedostatku paměti, nebo jste přepálili architekturu pro workload, který by DDP zvládlo s desetinou vývojářské práce.

Tento článek je pohledem na distribuované trénování očima kupujícího a architekta. Projde pět os paralelizace, čtyři (nyní pět) frameworků, které je kombinují, a recepty, které na hardwaru třídy Kentino skutečně fungují — především 4× a 8× RTX 5090, 4090 a RTX Pro 6000 Blackwell na hostech s AMD EPYC, s PCIe Gen5 a běžným Ethernetem nebo InfiniBandem mezi uzly. Poctivou pointu dáváme rovnou na začátek, aby ji zbytek článku nemusel pořád dokazovat: většina zákazníků Kentino model doladuje, nikoli předtrénovává, a FSDP2 na jednom osmi-GPU uzlu pokryje 90 % potřeb fine-tuningu. Megatron-Core a 3D paralelizace se vyplatí jedině tehdy, když předtrénováváte od nuly nad hranicí 30B — a to je výrazně užší klub, než marketing naznačuje.

Pět os

Každý moderní framework pro distribuované trénování skládá nějakou podmnožinu týchž pěti os paralelizace. Nejsou to alternativy — recepty pro velké modely kombinují tři i čtyři najednou. Čtěte sloupec s komunikací; v něm se odehrává celá hra.

DP křičí jednou za krok. TP křičí dvakrát za každou vrstvu. PP jednou za stupeň zašeptá. SP/CP křičí jednou za attention blok, ale v jiném rozměru. EP dělá all-to-all jen na vrstvách, kde je MoE aktivní. Právě tento jediný sloupec rozhoduje o tom, kde která osa bydlí — uvnitř rychlé skříně, nebo napříč pomalejší sítí.

„3D paralelizace“, která se objevuje v každém blogu NVIDIA, je DP × TP × PP. Přidejte SP a EP a máte 4D nebo 5D, což je spíš hra se značením než architektonická změna. Rozhoduje rozložení: TP uvnitř uzlu (kde je propustnost levná), PP mezi uzly (kde je propustnost drahá), DP navrch kvůli škálování propustnosti. SP se zařadí vedle TP; EP se týká jen MoE.

Křížové odkazy: propustnost pro tenzorovou paralelizaci uvnitř uzlu rozebíráme v K07, penalizaci NVLink versus PCIe v N03 a síť mezi uzly v N08.

DDP — když se model vejde a vy chcete jen vyšší propustnost

PyTorch DDP (DistributedDataParallel) je nejstarší, nejjednodušší a stále správná odpověď, pokud se model vejde na jednu GPU. Každý rank drží kompletní kopii modelu i stavu optimalizátoru. V každém kroku si každý rank udělá vlastní forward, backward a výpočet gradientů na vlastní mikrodávce. Pak jediný all-reduce sečte gradienty napříč ranky a všichni aplikují stejnou aktualizaci.

DDP v PyTorchi 2.x je totéž DDP jako vždy, se dvěma vylepšeními, která stojí za zmínku: robustnější cesta static_graph=True pro grafy přívětivé ke kompilátoru a těsnější integrace s torch.compile. Komunikační vzorec se nemění — jeden all-reduce za krok, překryv s backwardem, lineární škálování, dokud nezačne dominovat all-reduce.

Kdy je DDP správná odpověď:

• Celý model + stavy optimalizátoru + aktivace se vejdou na jednu GPU. U optimalizátorů typu Adam s FP32 master vahami platí pravidlo zhruba 16 bajtů na parametr paměti jen pro trénovatelný stav (4 bajty váhy, 4 bajty gradienty, 8 bajtů optimalizátor) plus aktivace. Model 8B = 128 GB stavu, což se na jednu RTX Pro 6000 Blackwell (96 GB) vejde jedině se smíšenou přesností a BF16 master vahami. Pod 8B parametry je DDP na jediné 5090 pohodlné; nad tím se dívejte po FSDP2.
• Chcete maximální propustnost, ne maximální velikost modelu. DDP má nejnižší poměr komunikace k výpočtu ze všech datově paralelních přístupů, protože gradienty se redukují jednou za krok, až po veškeré lokální backward práci.
• Děláte rollouty v posilovaném učení, LoRA nebo jakékoli nastavení, kde každý rank drží malý trénovatelný adaptér nad zmraženými základními vahami.

Kdy je DDP špatně: model se nevejde. Řešením není „menší dávka“. Řešením je FSDP2.

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

To je celý launcher. DDP je nudný výchozí nástroj, na který všichni zapomínají — a pro správný workload je to nejrychlejší věc, kterou můžete spustit.

FSDP2 — nový standard na všechno, co DDP nezvládne

FSDP (Fully Sharded Data Parallel) rozděluje parametry modelu, gradienty a stavy optimalizátoru napříč datově paralelní skupinou. Každá GPU uchovává 1/N parametrů. Při forward průchodu rank all-gatherem stáhne vrstvu, kterou právě potřebuje, provede výpočet a stažené váhy zahodí. Paměťová náročnost klesne oproti DDP zhruba N-krát; komunikace naroste, protože každá vrstva se stahuje a znovu stahuje.

Příběhem roku 2025 je FSDP2. Původní FSDP (FSDP1) balilo skupiny parametrů do jediného FlatParameter, což dělalo z úvah o chování jednotlivých parametrů — částečné zmrazení, smíšené datové typy, nastavení optimalizátoru po parametrech — utrpení nebo rovnou nemožnost. FSDP2 přepsalo vnitřek nad DTensorem: každý tenzor zůstává skutečný torch.Tensor, který je jen shardovaný podél dimenze 0 napříč ranky. Uživatelské API se změnilo z FSDP(model, ...) na fully_shard(model, ...).

Co FSDP2 oproti FSDP1 reálně přináší, podle publikovaných benchmarků i našich vlastních běhů:

• Zhruba o 7 % nižší spotřeba paměti GPU na Llama 2 7B při stejné konfiguraci, protože FSDP2 se vyhýbá vzorci record_stream, který paměť držel zbytečně pesimisticky.
• Zhruba o 1,5 % vyšší propustnost při srovnatelném nastavení a až o 50 % rychlejší průchod v kombinaci s torch.compile a float8 trénováním přes torchao na hardwaru třídy Hopper.
• Shardované state dicty, které se rychle načítají a čistě přeshardují mezi různými rozloženími paralelizace — formát checkpointů FSDP1 byl pověstně těžko převeditelný mezi trénováním a inferencí.
• Částečné zmrazení parametrů bez akrobacie, což je zásadní pro LoRA a trénování adaptérů.

FSDP1 je od PyTorche 2.11 označeno za zastaralé. Nové projekty by měly používat fully_shard. Starý wrapper FullyShardedDataParallel kvůli kompatibilitě stále existuje, ale míří k odstranění.

FSDP2 nabízí také dvě strategie shardování, které rozhodují o tom, kde model bydlí:

• Full shard. Parametry plně rozdělené mezi všechny ranky (výchozí nastavení FSDP1). Nejnižší paměťová náročnost, nejvyšší komunikace.
• Hybrid shard. Parametry shardované uvnitř uzlu a replikované mezi uzly. Uvnitř uzlu jde komunikace přes PCIe/NVLink (rychle). Mezi uzly přechází pomalou sítí jen all-reduce gradientů. Tohle je ideální volba pro 2 až 4 uzly na 100/200Gb/s Ethernetu nebo IB.

Kdy je FSDP2 správná odpověď (typický případ u Kentino):

• Fine-tuning 8B–70B na jednom osmi-GPU uzlu. Full shard, BF16, zapnutý gradient checkpointing, torch.compile. Hotovo.
• Fine-tuning 70B–405B napříč 2 až 4 uzly. Hybrid shard s full shardem uvnitř každého uzlu a replikací mezi nimi.
• Cokoli s LoRA / QLoRA — práce FSDP2 s jednotlivými parametry tu FSDP1 jednoznačně poráží.

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)

Spouští se stejně jako DDP, přes torchrun. Jediné, co se mění, je wrapper.

DeepSpeed a úrovně ZeRO — pořád tu je, už ale není výchozí volbou

DeepSpeed je stack Microsoftu pro distribuované trénování. Proslavil se díky ZeRO (Zero Redundancy Optimizer), který přišel roky před FSDP a definoval moderní přístup „shardujeme všechno“.

ZeRO-3 je architektonicky ekvivalentní FSDP full-shardu. Řeší stejný problém stejnými komunikačními primitivy.

Realita let 2025–2026: FSDP2 sebralo DeepSpeedu práci na husté LLM scéně. Je nativní v PyTorchi, nepotřebuje balíček navíc, je integrované s torch.compile a stejný recept se přenese přes Hugging Face Transformers, Accelerate i TorchTitan. Interní benchmarky Lightningu a Hugging Face ukazují, že FSDP full-shard běží v některých konfiguracích 2× až 5× rychleji na iteraci než ZeRO-3, i když DeepSpeed získává zpět půdu u velmi velkých modelů (10B+), kde jsou jeho cesty pro offload do CPU a na NVMe stále opravdu užitečné.

DeepSpeed stojí za pozornost ze tří důvodů:

1. Offload ZeRO-Infinity. Pokud musíte doladit model, který se do souhrnné paměti GPU vůbec nevejde — řekněme 405B základ na skříni se 4× RTX Pro 6000 Blackwell — umí DeepSpeed odložit parametry do operační paměti (levné, pomalé) a na NVMe (levnější, mnohem pomalejší). FSDP má CPU offload také, ale cesta přes NVMe je u DeepSpeedu vyzrálejší. Hodí se na situaci „mám jeden stroj a tvrdohlavý model“; není to správná odpověď, pokud si můžete pronajmout nebo pořídit druhý uzel.
2. Sekvenční paralelizace DeepSpeed-Ulysses. Komunikačně úsporné schéma sekvenční paralelizace, které pro attention používá all-to-all místo kruhového all-gatheru. Předvedené až na kontextech o 1 milionu tokenů na 64 kusech A100 a v publikované práci z roku 2025 na trénování Llama-8B s kontextem 15 milionů tokenů na 32 kusech H100. Pokud cíleně jdete po trénování s velmi dlouhým kontextem, je Ulysses pro některé tvary dat stále před implementací kontextové paralelizace v Megatronu.
3. DeepSpeed-MoE. Trénování mixture-of-experts s expertní paralelizací. Pro fine-tuning méně relevantní, velmi relevantní, pokud předtrénováváte MoE.

Pro většinu fine-tuningu u zákazníků Kentino je správnou volbou FSDP2, pokud nemáte konkrétní důvod sáhnout po DeepSpeedu (dlouhý kontext, offload do CPU/NVMe, předtrénování MoE). Setrvačnost ekosystému jednoznačně míří k FSDP2.

Megatron-LM, Megatron-Core, NeMo — kde bydlí těžká technika

Megatron začal v roce 2019 jako článek NVIDIA o tenzorově paralelním Transformeru. Dnes má rodina tři vrstvy:

• Megatron-LM — původní výzkumná codebase. Stále se používá, stále se aktualizuje.
• Megatron-Core — modulární knihovní verze. Skládatelné stavební bloky pro TP/PP/DP/EP/CP, smíšenou přesnost (FP16/BF16/FP8/FP4) a referenční architektury transformerů. To, co skutečně integrujete.
• NVIDIA NeMo — end-to-end framework postavený nad Megatron-Core. Recepty, datové pipeliny, alignment, nasazení.

Megatron-Core je framework, který vítězí na samé špičce, a to právě proto, že implementuje tenzorovou, pipeline, sekvenční, kontextovou i expertní paralelizaci v jedné skládatelné mřížce. Když trénujete hustý model s 405B parametry na 512 a více GPU, nevyhnete se kombinaci minimálně tří z nich — a Megatron-Core je nejnasazenější a nejprověřenější kombinací.

Doporučení Megatronu k paralelizaci pro rok 2026, podle vlastní dokumentace NVIDIA, odpovídají hardwarové realitě:

Ta tabulka vám říká, proč Megatron existuje. Je to framework, jehož autoři žijí s matematikou propustnosti, kterou popisujeme v N03 a K07, a jeho recepty jsou na ni vyladěné.

Kde je Megatron zbytečný: jakýkoli fine-tuning na jednom uzlu, jakýkoli model, který se vejde do paměti přívětivé pro FSDP2, jakýkoli workload, kde TP nepotřebujete. Mašinerie TP v Megatronu je na PCIe skutečně rychlejší než TP udělané svépomocí, jenže TP na PCIe je pořád pomalé — viz čísla v K07. Síla Megatronu leží na hardwaru SXM, který Kentino nestaví.

Kde je Megatron správnou odpovědí: předtrénování hustých modelů 70B–405B+ na pronajatém nebo vlastním hardwaru třídy NVLink, případně stavba produkční trénovací infrastruktury pro výzkumnou laboratoř. Pokud jste to vy, nejspíš už v ekosystému NeMo jste.

TorchTitan — nová reference

TorchTitan je referenční řešení Mety pro rozsáhlé trénování nativně v PyTorchi, přijaté na ICLR 2025 a dnes de facto ukázkový příklad toho, „jak má v roce 2026 vypadat recept TP × PP × FSDP2 × CP“. Nevymýšlí novou paralelizaci — skládá stavební bloky, které PyTorch už obsahuje (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor), do čistého čtyřrozměrného paralelního trénovacího skriptu s asynchronním shardovaným checkpointingem, torch.compile a float8.

Proč na něm záleží, i když ho přímo nepoužíváte:

• Je to kanonický příklad, jak FSDP2 skládat s TP a PP bez frameworku třetí strany.
• Stejná API jsou součástí běžného PyTorche. Není v tom žádná magie.
• AMD koncem roku 2025 vydalo optimalizovaný fork TorchTitanu pro ROCm; partnerství s Lightning AI oznámené v říjnu 2025 umožňuje spouštět recepty TorchTitanu na Lightning Studios.

Pro zákazníky třídy Kentino je TorchTitan spíš referencí ke čtení než frameworkem k nasazení. Pokud ladíte model, je Accelerate nebo Axolotl nad FSDP2 ergonomičtější. Pokud předtrénováváte v mírném měřítku (8 až 64 GPU) na běžném hardwaru, je TorchTitan konkurenceschopný vůči NeMo a provozně výrazně lehčí.

Matice frameworků

Accelerate a Axolotl nejsou samostatné strategie paralelizace — obalují výše uvedené backendy. Většina zákazníků Kentino, kteří ladí modely, skončí u Axolotlu nad FSDP2, aniž by nad tím přemýšleli, a je to tak správně.

Komunikační rozpočet — proč vám velikost modelu určuje síť

Křížový odkaz: N08 prochází matematiku RDMA a uplinků; tohle je pohled specifický pro trénování.

U datové paralelizace (DDP nebo FSDP) je komunikace mezi ranky na jeden krok zhruba úměrná počtu parametrů (gradienty k redukci). U tenzorové paralelizace je úměrná velikosti aktivací × počtu vrstev — na jeden krok tedy o řády více.

Orientační objem gradientů pro jeden krok v BF16:

Samotný all-reduce u 70B trvá na 200Gb/s síti 5,6 sekundy. Pokud váš forward+backward výpočet na jeden krok trvá také 5 sekund, jste už z 50 % limitovaní komunikací; pokud výpočet trvá 2 sekundy, čekáte na síť přes 70 % času. Proto 100GbE dusí trénování modelů 70B a větších a potřebujete 400GbE / NDR IB. Výpočet je stále rychlejší; síť s ním musí držet krok, jinak budou GPU zahálet.

FSDP2 část z toho schová překryvem (začne stahovat další vrstvu, zatímco počítá tu současnou). Hybrid shard schová ještě víc tím, že all-reduce gradientů udrží uvnitř rychlé sítě v rámci uzlu a mezi uzly redukuje jen replikované gradienty. Čísla výše jsou nejhorší případ pro full-shard FSDP napříč uzly bez překryvu.

U tenzorové paralelizace se komunikace na token škáluje s velikostí skryté vrstvy a počtem vrstev. Čísla v K07 ukazují proč: ~80 MB na vygenerovaný token při dekódování, ~300 GB na prefill u 70B při dávce 32. Tohle je režim, kde je PCIe (reálně 50 GB/s) zhruba 14× pomalejší než NVLink (reálně 700+ GB/s) a kde předtrénování hustého modelu 70B+ na PCIe prostě nefunguje s přijatelnou efektivitou.

Skutečné recepty

Fine-tuning 8B Llama, jeden osmi-GPU uzel — FSDP2

Hardware: 8× RTX 5090 nebo 8× RTX Pro 6000 Blackwell, host s EPYC, síť mezi uzly není potřeba.

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čekávejte: ~2000 tok/s souhrnně v BF16, pohodlně se vejde i s KV a aktivacemi, full-shard FSDP2 přes PCIe Gen5 zvládne all-reduce gradientů uvnitř skříně. Takhle vypadá i 90 % fine-tuningových úloh u Kentino.

Fine-tuning 70B Llama, 2× osmi-GPU uzel — FSDP2 hybrid shard

Hardware: 2× 8× RTX Pro 6000 Blackwell, mezi uzly 200Gb/s IB nebo 100GbE RoCE.

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 uvnitř každého osmi-GPU uzlu a replikuje ho mezi oběma uzly. Síť mezi uzly nese jen reduce-scatter replikovaných gradientů — zhruba 70 GB na krok v BF16, tedy ~3 s na 200Gb/s IB. Překryv většinu z toho schová. Na 100GbE stejný krok stojí ~5 až 6 s a GPU začínají vykazovat prostoje; recept stále funguje, jen je epocha pomalejší.

Předtrénování 405B, 8× osmi-GPU uzel — Megatron-Core 3D

Hardware: 8× osmi-GPU uzel s NVLink/SXM, 400Gb/s NDR IB. Kentino to nestaví — uvádíme pro úplnost.

# Megatron-Core launcher (zkráceno)
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 ranků na repliku; 8 nodes × 8 GPUs = 64 GPUs celkem, tedy přesně jedna replika. Pro škálování na více replik kvůli vyšší propustnosti vynásobte DP. Právě tady se Megatron vyplatí. Stejný model by na samotném FSDP2 strávil většinu času komunikací mezi ranky; 3D rozložení umisťuje nejtěžší komunikaci (TP) dovnitř NVLink domény.

Poctivý pohled pro zákazníky Kentino

Většina zákazníků Kentino nepředtrénovává. Dolaďují otevřené základní modely — Llama, Qwen, Mistral, občas Gemma — na svých oborových datech, občas s LoRA nebo QLoRA, občas plným fine-tuningem. Pro takovou práci je volba frameworku následující:

• Jeden model, který se v BF16 i se stavem optimalizátoru vejde na jednu GPU. Použijte DDP. Kopie replikujte kvůli propustnosti.
• Jeden model, který se na jednu GPU nevejde, ale souhrnně se vejde na jeden osmi-GPU uzel. Použijte FSDP2 full shard. Tím pokryjete fine-tuning 8B–70B.
• Jeden model, který se souhrnně vejde na dva osmi-GPU uzly. Použijte FSDP2 hybrid shard. Fine-tuning 70B–200B.
• Model větší než to, nebo předtrénování od nuly. Tady přichází na řadu rozhovor o Megatron-Core, hardwaru SXM a NDR IB. Úložiště a management plane postavíme, ale GPU se na tuhle fázi obvykle pronajímají.

Oněch 10 % zákazníků, kteří skutečně potřebují těsně provázané trénování na více uzlech, jsou většinou výzkumné laboratoře s financovanými předtrénovacími programy — a ty vědí, co potřebují, ještě než zvednou telefon. Zbylým 90 % by se cluster prodávat neměl — měl by se jim prodat jeden dobře naspecifikovaný osmi-GPU uzel se správným přípravkem pro budoucí druhý uzel, a síťové prvky nechat jako položku s prioritou P2.

---

Toto je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.