Introduzione al parallelismo dei modelli

Il parallelismo dei modelli è un metodo di addestramento distribuito in cui il modello di deep learning è partizionato su più dispositivi, all'interno o tra istanze. Questa pagina introduttiva fornisce una panoramica di alto livello sul parallelismo dei modelli, una descrizione di come può aiutare a superare i problemi che sorgono durante l'addestramento di modelli DL che in genere sono di dimensioni molto grandi ed esempi di ciò che offre la libreria SageMaker parallela del modello per aiutare a gestire le strategie parallele dei modelli e il consumo di memoria.

Che cos'è il parallelismo dei modelli?

L'aumento delle dimensioni dei modelli di deep learning (livelli e parametri) consente di ottenere una maggiore precisione per attività complesse come la visione artificiale e l'elaborazione del linguaggio naturale. Tuttavia, esiste un limite alla dimensione massima del modello che è possibile inserire nella memoria di un singolo modello. GPU Durante l'addestramento dei modelli DL, le limitazioni di GPU memoria possono essere ostacolate nei seguenti modi:

• Limitano le dimensioni del modello che è possibile addestrare, poiché l'ingombro di memoria di un modello si ridimensiona proporzionalmente al numero di parametri.

• Limitano la dimensione per GPU lotto durante l'addestramento, riducendo l'GPUutilizzo e l'efficienza della formazione.

Per superare i limiti associati all'addestramento di un modello su un singoloGPU, SageMaker fornisce la libreria parallela di modelli per aiutare a distribuire e addestrare i modelli DL in modo efficiente su più nodi di calcolo. Inoltre, con la libreria, è possibile ottenere la formazione distribuita più ottimizzata utilizzando dispositivi EFA supportati, che migliorano le prestazioni della comunicazione tra i nodi con bassa latenza, velocità effettiva elevata e bypass del sistema operativo.

Stima dei requisiti di memoria prima di utilizzare il parallelismo dei modelli

Prima di utilizzare la libreria SageMaker model parallel, considera quanto segue per avere un'idea dei requisiti di memoria necessari per l'addestramento di modelli DL di grandi dimensioni.

Per un processo di formazione che utilizza gli ottimizzatori AMP (FP16) e Adam, la GPU memoria richiesta per parametro è di circa 20 byte, che possiamo suddividere come segue:

• Un FP16 parametro ~ 2 byte

• Un FP16 gradiente ~ 2 byte

• Uno stato di FP32 ottimizzazione di ~ 8 byte basato sugli ottimizzatori Adam

• Una FP32 copia del parametro ~ 4 byte (necessaria per il funzionamento (OAoptimizer apply))

• Una FP32 copia di gradient ~ 4 byte (necessaria per il funzionamento OA)

Anche per un modello DL relativamente piccolo con 10 miliardi di parametri, può richiedere almeno 200 GB di memoria, che è molto più grande della memoria tipica (ad esempio, NVIDIA A100 con 40 GB/80 GB di GPU memoria e V100 con 16/32 GB) disponibile su una singola unità. GPU Tieni presente che oltre ai requisiti di memoria per gli stati del modello e dell'ottimizzatore, ci sono altri utenti di memoria, come le attivazioni generate nel forward pass. La memoria richiesta può essere molto superiore a 200 GB.

Per la formazione distribuita, ti consigliamo di utilizzare istanze Amazon EC2 P3 e P4 con Tensor Core rispettivamente NVIDIA V100 e A100. GPUs Per ulteriori dettagli su specifiche quali CPU core, RAM volume di storage collegato e larghezza di banda di rete, consulta la sezione Accelerated Computing nella pagina Amazon EC2 Instance Types.

Anche con le istanze di elaborazione accelerata, è ovvio che i modelli con circa 10 miliardi di parametri come Megatron-LM e T5 e i modelli ancora più grandi con centinaia di miliardi di parametri, come -3, non possono inserire repliche di modelli in ogni dispositivo. GPT GPU

In che modo la libreria utilizza il parallelismo dei modelli e le tecniche di risparmio della memoria

La libreria comprende vari tipi di funzionalità di parallelismo dei modelli e funzionalità di risparmio di memoria come il partizionamento dello stato dell'ottimizzatore, il checkpoint di attivazione e l'offload dell'attivazione. Tutte queste tecniche possono essere combinate per addestrare in modo efficiente modelli di grandi dimensioni composti da centinaia di miliardi di parametri.

PyTorchParallelismo dei dati condiviso (disponibile per)

