Distribuované školení v roce 2026: DDP, FSDP2, DeepSpeed, Megatron a pět os paralelismu

Jakmile máte v krabici více než jednu GPU, máte na výběr. Distribuovanému školení dnes dominují čtyři open-source stacky – PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed ​​a NVIDIA Megatron-Core – k nimž se připojil TorchTitan jako nová reference pro rozsáhlé školení s nativním PyTorchem. Každý z nich řeší jiný problém. Výběr špatného ztrácí týdny: buď model nesedí a zjistíte to v kroku 30 s chybou kvůli nedostatku paměti, nebo jste přepracovali systém pro zátěž, kterou by DDP zvládl za desetinu doby inženýrství.

Tento článek představuje pohled kupujícího a architekta na distribuované školení. Prochází pěti osami paralelismu, čtyřmi (nyní pěti) frameworky, které je kombinují, a recepty, které skutečně fungují na hardwaru třídy Kentino – primárně na 4× a 8× RTX 5090, 4090 a RTX Pro 6000 Blackwell na hostitelích AMD EPYC, s PCIe Gen5 a komoditním Ethernetem nebo InfiniBand mezi uzly. Upřímná pointa je nahoře, takže zbytek článku ji nemusí neustále dokazovat: většina zákazníků Kentina ladí, ne předtrénuje, a FSDP2 na jednom uzlu s 8 GPU zvládá 90 % potřeb jemného ladění. Megatron-Core a 3D paralelismus si vyslouží své uplatnění pouze tehdy, když předtrénujete od nuly nad úrovní 30B, a to je mnohem menší klub, než naznačuje marketing.

Pět os

Každý moderní framework pro distribuované trénování se skládá z nějaké podmnožiny stejných pěti os paralelismu. Nejsou to alternativy – recepty velkých modelů kombinují tři nebo čtyři najednou. Přečtěte si sloupec komunikace; to je celá hra.

DP křičí jednou za krok. TP křičí dvakrát za krok. vrstvaPP šeptá jednou za úroveň. SP/CP křičí jednou za blok pozornosti, ale podél jiné dimenze. EP provádí komunikaci „všechny ke všem“ pouze na vrstvách aktivních v MoE. Tento jediný sloupec určuje, kde se která osa nachází – uvnitř rychlého boxu nebo napříč pomalejší strukturou.

„3D paralelismus“, který se objevuje na každém blogu NVIDIA, je DP × TP × PPPřidejte SP a EP a získáte 4D nebo 5D, což je spíše notační hra než architektonická změna. Důležité je rozvržení: TP uvnitř uzlu (kde je šířka pásma levná), PP mezi uzly (kde je šířka pásma drahá), DP nahoře pro škálování propustnosti. SP se umisťuje vedle TP; EP se vztahuje pouze na MoE.

Křížové odkazy: tenzorově paralelní šířka pásma v rámci uzlu je rozbalena v K07, penalizace NVLink oproti PCIe v N03a meziuzlovou strukturu v N08.

DDP — když model vyhovuje a chcete jen větší propustnost

PyTorch DDP (DistributedDataParallel) je nejstarší, nejjednodušší a stále správná odpověď, když se model vejde na jeden GPU. Každá hodnost obsahuje úplnou kopii modelu a stavu optimalizátoru. Každý krok, každá hodnost provádí vlastní výpočet dopředu, zpět a gradientu ve své vlastní mikrodávce. Poté jedna redukce sečte gradienty napříč hodnostmi a všichni aplikují stejnou aktualizaci.

DDP v PyTorch 2.x je stejný jako vždy, s dvěma vylepšeními, která stojí za zmínku: robustnější static_graph=True cesta pro grafy přátelské k kompilátoru a užší integrace s torch.compileKomunikační vzorec se nemění – jedna all-reduce na krok, překrývání se zpětným postupem, lineární škálování, dokud all-reduce nepřevládne.

Když je DDP správná odpověď:

