Criar um cluster do GKE otimizado para IA com configuração padrão

Nesta página, mostramos como criar seu próprio cluster do Google Kubernetes Engine (GKE) otimizado para IA que usa máquinas virtuais (VMs) A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs) para oferecer suporte às suas cargas de trabalho de IA e ML.

As séries de máquinas A4X, A4, A3 Ultra, A3 Mega e A3 High (8 GPUs) foram projetadas para permitir executar clusters de IA/ML em grande escala com recursos como posicionamento de carga de trabalho direcionado, controles avançados de manutenção de cluster e programação com reconhecimento de topologia. Para mais informações, consulte Visão geral do gerenciamento de clusters.

O GKE oferece uma única plataforma para executar um conjunto diversificado de cargas de trabalho para as necessidades da sua organização. Isso inclui pré-treinamento distribuído de alto desempenho, ajuste fino e inferência de modelos, disponibilização de aplicativos e serviços de suporte. O GKE reduz a carga operacional de gerenciar várias plataformas.

Escolher como criar um cluster do GKE otimizado para IA

As opções a seguir para criação de clusters oferecem diferentes graus de facilidade e flexibilidade na configuração de clusters e no agendamento de cargas de trabalho:

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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.
  • Verifique se você tem as permissões necessárias para criar e gerenciar o cluster do GKE e as contas de serviço associadas:
    • Administrador do Kubernetes Engine (roles/container.admin)
    • Administrador do Compute (roles/compute.admin)
    • Administrador do Storage (roles/storage.admin)
    • Administrador de IAM do projeto (roles/resourcemanager.projectIamAdmin)
    • Administrador da conta de serviço (roles/iam.serviceAccountAdmin)
    • Usuário da conta de serviço (roles/iam.serviceAccountUser)
    • Consumidor do Service Usage (roles/serviceusage.serviceUsageConsumer)
    • Administrador de papéis (roles/iam.roleAdmin)
    • Gerenciador de versões de secret do Secret Manager (roles/secretmanager.secretVersionManager)

Escolher uma opção de consumo e obter capacidade

  1. Escolha uma opção de consumo. Faça sua escolha com base em como você quer receber e usar recursos de GPU. Para saber mais, consulte Escolher uma opção de consumo.

    Para o GKE, considere as seguintes informações adicionais ao escolher uma opção de consumo:

  2. Obter capacidade. O processo para conseguir capacidade varia de acordo com cada opção de consumo.

    Para saber mais sobre o processo da opção de consumo escolhida, consulte Visão geral da capacidade.

Requisitos

Os seguintes requisitos se aplicam a um cluster do GKE otimizado para IA:

  • Para o A4X, use a versão 1.33.4-gke.1036000 ou mais recente do GKE para a versão 1.33 ou mais recente. Ou, para a versão 1.32, use o GKE versão 1.32.8-gke.1108000 ou mais recente. Essas versões garantem que o A4X use o seguinte:

    • R580, a versão mínima do driver da GPU para A4X.
    • Gerenciamento de memória coerente baseado em driver (CDMM), 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 on-line 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) para o SO. Não há suporte para GPUs de várias instâncias quando o CDMM está ativado. Para mais informações sobre o CDMM, consulte Suporte de hardware e software.
    • GPUDirect RDMA, recomendado para permitir que os pools de nós A4X usem os recursos de rede do A4X.

  • Use a versão mínima do driver de GPU, dependendo do tipo de máquina:

    • A4X: as GPUs GB200 em VMs A4X exigem no mínimo a versão R580 do driver de GPU. Consulte os requisitos de versão mencionados anteriormente.
    • A4: as GPUs B200 em VMs A4 exigem uma versão mínima do driver de GPU R570. Por padrão, o GKE instala automaticamente essa versão do driver em todos os nós A4 que executam a versão mínima necessária para A4, 1.32.1-gke.1729000 ou mais recente.
    • A3 Ultra: as GPUs H200 nas VMs A3 Ultra exigem uma versão mínima do driver de GPU R550, que está disponível no GKE 1.31 como a versão do driver latest. Para o A3 Ultra, é necessário definir gpu-driver-version=latest com o GKE 1.31. Para o GKE versão 1.31.5-gke.1169000 ou mais recente, o GKE instala automaticamente, por padrão, as versões do driver de GPU R550 nos nós A3 Ultra.

  • Para pools de nós A3 Ultra, defina o tipo de disco como hyperdisk-balanced.

  • Para usar o GPUDirect RDMA, use as seguintes versões mínimas, dependendo do tipo de máquina:

    • A4X: consulte os requisitos de versão mencionados anteriormente.
    • A4: use a versão 1.32.2-gke.1475000 ou mais recente.
    • A3 Ultra: use a versão 1.31.4-gke.1183000 ou mais recente.

  • Para usar o GPUDirect RDMA, 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.

  • Você precisa usar o modelo de provisionamento vinculado à reserva para criar clusters com o A4X. Outros modelos de provisionamento não são compatíveis.

