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 sistema centralizzato TCPStore e si coordinino tramite un processo root, il che comporta un oneroso sovraccarico che diventa particolarmente problematico durante i riavvii. Questo design centralizzato crea tre problemi critici: sovraccarico di coordinamento dovuto alle TCPStore connessioni obbligatorie, ritardi di ripristino poiché ogni riavvio deve ripetere l'intera sequenza di inizializzazione e un singolo punto di errore nel processo principale stesso. Ciò impone procedure di coordinamento costose e centralizzate ogni volta che la formazione viene inizializzata o riavviata.
HyperPod la formazione senza checkpointless elimina questi ostacoli di coordinamento, permettendo un recupero più rapido dai guasti grazie a un'inizializzazione «senza radici» 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. 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, per i gruppi di processi NCCL e TCPStoreless Gloo.
L'implementazione di queste ottimizzazioni comporta la modifica di NCCL, Gloo e: PyTorch
Estensione della libreria di terze parti APIs per abilitare le ottimizzazioni Rootless e Storeless 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 costose TCPStore creazioni 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 checkpoint.
NCCL e Gloo
Si tratta di pacchetti indipendenti che eseguono le funzionalità principali delle comunicazioni collettive. Forniscono chiavi APIs, come ncclCommInit Rank, per inizializzare le reti di comunicazione, 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) l'inizializzazione della rete di comunicazione. TCPStore È 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, lo implementano ProcessGroup APIs richiamando le APIs librerie sottostanti corrispondenti. Poiché estendiamo le librerie di terze parti APIs, 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.