• Celý model + stavy optimalizátoru + aktivace se vejdou na jeden GPU. Pro optimalizátory typu Adam s hlavními váhami FP32 platí pravidlo zhruba 16 bajtů na parametr paměti pouze pro trénovatelný stav (4 bajty vah, 4 bajty gradientů, 8 bajtů optimalizátoru) plus aktivace. Model s 8B paměti = 128 GB stavu, což se vejde pouze na jednu RTX Pro 6000 Blackwell (96 GB) se smíšenou přesností a hlavními vahami BF16. Pod 8B parametry je DDP pohodlný na jednom 5090; nad ním se podívejte na FSDP2.
• Chcete maximální propustnost, ne maximální velikost modelu. DDP má nejnižší poměr komunikace k výpočtu ze všech paralelních datových přístupů, protože gradienty jsou sníženy. jednou za krok, po veškeré lokální zpětné práci.
• Provádíte zavádění posilovacího učení, LoRA nebo jakékoli nastavení, kde každá hodnost drží malý trénovatelný adaptér nad zmrazenými základními váhami.

Když je DDP špatný: model nesedí. Oprava není „menší dávka“. Oprava je FSDP2.

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

To je celý launcher. DDP je nudný výchozí program, na který všichni zapomínají, a pro správnou pracovní zátěž je to nejrychlejší věc, kterou lze spustit.

FSDP2 — nové výchozí nastavení pro vše, co DDP nezvládne

FSDP (Fully Shared Data Parallel) rozděluje parametry modelu, gradienty a stavy optimalizátoru napříč datově paralelní skupinou. Každá grafická karta (GPU) ukládá 1/N parametrů. Pro provedení dopředného průchodu shromáždí rank všechny hodnoty vrstvy, kterou aktuálně potřebuje, spustí výpočet a zahodí shromážděné váhy. Paměť se ve srovnání s DDP sníží zhruba N-násobně; komunikace se zvýší, protože každá vrstva je shromažďována a znovu shromažďována.

Příběh roku 2025 je FSDP2Původní FSDP (FSDP1) zabaloval skupiny parametrů do jednoho FlatParameter, což znemožňovalo nebo dokonce znemožňovalo uvažování o chování jednotlivých parametrů – částečné zmrazení, smíšené dtypy, nastavení optimalizátoru podle parametrů. FSDP2 přepsal interní mechanismy nad DTensor: každý tenzor zůstává reálným torch.Tensor který je shodou okolností horizontálně rozdělen podél svého dim-0 napříč ranky. Uživatelsky orientované API se změnilo z FSDP(model, ...) na fully_shard(model, ...).

Co FSDP2 ve skutečnosti nabízí oproti FSDP1, dle publikovaných benchmarků a našich vlastních testů:

• ~7 % méně paměti GPU na Llama 2 7B ve stejné konfiguraci, protože FSDP2 se vyhýbá record_stream vzorec, který pesimisticky upoutal paměť.
• ~1.5% nárůst propustnosti při paritěa až 50% zrychlení propustnosti v kombinaci s torch.compile a torchao Trénink float8 na hardwaru třídy Hopper.
• Sdílené stavové diktáty, které se rychle načítají a čistě znovu shardují napříč různými rozvrženími paralelismu – formát kontrolních bodů FSDP1 byl známý svou obtížností při přetváření mezi trénováním a inferencí.
• Částečné zmrazení parametrů bez akrobacie, což je důležité pro LoRA a trénink adaptérů.

FSDP1 je zastaralé od verze PyTorch 2.11Nová práce by měla používat fully_shardStarý FullyShardedDataParallel Wrapper stále existuje kvůli kompatibilitě, ale je na cestě k odstranění.

FSDP2 také zpřístupňuje dvě strategie shardingu, které rozhodují o umístění modelu:

• Plný střep. Parametry plně rozdělené napříč všemi ranky (výchozí hodnota FSDP1). Nejnižší paměť, nejvyšší komunikace.
• Hybridní střep. Parametry rozdělené do frakcí v uzel a replikováno mezi uzly. Uvnitř uzlu probíhá komunikace přes PCIe/NVLink (rychlé). Mezi uzly protíná pomalou strukturu pouze gradient all-reduce. Toto je ideální místo pro 2–4 uzly na Ethernetu/IB s rychlostí 100/200 Gb/s.

Pokud je FSDP2 správnou odpovědí (modální Kentino případ):

