// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

DDP, ZeRO, FSDP: la strategia decide quanto comunichi, il cablaggio quanto ti costa

Un’analisi misurata di DDP, ZeRO e FSDP su A100 e H200. La conclusione controintuitiva: sullo stesso nodo, quattro GPU identiche vanno 9 volte più lente se lo scheduler te le assegna nel gruppo sbagliato.

Hussen Mohammed Ibrahim ha pubblicato su Towards Data Science un confronto misurato tra le strategie di distributed training e il fabric che le regge. La tesi è semplice: la strategia decide quanti dati devono muoversi, il cablaggio decide quanto costa muoverli. Ed è la seconda parte quella che di solito nessuno controlla.

Il dial, non l’interruttore

DDP replica tutto su ogni GPU e comunica una volta per step, con un’all-reduce. FSDP shardà parametri, gradienti e optimizer state, e per farlo comunica a ogni layer: all-gather in avanti, all-gather e reduce-scatter all’indietro. Tra i due estremi stanno gli stage ZeRO di DeepSpeed, che tolgono un pezzo alla volta partendo dal più pesante — ZeRO-1 solo gli optimizer state, ZeRO-2 anche i gradienti, ZeRO-3 anche i parametri (a quel punto è la stessa idea di FSDP, implementata da un altro framework).

L’esempio numerico chiarisce perché serve. Mistral-7B con Adam in BF16 mixed precision: 14 GB di parametri, 14 GB di gradienti, circa 58 GB di optimizer state in FP32. Totale 87 GB prima ancora di vedere un batch. Su una A100 da 80 GB non entra. Con FSDP su quattro GPU la stima scende a circa 22 GB, il picco reale misurato è stato circa 29 GB includendo activation e overhead.

La scala della memoria è pulita e prevedibile: 87 GB con DDP, poi 55, 51, 40 e 37 GB scendendo lungo il dial. Non arriva mai a un quarto di 87, perché le activation restano locali a ogni GPU.

Poi c’è il filo

Qui la parte utile. Dentro un singolo nodo le GPU parlano via PCIe o via NVLink. Su H200 ogni GPU ha 18 link NVLink, circa 450 GB/s per direzione contro i circa 64 GB/s di uno slot PCIe Gen5 x16. Ma NVLink è solo il link: conta come sono disposti. Con NVSwitch ogni GPU è a un hop da ogni altra a piena velocità. Con le schede NVL, i link esistono solo dentro piccoli gruppi — nella macchina testata, due gruppi da quattro — e tra gruppi si ricade su PCIe.

Le misure: sulla stessa coppia di H200 SXM, forzare PCIe invece di NVLink costa 10–11x di banda. Sul nodo NVL, una all-reduce su quattro GPU dentro lo stesso quad raggiunge circa 322 GB/s; le stesse quattro schede a cavallo di due quad crollano a circa 35 GB/s. Circa 9x di differenza decisa solo da quali GPU ti assegna lo scheduler. Da notare anche il caso opposto: due sole GPU dentro un quad fanno 114 GB/s perché usano 6 dei 18 link disponibili — il quad non era lento, era sottoutilizzato.

Sul training end-to-end di Mistral-7B a quattro GPU, attraversare i quad taglia il throughput di 3–5x. E non colpisce tutti allo stesso modo: FSDP perde di più perché comunica a ogni layer, DDP tiene meglio perché comunica una volta per step. Su filo lento il dial si appiattisce: quale tensore shardài conta poco, decide il filo.

In sintesi

  • Su NVSwitch, FSDP tiene il passo di DDP usando molta meno memoria: è un default ragionevole anche quando il modello entrerebbe.
  • Su nodi NVL, tenere il job dentro un singolo gruppo bridged (via CUDA_VISIBLE_DEVICES) vale quanto scegliere la strategia giusta.
  • Prima di lanciare, un comando: nvidia-smi topo -m. Il nome della GPU non dice come sono cablate.

Fonte: Behind the Scenes of Distributed Training and Why Your GPU Wiring Matters as Much as Your Strategy

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma