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

Esta página descreve o início flexível no Google Kubernetes Engine (GKE). O início flexível, com tecnologia do Dynamic Workload Scheduler, oferece uma técnica flexível e econômica para consumir recursos de computação especializados, como GPUs ou TPUs, quando você precisa executar cargas de trabalho de IA/ML.

O início flexível permite provisionar dinamicamente VMs de início flexível para GPUs, TPUs e séries de máquinas H4D conforme necessário, por até sete dias, sem restrições de 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 pequenas a médias com requisitos de demanda flutuantes ou durações curtas. Por exemplo, pré-treinamento de modelos pequenos, ajuste fino de modelos ou modelos de veiculação escalonáveis.

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

  • Entender como o início flexível funciona no GKE.
  • Decidir se o início flexível é adequado para sua carga de trabalho.
  • Decidir qual configuração de início flexível é adequada para sua carga de trabalho.
  • Gerenciar interrupções ao usar VMs de início flexível.
  • Entender as limitações das VMs de início flexível 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 cargas de trabalho.

Quando usar o início flexível

Recomendamos que você use o início flexível se as cargas de trabalho atenderem a todas as condições a seguir:

  • As cargas de trabalho exigem recursos de GPU.
  • As cargas de trabalho exigem recursos de TPU que são executados em pools de nós de fração de TPU de host único.
  • As cargas de trabalho exigem outros hardwares especializados, como a série de máquinas H4D otimizada para HPC.
  • 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 do 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 cotas e acesso econômico. O início flexível é desenvolvido pelo Dynamic Workload Scheduler e é faturado usando os preços do Dynamic Workload Scheduler:

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

Requisitos

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

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

  • Para executar TPUs, consulte os requisitos de versão do GKE em Planejar TPUs no GKE. O início flexível oferece suporte à seguinte versão e zonas:

    • Ironwood (TPU7x) em us-central1-c.
    • TPU Trillium (v6e) em asia-northeast1-b, us-east5-a e us-east5-b.
    • TPU v5e em us-west4-a.
    • TPU v5p em us-east5-a.

    As 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 de computação necessária (como GPUs ou TPUs) nas cargas de trabalho. Além disso, com clusters Standard, você configura o início flexível em pools de nós específicos. O GKE provisiona automaticamente VMs de início flexível concluindo o processo a seguir quando a capacidade fica disponível:

  1. A carga de trabalho solicita 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 orquestração, como classes de computação personalizadas ou Kueue.
  2. O GKE identifica que o início flexível está ativado no nó e que a carga de trabalho pode aguardar um período 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 clusters 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. 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 terminar, os nós e os pods serão preemptivos.
  6. Se os pods forem concluídos antes e os nós não forem mais utilizados, o cluster escalonador automático 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 oferece suporte às seguintes configurações de início flexível:

  • Início flexível, 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 enfileirado, 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 o modo de provisionamento de início flexível funciona 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:

Início flexível Início flexível com provisionamento enfileirado
Disponibilidade Visualizar

Disponibilidade geral (GA)

Observação: o início flexível oferece suporte às flags flex-start e enable-queued-provisioning na pré-visualização.
Aceleradores compatíveis
Tamanho de carga de trabalho recomendado Pequeno a médio, o que significa que a carga de trabalho pode ser executada em um único nó. Por exemplo, essa configuração funciona bem se você estiver executando jobs de treinamento pequenos, inferência off-line ou jobs em lote. Médio a grande, o que significa que a carga de trabalho pode ser executada em vários nós. A carga de trabalho requer vários recursos e não pode começar a ser executada até que todos os nós sejam provisionados e estejam prontos ao mesmo tempo. Por exemplo, essa configuração funciona bem se você estiver executando cargas de trabalho de treinamento distribuído de machine learning.
Tipo de provisionamento O GKE provisiona um nó por vez quando os recursos estão disponíveis. Para TPUs, o GKE cria um nó por vez em pools de nós de fração de TPU de host único e a fração completa por vez em pools de nós de fração de TPU de vários hosts. O GKE aloca todos os recursos solicitados simultaneamente.
Complexidade da instalação Menos complexo. Essa configuração é semelhante às VMs spot e on demand. Mais complexo. Recomendamos o uso de uma ferramenta de gerenciamento de cotas, como o Kueue.
Suporte a classes de computação personalizadas Sim Não
Reciclagem de nós Sim Não
Preço SKU de início flexível SKU de início flexível
Quota
Estratégia de upgrade de nós Upgrades de curta duração Upgrades de curta duração
gcloud container node pool create flag --flex-start
  • --flex-start
  • --enable-queued-provisioning
