**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 su che si trova 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à.

# Usa GPU multiistanza (MIG) con GPU NVIDIA su Amazon EKS
<a name="device-management-nvidia-mig"></a>

 [Multi-Instance La GPU ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/index.html) (MIG) è una funzionalità hardware delle GPU NVIDIA che partiziona una singola GPU fisica in più istanze isolate. Il numero massimo di istanze partizionate dipende dalla GPU. Ogni istanza dispone di memoria, unità di calcolo e larghezza di banda di memoria dedicate, pertanto un carico di lavoro eseguito su un'istanza non può influire su un carico di lavoro su un'altra. A differenza del [ time-slicing](device-management-nvidia-time-slicing.md), che condivide una GPU tramite il time-multiplexing del software senza isolamento, il MIG fornisce memoria a livello hardware e isolamento dei guasti tra i pod.

MIG è più adatto per l'inferenza multi-tenant e per i carichi di lavoro che richiedono una qualità del servizio prevedibile. È disponibile sulle GPU NVIDIA Ampere (A100), Hopper (H100 e H200) e Blackwell. Sì AWS, questi sono i tipi di istanza e i tipi di istanza e P-family . Blackwell-based `g7` `g7e` Per l'elenco completo, consulta [MIG-capable tipi di istanza](#eks-mig-capable-instance-types).

Il MIG è adatto quando:
+ È necessario isolare la memoria, in modo che un carico di lavoro non possa consumare la memoria GPU richiesta da un altro carico di lavoro.
+ Si esegue un'inferenza multi-tenant in cui i tenant condividono l'hardware della GPU ma richiedono una qualità del servizio per tenant.
+ Esegui già il training su istanze A100, H100, H200 o Blackwell e desideri riutilizzare tali GPU per carichi di lavoro di inferenza più piccoli quando l'addestramento è inattivo.

Prendi in considerazione un approccio diverso quando:
+ I nodi utilizzano un tipo di istanza GPU che non supporta MIG, ad esempio le famiglie`g5`,`g6`, o`g6e`. Usa invece il [ time-slicing](device-management-nvidia-time-slicing.md).
+ Non è necessario l'isolamento della memoria e si desidera la configurazione più semplice. Usa invece il [ time-slicing. ](device-management-nvidia-time-slicing.md)
+ È necessario modificare frequentemente le partizioni della GPU senza interruzioni. La modifica della modalità MIG o del layout delle partizioni richiede un ripristino della GPU, che l'operatore GPU esegue riavviando il nodo.
+ Si esegue un training su più GPU che dipende dalla comunicazione collettiva o peer-to-peer tra le GPU. MIG non supporta NCCL o P2P tra GPU.

## Considerazioni
<a name="eks-mig-considerations"></a>

Esamina le seguenti considerazioni prima di utilizzare MIG in produzione.

### Considerazioni generali
<a name="_general_considerations"></a>
+  **La modifica della configurazione MIG richiede un ripristino della GPU. ** L'attivazione o la disattivazione della modalità MIG o la modifica del layout della partizione richiede un ripristino della GPU, quindi non può essere modificato sul posto. Ad esempio, il MIG Manager di NVIDIA GPU Operator applica una modifica alla configurazione arrestando i GPU Pod sul nodo e riavviando il nodo quando è necessario un riavvio per cambiare la modalità MIG.
+  **L'elaborazione non è strettamente proporzionale alla dimensione dell'istanza. ** Un'`1g`istanza non fornisce una quota proporzionale del throughput dell'intera GPU per ogni carico di lavoro, poiché la larghezza di banda della memoria e il comportamento della cache differiscono a seconda dei profili. Esegui il benchmark del tuo carico di lavoro sul profilo che intendi utilizzare prima di dimensionare le partizioni.
+  **Time-slicing non ha effetto sulle istanze MIG. ** Un'istanza MIG è già isolata dall'hardware e non può essere ulteriormente condivisa tramite time-slicing. La richiesta della strategia di `TimeSlicing` condivisione su un dispositivo MIG non modifica il comportamento dell'hardware. Per condividere una singola istanza MIG tra container, usa invece NVIDIA Multi-Process Service (MPS).
+  **Comunicazione tra GPU limitata. ** Quando il MIG è abilitato, le istanze MIG su GPU diverse non possono utilizzare la comunicazione GPU-to-GPU peer-to-peer (P2P) e NCCL non funziona con MIG. Multi-GPU i carichi di lavoro che dipendono dalla comunicazione collettiva o dal P2P tra le GPU, come l'addestramento di più GPU in parallelo con tensori, richiedono invece GPU intere. Per i dettagli, consulta le Considerazioni sulle [ applicazioni nella Guida per l'utente di NVIDIA MIG sul sito Web di ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#application-considerations) NVIDIA.

### Considerazioni sui plug-in dei dispositivi NVIDIA
<a name="_nvidia_device_plugin_considerations"></a>
+  **Le richieste di risorse dei pod devono corrispondere alla strategia. ** Con l'unica strategia, Pods request`nvidia.com/gpu`. Con la strategia mista, i Pods richiedono la risorsa specifica del profilo, ad esempio. `nvidia.com/mig-1g.10gb` Un Pod che richiede un profilo che il nodo non pubblicizza rimane nello stato. `Pending` Conferma le risorse pubblicizzate con. `kubectl describe node <node-name>`
+  **Plugin per dispositivi standalone su AL2023. ** Se installi il plug-in del dispositivo NVIDIA separatamente, ad esempio come parte della configurazione del cluster, escludilo dai tuoi nodi MIG in modo che non entri in conflitto con il plug-in del dispositivo gestito dall'operatore GPU. Aggiungi una regola di affinità dei nodi al plug-in del dispositivo autonomo che escluda i nodi con l'etichetta. `nvidia.com/mig.config`
+  **Nessun supporto per la modalità EKS Auto. ** EKS Auto Mode gestisce il plug-in del dispositivo NVIDIA e non ne espone la configurazione (vedere[Implementare un carico di lavoro accelerato](auto-accelerated.md)). Non è possibile abilitare MIG sui nodi EKS Auto Mode. Configura MIG su nodi Karpenter autogestiti o su un gruppo di nodi gestiti, in cui controlli le impostazioni dell'AMI e del plug-in del dispositivo.

### Considerazioni sui driver NVIDIA DRA
<a name="_nvidia_dra_driver_considerations"></a>
+  **Il MIG statico richiede istanze precreate. ** Con il MIG statico, il driver DRA alloca le istanze MIG esistenti ma non abilita la modalità MIG né partiziona le GPU. È necessario abilitare la modalità MIG e creare prima le istanze, ad esempio con MIG Manager in NVIDIA GPU Operator o. `nvidia-smi` Per ulteriori informazioni, consulta [Usa MIG con il driver NVIDIA DRA](#eks-mig-dra-driver).
+  **Dynamic MIG è una funzionalità alpha. ** Con il MIG dinamico, il driver crea e distrugge partizioni MIG su richiesta in risposta alle richieste di carico di lavoro. Richiede il `DynamicMIG` feature gate, che è disabilitato per impostazione predefinita. Per ulteriori informazioni, consulta [Usa MIG con il driver NVIDIA DRA](#eks-mig-dra-driver).
+  **Disabilita il plug-in del dispositivo integrato su Bottlerocket. ** Il driver DRA non può essere eseguito insieme al plug-in del dispositivo NVIDIA sullo stesso nodo. Su Bottlerocket, disabilita il plug-in del dispositivo integrato, che richiede Bottlerocket versione 1.63.0 o successiva. Per ulteriori informazioni, consulta [Installa il driver NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver).
+  **Supporto informatico. ** Il driver NVIDIA DRA è supportato con il provisioning statico della capacità in Karpenter, gruppi di nodi gestiti EKS o nodi autogestiti e non è supportato con EKS Auto Mode. Per ulteriori informazioni, consulta la documentazione statica di Karpenter sul sito Web di [ Karpenter. NodePool ](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool)

## MIG-capable tipi di istanza
<a name="eks-mig-capable-instance-types"></a>

Attivata AWS, i seguenti tipi di istanza forniscono MIG-capable GPU.


| Tipo di istanza | GPU | Memoria GPU | 
| --- | --- | --- | 
|  `p4d.24xlarge`  | 8 x NVIDIA A100 da 40 GB | 320 GB | 
|  `p4de.24xlarge`  | 8 x NVIDIA A100 da 80 GB | 640 GB | 
|  `p5.48xlarge`  | 8 x NVIDIA H100 da 80 GB | 640 GB | 
|  `p5e.48xlarge`  | 8 x NVIDIA H200 | 128 GB | 
|  `p5en.48xlarge`  | 8 x NVIDIA H200 | 128 GB | 
|  `p6-b200.48xlarge`  | 8 x NVIDIA Blackwell B200 | 1432 GB | 
|  `p6-b300.48xlarge`  | 8 x NVIDIA Blackwell Ultra B300 | 2144 GB | 
|  `g7.48xlarge`  | 8 x NVIDIA RTX PRO 4500 Blackwell Server Edition | 256 GB | 
|  `g7e.48xlarge`  | 8 x NVIDIA RTX PRO 6000 Blackwell Server Edition | 768 GB | 

MIG non è disponibile nelle famiglie`g5`,`g6`, o`g6e`. Per chi utilizza `p6e-gb200` UltraServers la MIG-capable GPU NVIDIA GB200, vedere. [Utilizzo P6e-GB200 UltraServers con Amazon EKS](ml-eks-nvidia-ultraserver.md)

**Nota**  
Il tipo di `g7` istanza richiede la versione 595 del driver NVIDIA o successiva. Le AMI EKS-optimized accelerate attualmente includono il driver NVIDIA versione 580, quindi per utilizzare MIG su è `g7` necessario creare un'AMI personalizzata con la versione del driver 595. Per ulteriori informazioni, consulta [Crea un'AMI EKS-optimized Amazon Linux personalizzata](eks-ami-build-scripts.md).

Le istanze MIG sono descritte da profili che utilizzano il modello di denominazione`<slices>g.<memory>gb`, dove `<slices>` è il numero di slice di calcolo e la memoria dell'istanza in gigabyte. `<memory>` Ad esempio, il `3g.40gb` profilo fornisce tre delle sette slice di calcolo e 40 GB di memoria. I profili supportati da ciascuna GPU vengono fissati dall'hardware. Per l'elenco completo, consulta la Guida per l'utente della Multi-Instance GPU [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) sul sito Web di NVIDIA.

## Profili MIG per tipo di istanza
<a name="eks-mig-profiles-per-instance-type"></a>

I profili MIG disponibili su un nodo dipendono dalla GPU per il tipo di istanza. Le sezioni seguenti elencano i profili per ogni tipo di istanza MIG-capable Amazon EC2. Per ogni profilo, il numero ** massimo di istanze ** è il numero massimo di istanze di quel profilo che puoi creare su una singola GPU e ** Memoria per istanza ** è la memoria GPU allocata a ciascuna di esse.

### ``p4d.24xlarge — NVIDIA A100 40 GB
<a name="eks-mig-profiles-p4d"></a>


| Profilo | Fette di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.5gb`  | 1 di 7 | 5 GB | 7 | 
|  `1g.10gb`  | 1 di 7 | 10 GB | 4 | 
|  `2g.10gb`  | 2 di 7 | 10 GB | 3 | 
|  `3g.20gb`  | 3 di 7 | 20 GB | 2 | 
|  `4g.20gb`  | 4 di 7 | 20 GB | 1 | 
|  `7g.40gb`  | 7 di 7 | 40 GB | 1 | 

### ``p4de.24xlarge — NVIDIA A100 80 GB
<a name="eks-mig-profiles-p4de"></a>


| Profilo | Sezioni di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 di 7 | 10 GB | 7 | 
|  `1g.20gb`  | 1 di 7 | 20 GB | 4 | 
|  `2g.20gb`  | 2 di 7 | 20 GB | 3 | 
|  `3g.40gb`  | 3 di 7 | 40 GB | 2 | 
|  `4g.40gb`  | 4 di 7 | 40 GB | 1 | 
|  `7g.80gb`  | 7 di 7 | 80 GB | 1 | 

### `p5.48xlarge` — NVIDIA H100 80 GB
<a name="eks-mig-profiles-p5"></a>


| Profilo | Fette di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 di 7 | 10 GB | 7 | 
|  `1g.20gb`  | 1 di 7 | 20 GB | 4 | 
|  `2g.20gb`  | 2 di 7 | 20 GB | 3 | 
|  `3g.40gb`  | 3 di 7 | 40 GB | 2 | 
|  `4g.40gb`  | 4 di 7 | 40 GB | 1 | 
|  `7g.80gb`  | 7 di 7 | 80 GB | 1 | 

### `p5e.48xlarge` e `` p5en.48xlarge — NVIDIA H200 141 GB
<a name="eks-mig-profiles-p5e-p5en"></a>


| Profilo | Sezioni di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.18gb`  | 1 di 7 | 18 GB | 7 | 
|  `1g.35gb`  | 1 di 7 | 35 GB | 4 | 
|  `2g.35gb`  | 2 di 7 | 35 GB | 3 | 
|  `3g.71gb`  | 3 di 7 | 71 GB | 2 | 
|  `4g.71gb`  | 4 di 7 | 71 GB | 1 | 
|  `7g.141gb`  | 7 di 7 | 141 GB | 1 | 

### ``p6-b200.48xlarge — NVIDIA Blackwell B200 da 180 GB
<a name="eks-mig-profiles-p6-b200"></a>


| Profilo | Fette di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.23gb`  | 1 di 7 | 23 GB | 7 | 
|  `1g.45gb`  | 1 di 7 | 45 GB | 4 | 
|  `2g.45gb`  | 2 di 7 | 45 GB | 3 | 
|  `3g.90gb`  | 3 di 7 | 90 GB | 2 | 
|  `4g.90gb`  | 4 di 7 | 90 GB | 1 | 
|  `7g.180gb`  | 7 di 7 | 180 GB | 1 | 

**``p6-b300.48xlarge — NVIDIA Blackwell Ultra B300**  
`p6-b300.48xlarge`Utilizza l'HGX B300, che supporta il partizionamento di ciascuna GPU in 7 istanze da 32 GB, 4 da 67 GB, 2 da 135 GB o 1 da 270 GB. Queste dimensioni sono preliminari e potrebbero cambiare. Per i dettagli del profilo, consulta i profili MIG supportati da [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) sul sito Web di NVIDIA.

### `g7.48xlarge` — NVIDIA RTX PRO 4500 Blackwell Server Edition da 32 GB
<a name="eks-mig-profiles-g7"></a>


| Profilo | Sezioni di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.16gb`  | 1 di 2 | 16 GB | 2 | 
|  `2g.32gb`  | 2 di 2 | 32 GB | 1 | 

L'RTX PRO 4500 Blackwell supporta anche varianti di profilo abilitate alla grafica (`+gfx`) e media-engine (,). `+me.all` `-me` Per l'elenco completo, consulta i profili MIG supportati da NVIDIA sul sito Web di [ NVIDIA. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html)

### `g7e.48xlarge` — NVIDIA RTX PRO 6000 Blackwell Server Edition 96 GB
<a name="eks-mig-profiles-g7e"></a>


| Profilo | Sezioni di calcolo | Memoria per istanza | Numero massimo di istanze | 
| --- | --- | --- | --- | 
|  `1g.24gb`  | 1 di 4 | 24 GB | 4 | 
|  `2g.48gb`  | 2 di 4 | 48 GB | 2 | 
|  `4g.96gb`  | 4 di 4 | 96 GB | 1 | 

L'RTX PRO 6000 Blackwell Server Edition supporta anche varianti di profilo abilitate alla grafica (`+gfx`) e media-engine (,). `+me.all` `-me` Per l'elenco completo, consulta i profili MIG supportati da NVIDIA sul sito Web di [ NVIDIA. ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html)

## Strategie MIG
<a name="eks-mig-strategies"></a>

Il driver NVIDIA DRA e il plug-in del dispositivo NVIDIA espongono le istanze MIG a Kubernetes in diversi modi. Il plug-in del dispositivo utilizza un'impostazione della strategia ** MIG a livello di nodo, mentre il driver DRA non ha un'**impostazione equivalente perché seleziona le istanze in base ai relativi attributi. Comprendere questa differenza è fondamentale per scegliere tra i due modelli.

### Driver NVIDIA DRA
<a name="_nvidia_dra_driver"></a>

Il driver NVIDIA DRA non utilizza il concetto di strategia singola o mista e non esiste un'impostazione equivalente da configurare. Invece di pubblicizzare le istanze MIG come risorse conteggiate, il driver pubblica ogni istanza come dispositivo `mig.nvidia.com` `DeviceClass` con attributi come il suo. `profile` I pod selezionano un'istanza facendo corrispondere questi attributi ai selettori CEL (Common Expression Language) in un `ResourceClaim` o`ResourceClaimTemplate`, come mostrato in. [Usa MIG con il driver NVIDIA DRA](#eks-mig-dra-driver)

Poiché la selezione è per istanza, i nodi a profilo misto funzionano senza un cambio di modalità strategica. Una singola GPU può essere suddivisa in diversi profili e ogni claim seleziona il profilo di cui ha bisogno. La scelta che conta per il driver DRA non è la strategia MIG singola o mista, ma la strategia MIG statica o dinamica, che determina se le istanze MIG sono precreate o il driver le crea su richiesta. Per ulteriori informazioni, consulta [Usa MIG con il driver NVIDIA DRA](#eks-mig-dra-driver).

### Plugin per dispositivi NVIDIA
<a name="_nvidia_device_plugin"></a>

Il plug-in per dispositivi NVIDIA pubblicizza le istanze MIG su Kubernetes utilizzando una delle due strategie. Poiché il plug-in del dispositivo espone le istanze MIG come risorse estese a livello di nodo, che contengono solo un conteggio di numeri interi e nessun attributo per istanza, la strategia determina il nome di tali risorse.
+  **Strategia singola**: ogni GPU su un nodo utilizza lo stesso profilo MIG. Il plug-in del dispositivo pubblicizza ogni istanza come `nvidia.com/gpu` risorsa e i Pods richiedono `nvidia.com/gpu: 1` come farebbero per una GPU dedicata. I manifesti esistenti non vengono modificati. Sia Bottlerocket che AL2023 supportano la strategia unica.
+  **Strategia mista**: le GPU sullo stesso nodo possono utilizzare diversi profili MIG. Il plug-in del dispositivo pubblicizza ogni profilo come una risorsa distinta, ad esempio `nvidia.com/mig-1g.10gb` or`nvidia.com/mig-3g.40gb`, e i Pods richiedono il profilo specifico di cui hanno bisogno. Non è possibile utilizzare una strategia mista con il plug-in per dispositivi NVIDIA integrato di Bottlerocket. Per ulteriori informazioni, consulta il numero \#4483 di [ GitHub Bottlerocket su. ](https://github.com/bottlerocket-os/bottlerocket/issues/4483) GitHub

## Usa MIG con il driver NVIDIA DRA
<a name="eks-mig-dra-driver"></a>

Quando si allocano le istanze MIG con il driver NVIDIA DRA, i Pod richiedono un'istanza MIG tramite un `ResourceClaim` or anziché la risorsa estesa del plug-in del dispositivo. `ResourceClaimTemplate` `nvidia.com/mig-<profile>`

Poiché il driver DRA descrive le istanze in base ai relativi attributi anziché come risorse conteggiate, non utilizza la strategia singola o mista richiesta dal plug-in del dispositivo (vedere). [Strategie MIG](#eks-mig-strategies) Il driver espone ogni istanza MIG come dispositivo `mig.nvidia.com` `DeviceClass` con un `gpu.nvidia.com/type` attributo of `mig` e pubblicizza attributi per istanza come `profile` (ad esempio`1g.5gb`) e della GPU fisica. `parentUUID` È possibile abbinare questi attributi ai selettori CEL (Common Expression Language) per richiedere un profilo specifico o per mantenere più istanze sulla stessa GPU.

Il driver DRA alloca le istanze MIG in una delle due modalità seguenti:
+  **MIG statico**: si abilita la modalità MIG e si creano le istanze MIG sul nodo prima dell'avvio del driver, ad esempio con il MIG Manager in NVIDIA GPU Operator, come descritto in. [Usa MIG sui nodi AL2023 con il plug-in del dispositivo NVIDIA](#eks-mig-device-plugin-al2023) Il driver rileva le istanze esistenti e le assegna ai Pods ma non modifica la configurazione MIG del nodo. Le istanze aggiunte dopo l'avvio del driver non vengono scoperte fino al riavvio del plug-in GPU kubelet. Il MIG statico è l'impostazione predefinita e non richiede alcun feature gate.
+  **MIG dinamico**: il driver crea e distrugge partizioni MIG su richiesta in risposta alle richieste di carico di lavoro, in modo da non partizionare le GPU in anticipo. Il MIG dinamico è una funzionalità alfa disattivata per impostazione predefinita. Si richiede un profilo con gli stessi `ResourceClaimTemplate` selettori mostrati nelle sezioni seguenti e il driver partiziona una GPU per soddisfare la richiesta.

### Considerazioni
<a name="_considerations"></a>
+ Il MIG dinamico sostituisce il rilevamento statico su un nodo. Il driver gestisce tutte le partizioni e distrugge tutte le partizioni MIG che non ha creato all'avvio del plug-in GPU kubelet. Non attivate il MIG dinamico sui nodi con partizioni predefinite che desiderate conservare e non eseguite `mig-parted` né `nvidia-smi mig` mentre il plugin è in esecuzione, perché le modifiche manuali possono entrare in conflitto con lo stato della partizione del driver e causare il fallimento della preparazione o della pulizia del Pod.
+ Il MIG dinamico è in stato alfa e richiede l'attivazione di un feature gate durante l'installazione del driver NVIDIA DRA, vedi le istruzioni. [Installa il driver NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver)
+ Le architetture Hopper (H100 e H200) e successive abilitano la modalità MIG su richiesta. Le generazioni precedenti non possono abilitare la modalità MIG on demand, incluse le GPU Ampere (A100).
+ Il MIG dinamico dipende dalla funzionalità dei dispositivi partizionabili di Kubernetes (attiva GitHub), abilitata per impostazione predefinita [ KEP-4815 ](https://github.com/kubernetes/enhancements/issues/4815) nella versione 1.36 e successive di Kubernetes. Nelle versioni precedenti questa funzionalità non è abilitata per impostazione predefinita, quindi lo scheduler non può allocare dispositivi MIG creati dinamicamente.

### Prerequisiti
<a name="_prerequisites"></a>
+ Un cluster Amazon EKS che esegue Kubernetes versione 1.34 o successiva con capacità statica fornita da Karpenter, gruppi di nodi gestiti da EKS o gruppi di nodi autogestiti.
+ MIG-capable P-family nodi con modalità MIG abilitata e GPU partizionate in istanze MIG. Per il MIG statico, consulta [ MIG Manager nella sezione NVIDIA GPU Operator sul sito Web di NVIDIA. ](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html)
+ Il driver NVIDIA DRA è stato installato come descritto in[Installa il driver NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver), opzionalmente con Dynamic MIG abilitato se non si utilizza il partizionamento MIG statico.

### Procedura
<a name="_procedure"></a>

I seguenti esempi possono essere utilizzati con MIG statico o dinamico e il driver NVIDIA DRA.

1. Crea un file `ResourceClaimTemplate` che richieda un'istanza MIG da e un Pod che `mig.nvidia.com` `DeviceClass` vi faccia riferimento. Questo esempio richiede qualsiasi istanza MIG disponibile senza vincolare il profilo.

   ```
   cat <<EOF | kubectl apply -f -
   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: mig-profile-any
   spec:
     spec:
       devices:
         requests:
         - name: mig
           exactly:
             deviceClassName: mig.nvidia.com
             count: 1
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: mig-dra-pod
   spec:
     tolerations:
       - key: nvidia.com/gpu
         operator: Exists
         effect: NoSchedule
     containers:
       - name: cuda
         image: nvidia/cuda:12.6.0-base-ubuntu22.04
         command: ["nvidia-smi", "-L"]
         resources:
           claims:
           - name: mig
     resourceClaims:
       - name: mig
         resourceClaimTemplateName: mig-profile-any
     restartPolicy: OnFailure
   EOF
   ```

1. Verifica che al Pod sia stata assegnata una singola istanza MIG.

   ```
   kubectl logs mig-dra-pod
   ```

   Di seguito viene riportato un output di esempio. Il Pod vede un'istanza MIG dalla GPU partizionata.

   ```
   GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-edd63844-8488-f76a-f6e0-1027a7319a88)
     MIG 2g.10gb     Device  0: (UUID: MIG-a5ad493e-e7e8-5675-9381-1d0f5311a456)
   ```

### Richiedi un profilo MIG specifico
<a name="_request_a_specific_mig_profile"></a>

Per richiedere un profilo specifico anziché qualsiasi istanza disponibile, aggiungi un selettore CEL che corrisponda all'`profile`attributo. Quanto segue `ResourceClaimTemplate` richiede un'`1g.5gb`istanza e il Pod vi fa riferimento.

```
cat <<EOF | kubectl apply -f -
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: mig-profile-1g.5gb
spec:
  spec:
    devices:
      requests:
      - name: mig
        exactly:
          deviceClassName: mig.nvidia.com
          selectors:
          - cel:
              expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'"
---
apiVersion: v1
kind: Pod
metadata:
  name: mig-profile-pod
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: cuda
      image: nvidia/cuda:12.6.0-base-ubuntu22.04
      command: ["nvidia-smi", "-L"]
      resources:
        claims:
        - name: mig
  resourceClaims:
    - name: mig
      resourceClaimTemplateName: mig-profile-1g.5gb
  restartPolicy: OnFailure
EOF
```

### Richiedi più istanze MIG dalla stessa GPU
<a name="_request_multiple_mig_instances_from_the_same_gpu"></a>

Per garantire che più istanze MIG in una singola richiesta provengano dalla stessa GPU fisica, aggiungi un blocco con. `constraints` `matchAttribute: "gpu.nvidia.com/parentUUID"` Quanto segue `ResourceClaimTemplate` richiede un'`1g.5gb`istanza e un'`2g.10gb`istanza dalla stessa GPU e il Pod fa riferimento al claim. Poiché il contenitore fa riferimento al claim senza nominare una richiesta specifica, riceve entrambe le istanze MIG.

```
cat <<EOF | kubectl apply -f -
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: multi-mig
spec:
  spec:
    devices:
      requests:
      - name: mig-small
        exactly:
          deviceClassName: mig.nvidia.com
          selectors:
          - cel:
              expression: "device.attributes['gpu.nvidia.com'].profile == '1g.5gb'"
      - name: mig-medium
        exactly:
          deviceClassName: mig.nvidia.com
          selectors:
          - cel:
              expression: "device.attributes['gpu.nvidia.com'].profile == '2g.10gb'"
      constraints:
      - requests: []
        matchAttribute: "gpu.nvidia.com/parentUUID"
---
apiVersion: v1
kind: Pod
metadata:
  name: multi-mig-pod
spec:
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: cuda
      image: nvidia/cuda:12.6.0-base-ubuntu22.04
      command: ["nvidia-smi", "-L"]
      resources:
        claims:
        - name: mig
  resourceClaims:
    - name: mig
      resourceClaimTemplateName: multi-mig
  restartPolicy: OnFailure
EOF
```

## Usa MIG sui nodi Bottlerocket con il plug-in del dispositivo NVIDIA
<a name="eks-mig-device-plugin-bottlerocket"></a>

Su Bottlerocket, l'AMI accelerata include il EKS-optimized plug-in del dispositivo NVIDIA. È possibile abilitare MIG con la singola strategia tramite le impostazioni. `settings.kubelet-device-plugins.nvidia` Bottlerocket supporta MIG nella versione 1.34.0 e successive.

### Prerequisiti
<a name="_prerequisites_2"></a>
+ Un cluster Amazon EKS. La procedura seguente esegue il provisioning MIG-capable P-family dei nodi con l'AMI NVIDIA EKS-optimized Bottlerocket, versione 1.34.0 o successiva.
+ Karpenter è stato installato e configurato nel cluster, poiché la procedura seguente utilizza un Karpenter per fornire le impostazioni MIG nei dati utente del nodo `EC2NodeClass` Bottlerocket. Per ulteriori informazioni, consulta la [ Guida introduttiva a Karpenter sul sito Web di Karpenter. ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/)
+  `kubectl`configurato per comunicare con il tuo cluster, vedi [`Installa o aggiorna kubectl`](install-kubectl.md#kubectl-install-update) per ulteriori informazioni.

### Procedura
<a name="_procedure_2"></a>

Aggiungi l'impostazione di partizionamento MIG ai dati utente di Bottlerocket per i tuoi nodi GPU. Il modo in cui fornisci i dati utente dipende dal modo in cui esegui il provisioning dei nodi. L'esempio seguente mostra un Karpenter `EC2NodeClass` per i `p4d.24xlarge` nodi.

```
cat <<EOF | kubectl apply -f -
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: gpu-bottlerocket-mig
spec:
  amiFamily: Bottlerocket
  amiSelectorTerms:
    - alias: bottlerocket@latest
  role: eksctl-KarpenterNodeRole-<cluster-name>
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: <cluster-name>
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: <cluster-name>
  userData: |
    [settings.kubelet-device-plugins.nvidia]
    device-partitioning-strategy = "mig"

    [settings.kubelet-device-plugins.nvidia.mig.profile]
    "a100.40gb" = "2g.10gb"
EOF
```

Quando i nodi dotati di queste impostazioni si uniscono al cluster, la modalità MIG viene abilitata sulle GPU, ogni GPU viene partizionata in `2g.10gb` istanze e il plug-in del dispositivo pubblicizza le istanze risultanti come risorsa. `nvidia.com/gpu` Poiché a `p4d.24xlarge` ha otto GPU A100 e ciascuna supporta tre istanze, il nodo fa pubblicità. `2g.10gb` `nvidia.com/gpu: 24`

**Nota**  
L'`mig.profile`impostazione è codificata in base al modello di GPU, ad esempio o. `a100.40gb` `h100.80gb` Senza un'`mig.profile`impostazione, la GPU attiva la modalità MIG e utilizza il suo profilo più grande. Poiché Bottlerocket utilizza la strategia singola, ogni GPU sul nodo utilizza lo stesso profilo. Per utilizzare profili diversi sullo stesso nodo (strategia mista), utilizza il percorso AL2023 con NVIDIA GPU Operator.

## Usa MIG sui nodi AL2023 con il plug-in del dispositivo NVIDIA
<a name="eks-mig-device-plugin-al2023"></a>

In AL2023, i passaggi seguenti utilizzano NVIDIA GPU Operator per installare il plug-in del dispositivo NVIDIA e il MIG Manager. Il MIG Manager abilita la modalità MIG e partiziona le GPU in base alla configurazione fornita. Il plug-in del dispositivo NVIDIA quindi annuncia le istanze risultanti a Kubernetes. L'operatore GPU supporta sia la strategia singola che quella mista.

Poiché la NVIDIA AMI EKS-optimized AL2023 include già il driver e il toolkit NVIDIA, disabilita la gestione dei driver nel GPU Operator per evitare conflitti con il driver preinstallato. In alternativa, puoi installare e gestire tu stesso il plug-in del dispositivo NVIDIA e MIG Manager senza utilizzare l'operatore GPU.

### Prerequisiti
<a name="_prerequisites_3"></a>
+ Un cluster Amazon EKS. La seguente procedura prevede il MIG-capable P-family provisioning di nodi (ad esempio`p4d.24xlarge`) con l'AMI NVIDIA EKS-optimized AL2023.
+ Karpenter è installato e configurato nel cluster, perché la procedura crea un Karpenter `EC2NodeClass` e `NodePool` esegue il provisioning dei nodi GPU. Per ulteriori informazioni, consulta la [ Guida introduttiva a Karpenter sul sito Web di Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/).
+ Helm è installato nell’ambiente a riga di comando, consulta le [istruzioni di configurazione di Helm](helm.md) per ulteriori informazioni.
+  `kubectl`configurato per comunicare con il tuo cluster, vedi [`Installa o aggiorna kubectl`](install-kubectl.md#kubectl-install-update) per ulteriori informazioni.

### Procedura
<a name="_procedure_3"></a>

1. Crea un `EC2NodeClass` and `NodePool` per i nodi P-family GPU AL2023. In AL2023, il partizionamento MIG viene applicato dall'operatore GPU nei passaggi successivi, quindi si tratta di una classe di nodi GPU AL2023 standard. L'esempio seguente esegue il provisioning dei nodi con l'AMI `p4d.24xlarge` NVIDIA AL2023. EKS-optimized 

   ```
   cat <<EOF | kubectl apply -f -
   apiVersion: karpenter.k8s.aws/v1
   kind: EC2NodeClass
   metadata:
     name: gpu-mig-al2023
   spec:
     amiFamily: AL2023
     amiSelectorTerms:
       - alias: al2023@latest
     role: eksctl-KarpenterNodeRole-<cluster-name>
     subnetSelectorTerms:
       - tags:
           karpenter.sh/discovery: <cluster-name>
     securityGroupSelectorTerms:
       - tags:
           karpenter.sh/discovery: <cluster-name>
     tags:
       karpenter.sh/discovery: <cluster-name>
   ---
   apiVersion: karpenter.sh/v1
   kind: NodePool
   metadata:
     name: gpu-mig-al2023
   spec:
     template:
       spec:
         nodeClassRef:
           group: karpenter.k8s.aws
           kind: EC2NodeClass
           name: gpu-mig-al2023
         taints:
           - key: nvidia.com/gpu
             effect: NoSchedule
         requirements:
           - key: karpenter.sh/capacity-type
             operator: In
             values: ["spot", "on-demand"]
           - key: node.kubernetes.io/instance-type
             operator: In
             values: ["p4d.24xlarge"]
           - key: kubernetes.io/arch
             operator: In
             values: ["amd64"]
     limits:
       cpu: 1000
       memory: 5000Gi
   EOF
   ```

1. Aggiungi il repository NVIDIA Helm.

   ```
   helm repo add nvidia https://nvidia.github.io/gpu-operator
   helm repo update
   ```

1. Crea un `gpu-operator-values.yaml` file che disabiliti la gestione dei driver, selezioni la strategia mista e definisca i profili MIG da applicare. L'esempio seguente definisce una `p4d-half-balanced` configurazione che partiziona quattro delle otto GPU su un `p4d.24xlarge` nodo e lascia il resto intero.

   ```
   cat <<EOF > gpu-operator-values.yaml
   driver:
     enabled: false
   toolkit:
     enabled: false
   devicePlugin:
     enabled: true
   nfd:
     enabled: true
   gfd:
     enabled: true
   mig:
     strategy: mixed
   migManager:
     enabled: true
     env:
       - name: WITH_REBOOT
         value: "true"
     config:
       create: true
       name: custom-mig-parted-configs
       default: all-disabled
       data:
         config.yaml: |-
           version: v1
           mig-configs:
             all-disabled:
               - devices: all
                 mig-enabled: false
             p4d-half-balanced:
               - devices: [0, 1, 2, 3]
                 mig-enabled: true
                 mig-devices:
                   "1g.5gb": 2
                   "2g.10gb": 1
                   "3g.20gb": 1
               - devices: [4, 5, 6, 7]
                 mig-enabled: false
   EOF
   ```

1. Installa l'operatore GPU con il file dei valori.

   ```
   helm install gpu-operator nvidia/gpu-operator \
       --namespace gpu-operator \
       --create-namespace \
       --values gpu-operator-values.yaml
   ```

1. Etichetta i tuoi MIG-capable nodi con la configurazione del profilo da applicare. Il componente MIG Manager controlla questa etichetta e partiziona le GPU di conseguenza, riavviando il nodo per applicare la modifica.

   ```
   kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \
       nvidia.com/mig.config=p4d-half-balanced --overwrite
   ```

1. Dopo che l'operatore GPU ha partizionato le GPU, i Pods richiedono un profilo MIG specifico in base al nome della risorsa anziché. `nvidia.com/gpu` L'esempio seguente esegue un Pod che richiede un'istanza. `1g.5gb`

   ```
   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: mig-inference
   spec:
     tolerations:
       - key: nvidia.com/gpu
         operator: Exists
         effect: NoSchedule
     containers:
       - name: cuda
         image: nvidia/cuda:12.6.0-base-ubuntu22.04
         command: ["nvidia-smi", "-L"]
         resources:
           limits:
             nvidia.com/mig-1g.5gb: 1
   EOF
   ```

Per esempi completi di configurazione a strategia mista per P-family le istanze, inclusi gruppi di nodi gestiti con prenotazioni di capacità e carichi di lavoro per profilo, consulta la sezione MIG della Amazon EKS Best Practices Guide. [https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)

## Verifica che MIG sia attivo
<a name="eks-mig-verify"></a>

Dopo aver installato i MIG-enabled nodi`Ready`, verificate che la modalità MIG sia attiva sulle GPU e che il nodo pubblicizzi le risorse MIG previste.

1. Verifica che il nodo pubblicizzi le risorse MIG. Con la strategia unica, il nodo riporta le istanze come. `nvidia.com/gpu` Con la strategia mista, il nodo riporta le risorse specifiche del profilo, ad esempio. `nvidia.com/mig-1g.10gb`

   ```
   kubectl describe node <node-name> | grep nvidia.com
   ```

1. Esegui `nvidia-smi` da un Pod su un MIG-enabled nodo per confermare che la modalità MIG è attiva.

    `nvidia-smi`segnala `MIG M.: Enabled` le GPU con la modalità MIG attivata ed elenca le istanze MIG configurate su ciascuna. Di seguito è riportato un esempio di output da una GPU A100 da 40 GB con MIG abilitato e partizionata in, e istanze. `3g.20gb` `2g.10gb` `1g.5gb`

   ```
   +-----------------------------------------------------------------------------------------+
   | NVIDIA-SMI 580.159.03             Driver Version: 580.159.03     CUDA Version: 13.0     |
   +-----------------------------------------+------------------------+----------------------+
   | GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
   | Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
   |                                         |                        |               MIG M. |
   |=========================================+========================+======================|
   |   0  NVIDIA A100-SXM4-40GB          On  |   00000000:10:1C.0 Off |                   On |
   | N/A   35C    P0             65W /  400W |     213MiB /  40960MiB |     N/A      Default |
   |                                         |                        |              Enabled |
   +-----------------------------------------+------------------------+----------------------+
   
   +-----------------------------------------------------------------------------------------+
   | MIG devices:                                                                            |
   +------------------+----------------------------------+-----------+-----------------------+
   | GPU  GI  CI  MIG |              Shared Memory-Usage |        Vol|        Shared         |
   |      ID  ID  Dev |                Shared BAR1-Usage | SM     Unc| CE ENC  DEC  OFA  JPG |
   |                  |                                  |        ECC|                       |
   |==================+==================================+===========+=======================|
   |  0    1   0   0  |             107MiB / 20096MiB    | 42      0 |  3   0    2    0    0 |
   |                  |               0MiB / 12211MiB    |           |                       |
   +------------------+----------------------------------+-----------+-----------------------+
   |  0    5   0   1  |              71MiB /  9984MiB    | 28      0 |  2   0    1    0    0 |
   |                  |               0MiB /  6105MiB    |           |                       |
   +------------------+----------------------------------+-----------+-----------------------+
   |  0   13   0   2  |              36MiB /  4864MiB    | 14      0 |  1   0    0    0    0 |
   |                  |               0MiB /  3052MiB    |           |                       |
   +------------------+----------------------------------+-----------+-----------------------+
   ```

   Con la strategia mista, un Pod vede solo l'istanza MIG richiesta, non il layout completo della GPU del nodo. Il `mig-inference` Pod del passaggio precedente ha richiesto un'`nvidia.com/mig-1g.5gb`istanza, quindi `nvidia-smi -L` all'interno di quel Pod è elencato un singolo dispositivo MIG.

   ```
   kubectl logs mig-inference
   ```

   Di seguito viene riportato un output di esempio.

   ```
   GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-5b7ce860-1951-004c-4881-6ac6997df770)
     MIG 1g.5gb      Device  0: (UUID: MIG-9b065868-21b6-5b8d-8ab9-e99089ed472c)
   ```

   Per vedere il layout completo delle partizioni di ogni GPU su un nodo, `nvidia-smi -L` esegui sull'host anziché all'interno di un Pod di carico di lavoro. Il comando seguente avvia un pod di debug privilegiato sul nodo ed esegue quello dell'host. `nvidia-smi` Sostituiscilo {{node-name}} con il nome del tuo MIG-enabled nodo.

   ```
   kubectl debug node/<node-name> -it --profile=sysadmin --image=nvidia/cuda:12.6.0-base-ubuntu22.04 -- chroot /host nvidia-smi -L
   ```

   Di seguito è riportato un esempio di output per la `p4d-half-balanced` configurazione. Le prime quattro GPU sono partizionate in istanze MIG e le restanti quattro sono GPU intere. Ogni `MIG` riga è un'istanza isolata dall'hardware con UUID, memoria e slice di calcolo propri.

   ```
   GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-5b7ce860-1951-004c-4881-6ac6997df770)
     MIG 3g.20gb     Device  0: (UUID: MIG-7dc16162-7ba2-5894-abde-d753dc8ecf56)
     MIG 2g.10gb     Device  1: (UUID: MIG-56cfe1f0-0662-50e4-a5f7-111107e4d5e6)
     MIG 1g.5gb      Device  2: (UUID: MIG-1409727e-2ffa-5fd4-9586-204c9e2b36d5)
     MIG 1g.5gb      Device  3: (UUID: MIG-9b065868-21b6-5b8d-8ab9-e99089ed472c)
   GPU 1: NVIDIA A100-SXM4-40GB (UUID: GPU-73692a43-dd2d-f1a1-b0df-2f4734e2a87d)
     MIG 3g.20gb     Device  0: (UUID: MIG-745fd93a-9582-57a6-8b3b-9782d289ca1b)
     MIG 2g.10gb     Device  1: (UUID: MIG-8440294e-c4a0-5687-add5-2cc506babb2f)
     MIG 1g.5gb      Device  2: (UUID: MIG-559810c0-f2bb-5ca2-b529-47228d99437f)
     MIG 1g.5gb      Device  3: (UUID: MIG-a91cf3f9-6459-59e9-97a8-dc69b9958eef)
   GPU 2: NVIDIA A100-SXM4-40GB (UUID: GPU-4e56019e-84de-eef5-5ac3-85e468e93639)
     MIG 3g.20gb     Device  0: (UUID: MIG-c130392b-fd7c-59f8-9f4b-ecab27a2984b)
     MIG 2g.10gb     Device  1: (UUID: MIG-7d61cf16-ad08-57be-b2c2-ac6e515b28c3)
     MIG 1g.5gb      Device  2: (UUID: MIG-f5388dec-d841-506c-bb7a-6ac136ceee53)
     MIG 1g.5gb      Device  3: (UUID: MIG-02d54020-c6cb-5997-894b-e95af0f49388)
   GPU 3: NVIDIA A100-SXM4-40GB (UUID: GPU-4fd894a0-b471-9e77-eb67-0ad15002ed5b)
     MIG 3g.20gb     Device  0: (UUID: MIG-10399b59-2625-5106-b3f8-76ae19da46e1)
     MIG 2g.10gb     Device  1: (UUID: MIG-ef81ee7d-fc48-56ed-8479-8ffa76eb4154)
     MIG 1g.5gb      Device  2: (UUID: MIG-ed9bf59d-6bf2-5e07-80fb-dd0d7ca41f9d)
     MIG 1g.5gb      Device  3: (UUID: MIG-a15d6f7d-661b-514e-8838-06fe4ffe7f75)
   GPU 4: NVIDIA A100-SXM4-40GB (UUID: GPU-05b6b91b-da6e-3078-1f4f-a7bbf1ff7ed2)
   GPU 5: NVIDIA A100-SXM4-40GB (UUID: GPU-078a8df1-f387-0315-6b0b-af12e082f6d5)
   GPU 6: NVIDIA A100-SXM4-40GB (UUID: GPU-6cdeffe7-45f1-7e8e-bcc1-4634399ad877)
   GPU 7: NVIDIA A100-SXM4-40GB (UUID: GPU-5f68814a-4e4a-5dec-79b4-8d70a61c7714)
   ```