Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
Uso do P6e-GB200 UltraServers com o Amazon EKS
Este tópico descreve como realizar a configuração e o uso do Amazon EKS com P6e-GB200 UltraServers. O tipo de instância p6e-gb200.36xlarge com 4 GPUs NVIDIA Blackwell está disponível apenas como P6e-GB200 UltraServers. Existem dois tipos de P6e-GB200 UltraServers. O UltraServer u-p6e-gb200x36 conta com 9 instâncias p6e-gb200.36xlarge e o UltraServer u-p6e-gb200x72 conta com 18 instâncias p6e-gb200.36xlarge.
Para saber mais informações, consulte a página da web do P6e-GB200 UltraServers do Amazon EC2
Considerações
-
O Amazon EKS oferece suporte ao P6e-GB200 UltraServers para a versão 1.33 e versões posteriores do Kubernetes. O lançamento desta versão do Kubernetes é compatível com a alocação dinâmica de recursos
(DRA, na sigla em inglês), habilitada por padrão no EKS e nas AMIs aceleradas e otimizadas para o EKS do AL2023. A DRA é um requisito para usar o P6e-GB200 UltraServers com o EKS. A DRA não é compatível no Karpenter ou no modo automático do EKS, e recomenda-se o uso de grupos de nós autogerenciados do EKS ou de grupos de nós gerenciados pelo EKS ao usar o P6e-GB200 UltraServers com o EKS. -
O P6e-GB200 UltraServers é disponibilizado por meio de Blocos de Capacidade do EC2 para ML
. Consulte Gerencie recursos computacionais para workloads de IA/ML no Amazon EKS para obter informações sobre como iniciar nós do EKS com Blocos de Capacidade. -
Ao usar grupos de nós gerenciados do EKS com Blocos de Capacidade, é obrigatório o uso de modelos de inicialização personalizados. Ao atualizar os grupos de nós gerenciados do EKS com P6e-GB200 UltraServers, você deve definir o tamanho desejado do grupo de nós como
0antes de atualizar. -
Recomenda-se usar a variante do AL2023 para a arquitetura ARM da NVIDIA nas AMIs aceleradas e otimizadas para EKS. Esta AMI inclui os componentes de nó e a configuração necessários para trabalhar com P6e-GB200 UltraServers. Se você decidir criar sua própria AMI, será responsável por instalar e validar a compatibilidade do nó e do software do sistema, incluindo os drivers. Para obter mais informações, consulte Uso de AMIs aceleradas e otimizadas para o EKS em instâncias de GPU.
-
Recomenda-se usar a versão
v20251103ou versões posteriores da AMI otimizada para o EKS, que inclui o driver da NVIDIA na versão 580. Esta versão do driver da NVIDIA habilita o Coherent Driver-Based Memory Management (CDMM) para tratar possíveis gerações excessivas de relatórios de memória. Quando o CDMM está habilitado, as seguintes funcionalidades não são suportadas: GPU multi-instância (MIG, na sigla em inglês) da NVIDIA e vGPU. Para obter mais informações sobre o CDMM, consulte NVIDIA Coherent Driver-based Memory Management (CDMM). -
Ao usar o NVIDIA GPU Operator
com a AMI do AL2023 otimizada para o EKS com a NVIDIA, você deve desabilitar a instalação do driver e do toolkit pelo operador, pois estes já estão incluídos na AMI. As AMIs do AL2023 otimizadas para o EKS com a NVIDIA não incluem o plug-in de dispositivo da NVIDIA para Kubernetes ou o driver de DRA da NVIDIA. Portanto, estes devem ser instalados separadamente. -
Cada instância
p6e-gb200.36xlargepode ser configurada com até 17 placas de rede e pode aproveitar o EFA para comunicação entre UltraServers. O tráfego de rede das workloads pode transitar entre diferentes UltraServers, mas, para obter a máxima performance, recomenda-se agendar as workloads no mesmo UltraServer, aproveitando o IMEX para comunicação entre GPUs no nível intra-UltraServer. Para obter mais informações, consulte Configuração do EFA para instâncias P6e-GB200. -
Cada instância
p6e-gb200.36xlargeconta com 3x 7,5 TB de armazenamento de instância. Por padrão, a AMI otimizada para o EKS não realiza a formatação nem a montagem desses armazenamentos de instâncias. O armazenamento efêmero do nó pode ser compartilhado entre pods que solicitam armazenamento efêmero e imagens de contêiner baixadas no nó. Se estiver usando a AMI do AL2023 otimizada para o EKS, isso pode ser configurado como parte da inicialização dos nós nos dados do usuário, definindo a política de armazenamento local da instância em NodeConfig como RAID0. Ao configurar o RAID0, a instância armazena os dados em faixas e configura o runtime do contêiner e o kubelet para usar esse armazenamento efêmero.
Componentes
Os componentes, apresentados a seguir, são recomendados para a execução de workloads no EKS com o P6e-GB200 UltraServers. Você pode, opcionalmente, usar o NVIDIA GPU Operator
| Stack | Componente |
|---|---|
|
AMI acelerada e otimizada para o EKS |
Kernel 6.12 |
|
Driver de GPU da NVIDIA |
|
|
Driver de modo de usuário do NVIDIA CUDA |
|
|
NVIDIA Container Toolkit |
|
|
NVIDIA Fabric Manager |
|
|
Driver de IMEX da NVIDIA |
|
|
Gerenciador de sub-rede NVIDIA NVLink |
|
|
Driver do EFA |
|
|
Componentes em execução no nó |
CNI da VPC |
|
Plug-in de dispositivo do EFA |
|
|
Plug-in de dispositivo da NVIDIA para K8s |
|
|
Driver de DRA da NVIDIA |
|
|
NVIDIA Node Feature Discovery (NFD) |
|
|
NVIDIA GPU Feature Discovery (GFD) |
Os componentes de nó listados na tabela anterior desempenham as seguintes funções:
-
CNI da VPC: realiza a alocação de IPs da VPC como interface de rede principal para os pods que são executados no EKS.
-
Plug-in de dispositivo do EFA: realiza a alocação de dispositivos do EFA como redes secundárias para pods que são executados no EKS. É responsável pelo tráfego de rede entre P6e-GB200 UltraServers. Para workloads de vários nós, o tráfego de GPU para GPU dentro de um UltraServer pode ocorrer por meio do NVLink de vários nós.
-
Plug-in de dispositivo da NVIDIA para Kubernetes: realiza a alocação de GPUs como dispositivos para pods que são executados no EKS. Recomenda-se usar o plug-in de dispositivo da NVIDIA para Kubernetes até que a funcionalidade de alocação de GPU do driver de DRA da NVIDIA saia do estágio experimental. Consulte os lançamentos do driver de DRA da NVIDIA
para obter informações atualizadas. -
Driver de DRA da NVIDIA: habilita recursos personalizados de ComputeDomain que facilitam a criação de domínios de IMEX que acompanham as workloads em execução no P6e-GB200 UltraServers.
-
O recurso ComputeDomain descreve um domínio de Internode Memory Exchange (IMEX). Quando workloads com um ResourceClaim para um ComputeDomain são implantadas no cluster, o driver de DRA da NVIDIA cria automaticamente um DaemonSet de IMEX que é executado nos nós correspondentes e estabelece os canais de IMEX entre os nós antes do início da workload. Para saber mais informações sobre o IMEX, consulte Overview of NVIDIA IMEX for multi-node NVLink systems
. -
O driver de DRA da NVIDIA usa um rótulo de ID de clique (
nvidia.com/gpu.clique) aplicado pelo NVIDIA GFD, que transmite o conhecimento da topologia de rede e do domínio do NVLink. -
É uma prática recomendada criar um ComputeDomain para cada trabalho de workload.
-
-
NVIDIA Node Feature Discovery (NFD): dependência obrigatória para que o GFD aplique rótulos aos nós com base nos atributos descobertos no nível do nó.
-
NVIDIA GPU Feature Discovery (GFD): aplica aos nós um rótulo de topologia padrão da NVIDIA chamado
nvidia.com/gpu.clique. Os nós que compartilham o mesmonvidia.com/gpu.cliquetêm conectividade NVLink para vários nós, e você pode usar afinidades de pod em sua aplicação para agendar pods ao mesmo domínio do NVLink.
Procedimento
A seção a seguir pressupõe que você tenha um cluster do EKS executando o Kubernetes na versão 1.33 ou em versões posteriores com um ou mais grupos de nós com UltraServers P6e-GB200 que executam a AMI do AL2023 acelerada e otimizada para o EKS com o ARM da NVIDIA. Consulte os links apresentados em Gerencie recursos computacionais para workloads de IA/ML no Amazon EKS para as etapas de pré-requisito para nós autogerenciados e nos grupos de nós gerenciados do EKS.
O procedimento a seguir usa os componentes apresentados abaixo.
| Nome | Versão | Descrição |
|---|---|---|
|
NVIDIA GPU Operator |
25.3.4 ou posteriores |
Para o gerenciamento do ciclo de vida dos plug-ins obrigatórios, como o plug-in de dispositivo da NVIDIA para Kubernetes e NFD/GFD. |
|
Drivers de DRA da NVIDIA |
25.8.0 ou posteriores |
Para as CRDs de ComputeDomain e o gerenciamento de domínios de IMEX. |
|
Plug-in de dispositivo do EFA |
0.5.14 ou posteriores |
Para a comunicação entre UltraServers. |
Instalação do NVIDIA GPU Operator
O NVIDIA GPU Operator simplifica o gerenciamento dos componentes necessários para o uso de GPUs em clusters do Kubernetes. Como o driver de GPU da NVIDIA e o Container Toolkit já estão instalados como parte da AMI acelerada e otimizada para o EKS, estes devem ser definidos como false na configuração de valores do Helm.
-
Crie um arquivo de valores do Helm chamado
gpu-operator-values.yamlcom a configuração apresentada a seguir.devicePlugin: enabled: true nfd: enabled: true gfd: enabled: true driver: enabled: false toolkit: enabled: false migManager: enabled: false -
Instale o NVIDIA GPU Operator no cluster utilizando o arquivo
gpu-operator-values.yamlque você criou na etapa anterior.helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo updatehelm install gpu-operator nvidia/gpu-operator \ --namespace gpu-operator \ --create-namespace \ --version v25.3.4 \ --values gpu-operator-values.yaml
Instalação do driver de DRA da NVIDIA
A partir da versão v25.3.4 do NVIDIA GPU Operator, o driver de DRA da NVIDIA deve ser instalado separadamente. Recomenda-se acompanhar as notas de lançamento
-
Crie um arquivo de valores do Helm chamado
dra-values.yamlcom a configuração apresentada a seguir. Observe que os valoresnodeAffinityetolerationsconfiguram o driver de DRA para ser implantado apenas em nós que contam com uma GPU da 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 -
Instale o driver de DRA da NVIDIA no cluster utilizando o arquivo
dra-values.yamlque você criou na etapa anterior.helm repo add nvidia https://helm.ngc.nvidia.com/nvidia helm repo updatehelm 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 -
Após a instalação, o driver de DRA cria recursos de
DeviceClassque permitem ao Kubernetes compreender e alocar recursos deComputeDomain, viabilizando o gerenciamento do IMEX para workloads de GPU distribuídas em UltraServers P6e-GB200.Confirme se os recursos de DRA estão disponíveis usando os comandos apresentados a seguir.
kubectl api-resources | grep resource.k8s.iodeviceclasses 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 ResourceSlicekubectl get deviceclassesNAME compute-domain-daemon.nvidia.com compute-domain-default-channel.nvidia.com
Instalação do plug-in de dispositivo do EFA
Para usar a comunicação EFA entre UltraServers, você deve instalar o plug-in de dispositivo do Kubernetes para EFA. As instâncias P6e-GB200 podem ser configuradas com até 17 placas de rede, sendo que a NCI primária (índice 0) deve ser do tipo interface e fornecer suporte para até 100 Gbps de largura de banda ENA. Configure as interfaces EFA e ENA conforme seus requisitos durante o provisionamento do nó. Analise a documentação da AWS sobre a configuração de EFA para instâncias P6e-GB200 para obter mais detalhes relacionados a essa configuração.
-
Crie um arquivo de valores do Helm chamado
efa-values.yamlcom a configuração apresentada a seguir.tolerations: - key: nvidia.com/gpu operator: Exists effect: NoSchedule -
Instale o NVIDIA DRA Operator no cluster utilizando o arquivo
dra-values.yamlque você criou na etapa anterior.helm repo add eks https://aws.github.io/eks-charts helm repo updatehelm install efa eks/aws-efa-k8s-device-plugin -n kube-system \ --version="0.5.14" \ -f efa-values.yamlComo exemplo, se você configurou as instâncias com uma interface apenas de EFA em cada grupo de NCI, ao descrever um nó, a expectativa é encontrar quatro dispositivos de EFA alocáveis.
kubectl describe node/<gb200-node-name>Capacity: ... vpc.amazonaws.com/efa: 4 Allocatable: ... vpc.amazonaws.com/efa: 4
Validação de IMEX no NVLink de vários nós
Confira o repositório awesome-distributed-training
-
Para executar um teste de largura de banda de vários nós entre dois nós no domínio NVL72, primeiro instale o MPI Operator:
kubectl create -f https://github.com/kubeflow/mpi-operator/releases/download/v0.7.0/mpi-operator.yaml -
Crie um arquivo de valores do Helm chamado
nvbandwidth-test-job.yamlque define o manifesto do teste. Observe o uso da afinidade do podnvidia.com/gpu.cliquepara garantir que os processamentos sejam agendados no mesmo domínio do NVLink que tem conectividade NVLink de vários nós.A partir da versão
v25.8.0do driver de DRA da NVIDIA, os ComputeDomains são elásticos e o campo.spec.numNodespode ser definido como0na definição do ComputeDomain. Consulte as últimas notas de lançamento do driver de DRA da NVIDIApara obter atualizações. --- 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: 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: 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 -
Crie o recurso ComputeDomain e inicie o trabalho com o comando apresentado a seguir.
kubectl apply -f nvbandwidth-test-job.yaml -
Após a criação do ComputeDomain, você poderá verificar que o ComputeDomain da workload tem dois nós:
kubectl get computedomains.resource.nvidia.com -o yamlstatus: nodes: - cliqueID: <ClusterUUID>.<Clique ID> ipAddress: <node-ip> name: <node-hostname> - cliqueID: <ClusterUUID>.<Clique ID> ipAddress: <node-ip> name: <node-hostname> status: Ready -
Analise os resultados do trabalho com o comando apresentado a seguir.
kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher -
Quando o teste estiver concluído, exclua-o com o comando apresentado a seguir.
kubectl delete -f nvbandwidth-test-job.yaml