Sobre o provisionamento de GPU e TPU com o modo de provisionamento de início flexível

Nesta página, descrevemos o modo de provisionamento flexível de início no Google Kubernetes Engine (GKE). O início flexível, com tecnologia do Programador Dinâmico de Cargas de Trabalho, oferece uma técnica flexível e econômica para obter GPUs e TPUs quando você precisa executar cargas de trabalho de IA/ML.

Com o início flexível, é possível provisionar GPUs e TPUs de forma dinâmica conforme necessário, por até sete dias, sem estar vinculado a um horário de início específico e sem o gerenciamento de reservas de longo prazo. Portanto, o início flexível funciona bem para cargas de trabalho de pequeno a médio porte com requisitos de demanda flutuantes ou durações curtas. Por exemplo, pré-treinamento de modelo pequeno, ajuste de detalhes do modelo ou modelos de exibição escalonáveis.

As informações nesta página podem ajudar você a fazer o seguinte:

• Entenda como o flex-start funciona no GKE.
• Decida se o flex-start é adequado para sua carga de trabalho.
• Decida qual configuração de início flexível é adequada para sua carga de trabalho.
• Gerenciar interrupções ao usar o flex-start.
• Entenda as limitações do flex-start no GKE.

Esta página é destinada a administradores e operadores de plataforma e engenheiros de machine learning (ML) que querem otimizar a infraestrutura de aceleradores para as cargas de trabalho.

Quando usar flex-start

Recomendamos que você use flex-start se as cargas de trabalho atenderem a todas as condições a seguir:

• Suas cargas de trabalho exigem recursos de GPU.
• Suas cargas de trabalho exigem recursos de TPU executados em pools de nós de fração de TPU de host único.
• Sua capacidade de GPU ou TPU é limitada ou não reservada e você precisa de um acesso mais confiável a esses aceleradores.
• Sua carga de trabalho é flexível por tempo e seu caso de uso pode esperar para ter toda a capacidade solicitada, por exemplo, quando o GKE aloca os recursos da GPU fora dos horários de maior movimento.

Preços de início flexível

O início flexível é recomendado se a carga de trabalho exigir recursos provisionados dinamicamente conforme necessário, por até sete dias com reservas de curto prazo, sem gerenciamento complexo de cota e acesso econômico. O início flexível é alimentado pelo Programador dinâmico de cargas de trabalho e é faturado usando os preços do Programador dinâmico de cargas de trabalho:

• Desconto de até 53% para vCPUs, GPUs e TPUs.
• Você paga conforme a utilização.

Requisitos

Para usar o início flexível no GKE, seu cluster precisa atender aos seguintes requisitos:

• Para executar GPUs, use a versão 1.32.2-gke.1652000 ou mais recente do GKE.

• Para executar TPUs, use o GKE versão 1.33.0-gke.1712000 ou mais recente. O flex-start é compatível com as seguintes versões e zonas:

  • TPU Trillium (v6e) em asia-northeast1-b e us-east5-a.
  • TPU v5e em us-west4-a.
  • TPU v5p em us-east5-a.

  TPUs v3 e v4 não são compatíveis.

Como funciona o modo de provisionamento de início flexível

Com o início flexível, você especifica a capacidade necessária de GPU ou TPU nas suas cargas de trabalho. Além disso, com os clusters Standard, é possível configurar o flex-start em pools de nós específicos. O GKE provisiona automaticamente as VMs concluindo o seguinte processo quando a capacidade fica disponível:

