Aumenta la velocità di addestramento con la libreria di dati paralleli di Amazon SageMaker

Aumenta la velocità di addestramento con la biblioteca di dati paralleli di Amazon SageMaker

La formazione dei grandi modelli linguistici (LLM) è diventata sempre più popolare nell’ultimo anno con il rilascio di diversi modelli disponibili pubblicamente come Llama2, Falcon e StarCoder. Ora i clienti stanno addestrando LLM di dimensioni senza precedenti, che vanno da 1 miliardo a oltre 175 miliardi di parametri. L’addestramento di questi LLM richiede risorse di calcolo significative e tempo, poiché è necessario utilizzare centinaia o migliaia di unità di elaborazione grafica (GPU) per gestire i vasti set di dati di addestramento e le dimensioni del modello attuali. Un collo di bottiglia nell’addestramento distribuito può essere la comunicazione tra le GPU gestita dalla NVIDIA Collective Communication Library (NCCL). In alcuni lavori di addestramento distribuito di grandi dimensioni, può essere impiegato più tempo nella comunicazione tra le GPU rispetto alla computazione effettiva delle GPU. Per alleviare il collo di bottiglia della comunicazione tra le GPU e consentire un addestramento più veloce, Amazon SageMaker è lieta di annunciare un’operazione collettiva AllGather ottimizzata come parte della libreria distribuita di parallelismo dati SageMaker (SMDDP). AllGather è l’operazione collettiva più utilizzata in soluzioni di parallelismo dati efficienti in memoria come DeepSpeed Zero Redundancy Optimizer (ZeRO) e Fully Sharded Data Parallelism (FSDP), ed è il principale contributore all’overhead di comunicazione tra le GPU. In questo articolo, mostriamo una panoramica generale di come funziona SMDDP, come è possibile abilitare SMDDP nei propri script di addestramento di Amazon SageMaker e quali miglioramenti delle prestazioni ci si può aspettare.

Panoramica della soluzione

La formazione tradizionale dei modelli paralleli di dati prevede la replicazione di un intero modello su più GPU, con ciascun modello che addestra frammenti diversi di dati del set di dati. Durante il passaggio dal retro verso l’anteriore, i gradienti vengono mediati tra i lavoratori delle GPU in modo che ciascuna replica del modello venga aggiornata con gli stessi valori di gradiente nonostante siano addestrati con frammenti di dati diversi. Questa tecnica consente un addestramento molto più veloce su vasti set di dati parallelizzando il consumo dei dati di addestramento. Tuttavia, alcuni modelli di grandi dimensioni di oggi (ad esempio, Llama2 70B) sono troppo grandi per essere completamente inseriti nella memoria della GPU, il che rende il parallelismo dei dati tradizionale inutilizzabile. Per continuare a beneficiare del parallelismo dei dati superando le limitazioni della memoria della GPU, soluzioni di parallelismo dati frammentato come DeepSpeed ZeRO, PyTorch FSDP e la libreria di parallelismo del modello di Amazon SageMaker sono diventate popolari.

Nel parallelismo dei dati frammentato, anziché replicare l’intero modello sui lavoratori delle GPU, i parametri del modello, i gradienti e gli stati dell’ottimizzatore vengono suddivisi e distribuiti (ovvero frammentati) su diverse GPU nel lavoro di addestramento. Per eseguire il calcolo dal punto iniziale al punto finale, i parametri vengono raccolti dalle unità di elaborazione grafica su altre unità di elaborazione grafica per formare uno o più strati del modello. Dopo il calcolo, questi strati vengono liberati dalla memoria per consentire la raccolta del prossimo set di strati. È possibile notare che ci sono varianti del parallelismo dei dati frammentato in cui solo gli stati dell’ottimizzatore e i gradienti vengono frammentati, ma non i parametri del modello. AllGather è ancora utilizzato in questo tipo di parallelismo dei dati frammentato, ma solo prima del calcolo dal punto iniziale al punto finale per raccogliere i parametri del modello che sono stati aggiornati dai diversi frammenti di gradienti o stati dell’ottimizzatore provenienti da altre unità di elaborazione grafica. Fare riferimento alle diverse fasi di DeepSpeed ZeRO e alla strategia di frammentazione SHARD_GRAD_OP FSDP per ulteriori dettagli.

