Ayude a mejorar esta página
Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.
Uso de GPU de varias instancias (MIG) con GPU de NVIDIA en Amazon EKS
GPU de varias instancias
MIG es ideal para la inferencia de varios inquilinos y para las cargas de trabajo que requieren una calidad del servicio predecible. Está disponible en las GPU de NVIDIA Ampere (A100), Hopper (H100 y H200) y Blackwell. En AWS, estos son los tipos de instancias de la familia P y los tipos de instancias g7 y g7e basados en Blackwell. Puede consultar la lista completa e Tipos de instancias compatibles con MIG.
MIG es una buena opción en los siguientes casos:
-
Necesita aislar la memoria para que una carga de trabajo no pueda consumir la memoria de la GPU que requiere otra carga de trabajo.
-
Ejecuta una inferencia de varios inquilinos en la que los inquilinos comparten el hardware de la GPU, pero necesitan una calidad del servicio por inquilino.
-
Ya ha ejecutado el entrenamiento en instancias A100, H100, H200 o Blackwell y quiere reutilizar esas GPU para cargas de trabajo de inferencia más pequeñas cuando el entrenamiento está inactivo.
Considere la posibilidad de adoptar otro enfoque cuando:
-
Los nodos utilizan un tipo de instancia de GPU que no admite MIG, como las familias
g5,g6og6e. En su lugar, utilice la segmentación temporal. -
No necesita aislar la memoria y desea la configuración más sencilla. En su lugar, utilice la segmentación temporal.
-
Necesita cambiar las particiones de la GPU con frecuencia y sin interrupciones. Cambiar el modo de MIG o el diseño de la partición requiere un restablecimiento de la GPU, que el operador de la GPU efectúa mediante el reinicio del nodo.
-
Ejecuta un entrenamiento con varias GPU que depende de la comunicación colectiva o de punto a punto entre las GPU. MIG no admite NCCL ni P2P entre GPU.
Consideraciones
Revise las siguientes consideraciones antes de usar MIG en producción.
Consideraciones generales
-
Cambiar la configuración de MIG requiere un restablecimiento de la GPU. Habilitar o deshabilitar el modo de MIG o cambiar el diseño de la partición requiere un restablecimiento de la GPU, por lo que no se puede cambiar in situ. Por ejemplo, el administrador de MIG del operador de GPU de NVIDIA aplica un cambio de configuración al detener los pods de la GPU en el nodo y reiniciarlo cuando es necesario reiniciar el nodo para cambiar el modo de MIG.
-
La computación no es estrictamente proporcional al tamaño de la instancia. Una instancia
1gno ofrece una parte proporcional del rendimiento de toda la GPU para cada carga de trabajo, ya que el ancho de banda de la memoria y el comportamiento de la caché difieren según los perfiles. Compare la carga de trabajo con el perfil que tiene previsto usar antes de cambiar el tamaño de las particiones. -
La segmentación temporal no tiene ningún efecto en instancias de MIG. Una instancia de MIG ya está aislada por hardware y no se puede continuar compartiendo mediante la segmentación temporal. Solicitar la estrategia de uso compartido
TimeSlicingen un dispositivo de MIG no cambia el comportamiento del hardware. Para compartir una única instancia de MIG entre contenedores, utilice el servicio multiproceso (MPS) de NVIDIA en su lugar. -
Comunicación limitada entre GPU. Cuando se ha habilitado MIG, las instancias de MIG de distintas GPU no pueden utilizar la comunicación de punto a punto (P2P) de GPU a GPU y NCCL no funciona con MIG. Las cargas de trabajo con varias GPU que dependen de la comunicación colectiva o P2P entre GPU, como el entrenamiento de paralelismo de tensores entre varias GPU, requieren GPU completas. Para obtener más información, consulte las consideraciones sobre la aplicación
en la Guía del usuario de MIG de NVIDIA en el sitio web de NVIDIA.
Consideraciones sobre el complemento para dispositivos de NVIDIA
-
Las solicitudes de recursos del pod deben coincidir con la estrategia. Con la estrategia única, los pods solicitan
nvidia.com/gpu. Con la estrategia mixta, los pods solicitan el recurso específico del perfil, comonvidia.com/mig-1g.10gb. Un pod que solicita un perfil que el nodo no anuncia permanece en el estadoPending. Confirme los recursos anunciados conkubectl describe node <node-name>. -
Complemento para dispositivos independiente en AL2023. Si instala el complemento para dispositivos de NVIDIA por separado, por ejemplo, como parte de la configuración del clúster, exclúyalo de los nodos de MIG para que no entre en conflicto con el complemento para dispositivos que administra el operador de GPU. Agregue una regla de afinidad de nodos al complemento para dispositivos independiente que excluya los nodos que tienen la etiqueta
nvidia.com/mig.config. -
No es compatible con el modo automático de EKS. El modo automático de EKS administra el complemento para dispositivos de NVIDIA y no expone su configuración (consulte Implementación de una carga de trabajo acelerada). No se puede habilitar MIG en nodos del modo automático de EKS. Configure MIG en nodos de Karpenter autoadministrado o en un grupo de nodos administrado, donde controle la AMI y la configuración del complemento para dispositivos.
Consideraciones sobre el controlador de DRA de NVIDIA
-
MIG estática requiere instancias creadas previamente. Con MIG estática, el controlador de DRA asigna las instancias de MIG existentes, pero no habilita el modo de MIG ni particiona las GPU. Antes debe habilitar el modo de MIG y crear las instancias, por ejemplo, con el administrador de MIG en el operador de GPU de NVIDIA o
nvidia-smi. Para obtener más información, consulte Uso de MIG con el controlador de DRA de NVIDIA. -
MIG dinámica son una característica alfa. Con MIG dinámica, el controlador crea y elimina particiones de MIG bajo demanda en respuesta a las solicitudes de carga de trabajo. Requiere la puerta de características
DynamicMIG, que está deshabilitada de forma predeterminada. Para obtener más información, consulte Uso de MIG con el controlador de DRA de NVIDIA. -
Deshabilite el complemento para dispositivos integrado en Bottlerocket, El controlador de DRA no se puede ejecutar junto con el complemento para dispositivos de NVIDIA en el mismo nodo. En Bottlerocket, deshabilite el complemento para dispositivos integrado, que requiere la versión 1.63.0 o posterior de Bottlerocket. Para obtener más información, consulte Instalación del controlador de DRA de NVIDIA.
-
Soporte de computación. El controlador de DRA de NVIDIA es compatible con el aprovisionamiento de capacidad estática en Karpenter, los grupos de nodos administrados de EKS o los nodos autoadministrados, pero no es compatible con el modo automático de EKS. Para obtener más información, consulte la documentación de NodePool estática de Karpenter
en el sitio web de Karpenter.
Tipos de instancias compatibles con MIG
En AWS, los siguientes tipos de instancias proporcionan GPU compatibles con MIG.
| Tipo de instancia | GPU | Memoria de GPU |
|---|---|---|
|
|
8 x NVIDIA A100 de 40 GB |
320 GB |
|
|
8 x NVIDIA A100 de 80 GB |
640 GB |
|
|
8 x NVIDIA H100 de 80 GB |
640 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA H200 |
1128 GB |
|
|
8 x NVIDIA Blackwell B200 |
1432 GB |
|
|
8 x NVIDIA Blackwell Ultra B300 |
2144 GB |
|
|
8 x NVIDIA RTX PRO 4500 Blackwell Server Edition |
256 GB |
|
|
8 x NVIDIA RTX PRO 6000 Blackwell Server Edition |
768 GB |
MIG no está disponible en las familias g5, g6 o g6e. Para los UltraServers p6e-gb200, que utilizan la GPU de NVIDIA GB200 compatible con MIG, consulte Uso de UltraServers P6e-GB200 con Amazon EKS.
nota
El tipo de instancia g7 requiere la versión 595 o posterior del controlador de NVIDIA. Las AMI aceleradas optimizadas para EKS incluyen actualmente la versión 580 del controlador de NVIDIA, por lo que, para utilizar MIG en g7, debe crear una AMI personalizada con la versión 595 del controlador. Para obtener más información, consulte Creación de una AMI de Amazon Linux optimizada para EKS personalizada.
Las instancias de MIG se describen mediante perfiles que utilizan el patrón de nomenclatura <slices>g.<memory>gb, donde <slices> es el número de segmentos de computación y <memory> es la memoria de la instancia en gigabytes. Por ejemplo, el perfil 3g.40gb proporciona tres de los siete segmentos de computación y 40 GB de memoria. El hardware fija los perfiles que admite cada GPU. Para ver la lista completa, consulte NVIDIA Multi-Instance GPU User Guide
Perfiles de MIG por tipo de instancia
Los perfiles de MIG disponibles en un nodo dependen de la GPU del tipo de instancia. En las secciones siguientes se muestran los perfiles de cada tipo de instancia de Amazon EC2 compatible con MIG. En cada perfil, Número máximo de instancias es el número máximo de instancias de ese perfil que puede crear en una sola GPU, mientras que Memoria por instancia es la memoria de GPU asignada a cada una.
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 7 |
5 GB |
7 |
|
|
1 de 7 |
10 GB |
4 |
|
|
2 de 7 |
10 GB |
3 |
|
|
3 de 7 |
20 GB |
2 |
|
|
4 de 7 |
20 GB |
1 |
|
|
7 de 7 |
40 GB |
1 |
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 7 |
10 GB |
7 |
|
|
1 de 7 |
20 GB |
4 |
|
|
2 de 7 |
20 GB |
3 |
|
|
3 de 7 |
40 GB |
2 |
|
|
4 de 7 |
40 GB |
1 |
|
|
7 de 7 |
80 GB |
1 |
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 7 |
10 GB |
7 |
|
|
1 de 7 |
20 GB |
4 |
|
|
2 de 7 |
20 GB |
3 |
|
|
3 de 7 |
40 GB |
2 |
|
|
4 de 7 |
40 GB |
1 |
|
|
7 de 7 |
80 GB |
1 |
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 7 |
18 GB |
7 |
|
|
1 de 7 |
35 GB |
4 |
|
|
2 de 7 |
35 GB |
3 |
|
|
3 de 7 |
71 GB |
2 |
|
|
4 de 7 |
71 GB |
1 |
|
|
7 de 7 |
141 GB |
1 |
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 7 |
23 GB |
7 |
|
|
1 de 7 |
45 GB |
4 |
|
|
2 de 7 |
45 GB |
3 |
|
|
3 de 7 |
90 GB |
2 |
|
|
4 de 7 |
90 GB |
1 |
|
|
7 de 7 |
180 GB |
1 |
p6-b300.48xlarge: NVIDIA Blackwell Ultra B300
p6-b300.48xlarge utiliza la HGX B300, que permite particionar cada GPU en 7 instancias de 32 GB, 4 de 67 GB, 2 de 135 GB o 1 de 270 GB. Estos tamaños son preliminares y pueden cambiar. Para ver los detalles del perfil, consulte NVIDIA Supported MIG Profiles
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 2 |
16 GB |
2 |
|
|
2 de 2 |
32 GB |
1 |
La RTX PRO 4500 Blackwell también admite variantes de perfil con gráficos (+gfx) y con motor multimedia (+me.all, -me). Para ver la lista completa, consulte NVIDIA Supported MIG Profiles
| Perfil | Segmentos de computación | Memoria por instancia | Instancias máximas |
|---|---|---|---|
|
|
1 de 4 |
24 GB |
4 |
|
|
2 de 4 |
48 GB |
2 |
|
|
4 de 4 |
96 GB |
1 |
La RTX PRO 6000 Blackwell Server Edition también admite variantes de perfil con gráficos (+gfx) y con motor multimedia (+me.all, -me). Para ver la lista completa, consulte NVIDIA Supported MIG Profiles
Estrategias de MIG
El controlador de DRA de NVIDIA y el complemento para dispositivos de NVIDIA exponen las instancias de MIG a Kubernetes de diferentes formas. El complemento para dispositivos utiliza una configuración de estrategia de MIG para todo el nodo, mientras que el controlador de DRA no tiene ninguna configuración equivalente porque selecciona las instancias según sus atributos. Entender esta diferencia es clave para elegir entre los dos modelos.
Controlador de DRA de NVIDIA
El controlador de DRA de NVIDIA no utiliza el concepto de estrategia única o mixta, y no hay ninguna configuración equivalente que ajustar. En lugar de anunciar las instancias de MIG como recursos contados, el controlador publica cada instancia como dispositivo en la DeviceClass mig.nvidia.com con atributos como su profile. Los pods seleccionan una instancia al hacer coincidir estos atributos con los selectores del lenguaje de expresión común (CEL) de una ResourceClaim o ResourceClaimTemplate, como se muestra en Uso de MIG con el controlador de DRA de NVIDIA.
Como la selección se hace por instancia, los nodos de perfil mixto funcionan sin necesidad de cambiar de modo de estrategia. Una sola GPU se puede particionar en varios perfiles diferentes, y cada instrucción selecciona el perfil que necesita. La elección que más importa para el controlador de DRA no es una estrategia única o mixta, sino MIG estática o dinámica, que determina si se crean previamente las instancias de MIG o si el controlador las crea bajo demanda. Para obtener más información, consulte Uso de MIG con el controlador de DRA de NVIDIA.
Complemento para dispositivos de NVIDIA
El complemento para dispositivos de NVIDIA anuncia las instancias de MIG en Kubernetes mediante una de estas dos estrategias. Como el complemento para dispositivos expone las instancias de MIG como recursos extendidos por nodo, que solo incluyen un recuento de números enteros y no atributos por instancia, la estrategia determina el nombre de esos recursos.
-
Estrategia única: todas las GPU de un nodo utilizan el mismo perfil de MIG. El complemento para dispositivos anuncia cada instancia como el recurso
nvidia.com/gpuy los pods solicitannvidia.com/gpu: 1como lo harían con una GPU dedicada. Los manifiestos existentes no cambian. Tanto Bottlerocket como AL2023 admiten la estrategia única. -
Estrategia mixta: las GPU del mismo nodo pueden usar diferentes perfiles de MIG. El complemento para dispositivos anuncia cada perfil como un recurso distinto, como
nvidia.com/mig-1g.10gbonvidia.com/mig-3g.40gb, y los pods solicitan el perfil específico que necesitan. No puede usar una estrategia mixta con el complemento para dispositivos de NVIDIA integrado en Bottlerocket. Para obtener más información, consulte el problema de GitHub de Bottlerocket n.º 4483en GitHub.
Uso de MIG con el controlador de DRA de NVIDIA
Al asignar instancias de MIG con el controlador de DRA de NVIDIA, los pods solicitan una instancia de MIG a través de una ResourceClaim o ResourceClaimTemplate en lugar del recurso extendido nvidia.com/mig-<profile> del complemento para dispositivos.
Como el controlador de DRA describe las instancias por sus atributos y no como recursos contados, no utiliza la estrategia única ni la mixta que requiere el complemento para dispositivos (consulte Estrategias de MIG). El controlador expone cada instancia de MIG como un dispositivo en la DeviceClass mig.nvidia.com con un atributo gpu.nvidia.com/type de mig, y anuncia atributos por instancia, como profile (por ejemplo, 1g.5gb) y los parentUUID de la GPU física. Estos atributos se combinan con los selectores del lenguaje de expresión común (CEL) para solicitar un perfil específico o para mantener varias instancias en la misma GPU.
El controlador de DRA asigna las instancias de MIG en uno de estos dos modos:
-
MIG estática: habilita el modo de MIG y crea las instancias de MIG en el nodo antes de que se inicie el controlador, por ejemplo, con el administrador de MIG en el operador de GPU de NVIDIA, como se describe en Uso de MIG en nodos de ALM2023 con el complemento para dispositivos de NVIDIA. El controlador detecta las instancias existentes y las asigna a los pods, pero no modifica la configuración de MIG del nodo. Las instancias agregadas después de que se inicie el controlador no se detectan hasta que se reinicie el complemento de kubelet de la GPU. MIG estática es la opción predeterminada y no requiere ninguna puerta de características.
-
MIG dinámica: el controlador crea y elimina particiones de MIG bajo demanda en respuesta a las solicitudes de carga de trabajo, de modo que no particiona GPU por adelantado. MIG dinámica es una característica alfa que está deshabilitada. Solicita un perfil con los mismos selectores
ResourceClaimTemplateque se muestran en las siguientes secciones, mientras que el controlador particiona una GPU para satisfacer la solicitud.
Consideraciones
-
MIG dinámica reemplaza la detección estática en un nodo. El controlador administra todas las particiones y elimina las particiones de MIG que no haya creado cuando se inicie el complemento de kubelet de la GPU. No habilite MIG dinámica en los nodos con particiones previamente creadas que desee conservar ni ejecute
mig-partedonvidia-smi migmientras el complemento esté en ejecución, ya que los cambios manuales pueden entrar en conflicto con el estado de la partición del controlador y hacer que no se pueda preparar o limpiar el pod. -
MIG dinámica se encuentra en estado alfa y requiere que se habilite una puerta de características al instalar el controlador de DRA de NVIDIA; consulte Instalación del controlador de DRA de NVIDIA para obtener instrucciones.
-
Las arquitecturas Hopper (H100 y H200) y posteriores habilitan el modo de MIG bajo demanda. Las generaciones anteriores no pueden habilitar el modo de MIG bajo demanda, incluidas las GPU Ampere (A100).
-
MIG dinámica depende de la característica de dispositivos particionables de Kubernetes (KEP-4815
en GitHub), que está habilitada de forma predeterminada en la versión 1.36 y posteriores de Kubernetes. En las versiones anteriores, esta característica no está habilitada de forma predeterminada, por lo que el programador no puede asignar los dispositivos de MIG creados dinámicamente.
Requisitos previos
-
Un clúster de Amazon EKS que ejecuta la versión 1.34 o posterior de Kubernetes con capacidad estática aprovisionada por Karpenter, grupos de nodos administrados de EKS o grupos de nodos autoadministrados.
-
Nodos de la familia P compatibles con MIG con el modo de MIG habilitado y GPU particionadas en instancias de MIG. Para obtener más información sobre MIG estática, consulte MIG Manager in the NVIDIA GPU Operator
en el sitio web de NVIDIA. -
El controlador de DRA de NVIDIA se instala tal y como se describe en Instalación del controlador de DRA de NVIDIA, con MIG dinámica habilitada de forma opcional si no se utilizan particiones de MIG estática.
Procedimiento
Los siguientes ejemplos se pueden utilizar con MIG estática o dinámica y con el controlador de DRA de NVIDIA.
-
Cree una
ResourceClaimTemplateque solicite una instancia de MIG de laDeviceClassmig.nvidia.com, y un pod que haga referencia a ella. En este ejemplo, se solicita cualquier instancia de MIG disponible sin restringir el perfil.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 -
Verifique que se haya asignado una sola instancia de MIG al pod.
kubectl logs mig-dra-podUn ejemplo de salida sería el siguiente. El pod ve una instancia de MIG de la GPU particionada.
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)
Solicitud de un perfil de MIG específico
Para solicitar un perfil específico en lugar de cualquier instancia disponible, agregue un selector del CEL que coincida con el atributo profile. La siguiente ResourceClaimTemplate solicita una instancia 1g.5gb a la que el pod hace referencia.
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
Solicitud de varias instancias de MIG desde la misma GPU
Para garantizar que varias instancias de MIG de una sola instrucción procedan de la misma GPU física, agregue un bloque constraints con matchAttribute: "gpu.nvidia.com/parentUUID". La siguiente ResourceClaimTemplate solicita una instancia 1g.5gb y una instancia 2g.10gb de la misma GPU y el pod hace referencia a la instrucción. Como el contenedor hace referencia a la instrucción sin mencionar ninguna solicitud específica, recibe ambas instancias de 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
Uso de MIG en nodos de Bottlerocket con el complemento para dispositivos de NVIDIA
En Bottlerocket, la AMI acelerada optimizada para EKS incluye el complemento para dispositivos de NVIDIA. Puede habilitar las MIG con una estrategia única a través de la configuración settings.kubelet-device-plugins.nvidia. Bottlerocket admite las MIG en la versión 1.34.0 y posteriores.
Requisitos previos
-
Un clúster de Amazon EKS. El siguiente procedimiento aprovisiona los nodos de la familia P compatibles con MIG con la versión 1.34.0 o posterior de la AMI de NVIDIA de Bottlerocket optimizada para EKS.
-
Karpenter está instalado y configurado en su clúster, ya que en el siguiente procedimiento se utiliza una
EC2NodeClassde Karpenter para proporcionar la configuración de MIG en los datos de usuario del nodo de Bottlerocket. Para obtener más información, consulte Introducción a Karpenteren el sitio web de Karpenter. -
kubectlconfigurado para comunicarse con su clúster. Consulte Instalación o actualización de kubectl para obtener más información.
Procedimiento
Agregue la configuración de partición de MIG a los datos de usuario de Bottlerocket para los nodos de GPU. La forma en que suministre los datos de usuario depende de cómo aprovisione los nodos. En el siguiente ejemplo, se muestra una EC2NodeClass de Karpenter para los nodos p4d.24xlarge.
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
Cuando los nodos aprovisionados con esta configuración se unen al clúster, se habilita el modo de MIG en las GPU, cada GPU se particiona en instancias 2g.10gb y el complemento para dispositivos anuncia las instancias resultantes como recurso nvidia.com/gpu. Como p4d.24xlarge tiene ocho GPU A100 y cada una admite tres instancias 2g.10gb, el nodo anuncia nvidia.com/gpu: 24.
nota
La configuración mig.profile depende del modelo de GPU, como a100.40gb o h100.80gb. Sin una configuración mig.profile, la GPU habilita el modo de MIG y usa su perfil más grande. Como Bottlerocket utiliza una estrategia única, todas las GPU del nodo utilizan el mismo perfil. Para utilizar diferentes perfiles en el mismo nodo (la estrategia mixta), utilice la ruta de AL2023 con el operador de GPU de NVIDIA.
Uso de MIG en nodos de ALM2023 con el complemento para dispositivos de NVIDIA
En AL2023, en los siguientes pasos, se utiliza el operador de GPU de NVIDIA para instalar el complemento para dispositivos de NVIDIA y el administrador de MIG. El administrador de MIG habilita el modo de MIG y divide las GPU según la configuración que proporcione. A continuación, el complemento para dispositivos de NVIDIA anuncia las instancias resultantes en Kubernetes. El operador de GPU admite tanto la estrategia única como la mixta.
Como la AMI de NVIDIA de AL2023 optimizada para EKS ya incluye el controlador y el kit de herramientas de NVIDIA, deshabilite la administración de controladores en el operador de GPU para evitar conflictos con el controlador preinstalado. Como alternativa, puede instalar y administrar el complemento para dispositivos de NVIDIA y el administrador de MIG sin utilizar el operador de GPU.
Requisitos previos
-
Un clúster de Amazon EKS. El siguiente procedimiento aprovisiona los nodos de la familia P con capacidad de MIG (por ejemplo,
p4d.24xlarge) con la AMI de NVIDIA de AL2023 optimizada para EKS. -
Karpenter está instalado y configurado en su clúster, ya que el procedimiento crea una
EC2NodeClassy unNodePoolde Karpenter para aprovisionar los nodos de GPU. Para obtener más información, consulte Introducción a Karpenteren el sitio web de Karpenter. -
Si tiene Helm instalado en su entorno de línea de comandos, consulte las instrucciones de configuración de Helm para obtener más información.
-
kubectlconfigurado para comunicarse con su clúster. Consulte Instalación o actualización de kubectl para obtener más información.
Procedimiento
-
Cree una
EC2NodeClassy unNodePoolpara los nodos de GPU de la familia P de AL2023. En AL2023, el operador de GPU aplica la partición de MIG en pasos posteriores, por lo que se trata de una clase de nodo de GPU de AL2023 estándar. En el siguiente ejemplo, se aprovisionan nodosp4d.24xlargecon la AMI de NVIDIA de AL2023 optimizada para EKS.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 -
Agregue el repositorio de Helm de NVIDIA.
helm repo add nvidia https://nvidia.github.io/gpu-operator helm repo update -
Cree un archivo
gpu-operator-values.yamlque deshabilite la administración de controladores, seleccione la estrategia mixta y defina los perfiles de MIG que se aplicarán. En el siguiente ejemplo, se define una configuraciónp4d-half-balancedque divide cuatro de las ocho GPU de un nodop4d.24xlargey deja el resto entero.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 -
Instale el operador de GPU con el archivo de valores.
helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --values gpu-operator-values.yaml -
Etiquete los nodos compatibles con MIG con la configuración de perfil que se aplicará. El componente Administrador de MIG busca esta etiqueta y particiona las GPU en consecuencia, lo que reinicia el nodo para aplicar el cambio.
kubectl label nodes -l node.kubernetes.io/instance-type=p4d.24xlarge \ nvidia.com/mig.config=p4d-half-balanced --overwrite -
Una vez que el operador de GPU divide las GPU, los pods solicitan un perfil de MIG específico por su nombre de recurso en lugar de
nvidia.com/gpu. En el siguiente ejemplo, se ejecuta un pod que solicita una instancia1g.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
Para ver ejemplos completos de configuración de la estrategia mixta para instancias de la familia P, incluidos los grupos de nodos administrados con reservas de capacidad y cargas de trabajo por perfil, consulte la sección MIG de la Guía de prácticas recomendadas de Amazon EKS.
Verificación de que MIG se haya activado
Una vez que los nodos habilitados para MIG estén Ready, confirme que el modo de MIG esté activo en las GPU y que el nodo anuncie los recursos de MIG esperados.
-
Confirme que el nodo anuncie los recursos de MIG. Con la estrategia única, el nodo informa de las instancias como
nvidia.com/gpu. Con la estrategia mixta, el nodo informa de los recursos específicos del perfil, comonvidia.com/mig-1g.10gb.kubectl describe node <node-name> | grep nvidia.com -
Ejecute
nvidia-smidesde un pod en un nodo habilitado para MIG para confirmar que el modo de MIG esté activo.nvidia-smiinforma deMIG M.: Enabledpara las GPU que tienen activado el modo de MIG y muestra las instancias de MIG configuradas en cada una de ellas. A continuación, se muestra un ejemplo de salida de una GPU A100 de 40 GB con MIG habilitadas y particionadas en instancias3g.20gb,2g.10gby1g.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 estrategia mixta, un pod solo ve la instancia de MIG que solicitó, no el diseño completo de la GPU del nodo. El pod
mig-inferencedel paso anterior solicitó una instancianvidia.com/mig-1g.5gb, por lo quenvidia-smi -Ldentro de ese pod enumera un único dispositivo de MIG.kubectl logs mig-inferenceUn ejemplo de salida sería el siguiente.
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)Para ver el diseño completo de las particiones de cada GPU de un nodo, ejecute
nvidia-smi -Len el host en lugar de dentro de un pod de carga de trabajo. El siguiente comando inicia un pod de depuración privilegiado en el nodo y ejecuta lanvidia-smidel host. Sustituyanode-namepor el nombre del nodo habilitado para MIG.kubectl debug node/<node-name> -it --profile=sysadmin --image=nvidia/cuda:12.6.0-base-ubuntu22.04 -- chroot /host nvidia-smi -LA continuación, se muestra la salida de ejemplo de la configuración
p4d-half-balanced. Las cuatro primeras GPU se particionan en instancias de MIG, mientras que las cuatro restantes son GPU completas. Cada línea deMIGes una instancia aislada por hardware con sus propios UUID, memoria y segmentos de computación.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)
