Accelerazione dei modelli di visione-linguaggio BridgeTower su Habana Gaudi2

'Accelerazione modelli visione-linguaggio BridgeTower su Habana Gaudi2'

Optimum Habana v1.6 su Habana Gaudi2 raggiunge quasi il triplo della velocità rispetto a A100 durante il fine-tuning di BridgeTower, un modello vision-language all’avanguardia. Due nuove funzionalità contribuiscono al miglioramento delle prestazioni: il caricamento dei dati accelerato dall’hardware e un’implementazione rapida di DDP.

Queste tecniche si applicano a qualsiasi altro carico di lavoro limitato dal caricamento dei dati, il che accade frequentemente per molti tipi di modelli di visione. Questo post ti guiderà attraverso il processo e il benchmark che abbiamo utilizzato per confrontare il fine-tuning di BridgeTower su Habana Gaudi2 e Nvidia A100 80GB. Mostra anche quanto sia facile sfruttare queste funzionalità nei modelli basati su transformers.

BridgeTower

Nel passato recente, i modelli Vision-Language (VL) hanno acquisito enorme importanza e mostrato dominanza in una varietà di compiti VL. Gli approcci più comuni sfruttano encoder uni-modali per estrarre rappresentazioni dalle rispettive modalità. Queste rappresentazioni vengono poi fuse insieme o alimentate in un encoder cross-modal. Per gestire efficientemente alcune limitazioni e restrizioni delle prestazioni nell’apprendimento delle rappresentazioni VL, BridgeTower introduce più strati di bridge che creano una connessione tra i livelli superiori degli encoder uni-modali e ogni livello dell’encoder cross-modal. Ciò consente un effettivo allineamento cross-modal dal basso verso l’alto e una fusione tra rappresentazioni visive e testuali a diversi livelli semantici nell’encoder cross-modal.

Pre-allenato con solo 4M di immagini (vedi i dettagli qui sotto), BridgeTower raggiunge prestazioni all’avanguardia su vari compiti di visione-language. In particolare, BridgeTower raggiunge un’accuratezza del 78,73% sul set di test-std di VQAv2, superando il modello all’avanguardia precedente (METER) del 1,09% utilizzando gli stessi dati di pre-allenamento e costi computazionali e parametri aggiuntivi quasi trascurabili. In particolare, quando si scala ulteriormente il modello, BridgeTower raggiunge un’accuratezza dell’81,15%, superando modelli pre-allenati su dataset molto più grandi.

• Creazione di un generatore di app web con modelli di ML aperti
• Sviluppa LLMs con i Punti di Inference di Hugging Face
• Creazione di giochi web potenziati da ML con Transformers.js

Hardware

Nvidia A100 Tensor Core GPU include la tecnologia Tensor Core di terza generazione. Sebbene sia stata rilasciata una generazione più recente di GPU (H100) di recente, questa è ancora la GPU più veloce che si trova nella maggior parte dei fornitori cloud. Qui utilizziamo la variante con memoria da 80GB, che offre anche una larghezza di banda di memoria più veloce rispetto alla variante da 40GB.

Habana Gaudi2 è l’acceleratore hardware AI di seconda generazione progettato da Habana Labs. Un singolo server contiene 8 dispositivi acceleratori chiamati HPUs con 96GB di memoria ciascuno. Dai un’occhiata al nostro post sul blog precedente per una presentazione più approfondita e una guida su come accedervi tramite Intel Developer Cloud. A differenza di molti acceleratori AI sul mercato, le funzionalità avanzate sono molto facili da applicare per sfruttare al massimo Gaudi2 con Optimum Habana, il che consente agli utenti di portare script compatibili con Transformers su Gaudi con solo un cambio di 2 righe.

Benchmark

Per il benchmark del training, andremo a fare il fine-tuning di un checkpoint di BridgeTower Large composto da 866M di parametri. Questo checkpoint è stato pre-allenato sulla lingua inglese utilizzando masked language modeling, image-text matching e image-text contrastive loss su Conceptual Captions, SBU Captions, MSCOCO Captions e Visual Genome.