• Jemné doladění 8B–70B na jednom uzlu s 8 GPU. Plný shard, BF16, zapnuté kontrolní bodování gradientu. torch.compile. Hotovo.
• Jemné doladění 70B–405B napříč 2–4 uzly. Hybridní shard s plným shardem uvnitř každého uzlu, replikovaný napříč.
• Cokoli LoRA / QLoRA — FSDP2 v tomto ohledu zvládá částečné parametry lépe než FSDP1.

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)

Spuštěno stejným způsobem jako DDP, prostřednictvím torchrunJediné, co se změní, je obal.

DeepSpeed ​​a úrovně ZeRO – stále existují, už nejsou výchozí

DeepSpeed ​​je distribuovaný trénovací stack od Microsoftu. Jeho sláva spočívala v Nula (Zero Redundancy Optimizer), který se objevil roky před FSDP a definoval moderní přístup shard-everything.

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

Realita v letech 2025–2026: FSDP2 v případě použití husté LLM snědl oběd od DeepSpeedu. PyTorch nativní, bez dalších balíčků, integrovaný s torch.compileStejný recept se portuje napříč hrami Hugging Face Transformers, Accelerate a TorchTitan. Interní benchmarky od Lightning a Hugging Face ukazují, že full-shard FSDP běží v některých nastaveních 2–5× rychleji na iteraci než ZeRO-3, ačkoli DeepSpeed ​​se snaží u velmi velkých modelů (10B+) udržet v pozadí, kde jsou jeho cesty pro odlehčení CPU a NVMe stále skutečně užitečné.

O DeepSpeed ​​stále stojí za to vědět ze tří důvodů:

1. Zero-Infinity offload. Pokud musíte doladit model, který se vůbec nevejde do agregované paměti GPU – řekněme 405B základnu na 4× RTX Pro 6000 Blackwell boxu – DeepSpeed ​​dokáže přesunout parametry do RAM CPU (levné, pomalé) a do NVMe (levnější, mnohem pomalejší). FSDP má také přesunutí CPU, ale cesta DeepSpeed ​​pro NVMe je vyspělejší. Užitečné pro „mám jeden stroj a tvrdohlavý model“; není to správná odpověď, pokud si můžete pronajmout nebo koupit druhý uzel.
2. Paralelismus sekvencí DeepSpeed-Ulysses. Komunikačně efektivní sekvenčně paralelní schéma, které využívá all-to-all namísto ring all-gather pro upoutání pozornosti. V publikované práci z roku 2025 demonstroval až 1 milion kontextů tokenů na 64 A100 a trénoval Llama-8B na 15 milionech kontextových tokenů na 32 H100. Pokud se konkrétně zaměřujete na trénování velmi dlouhých kontextů, Ulysses je u některých tvarů stále napřed před kontextově paralelní implementací Megatron.
3. DeepSpeed-MoE. Školení smíšených expertů s paralelním školením expertů. Méně relevantní pro doladění, velmi relevantní, pokud provádíte předškolování MoE.

Pro většinu dolaďování Kentina pro zákazníky je správnou volbou FSDP2, pokud nemáte konkrétní důvod sáhnout po DeepSpeedu (dlouhý kontext, odlehčení CPU/NVMe, předtrénování MoE). Hybná síla ekosystému jednoznačně směřuje k FSDP2.

Megatron-LM, Megatron-Core, NeMo — kde žije těžké železo

Megatron začínal jako tenzorově paralelní transformátorový papír společnosti NVIDIA v roce 2019. Dnes má tato rodina tří vrstev:

• Megatron-LM — původní výzkumná kódová základna. Stále se používá; stále se aktualizuje.
• Megatron-Core — modulární verze knihovny. Skládatelné stavební bloky pro architektury TP/PP/DP/EP/CP, smíšené přesnosti (FP16/BF16/FP8/FP4) a referenčních transformátorů. Věc, kterou skutečně integrujete.
• Nvidia NeMo — komplexní framework postavený na platformě Megatron-Core. Recepty, datové kanály, zarovnání, nasazení.

Megatron-Core je framework, který vítězí na samém vrcholu, zejména proto, že implementuje tenzorový paralelismus, pipeline paralelismus, sekvenční paralelismus, kontextový paralelismus a expertní paralelismus v jedné kompoziční síti. Když trénujete model s hustotou 405B na 512+ GPU, nelze se vyhnout kombinaci alespoň tří z nich a Megatron-Core je nejpoužívanější a nejtestovanější kombinací.

