Robocikowo>ROBOCIKOWO
Trening

Synchronous Training

2017AktywnyOpublikowano: 8 maja 2026Aktualizacja: 8 maja 2026Opublikowany
Synchronous Distributed Training to paradygmat treningu w którym wszystkie workery wykonują ten sam krok SGD, a po backward pass synchronizują gradienty (zwykle przez all-reduce) zanim zaktualizują wagi.
Kluczowa innowacja
Wszyscy workery przetwarzają w lockstep ten sam krok SGD, agregując gradienty operacją all-reduce, dzięki czemu rozproszone trenowanie jest matematycznie równoważne pojedynczemu SGD na dużym minibatchu.
Kategoria
Trening
Poziom abstrakcji
Paradigm
Poziom operacji
TreningSystem
Zastosowania
Trenowanie LLM (GPT, LLaMA, Claude, Gemini) na tysiącach GPUComputer Vision (ResNet, ViT) w skali ImageNet+Reinforcement Learning z masywnym samplingiemModele rekomendacji w skali produkcyjnejFoundation models multimodalne

Jak działa

Krok treningowy: 1) Każdy z N workerów otrzymuje shard minibatcha B/N i wykonuje forward + backward pass na lokalnej kopii modelu, 2) Wszyscy uczestnicy wywołują all-reduce na buforze gradientów (zwykle ring all-reduce w NCCL/MPI lub tree-reduce na hierarchii), 3) Po zakończeniu kolektywu każdy worker ma identyczną sumę/średnią gradientów, 4) Lokalny optimizer (Adam, SGD) aktualizuje wagi – ponieważ wszystkie repliki startowały identyczne i dostały identyczny gradient, wagi pozostają zsynchronizowane bez dodatkowej komunikacji. W FSDP/ZeRO dochodzą dodatkowe all-gather/reduce-scatter do partycjonowania stanu optymalizatora, gradientów i parametrów.

Rozwiązany problem

Trening dużych modeli na pojedynczym GPU jest niewykonalny ze względu na czas i pamięć. Asynchronous parameter server skaluje się słabo z powodu stale gradients. Synchronous training rozwiązuje oba problemy zachowując zbieżność równoważną SGD na dużym minibatchu.

Implementacja

Pułapki implementacyjne
StragglersWysoka

Najwolniejszy worker (np. termiczny throttling GPU lub failing NIC) opóźnia cały krok – im większy klaster, tym większe ryzyko.

Rozwiązanie:Backup workers, elastic training, redundant replicas, careful per-host monitoring.
Generalization gap przy dużych batchachŚrednia

Bardzo duże globalne batche (>32k) potrafią pogorszyć generalization mimo zachowanej zbieżności trenu.

Rozwiązanie:Linear LR scaling + warmup, LARS/LAMB optymizatory, label smoothing.
Komunikacyjny bottleneckWysoka

Czas all-reduce skaluje się z liczbą węzłów; dla małych modeli komunikacja może dominować nad obliczeniami.

Rozwiązanie:Gradient compression, overlap compute/communication (PyTorch DDP bucketing), high-bandwidth interconnect (RoCE, InfiniBand, NVLink).
Failure recoveryKrytyczna

Awaria pojedynczego GPU/węzła w klasycznym sync training wymaga restartu z checkpointu – w klastrach 10k+ GPU MTBF jest godziny.

Rozwiązanie:Frequent checkpointing, async checkpointing (e.g. PyTorch DCP), elastic training (TorchElastic).

Ewolucja

Oryginalny paper · 2017 · arXiv (Facebook AI Research tech report) · Priya Goyal
Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour
Priya Goyal, Piotr Dollár, Ross Girshick, Pieter Noordhuis, Lukasz Wesolowski, Aapo Kyrola, Andrew Tulloch, Yangqing Jia, Kaiming He
2012
DistBelief (Google) — wczesny parameter server

Dean et al. wprowadzają asynchroniczny parameter server jako pierwszą rozproszoną architekturę treningu DL.

2017
Goyal et al. — synchronous training na 256 GPU
Punkt przełomowy

Linear scaling rule + warmup pozwala trenować ImageNet w 1h na 256 GPU. Establishuje synchronous training jako standard.

2017
Horovod (Uber)

Sergeev & Del Balso publikują Horovod – framework synchronous training oparty na ring all-reduce z NCCL/MPI.

2019
ZeRO (DeepSpeed) — partycjonowanie stanu optymalizatora
Punkt przełomowy

Rajbhandari et al. wprowadzają ZeRO redukujący pamięć przez sharding optymalizatora, gradientów i parametrów (stage 1/2/3).

2022
PyTorch FSDP – stable release

Fully Sharded Data Parallel (port ZeRO-3 do PyTorch core) staje się głównym mechanizmem treningu LLM.

2024
Trening na 100k+ GPU

xAI Colossus, Meta Llama 3, OpenAI GPT-4 trenowane na 25-100k+ GPU klastrach z synchronous SGD i RoCE/IB scale-out.

Szczegóły techniczne

Hiperparametry (konfigurowalne osie)

Number of workers (N)Krytyczna

Liczba GPU/TPU uczestniczących w treningu. Skaluje minibatch globalny i wymaga liniowego skalowania learning rate.

8 (single node)
256 (Goyal et al. 2017)
10000+ (frontier LLMs)
Global batch sizeKrytyczna

Sumaryczny minibatch B = per_worker × N. Zbyt duży powoduje generalization gap.

All-reduce algorithmWysoka

Ring vs tree vs hierarchical (NVLink+IB) all-reduce. Wpływa na skalowanie i tolerancję topologii.

Gradient accumulation stepsWysoka

Liczba mikrobatchy akumulowanych przed all-reduce – pozwala emulować większy effective batch przy ograniczonej pamięci.

Paradygmat wykonania

Tryb główny
dense

Wszystkie workery wykonują dokładnie te same operacje na każdym kroku – brak warunkowego wykonania na poziomie systemu.

Wzorzec aktywacji
all_paths_active

Równoległość

Poziom równoległości
fully_parallel
Zakres
trainingacross_devices
Ograniczenia
!Każdy krok kończy się all-reduce – najwolniejszy worker (straggler) blokuje cały klaster.
!Czas all-reduce dominuje, gdy interconnect ma wysokie opóźnienia – stąd potrzeba RDMA/InfiniBand/RoCE.

Wymagania sprzętowe

Podstawowe

Synchronous training jest dziś podstawowym workloadem klastrów NVIDIA H100/H200/B200 z NVLink + InfiniBand/RoCE.

Podstawowe

TPU pods (Google) oparte są na synchronous training z dedykowanym ICI all-reduce.