Successivamente faremo un ulteriore fine-tuning di questo checkpoint sul dataset del New Yorker Caption Contest, che consiste in vignette tratte da The New Yorker e le didascalie più votate.

Gli iperparametri sono gli stessi per entrambi gli acceleratori, ad eccezione della dimensione del batch: siamo riusciti a inserire 40 campioni su Gaudi2 contro i 32 su A100. Puoi consultarli qui per Gaudi2 e qui per A100.

Quando si lavora con dataset che coinvolgono immagini, il caricamento dei dati è spesso un collo di bottiglia perché molte operazioni costose vengono eseguite sulla CPU (decodifica delle immagini, aumenti dell’immagine) e poi le immagini complete vengono inviate ai dispositivi di training. Idealmente, vorremmo inviare solo byte grezzi ai dispositivi e quindi eseguire la decodifica e le varie trasformazioni delle immagini sul dispositivo. Ma vediamo prima come allocare facilmente più risorse al caricamento dei dati per accelerare le tue esecuzioni.

Utilizzo di dataloader_num_workers

Quando il caricamento delle immagini viene eseguito sulla CPU, un modo rapido per velocizzarlo sarebbe allocare più sottoprocessi per il caricamento dei dati. Questo è molto facile da fare con gli TrainingArguments di Transformers (o il loro corrispettivo Optimum Habana GaudiTrainingArguments): puoi utilizzare l’argomento dataloader_num_workers=N per impostare il numero di sottoprocessi (N) allocati sulla CPU per il caricamento dei dati.

Il valore predefinito è 0, il che significa che i dati vengono caricati nel processo principale. Questo potrebbe non essere ottimale poiché il processo principale ha molte cose da gestire. Possiamo impostarlo su 1 per avere un sottoprocesso completamente dedicato al caricamento dei dati. Quando vengono allocati diversi sottoprocessi, ognuno di essi sarà responsabile della preparazione di un batch. Ciò significa che il consumo di RAM aumenterà con il numero di worker. Una raccomandazione sarebbe di impostarlo sul numero di core della CPU, ma quei core potrebbero non essere completamente liberi quindi dovrai provarlo per trovare la migliore configurazione.

Eseguiamo i due seguenti esperimenti:

• un’esecuzione di precisione mista (bfloat16 / float) distribuita su 8 dispositivi in cui il caricamento dei dati viene eseguito dallo stesso processo di tutto il resto (cioè dataloader_num_workers=0)
• un’esecuzione di precisione mista (bfloat16 / float) distribuita su 8 dispositivi con 1 sottoprocesso dedicato al caricamento dei dati (cioè dataloader_num_workers=1)

Ecco le velocità di attraversamento che abbiamo ottenuto su Gaudi2 e A100:

Vediamo innanzitutto che Gaudi2 è x2,16 più veloce di A100 con dataloader_num_workers=1 e x2,53 più veloce con dataloader_num_workers=0, che è in linea con gli acceleramenti che abbiamo segnalato in precedenza!

In secondo luogo, vediamo che allocare più risorse per il caricamento dei dati può portare a accelerazioni facili: x1,20 su Gaudi2 e x1,41 su A100.

Abbiamo anche eseguito esperimenti con diversi sottoprocessi dedicati al caricamento dei dati, ma le prestazioni non sono state migliori rispetto a dataloader_num_workers=1 sia per Gaudi2 che per A100. Pertanto, utilizzare dataloader_num_workers=1 è di solito un buon primo modo per accelerare le esecuzioni che coinvolgono immagini!

I log di Tensorboard possono essere visualizzati qui per Gaudi2 e qui per A100.

Optimum Habana’s fast DDP ottimale

Prima di approfondire come eseguire il caricamento dei dati accelerato dall’hardware, diamo un’occhiata a un altro modo molto semplice per velocizzare le tue esecuzioni distribuite su Gaudi. La nuova versione di Optimum Habana, la versione 1.6.0, ha introdotto una nuova funzionalità che consente agli utenti di scegliere la strategia di distribuzione da utilizzare:

• distribution_strategy="ddp" per utilizzare PyTorch DistributedDataParallel (DDP)
• distribution_strategy="fast_ddp" per utilizzare un’implementazione più leggera e solitamente più veloce

