O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Criar um cluster do GKE personalizado otimizado para IA que usa o A4X Max

Este documento mostra como criar um cluster do Google Kubernetes Engine (GKE) otimizado para IA que usa instâncias A4X Max do Compute Engine para oferecer suporte às cargas de trabalho de IA e ML.

As séries A4X Max e A4X permitem executar clusters de IA/ML em grande escala usando o sistema NVIDIA Multi-Node NVLink (MNNVL), uma solução de rack que permite maior potência e desempenho da GPU. Essas máquinas oferecem recursos como posicionamento de carga de trabalho direcionado, programação com reconhecimento de topologia e controles avançados de manutenção de cluster. Para mais informações, consulte Capacidades de gerenciamento de clusters. Com o A4X Max, o GKE também oferece uma configuração de rede automatizada que simplifica a configuração do cluster.

As cargas de trabalho de IA e ML, como o treinamento distribuído, exigem aceleração poderosa para otimizar o desempenho, reduzindo os tempos de conclusão de jobs. O GKE oferece uma única plataforma para executar um conjunto diversificado de cargas de trabalho para suas organizações, reduzindo o ônus operacional de gerenciar várias plataformas. É possível executar cargas de trabalho como pré-treinamento distribuído de alto desempenho, ajuste fino de modelos, inferência de modelos, exibição de aplicativos e serviços de suporte. Para cargas de trabalho que exigem alto desempenho, alta capacidade de processamento e baixa latência, o GPUDirect RDMA reduz os saltos de rede necessários para transferir payloads de e para GPUs. Essa abordagem usa de maneira mais eficiente a largura de banda de rede disponível. Para mais informações, consulte Pilhas de rede de GPU.

Neste documento, você vai aprender a criar um cluster do GKE com a Google Cloud CLI para ter máxima flexibilidade na configuração do cluster com base nas necessidades da carga de trabalho. Para usar a CLI gcloud para criar clusters com outros tipos de máquina, consulte o seguinte:

A4X: crie um cluster do GKE personalizado otimizado para IA que usa o A4X.
A4 ou A3 Ultra: para criar um cluster que usa o A4 ou A3 Ultra, consulte Criar um cluster do GKE personalizado otimizado para IA que usa o A4 ou A3 Ultra. É possível usar essas séries de máquinas para executar cargas de trabalho com ou sem o GPUDirect RDMA.

Como alternativa, você pode usar o Cluster Toolkit para implantar rapidamente o cluster com configurações padrão que refletem as práticas recomendadas para muitos casos de uso. Para mais informações, consulte Criar um cluster do GKE otimizado para IA com configuração padrão.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação: Para instalações prévias da CLI gcloud, defina a compute/region propriedade. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Como conseguir capacidade

É possível conseguir capacidade para instâncias de computação A4X Max criando uma reserva adiantada. Para mais informações sobre reservas adiantadas, consulte a coluna Reservas adiantadas no Hipercomputador de IA na tabela para Escolher uma opção de consumo.

Para conseguir capacidade com uma reserva adiantada, consulte a linha Reservas adiantadas no Hipercomputador de IA na tabela para Como conseguir capacidade.

Requisitos

Os requisitos a seguir se aplicam a um cluster do GKE otimizado para IA com instâncias de computação A4X Max:

