UltraServer architettura Etichette della topologia Plugin della topologia Slurm Best practice Limitazioni

Utilizzo della pianificazione basata sulla topologia in Amazon SageMaker HyperPod

L’efficienza del trasferimento dei dati è un fattore critico nei carichi di lavoro di calcolo ad alte prestazioni e di machine learning. Quando lo utilizzi UltraServers con Amazon SageMaker HyperPod, applica SageMaker HyperPod automaticamente le etichette della topologia alle tue risorse. Topology-aware la pianificazione aiuta ad allocare le risorse per ridurre al minimo i costi generali di trasferimento dei dati considerando sia la topologia dell'istanza (come le risorse sono connesse all'interno di un'istanza) che la topologia di rete (come le istanze sono collegate tra loro). Per ulteriori informazioni sulla topologia delle istanze, consulta Amazon EC2 instance topology.

Topology-aware la pianificazione funziona con entrambi i cluster su Slurm e Amazon EKS. Per informazioni generali su come funziona la topologia con Slurm, consulta la guida alla topologia nella documentazione di Slurm.

In Amazon SageMaker HyperPod, le spese generali di trasferimento dei dati provengono in genere da tre fonti principali:

GPU-to-GPU trasferimento dati: tecnologie moderne come gli switch NVLink e NVLink consentono il trasferimento di dati ad alta velocità tra GPU senza coinvolgere altre risorse di elaborazione. Si tratta di un metodo estremamente efficiente, ma di solito limitato a una singola istanza.
GPU-to-CPU trasferimento dati: i sistemi di accesso alla Non-uniform memoria (NUMA) dispongono di più bus di sistema su un'unica scheda madre. In una tipica architettura di istanze EC2 come p5.48xlarge, ci sono due diversi bus di sistema, ciascuno con una CPU e 4 GPU. Per prestazioni ottimali, i processi che caricano o leggono le to/from GPU di dati devono essere eseguiti su una CPU collegata allo stesso bus di sistema della GPU.
Comunicazioni di rete tra istanze: le istanze trasferiscono i dati attraverso una catena di switch di rete. Il percorso più breve corrisponde in genere alla latenza più bassa.

UltraServer architettura

SageMaker HyperPod supporta l' UltraServer architettura con istanze p6e-gb200.36xlarge. An UltraServer contiene fino a 18 istanze p6e-gb200.36xlarge, con 4 GPU per ogni istanza. Tutte le GPU su tutti i nodi sono interconnesse tramite switch NVLink, che consentono il trasferimento dei dati tra due GPU senza utilizzare interfacce di rete.

Questa architettura offre un notevole incremento delle prestazioni rispetto alle singole istanze. Per sfruttare efficacemente questa architettura, i lavori devono essere inviati ai nodi di calcolo da un singolo nodo. UltraServer

Etichetta della topologia EKS

In base alla topologia delle istanze EC2, etichetta HyperPod automaticamente i nodi con le seguenti etichette:

topologia.kubernetes. io/region- quello in cui risiede il nodo. Regione AWS
topologia.kubernetes. io/zone- la zona di disponibilità in cui risiede il nodo.
topologia.k8s. aws/network-node-layer: NetworkNodes descrive il set di nodi di rete di un'istanza. In ogni set di nodi di rete, i nodi sono elencati in ordine gerarchico dall’alto verso il basso. Il nodo di rete connesso all’istanza è l’ultimo nell’elenco. Esistono fino a quattro livelli di nodi di rete e ogni nodo è contrassegnato da un’etichetta. I livelli disponibili sono topology.k8s.aws/network-node-layer-1, topology.k8s.aws/network-node-layer-2 e topology.k8s.aws/network-node-layer-3.
topologia.k8s. aws/ultraserver-id - Un identificatore utilizzato per etichettare ciascuna delle istanze appartenenti allo stesso dominio NVLink in un Ultraserver. Per ulteriori informazioni sull'utilizzo di with, consulta. UltraServers SageMaker HyperPod Utilizzo UltraServers in Amazon SageMaker HyperPod

