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à.
Miglioramenti all'inizializzazione delle comunicazioni collettive
NCCL e Gloo sono librerie di comunicazione fondamentali che consentono operazioni collettive (come all-reduce e broadcast) attraverso processi di formazione distribuiti. Tuttavia, l'inizializzazione tradizionale di NCCL e Gloo può creare intoppi durante il ripristino dei guasti.
Il processo di ripristino standard richiede che tutti i processi si connettano a un TCPStore centralizzato e si coordinino tramite un processo root, il che comporta un oneroso sovraccarico che diventa particolarmente problematico durante i riavvii. Questa progettazione centralizzata crea tre problemi critici: il sovraccarico di coordinamento dovuto alle connessioni TCPStore obbligatorie, i ritardi di ripristino dovuti alla necessità di ripetere l'intera sequenza di inizializzazione a ogni riavvio e la presenza di un singolo punto di errore nel processo root stesso. Ciò impone una procedura di coordinamento costosa e centralizzata ogni volta che il training viene inizializzato o riavviato.
HyperPod La formazione checkpointless elimina queste difficoltà di coordinamento, consentendo un ripristino più rapido dai guasti rendendo l'inizializzazione «root less» e «TCPStoreless».
configurazioni senza root
Per abilitare Rootless, è sufficiente esporre le seguenti variabili di ambiente.
export HPCT_USE_ROOTLESS=1 && \ sysctl -w net.ipv4.ip_local_port_range="20000 65535" && \
HPCT_USE_ROOTLESS: 0 o 1. Usare per attivare e disattivare il sistema rootless
sysctl -w net.ipv4.ip_local_port_range="20000 65535": imposta l'intervallo delle porte di sistema
Vedi l'esempio per abilitare Rootless
Rootless
HyperPod checkpointless training offre nuovi metodi di inizializzazione, Rootless e TCPStoreless, per i gruppi di processi NCCL e Gloo.
L'implementazione di queste ottimizzazioni comporta la modifica di NCCL, Gloo e: PyTorch
Estensione delle API di librerie di terze parti per abilitare le ottimizzazioni Rootless e Storeless NCCL e Gloo mantenendo la compatibilità con le versioni precedenti
Aggiornamento dei backend dei gruppi di processi per utilizzare in modo condizionale percorsi ottimizzati e gestire i problemi di ripristino durante il processo
Bypassare la costosa creazione di TCPStore a livello PyTorch distribuito e mantenere modelli di indirizzi simmetrici tramite contatori di gruppo globali
Il grafico seguente mostra l'architettura delle librerie di formazione distribuite e le modifiche apportate alla formazione senza checkpoint.
NCCL e Gloo
Si tratta di pacchetti indipendenti che svolgono le funzionalità principali delle comunicazioni collettive. Forniscono API chiave, come nccl, per inizializzare le reti di comunicazioneCommInitRank, gestire le risorse sottostanti ed eseguire comunicazioni collettive. Dopo aver apportato modifiche personalizzate a NCCL e Gloo, Rootless e Storeless ottimizzano (ad esempio, saltando la connessione a TCPStore) l'inizializzazione della rete di comunicazione. È possibile passare dall'utilizzo dei percorsi di codice originali a quelli ottimizzati in modo flessibile.
PyTorch backend del gruppo di processi
I backend del gruppo di processi, in particolare ProcessGroup NCCL e ProcessGroupGloo, implementano le ProcessGroup API richiamando le API delle corrispondenti librerie sottostanti. Poiché estendiamo le API delle librerie di terze parti, dobbiamo richiamarle correttamente e modificare il percorso del codice in base alle configurazioni dei clienti.
Oltre ai percorsi del codice di ottimizzazione, modifichiamo anche il backend del gruppo di processi per supportare il ripristino durante il processo.
