View a markdown version of this page

Utilisation P6e-GB200 UltraServers avec Amazon EKS - Amazon EKS

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 sur 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.

Utilisation P6e-GB200 UltraServers avec Amazon EKS

Cette rubrique décrit comment configurer et utiliser Amazon EKS avec P6e-GB200 UltraServers. Le type d'p6e-gb200.36xlargeinstance avec 4 GPU NVIDIA Blackwell est uniquement disponible en tant que. P6e-GB200 UltraServers Il existe deux types de P6e-GB200 UltraServers. u-p6e-gb200x36 UltraServer Il a 9 p6e-gb200.36xlarge instances et 18 p6e-gb200.36xlarge instances. u-p6e-gb200x72 UltraServer

Pour en savoir plus, consultez la page Web Amazon EC2. P6e-GB200 UltraServers

Considérations

  • Amazon EKS prend en charge P6e-GB200 UltraServers les versions 1.33 et supérieures de Kubernetes. Cette version de Kubernetes prend en charge l'allocation dynamique des ressources (DRA), activée par défaut dans EKS et dans les AMI accélérées AL2023. EKS-optimized Le DRA est obligatoire pour utiliser le P6e-GB200 UltraServers avec EKS. Le DRA n'est pas pris en charge en mode Karpenter ou EKS Auto, et il est recommandé d'utiliser des groupes de nœuds autogérés par EKS ou des groupes de nœuds gérés par EKS lorsque vous utilisez le P6e-GB200 UltraServers avec EKS.

  • P6e-GB200 UltraServers sont disponibles via les blocs de capacité EC2 pour ML. Consultez Gérez les ressources informatiques pour les AI/ML charges de travail sur Amazon EKS pour plus d'informations sur le lancement de nœuds EKS avec des blocs de capacité.

  • Lorsque vous utilisez des groupes de nœuds gérés par EKS avec des blocs de capacité, vous devez utiliser des modèles de lancement personnalisés. Lorsque vous mettez à niveau des groupes de nœuds gérés par EKS avec P6e-GB200 UltraServers, vous devez définir la taille souhaitée du groupe de nœuds 0 avant de procéder à la mise à niveau.

  • Il est recommandé d'utiliser la variante AL2023 ARM NVIDIA des AMI EKS-optimized accélérées. Cette AMI inclut les composants de nœud et la configuration requis pour fonctionner P6e-GB200 UltraServers. Si vous décidez de créer votre propre AMI, vous êtes responsable de l'installation et de la validation de la compatibilité du nœud et du logiciel système, y compris les pilotes. Pour de plus amples informations, veuillez consulter Utiliser l'accélérateur optimisé pour EKS AMIs pour les instances GPU.

  • Il est recommandé d'utiliser la version EKS-optimized AMI v20251103 ou ultérieure, qui inclut la version 580 du pilote NVIDIA. Cette version du pilote NVIDIA permet à Coherent Driver-Based Memory (CDMM) de remédier à un éventuel sursignalement de mémoire. Lorsque le CDMM est activé, les fonctionnalités suivantes ne sont pas prises en charge : Multi-Instance GPU NVIDIA (MIG) et vGPU. Pour plus d'informations sur le CDMM, consultez NVIDIA Coherent Driver-based Memory Management (CDMM).

  • Lorsque vous utilisez l'opérateur GPU NVIDIA avec l'AMI NVIDIA EKS-optimized AL2023, vous devez désactiver l'installation du pilote et du kit d'outils par l'opérateur, car ceux-ci sont déjà inclus dans l'AMI. Les AMI NVIDIA EKS-optimized AL2023 n'incluent pas le plug-in de périphérique NVIDIA Kubernetes ni le pilote NVIDIA DRA, et ceux-ci doivent être installés séparément.

  • Chaque p6e-gb200.36xlarge instance peut être configurée avec un maximum de 17 cartes réseau et peut utiliser l'EFA pour la communication entre les deux UltraServers. Le trafic réseau peut se croiser UltraServers, mais pour des performances optimales, il est recommandé de planifier les charges de travail de la même manière en UltraServer tirant parti de l'IMEX pour les communications intra-GPU. UltraServer Pour plus d'informations, consultez la section Configuration EFA pour les P6e-GB200 instances.

  • Chaque p6e-gb200.36xlarge instance dispose de 3 fois 7,5 To de stockage d'instance. Par défaut, l' EKS-optimized AMI ne met pas en forme et ne monte pas les magasins d'instances. Le stockage éphémère du nœud peut être partagé entre les pods qui demandent un stockage éphémère et les images des conteneurs téléchargées sur le nœud. Si vous utilisez l' EKS-optimized AMI AL2023, celle-ci peut être configurée dans le cadre du bootstrap des nœuds dans les données utilisateur en définissant la politique de stockage local de l'instance sur RAID0. NodeConfig Le réglage sur RAID0 répartit l'instance pour stocker et configurer le runtime du conteneur et le kubelet pour utiliser ce stockage éphémère.