Utilizzando queste etichette, è possibile utilizzare la pianificazione basata sulla topologia nella governance delle HyperPod attività per applicare etichette e annotazioni topologiche per ottimizzare l'efficienza della formazione dei carichi di lavoro. Per ulteriori informazioni, consulta Utilizzo della pianificazione basata sulla topologia nella governance delle attività di Amazon SageMaker HyperPod.

Plugin della topologia di rete Slurm

Slurm fornisce plugin integrati per il riconoscimento della topologia di rete. SageMaker HyperPod seleziona e configura automaticamente il plug-in di topologia appropriato in base ai tipi di istanza presenti nel cluster.

Selezione automatica della topologia

Quando si crea un cluster HyperPod Slurm, il sistema ispeziona tutti i gruppi di istanze e i tipi di istanza associati, identifica le caratteristiche di comunicazione GPU di ciascun tipo di istanza e configura Slurm con il plug-in di topologia appropriato. Questo processo viene eseguito automaticamente e non richiede alcuna configurazione.

HyperPod gestisce la topologia tramite un file generato topology.conf dinamicamente. Man mano che il cluster si evolve attraverso operazioni di scalabilità o la sostituzione dei nodi, riconcilia HyperPod continuamente la configurazione della topologia per riflettere lo stato corrente del cluster. Per ulteriori informazioni, consulta Aggiornamenti dinamici della topologia.

Utilizzo del plugin topology/tree

Il topology/tree plugin modella strutture di comunicazione gerarchiche con più livelli di larghezza di banda. La topologia ad albero consente a Slurm di collocare i lavori in modo da ridurre al minimo la comunicazione tra livelli e massimizzare la località.

La topologia ad albero viene utilizzata ad esempio per i tipi con interconnessioni gerarchiche, in cui i carichi di lavoro di formazione distribuiti traggono vantaggio da un posizionamento consapevole della località. Ciò include tipi di istanze come, e. ml.p5.48xlarge ml.p5e.48xlarge ml.p5en.48xlarge

SageMaker HyperPod configura automaticamente il topology/tree plug-in quando il cluster utilizza questi tipi di istanze. I nodi generati vengono topology.conf mappati in una gerarchia di switch che riflette i livelli di comunicazione dell'hardware.

Assicurati che slurm.conf includa:


TopologyPlugin=topology/tree

Configurazione

SageMaker HyperPod configura automaticamente il topology/tree plug-in in base alle informazioni fornite da Amazon EC2. Per ulteriori dettagli sulla topologia di Amazon EC2, consulta Topologia delle istanze di Amazon EC2.

Quando viene utilizzato il topology/tree plug-in, Slurm ha il seguente aspetto: topology.conf


SwitchName=nn-6fe9d8a965d34d181 Switches=nn-0b53107754517bf0e

SwitchName=nn-0b53107754517bf0e Switches=nn-424c855d4ad825aa4,nn-95acd7c656329fc30

SwitchName=nn-424c855d4ad825aa4 Nodes=ip-10-1-111-198
SwitchName=nn-95acd7c656329fc30 Nodes=ip-10-1-53-231

Utilizzo

Quando il topology/tree plugin è configurato, Slurm cerca di allocare macchine vicine l'una all'altra. Puoi forzare Slurm ad allocare macchine su un singolo switch passando il parametro della --switch riga di comando a o: sbatch srun


sbatch --switch=1 ....

Usando il plugin topology/block

NVIDIA ha sviluppato un topology/block plug-in che fornisce una pianificazione gerarchica su blocchi di nodi con le seguenti caratteristiche:

Un blocco è un intervallo consecutivo di nodi
I blocchi non possono essere sovrapposti
Tutti i nodi di un blocco devono essere assegnati a un processo prima di passare al blocco successivo
La dimensione del blocco di pianificazione equivale alla dimensione configurata del blocco più piccolo
Ogni livello di blocco superiore ha una dimensione che è una potenza di due rispetto a quella del livello precedente

