**Aidez à améliorer cette page** 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub ** lien ** Modifier cette page qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Utiliser des GPU multi-instances (MIG) avec des GPU NVIDIA sur Amazon EKS
<a name="device-management-nvidia-mig"></a>

 [Multi-Instance Le GPU ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/index.html) (MIG) est une fonctionnalité matérielle des GPU NVIDIA qui partitionne un seul GPU physique en plusieurs instances isolées. Le nombre maximum d'instances partitionnées dépend du GPU. Chaque instance possède une mémoire dédiée, des unités de calcul et une bande passante mémoire, de sorte qu'une charge de travail exécutée sur une instance ne peut pas affecter la charge de travail d'une autre. Contrairement au [ découpage temporel](device-management-nvidia-time-slicing.md), qui partage un GPU par le biais d'un multiplexage temporel logiciel sans isolation, le MIG fournit une mémoire au niveau matériel et une isolation des pannes entre les Pods.

Le MIG convient parfaitement à l'inférence multi-tenant et aux charges de travail nécessitant une qualité de service prévisible. Il est disponible sur les GPU NVIDIA Ampere (A100), Hopper (H100 et H200) et Blackwell. AWS Activé, il s'agit des types d' P-family `g7e`instance Blackwell-based `g7` et des types d'instances. Pour obtenir la liste complète, consultez [MIG-capable types d'instances](#eks-mig-capable-instance-types).

Le MIG convient parfaitement lorsque :
+ Vous devez isoler la mémoire afin qu'une charge de travail ne puisse pas consommer la mémoire GPU requise par une autre charge de travail.
+ Vous exécutez une inférence multilocataire dans le cadre de laquelle les locataires partagent du matériel GPU mais exigent une qualité de service par locataire.
+ Vous exécutez déjà des formations sur des instances A100, H100, H200 ou Blackwell et vous souhaitez réutiliser ces GPU pour réduire les charges de travail d'inférence lorsque la formation est inactive.

Envisagez une approche différente lorsque :
+ Vos nœuds utilisent un type d'instance GPU qui ne prend pas en charge le MIG, tel que les `g6e` familles `g5``g6`, ou. Utilisez plutôt [ le découpage en tranches temporelles](device-management-nvidia-time-slicing.md).
+ Vous n'avez pas besoin d'isolation de la mémoire et souhaitez la configuration la plus simple. Utilisez plutôt [ le découpage en tranches temporelles](device-management-nvidia-time-slicing.md).
+ Vous devez changer fréquemment les partitions du GPU sans interruption. La modification du mode MIG ou de la disposition des partitions nécessite une réinitialisation du GPU, que l'opérateur GPU effectue en redémarrant le nœud.
+ Vous exécutez un entraînement multi-GPU qui dépend de la communication collective ou pair à pair entre les GPU. Le MIG ne prend pas en charge le NCCL ou le P2P inter-GPU.

## Considérations
<a name="eks-mig-considerations"></a>

Prenez en compte les points suivants avant d'utiliser MIG en production.

### Considérations d’ordre général
<a name="_general_considerations"></a>
+  **La modification de la configuration MIG nécessite une réinitialisation du GPU. ** L'activation ou la désactivation du mode MIG, ou la modification de la disposition des partitions, nécessitent une réinitialisation du GPU. Il ne peut donc pas être modifié sur place. Par exemple, le MIG Manager de l'opérateur GPU NVIDIA applique une modification de configuration en arrêtant les modules GPU du nœud et en redémarrant le nœud lorsqu'un redémarrage est nécessaire pour changer de mode MIG.
+  **Le calcul n'est pas strictement proportionnel à la taille de l'instance. ** Une `1g` instance ne fournit pas une part proportionnelle du débit de l'ensemble du GPU pour chaque charge de travail, car la bande passante mémoire et le comportement du cache diffèrent selon les profils. Comparez votre charge de travail au profil que vous comptez utiliser avant de dimensionner les partitions.
+  **Time-slicing n'a aucun effet sur les instances MIG. ** Une instance MIG est déjà isolée matériellement et ne peut plus être partagée par tranches temporelles. La demande de stratégie de `TimeSlicing` partage sur un périphérique MIG ne modifie pas le comportement du matériel. Pour partager une seule instance MIG sur plusieurs conteneurs, utilisez plutôt NVIDIA Multi-Process Service (MPS).
+  **Communication inter-GPU limitée. ** Lorsque MIG est activé, les instances MIG sur différents GPU ne peuvent pas utiliser la communication GPU-to-GPU peer-to-peer (P2P) et NCCL ne fonctionne pas avec MIG. Multi-GPU les charges de travail qui dépendent de la communication collective ou du P2P entre les GPU, comme l'entraînement multiGPU en parallèle aux tenseurs, nécessitent plutôt des GPU complets. Pour plus de détails, consultez les considérations relatives [ à ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html#application-considerations) l'application dans le guide de l'utilisateur NVIDIA MIG sur le site Web de NVIDIA.

### Considérations relatives aux plug-ins pour appareils NVIDIA
<a name="_nvidia_device_plugin_considerations"></a>
+  **Les demandes de ressources du pod doivent correspondre à la stratégie. ** Avec la stratégie unique, Pods demande`nvidia.com/gpu`. Avec la stratégie mixte, les pods demandent la ressource spécifique au profil, telle que. `nvidia.com/mig-1g.10gb` Un pod qui demande un profil que le nœud n'annonce pas reste dans `Pending` cet état. Confirmez les ressources annoncées avec`kubectl describe node <node-name>`.
+  **Plug-in d'appareil autonome sur AL2023. ** Si vous installez le plug-in de périphérique NVIDIA séparément, par exemple dans le cadre de la configuration du cluster, excluez-le de vos nœuds MIG afin qu'il n'entre pas en conflit avec le plug-in de périphérique géré par l'opérateur GPU. Ajoutez une règle d'affinité de nœud au plug-in de l'appareil autonome qui exclut les nœuds `nvidia.com/mig.config` portant l'étiquette.
+  **Aucune assistance en mode automatique EKS. ** Le mode EKS Auto gère le plug-in du périphérique NVIDIA et n'expose pas sa configuration (voir[Déploiement d’une charge de travail accélérée](auto-accelerated.md)). Vous ne pouvez pas activer MIG sur les nœuds EKS Auto Mode. Configurez MIG sur des nœuds Karpenter autogérés ou sur un groupe de nœuds géré, dans lequel vous contrôlez les paramètres de l'AMI et du plug-in de l'appareil.

### Considérations relatives au pilote NVIDIA DRA
<a name="_nvidia_dra_driver_considerations"></a>
+  **Le MIG statique nécessite des instances pré-créées. ** Avec le MIG statique, le pilote DRA alloue les instances MIG existantes mais n'active pas le mode MIG et ne partitionne pas les GPU. Vous devez d'abord activer le mode MIG et créer les instances, par exemple avec le MIG Manager dans le NVIDIA GPU Operator ou. `nvidia-smi` Pour de plus amples informations, veuillez consulter [Utiliser MIG avec le pilote NVIDIA DRA](#eks-mig-dra-driver).
+  **Dynamic MIG est une fonctionnalité alpha. ** Avec le MIG dynamique, le pilote crée et détruit des partitions MIG à la demande en réponse aux demandes de charge de travail. Elle nécessite le `DynamicMIG` Feature Gate, qui est désactivé par défaut. Pour de plus amples informations, veuillez consulter [Utiliser MIG avec le pilote NVIDIA DRA](#eks-mig-dra-driver).
+  **Désactivez le plug-in intégré à l'appareil sur Bottlerocket. ** Le pilote DRA ne peut pas fonctionner en même temps que le plug-in de périphérique NVIDIA sur le même nœud. Sur Bottlerocket, désactivez le plug-in intégré à l'appareil, qui nécessite la version 1.63.0 ou ultérieure de Bottlerocket. Pour de plus amples informations, veuillez consulter [Installez le pilote NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver).
+  **Support informatique. ** Le pilote NVIDIA DRA est pris en charge avec le provisionnement de capacité statique dans Karpenter, les groupes de nœuds gérés par EKS ou les nœuds autogérés, et n'est pas pris en charge avec le mode automatique EKS. Pour plus d'informations, consultez la NodePool documentation statique de [ Karpenter ](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool) sur le site Web de Karpenter.

## MIG-capable types d'instances
<a name="eks-mig-capable-instance-types"></a>

Activé AWS, les types d'instance suivants fournissent des MIG-capable GPU.


| Type d’instance | Processeurs graphiques | Mémoire GPU | 
| --- | --- | --- | 
|  `p4d.24xlarge`  | 8 cartes NVIDIA A100 40 Go | 320 GO | 
|  `p4de.24xlarge`  | 8 cartes NVIDIA A100 de 80 Go | 640 GO | 
|  `p5.48xlarge`  | 8 cartes NVIDIA H100 de 80 Go | 640 GO | 
|  `p5e.48xlarge`  | 8 cartes NVIDIA H200 | 128 GO | 
|  `p5en.48xlarge`  | 8 cartes NVIDIA H200 | 128 GO | 
|  `p6-b200.48xlarge`  | 8 processeurs NVIDIA Blackwell B200 | 1432 GO | 
|  `p6-b300.48xlarge`  | 8 processeurs NVIDIA Blackwell Ultra B300 | 214 GO | 
|  `g7.48xlarge`  | 8 cartes NVIDIA RTX PRO 4500 Édition serveur Blackwell | 256 Go | 
|  `g7e.48xlarge`  | 8 cartes NVIDIA RTX PRO 6000 Édition serveur Blackwell | 768 GO | 

Le MIG n'est pas disponible sur les `g6e` familles `g5``g6`,, ou. Pour `p6e-gb200` UltraServers, qui utilisent le GPU MIG-capable NVIDIA GB200, voir[À utiliser P6e-GB200 UltraServers avec Amazon EKS](ml-eks-nvidia-ultraserver.md).

**Note**  
Le type d'`g7`instance nécessite la version 595 ou ultérieure du pilote NVIDIA. Les AMI EKS-optimized accélérées incluent actuellement la version 580 du pilote NVIDIA. Pour utiliser MIG, `g7` vous devez créer une AMI personnalisée avec la version 595 du pilote. Pour de plus amples informations, veuillez consulter [Création d'une AMI EKS-optimized Amazon Linux personnalisée](eks-ami-build-scripts.md).

Les instances MIG sont décrites par des profils qui utilisent le modèle de dénomination`<slices>g.<memory>gb`, où `<slices>` est le nombre de tranches de calcul et `<memory>` la mémoire de l'instance en gigaoctets. Par exemple, le `3g.40gb` profil fournit trois des sept tranches de calcul et 40 Go de mémoire. Les profils pris en charge par chaque GPU sont fixés par le matériel. Pour la liste complète, consultez le guide de l'utilisateur du Multi-Instance GPU [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/) sur le site Web de NVIDIA.

## Profils MIG par type d'instance
<a name="eks-mig-profiles-per-instance-type"></a>

Les profils MIG disponibles sur un nœud dépendent du GPU utilisé pour le type d'instance. Les sections suivantes répertorient les profils pour chaque type d'instance MIG-capable Amazon EC2. Pour chaque profil, le nombre ** maximum d'instances ** est le nombre maximum d'instances de ce profil que vous pouvez créer sur un seul GPU, et la ** mémoire par instance ** est la mémoire GPU allouée à chacun d'eux.

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.5gb`  | 1 sur 7 | 5 Go | 7 | 
|  `1g.10gb`  | 1 sur 7 | 10 Go | 4 | 
|  `2g.10gb`  | 2 sur 7 | 10 Go | 3 | 
|  `3g.20gb`  | 3 sur 7 | 20 Go | 2 | 
|  `4g.20gb`  | 4 sur 7 | 20 Go | 1 | 
|  `7g.40gb`  | 7 sur 7 | 40 GO | 1 | 

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 sur 7 | 10 Go | 7 | 
|  `1g.20gb`  | 1 sur 7 | 20 Go | 4 | 
|  `2g.20gb`  | 2 sur 7 | 20 Go | 3 | 
|  `3g.40gb`  | 3 sur 7 | 40 GO | 2 | 
|  `4g.40gb`  | 4 sur 7 | 40 GO | 1 | 
|  `7g.80gb`  | 7 sur 7 | 80 GO | 1 | 

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.10gb`  | 1 sur 7 | 10 Go | 7 | 
|  `1g.20gb`  | 1 sur 7 | 20 Go | 4 | 
|  `2g.20gb`  | 2 sur 7 | 20 Go | 3 | 
|  `3g.40gb`  | 3 sur 7 | 40 GO | 2 | 
|  `4g.40gb`  | 4 sur 7 | 40 GO | 1 | 
|  `7g.80gb`  | 7 sur 7 | 80 GO | 1 | 

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.18gb`  | 1 sur 7 | 18 GO | 7 | 
|  `1g.35gb`  | 1 sur 7 | 35 Go | 4 | 
|  `2g.35gb`  | 2 sur 7 | 35 Go | 3 | 
|  `3g.71gb`  | 3 sur 7 | 71 GO | 2 | 
|  `4g.71gb`  | 4 sur 7 | 71 GO | 1 | 
|  `7g.141gb`  | 7 sur 7 | 141 GO | 1 | 

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.23gb`  | 1 sur 7 | 23 GO | 7 | 
|  `1g.45gb`  | 1 sur 7 | 45 GO | 4 | 
|  `2g.45gb`  | 2 sur 7 | 45 GO | 3 | 
|  `3g.90gb`  | 3 sur 7 | 90 GO | 2 | 
|  `4g.90gb`  | 4 sur 7 | 90 GO | 1 | 
|  `7g.180gb`  | 7 sur 7 | 180 GO | 1 | 

**``p6-b300,48xlarge — NVIDIA Blackwell Ultra B300**  
Il `p6-b300.48xlarge` utilise le HGX B300, qui permet de partitionner chaque GPU en 7 instances de 32 Go, 4 de 67 Go, 2 de 135 Go ou 1 de 270 Go. Ces tailles sont préliminaires et peuvent changer. Pour plus de détails sur les profils, consultez les profils MIG pris en charge par [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) sur le site Web de NVIDIA.

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.16gb`  | 1 sur 2 | 16 Go | 2 | 
|  `2g.32gb`  | 2 sur 2 | 32 GO | 1 | 

Le RTX PRO 4500 Blackwell prend également en charge les variantes de profil avec fonction graphique (`+gfx`) et avec moteur multimédia (,). `+me.all` `-me` Pour la liste complète, consultez les profils MIG pris en charge par [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) sur le site Web de NVIDIA.

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


| Profil | Calculez les tranches | Mémoire par instance | Nombre maximum d'instances | 
| --- | --- | --- | --- | 
|  `1g.24gb`  | 1 sur 4 | 24 GO | 4 | 
|  `2g.48gb`  | 2 sur 4 | 48 GO | 2 | 
|  `4g.96gb`  | 4 sur 4 | 96 GO | 1 | 

Le RTX PRO 6000 Blackwell Server Edition prend également en charge les variantes de profil graphiques (`+gfx`) et de moteur multimédia (,). `+me.all` `-me` Pour la liste complète, consultez les profils MIG pris en charge par [ NVIDIA ](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/supported-mig-profiles.html) sur le site Web de NVIDIA.

## Stratégies MIG
<a name="eks-mig-strategies"></a>

Le pilote NVIDIA DRA et le plug-in de périphérique NVIDIA exposent les instances MIG à Kubernetes de différentes manières. Le plug-in de périphérique utilise un ** paramètre de stratégie ** MIG à l'échelle du nœud, tandis que le pilote DRA n'a aucun paramètre équivalent car il sélectionne les instances en fonction de leurs attributs. Comprendre cette différence est essentiel pour choisir entre les deux modèles.

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

Le pilote NVIDIA DRA n'utilise pas le concept de stratégie unique ou mixte, et il n'existe aucun paramètre équivalent à configurer. Au lieu de publier les instances MIG en tant que ressources comptées, le pilote publie chaque instance en tant que périphérique dans le `mig.nvidia.com` `DeviceClass` avec des attributs tels que le sien`profile`. Les pods sélectionnent une instance en faisant correspondre ces attributs aux sélecteurs CEL (Common Expression Language) placés dans un `ResourceClaim` ou`ResourceClaimTemplate`, comme indiqué dans[Utiliser MIG avec le pilote NVIDIA DRA](#eks-mig-dra-driver).

Comme la sélection s'effectue par instance, les nœuds à profil mixte fonctionnent sans changement de mode de stratégie. Un seul GPU peut être partitionné en plusieurs profils différents, et chaque demande sélectionne le profil dont elle a besoin. Le choix qui compte pour le pilote DRA n'est pas une stratégie unique ou mixte, mais un MIG statique par rapport à une stratégie MIG dynamique, qui permet de déterminer si vous pré-créez les instances MIG ou si le pilote les crée à la demande. Pour de plus amples informations, veuillez consulter [Utiliser MIG avec le pilote NVIDIA DRA](#eks-mig-dra-driver).

### Plug-in pour appareil NVIDIA
<a name="_nvidia_device_plugin"></a>

Le plug-in de périphérique NVIDIA annonce les instances MIG à Kubernetes en utilisant l'une des deux stratégies suivantes. Étant donné que le plug-in de périphérique expose les instances MIG en tant que ressources étendues au niveau des nœuds, qui ne comportent qu'un nombre entier et aucun attribut par instance, la stratégie détermine la façon dont ces ressources sont nommées.
+  **Stratégie unique ** : chaque processeur graphique d'un nœud utilise le même profil MIG. Le plug-in de l'appareil annonce chaque instance en tant que `nvidia.com/gpu` ressource, et les Pods demandent `nvidia.com/gpu: 1` comme ils le feraient pour un GPU dédié. Les manifestes existants ne changent pas. Bottlerocket et AL2023 soutiennent tous deux la stratégie unique.
+  **Stratégie mixte ** : les GPU d'un même nœud peuvent utiliser différents profils MIG. Le plug-in de l'appareil présente chaque profil comme une ressource distincte, telle que `nvidia.com/mig-1g.10gb` ou`nvidia.com/mig-3g.40gb`, et les Pods demandent le profil spécifique dont ils ont besoin. Vous ne pouvez pas utiliser une stratégie mixte avec le plug-in d'appareil NVIDIA intégré à Bottlerocket. Pour plus d'informations, consultez le GitHub numéro \#4483 de [ Bottlerocket sur. ](https://github.com/bottlerocket-os/bottlerocket/issues/4483) GitHub

## Utiliser MIG avec le pilote NVIDIA DRA
<a name="eks-mig-dra-driver"></a>

Lors de l'allocation d'instances MIG à l'aide du pilote NVIDIA DRA, les Pods demandent une instance MIG via un `ResourceClaim` ou `ResourceClaimTemplate` plutôt que la ressource étendue du plug-in de `nvidia.com/mig-<profile>` l'appareil.

Étant donné que le pilote DRA décrit les instances en fonction de leurs attributs plutôt que comme des ressources comptées, il n'utilise pas la stratégie unique ou mixte requise par le plug-in du périphérique (voir[Stratégies MIG](#eks-mig-strategies)). Le pilote expose chaque instance MIG en tant que périphérique `mig.nvidia.com` `DeviceClass` avec un `gpu.nvidia.com/type` attribut de`mig`, et annonce des attributs par instance tels que le `profile` (par exemple`1g.5gb`) et le `parentUUID` du GPU physique. Vous associez ces attributs à des sélecteurs CEL (Common Expression Language) pour demander un profil spécifique ou pour conserver plusieurs instances sur le même GPU.

Le pilote DRA alloue les instances MIG selon l'un des deux modes suivants :
+  **MIG statique ** : vous activez le mode MIG et créez les instances MIG sur le nœud avant le démarrage du pilote, par exemple avec le MIG Manager dans l'opérateur GPU NVIDIA, comme décrit dans. [Utiliser MIG sur les nœuds AL2023 avec le plug-in de périphérique NVIDIA](#eks-mig-device-plugin-al2023) Le pilote découvre les instances existantes et les alloue aux Pods mais ne modifie pas la configuration MIG du nœud. Les instances ajoutées après le démarrage du pilote ne sont découvertes qu'après le redémarrage du plug-in Kubelet du GPU. Le MIG statique est la valeur par défaut et ne nécessite aucune porte de fonctionnalité.
+  **MIG dynamique ** : le pilote crée et détruit des partitions MIG à la demande en réponse à des demandes de charge de travail. Vous ne partitionnez donc pas les GPU à l'avance. Dynamic MIG est une fonctionnalité alpha désactivée par défaut. Vous demandez un profil avec les mêmes `ResourceClaimTemplate` sélecteurs que ceux présentés dans les sections suivantes, et le pilote partitionne un GPU pour répondre à la demande.

### Considérations
<a name="_considerations"></a>
+ Le MIG dynamique remplace la découverte statique sur un nœud. Le pilote gère toutes les partitions et détruit toutes les partitions MIG qu'il n'a pas créées au démarrage du plug-in GPU Kubelet. N'activez pas le MIG dynamique sur les nœuds contenant des partitions pré-créées que vous souhaitez conserver, et ne l'exécutez pas `mig-parted` ou `nvidia-smi mig` pendant que le plug-in est en cours d'exécution, car les modifications manuelles peuvent entrer en conflit avec l'état de la partition du pilote et entraîner l'échec de la préparation ou du nettoyage du pod.
+ Dynamic MIG est en état alpha et nécessite l'activation d'un Feature Gate lors de l'installation du pilote NVIDIA DRA. Consultez [Installez le pilote NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver) les instructions.
+ Les architectures Hopper (H100 et H200) et versions ultérieures activent le mode MIG à la demande. Les générations précédentes ne peuvent pas activer le mode MIG à la demande, y compris les GPU Ampere (A100).
+ Le MIG dynamique dépend de la fonctionnalité des périphériques partitionnables Kubernetes (activée GitHub), qui est activée par défaut dans [ KEP-4815 ](https://github.com/kubernetes/enhancements/issues/4815) les versions 1.36 et ultérieures de Kubernetes. Dans les versions précédentes, cette fonctionnalité n'est pas activée par défaut, de sorte que le planificateur ne peut pas allouer de périphériques MIG créés dynamiquement.

### Conditions préalables
<a name="_prerequisites"></a>
+ Cluster Amazon EKS exécutant Kubernetes version 1.34 ou ultérieure avec une capacité statique provisionnée par Karpenter, des groupes de nœuds gérés par EKS ou des groupes de nœuds autogérés.
+ MIG-capable P-family nœuds sur lesquels le mode MIG est activé et GPU partitionnés en instances MIG. Pour les fichiers MIG statiques, consultez le [ MIG Manager dans l'opérateur GPU NVIDIA ](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html) sur le site Web de NVIDIA.
+ Le pilote NVIDIA DRA est installé comme décrit dans[Installez le pilote NVIDIA DRA](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver), éventuellement avec Dynamic MIG activé si vous n'utilisez pas le partitionnement MIG statique.

### Procédure
<a name="_procedure"></a>

Les exemples suivants peuvent être utilisés avec un MIG statique ou dynamique et le pilote NVIDIA DRA.

1. Créez un `ResourceClaimTemplate` qui demande une instance MIG à partir de `mig.nvidia.com``DeviceClass`, et un pod qui y fait référence. Cet exemple demande n'importe quelle instance MIG disponible sans restreindre le profil.

   ```
   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. Vérifiez qu'une seule instance MIG a été allouée au Pod.

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

   L'exemple qui suit illustre un résultat. Le Pod voit une instance MIG provenant du GPU partitionné.

   ```
   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)
   ```

### Demander un profil MIG spécifique
<a name="_request_a_specific_mig_profile"></a>

Pour demander un profil spécifique au lieu de n'importe quelle instance disponible, ajoutez un sélecteur CEL correspondant à l'`profile`attribut. Ce qui suit `ResourceClaimTemplate` demande une `1g.5gb` instance et le Pod y fait référence.

```
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
```

### Demander plusieurs instances MIG à partir du même GPU
<a name="_request_multiple_mig_instances_from_the_same_gpu"></a>

Pour vous assurer que plusieurs instances MIG d'une seule réclamation proviennent du même GPU physique, ajoutez un `constraints` bloc avec`matchAttribute: "gpu.nvidia.com/parentUUID"`. Ce qui suit `ResourceClaimTemplate` demande une `1g.5gb` instance et une `2g.10gb` instance à partir du même GPU, et le Pod fait référence à la réclamation. Comme le conteneur fait référence à la revendication sans nommer de demande spécifique, il reçoit les deux instances 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
```

## Utilisez MIG sur les nœuds Bottlerocket avec le plug-in de périphérique NVIDIA
<a name="eks-mig-device-plugin-bottlerocket"></a>

Sur Bottlerocket, l'AMI EKS-optimized accélérée inclut le plug-in de périphérique NVIDIA. Vous activez MIG avec la stratégie unique via les `settings.kubelet-device-plugins.nvidia` paramètres. Bottlerocket prend en charge le MIG dans la version 1.34.0 et les versions ultérieures.

### Conditions préalables
<a name="_prerequisites_2"></a>
+ Un cluster Amazon EKS. La procédure suivante approvisionne les MIG-capable P-family nœuds avec l'AMI NVIDIA EKS-optimized Bottlerocket, version 1.34.0 ou ultérieure.
+ Karpenter a été installé et configuré dans votre cluster, car la procédure suivante utilise un Karpenter `EC2NodeClass` pour fournir les paramètres MIG dans les données utilisateur du nœud Bottlerocket. Pour plus d'informations, consultez la section [ Getting Started with Karpenter ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/) sur le site Web de Karpenter.
+  `kubectl`configuré pour communiquer avec votre cluster, consultez [Installer ou mettre à jour `kubectl`](install-kubectl.md#kubectl-install-update) pour plus d'informations.

### Procédure
<a name="_procedure_2"></a>

Ajoutez le paramètre de partitionnement MIG aux données utilisateur de Bottlerocket pour vos nœuds GPU. La manière dont vous fournissez les données utilisateur dépend de la manière dont vous approvisionnez les nœuds. L'exemple suivant montre un Karpenter `EC2NodeClass` pour les `p4d.24xlarge` nœuds.

```
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
```

Lorsque les nœuds configurés avec ces paramètres rejoignent le cluster, le mode MIG est activé sur les GPU, chaque GPU est partitionné en `2g.10gb` instances et le plug-in de l'appareil annonce les instances résultantes comme ressource. `nvidia.com/gpu` Étant donné que a `p4d.24xlarge` possède huit GPU A100 et que chacun prend en charge trois `2g.10gb` instances, le nœud fait de la publicité. `nvidia.com/gpu: 24`

**Note**  
Le `mig.profile` réglage est défini par le modèle de processeur graphique, tel que `a100.40gb` ou`h100.80gb`. Sans `mig.profile` réglage, le GPU active le mode MIG et utilise son profil le plus large. Comme Bottlerocket utilise une stratégie unique, chaque GPU du nœud utilise le même profil. Pour utiliser différents profils sur le même nœud (stratégie mixte), utilisez le chemin AL2023 avec l'opérateur GPU NVIDIA.

## Utiliser MIG sur les nœuds AL2023 avec le plug-in de périphérique NVIDIA
<a name="eks-mig-device-plugin-al2023"></a>

Sur AL2023, les étapes suivantes utilisent l'opérateur GPU NVIDIA pour installer le plug-in de périphérique NVIDIA et le MIG Manager. Le MIG Manager active le mode MIG et partitionne les GPU en fonction d'une configuration que vous fournissez. Le plug-in de périphérique NVIDIA annonce ensuite les instances résultantes à Kubernetes. L'opérateur GPU prend en charge les stratégies simples et mixtes.

Étant donné que l'AMI NVIDIA EKS-optimized AL2023 inclut déjà le pilote et la boîte à outils NVIDIA, désactivez la gestion des pilotes dans l'opérateur GPU pour éviter tout conflit avec le pilote préinstallé. Vous pouvez également installer et gérer vous-même le plug-in de périphérique NVIDIA et MIG Manager sans utiliser l'opérateur GPU.

### Conditions préalables
<a name="_prerequisites_3"></a>
+ Un cluster Amazon EKS. La procédure suivante fournit aux MIG-capable P-family nœuds (tels que`p4d.24xlarge`) l'AMI NVIDIA EKS-optimized AL2023.
+ Karpenter a été installé et configuré dans votre cluster, car la procédure permet de créer un Karpenter `EC2NodeClass` et de `NodePool` provisionner les nœuds GPU. Pour plus d'informations, consultez la section [ Getting Started with Karpenter ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/) sur le site Web de Karpenter.
+ Helm installé dans votre environnement de ligne de commande, consultez les instructions de configuration de Helm pour plus d’informations.[Déployez des applications avec Helm sur Amazon EKS](helm.md)
+  `kubectl`configuré pour communiquer avec votre cluster, consultez [Installer ou mettre à jour `kubectl`](install-kubectl.md#kubectl-install-update) pour plus d'informations.

### Procédure
<a name="_procedure_3"></a>

1. Créez un `EC2NodeClass` et `NodePool` pour les nœuds P-family GPU AL2023. Sur AL2023, le partitionnement MIG est appliqué par l'opérateur GPU lors des étapes ultérieures. Il s'agit donc d'une classe de nœuds GPU AL2023 standard. L'exemple suivant provisionne `p4d.24xlarge` les nœuds avec l'AMI NVIDIA EKS-optimized AL2023.

   ```
   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. Ajoutez le référentiel NVIDIA Helm.

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

1. Créez un `gpu-operator-values.yaml` fichier qui désactive la gestion des pilotes, sélectionne la stratégie mixte et définit les profils MIG à appliquer. L'exemple suivant définit une `p4d-half-balanced` configuration qui partitionne quatre des huit GPU d'un `p4d.24xlarge` nœud et laisse le reste entier.

   ```
   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. Installez l'opérateur GPU avec le fichier de valeurs.

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

1. Étiquetez vos MIG-capable nœuds avec la configuration de profil à appliquer. Le composant MIG Manager surveille cette étiquette et partitionne les GPU en conséquence, en redémarrant le nœud pour appliquer la modification.

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

1. Une fois que l'opérateur GPU a partitionné les GPU, les Pods demandent un profil MIG spécifique par son nom de ressource plutôt que. `nvidia.com/gpu` L'exemple suivant exécute un Pod qui demande une `1g.5gb` instance.

   ```
   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
   ```

Pour obtenir des exemples complets de configuration à stratégies mixtes pour les P-family instances, y compris des groupes de nœuds gérés avec des réservations de capacité et des charges de travail par profil, consultez la section MIG du guide des meilleures pratiques [ Amazon EKS. ](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html)

## Vérifiez que MIG est actif
<a name="eks-mig-verify"></a>

Une fois vos MIG-enabled nœuds terminés`Ready`, vérifiez que le mode MIG est actif sur les GPU et que le nœud annonce les ressources MIG attendues.

1. Vérifiez que le nœud annonce les ressources MIG. Avec la stratégie unique, le nœud signale les instances sous la forme`nvidia.com/gpu`. Avec la stratégie mixte, le nœud signale les ressources spécifiques au profil, telles que. `nvidia.com/mig-1g.10gb`

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

1. Exécutez `nvidia-smi` depuis un pod sur un MIG-enabled nœud pour confirmer que le mode MIG est actif.

    `nvidia-smi`génère des rapports `MIG M.: Enabled` pour les GPU sur lesquels le mode MIG est activé et répertorie les instances MIG configurées sur chacun d'eux. Voici un exemple de sortie d'un GPU A100 de 40 Go avec MIG activé et partitionné en instances `3g.20gb``2g.10gb`, et. `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    |           |                       |
   +------------------+----------------------------------+-----------+-----------------------+
   ```

   Avec la stratégie mixte, un pod ne voit que l'instance MIG qu'il a demandée, et non la configuration graphique complète du nœud. Le `mig-inference` Pod de l'étape précédente a demandé une `nvidia.com/mig-1g.5gb` instance, donc `nvidia-smi -L` à l'intérieur de ce Pod figure un seul périphérique MIG.

   ```
   kubectl logs mig-inference
   ```

   L'exemple qui suit illustre un résultat.

   ```
   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)
   ```

   Pour voir la disposition complète des partitions de chaque GPU sur un nœud, exécutez `nvidia-smi -L` sur l'hôte plutôt que dans un pod de charge de travail. La commande suivante démarre un pod de débogage privilégié sur le nœud et exécute celui de `nvidia-smi` l'hôte. {{node-name}}Remplacez-le par le nom de votre MIG-enabled nœud.

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

   Voici un exemple de sortie pour la `p4d-half-balanced` configuration. Les quatre premiers GPU sont partitionnés en instances MIG et les quatre autres sont des GPU complets. Chaque `MIG` ligne est une instance isolée matériellement avec son propre UUID, sa propre mémoire et ses propres tranches de calcul.

   ```
   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)
   ```