Recursos de computação

Se você tiver interesse nos clusters de treinamento da Vertex AI, entre em contato com seu representante de vendas para ter acesso.

Os clusters de treinamento da Vertex AI oferecem suporte a vários tipos de máquinas para acomodar diferentes cargas de trabalho. É possível escolher entre as seguintes opções ao configurar os pools de nós do cluster:

  • a4-highgpu-8g
  • a4x-highgpu-4g
  • a3-ultragpu-8g
  • a3-megagpu-8g
  • Família de CPUs n2

Tipo de máquina A4X

Os clusters de treinamento da Vertex AI são compatíveis com o tipo de máquina otimizado para acelerador A4X (a4x-highgpu-4g), uma plataforma de exaescala baseada na arquitetura NVIDIA GB200 NVL72 em escala de rack.

Comparação de arquitetura

A tabela a seguir descreve as diferenças fundamentais de hardware entre a família A4X e outras famílias otimizadas para aceleradores.

Recurso A4X (a4x-highgpu-4g) A3 / A4H
Arquitetura da CPU ARM X86
Contagem de GPUs 4 GPUs por nó 8 GPUs por nó
Tipo de reserva Modo de capacidade total Modo gerenciado
Política de posicionamento Estrito (compacto) Flexível

Diretrizes específicas do A4X

  • A contagem de VMs do pool de nós A4X precisa ser um múltiplo de 18 (por exemplo, 18, 36, 54). Isso é necessário porque a capacidade do A4X é provisionada em blocos fixos e não compartilháveis de 18 nós chamados domínios NVLink. Esses domínios estão vinculados a uma política de posição compacta estrita, e nenhum bloco parcialmente alocado pode ser usado por outros clusters.
  • Devido à arquitetura baseada em ARM dos nós A4X, é necessário fazer duas mudanças importantes nas cargas de trabalho de treinamento:
    • Use imagens compatíveis com ARM: todos os jobs de treinamento precisam usar uma imagem de contêiner criada para a arquitetura ARM.
    • Adapte para quatro GPUs: sua lógica de treinamento distribuído precisa ser atualizada para reconhecer e usar corretamente as quatro GPUs disponíveis em cada nó A4X.
  • Processo de relatório de falhas do host e tempo de inatividade Ao informar que um host está com falha, fique atento ao seguinte processo de recuperação:
    • Sem capacidade de espera: o sistema não usa um pool de espera para uma substituição instantânea de nós.
    • Recuperação com base em reparo: o nó permanece indisponível até que o host físico subjacente seja reparado.
    • Tempo de inatividade prolongado: esse processo de reparo normalmente leva de 3 a 14 dias.

Provisionamento de capacidade

Escolher o modelo de provisionamento certo é fundamental para equilibrar custo, velocidade e disponibilidade de recursos. Confira as seguintes opções de provisionamento:

  • RESERVATION: aloca nós de uma reserva específica do Compute Engine que você criou com antecedência. Esse modelo garante capacidade e é a opção recomendada para recursos de alta demanda.

  • FLEX_START: usa o Dynamic Workload Scheduler para enfileirar seu job. O job começa automaticamente assim que os recursos de computação solicitados ficam disponíveis, oferecendo um horário de início flexível sem exigir uma reserva.

  • SPOT: provisiona o pool de nós usando VMs spot. Essa é a opção mais econômica, mas só deve ser usada para cargas de trabalho tolerantes a falhas e que podem lidar com interrupções, já que as VMs podem ser preemptivas a qualquer momento.

  • ON_DEMAND: essa é a opção padrão para pools de nós somente de CPU e é mais adequada para tipos de máquinas que não são escassos. Ele oferece instâncias de VM padrão com preços previsíveis de pagamento por utilização.

Use as orientações a seguir para fazer sua seleção:

  • Para recursos de GPU de alta demanda (como A3 e A4): o modelo RESERVATION é altamente recomendado. Isso garante que você tenha acesso dedicado à capacidade necessária para jobs de treinamento críticos.

  • Para cargas de trabalho flexíveis ou com picos: considere FLEX_START ou SPOT. O FLEX_START coloca seu job em fila até que os recursos estejam disponíveis, enquanto o SPOT oferece uma economia significativa de custos para jobs tolerantes a falhas que podem lidar com preempção.

  • Para tipos de máquinas abundantes: o modelo ON_DEMAND é a opção preferida. Use para tipos de máquina que não são escassos e em que a disponibilidade imediata não é uma preocupação.

Usar uma reserva compartilhada (opcional)

Se você quiser usar uma reserva compartilhada em vez de uma local, há outras etapas a serem seguidas antes de criar um cluster.

Antes de usar uma reserva compartilhada com clusters de treinamento da Vertex AI, verifique se ela funciona criando manualmente uma VM que a use. Se a criação da VM funcionar, siga para a próxima etapa. Na configuração de criação do cluster, use o nome da reserva no seguinte formato: projects/RESERVATION_HOST_PROJECT_ID/zones/RESERVATION_ZONE/reservations/RESERVATION_NAME.

A seguir

Depois de selecionar as opções de computação e provisionamento para o cluster de treinamento, você estará pronto para criar o cluster e executar uma carga de trabalho nele.

  • Crie uma reserva do Compute Engine: o modelo RESERVATION é usado para alocar recursos de alta demanda, como GPUs. Saiba como criar uma reserva no Compute Engine para ter acesso dedicado aos recursos necessários.
  • Crie seu cluster de treinamento: siga o guia detalhado para criar seu primeiro cluster de treinamento persistente usando a API Vertex AI ou gcloud.
  • Envie um job de treinamento para o cluster: depois que o cluster estiver ativo, a próxima etapa será executar uma carga de trabalho. Envie um CustomJob que tenha como destino seu cluster permanente para execução.
  • Adapte seu código para treinamento distribuído: para aproveitar ao máximo um cluster de vários nós, adapte seu código de treinamento para um ambiente distribuído.