Questo plugin alloca i nodi in base alla topologia di rete definita.

La topologia a blocchi modella domini di comunicazione uniformi e ad alta larghezza di banda in cui tutte le GPU partecipano a un unico dominio ad alta velocità con latenza quasi uniforme. La topologia a blocchi considera tutti i nodi come parte di un'unica unità di comunicazione coesiva. UltraServer l'architettura in SageMaker HyperPod supporta il plugin a blocchi.

La topologia a blocchi viene utilizzata per tipi di esempio come ml.p6e-gb200.NVL72 eml.p6e-gb300.NVL72.

Configurazione

SageMaker HyperPod configura automaticamente il plugin. topology/block Se desideri configurare il plugin manualmente, specifica quanto segue nel topology.conf file nella tua directory di configurazione di Slurm:


BlockName=us1 Nodes=ultraserver1-[0-17]
BlockName=us2 Nodes=ultraserver2-[0-17]
BlockSizes=18

Assicurati che slurm.conf includa:


TopologyPlugin=topology/block

Utilizzo

Quando invii i processi, puoi utilizzare i seguenti argomenti aggiuntivi con i comandi sbatch e srun:

--segment=N: specifica il numero di nodi da raggruppare. La dimensione del segmento deve essere minore o uguale alla dimensione del blocco di pianificazione.
--exclusive=topo: richiedi che nessun altro processo venga inserito nello stesso blocco. Questa operazione è utile per il benchmarking e per le applicazioni sensibili alle prestazioni.

Di seguito sono riportati alcuni scenari di esempio da prendere in considerazione durante l’allocazione dei blocchi.

Allocazione di un intero blocco di nodi su un sistema vuoto


sbatch -N18

Allocazione di due blocchi di nodi su un sistema vuoto


sbatch -N36

Allocazione di 18 nodi su un blocco con più di 6 nodi su un altro blocco


sbatch -N24

Allocazione di 12 nodi su un blocco e di 12 nodi su un altro blocco


sbatch -N24 --segment=12

Con --exclusive=topo, il lavoro deve essere messo in blocco senza altri lavori


sbatch -N12 --exclusive=topo

Selezione della topologia per cluster con tipi di istanze misti

HyperPod attualmente utilizza Slurm 24.11, che supporta solo una singola configurazione topologica per cluster. Ciò significa che la selezione della topologia per partizione non è supportata, più modelli di topologia non possono coesistere all'interno di un singolo cluster e tutti i nodi devono essere conformi a un'unica definizione di topologia.

Quando il cluster contiene più tipi di istanze, HyperPod seleziona una topologia compatibile con tutti. La tabella seguente mostra un esempio di come HyperPod risolve la topologia per un cluster con tipi di istanze misti.

Gruppo di istanze	Tipo di istanza	Topologia preferita
IG-1	ml.p5.48xlarge	Struttura
IG-2	ml.p6e-GB300.nvl72	Blocco

In questo esempio, la topologia a blocchi è ottimale per ML.P6E-GB300.nvl72, ma la topologia ad albero è compatibile sia con ml.p5.48xlarge che con ML.P6E-GB300.nvl72. HyperPod seleziona la topologia ad albero come topologia a livello di cluster per garantire che tutti i nodi possano partecipare correttamente alla pianificazione e che nessun tipo di istanza venga escluso o travisato.

Importante

Per i carichi di lavoro in cui la pianificazione basata sulla topologia è fondamentale per le prestazioni, consigliamo di creare cluster separati per ogni tipo di istanza anziché combinare diversi tipi di istanze in un unico cluster. Ciò garantisce che ogni cluster utilizzi la topologia ottimale per il proprio hardware, offrendo le migliori prestazioni possibili in termini di carico di lavoro. Ad esempio, invece di combinare le istanze ml.p5.48xlarge e ml.p6e-GB300.nvl72 in un singolo cluster in cui la topologia ad albero è selezionata come compromesso compatibile, crea un cluster dedicato per ogni tipo di istanza in modo che ognuno utilizzi il proprio modello di topologia ideale.

