Pianifica un'esecuzione PyTorch riproducibile

Dimostra un passaggio completo prima di scalare

Blocca le revisioni del modello e del dataset, le versioni delle dipendenze, la configurazione di addestramento, i seed casuali e il digest del container. Esegui il caricamento del modello, un passo di addestramento completo, la valutazione, il salvataggio del checkpoint e il ripristino del checkpoint su un acceleratore.

Utilizza la stessa lunghezza di sequenza e le stesse impostazioni di micro-batch previste per l'esecuzione più lunga. Un pilota minuscolo che omette lo stato dell'ottimizzatore o utilizza sequenze più brevi può nascondere il problema di memoria che stai cercando di misurare.

Misurare un passaggio di ottimizzazione rappresentativo

All'interno del tuo programma di addestramento esistente, circonda un passaggio rappresentativo con una misurazione della memoria di picco. L'esempio presuppone che modello, batch e ottimizzatore siano già stati inizializzati sulla GPU. Includi il passaggio dell'ottimizzatore perché parte dello stato viene creata in modo lazy.

torch.cuda.reset_peak_memory_stats()
optimizer.zero_grad(set_to_none=True)
loss = model(**batch).loss
loss.backward()
optimizer.step()
torch.cuda.synchronize()
peak_gib = torch.cuda.max_memory_allocated() / 2**30
print(f"Peak tensor memory: {peak_gib:.2f} GiB")

Questo riporta l'allocazione di picco dei tensori, non l'impronta completa del dispositivo. Ispezionare anche la memoria riservata, l'overhead di runtime e il report sulla memoria del dispositivo di sistema.

Scegli DDP o lo sharding per il motivo giusto

DistributedDataParallel mantiene una replica del modello su ogni processo e sincronizza i gradienti. È utile quando l'intero stato di addestramento entra in ogni GPU e si desidera elaborare più dati in parallelo; non unisce la VRAM in un unico pool contiguo.

Fully Sharded Data Parallel può distribuire parametri, gradienti e stato dell'ottimizzatore. Usalo quando la pressione sulla memoria giustifica lo sharding e tieni conto della comunicazione aggiuntiva e della complessità dei checkpoint distribuiti.

La precisione mista e il checkpointing delle attivazioni sono scelte separate. Convalida il comportamento numerico per la precisione inferiore; misura il costo di calcolo del ricalcolo delle attivazioni quando il checkpointing consente di risparmiare memoria.

Avvia un pilota su singolo nodo

Lo script di addestramento deve inizializzare l'esecuzione distribuita e assegnare un processo a ciascuna GPU usando le informazioni sul rango locale. Fai corrispondere il numero di processi alle GPU visibili. Quello che segue è un esempio di avvio per uno script consapevole della distribuzione, non un'implementazione completa di addestramento.

torchrun --standalone --nproc-per-node=4 \
  train.py --config configs/pilot.yaml

Esegui questa operazione solo su un nodo provisionato. La demo locale AnchorGPU non esegue addestramento né alloca GPU remote.

Seleziona l’hardware in base al risultato del progetto pilota

Usa A100 come base 80 GB CUDA a prezzo inferiore e testa H100 se il carico di lavoro dispone di un percorso specifico Hopper utile. H200 offre una configurazione di memoria CUDA più ampia. MI300X offre maggiore capacità per acceleratore in questo catalogo, a condizione che l'intera applicazione sia qualificata su ROCm.

Per AMD, verifica estensioni personalizzate, kernel, versioni dei pacchetti e l'immagine PyTorch testata con ROCm come insieme completo. La compatibilità a livello di framework non convalida ogni operazione opzionale.

Testa il ripristino, non solo il salvataggio

Registra modello, ottimizzatore, scheduler, passo di addestramento, configurazione e stato dello scaler a precisione mista, ove pertinente. Salva un checkpoint, termina il processo, quindi ripristina e riprendi prima di impegnarti nell'esecuzione prolungata.

Utilizza un metodo di checkpoint appropriato allo stato distribuito. Verifica che gli artefatti salvati possano essere letti indipendentemente dal processo originale e che l'output della valutazione rimanga entro la tolleranza prevista.

Prevedi un budget per l'intera pipeline

Includi download, pre-elaborazione, caricamento dei dati, convalida, checkpointing, esportazione e copia degli output fuori dal nodo. Misura il throughput insieme a memoria, stalli di caricamento dati, tempo di comunicazione, durata del checkpoint e qualità della convalida.

Un termine di 7 giorni è utile per un passaggio limitato di compatibilità e profilazione. Scegli una prenotazione di 30 giorni solo dopo aver stimato il lavoro utile e il margine operativo. Più GPU aiutano solo quando il calcolo aggiuntivo supera i limiti di comunicazione e della pipeline di input.