1. A carga de trabalho solicita uma capacidade que não está disponível imediatamente. Essa solicitação pode ser feita diretamente pela especificação da carga de trabalho ou por ferramentas de programação, como classes de computação personalizadas ou Kueue.
2. O GKE identifica que o nó tem o início flexível ativado e que a carga de trabalho pode aguardar um tempo indeterminado.
3. O escalonador automático de clusters aceita sua solicitação e calcula o número de nós necessários, tratando-os como uma única unidade.
4. O escalonador automático de cluster provisiona os nós necessários quando eles estão disponíveis. Esses nós são executados por um máximo de sete dias ou por um período mais curto se você especificar um valor no parâmetro maxRunDurationSeconds. Esse parâmetro está disponível na versão 1.28.5-gke.1355000 ou mais recente do GKE. Se você não especificar um valor para o parâmetro maxRunDurationSeconds, o padrão será de sete dias.
5. Depois que o tempo de execução definido no parâmetro maxRunDurationSeconds termina, os nós e os pods são interrompidos.
6. Se os pods forem concluídos antes e os nós não forem mais utilizados, o escalonador automático de clusters os removerá de acordo com o perfil de escalonamento automático.

O GKE conta a duração de cada solicitação de início flexível no nível do nó. O tempo disponível para executar os pods pode ser um pouco menor devido a atrasos durante a inicialização. As novas tentativas do pod compartilham essa duração, o que significa que há menos tempo disponível para os pods após a nova tentativa. O GKE conta a duração de cada solicitação de início flexível separadamente.

Configurações de início flexível

O GKE é compatível com as seguintes configurações de início flexível:

• Flex-start, em que o GKE aloca recursos nó por nó. Essa configuração exige apenas que você defina a flag --flex-start durante a criação do nó.

• Início flexível com provisionamento em fila, em que o GKE aloca todos os recursos solicitados ao mesmo tempo. Para usar essa configuração, adicione as flags --flex-start e enable-queued-provisioning ao criar o pool de nós. O GKE segue o processo em Como funciona o modo de provisionamento de início flexível neste documento, mas também aplica as seguintes condições:

  • O programador aguarda até que todos os recursos solicitados estejam disponíveis em uma única zona.
  • Todos os pods da carga de trabalho podem ser executados juntos em nós recém-provisionados.
  • Os nós provisionados não são reutilizados entre as execuções de carga de trabalho.

A tabela a seguir compara as configurações de início flexível:

Otimizar a configuração de flex-start

Para criar uma infraestrutura de IA/ML robusta e otimizada em termos de custos, combine configurações de início flexível com os recursos disponíveis do GKE. Recomendamos que você use as classes de computação para definir uma lista priorizada de configurações de nós com base nos requisitos da sua carga de trabalho. O GKE vai selecionar a configuração mais adequada com base na disponibilidade e na prioridade definida.

Gerenciar interrupções em cargas de trabalho que usam o Dynamic Workload Scheduler

As cargas de trabalho que exigem a disponibilidade de todos os nós, ou da maioria dos nós, em um pool de nós são sensíveis a remoções. Além disso, os nós provisionados usando solicitações do Programador de carga de trabalho dinâmico não oferecem suporte ao reparo automático. O reparo automático remove todas as cargas de trabalho de um nó, impedindo que elas sejam executadas.

Todos os nós que usam flex-start, provisionamento em fila ou ambos usam upgrades de curta duração quando o plano de controle do cluster executa a versão mínima para flex-start, 1.32.2-gke.1652000 ou mais recente.

Os upgrades de curta duração atualizam um pool de nós Standard ou um grupo de nós em um cluster do Autopilot sem interromper os nós em execução. Novos nós são criados com a nova configuração, substituindo gradualmente os nós atuais com a configuração antiga ao longo do tempo. As versões anteriores do GKE, que não são compatíveis com upgrades de início flexível ou de curta duração, exigem outras práticas recomendadas.

Práticas recomendadas para minimizar interrupções na carga de trabalho em nós que usam upgrades de curta duração

Os nós de início flexível e os nós que usam provisionamento em fila são configurados automaticamente para usar upgrades de curta duração quando o cluster executa a versão 1.32.2-gke.1652000 ou mais recente.

Para minimizar as interrupções nas cargas de trabalho em execução em nós que usam upgrades de curta duração, faça o seguinte:

• Configure janelas e exclusões de manutenção para definir quando o GKE deve e não deve realizar operações de atualização, como upgrades de nós, garantindo que o GKE ainda tenha tempo para fazer a manutenção automática.
• Desative o reparo automático de nós.