Il parallelismo dei dati condivisi è una tecnica di addestramento distribuito che consente di risparmiare memoria che suddivide lo stato di un modello (parametri del modello, gradienti e stati dell'ottimizzatore) all'interno di un gruppo parallelo di dati. GPUs

SageMaker implementa il parallelismo dei dati condivisi attraverso l'implementazione di MIC, una libreria che minimizza la comunicazione su larga scala e discussa nel post del blog Near-linear scaling of gigantic-model training on. AWS

Puoi applicare il parallelismo dei dati partizionati al modello come strategia autonoma. Inoltre, se utilizzi le GPU istanze più performanti dotate di NVIDIA A100 Tensor Core, puoi sfruttare la maggiore velocità di addestramento derivante dalle operazioni offerte da Collectives. GPUs ml.p4d.24xlarge AllGather SMDDP

Per approfondire il parallelismo dei dati condivisi e imparare a configurarlo o utilizzare una combinazione del parallelismo dei dati condivisi con altre tecniche come il parallelismo tensoriale e l'addestramento, vedi. FP16 Parallelismo dei dati partizionati

PyTorch TensorFlowParallelismo delle pipeline (disponibile per e)

Il parallelismo della pipeline partiziona l'insieme di livelli o operazioni sull'insieme di dispositivi, lasciando intatta ogni operazione. Quando specificate un valore per il numero di partizioni del modello (pipeline_parallel_degree), il numero totale di GPUs (processes_per_host) deve essere divisibile per il numero delle partizioni del modello. Per configurarlo correttamente, devi specificare i valori corretti per i parametri pipeline_parallel_degree e processes_per_host. Il semplice calcolo è il seguente:

(pipeline_parallel_degree) x (data_parallel_degree) = processes_per_host

La libreria si occupa di calcolare il numero di repliche del modello (chiamate anche data_parallel_degree) in base ai due parametri di input forniti.

Ad esempio, se impostate "pipeline_parallel_degree": 2 e "processes_per_host": 8 utilizzate un'istanza ML con otto GPU worker, ad esempioml.p3.16xlarge, la libreria imposta automaticamente il modello distribuito attraverso il parallelismo dei GPUs dati a quattro vie. L'immagine seguente illustra come un modello viene distribuito tra gli otto sistemi, GPUs ottenendo un parallelismo dei dati a quattro vie e un parallelismo di pipeline bidirezionale. Ogni replica del modello, dove la definiamo come un gruppo parallelo di pipeline e la etichettiamo comePP_GROUP, è partizionata su due. GPUs Ogni partizione del modello è assegnata a quattroGPUs, dove le quattro repliche di partizione si trovano in un gruppo parallelo di dati e sono etichettate come. DP_GROUP Senza il parallelismo tensoriale, il gruppo parallelo della pipeline è essenzialmente il gruppo parallelo del modello.

Per approfondire il parallelismo delle pipeline, consulta Caratteristiche principali della SageMaker Model Parallelism Library.

Per iniziare a eseguire il modello utilizzando il parallelismo della pipeline, consulta Run a Distributed SageMaker Training Job with the SageMaker Model Parallel Library.

Parallelismo tensoriale (disponibile per) PyTorch

Il parallelismo tensoriale divide i singoli livelli, o nn.Modules, tra dispositivi, per essere eseguiti in parallelo. La figura seguente mostra l'esempio più semplice di come la libreria divide un modello con quattro livelli per ottenere un parallelismo tensoriale bidirezionale ("tensor_parallel_degree": 2). Gli strati di ogni replica del modello sono divisi in due e distribuiti in due. GPUs In questo caso di esempio, la configurazione parallela del modello include anche "pipeline_parallel_degree": 1 e "ddp": True (utilizza il PyTorch DistributedDataParallel pacchetto in background), quindi il grado di parallelismo dei dati diventa otto. La libreria gestisce la comunicazione tra le repliche del modello distribuite dai tensori.

L'utilità di questa funzionalità sta nel fatto che è possibile selezionare livelli specifici o un sottoinsieme di livelli per applicare il parallelismo tensoriale. Per approfondire il parallelismo tensoriale e altre funzionalità di risparmio di memoria e per imparare a impostare una combinazione di parallelismo tensoriale e di pipeline PyTorch, vedete. Parallelismo tensoriale

Condivisione dello stato dell'ottimizzatore (disponibile per) PyTorch

Per capire come la libreria esegue il partizionamento dello stato dell'ottimizzatore, prendi in considerazione un semplice modello di esempio con quattro livelli. L'idea chiave nell'ottimizzazione dello state sharding è che non è necessario replicare lo stato dell'ottimizzatore in tutti i tuoi. GPUs Piuttosto, una singola replica dello stato dell'ottimizzatore viene suddivisa tra classificazioni parallele ai dati, senza ridondanza tra i dispositivi. Ad esempio, GPU 0 contiene lo stato dell'ottimizzatore per il primo livello, l'GPU1 successivo contiene lo stato dell'ottimizzatore per L2 e così via. La seguente figura animata mostra una propagazione all'indietro con la tecnica di partizionamento dello stato dell'ottimizzatore. Al termine della propagazione all'indietro, è previsto il tempo di calcolo e di rete necessario all'operazione optimizer apply (OA) per aggiornare gli stati dell'ottimizzatore e all'operazione all-gather (AG) per aggiornare i parametri del modello per l'iterazione successiva. Soprattutto, l'reduceoperazione può sovrapporsi al calcolo su GPU 0, ottenendo una propagazione all'indietro più efficiente in termini di memoria e più rapida. Nell'attuale implementazione, le operazioni AG e OA non si sovrappongono a compute. Può comportare un calcolo esteso durante l'operazione AG, quindi potrebbe esserci un compromesso.

Per ulteriori informazioni su come utilizzare questa funzionalità, consulta Optimizer State Sharding.

Attivazione, offload e checkpoint (disponibile per) PyTorch

Per risparmiare GPU memoria, la libreria supporta il checkpoint di attivazione per evitare di archiviare le attivazioni interne nella GPU memoria per i moduli specificati dall'utente durante il passaggio in avanti. La libreria ricalcola queste attivazioni durante il passaggio all'indietro. Inoltre, la funzione di scaricamento dell'attivazione scarica le attivazioni memorizzate in CPU memoria e le recupera GPU durante il passaggio all'indietro per ridurre ulteriormente l'ingombro della memoria di attivazione. Per ulteriori informazioni su come utilizzare queste funzionalità, consulta Activation Checkpoint e Activation Offloading.

Scelta delle tecniche giuste per il modello

Per ulteriori informazioni sulla scelta delle tecniche e delle configurazioni corrette, consulta SageMaker Distributed Model Parallel Practices and Configuration Tips and Pitfalls.