Criar um cluster

Use as instruções a seguir para criar um cluster usando o Cluster Toolkit ou o XPK.

Criar um cluster usando o Cluster Toolkit

Esta seção orienta você no processo de criação de cluster, garantindo que seu projeto siga as práticas recomendadas e atenda aos requisitos de um cluster do GKE otimizado para IA.

A4X

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas recomendamos o Cloud Shell porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Clone o Cluster Toolkit do repositório git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Instale o Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. Crie um bucket do Cloud Storage para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  5. No blueprint examples/gke-a4x/gke-a4x-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

    • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4x.
    • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION: a região de computação do cluster.
    • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A4X. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • NODE_COUNT: o número de nós A4X no pool de nós do cluster, que precisa ser de 18 nós ou menos. Recomendamos usar 18 nós para obter a topologia de GPU de 1x72 em um subbloco usando um domínio NVLink.
    • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir que se conecte ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.

    • Para o campo extended_reservation, use uma das seguintes opções, dependendo se você quer segmentar blocos específicos em uma reserva ao provisionar o pool de nós:

      • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua reserva, use os nomes da reserva e do bloco no seguinte formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver uma topologia de reserva.

    • Defina os tamanhos dos discos de inicialização para cada nó do sistema e pools de nós A4X. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 200.
      • A4X_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A4X. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    Para modificar as configurações avançadas, edite o arquivo examples/gke-a4x/gke-a4x.yaml.

  6. Se quiser, ative o Cluster Health Scanner (CHS) no cluster. O CHS verifica a integridade dos clusters de GPU executando testes para verificar se eles estão prontos para executar suas cargas de trabalho. Para ativar o CHS, faça as seguintes mudanças no arquivo examples/gke-a4x/gke-a4x-deployment.yaml:

    • No bloco vars, defina o campo enable_periodic_health_checks como true.

    • Por padrão, as verificações de integridade são executadas todos os domingos às 12h (horário do Pacífico). Se quiser mudar essa configuração, no bloco vars, defina o campo health_check_schedule com um valor adequado, no formato cron.
      Programação no formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Gere as credenciais padrão do aplicativo (ADC) para dar acesso ao Terraform. Se você estiver usando o Cloud Shell, execute o seguinte comando:

    gcloud auth application-default login

  8. Implante o blueprint para provisionar a infraestrutura do GKE usando tipos de máquina A4X:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4x/gke-a4x-deployment.yaml \