Pokyny pro paralelismus Megatronu pro rok 2026 z vlastní dokumentace NVIDIA odpovídají hardwarové realitě:

Tato tabulka vám vysvětluje, proč Megatron existuje. Je to framework, jehož autoři žijí s matematikou šířky pásma, kterou popisujeme v N03 a K07a jeho recepty jsou pro něj vyladěny.

Kde je Megatron zbytečný: jakékoli doladění jednoho uzlu, jakýkoli model, který se vejde do paměti kompatibilní s FSDP2, jakákoli úloha, kde nepotřebujete TP. TP systém od Megatronu je skutečně rychlejší než DIY TP na PCIe, ale TP na PCIe je stále pomalý – viz čísla K07. Silnou stránkou Megatronu je hardware SXM, který Kentino nestaví.

Kde je Megatron správnou odpovědí: předtrénování modelů s hustotou 70B–405B+ na pronajatém nebo vlastněném hardwaru třídy NVLink nebo budování produkční trénovací infrastruktury pro výzkumnou laboratoř. Pokud jste to vy, pravděpodobně již jste součástí ekosystému NeMo.

TorchTitan — nová reference

TorchTitan je rozsáhlá referenční platforma pro školení od Mety, která je nativní pro PyTorch a byla přijata na ICLR 2025 a nyní je de facto příkladem pro otázku „jak by měl vypadat recept TP × PP × FSDP2 × CP v roce 2026?“. Nevynalézá nový paralelismus – skládá stavební bloky, které PyTorch již nabízí (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor) do čistého, čtyřrozměrného paralelního trénovacího skriptu s asynchronním horizontálním kontrolním bodováním, torch.compilea float8.

Proč je to důležité, i když to nepoužíváte přímo:

• Je kanonický příklad o tom, jak FSDP2 komponuje s TP a PP bez frameworku třetí strany.
• Stejná API jsou dodávána jako PyTorch. Není v tom nic magického.
• Společnost AMD koncem roku 2025 dodala optimalizovaný fork TorchTitan pro ROCm; partnerství s Lightning AI oznámené v říjnu 2025 umožňuje spouštění receptů TorchTitan v Lightning Studios.

Pro zákazníky s Kentino je TorchTitan spíše referencí ke čtení než jen frameworkem k nasazení. Pokud ladíte, je ergonomičtější Accelerate nebo Axolotl než FSDP2. Pokud provádíte předběžný trénink ve středním měřítku (8–64 GPU) na běžném hardwaru, TorchTitan je konkurenceschopný s NeMo a je mnohem méně náročný na provoz.

Rámcová matice

Accelerate a Axolotl nejsou oddělené strategie paralelismu – obalují výše uvedené backendy. Většina zákazníků, kteří ladí Kentino, nakonec bez přemýšlení použije Axolotl místo FSDP2, a to je správně.

Komunikační rozpočet – proč vaše síť omezuje model

Křížový odkaz: N08 prochází RDMA a matematickými výpočty pro uplink; jedná se o zobrazení specifické pro trénování.

Pro paralelní datová zpracování (DDP nebo FSDP) je meziúrovňová komunikace na krok zhruba úměrná počet parametrů (gradienty k redukci). Pro tenzorové rovnoběžky je úměrná aktivační velikost × počet vrstev — řády větší na krok.

Objem gradientu vypočítaný pomocí empirického pravidla pro jeden krok v BF16:

Samotné snížení výkonu 70B je na síti s rychlostí 200 Gb/s 5.6 sekundy. Pokud vaše výpočty vpřed i vzad v jednom kroku trvají také 5 sekund, máte již 50% komunikační vazbu; pokud jsou výpočty 2 sekundy, jste v síti nečinní z více než 70 %. Proto 100 GbE brzdí 70B+ trénink a potřebujete 400 GbE / NDR IB. Výpočetní výkon se neustále zrychluje; síť musí držet krok, jinak jsou grafické karty nečinné.