Para nós em clusters que executam versões anteriores a 1.32.2-gke.1652000 e, portanto, não usam upgrades de curta duração, consulte a orientação específica para esses nós.

Práticas recomendadas para minimizar a interrupção da carga de trabalho em nós de provisionamento enfileirados sem upgrades de curta duração

Os nós que usam provisionamento em fila em um cluster que executa uma versão do GKE anterior a 1.32.2-gke.1652000 não usam upgrades de curta duração. Os clusters atualizados para a versão 1.32.2-gke.1652000 ou mais recente com nós de provisionamento enfileirados são atualizados automaticamente para usar upgrades de curta duração.

Para nós que executam essas versões anteriores, consulte as seguintes orientações:

• Dependendo do registro de canal de lançamento do cluster, use as seguintes práticas recomendadas para evitar que os upgrades automáticos de nós interrompam as cargas de trabalho:
  • Se o cluster estiver inscrito em um canal de lançamento, use janelas e exclusões de manutenção para evitar que o GKE faça upgrade dos nós automaticamente enquanto a carga de trabalho estiver em execução.
  • Se o cluster não estiver inscrito em um canal de lançamento, desative os upgrades automáticos do nó. No entanto, recomendamos usar canais de lançamento, em que é possível usar exclusões de manutenção com escopos mais granulares.
• Desative o reparo automático de nós.
• Use janelas e exclusões de manutenção para minimizar a interrupção das cargas de trabalho em execução, garantindo que o GKE ainda tenha tempo para fazer a manutenção automática. Programe esse horário para quando nenhuma carga de trabalho estiver em execução.
• Para garantir que o pool de nós permaneça atualizado, faça o upgrade manual do pool de nós quando não houver solicitações do Dynamic Workload Scheduler ativas e o pool de nós estiver vazio.

Considerações para quando o cluster migrar para upgrades de curta duração

O GKE atualiza os nós atuais usando o provisionamento em fila para usar upgrades de curta duração quando o cluster é atualizado para a versão 1.32.2-gke.1652000 ou posterior. O GKE não atualiza outras configurações, como a ativação de upgrades automáticos de nós se você os desativou para um pool de nós específico.

Recomendamos que você implemente as seguintes práticas recomendadas agora que seus pools de nós usam upgrades de curta duração:

• Se você desativou os upgrades automáticos de nós usando a flag --no-enable-autoupgrade, essa migração não vai reativar os upgrades automáticos de nós para o pool de nós. Recomendamos que você ative os upgrades automáticos de nós, porque os upgrades de curta duração não prejudicam os nós atuais e as cargas de trabalho executadas neles. Para mais informações, consulte Upgrades de curta duração.
• Também recomendamos que, se o cluster ainda não estiver inscrito em um canal de lançamento, você inscreva o cluster para usar escopos de exclusão de manutenção mais granulares.

Reciclagem de nós no início flexível

Para ajudar a garantir uma transição tranquila dos nós e evitar inatividade nos jobs em execução, o flex-start oferece suporte à reciclagem de nós. Quando um nó chega ao fim da duração, o GKE o substitui automaticamente por um novo para preservar as cargas de trabalho em execução.

Para usar a reciclagem de nós, crie um perfil de classe de computação personalizada e inclua o campo nodeRecycling na especificação flexStart com o parâmetro leadTimeSeconds.

O parâmetro leadTimeSeconds permite equilibrar a disponibilidade de recursos e a eficiência de custos. Esse parâmetro especifica com quanto tempo de antecedência (em segundos) antes de um nó atingir o fim da duração de sete dias para que um novo processo de provisionamento de nó comece a substituí-lo. Um lead time mais longo aumenta a probabilidade de que o novo nó esteja pronto antes da remoção do antigo, mas pode gerar custos adicionais.

O processo de reciclagem de nós consiste nas seguintes etapas:

