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

Neste documento, mostramos como criar um cluster do Google Kubernetes Engine (GKE) otimizado para IA que usa instâncias do Compute Engine A4X Max para dar suporte às suas 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 NVLink de vários nós (MNNVL) da NVIDIA, uma solução em escala 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 Recursos 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 uma 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 a carga operacional de gerenciar várias plataformas. É possível executar cargas de trabalho como pré-treinamento distribuído de alto desempenho, ajuste de modelos, inferência de modelos, disponibilizaçã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 a largura de banda de rede disponível de maneira mais eficiente. 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 o máximo de flexibilidade ao configurar o cluster com base nas necessidades da sua carga de trabalho. Para usar a CLI gcloud para criar clusters com outros tipos de máquina, consulte o seguinte:

Como alternativa, use 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 o Cluster Toolkit.

Antes de começar

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

  • Ative a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Para usar a Google Cloud CLI nesta tarefa, instale e 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.

Funções exigidas

Para receber as permissões necessárias para criar e gerenciar um cluster do GKE, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Obter capacidade

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

Para conseguir capacidade com uma reserva adiantada, consulte a linha Reservas adiantadas no Hipercomputador de IA na tabela 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, use uma das seguintes versões:

    • Para a versão 1.35 ou mais recente, use o GKE versão 1.35.0-gke.2745000 ou mais recente.
    • Para a versão 1.34, use o GKE 1.34.3-gke.1318000 ou mais recente.

    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 o 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 que o SO coloque a memória da GPU on-line e a expõe como um nó de acesso não uniforme à memória (NUMA) 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 o CDMM, consulte Suporte de hardware e software.
    • GPUDirect RDMA e MNNVL, que são recomendados para permitir que os pools de nós do 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.

  • É preciso 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 a 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 de cluster:
    • Verifique se você está usando 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, use a flag --node-locations 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: instale 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: instale 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: pula a instalação automática do driver. Você precisa instalar manualmente um driver 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 drivers de GPU NVIDIA.

  • Escolha uma afinidade de reserva:

    • É possível encontrar informações sobre sua reserva, como o nome dela ou de um bloco específico. Para encontrar esses valores, consulte Ver solicitações de reserva adiantada.
    • A flag --reservation-affinity pode assumir os valores de specific ou any. No entanto, para cargas de trabalho de IA distribuídas de alto desempenho, recomendamos usar 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 projeto Google Cloud .
      • RESERVATION_NAME: o nome da sua reserva.
      • BLOCK_NAME: o nome de um bloco específico na reserva.

      Também recomendamos que você use uma reserva com destino de 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.

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 geralmente são 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 e 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 o escalonamento e a 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, siga as etapas descritas nas seções a seguir:

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

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

Criar o cluster do GKE

  1. 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 [\
  --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 é compatível com sua configuração, consulte os Requisitos neste documento.
    • COMPUTE_REGION: o nome da região de computação.

    • Se quiser, você pode fornecer explicitamente os intervalos 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, verifique se os intervalos CIDR não se sobrepõem aos intervalos de sub-rede de outras redes de nós. 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 pod.

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

  1. Crie o seguinte arquivo de configuração para pré-alocar hugepages com o pool de nós:

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

export NODE_CUSTOM=node_custom.yaml

  2. Crie um pool de nós A4X Max. A flag --accelerator-network-profile=auto cria automaticamente uma rede que conecta todos os nós do A4X Max em uma única zona:

    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 usar 18 nós para obter 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 que você criou anteriormente.
    • RESERVATION_NAME: o nome da sua reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantada.
    • BLOCK_NAME: o nome de um bloco específico dentro da reserva. Para encontrar esse valor, consulte Ver solicitações de reserva adiantada.

Configurar as NICs de 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.

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

  2. Valide as réplicas no DaemonSet asapd-lite:

    kubectl get daemonset -n kube-system asapd-lite

    O resultado será o seguinte:

    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 de READY precisa corresponder ao número de nós que foram criados e estão íntegros no pool de nós.

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

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

  1. 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, será possível instalar 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

  2. Adicione o repositório do Helm da NVIDIA:

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

  3. Crie um objeto ResourceQuota para o driver de 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 que seja pelo menos duas vezes o número de nós A4X Max no cluster mais um. Por exemplo, você precisa definir a variável como pelo menos 37 se tiver 18 nós A4X Max no cluster.

  4. Instale o CRD ComputeDomain e o driver de 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

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

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

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

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

  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.

  5. Crie um ResourceClaimTemplate para alocar recursos de rede usando 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

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

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

Teste a performance das redes

Recomendamos que você valide a funcionalidade dos clusters provisionados. Para 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 a NCCL em clusters do GKE que usam o A4X Max.

A seguir