Recursos de computação

Se você tiver interesse em clusters de treinamento do Gemini Enterprise Agent Platform, entre em contato com seu representante de vendas para ter acesso.

Os clusters de treinamento da plataforma de agentes do Gemini Enterprise são compatíveis com 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 Gemini Enterprise Agent Platform são compatíveis com o tipo de máquina otimizado para aceleradores A4X (a4x-highgpu-4g), uma plataforma de exaescala baseada na arquitetura de rack NVIDIA GB200 NVL72.

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 Estrita (compacta) 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 de domínios NVLink. Esses domínios são vinculados por uma política de posicionamento compacto estrita, e os blocos parcialmente alocados não podem ser usados 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:
    • Usar imagens compatíveis com ARM: todos os jobs de treinamento precisam usar uma imagem do contêiner criada para a arquitetura ARM.
    • Adaptar para 4 GPUs: a lógica de treinamento distribuído precisa ser atualizada para reconhecer e usar corretamente as 4 GPUs disponíveis em cada nó A4X.
  • Processo de relatórios de falhas de host e tempo de inatividade Ao informar um host como com falha, esteja ciente do 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 baseada em reparo: o nó permanece indisponível até que o host físico subjacente seja reparado.
    • Tempo de inatividade prolongado: esse processo de reparo geralmente leva de 3 a 14 dias.

Provisionamento de capacidade

A escolha do 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 a capacidade e é a opção recomendada para recursos de alta demanda.

  • FLEX_START: usa o programador dinâmico de cargas de trabalho 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. Ela fornece instâncias de VM padrão com preços previsíveis e de pagamento por uso.

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. Ele garante 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. FLEX_START enfileira seu job até que os recursos estejam disponíveis, enquanto SPOT oferece economia de custos significativa para jobs tolerantes a falhas que podem lidar com a preempção.

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

Como usar uma reserva compartilhada (opcional)

Se você quiser usar uma reserva compartilhada em vez de uma reserva local, será necessário realizar outras etapas antes de criar um cluster.

Antes de usar uma reserva compartilhada com clusters de treinamento da Gemini Enterprise Agent Platform, verifique se a reserva compartilhada funciona criando manualmente uma VM que use a reserva compartilhada. Se a criação da VM funcionar, avance 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.

  • Criar uma reserva do Compute Engine: o modelo RESERVATION é usado para alocar recursos de alta demanda, como GPUs. Aprenda a criar uma nova reserva no Compute Engine para ter acesso dedicado aos recursos necessários.
  • Criar o cluster de treinamento: aplique as configurações que você aprendeu seguindo o guia explicativo para criar seu primeiro cluster de treinamento persistente usando a API da Agent Platform ou gcloud.
  • Enviar 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 o cluster persistente para execução.
  • Adaptar o código para treinamento distribuído: para aproveitar ao máximo um cluster de vários nós, adapte o código de treinamento para um ambiente distribuído.