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 della comunicazione collettiva
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 colli di bottiglia 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 costoso sovraccarico che diventa particolarmente problematico durante i riavvii. Questo design centralizzato crea tre problemi critici: sovraccarico di coordinamento dovuto alle connessioni TCPStore obbligatorie, ritardi di ripristino in quanto ogni riavvio deve ripetere l'intera sequenza di inizializzazione e un singolo punto di errore nel processo root stesso. Ciò impone procedure di coordinamento costose e centralizzate ogni volta che l'allenamento viene inizializzato o riavviato.
HyperPod La formazione senza checkpointless elimina questi ostacoli di coordinamento e consente un ripristino più rapido dai guasti grazie all'inizializzazione «rootless» e «TCPStoreless».
configurazioni rootless
Per abilitare Rootless, si possono semplicemente 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. Si usa per accendere e spegnere 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 di NCCL e Gloo mantenendo al contempo 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
Evitando la costosa creazione di TCPStore a livello PyTorch distribuito mantenendo al contempo modelli di indirizzi simmetrici attraverso contatori di gruppo globali
Il grafico seguente mostra l'architettura delle librerie di formazione distribuite e le modifiche apportate alla formazione senza checkpointless.
NCCL e Gloo
Si tratta di pacchetti indipendenti che eseguono 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 in 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 ai percorsi di codice 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 librerie sottostanti corrispondenti. 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 all'ottimizzazione dei percorsi di codice, modifichiamo anche il backend del gruppo di processi per supportare il ripristino durante il processo.