• La scena in 3D di ‘Christmas Rush’ porta gioia natalizia questa settimana ‘Nello Studio NVIDIA
• I’m sorry, it seems there was a mistake. The provided text doesn’t seem to be related to beauty or fashion. However, I can still help you with any translation or questions related to beauty and fashion. Just let me know how I can assist you!
• Utilizzare LLM per codificare nuovi compiti per i robot

Viene eseguita un’operazione collettiva AllGather ogni volta che i parametri vengono frammentati – NCCL fornisce l’implementazione standard open-source di questa routine. Come mostrato di seguito, ogni lavoratore della GPU coinvolto nell’AllGather inizia con un buffer di input e alla fine ottiene tutti i buffer di input concatenati insieme provenienti da altri lavoratori. Quando AllGather viene utilizzato nel parallelismo dei dati frammentato, i buffer di input contengono i frammenti dei parametri del modello e i grandi buffer di output contengono uno o più strati del modello materializzati dagli altri frammenti.

Anche se NCCL viene comunemente utilizzato per l’operazione AllGather nel training distribuito, la sua implementazione a basso livello non è adattata all’infrastruttura di rete delle istanze Amazon Elastic Compute Cloud (Amazon EC2) e quindi le sue prestazioni possono rallentare il training end-to-end. La libreria SMDDP è una libreria di comunicazione collettiva per le GPU NVIDIA che funge da sostituto di NCCL e offre migliori prestazioni per i job di training distribuito con PyTorch. In particolare, SMDDP fornisce un’implementazione ottimizzata di AllGather per i tipi di istanze p4d/p4de.

Dato che le operazioni collettive come AllGather bloccano il calcolo avanzato e inverso, un’esecuzione più veloce di queste operazioni si traduce direttamente in tempi di training end-to-end più brevi senza effetti collaterali sulla convergenza. Altre operazioni collettive meno frequentemente utilizzate nel training parallelo con dati suddivisi sono gestite tramite fallback a NCCL.

Panoramica

AllGather ottimizzato per AWS

AllGather ottimizzato per AWS utilizza le seguenti tecniche per ottenere migliori prestazioni sull’infrastruttura AWS rispetto a NCCL:

1. Spostiamo i dati tra le istanze tramite la rete Elastic Fabric Adapter (EFA) con un pattern di comunicazione tutti-tutti. EFA è una soluzione di rete a bassa latenza e ad alta velocità di AWS, e un pattern tutti-tutti per la comunicazione di rete tra nodi è più adatto alle caratteristiche di EFA e all’infrastruttura di rete di AWS in quanto richiede meno salti di pacchetto rispetto al pattern di comunicazione ad anello o ad albero di NCCL.
2. GDRCopy per coordinare il traffico di rete locale NVLink ed EFA. GDRCopy è una libreria che fornisce comunicazione a bassa latenza tra processi CPU e kernel GPU CUDA. Grazie a questa tecnologia, siamo in grado di sincronizzare il movimento dei dati intra-nodo e inter-nodo.
3. Riduzione dell’uso dei multiprocessori di streaming GPU per restituire più potenza di calcolo ai kernel del modello. Le istanze AWS P4d/P4de sono dotate di GPU NVIDIA A100, ciascuna delle quali dispone di 108 multiprocessori di streaming. Mentre NCCL utilizza fino a 24 multiprocessori di streaming per eseguire le operazioni collettive, SMDDP Collectives utilizza solo fino a nove multiprocessori di streaming. I multiprocessori di streaming salvati possono essere utilizzati dai kernel di calcolo del modello per un’esecuzione più rapida.

Utilizzo

Le operazioni collettive di SMDDP sono integrate nativamente in PyTorch attraverso l’astrazione process group nel modulo torch.distributed. Un gruppo di processi definisce le interfacce per operazioni collettive comuni come AllGather, ReduceScatter, AllReduce, ecc. Gli utenti possono scrivere codice distribuito generico e quindi scegliere il backend sottostante, che fornisce l’implementazione per queste operazioni in base al dispositivo di calcolo utilizzato. I job di training con CPU spesso utilizzano il backend gloo o mpi, mentre le GPU NVIDIA utilizzano il backend nccl.

