**Contribuisci a migliorare questa pagina**
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à.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
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à.
# Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS
Questa sezione è progettata per aiutarti a gestire le risorse di calcolo per i carichi di lavoro di machine learning in Amazon Elastic Kubernetes Service (EKS). Troverai i dettagli sulla prenotazione GPUs utilizzando Capacity Blocks per gruppi di nodi gestiti e nodi autogestiti, tra cui prerequisiti, configurazione del modello di lancio, configurazioni di scalabilità, preparazione del carico di lavoro e considerazioni chiave per la gestione dei cicli di vita delle prenotazioni e la chiusura graduale dei nodi.
**Topics**
+ [Creare un gruppo di nodi gestito con blocchi di capacità per il ML](capacity-blocks-mng.md)
+ [Crea nodi autogestiti con i blocchi di capacità per il ML](capacity-blocks.md)
+ [Usa P6e- con GB200 UltraServers Amazon EKS](ml-eks-nvidia-ultraserver.md)
# Creare un gruppo di nodi gestito con blocchi di capacità per il ML
I blocchi di capacità per il machine learning (ML) ti consentono di riservare istanze GPU in una data futura per supportare i carichi di lavoro ML di breve durata. Per ulteriori informazioni, consulta [Blocchi di capacità per il machine learning](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella *Guida per l’utente di Amazon EC2 per le istanze Linux*.
## Considerazioni
**Importante**
I blocchi di capacità sono disponibili solo per certi tipi di istanze e regioni AWS Amazon EC2. Per informazioni relative alla compatibilità, consulta [Work with Capacity Blocks Prerequisites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) nella *Guida per l’utente di Amazon EC2 per le istanze Linux*.
Per ulteriori informazioni, consulta [Usa i blocchi di capacità per carichi di lavoro di machine learning](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.
I gruppi di nodi gestiti con i blocchi di capacità possono essere creati solo con modelli di avvio personalizzati.
Quando aggiorni i gruppi di nodi gestiti con i blocchi di capacità, assicurati che la dimensione desiderata del gruppo di nodi sia impostata su `0`.
## Creare un gruppo di nodi gestito con blocchi di capacità di Amazon EC2
Puoi usare i blocchi di capacità con i gruppi di nodi gestiti da Amazon EKS per il provisioning e il dimensionamento dei nodi di lavoro accelerati da GPU. Gli esempi di modelli AWS CloudFormation riportati di seguito non coprono tutti gli aspetti necessari in un cluster di produzione. In genere, serve anche uno script di bootstrap per unire il nodo al cluster e specificare un’AMI accelerata Amazon EKS. Per ulteriori informazioni, consulta [Creare un gruppo di nodi gestiti per il cluster](create-managed-node-group.md).
1. Crea un modello di avvio adatto ai tuoi carichi di lavoro e che funzioni con i gruppi di nodi gestiti da Amazon EKS. Per ulteriori informazioni, consulta [Personalizzazione dei nodi gestiti con modelli di avvio](launch-templates.md).
Oltre ai requisiti indicati nelle procedure sopra riportate, assicurati che `LaunchTemplateData` includa quanto segue:
+ `InstanceMarketOptions` con `MarketType` impostato su `"capacity-block"`
+ `CapacityReservationSpecification: CapacityReservationTarget` con `CapacityReservationId` impostato sul blocco di capacità (ad esempio: `cr-02168da1478b509e0 `)
+ `InstanceType` impostato su un tipo di istanza che supporta i blocchi di capacità (ad esempio: *p5.48xlarge*)
Di seguito è riportato un estratto di un modello CloudFormation che crea un modello di avvio destinato a un blocco di capacità. Per creare un gruppo di nodi gestiti AMI personalizzato, è anche possibile aggiungere i parametri `ImageId` e `UserData`.
```
NodeLaunchTemplate:
Type: "AWS::EC2::LaunchTemplate"
Properties:
LaunchTemplateData:
InstanceMarketOptions:
MarketType: "capacity-block"
CapacityReservationSpecification:
CapacityReservationTarget:
CapacityReservationId: "cr-02168da1478b509e0"
InstanceType: p5.48xlarge
```
1. Utilizza il modello di avvio per creare un gruppo di nodi gestito.
Di seguito è riportato un esempio di comando per la creazione di un gruppo di nodi per i blocchi di capacità. Sostituisci i *valori di esempio* con quelli applicabili al cluster.
Quando crei il gruppo di nodi gestiti del blocco di capacità, procedi come segue:
+ Imposta `capacity-type` su `"CAPACITY_BLOCK"`. Se il tipo di capacità non è impostato su `"CAPACITY_BLOCK"` se manca uno qualsiasi degli altri valori richiesti sopra indicati per il modello di avvio, la richiesta di creazione verrà rifiutata.
+ Quando specifichi `subnets` nella richiesta di creazione, assicurati di specificare solo la sottorete nella stessa zona di disponibilità della prenotazione della capacità.
+ Se specifichi un valore diverso da zero per `desiredSize` nella richiesta di creazione, Amazon EKS lo rispetterà durante la creazione del gruppo Auto Scaling (ASG). Tuttavia, se la richiesta di creazione viene effettuata prima che la prenotazione della capacità sia attiva, l’ASG non sarà in grado di avviare istanze Amazon EC2 fino a quando non diventa attiva. Di conseguenza, le attività di dimensionamento dell’ASG presenteranno errori di avvio. Quando la prenotazione diventa attiva, l’avvio delle istanze avrà esito positivo e l’ASG aumenterà verticalmente fino alla `desiredSize` specificata al momento della creazione.
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-mng \
--node-role node-role-arn \
--region region-code \
--subnets subnet-id \
--scaling-config minSize=node-group-min-size,maxSize=node-group-max-size,desiredSize=node-group-desired-size \
--ami-type "AL2023_x86_64_NVIDIA" \
--capacity-type "CAPACITY_BLOCK" \
--launch-template id="lt-id",version=1
```
1. Assicurati che i nodi si uniscano dopo l’aumento verticale. I cluster Amazon EKS che usano gruppi di nodi gestiti con blocchi di capacità non eseguono alcuna verifica per accertarsi che le istanze avviate si uniscano effettivamente al cluster e vi si registrino.
1. Se imposti `desiredSize` su `0` al momento della creazione, sono disponibili diverse opzioni per aumentare verticalmente il gruppo di nodi quando la prenotazione della capacità diventa attiva:
+ Crea una policy di dimensionamento programmato per l’ASG che si allinei all’ora di inizio della prenotazione dei blocchi di capacità. Per ulteriori informazioni, consulta [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.
+ Utilizza la console Amazon EKS o `eks update-nodegroup-config` per aggiornare la configurazione del dimensionamento e impostare la dimensione desiderata del gruppo di nodi.
+ Utilizza l’autoscaler del cluster Kubernetes. Per ulteriori informazioni consultare [Cluster Autoscaler su AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
1. Il gruppo di nodi è ora pronto per la pianificazione di carichi di lavoro e pod.
1. Affinché i tuoi Pod vengano svuotati senza problemi prima della fine della prenotazione, Amazon EKS usa una policy di dimensionamento pianificata per ridurre verticalmente la dimensione del gruppo di nodi a `0`. Questo dimensionamento programmato verrà impostato con il nome `Amazon EKS Node Group Capacity Scaledown Before Reservation End` . Suggeriamo di non modificare né eliminare questa azione.
Amazon EC2 inizia a spegnere le istanze 30 minuti prima della fine della prenotazione. Di conseguenza, Amazon EKS imposterà una riduzione verticale programmata del gruppo di nodi 40 minuti prima della fine della prenotazione, al fine di espellere i pod in modo sicuro e graduale.
# Crea nodi autogestiti con i blocchi di capacità per il ML
I blocchi di capacità per il machine learning (ML) ti consentono di riservare istanze GPU in una data futura per supportare i carichi di lavoro ML di breve durata. Per ulteriori informazioni, consulta [Blocchi di capacità per il machine learning](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) nella *Guida per l’utente di Amazon EC2 per le istanze Linux*.
## Considerazioni
**Importante**
I blocchi di capacità sono disponibili solo per certi tipi di istanze e regioni AWS Amazon EC2. Per informazioni relative alla compatibilità, consulta [Work with Capacity Blocks Prerequisites](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-using.html#capacity-blocks-prerequisites) nella *Guida per l’utente di Amazon EC2 per le istanze Linux*.
Se crei un gruppo di nodi autogestito prima che la prenotazione della capacità diventi attiva, imposta la capacità desiderata su `0`.
Per avere tempo sufficiente per svuotare correttamente i nodi, suggeriamo di pianificare il dimensionamento fino a zero più di 30 minuti prima dell'orario di fine della prenotazione del blocco di capacità.
Affinché i tuoi pod vengano svuotati correttamente, consigliamo di configurare AWS Node Termination Handler, come spiegato nei passaggi di esempio.
## Utilizza i blocchi di capacità con nodi autogestiti
Puoi utilizzare i blocchi di capacità con Amazon EKS per effettuare il provisioning e il dimensionamento dei nodi autogestiti. Le seguenti fasi forniscono una panoramica generale di esempio. Gli esempi di modelli AWS CloudFormation non coprono tutti gli aspetti necessari in un carico di lavoro di produzione. In genere è anche necessario uno script di bootstrap per unire il nodo al cluster, specificare un’AMI accelerata Amazon EKS e un profilo dell’istanza adeguato per l’aggiunta al cluster. Per ulteriori informazioni, consulta [Crea nodi Amazon Linux autogestiti](launch-workers.md).
1. Crea un modello di lancio applicabile al tuo carico di lavoro. Per ulteriori informazioni, consulta [Usa i blocchi di capacità per carichi di lavoro di machine learning](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-template-capacity-blocks.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.
Assicurati che `LaunchTemplateData` includa quanto segue:
+ `InstanceMarketOptions` con `MarketType` impostato su `"capacity-block"`
+ `CapacityReservationSpecification: CapacityReservationTarget` con `CapacityReservationId` impostato sul blocco di capacità (ad esempio: `cr-02168da1478b509e0 `)
+ `IamInstanceProfile` con l’`Arn` impostato sul valore *iam-instance-profile-arn* applicabile
+ `ImageId` impostato sull’*image-id* applicabile
+ `InstanceType` impostato su un tipo di istanza che supporta i blocchi di capacità (ad esempio: *p5.48xlarge*)
+ `SecurityGroupIds` impostato sugli ID applicabili (ad esempio: *sg-05b1d815d1EXAMPLE*)
+ `UserData` impostato *sui dati utente* applicabili per il gruppo di nodi autogestito
Di seguito è riportato un estratto di un modello CloudFormation che crea un modello di avvio destinato a un blocco di capacità.
```
NodeLaunchTemplate:
Type: "aws::EC2::LaunchTemplate"
Properties:
LaunchTemplateData:
InstanceMarketOptions:
MarketType: "capacity-block"
CapacityReservationSpecification:
CapacityReservationTarget:
CapacityReservationId: "cr-02168da1478b509e0"
IamInstanceProfile:
Arn: iam-instance-profile-arn
ImageId: image-id
InstanceType: p5.48xlarge
KeyName: key-name
SecurityGroupIds:
- sg-05b1d815d1EXAMPLE
UserData: user-data
```
Devi trasmettere la sottorete nella zona di disponibilità in cui viene effettuata la prenotazione, perché i blocchi di capacità sono zonali.
1. Utilizza il modello di avvio per creare un gruppo di nodi autogestito. Se lo fai prima che la prenotazione della capacità diventi attiva, imposta la capacità desiderata su `0`. Quando crei il gruppo di nodi, assicurati di specificare solo la rispettiva sottorete per la zona di disponibilità in cui è la capacità è riservata.
Di seguito è riportato un esempio di modello CloudFormation che puoi usare come riferimento per crearne uno applicabile al tuo carico di lavoro. Questo esempio ottiene i valori di `LaunchTemplateId` e `Version` della risorsa ` AWS::Amazon EC2::LaunchTemplate` mostrata nel passaggio precedente. Ottiene anche i valori di `DesiredCapacity`, `MaxSize`, `MinSize` e `VPCZoneIdentifier` che sono dichiarati altrove nello stesso modello.
```
NodeGroup:
Type: "AWS::AutoScaling::AutoScalingGroup"
Properties:
DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity
LaunchTemplate:
LaunchTemplateId: !Ref NodeLaunchTemplate
Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber
MaxSize: !Ref NodeAutoScalingGroupMaxSize
MinSize: !Ref NodeAutoScalingGroupMinSize
VPCZoneIdentifier: !Ref Subnets
Tags:
- Key: Name
PropagateAtLaunch: true
Value: !Sub ${ClusterName}-${NodeGroupName}-Node
- Key: !Sub kubernetes.io/cluster/${ClusterName}
PropagateAtLaunch: true
Value: owned
```
1. Una volta che il gruppo di nodi è stato creato, assicurati di registrare il valore `NodeInstanceRole` per il gruppo di nodi creato. Ciò è necessario per verificare che, in seguito al dimensionamento del gruppo di nodi, i nuovi nodi vengano aggiunti al cluster e Kubernetes sia in grado di riconoscerli. Per ulteriori informazioni, consulta le istruzioni Console di gestione AWS in [Create self-managed Amazon Linux nodes](launch-workers.md).
1. Consigliamo di creare una policy di dimensionamento programmato per il gruppo con dimensionamento automatico che si allinei ai tempi di prenotazione dei blocchi di capacità. Per ulteriori informazioni, consulta [Dimensionamento programmato per Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) nella *Guida per l'utente di Amazon EC2 Auto Scaling*.
Puoi utilizzare tutte le istanze prenotate fino a 30 minuti prima dell'orario di fine del blocco di capacità. Le istanze ancora in esecuzione in quel momento inizieranno a terminare. Per avere tempo sufficiente per svuotare correttamente i nodi, suggeriamo di pianificare il dimensionamento fino a zero più di 30 minuti prima dell'orario di fine della prenotazione del blocco di capacità.
Se desideri invece aumentare le dimensioni manualmente ogni volta che la prenotazione della capacità diventa `Active`, devi aggiornare la capacità desiderata del gruppo con dimensionamento automatico all’inizio della prenotazione del blocco di capacità. Successivamente, dovrai anche ridurre le dimensioni manualmente più di 30 minuti prima dell'orario di fine della prenotazione del blocco di capacità.
1. Il gruppo di nodi è ora pronto per la pianificazione di carichi di lavoro e pod.
1. Affinché i tuoi pod vengano svuotati correttamente, consigliamo di configurare AWS Node Termination Handler. Questo strumento sarà in grado di monitorare gli eventi del ciclo di vita “Ridimensionamento di ASG” di Amazon EC2 Auto Scaling utilizzando EventBridge e consentire al piano di controllo Kubernetes di intraprendere l’azione richiesta prima che l’istanza diventi non disponibile. Altrimenti, i tuoi oggetti pod e Kubernetes rimarranno bloccati nello stato in sospeso. Per ulteriori informazioni, consulta [AWS Node Termination Handler](https://github.com/aws/aws-node-termination-handler) su GitHub.
Se non configuri Node Termination Handler, consigliamo di cominciare a svuotare manualmente i pod prima di raggiungere la finestra di 30 minuti, in modo che abbiano tempo sufficiente per il corretto svuotamento.
# Usa P6e- con GB200 UltraServers Amazon EKS
Questo argomento descrive come configurare e utilizzare Amazon EKS con P6e-. GB200 UltraServers Il tipo di `p6e-gb200.36xlarge` istanza con 4 NVIDIA Blackwell GPUs è disponibile solo come P6e-. GB200 UltraServers Esistono due tipi di P6e-. GB200 UltraServers `u-p6e-gb200x36` UltraServer Ha 9 `p6e-gb200.36xlarge` istanze e `u-p6e-gb200x72` UltraServer ha 18 istanze. `p6e-gb200.36xlarge`
Per ulteriori informazioni, consulta la pagina web di [Amazon EC2 P6e](https://aws.amazon.com/ec2/instance-types/p6/) -. GB200 UltraServers
## Considerazioni
+ Amazon EKS supporta P6e- GB200 UltraServers per Kubernetes versioni 1.33 e successive. [Questa versione di Kubernetes fornisce il supporto per [Dynamic Resource Allocation](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (DRA), abilitato di default in EKS e nella versione accelerata ottimizzata per EKS. AL2023 AMIs](https://docs.aws.amazon.com/eks/latest/userguide/ml-eks-optimized-ami.html) Il DRA è un requisito per utilizzare il P6e- con EKS. GB200 UltraServers Il DRA non è supportato in Karpenter o EKS Auto Mode e si consiglia di utilizzare i gruppi di nodi autogestiti EKS o i gruppi di nodi gestiti da EKS quando si utilizza il P6e- con EKS. GB200 UltraServers
+ [I P6e- GB200 UltraServers sono resi disponibili tramite EC2 Capacity Blocks for ML.](https://aws.amazon.com/ec2/capacityblocks/) Vedi [Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS](ml-compute-management.md) per informazioni su come avviare i nodi EKS con Capacity Blocks.
+ Quando si utilizzano gruppi di nodi gestiti EKS con Capacity Blocks, è necessario utilizzare modelli di avvio personalizzati. Quando si aggiornano i gruppi di nodi gestiti EKS con P6e- GB200 UltraServers, è necessario impostare la dimensione desiderata del gruppo di nodi prima dell'aggiornamento. `0`
+ Si consiglia di utilizzare la variante AL2023 ARM NVIDIA dell'accelerato ottimizzato per EKS. AMIs Questa AMI include i componenti e la configurazione del nodo necessari per funzionare con P6e-. GB200 UltraServers Se decidi di creare la tua AMI, sei responsabile dell'installazione e della convalida della compatibilità del nodo e del software di sistema, inclusi i driver. Per ulteriori informazioni, consulta [Usa l'accelerazione ottimizzata per EKS per le istanze AMIs GPU](ml-eks-optimized-ami.md).
+ Si consiglia di utilizzare la versione AMI ottimizzata per EKS `v20251103` o successiva, che include il driver NVIDIA versione 580. Questa versione del driver NVIDIA consente alla Coherent Driver-Based Memory (CDMM) di risolvere il problema del potenziale eccesso di memoria. Quando CDMM è abilitato, le seguenti funzionalità non sono supportate: NVIDIA Multi-Instance GPU (MIG) e vGPU. Per ulteriori informazioni su CDMM, consulta [NVIDIA](https://nvdam.widen.net/s/gpqp6wmz7s/cuda-whitepaper—cdmm-pdf) Coherent Driver Memory Management (CDMM).
+ Quando si utilizza l'[operatore GPU NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) con l'AMI AL2023 NVIDIA ottimizzata per EKS, è necessario disabilitare l'installazione da parte dell'operatore del driver e del toolkit, poiché questi sono già inclusi nell'AMI. I prodotti AL2023 NVIDIA ottimizzati per EKS AMIs non includono il plug-in per dispositivi NVIDIA Kubernetes o il driver NVIDIA DRA, che devono essere installati separatamente.
+ Ogni `p6e-gb200.36xlarge` istanza può essere configurata con un massimo di 17 schede di rete e può sfruttare EFA per la comunicazione tra. UltraServers Il traffico di rete dei carichi di lavoro può UltraServers intersecarsi, ma per ottenere prestazioni ottimali si consiglia di pianificare i carichi di lavoro nello stesso ambiente UltraServer sfruttando IMEX per la comunicazione intra-GPU. UltraServer Per ulteriori informazioni, consulta Configurazione [EFA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) per le istanze P6e-. GB200
+ [Ogni `p6e-gb200.36xlarge` istanza dispone di 3 istanze di storage da 7,5 TB.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) Per impostazione predefinita, l'AMI ottimizzata per EKS non formatta e monta gli instance store. Lo storage temporaneo del nodo può essere condiviso tra i pod che richiedono lo storage temporaneo e le immagini dei contenitori che vengono scaricate nel nodo. Se si utilizza l' AL2023 AMI ottimizzata per EKS, questa può essere configurata come parte del bootstrap dei nodi nei dati utente impostando la politica di archiviazione locale dell'istanza su. [NodeConfig](https://docs.aws.amazon.com/eks/latest/eksctl/node-bootstrapping.html#configuring-the-bootstrapping-process) RAID0 Impostando su RAID0 stripes, l'istanza archivia e configura il runtime del contenitore e il kubelet per utilizzare questo spazio di archiviazione effimero.
## Componenti
I seguenti componenti sono consigliati per eseguire carichi di lavoro su EKS con il P6e-. GB200 UltraServers Facoltativamente, puoi utilizzare l'[operatore GPU NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) per installare i componenti del nodo NVIDIA. Quando si utilizza l'operatore GPU NVIDIA con l'AMI AL2023 NVIDIA ottimizzata per EKS, è necessario disabilitare l'installazione da parte dell'operatore del driver e del toolkit, poiché questi sono già inclusi nell'AMI.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/eks/latest/userguide/ml-eks-nvidia-ultraserver.html)
I componenti del nodo nella tabella precedente svolgono le seguenti funzioni:
+ **VPC CNI**: alloca VPC IPs come interfaccia di rete principale per i pod in esecuzione su EKS
+ **Plugin per dispositivi EFA**: alloca i dispositivi EFA come reti secondarie per i pod in esecuzione su EKS. Responsabile del traffico di rete su P6e-. GB200 UltraServers Per carichi di lavoro multinodo, GPU-to-GPU all'interno di un UltraServer canale che scorre su più nodi. NVLink
+ **Plugin per dispositivi NVIDIA Kubernetes: viene allocato come dispositivi** per i GPUs pod in esecuzione su EKS. Si consiglia di utilizzare il plug-in per dispositivi NVIDIA Kubernetes fino a quando la funzionalità di allocazione della GPU del driver NVIDIA DRA non sarà più sperimentale. [Consulta le versioni dei driver NVIDIA DRA per informazioni aggiornate.](https://github.com/NVIDIA/k8s-dra-driver-gpu/releases)
+ **Driver NVIDIA DRA**: abilita risorse ComputeDomain personalizzate che facilitano la creazione di domini IMEX che seguono i carichi di lavoro in esecuzione su P6e-. GB200 UltraServers
+ La ComputeDomain risorsa descrive un dominio Internode Memory Exchange (IMEX). Quando i carichi di lavoro con un ResourceClaim for a ComputeDomain vengono distribuiti nel cluster, il driver NVIDIA DRA crea automaticamente un IMEX DaemonSet che viene eseguito su nodi corrispondenti e stabilisce i canali IMEX tra i nodi prima dell'avvio del carico di lavoro. [Per saperne di più su IMEX, consulta la panoramica di NVIDIA IMEX per sistemi multi-nodo. NVLink ](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/overview.html)
+ Il driver NVIDIA DRA utilizza un'etichetta Clique ID (`nvidia.com/gpu.clique`) applicata da NVIDIA GFD che trasmette la conoscenza della topologia e del dominio di rete. NVLink
+ È consigliabile creare un lavoro per carico di lavoro. ComputeDomain
+ **NVIDIA Node Feature Discovery (NFD)**: dipendenza richiesta per GFD per applicare le etichette dei nodi in base agli attributi a livello di nodo rilevati.
+ **NVIDIA GPU Feature Discovery (GFD)**: applica un'etichetta topologica standard NVIDIA chiamata ai nodi. `nvidia.com/gpu.clique` I nodi all'interno dello stesso `nvidia.com/gpu.clique` hanno una NVLink raggiungibilità multinodo e puoi utilizzare le affinità dei pod nell'applicazione per pianificare i pod sullo stesso dominio. NVlink
## Procedura
La sezione seguente presuppone che tu abbia un cluster EKS che esegue Kubernetes versione 1.33 o successiva con uno o più gruppi di nodi con P6e, che esegue l'AMI accelerata ottimizzata per ARM NVIDIA EKS. GB200 UltraServers AL2023 Consulta i collegamenti per i passaggi preliminari [Gestisci le risorse di calcolo per i AI/ML carichi di lavoro su Amazon EKS](ml-compute-management.md) per i nodi autogestiti e i gruppi di nodi gestiti da EKS.
La procedura seguente utilizza i componenti riportati di seguito.
| Name | Versione | Description |
| --- | --- | --- |
| Operatore GPU NVIDIA | 25.3.4\$1 | Per la gestione del ciclo di vita dei plug-in richiesti come il plug-in per dispositivi NVIDIA Kubernetes e NFD/GFD. |
| Driver NVIDIA DRA | 25.8.0\$1 | Per la gestione ComputeDomain CRDs dei domini IMEX. |
| Plugin per dispositivi EFA | 0.5.14 e versioni successive | Per la comunicazione incrociata. UltraServer |
## Installa l'operatore GPU NVIDIA
L'operatore GPU NVIDIA semplifica la gestione dei componenti necessari per l'uso nei cluster Kubernetes. GPUs Poiché il driver della GPU NVIDIA e il toolkit contenitore sono installati come parte dell'AMI accelerata ottimizzata per EKS, questi devono essere `false` impostati nella configurazione dei valori Helm.
1. Crea un file di valori Helm denominato con la seguente configurazione. `gpu-operator-values.yaml`
```
devicePlugin:
enabled: true
nfd:
enabled: true
gfd:
enabled: true
driver:
enabled: false
toolkit:
enabled: false
migManager:
enabled: false
```
1. Installa l'operatore GPU NVIDIA per il tuo cluster utilizzando il `gpu-operator-values.yaml` file creato nel passaggio precedente.
```
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
```
```
helm install gpu-operator nvidia/gpu-operator \
--namespace gpu-operator \
--create-namespace \
--version v25.3.4 \
--values gpu-operator-values.yaml
```
## Installa il driver NVIDIA DRA
A partire dalla versione NVIDIA GPU Operator`v25.3.4`, il driver NVIDIA DRA deve essere installato separatamente. Si consiglia di tenere traccia delle [note di rilascio](https://github.com/NVIDIA/gpu-operator/releases) dell'operatore della GPU NVIDIA poiché potrebbero cambiare in una versione futura.
1. Crea un file di valori Helm denominato `dra-values.yaml` con la seguente configurazione. Nota `tolerations` che configura il `nodeAffinity` driver DRA in modo che venga distribuito solo su nodi con una GPU NVIDIA.
```
resources:
gpus:
enabled: false # set to false to disable experimental gpu support
computeDomains:
enabled: true
controller:
nodeSelector: null
affinity: null
tolerations: []
kubeletPlugin:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "nvidia.com/gpu.present"
operator: In
values:
- "true"
tolerations:
- key: "nvidia.com/gpu"
operator: Exists
effect: NoSchedule
```
1. Installa il driver NVIDIA DRA per il tuo cluster utilizzando il `dra-values.yaml` file creato nel passaggio precedente.
```
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
```
```
helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
--version="25.8.0" \
--namespace nvidia-dra-driver-gpu \
--create-namespace \
-f dra-values.yaml
```
1. Dopo l'installazione, il driver DRA crea `DeviceClass` risorse che consentono a Kubernetes di comprendere e allocare le `ComputeDomain` risorse, rendendo possibile la gestione IMEX per carichi di lavoro GPU distribuiti su P6e-. GB200 UltraServers
Verifica che le risorse DRA siano disponibili con i seguenti comandi.
```
kubectl api-resources | grep resource.k8s.io
```
```
deviceclasses resource.k8s.io/v1 false DeviceClass
resourceclaims resource.k8s.io/v1 true ResourceClaim
resourceclaimtemplates resource.k8s.io/v1 true ResourceClaimTemplate
resourceslices resource.k8s.io/v1 false ResourceSlice
```
```
kubectl get deviceclasses
```
```
NAME
compute-domain-daemon.nvidia.com
compute-domain-default-channel.nvidia.com
```
## Installa il plug-in del dispositivo EFA
Per utilizzare la comunicazione EFA tra UltraServers, devi installare il plug-in del dispositivo Kubernetes per EFA. GB200 Le istanze P6e- possono essere configurate con un massimo di [17 schede di rete](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) e l'NCI primario (indice 0) deve essere di tipo `interface` e supporta fino a 100 Gbps di larghezza di banda ENA. Configura le interfacce EFA ed ENA in base alle tue esigenze durante il provisioning dei nodi. Consulta la [AWS documentazione relativa alla configurazione EFA per le GB200 istanze P6e per maggiori dettagli](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) sulla configurazione EFA.
1. Create un file di valori Helm denominato con la seguente configurazione. `efa-values.yaml`
```
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
1. Installa l'operatore NVIDIA DRA per il tuo cluster utilizzando il `dra-values.yaml` file creato nel passaggio precedente.
```
helm repo add eks https://aws.github.io/eks-charts
helm repo update
```
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system \
--version="0.5.14" \
-f efa-values.yaml
```
Ad esempio, se hai configurato le istanze con 1 interfaccia solo efa in ogni [gruppo NCI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e), quando descrivi un nodo, si prevede che vengano visualizzati 4 dispositivi EFA allocabili per nodo.
```
kubectl describe node/
```
```
Capacity:
...
vpc.amazonaws.com/efa: 4
Allocatable:
...
vpc.amazonaws.com/efa: 4
```
## Convalida IMEX su più nodi NVLink
Per un test NVLINK NCCL multinodo e altri micro-benchmark, consulta il repository. [awesome-distributed-training](https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests) GitHub I passaggi seguenti mostrano come eseguire un test multinodo con nvbandwidth. NVLink
1. Per eseguire un test della larghezza di banda multinodo su due nodi del NVL72 dominio, installa prima l'operatore MPI:
```
kubectl create -f https://github.com/kubeflow/mpi-operator/releases/download/v0.7.0/mpi-operator.yaml
```
1. Create un file di valori Helm denominato `nvbandwidth-test-job.yaml` che definisce il manifesto del test. Nota l'affinità del `nvidia.com/gpu.clique` pod per pianificare i lavoratori nello stesso NVLink dominio con raggiungibilità NVLink multinodo. L'esempio seguente esegue un test memcpy device-to-device CE Read multi-nodo utilizzando cuMemcpyAsync e stampa i risultati nei log.
A partire dalla versione NVIDIA DRA, i driver `v25.8.0` ComputeDomains sono elastici e `.spec.numNodes` possono essere impostati nella definizione. `0` ComputeDomain Consulta le ultime note di [rilascio del driver NVIDIA DRA](https://github.com/NVIDIA/k8s-dra-driver-gpu) per gli aggiornamenti.
```
---
apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
name: nvbandwidth-test-compute-domain
spec:
numNodes: 0 # This can be set to 0 from NVIDIA DRA Driver version v25.8.0+
channel:
resourceClaimTemplate:
name: nvbandwidth-test-compute-domain-channel
---
apiVersion: kubeflow.org/v2beta1
kind: MPIJob
metadata:
name: nvbandwidth-test
spec:
slotsPerWorker: 4 # 4 GPUs per worker node
launcherCreationPolicy: WaitForWorkersReady
runPolicy:
cleanPodPolicy: Running
sshAuthMountPath: /home/mpiuser/.ssh
mpiReplicaSpecs:
Launcher:
replicas: 1
template:
metadata:
labels:
nvbandwidth-test-replica: mpi-launcher
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
# Only schedule on NVIDIA GB200/GB300 nodes
- key: node.kubernetes.io/instance-type
operator: In
values:
- p6e-gb200.36xlarge
- p6e-gb300.36xlarge
containers:
- image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163
name: mpi-launcher
securityContext:
runAsUser: 1000
command:
- mpirun
args:
- --bind-to
- core
- --map-by
- ppr:4:node
- -np
- "8"
- --report-bindings
- -q
- nvbandwidth
- -t
- multinode_device_to_device_memcpy_read_ce
Worker:
replicas: 2 # 2 worker nodes
template:
metadata:
labels:
nvbandwidth-test-replica: mpi-worker
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
# Only schedule on NVIDIA GB200/GB300 nodes
- key: node.kubernetes.io/instance-type
operator: In
values:
- p6e-gb200.36xlarge
- p6e-gb300.36xlarge
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: nvbandwidth-test-replica
operator: In
values:
- mpi-worker
topologyKey: nvidia.com/gpu.clique
containers:
- image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163
name: mpi-worker
securityContext:
runAsUser: 1000
env:
command:
- /usr/sbin/sshd
args:
- -De
- -f
- /home/mpiuser/.sshd_config
resources:
limits:
nvidia.com/gpu: 4 # Request 4 GPUs per worker
claims:
- name: compute-domain-channel # Link to IMEX channel
resourceClaims:
- name: compute-domain-channel
resourceClaimTemplateName: nvbandwidth-test-compute-domain-channel
```
1. Crea ComputeDomain e avvia il processo con il seguente comando.
```
kubectl apply -f nvbandwidth-test-job.yaml
```
1. ComputeDomain creazione, puoi vedere che il carico di lavoro ComputeDomain ha due nodi:
```
kubectl get computedomains.resource.nvidia.com -o yaml
```
```
status:
nodes:
- cliqueID: .
ipAddress:
name:
- cliqueID: .
ipAddress:
name:
status: Ready
```
1. Esamina i risultati del lavoro con il seguente comando.
```
kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher
```
Un test riuscito mostra le statistiche sulla larghezza di banda GB/s per il test memcpy a più nodi. Di seguito è riportato un esempio di risultato positivo del test.
```
...
nvbandwidth Version: ...
Built from Git version: ...
MPI version: ...
CUDA Runtime Version: ...
CUDA Driver Version: ...
Driver Version: ...
Process 0 (nvbandwidth-test-worker-0): device 0: NVIDIA GB200 (...)
Process 1 (nvbandwidth-test-worker-0): device 1: NVIDIA GB200 (...)
Process 2 (nvbandwidth-test-worker-0): device 2: NVIDIA GB200 (...)
Process 3 (nvbandwidth-test-worker-0): device 3: NVIDIA GB200 (...)
Process 4 (nvbandwidth-test-worker-1): device 0: NVIDIA GB200 (...)
Process 5 (nvbandwidth-test-worker-1): device 1: NVIDIA GB200 (...)
Process 6 (nvbandwidth-test-worker-1): device 2: NVIDIA GB200 (...)
Process 7 (nvbandwidth-test-worker-1): device 3: NVIDIA GB200 (...)
Running multinode_device_to_device_memcpy_read_ce.
memcpy CE GPU(row) -> GPU(column) bandwidth (GB/s)
0 1 2 3 4 5 6 7
0 N/A 821.45 822.18 821.73 822.05 821.38 822.61 821.89
1 822.34 N/A 821.67 822.12 821.94 820.87 821.53 822.08
2 821.76 822.29 N/A 821.58 822.43 821.15 821.82 822.31
3 822.19 821.84 822.05 N/A 821.67 821.23 820.95 822.47
4 821.63 822.38 821.49 822.17 N/A 821.06 821.78 822.22
5 822.08 821.52 821.89 822.35 821.27 N/A 821.64 822.13
6 821.94 822.15 821.68 822.04 821.39 820.92 N/A 822.56
7 822.27 821.73 822.11 821.86 822.38 821.04 821.49 N/A
SUM multinode_device_to_device_memcpy_read_ce ...
NOTE: The reported results may not reflect the full capabilities of the platform.
Performance can vary with software drivers, hardware clocks, and system topology.
```
1. Quando il test è completo, eliminalo con il seguente comando.
```
kubectl delete -f nvbandwidth-test-job.yaml
```