Éléments

Les composants suivants sont recommandés pour exécuter des charges de travail sur EKS avec le P6e-GB200 UltraServers. Vous pouvez éventuellement utiliser l'opérateur GPU NVIDIA pour installer les composants du nœud NVIDIA. Lorsque vous utilisez l'opérateur GPU NVIDIA avec l'AMI NVIDIA EKS-optimized AL2023, vous devez désactiver l'installation du pilote et du kit d'outils par l'opérateur, car ceux-ci sont déjà inclus dans l'AMI.

Pile Composant

EKS-optimized AMI accéléré

Noyau 6.12

pilote GPU NVIDIA

Pilote en mode utilisateur NVIDIA CUDA

Boîte à outils pour conteneurs NVIDIA

Gestionnaire de tissus NVIDIA

pilote NVIDIA IMEX

Gestionnaire de sous-réseau NVIDIA NVLink

pilote EFA

Composants exécutés sur le nœud

PVC CNI

pilote EFA DRA ou plug-in de périphérique EFA

Plug-in pour appareil NVIDIA K8s

pilote NVIDIA DRA

Découverte des fonctionnalités des nœuds NVIDIA (NFD)

Découverte des fonctionnalités du GPU NVIDIA (GFD)

Les composants du nœud présentés dans le tableau ci-dessus exécutent les fonctions suivantes :

  • VPC CNI : alloue des adresses IP VPC comme interface réseau principale pour les pods exécutés sur EKS

  • Pilote EFA DRA ou plug-in de périphérique EFA : alloue les périphériques EFA en tant que réseaux secondaires pour les pods fonctionnant sur EKS. Responsable du trafic réseau à travers P6e-GB200 UltraServers. Pour les charges de travail à nœuds multiples, le GPU-to-GPU trafic au sein de et UltraServer peut circuler sur NVLink à nœuds multiples. Le pilote EFA DRA est recommandé pour Kubernetes 1.34 et versions ultérieures et permet une allocation et un partage de périphériques adaptés à la topologie. Le plugin pour appareil EFA est compatible avec toutes les versions de Kubernetes. Pour de plus amples informations, veuillez consulter Gérez les appareils EFA sur Amazon EKS.

  • Plug-in pour appareils NVIDIA Kubernetes : alloue des GPU en tant qu'appareils aux pods exécutés sur EKS. Il est recommandé d'utiliser le plug-in de périphérique NVIDIA Kubernetes jusqu'à ce que la fonctionnalité d'allocation du GPU du pilote NVIDIA DRA soit terminée à la fin de la phase expérimentale. Consultez les versions du pilote NVIDIA DRA pour obtenir des informations actualisées.

  • Pilote NVIDIA DRA : active des ressources ComputeDomain personnalisées qui facilitent la création de domaines IMEX qui suivent les charges de travail en cours d'exécution. P6e-GB200 UltraServers

    • La ComputeDomain ressource décrit un domaine IMEX (Internode Memory Exchange). Lorsque des charges de travail dotées ResourceClaim de la forme a ComputeDomain sont déployées sur le cluster, le pilote NVIDIA DRA crée automatiquement un IMEX DaemonSet qui s'exécute sur les nœuds correspondants et établit le ou les canaux IMEX entre les nœuds avant le démarrage de la charge de travail. Pour en savoir plus sur l'IMEX, consultez la présentation de NVIDIA IMEX pour les systèmes NVLink à nœuds multiples.

    • Le pilote NVIDIA DRA utilise une étiquette d'identification par clic (nvidia.com/gpu.clique) appliquée par NVIDIA GFD qui transmet la connaissance de la topologie du réseau et du domaine NVLink.

    • Il est recommandé de créer une tâche ComputeDomain par charge de travail.

  • NVIDIA Node Feature Discovery (NFD) : dépendance requise pour que le GFD applique des étiquettes de nœuds en fonction des attributs découverts au niveau du nœud.

  • NVIDIA GPU Feature Discovery (GFD) : applique une étiquette topologique standard NVIDIA appelée nvidia.com/gpu.clique aux nœuds. Les nœuds d'un même nœud nvidia.com/gpu.clique ont plusieurs nœuds NVLink-reachability, et vous pouvez utiliser les affinités des pods dans votre application pour planifier des pods dans le même domaine NVLink.