1. Fase de reciclagem:o GKE valida se um nó provisionado com início flexível tem o campo nodeRecycling com o parâmetro leadTimeSeconds definido. Se sim, o GKE vai iniciar a fase de reciclagem de nós quando a data atual for maior ou igual à diferença entre os valores dos seguintes campos:

   • creationTimestamp mais maxRunDurationSeconds
   • leadTimeSeconds

   A flag creationTimeStamp inclui o horário em que o nó foi criado. O campo maxRunDurationSeconds pode ser especificado na classe de computação personalizada e tem como padrão sete dias.

2. Criação de nós:o processo de criação do novo nó começa, passando pelas fases de enfileiramento e provisionamento. A duração da fase de enfileiramento pode variar dinamicamente dependendo da zona e da capacidade específica do acelerador.

3. Restrinja o nó que está chegando ao fim da duração de sete dias:depois que o novo nó estiver em execução, o nó antigo será restringido. Essa ação impede que novos pods sejam programados nele. Os pods atuais nesse nó continuam sendo executados.

4. Desprovisionamento de nós:o nó que está chegando ao fim da duração de sete dias é desprovisionado após um período adequado, o que ajuda a garantir que as cargas de trabalho em execução tenham migrado para o novo nó.

O exemplo a seguir de uma configuração de classe de computação inclui os campos leadTimeSeconds e maxRunDuration:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: dws-model-inference-class
spec:
  priorities:
    - machineType: g2-standard-24
      spot: true
    - machineType: g2-standard-24
      maxRunDurationSeconds: 72000
      flexStart:
        enabled: true
        nodeRecycling:
          leadTimeSeconds: 3600
  nodePoolAutoCreation:
    enabled: true

Para mais informações sobre como usar a reciclagem de nós, consulte o tutorial Veicular LLMs no GKE com uma estratégia de provisionamento de GPU de alta disponibilidade e custo otimizado.

Limitações

• A antiafinidade entre pods não tem suporte. O escalonador automático de cluster não considera regras de antiafinidade entre pods durante o provisionamento de nós, o que pode levar a cargas de trabalho não programáveis. Isso pode acontecer quando os nós de dois ou mais objetos do Programador de carga de trabalho dinâmica foram provisionados no mesmo pool de nós.
• Somente os nós da GPU são compatíveis.
• Não há suporte para reservas com o Programador de carga de trabalho dinâmico. É preciso especificar a flag --reservation-affinity=none ao criar o pool de nós. O Dynamic Workload Scheduler requer e oferece suporte apenas à política de local ANY para o escalonamento automático de clusters.
• Uma única solicitação do Dynamic Workload Scheduler pode criar até 1.000 máquinas virtuais (VMs), que é o número máximo de nós por zona para um único pool de nós.
• O GKE usa a cota ACTIVE_RESIZE_REQUESTS do Compute Engine para controlar o número de solicitações pendentes do programador de cargas de trabalho dinâmicas em uma fila. Por padrão, essa cota tem um limite de 100 solicitações por projeto Trusted Cloud. Se você tentar criar uma solicitação do programador de carga de trabalho dinâmica maior que essa cota, a nova solicitação vai falhar.
• Os pools de nós que usam o Dynamic Workload Scheduler são sensíveis a interrupções, já que os nós são provisionados juntos. Para saber mais, consulte Gerenciar interrupções em cargas de trabalho que usam o Dynamic Workload Scheduler.
• Talvez você veja outras VMs de curta duração listadas no console Trusted Cloud . Esse comportamento ocorre porque o Compute Engine pode criar e remover VMs imediatamente até que a capacidade de provisionar todas as máquinas necessárias esteja disponível.
• As VMs spot não são compatíveis.
• O Programador de carga de trabalho dinâmico não é compatível com volumes efêmeros. É necessário usar volumes permanentes para armazenamento. Para selecionar o melhor tipo de armazenamento que usa volumes permanentes, consulte Visão geral do armazenamento para clusters do GKE.
• Se a carga de trabalho usar reciclagem de nós e for implantada por um job, configure o job com o modo de conclusão definido como Indexed.

A seguir

• Selecionar um tipo de GPU
• Implante GPUs com o Dynamic Workload Scheduler.