Para o A4X Max, é necessário usar uma das seguintes versões:
- Para a versão 1.35 ou mais recente, use a versão 1.35.0-gke.2745000 ou mais recente do GKE.
- Para a versão 1.34, use a versão 1.34.3-gke.1318000 ou mais recente do GKE.
Essas versões ajudam a garantir que o A4X Max use o seguinte:
- R580.95.05, a versão mínima do driver de GPU para A4X Max, que é ativada por padrão.
- Gerenciamento de memória baseado em driver coerente (CDMM, na sigla em inglês), que é ativado por padrão. A NVIDIA recomenda que os clusters do Kubernetes ativem esse modo para resolver o excesso de relatórios de memória. O CDMM permite que a memória da GPU seja gerenciada pelo driver em vez do sistema operacional (SO). Essa abordagem ajuda a evitar a ativação da memória da GPU pelo SO e expõe a memória da GPU como um nó de acesso à memória não uniforme (NUMA, na sigla em inglês) para o SO. As GPUs de várias instâncias não são compatíveis quando o CDMM está ativado. Para mais informações sobre CDMM, consulte Suporte de hardware e software Suporte.
- GPUDirect RDMA e MNNVL, que são recomendados para permitir que os pools de nós A4X Max usem os recursos de rede do A4X Max.
Os nós do GKE precisam usar uma imagem de nó do Container-Optimized OS. As imagens de nós do Ubuntu e do Windows não são compatíveis.
Sua carga de trabalho do GKE precisa usar todas as GPUs disponíveis, e o pod precisa usar todas as NICs secundárias disponíveis em um único nó do GKE. Vários pods não podem compartilhar o RDMA em um único nó do GKE.
É necessário usar o modelo de provisionamento vinculado à reserva para criar clusters com o A4X Max. Outros modelos de provisionamento não são compatíveis.
Estas instruções usam DRANET para configurar um cluster do GKE otimizado para IA com o A4X Max. Não há suporte para várias redes no tipo de máquina a4x-maxgpu-4g-metal.

Considerações para criar um cluster

Ao criar um cluster, considere as seguintes informações:

Escolha um local do cluster:
- Verifique se você usa um local que tenha disponibilidade para o tipo de máquina escolhido. Para mais informações, consulte Disponibilidade do acelerador.
- Ao criar pools de nós em um cluster regional, que são recomendados para cargas de trabalho de produção, é possível usar a --node-locations flag para especificar as zonas dos nós do GKE.
Escolha uma versão do driver:
- A versão do driver pode ser um dos seguintes valores:
  - default: instala a versão padrão do driver para a versão do nó do GKE. Para mais informações sobre os requisitos das versões padrão do driver, consulte a seção Requisitos.
  - latest: instala a versão mais recente disponível do driver para a versão do GKE. Essa opção está disponível apenas para nós que usam o Container-Optimized OS.
  - disabled: ignora a instalação automática do driver. É necessário instalar um driver manualmente depois de criar o pool de nós.
- Para mais informações sobre as versões padrão e mais recentes do driver de GPU para versões de nó do GKE, consulte a tabela na seção Instalar manualmente os drivers de GPU NVIDIA.
Escolha uma afinidade de reserva:
- É possível encontrar informações sobre a reserva, como o nome dela ou o nome de um bloco específico na reserva. Para encontrar esses valores, consulte Conferir futuras solicitações de reserva .
- A flag --reservation-affinity pode receber os valores specific ou any. No entanto, para cargas de trabalho de IA distribuídas de alto desempenho, recomendamos o uso de uma reserva específica.
- Ao usar uma reserva específica, incluindo reservas compartilhadas, especifique o valor da flag --reservation no seguinte formato:
```
projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
```
  Substitua os seguintes valores:
  - PROJECT_ID: o ID do Google Cloud projeto.
  - RESERVATION_NAME: o nome da reserva.
  - BLOCK_NAME: o nome de um bloco específico dentro da reserva.
  Também recomendamos o uso de uma reserva direcionada a um sub-bloco para que as instâncias de computação sejam colocadas em um único sub-bloco dentro do BLOCK_NAME. Adicione o seguinte ao final do caminho:
```
/reservationSubBlocks/SUB_BLOCK_NAME
```
  Substitua SUB_BLOCK_NAME pelo nome do sub-bloco.
  
  Dica: Se a reserva estiver localizada no projeto atual, omita projects/PROJECT_ID/reservations/do valor da reserva.

Criar um cluster do GKE otimizado para IA que usa o A4X Max e o GPUDirect RDMA