examples/gke-a4x/gke-a4x.yaml

  9. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A4

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas recomendamos o Cloud Shell porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Clone o Cluster Toolkit do repositório git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Instale o Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. Crie um bucket do Cloud Storage para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  5. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

    • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4.
    • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION: a região de computação do cluster.
    • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A4. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • NODE_COUNT: o número de nós A4 no cluster.
    • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.

    • Para o campo reservation, use uma das seguintes opções, dependendo se você quer segmentar blocos específicos em uma reserva ao provisionar o pool de nós:

      • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua reserva, use os nomes da reserva e do bloco no seguinte formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver uma topologia de reserva.

    • Defina os tamanhos dos discos de inicialização para cada nó do sistema e pools de nós A4. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
      • A4_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A4. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    Para modificar as configurações avançadas, edite examples/gke-a4/gke-a4.yaml.

    Início flexível

    1. No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

      • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4.
      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A4.
      • Remova static_node_count.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Remova o campo reservation e substitua-o por enable_flex_start: true. Adicione na próxima linha enable_queued_provisioning: true se você também quiser usar o provisionamento em fila. Para mais informações, consulte Usar pools de nós com flex-start com provisionamento em fila.

      • Defina os tamanhos dos discos de inicialização para cada nó do sistema e pools de nós A4. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
        • A4_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A4. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    2. No blueprint examples/gke-a4/gke-a4.yaml do repositório do GitHub, faça as seguintes mudanças:

      • No bloco vars, remova static_node_count.
      • No bloco vars, verifique se o número version_prefix é "1.32." ou mais recente. Para usar o flex-start no GKE, seu cluster precisa usar a versão 1.32.2-gke.1652000 ou mais recente.
      • No bloco vars, substitua todo o bloco reservation (incluindo a linha reservation) por enable_flex_start: true e, opcionalmente, enable_queued_provisioning: true.
      • No bloco vars, se você não precisar do provisionamento em fila, remova a seguinte linha: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Em id: a4-pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a4-pool, remova o bloco reservation_affinity. Substitua este bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se quiser ativar, adicione as seguintes linhas:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Em id: workload-manager-install, remova o seguinte bloco:

         kueue:
    install: true
    config_path: $(vars.kueue_configuration_path)
    config_template_vars:
       num_gpus: $(a3-ultragpu-pool.static_gpu_count)
       accelerator_type: $(vars.accelerator_type)

        • Para início flexível com provisionamento em fila, faça o seguinte:

          1. Adicione gpu_nominal_quota: NOMINAL_QUOTA ao bloco vars. O valor gpu_nominal_quota é usado para definir o nominalQuota de GPUs na especificação ClusterQueue (a seguir, consulte a etapa de configuração de ClusterQueue). Neste exemplo, o ClusterQueue só aceita cargas de trabalho se a soma das solicitações de GPU for menor ou igual ao valor NOMINAL_QUOTA. Para mais informações sobre ClusterQueue, consulte o seguinte documento do Kueue sobre a fila de cluster.

          2. Atualize o bloco kueue para:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Substitua o conteúdo do arquivo kueue-configuration.yaml.tftpl pelo seguinte:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

      • Em id: job-template, substitua a variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a4/gke-a4-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

      • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar. O valor padrão é gke-a4.
      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A4.
      • STATIC_NODE_COUNT: o número de nós A4 no cluster.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Substitua todo o bloco reservation (incluindo a linha reservation) por spot: true.

      • Defina os tamanhos dos discos de inicialização para cada nó do sistema e pools de nós A4. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
        • A4_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A4. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    2. No blueprint examples/gke-a4/gke-a4.yaml do repositório do GitHub, faça as seguintes mudanças:

      • No bloco vars, substitua todo o bloco reservation (incluindo a linha reservation) por spot: true.

      • Em id: a4-pool, remova o bloco reservation_affinity. Substitua este bloco pela seguinte linha:

        • spot: $(vars.spot)

  6. Se quiser, ative o Cluster Health Scanner (CHS) no cluster. O CHS verifica a integridade dos clusters de GPU executando testes para verificar se eles estão prontos para executar suas cargas de trabalho. Para ativar o CHS, faça as seguintes mudanças no arquivo examples/gke-a4/gke-a4-deployment.yaml:

    • No bloco vars, defina o campo enable_periodic_health_checks como true.

    • Por padrão, as verificações de integridade são executadas todos os domingos às 12h (horário do Pacífico). Se quiser mudar essa configuração, no bloco vars, defina o campo health_check_schedule com um valor adequado, no formato cron.
      Programação no formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Gere as credenciais padrão do aplicativo (ADC) para dar acesso ao Terraform. Se você estiver usando o Cloud Shell, execute o seguinte comando:

    gcloud auth application-default login

  8. Implante o blueprint para provisionar a infraestrutura do GKE usando tipos de máquina A4:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a4/gke-a4-deployment.yaml \
examples/gke-a4/gke-a4.yaml

  9. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

A3 Ultra

  1. Inicie o Cloud Shell. Você pode usar um ambiente diferente, mas recomendamos o Cloud Shell porque as dependências já estão pré-instaladas para o Cluster Toolkit. Se você não quiser usar o Cloud Shell, siga as instruções para instalar dependências e preparar um ambiente diferente.

  2. Clone o Cluster Toolkit do repositório git:

    cd ~
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git

  3. Instale o Cluster Toolkit:

    cd cluster-toolkit && git checkout main && make

  4. Crie um bucket do Cloud Storage para armazenar o estado da implantação do Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
    --default-storage-class=STANDARD \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION_TERRAFORM_STATE \
    --uniform-bucket-level-access
