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à.
Rete
Suggerimento
Registrati
Prendi in considerazione una maggiore larghezza di banda di rete o un adattatore Elastic Fabric per applicazioni con comunicazioni elevate Inter-Node
Per carichi di lavoro di formazione distribuiti su Amazon EKS con elevate esigenze di comunicazione tra nodi, valuta la possibilità di selezionare istanze con larghezza di banda di rete più elevata o Elastic Fabric Adapter (EFA). Prestazioni di rete insufficienti possono ostacolare il trasferimento dei dati, rallentando le attività di machine learning come il training distribuito su più GPU. Tieni presente che i carichi di lavoro di inferenza in genere non hanno un'elevata comunicazione tra i nodi.
Assicurati che l'immagine del contenitore includa NCCL e il plug-in aws-ofi-nccl (che consente a NCCL di utilizzare EFA tramite libfabric).
Considerazioni sul provisioning dei nodi per i carichi di lavoro EFA
Quando si effettua il provisioning EFA-capable dei nodi, le istanze che devono comunicare devono trovarsi nella stessa zona di disponibilità (requisito fondamentale). Inoltre, AWS consiglia di avviare tutte le EFA-enabled istanze in un gruppo di posizionamento del cluster per ridurre al minimo la distanza fisica tra di esse all'interno di quella singola AZ, garantendo così la latenza più bassa possibile. Un gruppo di collocamento non è necessario per il funzionamento dell'EFA, ma è fortemente consigliato per prestazioni ottimali.
Le seguenti considerazioni si applicano a qualsiasi implementazione di formazione EFA-based distribuita su EKS. Di seguito facciamo riferimento alle annotazioni di Karpenter come esempio, ma le stesse considerazioni possono essere applicate anche alle implementazioni di Managed e Self-managed Node Groups.
-
Aggiungi a un AZ. L'EFA richiede che tutti i nodi comunicanti si trovino nella stessa AZ, quindi, ad esempio, i nodi che partecipano allo stesso lavoro di formazione distribuito non devono essere distribuiti tra le zone. Puoi imporlo bloccando il Pod su un AZ usando l'affinità
nodeSelectoro l'affinità del pod.topology.kubernetes.io/zoneSeleziona l'AZ in cui il tipo di istanza di destinazione ha la migliore disponibilità o in cui il tuo Capacity Block è riservato. Tieni presente che, se da un lato la co-locazione Same-AZ migliora la latenza tra i nodi, dall'altro aumenta anche il raggio di esplosione di un guasto. AZ-level Per carichi di lavoro di formazione di lunga durata, una singola interruzione dell'AZ o un evento di capacità può cancellare ore di progressi accumulati nella formazione, una perdita costosa. Includi questo aspetto nella tua strategia di checkpoint e nella pianificazione della durata del lavoro. -
Configura il gruppo di collocamento del cluster (consigliato). Specifica il gruppo di posizionamento in EC2NodeClass. Karpenter lo rifornisce automaticamente. Questo è consigliato per una latenza ottimale ma non è strettamente necessario per il funzionamento dell'EFA. Per Capacity Blocks for ML, il posizionamento viene gestito automaticamente tramite UltraClusters : non è necessario alcun gruppo di posizionamento manuale. Nota che, in questo caso, l'AZ è già bloccato e quindi non sono necessarie restrizioni aggiuntive Pod-level o NodePool-level AZ.
-
Evita l'interruzione delle attività di formazione con più nodi. Usa i PDB o le
karpenter.sh/do-not-disrupt: "true"annotazioni sui training pod. In caso contrario, il consolidamento di Karpenter potrebbe tentare di sostituire o spostare i carichi di lavoro EFA a metà lavoro, interrompendo l'intero ciclo di formazione distribuito. ImpostatoconsolidationPolicy: WhenEmptysu per impedire il consolidamento dei nodi occupati. NodePool Rivedi l'interazione tra queste etichette eterminationGracePeriodeexpireAfterqui. -
Imposta la scadenza appropriata. Configura
expireAfterun valore più lungo del NodePool tuo lavoro di formazione più lungo o disattivalo NodePools completamente per la formazione. Un nodo che scade durante la fase di formazione interrompe il job. -
Usa la versione corretta del plug-in del dispositivo EFA. Il plug-in del dispositivo EFA
si presenta vpc.amazonaws.com/efacome risorsa programmabile. -
Configura i gruppi di sicurezza. Tutte le istanze EFA devono appartenere allo stesso gruppo di sicurezza con una regola autoreferenziale che consenta tutto il traffico stesso. to/from Senza questo, il traffico EFA si interrompe silenziosamente.
Comprendi i rischi delle istanze Spot derivanti dalla co-locazione EFA
Le istanze Spot di Amazon EC2 offrono notevoli risparmi sui costi dei carichi di lavoro di formazione (consulta questa sezione per le best practice generali di Spot con le GPU). Tuttavia, l'EFA richiede che tutti i nodi comunicanti risiedano nella stessa zona di disponibilità e AWS consiglia di inserirli in un gruppo di posizionamento del cluster per una latenza ottimale. Questa co-locazione introduce un rischio di interruzione correlato: le istanze condividono l'infrastruttura fisica sottostante all'interno della stessa AZ (e ancora di più all'interno di un gruppo di collocamento), quindi un singolo evento di recupero della capacità può interessare più istanze contemporaneamente, interrompendo potenzialmente l'intero processo di formazione multinodo contemporaneamente anziché un singolo nodo.
Ciò è fondamentalmente diverso dall'utilizzo di Spot senza vincoli EFA, in cui i nodi possono essere distribuiti tra le AZ e le interruzioni sono statisticamente indipendenti. Con lo stesso requisito AZ di EFA, un singolo evento di capacità può verificarsi a cascata nel cluster di formazione.
Se stai cercando di risparmiare sui costi per i carichi di lavoro di formazione tramite GPU, assicurati di aver valutato tutte le opzioni di acquisto disponibili prima di affidarti a Spot. Le istanze riservate, le prenotazioni di On-Demand capacità (ODCR), i piani di risparmio e i blocchi di capacità per il machine learning possono tutti offrire sconti significativi garantendo al contempo la disponibilità della capacità, evitando il rischio di interruzione correlato a Spot con i vincoli di co-locazione EFA.
Pianificazione del consumo di indirizzi IP su istanze GPU di grandi dimensioni
Per impostazione predefinita, il plug-in Amazon VPC CNI prealloca gli indirizzi IP per garantire che i pod possano essere pianificati rapidamente, mantenendo un ENI completo di riserva collegato e popolato con IP. Su istanze di grandi dimensioni, ciò può comportare la prenotazione di dozzine di IP per nodo anche quando sono in esecuzione solo pochi pod.
Questa discrepanza è comune nei carichi di lavoro di addestramento e inferenza in cui la densità dei pod per nodo è bassa. A livello di cluster, specialmente durante gli eventi di scalabilità automatica che attivano molti nodi GPU con pochi pod ciascuno, ciò può portare all'esaurimento degli IP di sottorete anche se l'effettivo utilizzo dell'IP è basso.
Per ovviare a questo problema, regolate le variabili, e in modo che corrispondano alla WARM_IP_TARGET densità effettiva dei MINIMUM_IP_TARGET pod. WARM_ENI_TARGET Maggiori informazioni nelle impostazioni dei target ENI e IP di VPC CNI.
Per una guida completa sull'ottimizzazione del consumo IP, consulta Ottimizzazione dell'utilizzo degli indirizzi IP.