Para cargas de trabalho de IA distribuídas, vários nós de GPU são geralmente vinculados para funcionar como um único computador. O A4X Max é uma plataforma de exaescala baseada na arquitetura de rack NVIDIA GB300 NVL72. As instâncias de computação A4X Max usam uma arquitetura de rede hierárquica de várias camadas com um design alinhado por rails para otimizar o desempenho de vários tipos de comunicação. Esse tipo de máquina permite escalonamento e colaboração em várias GPUs, oferecendo uma experiência de nuvem de alto desempenho para cargas de trabalho de IA. Para mais informações sobre a arquitetura de rede do A4X Max, incluindo a largura de banda da rede e o arranjo de NICs, consulte Tipo de máquina A4X Max (bare metal).

Para criar um cluster do GKE Standard com o A4X Max que usa o GPUDirect RDMA e o MNNVL, conclua as etapas descritas nas seções a seguir:

Criar o cluster do GKE
Criar uma política de carga de trabalho
Criar um pool de nós com o A4X Max
Configurar as NICs MRDMA com asapd-lite
Instalar o CRD do domínio de computação da NVIDIA e o driver DRA
Configurar o manifesto da carga de trabalho para o domínio RDMA e IMEX

Estas instruções usam perfis de rede de acelerador para configurar automaticamente redes VPC e sub-redes para os nós A4X Max. Como alternativa, é possível especificar explicitamente a rede VPC e as sub-redes.

Criar o cluster do GKE

Crie um cluster do GKE Standard:
```
gcloud container clusters create CLUSTER_NAME \
  --enable-dataplane-v2 \
  --enable-ip-alias \
  --location=COMPUTE_REGION \
  --cluster-version=CLUSTER_VERSION \
  --no-enable-shielded-nodes [\
  --services-ipv4-cidr=SERVICE_CIDR \
  --cluster-ipv4-cidr=POD_CIDR \
  --addons=GcpFilestoreCsiDriver=ENABLED]
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- CLUSTER_VERSION: a versão do novo cluster. Para mais informações sobre qual versão do GKE oferece suporte à sua configuração, consulte os Requisitos neste documento.
- COMPUTE_REGION: o nome da região de computação.
- Opcionalmente, é possível fornecer explicitamente os intervalos de CIDR secundários para serviços e pods. Se você usar essas flags opcionais, substitua as seguintes variáveis:
  - SERVICE_CIDR: o intervalo CIDR secundário para serviços.
  - POD_CIDR: o intervalo CIDR secundário para pods.
  Ao usar essas flags, é necessário verificar se os intervalos de CIDR não se sobrepõem aos intervalos de sub-rede para redes de nós adicionais. Por exemplo, considere SERVICE_CIDR=10.65.0.0/19 e POD_CIDR=10.64.0.0/19. Para mais informações, consulte Como adicionar intervalos de endereços IPv4 de pods.
Para executar os comandos kubectl nas próximas seções, conecte-se ao cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME --location=COMPUTE_REGION
```
Substitua:
- CLUSTER_NAME: o nome do cluster.
- COMPUTE_REGION: o nome da região de computação.
Para mais informações, consulte Instalar o kubectl e configurar o acesso ao cluster.

Criar uma política de carga de trabalho

Uma política de carga de trabalho é necessária para criar uma partição. Para mais informações, consulte Política de carga de trabalho para MIGs.

Crie uma política de carga de trabalho HIGH_THROUGHPUT com o campo accelerator_topology definido como 1x72.

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

Substitua:

WORKLOAD_POLICY_NAME: o nome da política de carga de trabalho.
PROJECT: o nome do projeto.
COMPUTE_REGION: o nome da região de computação.

Criar um pool de nós com o A4X Max

Crie o seguinte arquivo de configuração para pré-alocar páginas enormes com o pool de nós:

cat > node_custom.yaml <<EOF
linuxConfig:
  hugepageConfig:
    hugepage_size2m: 4096
EOF

export NODE_CUSTOM=node_custom.yaml