gcloud storage buckets update gs://BUCKET_NAME --versioning

    Substitua as seguintes variáveis:

    • BUCKET_NAME: o nome do novo bucket do Cloud Storage.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION_TERRAFORM_STATE: a região de computação em que você quer armazenar o estado da implantação do Terraform.

  5. Os arquivos que você precisa editar para criar um cluster dependem da opção de consumo que está usando para sua implantação. Selecione a guia que corresponde ao modelo de provisionamento da sua opção de consumo.

    Vinculada à reserva

    No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, substitua as seguintes variáveis nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

    • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar.
    • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • COMPUTE_REGION: a região de computação do cluster.
    • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra. Essa zona precisa corresponder à zona em que as máquinas estão disponíveis na sua reserva.
    • NODE_COUNT: o número de nós A3 Ultra no cluster.
    • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.

    • Para o campo reservation, use uma das seguintes opções, dependendo se você quer segmentar blocos específicos em uma reserva ao provisionar o pool de nós:

      • Para colocar o pool de nós em qualquer lugar da reserva, forneça o nome dela (RESERVATION_NAME).

      • Para segmentar um bloco específico na sua reserva, use os nomes da reserva e do bloco no seguinte formato:

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME

      Se você não souber quais blocos estão disponíveis na sua reserva, consulte Ver uma topologia de reserva.

    • Defina os tamanhos dos discos de inicialização para cada nó dos pools de nós do sistema e A3 Ultra. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

      • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
      • A3ULTRA_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A3 Ultra. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    Para modificar as configurações avançadas, edite examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Início flexível

    1. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, substitua as seguintes variáveis nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

      • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar.
      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra.
      • Remova static_node_count.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como as redes autorizadas funcionam.
      • Remova o campo reservation e substitua-o por enable_flex_start: true. Adicione na próxima linha enable_queued_provisioning: true se você também quiser usar o provisionamento em fila. Para mais informações, consulte Usar pools de nós com flex-start com provisionamento em fila.

      • Defina os tamanhos dos discos de inicialização para cada nó dos pools de nós do sistema e A3 Ultra. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A3 Ultra. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    2. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml do repositório do GitHub, faça as seguintes mudanças:

      • No bloco vars, remova static_node_count.
      • No bloco vars, atualize o número version_prefix para "1.32." ou mais recente. Para usar o flex-start no GKE, seu cluster precisa usar a versão 1.32.2-gke.1652000 ou mais recente.
      • No bloco vars, substitua todo o bloco reservation (incluindo a linha reservation) por enable_flex_start: true e, opcionalmente, enable_queued_provisioning: true.
      • No bloco vars, remova a seguinte linha: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • Em id: a3-ultragpu-pool, remova a seguinte linha: static_node_count: $(vars.static_node_count).

      • Em id: a3-ultragpu-pool, remova o bloco reservation_affinity. Substitua este bloco pelas seguintes linhas:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • Para o provisionamento em fila, se quiser ativar, adicione as seguintes linhas:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0

      • Em id: workload-manager-install, remova o seguinte bloco:

        config_path: $(vars.kueue_configuration_path)
config_template_vars:
  num_gpus: $(a4-pool.static_gpu_count)
  accelerator_type: $(vars.accelerator_type)

        • Para o início flexível com provisionamento em fila, siga estas três etapas:

          1. Adicione gpu_nominal_quota: NOMINAL_QUOTA ao bloco vars. O valor gpu_nominal_quota é usado para definir o nominalQuota de GPUs na especificação ClusterQueue. Neste exemplo, o ClusterQueue só aceita cargas de trabalho se a soma das solicitações de GPU for menor ou igual ao valor de NOMINAL_QUOTA. Para mais informações sobre ClusterQueue, consulte o seguinte documento do Kueue sobre a fila de cluster.

          2. Atualize o bloco kueue para:

            kueue:
   install: true
   config_path: $(vars.kueue_configuration_path)
   config_template_vars:
      num_gpus: $(vars.gpu_nominal_quota)

          3. Substitua o conteúdo do arquivo kueue-configuration.yaml.tftpl pelo seguinte:

            apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
   name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
   name: dws-prov
spec:
   controllerName: kueue.x-k8s.io/provisioning-request
   parameters:
      apiGroup: kueue.x-k8s.io
      kind: ProvisioningRequestConfig
      name: dws-config
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ProvisioningRequestConfig
metadata:
   name: dws-config
spec:
   provisioningClassName: queued-provisioning.gke.io
   managedResources:
   - nvidia.com/gpu
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
   name: "dws-cluster-queue"
