**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 UltraServers P6e-GB200 con Amazon EKS En este tema, se describe cómo configurar y usar Amazon EKS con UltraServers P6e-GB200. El tipo de instancia `p6e-gb200.36xlarge` con 4 GPU Blackwell de NVIDIA solo está disponible como UltraServers P6e-GB200. Existen dos tipos de UltraServers P6e-GB200. El UltraServer `u-p6e-gb200x36` tiene 9 instancias `p6e-gb200.36xlarge`, mientras que el UltraServer `u-p6e-gb200x72` tiene 18 instancias `p6e-gb200.36xlarge`. Para obtener más información, consulte la [página web de UltraServers P6e-GB200 de Amazon EC2](https://aws.amazon.com/ec2/instance-types/p6/). ## Consideraciones + Amazon EKS es compatible con UltraServers P6e-GB200 en las versión 1.33 y posteriores de Kubernetes. El lanzamiento de esta versión de Kubernetes admite la [asignación dinámica de recursos](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (DRA), activada de forma predeterminada en EKS y en las [AMI aceleradas optimizadas para EKS de AL2023](https://docs.aws.amazon.com/eks/latest/userguide/ml-eks-optimized-ami.html). La DRA es un requisito para utilizar UltraServers P6e-GB200 con EKS. La DRA no se admite en el modo automático de EKS o Karpenter, y se recomienda utilizar grupos de nodos autoadministrados de EKS o grupos de nodos administrados de EKS al utilizar UltraServers P6e-GB200 con EKS. + Los UltraServers P6e-GB200 están disponibles a través de los [Bloques de capacidad de EC2 para ML](https://aws.amazon.com/ec2/capacityblocks/) Consulte [Administración de los recursos computacionales para las cargas de trabajo de IA/ML en Amazon EKS](ml-compute-management.md) para obtener información sobre cómo lanzar nodos de EKS con Bloques de capacidad. + Al utilizar grupos de nodos administrados de EKS con Bloques de capacidad, debe usar plantillas de lanzamiento personalizadas. Al actualizar grupos de nodos administrados de EKS con UltraServers P6e-GB200, debe establecer el tamaño deseado del grupo de nodos en `0` antes de la actualización. + Se recomienda utilizar la variante ARM de NVIDIA de AL2023 de las AMI aceleradas optimizadas para EKS. Esta AMI incluye la configuración y los componentes del nodo necesarios para funcionar con UltraServers P6e-GB200. Si decide crear su propia AMI, es responsable de instalar y validar la compatibilidad del software del nodo y del sistema, incluidos los controladores. Para obtener más información, consulte [Uso de AMI aceleradas optimizadas para EKS para instancias de GPU](ml-eks-optimized-ami.md). + Se recomienda utilizar una versión `v20251103` o posterior de la AMI optimizada para EKS, que incluya la versión 580 del controlador NVIDIA. Esta versión del controlador NVIDIA permite que la Administración de memoria coherente basada en controladores (CDMM) aborde una posible sobrecarga de memoria. Cuando la CDMM está activada, no se admiten las siguientes capacidades: GPU multiinstancia (MIG) y vGPU de NVIDIA. Para obtener más información sobre la CDMM, consulte [NVIDIA Coherent Driver-based Memory Management (CDMM)](https://nvdam.widen.net/s/gpqp6wmz7s/cuda-whitepaper—​cdmm-pdf). + Cuando utilice el [operador de GPU de NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) con la AMI de NVIDIA de AL2023 optimizada para EKS, debe desactivar la instalación del controlador y el kit de herramientas por parte del operador, ya que se incluyen en la AMI. Las AMI de NVIDIA de AL2023 optimizadas para EKS no incluyen el complemento para dispositivos de Kubernetes de NVIDIA ni el controlador NVIDIA de DRA, que deben instalarse por separado. + Cada instancia `p6e-gb200.36xlarge` se puede configurar con hasta 17 tarjetas de red y puede usar EFA para la comunicación entre UltraServers. El tráfico de la red de carga de trabajo puede atravesar UltraServers, pero, para obtener el máximo rendimiento, se recomienda programar las cargas de trabajo en el mismo UltraServer y utilizar IMEX para la comunicación de la GPU dentro del UltraServer. Para obtener más información, consulte [Configuración de EFA para instancias P6e-GB200](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e). + Cada instancia `p6e-gb200.36xlarge` cuenta con 3 [almacenes de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) de 7,5 TB cada uno. De forma predeterminada, la AMI optimizada para EKS no formatea ni monta los almacenes de instancias. El almacenamiento efímero del nodo se puede compartir entre los pods que solicitan almacenamiento efímero y las imágenes de contenedores que se descargan en el nodo. Si utiliza la AMI optimizada para EKS de AL2023, se puede configurar como parte del arranque de nodos en los datos del usuario mediante la configuración de la política de almacenamiento local de instancias en [NodeConfig](https://docs.aws.amazon.com/eks/latest/eksctl/node-bootstrapping.html#configuring-the-bootstrapping-process) como RAID0. Si se establece en RAID0, se transfieren los almacenes de instancias y se configura el tiempo de ejecución del contenedor y el kubelet para utilizar este almacenamiento efímero. ## Componentes Se recomiendan los siguientes componentes para ejecutar cargas de trabajo en EKS con los UltraServers P6e-GB200. Si lo desea, puede utilizar el [operador de GPU de NVIDIA](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) para instalar los componentes del nodo de NVIDIA. Cuando utilice el operador de GPU de NVIDIA con la AMI de NVIDIA de AL2023 optimizada para EKS, debe desactivar la instalación del controlador y el kit de herramientas por parte del operador, ya que se incluyen en la AMI. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/ml-eks-nvidia-ultraserver.html) Los componentes de los nodos de la tabla anterior llevan a cabo las siguientes funciones: + **CNI de VPC**: asigna las IP de VPC como la interfaz de red principal para los pods que se ejecutan en EKS. + **Complemento para dispositivos de EFA**: asigna los dispositivos EFA como redes secundarias para los pods que se ejecutan en EKS. Es responsable del tráfico de red en los UltraServers P6e-GB200. En el caso de las cargas de trabajo de varios nodos, las de GPU a GPU dentro de un UltraServer pueden fluir a través de NVLink de varios nodos. + **Complemento para dispositivos de Kubernetes de NVIDIA**: asigna las GPU como dispositivos para los pods que se ejecutan en EKS. Se recomienda utilizar el complemento para dispositivos de Kubernetes de NVIDIA hasta que la funcionalidad de asignación de GPU del controlador de DRA de NVIDIA deje de ser experimental. Consulte las [versiones de los controladores de DRA de NVIDIA](https://github.com/NVIDIA/k8s-dra-driver-gpu/releases) para obtener información actualizada. + **Controlador de DRA de NVIDIA**: activa los recursos personalizados de ComputeDomain que facilitan la creación de dominios de IMEX que siguen las cargas de trabajo que se ejecutan en los UltraServers P6e-GB200. + El recurso ComputeDomain describe un dominio de intercambio de memoria entre nodos (IMEX). Cuando se implementan en el clúster cargas de trabajo con un ResourceClaim para un ComputeDomain, el controlador de DRA de NVIDIA crea automáticamente un DaemonSet de IMEX que se ejecuta en los nodos coincidentes y establece los canales de IMEX entre los nodos antes de que se inicie la carga de trabajo. Para obtener más información sobre IMEX, consulte la [descripción general de IMEX de NVIDIA para sistemas NVLink de varios nodos](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/overview.html). + El controlador de DRA de NVIDIA utiliza una etiqueta de ID de grupo (`nvidia.com/gpu.clique`) aplicada por la GFD de NVIDIA y que transmite los conocimientos sobre la topología de la red y el dominio de NVLink. + Es una práctica recomendada crear un ComputeDomain por cada trabajo de carga de trabajo. + **Detección de características de nodos (NFD) de NVIDIA**: dependencia necesaria para que la GFD aplique etiquetas a los nodos en función de los atributos de nodo detectados. + **Detección de características de GPU (GFD) de NVIDIA**: aplica una etiqueta de topología estándar de NVIDIA llamada `nvidia.com/gpu.clique` a los nodos. Los nodos dentro de un mismo `nvidia.com/gpu.clique` tienen accesibilidad de NVLink de varios nodos, y puede utilizar las afinidades de los pods en la aplicación para programar los pods en el mismo dominio de NVLink. ## Procedimiento En la siguiente sección, se supone que cuenta con un clúster de EKS que ejecuta la versión 1.33 o posterior de Kubernetes con uno o más grupos de nodos con UltraServers P6e-GB200 que ejecutan la AMI acelerada optimizada para EKS ARM de NVIDIA de AL2023. Consulte los enlaces de [Administración de los recursos computacionales para las cargas de trabajo de IA/ML en Amazon EKS](ml-compute-management.md) para obtener los pasos con los requisitos previos para los grupos de nodos administrados y los nodos autoadministrados de EKS. En el siguiente procedimiento, se utilizan los siguientes componentes. | Nombre | Versión | Descripción | | --- | --- | --- | | Operador de GPU de NVIDIA | 25.3.4\$1 | Para la administración del ciclo de vida de los complementos necesarios, como el complemento para dispositivos de Kubernetes de NVIDIA y la NFD o GFD. | | Controladores de DRA de NVIDIA | 25.8.0\$1 | Para la administración de dominios de IMEX y CRD de ComputeDomain. | | Complemento para dispositivos de EFA | 0.5.14\$1 | Para la comunicación entre UltraServers. | ## Instalación del operador de GPU de NVIDIA El operador de GPU de NVIDIA simplifica la administración de los componentes necesarios para usar las GPU en los clústeres de Kubernetes. Como el kit de herramientas de contenedores y el controlador de GPU de NVIDIA se instalan como parte de la AMI acelerada optimizada para EKS, deben configurarse como `false` en la configuración de valores de Helm. 1. Cree un archivo de valores de Helm denominado `gpu-operator-values.yaml` con la configuración siguiente. ``` devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true driver: enabled: false toolkit: enabled: false migManager: enabled: false ``` 1. Instale el operador de GPU de NVIDIA para el clúster con el archivo `gpu-operator-values.yaml` creado en el paso anterior. ``` helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update ``` ``` helm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --version v25.3.4 \ --values gpu-operator-values.yaml ``` ## Instalación del controlador de DRA de NVIDIA A partir de la versión `v25.3.4` del operador de GPU de NVIDIA, el controlador de DRA de NVIDIA debe instalarse por separado. Se recomienda seguir las [notas de la versión](https://github.com/NVIDIA/gpu-operator/releases) del operador de GPU de NVIDIA, ya que esto podría cambiar en una versión futura. 1. Cree un archivo de valores de Helm denominado `dra-values.yaml` con la configuración siguiente. Tenga en cuenta `nodeAffinity` y `tolerations` que configuran el controlador de DRA para implementar solo en nodos con una GPU de NVIDIA. ``` resources: gpus: enabled: false # set to false to disable experimental gpu support computeDomains: enabled: true controller: nodeSelector: null affinity: null tolerations: [] kubeletPlugin: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "nvidia.com/gpu.present" operator: In values: - "true" tolerations: - key: "nvidia.com/gpu" operator: Exists effect: NoSchedule ``` 1. Instale el controlador de DRA de NVIDIA para el clúster con el archivo `dra-values.yaml` creado en el paso anterior. ``` helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo update ``` ``` helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \ --version="25.8.0" \ --namespace nvidia-dra-driver-gpu \ --create-namespace \ -f dra-values.yaml ``` 1. Tras la instalación, el controlador de DRA crea recursos `DeviceClass` que permiten a Kubernetes comprender y asignar los recursos `ComputeDomain`, lo que permite que las cargas de trabajo de GPU distribuidas en UltraServers P6e-GB200 administren el IMEX. Confirme que los recursos de DRA estén disponibles con los siguientes comandos. ``` kubectl api-resources | grep resource.k8s.io ``` ``` deviceclasses resource.k8s.io/v1 false DeviceClass resourceclaims resource.k8s.io/v1 true ResourceClaim resourceclaimtemplates resource.k8s.io/v1 true ResourceClaimTemplate resourceslices resource.k8s.io/v1 false ResourceSlice ``` ``` kubectl get deviceclasses ``` ``` NAME compute-domain-daemon.nvidia.com compute-domain-default-channel.nvidia.com ``` ## Instalación del complemento para dispositivos de EFA Para utilizar la comunicación de EFA entre UltraServers, debe instalar el complemento para dispositivos de Kubernetes para EFA. Las instancias P6e-GB200 se pueden configurar con hasta [17 tarjetas de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) y el NCI principal (índice 0) debe ser del tipo `interface` y admitir un ancho de banda ENA de hasta 100 Gbps. Configure las interfaces de EFA y ENA según sus requisitos durante el aprovisionamiento de nodos. Consulte la [documentación de AWS sobre la configuración de EFA para instancias P6e-GB200](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) para obtener más detalles sobre la configuración de EFA. 1. Cree un archivo de valores de Helm denominado `efa-values.yaml` con la configuración siguiente. ``` tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule ``` 1. Instale el operador de DRA de NVIDIA para el clúster con el archivo `dra-values.yaml` creado en el paso anterior. ``` helm repo add eks https://aws.github.io/eks-charts helm repo update ``` ``` helm install efa eks/aws-efa-k8s-device-plugin -n kube-system \ --version="0.5.14" \ -f efa-values.yaml ``` Por ejemplo, si configuró sus instancias con 1 interfaz de solo EFA en cada [grupo del NCI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e), al describir un nodo, se espera que haya 4 dispositivos de EFA asignables por nodo. ``` kubectl describe node/ ``` ``` Capacity: ... vpc.amazonaws.com/efa: 4 Allocatable: ... vpc.amazonaws.com/efa: 4 ``` ## Validación del IMEX mediante NVLink de varios nodos Para una prueba de NCCL de NVLink de varios nodos y otras microrreferencias, consulte el repositorio de GitHub [awesome-distributed-training](https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests). En los siguientes pasos se muestra cómo ejecutar una prueba de NVLink de varios nodos con nvbandwidth. 1. Para ejecutar una prueba de ancho de banda de varios nodos en dos nodos del dominio NVL72, instale antes el operador de MPI: ``` kubectl create -f https://github.com/kubeflow/mpi-operator/releases/download/v0.7.0/mpi-operator.yaml ``` 1. Cree un archivo de valores de Helm denominado `nvbandwidth-test-job.yaml` que defina el manifiesto de la prueba. Tenga en cuenta la afinidad del pod `nvidia.com/gpu.clique` para programar los trabajadores en el mismo dominio de NVLink que tiene accesibilidad de NVLink de varios nodos. El siguiente ejemplo ejecuta una prueba CE Read memcpy de dispositivo a dispositivo con varios nodos mediante cuMemcpyAsync e imprime los resultados en los registros. A partir de la versión `v25.8.0` del controlador de DRA de NVIDIA, los ComputeDomains son elásticos y se puede establecer `.spec.numNodes` `0` en la definición de ComputeDomain. Consulte las [notas de la versión más reciente del controlador de DRA de NVIDIA](https://github.com/NVIDIA/k8s-dra-driver-gpu) para ver las actualizaciones. ``` --- apiVersion: resource.nvidia.com/v1beta1 kind: ComputeDomain metadata: name: nvbandwidth-test-compute-domain spec: numNodes: 0 # This can be set to 0 from NVIDIA DRA Driver version v25.8.0+ channel: resourceClaimTemplate: name: nvbandwidth-test-compute-domain-channel --- apiVersion: kubeflow.org/v2beta1 kind: MPIJob metadata: name: nvbandwidth-test spec: slotsPerWorker: 4 # 4 GPUs per worker node launcherCreationPolicy: WaitForWorkersReady runPolicy: cleanPodPolicy: Running sshAuthMountPath: /home/mpiuser/.ssh mpiReplicaSpecs: Launcher: replicas: 1 template: metadata: labels: nvbandwidth-test-replica: mpi-launcher spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: # Only schedule on NVIDIA GB200/GB300 nodes - key: node.kubernetes.io/instance-type operator: In values: - p6e-gb200.36xlarge - p6e-gb300.36xlarge containers: - image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163 name: mpi-launcher securityContext: runAsUser: 1000 command: - mpirun args: - --bind-to - core - --map-by - ppr:4:node - -np - "8" - --report-bindings - -q - nvbandwidth - -t - multinode_device_to_device_memcpy_read_ce Worker: replicas: 2 # 2 worker nodes template: metadata: labels: nvbandwidth-test-replica: mpi-worker spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: # Only schedule on NVIDIA GB200/GB300 nodes - key: node.kubernetes.io/instance-type operator: In values: - p6e-gb200.36xlarge - p6e-gb300.36xlarge podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: nvbandwidth-test-replica operator: In values: - mpi-worker topologyKey: nvidia.com/gpu.clique containers: - image: ghcr.io/nvidia/k8s-samples:nvbandwidth-v0.7-8d103163 name: mpi-worker securityContext: runAsUser: 1000 env: command: - /usr/sbin/sshd args: - -De - -f - /home/mpiuser/.sshd_config resources: limits: nvidia.com/gpu: 4 # Request 4 GPUs per worker claims: - name: compute-domain-channel # Link to IMEX channel resourceClaims: - name: compute-domain-channel resourceClaimTemplateName: nvbandwidth-test-compute-domain-channel ``` 1. Cree el ComputeDomain e inicie el trabajo con el siguiente comando. ``` kubectl apply -f nvbandwidth-test-job.yaml ``` 1. Al crear el ComputeDomain, puede ver que el ComputeDomain de la carga de trabajo tiene dos nodos: ``` kubectl get computedomains.resource.nvidia.com -o yaml ``` ``` status: nodes: - cliqueID: . ipAddress: name: - cliqueID: . ipAddress: name: status: Ready ``` 1. Revise los resultados del trabajo con el siguiente comando. ``` kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher ``` Si la prueba se realiza correctamente, se muestran las estadísticas de ancho de banda en GB/s para la prueba con memcpy multinodo. A continuación, se muestra un ejemplo de resultado correcto de la prueba. ``` ... nvbandwidth Version: ... Built from Git version: ... MPI version: ... CUDA Runtime Version: ... CUDA Driver Version: ... Driver Version: ... Process 0 (nvbandwidth-test-worker-0): device 0: NVIDIA GB200 (...) Process 1 (nvbandwidth-test-worker-0): device 1: NVIDIA GB200 (...) Process 2 (nvbandwidth-test-worker-0): device 2: NVIDIA GB200 (...) Process 3 (nvbandwidth-test-worker-0): device 3: NVIDIA GB200 (...) Process 4 (nvbandwidth-test-worker-1): device 0: NVIDIA GB200 (...) Process 5 (nvbandwidth-test-worker-1): device 1: NVIDIA GB200 (...) Process 6 (nvbandwidth-test-worker-1): device 2: NVIDIA GB200 (...) Process 7 (nvbandwidth-test-worker-1): device 3: NVIDIA GB200 (...) Running multinode_device_to_device_memcpy_read_ce. memcpy CE GPU(row) -> GPU(column) bandwidth (GB/s) 0 1 2 3 4 5 6 7 0 N/A 821.45 822.18 821.73 822.05 821.38 822.61 821.89 1 822.34 N/A 821.67 822.12 821.94 820.87 821.53 822.08 2 821.76 822.29 N/A 821.58 822.43 821.15 821.82 822.31 3 822.19 821.84 822.05 N/A 821.67 821.23 820.95 822.47 4 821.63 822.38 821.49 822.17 N/A 821.06 821.78 822.22 5 822.08 821.52 821.89 822.35 821.27 N/A 821.64 822.13 6 821.94 822.15 821.68 822.04 821.39 820.92 N/A 822.56 7 822.27 821.73 822.11 821.86 822.38 821.04 821.49 N/A SUM multinode_device_to_device_memcpy_read_ce ... NOTE: The reported results may not reflect the full capabilities of the platform. Performance can vary with software drivers, hardware clocks, and system topology. ``` 1. Cuando se haya completado la prueba, elimínela con el siguiente comando. ``` kubectl delete -f nvbandwidth-test-job.yaml ```