Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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 parallela dei modelli SageMaker per aiutare a gestire le strategie di parallelismo 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 una singola GPU. Durante l'addestramento dei modelli DL, le limitazioni della memoria della GPU possono rappresentare un ostacolo nei seguenti modi:

Per superare i limiti associati all'addestramento di un modello su una singola GPU, 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 un addestramento distribuito più ottimizzato utilizzando dispositivi supportati da EFA, che migliorano le prestazioni della comunicazione tra i nodi con bassa latenza, throughput elevato e bypass del sistema operativo.

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

Prima di utilizzare la libreria di parallelismo dei modelli SageMaker, 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 addestramento che utilizza gli ottimizzatori AMP (FP16) e Adam, la memoria GPU richiesta per parametro è di circa 20 byte, che possiamo suddividere come segue:

Anche per un modello DL relativamente piccolo con 10 miliardi di parametri, possono essere necessari almeno 200 GB di memoria, che è una dimensione molto più grande della tipica memoria GPU (ad esempio, NVIDIA A100 con 40 GB/80 GB di memoria e V100 con 16/32 GB) disponibile su una singola 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 l’addestramento distribuito, ti consigliamo di utilizzare istanze Amazon EC2 P3 e P4 con GPU NVIDIA V100 e A100 Tensor Core rispettivamente. Per ulteriori dettagli sulle specifiche quali core della CPU, RAM, volume di archiviazione collegato e larghezza di banda della rete, consulta la sezione Elaborazione accelerata nella pagina Tipi di istanze Amazon EC2.

Anche con le istanze a calcolo accelerato, è 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 GPT-3 non possono contenere repliche di modelli in ogni dispositivo 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.

Parallelismo dei dati partizionati (disponibile per PyTorch)

La parallelizzazione dei dati sottoposti a sharding è una tecnica di addestramento distribuito a risparmio di memoria che suddivide lo stato di un modello (parametri del modello, gradienti e stati dell’ottimizzatore) tra le GPU all’interno di un gruppo parallelo di dati.

SageMaker AI implementa la parallelizzazione dei dati sottoposti a sharding attraverso l’implementazione di MiCS, una libreria che minimizza la comunicazione su scala e discussa nel post del blog Near-linear scaling of gigantic-model training on AWS.

Puoi applicare la parallelizzazione dei dati sottoposti a sharding al modello come strategia standalone. Inoltre, se utilizzi le istanze GPU più performanti dotate di GPU NVIDIA A100 Tensor Core, ml.p4d.24xlarge, puoi trarre vantaggio dalla maggiore velocità di addestramento dell’operazione AllGather SMDDP offerta da SMDDP Collectives.

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

Parallelizzazione della pipeline (disponibile per Pytorch e TensorFlow)

Il parallelismo della pipeline partiziona l'insieme di livelli o operazioni sull'insieme di dispositivi, lasciando intatta ogni operazione. Quando specifichi un valore per il numero di partizioni del modello (pipeline_parallel_degree), il numero totale di GPU (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 imposti "pipeline_parallel_degree": 2 e "processes_per_host": 8 per utilizzare un'istanza ML con otto GPU worker, ad esempio ml.p3.16xlarge, la libreria configura automaticamente il modello distribuito tra le GPU e il parallelismo dei dati a quattro vie. L'immagine seguente illustra come un modello viene distribuito tra le otto GPU, ottenendo un parallelismo dei dati a quattro vie e un parallelismo di pipeline bidirezionale. Ogni replica del modello, che definiamo come un gruppo parallelo di pipeline ed etichettiamo come PP_GROUP, è partizionata su due GPU. Ogni partizione del modello è assegnata a quattro GPU, dove le quattro repliche delle partizioni 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 la parallelizzazione delle pipeline, consulta Caratteristiche principali della libreria di parallelismo dei modelli SageMaker.

Per iniziare a eseguire il modello utilizzando il parallelismo delle pipeline, consulta Run a SageMaker Distributed 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). I livelli di ogni replica del modello sono divisi in due e distribuiti in due GPU. In questo caso di esempio, la configurazione parallela del modello include anche "pipeline_parallel_degree": 1 e "ddp": True (utilizza il pacchetto PyTorch DistributedDataParallel 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 per PyTorch e per imparare a impostare una combinazione di parallelismo della pipeline e del tensore, consulta Parallelismo tensoriale.

Partizionamento 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 del partizionamento dello stato sta nel fatto che non è necessario replicare lo stato dell'ottimizzatore in tutte le GPU. Piuttosto, una singola replica dello stato dell'ottimizzatore viene suddivisa tra classificazioni parallele ai dati, senza ridondanza tra i dispositivi. Ad esempio, la GPU 0 contiene lo stato dell'ottimizzatore per il primo livello, la GPU 1 successiva 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'operazione reduce può sovrapporsi al calcolo sulla 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 dell'offload e del checkpoint (disponibile per PyTorch)

Per risparmiare memoria della GPU, la libreria supporta il checkpoint di attivazione per evitare di memorizzare le attivazioni interne nella memoria della GPU 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 offload dell'attivazione scarica le attivazioni memorizzate nella memoria della CPU e le recupera sulla 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 SageMaler Distributed Model Parallel Best Practices e Configuration Tips and Pitfalls.