Optimum Habana’s fast DDP non suddivide i gradienti dei parametri in bucket come fa DDP. Utilizza anche i grafici HPU per raccogliere i gradienti in tutti i processi e quindi aggiornarli (dopo l’esecuzione di all_reduce) con un minimo overhead dell’host. Puoi controllare questa implementazione qui.

Semplicemente utilizzando distribution_strategy="fast_ddp" (e mantenendo dataloader_num_workers=1) su Gaudi2 otteniamo 705,9 campioni/s. Questo è x1,10 più veloce rispetto a DDP e x2,38 più veloce rispetto ad A100!

Quindi aggiungendo solo due argomenti di addestramento (dataloader_num_workers=1 e distribution_strategy="fast_ddp") abbiamo ottenuto un’accelerazione di x1,33 su Gaudi2 e un’accelerazione di x2,38 rispetto ad A100 con dataloader_num_workers=1.

Caricamento dei dati accelerato dall’hardware con Optimum Habana

Per accelerazioni ancora maggiori, ora stiamo per spostare quante più operazioni di caricamento dei dati possibile dalla CPU ai dispositivi dell’acceleratore (cioè HPUs su Gaudi2 o GPU su A100). Questo può essere fatto su Gaudi2 utilizzando la pipeline multimediale di Habana.

Dato un dataset, la maggior parte dei dataloader segue la seguente ricetta:

1. Recupera i dati (ad esempio, dove sono archiviate le immagini JPEG sul disco)
2. La CPU legge le immagini codificate
3. La CPU decodifica le immagini
4. La CPU applica le trasformazioni delle immagini per aumentare le immagini
5. Infine, le immagini vengono inviate ai dispositivi (anche se di solito ciò non viene fatto direttamente dal dataloader stesso)

Al posto di eseguire l’intero processo sulla CPU e inviare dati pronti per l’addestramento ai dispositivi, un flusso di lavoro più efficiente sarebbe inviare immagini codificate ai dispositivi prima e quindi eseguire la decodifica delle immagini e le augmentations:

1. Come prima
2. Come prima
3. Le immagini codificate vengono inviate ai dispositivi
4. I dispositivi decodificano le immagini
5. I dispositivi applicano trasformazioni alle immagini per aumentarle

In questo modo possiamo beneficiare della potenza di calcolo dei nostri dispositivi per velocizzare la decodifica delle immagini e le trasformazioni. Notare che ci sono due precauzioni da tenere presente quando si fa ciò:

• Il consumo di memoria dei dispositivi aumenterà, quindi potrebbe essere necessario ridurre la dimensione del batch se non c’è memoria sufficiente. Ciò potrebbe mitigare l’accelerazione ottenuta da questo approccio.
• Se i dispositivi vengono utilizzati intensivamente (100% o vicino ad esso) durante il caricamento dei dati sulla CPU, non aspettarsi alcuna accelerazione quando viene eseguito sui dispositivi in quanto sono già impegnati.

Per implementare questo su Gaudi2, abbiamo pensato a tutto: l’esempio di immagini e testo con contrasto in Optimum Habana fornisce ora una pipeline multimediale pronta all’uso che puoi utilizzare con dataset simili a COCO che contengono testo e immagini! Dovrai solo aggiungere --mediapipe_dataloader al tuo comando per utilizzarla.

Per i lettori interessati, una panoramica a livello più basso è disponibile nella documentazione di Gaudi qui e l’elenco di tutti gli operatori supportati è disponibile lì .

Stiamo per effettuare un benchmark con dataloader_num_workers=1 , distribution_strategy="fast_ddp" e mediapipe_dataloader poiché tutte queste ottimizzazioni sono compatibili tra loro:

Rispetto all’esecuzione precedente con dataloader_num_workers=1 e distribution_strategy="fast_ddp" , abbiamo ottenuto un’accelerazione aggiuntiva di x1.14. Questa esecuzione finale è quindi x1.51 più veloce rispetto alla nostra esecuzione di base su Gaudi2 aggiungendo semplicemente 3 argomenti di addestramento pronti all’uso. È anche x2.70 più veloce di A100 con dataloader_num_workers=1 !

Riproduzione di questo benchmark

