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. O exemplo abaixo executa um teste CE de leitura memcpy entre dispositivos em vários nós utilizando cuMemcpyAsync e exibe os resultados nos logs.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: 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 -
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-launcherUm teste com êxito exibe as estatísticas de largura de banda em GB/s para o teste memcpy com vários nós. Segue abaixo um exemplo de resultado de teste com êxito.
... 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. -
Quando o teste estiver concluído, exclua-o com o comando apresentado a seguir.
kubectl delete -f nvbandwidth-test-job.yaml