Disattiva o modifica il plug-in di topologia

Quando viene creato un cluster Slurm, seleziona HyperPod automaticamente il plug-in di topologia ottimale. Per modificare manualmente il plug-in di topologia, aggiorna il TopologyPlugin valore nel slurm.conf nodo del controller.

Esempio:


# Set this value to disable topology plugin
TopologyPlugin=topology/flat

Aggiornamenti dinamici della topologia

Topology-aware la pianificazione mantiene costantemente la correttezza della topologia man mano che il cluster cambia. La topologia viene ricalcolata automaticamente e il topology.conf file viene rigenerato quando si verifica uno dei seguenti eventi:

Scale-up: i nuovi nodi vengono aggiunti al cluster.
Scale-down: i nodi vengono rimossi dal cluster.
Sostituzione dei nodi: i nodi guasti o non integri vengono sostituiti oppure i nodi vengono sostituiti manualmente utilizzando l'BatchReplaceClusterNodesAPI.

Quando la topologia viene aggiornata, i nuovi nodi vengono incorporati nella struttura topologica corretta, i nodi rimossi vengono eliminati e la configurazione Slurm viene aggiornata senza richiedere l'intervento manuale. Ciò garantisce che la topologia rifletta sempre lo stato effettivo del cluster.

Nota

Gli utenti esperti possono ignorare il comportamento della topologia accedendo al nodo controller Slurm e modificando manualmente e. slurm.conf topology.conf Tuttavia, le modifiche manuali possono essere sovrascritte HyperPod durante i successivi aggiornamenti del cluster, incluse le operazioni di scalabilità, la sostituzione dei nodi e altri eventi del ciclo di vita del cluster. Se modifichi questi file manualmente, verifica le modifiche dopo ogni aggiornamento del cluster.

Le migliori pratiche per la UltraServer topologia

Per prestazioni ottimali con UltraServer un'architettura in SageMaker HyperPod:

Imposta le dimensioni dei blocchi appropriate: configura BlockSizes=18 (o 17 se un nodo è libero) in modo che corrispondano all' UltraServer architettura.
Utilizza i segmenti per una maggiore disponibilità: utilizza --segment=16, --segment=8 o --segment=9 con i comandi srun e sbatch per migliorare la flessibilità della pianificazione dei processi.
Considera le dimensioni del processo e del segmento:
- SeBlockSizes=18, i lavori con un massimo di 18 istanze verranno sempre eseguiti su una singola UltraServer istanza.
- SeBlockSizes=16, i lavori con meno di 16 istanze verranno sempre eseguiti su una singola istanza UltraServer, mentre i lavori con 18 istanze possono essere eseguiti su una o due istanze. UltraServers

Durante la procedura di segmentazione, considera quanto segue

Con--segment=1, ogni istanza può essere eseguita su un'istanza separata. UltraServer
Con-N 18 --segment 9, 9 nodi verranno posizionati su uno UltraServer e altri 9 nodi possono essere posizionati sullo stesso o su un altro UltraServer.
Con-N 24 --segment 8, il processo può essere eseguito su 2 o 3 UltraServers, con ogni 8 nodi posizionati insieme sullo stesso server.

Limitazioni nella pianificazione SageMaker HyperPod basata sulla topologia

Il plugin topology/block presenta delle limitazioni nel caso di cluster eterogenei (cluster con diversi tipi di istanze):

Solo i nodi elencati nei blocchi possono essere pianificati con Slurm
Ogni blocco deve avere almeno BlockSizes[0] nodi

Per i cluster eterogenei, considera queste alternative:

Non utilizzare il plugin a blocchi con i cluster eterogenei. Invece, isola i UltraServer nodi in una partizione diversa.
Crea un cluster separato UltraServers solo nello stesso VPC e usa la configurazione multicluster di Slurm.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Implementazione di un carico di lavoro

Distribuisci modelli su HyperPod