spec:
   namespaceSelector: {}
   resourceGroups:
   - coveredResources: ["nvidia.com/gpu"]
      flavors:
      - name: "default-flavor"
      resources:
      - name: "nvidia.com/gpu"
         nominalQuota: ${num_gpus}
   admissionChecks:
   - dws-prov
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
   namespace: "default"
   name: "dws-local-queue"
spec:
   clusterQueue: "dws-cluster-queue"
---

        • No campo id: job-template, substitua a variável node_count por 2.

    Spot

    1. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml do repositório do GitHub, preencha as seguintes configurações nas seções terraform_backend_defaults e vars para corresponder aos valores específicos da sua implantação:

      • DEPLOYMENT_NAME: um nome exclusivo para o implantação, que precisa ter entre 6 e 30 caracteres. Se o nome da implantação não for exclusivo em um projeto, a criação do cluster vai falhar.
      • BUCKET_NAME: o nome do bucket do Cloud Storage criado na etapa anterior.
      • PROJECT_ID: o ID do projeto Google Cloud .
      • COMPUTE_REGION: a região de computação do cluster.
      • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra.
      • STATIC_NODE_COUNT: o número de nós A3 Ultra no cluster.
      • IP_ADDRESS/SUFFIX: o intervalo de endereços IP que você quer permitir para se conectar ao cluster. Esse bloco CIDR precisa incluir o endereço IP da máquina que você quer usar para chamar o Terraform. Para mais informações, consulte Como funcionam as redes autorizadas.
      • Substitua todo o bloco reservation (incluindo a linha reservation) por spot: true.

      • Defina os tamanhos dos discos de inicialização para cada nó dos pools de nós do sistema e A3 Ultra. O tamanho do disco necessário depende do seu caso de uso. Por exemplo, se você usar o disco como um cache para reduzir a latência de extrair uma imagem repetidamente, poderá definir um tamanho maior para acomodar seu framework, modelo ou imagem de contêiner:

        • SYSTEM_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós do sistema. O menor tamanho de disco permitido é 10. O valor padrão é 100.
        • A3ULTRA_NODE_POOL_DISK_SIZE_GB: o tamanho do disco de inicialização para cada nó do pool de nós A3 Ultra. O menor tamanho de disco permitido é 10. O valor padrão é 100.

    2. No blueprint examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml do repositório do GitHub, faça as seguintes mudanças:

      • No bloco vars, substitua todo o bloco reservation (incluindo a linha reservation) por spot: true.

      • Em id: a3-ultragpu-pool, remova o bloco reservation_affinity. Substitua este bloco pela seguinte linha:

        • spot: $(vars.spot)

  6. Se quiser, ative o Cluster Health Scanner (CHS) no cluster. O CHS verifica a integridade dos clusters de GPU executando testes para verificar se eles estão prontos para executar suas cargas de trabalho. Para ativar o CHS, faça as seguintes mudanças no arquivo examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml:

    • No bloco vars, defina o campo enable_periodic_health_checks como true.

    • Por padrão, as verificações de integridade são executadas todos os domingos às 12h (horário do Pacífico). Se quiser mudar essa configuração, no bloco vars, defina o campo health_check_schedule com um valor adequado, no formato cron.
      Programação no formato cron: none * * * * * # | | | | | # | | | | day of the week (0-6) (Sunday to Saturday) # | | | month (1-12) # | | day of the month (1-31) # | hour (0-23) # minute (0-59)

  7. Gere Application Default Credentials (ADC) para fornecer acesso ao Terraform. Se você estiver usando o Cloud Shell, execute o comando a seguir:

    gcloud auth application-default login

  8. Implante o blueprint para provisionar a infraestrutura do GKE usando tipos de máquina A3 Ultra:

    cd ~/cluster-toolkit
./gcluster deploy -d \
examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml

  9. Quando solicitado, selecione (A)plicar para implantar o blueprint.

    • O blueprint cria redes VPC, uma rede VPC de RDMA de GPU, contas de serviço, um cluster e um pool de nós.
    • Para oferecer suporte ao modelo de job fio-bench-job-template no blueprint, os recursosGoogle Cloud buckets, armazenamento de rede e volumes permanentes são criados.

Criar um cluster e executar cargas de trabalho usando o XPK

O Accelerated Processing Kit (XPK) permite provisionar e usar clusters rapidamente. O XPK gera uma infraestrutura pré-configurada e otimizada para treinamento, ideal quando a execução da carga de trabalho é seu foco principal.