Per riprodurre questo benchmark, è necessario prima ottenere l’accesso a Gaudi2 tramite Intel Developer Cloud (vedere questa guida per ulteriori informazioni).

Successivamente, è necessario installare l’ultima versione di Optimum Habana ed eseguire run_bridgetower.py che puoi trovare qui . Ecco come farlo:

pip install optimum[habana]
git clone https://github.com/huggingface/optimum-habana.git
cd optimum-habana/examples/contrastive-image-text
pip install -r requirements.txt

Il comando di base per eseguire lo script è:

python ../gaudi_spawn.py --use_mpi --world_size 8 run_bridgetower.py \
--output_dir /tmp/bridgetower-test \
--model_name_or_path BridgeTower/bridgetower-large-itm-mlm-itc \
--dataset_name jmhessel/newyorker_caption_contest --dataset_config_name matching \
--image_column image --caption_column image_description \
--remove_unused_columns=False \
--do_train --do_eval --do_predict \
--per_device_train_batch_size="40" --per_device_eval_batch_size="16" \
--num_train_epochs 5 \
--learning_rate="1e-5" \
--push_to_hub --report_to tensorboard --hub_model_id bridgetower\
--overwrite_output_dir \
--use_habana --use_lazy_mode --use_hpu_graphs_for_inference --gaudi_config_name Habana/clip \
--throughput_warmup_steps 3 \
--logging_steps 10

che corrisponde al caso --dataloader_num_workers 0 . È quindi possibile aggiungere --dataloader_num_workers 1 , --distribution_strategy fast_ddp e --mediapipe_dataloader per testare altre configurazioni.

Per pubblicare il modello e i log di Tensorboard su Hugging Face Hub, è necessario effettuare il login al proprio account in anticipo con:

huggingface-cli login

Per A100, è possibile utilizzare lo stesso script run_bridgetower.py con alcune piccole modifiche:

• Sostituisci GaudiTrainer e GaudiTrainingArguments con Trainer e TrainingArguments da Transformers
• Rimuovi i riferimenti a GaudiConfig, gaudi_config e HabanaDataloaderTrainer
• Importa set_seed direttamente da Transformers: from transformers import set_seed

I risultati visualizzati in questo benchmark sono stati ottenuti con un’istanza GCP Nvidia A100 80GB con 8 GPUS.

Note che --distribution_strategy fast_ddp e --mediapipe_dataloader sono compatibili solo con Gaudi2 e non funzioneranno con A100.

Conclusioni

Nel trattare le immagini, abbiamo presentato due soluzioni per velocizzare i flussi di lavoro di addestramento: allocare più risorse per il dataloader e decodificare e aumentare le immagini direttamente sui dispositivi di accelerazione anziché sulla CPU. Abbiamo dimostrato che ciò porta a velocizzazioni drastiche nell’addestramento di un modello di visione-linguaggio SOTA come BridgeTower: Habana Gaudi2 con Optimum Habana è quasi 3 volte più veloce di Nvidia A100 80GB con Transformers! E questo è molto facile da usare, poiché è sufficiente fornire alcuni argomenti di addestramento aggiuntivi.

Per andare oltre, non vediamo l’ora di utilizzare i grafici HPU per addestrare modelli ancora più velocemente e di presentare come utilizzare DeepSpeed ZeRO-3 su Gaudi2 per accelerare l’addestramento dei tuoi LLM. Restate sintonizzati!

Se siete interessati ad accelerare i flussi di lavoro di addestramento e inferenza del Machine Learning utilizzando gli ultimi acceleratori hardware e librerie software per l’IA, date un’occhiata al nostro Expert Acceleration Program. Per saperne di più sulle soluzioni Habana, leggete la nostra partnership e contattateli qui. Per saperne di più sugli sforzi di Hugging Face per rendere gli acceleratori hardware per l’IA facili da usare, date un’occhiata al nostro Hardware Partner Program.

Argomenti correlati

• Addestramento e inferenza più veloci: Habana Gaudi-2 vs Nvidia A100 80GB
• Inferenza rapida su modelli di linguaggio di grandi dimensioni: BLOOMZ su acceleratore Habana Gaudi2