Procédure

La section suivante suppose que vous disposez d'un cluster EKS exécutant Kubernetes version 1.33 ou supérieure avec un ou plusieurs groupes de nœuds exécutant P6e-GB200 UltraServers l'AMI accélérée AL2023 ARM NVIDIA. EKS-optimized Consultez les liens ci-dessous Gérez les ressources informatiques pour les AI/ML charges de travail sur Amazon EKS pour connaître les étapes préalables relatives aux nœuds autogérés et aux groupes de nœuds gérés par EKS.

La procédure suivante utilise les composants ci-dessous.

Nom Version Description

Opérateur GPU NVIDIA

25,3,4 et plus

Pour la gestion du cycle de vie des plug-ins requis tels que le plug-in pour appareils NVIDIA Kubernetes et. NFD/GFD

Pilotes NVIDIA DRA

25,8,0 et plus

Pour la ComputeDomain gestion des domaines CRD et IMEX.

pilote EFA DRA (DRANET)

Dernière

Pour une UltraServer communication croisée avec une allocation adaptée à la topologie. Recommandé pour Kubernetes 1.34+.

Plug-in pour appareil EFA

0,5,14 et plus

Pour la UltraServer communication croisée. Pris en charge pour toutes les versions de Kubernetes.

Installer l'opérateur GPU NVIDIA

L'opérateur de GPU NVIDIA simplifie la gestion des composants nécessaires à l'utilisation des GPU dans les clusters Kubernetes. Comme le pilote GPU NVIDIA et le kit d'outils de conteneur sont installés dans le cadre de l'AMI EKS-optimized accélérée, ils doivent être définis false dans la configuration des valeurs Helm.

  1. Créez un fichier de valeurs Helm nommé gpu-operator-values.yaml avec la configuration suivante.

    devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true driver: enabled: false toolkit: enabled: false migManager: enabled: false
  2. Installez l'opérateur GPU NVIDIA pour votre cluster à l'aide du gpu-operator-values.yaml fichier que vous avez créé à l'étape précédente.

    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

Installez le pilote NVIDIA DRA

À partir de la version opérateur du GPU NVIDIAv25.3.4, le pilote NVIDIA DRA doit être installé séparément. Il est recommandé de suivre les notes de mise à jour des opérateurs du GPU NVIDIA, car cela pourrait changer dans une future version.

  1. Créez un fichier de valeurs Helm nommé dra-values.yaml avec la configuration suivante. Notez le nodeAffinity et tolerations qui configure le pilote DRA pour qu'il soit déployé uniquement sur des nœuds dotés d'un GPU NVIDIA.

    resources: gpus: enabled: false # set to false to disable experimental gpu support computeDomains: enabled: true controller: nodeSelector: null affinity: null tolerations: [] kubeletPlugin: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "nvidia.com/gpu.present" operator: In values: - "true" tolerations: - key: "nvidia.com/gpu" operator: Exists effect: NoSchedule
  2. Installez le pilote NVIDIA DRA pour votre cluster à l'aide du dra-values.yaml fichier que vous avez créé à l'étape précédente.

    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
  3. Après l'installation, le pilote DRA crée DeviceClass des ressources qui permettent à Kubernetes de comprendre et d'allouer les ComputeDomain ressources, rendant ainsi possible la gestion IMEX pour les charges de travail distribuées sur le GPU. P6e-GB200 UltraServers

    Vérifiez que les ressources DRA sont disponibles à l'aide des commandes suivantes.

    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

Installez EFA pour la UltraServer communication croisée

Pour utiliser la communication EFA entre UltraServers eux, installez le pilote EFA DRA (DRANET) ou le plug-in de périphérique EFA. P6e-GB200 les instances peuvent être configurées avec un maximum de 17 cartes réseau et le NCI principal (indice 0) doit être de type interface et prendre en charge jusqu'à 100 Gbit/s de bande passante ENA. Configurez vos interfaces EFA et ENA selon vos besoins lors du provisionnement des nœuds. Consultez la AWS documentation relative à la configuration EFA pour les P6e-GB200 instances pour plus de détails sur la configuration EFA.

Important

N'installez pas le pilote EFA DRA et le plug-in de périphérique EFA sur le même nœud. Les deux mécanismes ne peuvent pas coexister sur le même nœud.