Crie um cluster e execute cargas de trabalho com VMs A3 Ultra usando o XPK:

  1. Instale as ferramentas necessárias para atender aos pré-requisitos do XPK.
  2. Copie o número da versão do lançamento mais recente com tag do XPK, por exemplo, "v0.8.0". No comando a seguir, substitua XPK_TAG pelo número da versão mais recente do XPK.

  3. Abra uma janela de shell em uma máquina Linux e insira os comandos a seguir para clonar o XPK do repositório Git e instalar os pacotes necessários:

      ## Setup virtual environment.
  VENV_DIR=~/venvp3
  python3 -m venv $VENV_DIR
  source $VENV_DIR/bin/activate
  ## Clone the repository.
  git clone --branch XPK_TAG https://github.com/google/xpk.git
  cd xpk
  ## Install required packages
  make install && export PATH=$PATH:$PWD/bin

  4. Crie um cluster Standard usando VMs A3 Ultra. É possível provisionar os nós do cluster usando a capacidade reservada:

      python3 xpk.py cluster create \
     --cluster=CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --zone=COMPUTE_ZONE  \
     --project=PROJECT_ID \
     --num-nodes=NUM_NODES \
     --reservation=RESERVATION_NAME

    Substitua as seguintes variáveis:

    • CLUSTER_NAME: um nome para o cluster.
    • COMPUTE_ZONE: a zona do Compute para o pool de nós de máquinas A3 Ultra. Para usar a capacidade reservada, verifique se você está usando a zona em que fez a reserva. Em geral, recomendamos escolher uma zona perto do usuário para minimizar a latência.
    • PROJECT_ID: o ID do projeto Google Cloud .
    • NUM_NODES: o número de nós de trabalho no pool de nós.

    • RESERVATION_NAME: o nome da sua reserva.

      O XPK oferece outros argumentos para a criação de clusters, incluindo aqueles para criar clusters particulares, criar painéis do TensorBoard da Vertex AI e usar o provisionamento automático de nós. Para mais informações, consulte o guia de criação de cluster para XPK.

  5. Verifique se o cluster foi criado com sucesso:

      python3 xpk.py cluster list --zone=COMPUTE_ZONE --project=PROJECT_ID

  6. Opcional: execute uma carga de trabalho para testar o ambiente do cluster:

      python3 xpk.py workload create \
     --workload WORKLOAD_NAME --command "echo goodbye" \
     --cluster CLUSTER_NAME \
     --device-type=h200-141gb-8 \
     --num-nodes=WORKLOAD_NUM_NODES \
     --zone=COMPUTE_ZONE \
     --project=PROJECT_ID

    Substitua as seguintes variáveis:

    • WORKLOAD_NAME: nome da carga de trabalho.
    • CLUSTER_NAME: o nome do cluster.
    • WORKLOAD_NUM_NODES: número de nós de worker usados para a execução da carga de trabalho.
    • COMPUTE_ZONE: a zona de computação para o pool de nós de máquinas A3 Ultra.
    • PROJECT_ID: o Google Cloud ID do projeto.

Testar o desempenho da rede

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.

Executar comparativos reproduzíveis

É possível reproduzir comparativos de pré-treinamento para modelos de machine learning abertos grandes em VMs A4 e A3 Ultra no GKE.

Cada receita fornece instruções para concluir as seguintes tarefas:

  • Prepare seu ambiente.
  • Execute o comparativo.
  • Analise os resultados das comparativas de mercado. Isso inclui os resultados do comparativo de mercado e registros detalhados para análise mais detalhada.

Para conferir todas as receitas disponíveis, consulte o repositório do GitHub de receitas de GPU.

Modelos Framework Roteiro
Llama-3.1-70B MaxText Carga de trabalho de 32 nós
Llama-3.1-70B NeMo Carga de trabalho de 32 nós
Mixtral 8x7B NeMo Carga de trabalho de 32 nós

Limpar os recursos criados pelo Cluster Toolkit

Para evitar cobranças recorrentes pelos recursos usados nesta página, limpe os recursos provisionados pelo Cluster Toolkit, incluindo as redes VPC e o cluster do GKE:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

Substitua CLUSTER_NAME pelo nome do cluster. Para os clusters criados com o Cluster Toolkit, o nome do cluster é baseado no DEPLOYMENT_NAME.

A seguir