Crie um pool de nós A4X Max:
```
gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=COMPUTE_REGION \
    --node-locations=COMPUTE_ZONE \
    --num-nodes=NODE_COUNT \
    --placement-policy=WORKLOAD_POLICY_NAME \
    --machine-type=a4x-maxgpu-4g-metal \
    --accelerator=type=nvidia-gb300,count=4,gpu-driver-version=latest \
    --system-config-from-file=${NODE_CUSTOM} \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true,cloud.google.com/gke-dpv2-unified-cni=cni-migration \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUB_BLOCK_NAME
```
Substitua:
- NODE_POOL_NAME: o nome do pool de nós.
- CLUSTER_NAME: o nome do cluster.
- COMPUTE_REGION: a região de computação do cluster.
- COMPUTE_ZONE: a zona do pool de nós.
- NODE_COUNT: o número de nós do pool de nós, que precisa ser de 18 nós ou menos. Recomendamos o uso de 18 nós para conseguir a topologia de GPU de 1x72 em um sub-bloco usando um domínio NVLink.
- WORKLOAD_POLICY_NAME: o nome da política de carga de trabalho criada anteriormente.
- RESERVATION_NAME: o nome da reserva. Para encontrar esse valor, consulte Conferir solicitações de reserva adiantada.
- BLOCK_NAME: o nome de um bloco específico dentro da reserva. Para encontrar esse valor, consulte Conferir solicitações de reserva adiantada.
Esse comando cria automaticamente uma rede que conecta todos os nós A4X Max em uma única zona usando o perfil de rede do acelerador auto. Ao criar um pool de nós com a flag --accelerator-network-profile=auto, o GKE adiciona automaticamente o rótulo gke.networks.io/accelerator-network-profile: auto aos nós. Para programar cargas de trabalho nesses nós, é necessário incluir esse rótulo no campo nodeSelector da carga de trabalho.

Configurar as NICs MRDMA com `asapd-lite`

O DaemonSet asapd-lite configura as NICs MRDMA. Um DaemonSet asapd-lite não íntegro pode indicar que não há conectividade RDMA.

Instale o DaemonSet:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/asapd-lite-installer/asapd-lite-installer-a4x-max-bm-cos.yaml

Valide as réplicas no DaemonSet asapd-lite:

kubectl get daemonset -n kube-system asapd-lite

O resultado será assim:

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
asapd-lite   18        18        18      18           18          <none>          5m

O número de réplicas READY precisa corresponder ao número de nós criados e íntegros no pool de nós.

Instalar o CRD do domínio de computação da NVIDIA e o driver DRA

As etapas a seguir instalam o CRD do domínio de computação da NVIDIA e o driver DRA para permitir o uso do MNNVL. Para mais informações, consulte Driver DRA da NVIDIA para GPUs.

Verifique se o Helm está instalado no ambiente de desenvolvimento. O Helm vem pré-instalado no Cloud Shell.

Embora não haja um requisito específico de versão do Helm, você pode usar o comando abaixo para verificar se o Helm está instalado.
```
helm version
```
Se a saída for semelhante a Command helm not found, instale a CLI do Helm:
```
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && ./get_helm.sh
```

Adicione o repositório do Helm da NVIDIA:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

Crie um objeto ResourceQuota para o driver DRA:

export POD_QUOTA=POD_QUOTA

kubectl create ns nvidia-dra-driver-gpu

kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nvidia-dra-driver-gpu-quota
spec:
  hard:
    pods: ${POD_QUOTA}
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
        - system-node-critical
        - system-cluster-critical
EOF

Substitua POD_QUOTA por um número pelo menos duas vezes maior que o número de nós A4X Max no cluster mais 1. Por exemplo, é necessário definir a variável como pelo menos 37 se você tiver 18 nós A4X Max no cluster.

Instale o CRD do ComputeDomain e o driver DRA:

helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
    --set controller.args.v=4 --set kubeletPlugin.args.v=4 \
    --version="25.8.0" \
    --create-namespace \
    --namespace nvidia-dra-driver-gpu \
    -f <(cat <<EOF
nvidiaDriverRoot: /home/kubernetes/bin/nvidia
resources:
  gpus:
    enabled: false

controller:
  affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "nvidia.com/gpu"
              operator: "DoesNotExist"

kubeletPlugin:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: In
                values:
                  - nvidia-gb300
              - key: kubernetes.io/arch
                operator: In
                values:
                  - arm64

  tolerations:
    - key: nvidia.com/gpu
      operator: Equal
      value: present
      effect: NoSchedule
    - key: kubernetes.io/arch
      operator: Equal
      value: arm64
      effect: NoSchedule
EOF
)

