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à. # 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 si utilizza UltraServers con Amazon SageMaker HyperPod, applica SageMaker HyperPod automaticamente le etichette di topologia alle 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) sia la topologia di rete (come le istanze sono collegate tra loro). Per ulteriori informazioni sulla topologia delle istanze, consulta [ Amazon EC2 instance topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html). 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](https://slurm.schedmd.com/topology.html). In Amazon SageMaker HyperPod, i costi 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 alto rendimento tra GPU senza coinvolgere altre risorse di calcolo. 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 una singola 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 dati sulle to/from GPU devono essere eseguiti su una CPU connessa 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 su ciascuna 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 conformità con la topologia delle istanze EC2, etichetta HyperPod automaticamente i nodi con le seguenti etichette: + **topologia.kubernetes. io/region**- il nome in cui risiede il nodo. Regione AWS + **topologia.kubernetes. io/zone**- la zona di disponibilità in cui risiede il nodo. + **topology.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 saperne di più sull'utilizzo di with, vedere. UltraServers SageMaker HyperPod [Utilizzo UltraServers in Amazon SageMaker HyperPod](sagemaker-hyperpod-ultraserver.md) Utilizzando queste etichette, puoi 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](sagemaker-hyperpod-eks-operate-console-ui-governance-tasks-scheduling.md). ## Plugin della topologia di rete Slurm Slurm fornisce plugin integrati per la consapevolezza 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 della 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 file di configurazione generati dinamicamente. In Slurm 25.11 e versioni successive, la topologia è definita in un `topology.yaml` file, che è la fonte della verità e supporta più definizioni di topologia e assegnazioni per partizione. In Slurm 24.x, la topologia è definita in un file con un'unica topologia a livello di cluster. `topology.conf` Man mano che il cluster si evolve tramite operazioni di scalabilità o sostituzioni di nodi, riconcilia HyperPod continuamente la configurazione della topologia per riflettere lo stato corrente del cluster. Per ulteriori informazioni, consulta [Aggiornamenti dinamici della topologia](#sagemaker-hyperpod-topology-dynamic-updates). ### Tipi di istanza che supportano la topologia di rete HyperPod configura la topologia ad albero o a blocchi per i tipi di istanza che supportano la topologia di istanze Amazon EC2. Per un elenco autorevole e aggiornato dei tipi di istanza supportati, consulta [ Prerequisiti per la topologia Amazon EC2 nella Amazon EC2 User Guide. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html#inst-net-topology-prereqs-instance-types) * * I tipi di istanza supportati includono famiglie di elaborazione accelerata come G6e, G7e, P4d, P4de, P5, P5e, P5en e famiglie AWS Trainium come Trn1, Trn1n e Trn2. P6e-GB200 UltraServeri tipi di istanza (ad esempio) utilizzano la topologia a blocchi e altri tipi di istanza compatibili con la topologia utilizzano la topologia ad albero. `ml.p6e-gb200.36xlarge` ### Usare il 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 le comunicazioni tra livelli e massimizzare la località. La topologia ad albero viene utilizzata per i tipi di esempio con interconnessioni gerarchiche, in cui i carichi di lavoro di formazione distribuiti traggono vantaggio dal posizionamento basato sulla località. Ciò include tipi di istanza 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 istanza. La configurazione della topologia generata mappa i nodi 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 la topologia ad albero in base alle informazioni fornite da Amazon EC2. Per maggiori dettagli sulla topologia di Amazon EC2, consulta [ la topologia delle istanze di Amazon EC2. ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html) In Slurm 25.11 e versioni successive, HyperPod definisce la topologia in`topology.yaml`, che è la fonte della verità. Una voce di topologia ad albero mappa i nodi in una gerarchia di switch che riflette i livelli di comunicazione dell'hardware: ``` - topology: tree cluster_default: true tree: switches: - switch: root children: leaf-0,leaf-1 - switch: leaf-0 nodes: compute-1,compute-2 - switch: leaf-1 nodes: compute-3,compute-4 ``` In Slurm 24.x, la topologia ad albero è `topology.conf` invece definita in, che utilizza il seguente formato: ``` 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 tenta di allocare macchine vicine l'una all'altra. Puoi forzare Slurm ad allocare le macchine su un singolo switch passando il parametro della `--switch` riga di comando a o: `sbatch` `srun` ``` sbatch --switch=1 .... ``` ### Usare il plugin topology/block NVIDIA ha sviluppato un `topology/block` plugin che fornisce una pianificazione gerarchica tra 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 architecture in SageMaker HyperPod supporta il plugin a blocchi. La topologia a blocchi viene utilizzata per tipi di UltraServer istanza come`ml.p6e-gb200.36xlarge`. Assicurati che `slurm.conf` includa: ``` TopologyPlugin=topology/block ``` #### Configurazione SageMaker HyperPod configura automaticamente la topologia a blocchi. In Slurm 25.11 e versioni successive, la topologia a blocchi è definita in`topology.yaml`, che è la fonte della verità. Le topologie a blocchi e ad albero per un cluster sono definite insieme nello stesso file. L'esempio seguente mostra un cluster con una partizione P5 (albero) e una UltraServer partizione (blocco): ``` - topology: tree cluster_default: true tree: switches: - switch: root children: leaf-0,leaf-1 - switch: leaf-0 nodes: compute-p5-1,compute-p5-2 - switch: leaf-1 nodes: compute-p5-3,compute-p5-4 - topology: block cluster_default: false block: block_sizes: - 18 blocks: - block: cb-001 nodes: ultraserver-1-[1-18] ``` In Slurm 24.x, la topologia a blocchi è `topology.conf` invece definita in, che utilizza il seguente formato: ``` BlockName=us1 Nodes=ultraserver1-[0-17] BlockName=us2 Nodes=ultraserver2-[0-17] BlockSizes=18 ``` #### 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 inserito in un blocco senza altri lavori ** ``` sbatch -N12 --exclusive=topo ``` ### Partition-level selezione della topologia A partire da Slurm 25.11, HyperPod supporta la configurazione della topologia a livello di partizione. A ogni partizione viene assegnata una topologia basata sui tipi di istanza dei relativi gruppi di istanze di calcolo, quindi un singolo cluster può eseguire la topologia ad albero in una partizione e la topologia a blocchi in un'altra. Le partizioni che contengono tipi di istanza senza supporto per la topologia di rete ereditano un'impostazione predefinita a livello di cluster, che mantiene i nodi programmabili. `flat` HyperPod risolve la topologia per ogni partizione come segue: + Se ogni gruppo di istanze di calcolo nella partizione è un tipo di UltraServer istanza, la partizione utilizza la topologia. `block` + Se ogni gruppo di istanze di calcolo nella partizione supporta la topologia di rete (e la partizione non è completa), la partizione utilizza la topologia. UltraServer `tree` + Se una partizione contiene entrambi i tipi di istanza compatibili con la topologia, UltraServer la partizione utilizza la topologia. `tree` + Se un gruppo di istanze di calcolo nella partizione utilizza un tipo di istanza che non supporta la topologia di rete, alla partizione non è assegnata alcuna topologia ed eredita l'impostazione predefinita a livello di cluster. `flat` La topologia predefinita a livello di cluster viene selezionata in base alle topologie presenti nel cluster: se è presente un solo tipo di topologia, quel tipo è l'impostazione predefinita; se sia il blocco che l'albero sono presenti senza gruppi non topologici, l'albero è l'impostazione predefinita; e se è presente un gruppo di calcolo non topologico, `flat` è l'impostazione predefinita in modo che quei nodi rimangano pianificabili. La tabella seguente mostra un esempio di come HyperPod risolve la topologia per un cluster con tipi di istanza misti. | Gruppo di istanze | Tipo di istanza | Topologia applicata | | --- | --- | --- | | IG-1 | ml.p5.48xlarge | Struttura | | IG-2 | ml.p6e-gb200.36xlarge | Blocco | In questo esempio, la partizione P5 utilizza la topologia ad albero e la partizione utilizza la UltraServer topologia a blocchi. Con la topologia a livello di partizione, ogni partizione utilizza la topologia ottimale all'interno dello stesso cluster, quindi non è più necessario creare cluster separati per assegnare a ciascun tipo di istanza il modello di topologia ideale. **Nota** Sui cluster che eseguono Slurm 24.x, è supportata una sola configurazione topologica a livello di cluster. Per-partition la topologia richiede Slurm 25.11 o successivo. ### Topologia piatta (predefinita) Quando un cluster contiene una combinazione di tipi di istanze compatibili con la topologia e non topologici, HyperPod viene applicata come impostazione predefinita del cluster. `topology/flat` Topology-aware le partizioni sono indirizzate alla rispettiva topologia ad albero o a blocchi tramite `Topology=` direttive per partizione in `slurm.conf` (Slurm 25.11 e versioni successive), mentre le partizioni con nodi non topologici non hanno alcuna direttiva ed ereditano l'impostazione predefinita flat. `Topology=` Ciò garantisce che ogni nodo rimanga programmabile. ### Disabilita 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. Per disabilitare il posizionamento basato sulla topologia, imposta il plug-in su (o): `topology/flat` `topology/default` ``` # Set this value to disable topology-aware placement TopologyPlugin=topology/flat ``` ### Aggiornamenti dinamici della topologia Topology-aware la pianificazione mantiene continuamente la correttezza della topologia man mano che il cluster cambia. La topologia viene ricalcolata automaticamente e il file di configurazione della topologia viene rigenerato quando si verifica uno dei seguenti eventi: + **Scale-up**: vengono aggiunti nuovi nodi al cluster. + **Scale-down**: i nodi vengono rimossi dal cluster. + **Sostituzione dei nodi**: i nodi non funzionanti o non integri vengono sostituiti oppure i nodi vengono sostituiti manualmente utilizzando l'[BatchReplaceClusterNodes](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_BatchReplaceClusterNodes.html)API. Quando la topologia viene aggiornata, i nuovi nodi vengono incorporati nella struttura topologica corretta, i nodi rimossi vengono eliminati e la configurazione di Slurm viene aggiornata senza richiedere interventi manuali. Ciò garantisce che la topologia rifletta sempre lo stato effettivo del cluster. **Nota** Gli utenti esperti possono sovrascrivere il comportamento della topologia accedendo al nodo del controller Slurm e modificando manualmente il file di topologia applicabile (`topology.yaml`su Slurm 25.11 `slurm.conf` e versioni successive o su Slurm 24.x). `topology.conf` Tuttavia, le modifiche manuali possono essere sovrascritte HyperPod durante i successivi aggiornamenti del cluster, incluse le operazioni di ridimensionamento, 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. ## Procedure consigliate 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**: + Se`BlockSizes=18`, i processi con un massimo di 18 istanze verranno sempre eseguiti su una singola UltraServer istanza. + Se`BlockSizes=16`, i processi 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. UltraServers Quando pensi alla segmentazione, considera quanto segue: + Con`--segment=1`, ogni istanza può essere eseguita su un sistema separato. UltraServer + Con`-N 18 --segment 9`, 9 nodi verranno posizionati su uno UltraServer e altri 9 nodi possono essere posizionati sullo stesso o sull'altro UltraServer. + Con`-N 24 --segment 8`, il lavoro può essere eseguito su 2 o 3 UltraServers, con ogni 8 nodi messi insieme sullo stesso server. ## Limitazioni nella SageMaker HyperPod pianificazione basata sulla topologia Con Slurm 25.11 e versioni successive, i cluster eterogenei (cluster con diversi tipi di istanza) sono supportati tramite la topologia a livello di partizione e l'impostazione predefinita del cluster. `flat` Ogni partizione riceve la topologia più adatta ai suoi tipi di istanza e i nodi non topologici rimangono pianificabili all'interno dello stesso cluster. UltraServer Per ulteriori informazioni, consulta [Partition-level selezione della topologia](#sagemaker-hyperpod-topology-partition-level). Sui cluster che eseguono Slurm 24.x, si applica una singola topologia a livello di cluster e il plug-in presenta le seguenti limitazioni con i cluster eterogenei: `topology/block` + Solo i nodi elencati in blocchi sono pianificabili da Slurm. + Ogni blocco deve avere almeno nodi. `BlockSizes[0]` Per i cluster eterogenei su Slurm 24.x, considera queste alternative: + Non utilizzare il plugin a blocchi con i cluster eterogenei. Invece, isola i nodi in una partizione diversa. UltraServer + Crea un cluster separato utilizzando UltraServers solo lo stesso VPC e utilizza la configurazione multicluster di Slurm.