FSDP2 část tohoto skrývá pomocí překrytí (začíná shromažďovat další vrstvu během výpočtu aktuální). Hybridní shard skrývá více tím, že zachovává stoupání all-reduce uvnitř rychlé intranodové struktury a redukce pouze replikovaných gradientů napříč uzly. Výše ​​uvedená čísla představují nejhorší případ pro full-shard FSDP napříč uzly bez překrývání.

U tenzorových paralelních systémů se komunikace mezi jednotlivými tokeny škáluje podle velikosti skrytého objektu a počtu vrstev. Čísla v K07 ukažte proč: ~80 MB na vygenerovaný token během dekódování, ~300 GB na předběžné naplnění na 70B v dávce 32. Toto je režim, kde je PCIe (realistických 50 GB/s) zhruba 14× pomalejší než NVLink (realistických 700+ GB/s) a kde předběžné trénování modelu s hustotou 70B+ na PCIe jednoduše nefunguje s přijatelnou efektivitou.

Skutečné recepty

8B Llama jemné doladění, jeden uzel s 8 GPU — FSDP2

Hardware: 8× RTX 5090 nebo 8× RTX Pro 6000 Blackwell, hostitel EPYC, bez nutnosti inter-node fabric.

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ává se: agregát ~2000 tok/s na BF16, pohodlně se hodí pro KV/aktivace, full-shard FSDP2 přes PCIe Gen5 zvládá gradientní all-reduce uvnitř krabice. Takto také vypadá 90 % jemných ladění Kentina.

70B Llama jemné doladění, 2× uzly s 8 GPU — hybridní shard FSDP2

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

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

Hybridní shard udržuje plný shard uvnitř každého uzlu s 8 GPU a replikuje se napříč 2 uzly. Meziuzlová struktura nese pouze reduce-scatter replikovaných gradientů – zhruba 70 GB/krok při BF16, ~3 s na 200 Gbps IB. Překrytí většinu z toho skryje. Při 100 GbE stojí stejný krok ~5–6 s a GPU začnou vykazovat dobu nečinnosti; recept stále funguje, jen pomaleji na epochu.

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

Hardware: 8× 8-GPU uzly NVLink/SXM, 400 Gb/s NDR IB. Není postaveno společností Kentino – pro úplnost.

# 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 pořadí na repliku; 8 nodes × 8 GPUs = 64 GPUs celkem přesně jedna replika. Chcete-li škálovat na více replik pro vyšší propustnost, vynásobte DPA právě zde se Megatron prosadí. Stejný model na FSDP2 by většinu času strávil komunikací mezi úrovněmi; 3D rozvržení umisťuje nejintenzivnější komunikaci (TP) do domény NVLink.

Upřímný pohled na zákazníky Kentina

Většina zákazníků Kentina neprovádí předtrénování. Dolaďují základní modely s otevřenou váhou – Llama, Qwen, Mistral, někdy Gemma – na datech ze své domény, občas s LoRA nebo QLoRA, občas kompletně dolaďují. Pro tuto práci je volbou frameworku:

• Jeden model, který se vejde na jednu GPU v BF16, s optimalizovaným stavem. Používejte DDP. Replikujte kopie pro zvýšení propustnosti.
• Jeden model, který se nevejde na jednu GPU, ale vejde se agregátně na jeden uzel s 8 GPU. Použijte plný shard FSDP2. To pokrývá jemné doladění 8B–70B.
• Jeden model, který se agregovaně hodí na dva uzly s 8 GPU. Použijte hybridní horizontální oddíl FSDP2. Jemné doladění 70B–200B.
• Větší model nebo předtrénování od nuly. Tohle je téma, kam patří Megatron-Core, hardware SXM a NDR IB. My postavíme úložiště a rovinu správy, ale GPU se pro tuto fázi obvykle pronajímají.

10 % zákazníků, kteří skutečně potřebují víceuzlové, úzce propojené školení, jsou většinou výzkumné laboratoře s financovanými programy předškolení a vědí, co potřebují, ještě než zavolají. Zbývajícím 90 % by se neměl prodávat cluster – měl by se jim prodat jeden dobře specifikovaný 8GPU uzel se správnou fabric sítí pro budoucí druhý uzel a síťové vybavení by mělo být ponecháno jako položka P2.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.