Primeiros passos GPUs: TPUs: Executar uma carga de trabalho em grande escala com início flexível com provisionamento enfileirado

Otimizar a configuração de início flexível

Para criar uma infraestrutura de IA/ML robusta e otimizada para custos, combine configurações de início flexível com os recursos disponíveis do GKE. Recomendamos o uso de classes de computação para definir uma lista priorizada de configurações de nós com base nos requisitos da 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 Dynamic Workload Scheduler não oferecem suporte ao reparo automático. O reparo automático remove todas as cargas de trabalho de um nó e, portanto, impede que elas sejam executadas.

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

Os upgrades de curta duração atualizam um pool de nós padrão 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 oferecem suporte a upgrades de início flexível ou de curta duração, exigem práticas recomendadas diferentes.

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

Os nós que usam VMs de início flexível e os nós que usam provisionamento enfileirado 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, realize as seguintes tarefas:

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

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

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

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

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

O GKE atualiza os nós atuais usando o provisionamento enfileirado para usar upgrades de curta duração quando o cluster é atualizado para a versão 1.32.2-gke.1652000 ou mais recente. 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 os pools de nós usam upgrades de curta duração:

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

Para garantir uma transição tranquila de nós e evitar inatividade para os jobs em execução, o início flexível oferece suporte à reciclagem de nós. Quando um nó atinge o final 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 personalizado e inclua o campo nodeRecycling na especificação flexStart com o leadTimeSeconds parâmetro.

O parâmetro leadTimeSeconds permite equilibrar a disponibilidade de recursos e a eficiência de custos. Esse parâmetro especifica com que antecedência (em segundos) antes que um nó atinja o final da duração de sete dias para que um novo processo de provisionamento de nó comece a substituí-lo. Um tempo de espera maior aumenta a probabilidade de que o novo nó esteja pronto antes que o antigo seja removido, mas pode gerar custos adicionais.

O processo de reciclagem de nós consiste nas etapas a seguir:

  1. Fase de reciclagem:o GKE valida se um nó provisionado de início flexível tem o campo nodeRecycling com o parâmetro leadTimeSeconds definido. Se for o caso, o GKE inicia 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 a hora 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. Restringir o nó que está atingindo o final 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 em execução.

  4. Desprovisionamento de nós:o nó que está atingindo o final 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 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 otimizada para custos e alta disponibilidade.

Limitações

  • A antiafinidade entre pods não tem suporte. O escalonador automático de clusters 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. Essa situação pode acontecer quando os nós de dois ou mais objetos do Dynamic Workload Scheduler foram provisionados no mesmo pool de nós.
  • Não há suporte para reservas com o Programador de carga de trabalho dinâmico. É necessário especificar a flag --reservation-affinity=none ao criar o pool de nós. O Dynamic Workload Scheduler requer e oferece suporte apenas à ANY política de local 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 do Dynamic Workload Scheduler que estão pendentes em uma fila. Por padrão, essa cota tem um limite de 100 solicitações por Google Cloud projeto. Se você tentar criar uma solicitação do Dynamic Workload Scheduler 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 Google Cloud console. 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 Dynamic Workload Scheduler não oferece suporte a 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 a reciclagem de nós e for implantada por um job, configure o job com modo de conclusão definido como Indexed.
  • Um único objeto ProvisioningRequest oferece suporte a apenas uma entrada na lista podSets. As solicitações com várias entradas podSet falham.

A seguir