**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](https://aws.amazon.com/ec2/instance-types/p6/).
## 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](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (DRA, na sigla em inglês), habilitada por padrão no EKS e nas [AMIs aceleradas e otimizadas para o EKS do AL2023](https://docs.aws.amazon.com/eks/latest/userguide/ml-eks-optimized-ami.html). 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](https://aws.amazon.com/ec2/capacityblocks/). Consulte [Gerencie recursos computacionais para workloads de IA/ML no Amazon EKS](ml-compute-management.md) 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 `0` antes 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](ml-eks-optimized-ami.md).
+ Recomenda-se usar a versão `v20251103` ou 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 (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)](https://nvdam.widen.net/s/gpqp6wmz7s/cuda-whitepaper—cdmm-pdf).
+ Ao usar o [NVIDIA GPU Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) 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.36xlarge` pode 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e).
+ Cada instância `p6e-gb200.36xlarge` conta com 3x 7,5 TB de [armazenamento de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html). 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](https://docs.aws.amazon.com/eks/latest/eksctl/node-bootstrapping.html#configuring-the-bootstrapping-process) 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](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html) para instalar os componentes de nó da NVIDIA. 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.
- ** 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](https://github.com/NVIDIA/k8s-dra-driver-gpu/releases) 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](https://docs.nvidia.com/multi-node-nvlink-systems/imex-guide/overview.html).
+ 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 mesmo `nvidia.com/gpu.clique` tê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](ml-compute-management.md) 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.
1. Crie um arquivo de valores do Helm chamado `gpu-operator-values.yaml` com a configuração apresentada a seguir.
```
devicePlugin:
enabled: true
nfd:
enabled: true
gfd:
enabled: true
driver:
enabled: false
toolkit:
enabled: false
migManager:
enabled: false
```
1. Instale o NVIDIA GPU Operator no cluster utilizando o arquivo `gpu-operator-values.yaml` que você criou na etapa 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
```
## 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](https://github.com/NVIDIA/gpu-operator/releases) do NVIDIA GPU Operator, pois isso pode mudar em versões futuras.
1. Crie um arquivo de valores do Helm chamado `dra-values.yaml` com a configuração apresentada a seguir. Observe que os valores `nodeAffinity` e `tolerations` configuram 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
```
1. Instale o driver de DRA da NVIDIA no cluster utilizando o arquivo `dra-values.yaml` que você criou na etapa 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. Após a instalação, o driver de DRA cria recursos de `DeviceClass` que permitem ao Kubernetes compreender e alocar recursos de `ComputeDomain`, 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.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
```
## 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e), 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e) para obter mais detalhes relacionados a essa configuração.
1. Crie um arquivo de valores do Helm chamado `efa-values.yaml` com a configuração apresentada a seguir.
```
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
```
1. Instale o NVIDIA DRA Operator no cluster utilizando o arquivo `dra-values.yaml` que você criou na etapa 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
```
Como exemplo, se você configurou as instâncias com uma interface apenas de EFA em cada [grupo de NCI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html#efa-for-p6e), ao descrever um nó, a expectativa é encontrar quatro dispositivos de EFA alocáveis.
```
kubectl describe node/
```
```
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](https://github.com/aws-samples/awsome-distributed-training/tree/main/micro-benchmarks/nccl-tests) do GitHub para realizar testes de NCCL para o NCLink de vários nós e outras avaliações comparativas de performance. As etapas a seguir mostram como executar um teste de NVLink de vários nós com o nvbandwidth.
1. 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
```
1. Crie um arquivo de valores do Helm chamado `nvbandwidth-test-job.yaml` que define o manifesto do teste. Observe o uso da afinidade do pod `nvidia.com/gpu.clique` para 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.0` do driver de DRA da NVIDIA, os ComputeDomains são elásticos e o campo `.spec.numNodes` pode ser definido como `0` na definição do ComputeDomain. Consulte as últimas [notas de lançamento do driver de DRA da NVIDIA](https://github.com/NVIDIA/k8s-dra-driver-gpu) para 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
```
1. Crie o recurso ComputeDomain e inicie o trabalho com o comando apresentado a seguir.
```
kubectl apply -f nvbandwidth-test-job.yaml
```
1. 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 yaml
```
```
status:
nodes:
- cliqueID: .
ipAddress:
name:
- cliqueID: .
ipAddress:
name:
status: Ready
```
1. Analise os resultados do trabalho com o comando apresentado a seguir.
```
kubectl logs --tail=-1 -l job-name=nvbandwidth-test-launcher
```
Um 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.
```
1. Quando o teste estiver concluído, exclua-o com o comando apresentado a seguir.
```
kubectl delete -f nvbandwidth-test-job.yaml
```