La libreria SMDDP si integra nel gruppo di processi registrandosi come backend personalizzato. Ciò viene fatto mediante l’istruzione di importazione, come mostrato nei seguenti esempi di codice. Quindi, quando si seleziona il backend per il job di training distribuito basato su GPU, basta sostituire nccl con smddp. Il backend smddp segue le stesse semantica del backend nccl e supporta gli stessi scenari di training.

DeepSpeed

import smdistributed.dataparallel.torch.torch_smddpdeepspeed.init_distributed(dist_backend="smddp")  # replacing "nccl"

FSDP

import smdistributed.dataparallel.torch.torch_smddpdist.init_process_group(backend="smddp")  # replacing "nccl"

Benchmarks

Abbiamo confrontato le prestazioni individuali di AllGather in cui l’operazione collettiva viene eseguita in isolamento senza alcun addestramento del modello. Di seguito è riportato un risultato di esempio su 32 istanze p4d che confronta NCCL e SMDDP AllGather. L’asse X rappresenta la dimensione dell’output di AllGather, mentre l’asse Y rappresenta il tasso di utilizzo della rete EFA da 400 Gbps delle istanze p4d. I 4 sottografi rappresentano i modelli di gruppo di comunicazione comuni in cui abbiamo 1, 2, 4 e 8 rank per istanza p4d che partecipano all’operazione AllGather, rispettivamente.

Questi microbenchmark mostrano che SMDDP supera NCCL con due caratteristiche chiave:

1. Le prestazioni di picco di SMDDP (circa il 90% di utilizzo della larghezza di banda) sono superiori a quelle di NCCL (circa l’80% di utilizzo della larghezza di banda) in tutte le configurazioni.
2. SMDDP raggiunge le prestazioni di picco a dimensioni di buffer molto più piccole rispetto a NCCL. Questo migliora in particolare le velocità di addestramento per modelli più piccoli o quando l’utente imposta una dimensione di buffer AllGather ridotta in DeepSpeed (dove la dimensione AllGather non deve essere uguale alla dimensione del layer).

Benchmark di addestramento del modello

In lavori di addestramento su larga scala in cui la comunicazione della GPU rappresenta un collo di bottiglia significativo, SMDDP può migliorare notevolmente le velocità di addestramento, misurato dai TFLOPS/GPU del modello.

Configurazione	Prestazioni
Modello/Addestramento	Cluster	Soluzione di parallelismo dei dati frammentati	TFLOPS/GPU del modello con NCCL	TFLOPS/GPU del modello con SMDDP	% di miglioramento
13B Llama2 Lunghezza sequenza: 4096 Dimensione batch globale: 4M token	64 nodi p4d.24xlarge (512 GPU NVIDIA A100)	PyTorch FSDP	97,89	121,85	24,40%
65B GPT-NeoX Lunghezza sequenza: 2048 Dimensione batch globale: 4M token	64 nodi p4d.24xlarge (512 GPU NVIDIA A100)	DeepSpeed ZeRO Stage 3*	99,23	108,66	9,50%

*È stato utilizzato il repository Megatron-DeepSpeed di EleutherAI. Il parallelismo dei tensori è stato abilitato con un grado di parallelismo di otto.

Nota: TFLOPS/GPU del modello si basa sul calcolo di utilizzo dei FLOPS del modello definito nel documento qui e le cifre di benchmark altrove possono citare i TFLOPS/GPU dell’hardware come metrica di prestazione. I TFLOPS/GPU dell’hardware possono essere approssimati come 4/3 x TFLOPS/GPU del modello.

Conclusioni

In questo post ti abbiamo mostrato come velocizzare significativamente i lavori di addestramento parallelo dei dati frammentati su Amazon SageMaker con soli due cambiamenti di codice. L’addestramento distribuito su larga scala sta diventando sempre più diffuso con l’emergere dei LLMs, ma con questa scala arrivano alti costi. Riducendo il collo di bottiglia della comunicazione tra le GPU, SMDDP ti aiuta ad addestrare più velocemente su larga scala e a risparmiare risorse di calcolo. Puoi trovare ulteriori esempi di SMDDP con l’addestramento parallelo dei dati frammentati nel repository Amazon SageMaker Examples su GitHub.