Configurar o manifesto da carga de trabalho para o domínio RDMA e IMEX

Adicione uma regra de afinidade de nó para programar a carga de trabalho em nós do Arm:

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        -   matchExpressions:
          -   key: kubernetes.io/arch
            operator: In
            values:
            -   arm64

Adicione o seguinte volume à especificação do pod:

spec:
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia

Adicione as seguintes montagens de volume, variável de ambiente e recurso ao contêiner que solicita GPUs. O contêiner de carga de trabalho precisa solicitar todas as quatro GPUs:

containers:
  - name: my-container
    volumeMounts:
      - name: library-dir-host
        mountPath: /usr/local/nvidia

    env:
      - name: LD_LIBRARY_PATH
        value: /usr/local/nvidia/lib64
    resources:
      limits:
        nvidia.com/gpu: 4

Crie o recurso ComputeDomain para a carga de trabalho:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-max-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-max-compute-domain-channel

Substitua NUM_NODES pelo número de nós que a carga de trabalho exige.

Crie um ResourceClaimTemplate para alocar recursos de rede usando o DRANET e solicite dispositivos RDMA para o pod:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: all-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 8

Especifique o ResourceClaimTemplate que o pod usa:

spec:
  ...
  volumes:
    ...
  containers:
    - name: my-container
      ...
      resources:
        limits:
          nvidia.com/gpu: 4
  claims:
          - name: compute-domain-channel
          - name: rdma
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-max-compute-domain-channel
  - name: rdma
    resourceClaimTemplateName: all-mrdma

Instale as bibliotecas de espaço do usuário mais recentes na imagem do contêiner:

Debian 12+/Ubuntu 20.04+ (pacote .deb)

apt update
apt install curl

# Fetch DOCA OFED userspace libraries
export DOCA_URL="https://linux.mellanox.com/public/repo/doca/latest/ubuntu22.04/arm64-sbsa/"
export BASE_URL="https://linux.mellanox.com/public/repo/doca"
curl "${BASE_URL}/GPG-KEY-Mellanox.pub" | gpg --dearmor -o /etc/apt/trusted.gpg.d/GPG-KEY-Mellanox.pub
echo "deb [signed-by=/etc/apt/trusted.gpg.d/GPG-KEY-Mellanox.pub] ${DOCA_URL} ./" | tee /etc/apt/sources.list.d/doca.list

apt update
apt install doca-ofed-userspace

# Upgrade to latest NCCL for best compatibility
apt install --only-upgrade --allow-change-held-packages libnccl2 libnccl-dev

Uma especificação de pod completa tem esta aparência:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-max-compute-domain
spec:
  numNodes:  NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-max-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
  hostNetwork: true
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
          - name: rdma
        ...
  resourceClaims:
    - name: compute-domain-channel
      resourceClaimTemplateName: a4x-max-compute-domain-channel
    - name: rdma
      resourceClaimTemplateName: all-mrdma

Testar o desempenho da rede

Recomendamos validar a funcionalidade dos clusters provisionados. Para fazer isso, use os testes NCCL/gIB, que são testes da NVIDIA Collective Communications Library (NCCL) otimizados para o ambiente do Google.

Para mais informações, consulte Executar o NCCL em clusters personalizados do GKE que usam o A4X Max.

A seguir

Para saber como programar cargas de trabalho nos clusters do GKE usando o TAS e o Kueue, consulte Agendar cargas de trabalho do GKE com o Agendamento com reconhecimento de topologia.
Para saber como gerenciar eventos comuns relevantes para clusters do GKE e cargas de trabalho de IA, consulte Gerenciar clusters do GKE otimizados para IA.