Option 1 : installer le pilote EFA DRA (DRANET)

  1. Créez un fichier de valeurs Helm nommé efa-values.yaml avec la configuration suivante.

    tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule
  2. Ajoutez le référentiel de cartes EKS Helm et installez le pilote EFA DRA.

    helm repo add eks https://aws.github.io/eks-charts helm repo update
    helm install aws-dranet eks/aws-dranet --namespace kube-system -f efa-values.yaml
  3. Vérifiez que le DRANET DaemonSet est en cours d'exécution.

    kubectl get daemonset -n kube-system aws-dranet
    NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE aws-dranet 2 2 2 2 2 <none> 60s
  4. Vérifiez que les ResourceSlice objets DeviceClass et sont disponibles.

    kubectl get deviceclass efa.networking.k8s.aws
    NAME AGE efa.networking.k8s.aws 60s
    kubectl get resourceslices -l resource.k8s.io/driver=dra.net

Pour plus d'informations sur l'utilisation du pilote EFA DRA, notamment sur l'allocation adaptée à la topologie et le partage de périphériques, consultez. Gérez les appareils EFA sur Amazon EKS

Option 2 : installer le plug-in pour appareil EFA

  1. Créez un fichier de valeurs Helm nommé efa-values.yaml avec la configuration suivante.

    tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule
  2. Ajoutez le référentiel de cartes EKS Helm et installez le plug-in de l'appareil EFA.

    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 -f efa-values.yaml
  3. Vérifiez que le plug-in de l'appareil EFA DaemonSet est en cours d'exécution.

    kubectl get daemonset -n kube-system aws-efa-k8s-device-plugin-daemonset
    NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE aws-efa-k8s-device-plugin-daemonset 2 2 2 2 2 <none> 60s
  4. Vérifiez que vos nœuds disposent de dispositifs EFA allouables. Par exemple, si vous avez configuré vos instances avec une interface EFA uniquement dans chaque groupe NCI, il est prévu de voir 4 périphériques EFA allouables par nœud.

    kubectl get nodes "-o=custom-columns=NAME:.metadata.name,EFA:.status.allocatable.vpc\.amazonaws\.com/efa"
    NAME EFA ip-192-168-11-225.us-west-2.compute.internal 4 ip-192-168-24-96.us-west-2.compute.internal 4

Pour un test NCCL NVLINK multi-nœuds et d'autres microbenchmarks, consultez le référentiel d'entraînement distribué impressionnant. GitHub Les étapes suivantes montrent comment exécuter un test NVLink à nœuds multiples avec nvbandwidth.

  1. Pour exécuter un test de bande passante multi-nœuds sur deux nœuds du domaine NVL72, installez d'abord l'opérateur MPI :

    kubectl create -f https://github.com/kubeflow/mpi-operator/releases/download/v0.7.0/mpi-operator.yaml
  2. Créez un fichier nommé nvbandwidth-test-job.yaml qui définit le manifeste de test. Notez l'affinité du nvidia.com/gpu.clique pod pour planifier les travailleurs dans le même domaine NVLink auquel NVLink est Multi-Node joignable. L'exemple ci-dessous exécute un test CE Read memcpy multinœud périphérique à périphérique à l'aide de cu MemcpyAsync et imprime les résultats dans les journaux.

    À partir de la version du pilote NVIDIA DRA, v25.8.0 ComputeDomains elles sont élastiques et .spec.numNodes peuvent être définies 0 dans la ComputeDomain définition. Consultez les dernières notes de version du pilote NVIDIA DRA pour les mises à jour.

    Il ne peut y avoir qu'un seul ComputeDomain (canal IMEX) par nœud. Ne modifiez pas la valeur allocationMode All de la ComputeDomain ressource, car cela peut empêcher les pods ComputeDomain et d'y accéder ComputeDomain d'être alloués et planifiés correctement. Pour plus d'informations, consultez le numéro #353 du pilote NVIDIA DRA.

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

+. Créez le ComputeDomain et lancez-le avec la commande suivante.

+

kubectl apply -f nvbandwidth-test-job.yaml

+. ComputeDomain création, vous pouvez voir que la charge de travail ComputeDomain comporte deux nœuds :

+

kubectl get computedomains.resource.nvidia.com -o yaml

+

status: nodes: - cliqueID: <ClusterUUID>.<Clique ID> ipAddress: <node-ip> name: <node-hostname> - cliqueID: <ClusterUUID>.<Clique ID> ipAddress: <node-ip> name: <node-hostname> status: Ready

+. Passez en revue les résultats de la tâche à l'aide de la commande suivante.

+

kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher

+ Un test réussi affiche les statistiques de bande passante GB/s pour le test memcpy multi-nœuds. Un exemple de résultat de test réussi est présenté ci-dessous.

+

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

+. Lorsque le test est terminé, supprimez-le à l'aide de la commande suivante.

+

kubectl delete -f nvbandwidth-test-job.yaml