Esta página foi traduzida pela API Cloud Translation.

Acerca do consumo de GPU, TPU e H4D com o modo de aprovisionamento de início flexível

Autopilot Padrão

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

O início flexível permite-lhe consumir dinamicamente recursos de computação especializados conforme necessário, durante um máximo de sete dias, sem estar limitado a uma hora de início específica e sem a gestão de reservas de longo prazo. Por conseguinte, o início flexível funciona bem para cargas de trabalho de pequenas a médias dimensões com requisitos de procura flutuantes ou durações curtas. Por exemplo, pré-preparação de modelos pequenos, ajuste preciso de modelos ou modelos de publicação escaláveis.

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

Compreenda como funciona o início flexível no GKE.
Decida se o início flexível é adequado para a sua carga de trabalho.
Decida qual a configuração de início flexível mais adequada para a sua carga de trabalho.
Faça a gestão das interrupções quando usar o início flexível.
Compreenda as limitações do início flexível no GKE.

Esta página destina-se a administradores e operadores da plataforma e engenheiros de aprendizagem automática (AA) que querem otimizar a infraestrutura de aceleradores para as respetivas cargas de trabalho.

Quando usar o início flexível

Recomendamos que use o início flexível se as suas cargas de trabalho cumprirem todas as seguintes condições:

As suas cargas de trabalho requerem recursos de GPU.
As suas cargas de trabalho requerem recursos de TPU que são executados em pools de nós de fatia de TPU de anfitrião único.
As suas cargas de trabalho requerem outro hardware especializado, como a série de máquinas H4D otimizadas para HPC.
Tem uma capacidade de GPU ou TPU reservada limitada ou inexistente e precisa de um acesso mais fiável a estes aceleradores.
A sua carga de trabalho é flexível em termos de tempo e o seu exemplo de utilização pode esperar para receber toda a capacidade pedida, por exemplo, quando o GKE atribui os recursos de GPU fora das horas de maior atividade.

Preços de início flexível

Recomendamos o início flexível se a sua carga de trabalho exigir recursos aprovisionados dinamicamente conforme necessário, durante um máximo de sete dias com reservas de curto prazo, sem gestão complexa de quotas e acesso rentável. O início flexível é alimentado pelo programador de carga de trabalho dinâmico e é faturado através dos preços do programador de carga de trabalho dinâmico:

Com desconto (até 53%) para vCPUs, GPUs e TPUs.
Paga à medida que usa.

Requisitos

Para usar o início flexível no GKE, o cluster tem de cumprir os seguintes requisitos:

Para executar GPUs, use a versão 1.32.2-gke.1652000 ou posterior do GKE.
Para executar TPUs, use a versão 1.33.0-gke.1712000 ou posterior do GKE. O Flex-start suporta a seguinte versão e zonas:
- 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 suportadas.

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

Com o início flexível, especifica a capacidade de computação necessária (como GPUs ou TPUs) nas suas cargas de trabalho. Além disso, com clusters padrão, configura o início flexível em pools de nós específicos. O GKE aprovisiona automaticamente VMs concluindo o seguinte processo quando a capacidade fica disponível:

A carga de trabalho pede capacidade que não está imediatamente disponível. Este pedido pode ser feito diretamente pela especificação da carga de trabalho ou através de ferramentas de agendamento, como classes de computação personalizadas ou Kueue.
O GKE identifica que o seu nó tem o início flexível ativado e que a carga de trabalho pode esperar por um período indeterminado.
O dimensionamento automático do cluster aceita o seu pedido e calcula o número de nós necessários, tratando-os como uma única unidade.
O redimensionador automático de clusters aprovisiona os nós necessários quando estão disponíveis. Estes nós são executados durante um máximo de sete dias ou durante um período mais curto, se especificar um valor no parâmetro maxRunDurationSeconds. Se não especificar um valor para o parâmetro maxRunDurationSeconds, a predefinição é sete dias.
Após o tempo de execução definido no parâmetro maxRunDurationSeconds, os nós e os pods são preempted.
Se os pods terminarem mais cedo e os nós deixarem de ser usados, o escalador automático do cluster remove-os de acordo com o perfil de escalamento automático.

O GKE contabiliza a duração de cada pedido de início flexível ao nível do nó. O tempo disponível para executar os pods pode ser ligeiramente inferior devido a atrasos durante o arranque. As novas tentativas dos pods partilham esta duração, o que significa que há menos tempo disponível para os pods após a nova tentativa. O GKE contabiliza a duração de cada pedido de início flexível separadamente.

Configurações de início flexível

O GKE suporta as seguintes configurações de início flexível:

Flex-start, em que o GKE atribui recursos nó a nó. Esta configuração só requer que defina a flag --flex-start durante a criação do nó.
Início flexível com aprovisionamento em fila, em que o GKE atribui todos os recursos pedidos ao mesmo tempo. Para usar esta configuração, tem de adicionar os flags --flex-start e enable-queued-provisioning quando criar o conjunto de nós. O GKE segue o processo descrito em Como funciona o modo de aprovisionamento de início flexível neste documento, mas também aplica as seguintes condições:
- O programador aguarda até que todos os recursos pedidos estejam disponíveis numa única zona.
- Todos os pods da carga de trabalho podem ser executados em conjunto em nós recém-aprovisionados.
- Os nós aprovisionados não são reutilizados entre execuções de cargas de trabalho.
Nota: os clusters que executam a versão 1.29.1-gke.1708000 do GKE e posteriormente otimizam a seleção de zonas para tempos de espera mais baixos. As versões anteriores podem ter tempos de espera mais longos.

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

	Flex-start	Início flexível com aprovisionamento em fila
Disponibilidade	Pré-visualizar	Disponibilidade geral (GA) Nota: o início flexível suporta as flags `flex-start` e `enable-queued-provisioning` na pré-visualização.
Aceleradores suportados	GPU TPU em pools de nós de fatia de TPU de host único e pools de nós de fatia de TPU de vários hosts	GPU TPU em pools de nós de fatia de TPU com vários anfitriões
Tamanho da carga de trabalho recomendado	Pequena a média, o que significa que a carga de trabalho pode ser executada num único nó. Por exemplo, esta configuração funciona bem se estiver a executar tarefas de preparação pequenas, inferência offline ou tarefas em lote.	Médio a grande, o que significa que a carga de trabalho pode ser executada em vários nós. A sua carga de trabalho requer vários recursos e não pode começar a ser executada até que todos os nós sejam aprovisionados e estejam prontos em simultâneo. Por exemplo, esta configuração funciona bem se estiver a executar cargas de trabalho de preparação de aprendizagem automática distribuída.
Tipo de aprovisionamento	O GKE aprovisiona um nó de cada vez quando os recursos estão disponíveis.	O GKE atribui todos os recursos pedidos em simultâneo.
Complexidade da configuração	Menos complexo. Esta configuração é semelhante às VMs a pedido e às VMs Spot.	Mais complexo. Recomendamos vivamente que use uma ferramenta de gestão de quotas, como o Kueue.
Suporte para 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	Quota preemptível de GPU Quota preemptível da TPU	Quota preemptível de GPU Quota preemptível da TPU
Estratégia de atualização de nós	Atualizações de curta duração	Atualizações de curta duração
`gcloud container node pool create` denúncia	`--flex-start`	`--flex-start` `--enable-queued-provisioning`
Começar	GPUs: Publique MDIs no GKE com uma estratégia de aprovisionamento de GPUs de alta disponibilidade e otimizada em termos de custos Execute uma carga de trabalho de pequeno lote com GPUs e o modo de aprovisionamento de início flexível TPUs: Execute uma carga de trabalho de pequeno lote com TPUs e o modo de aprovisionamento de início flexível	Execute uma carga de trabalho em grande escala com início flexível e aprovisionamento em fila

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

Para criar uma infraestrutura de IA/AA robusta e otimizada em termos de custos, pode combinar configurações de início flexível com as funcionalidades do GKE disponíveis. Recomendamos que use as classes de computação para definir uma lista prioritária de configurações de nós com base nos requisitos da sua carga de trabalho. O GKE seleciona a configuração mais adequada com base na disponibilidade e na prioridade definida.

Faça a gestão das interrupções em cargas de trabalho que usam o Dynamic Workload Scheduler

As cargas de trabalho que requerem a disponibilidade de todos os nós ou da maioria dos nós num conjunto de nós são sensíveis a despejos. Além disso, os nós aprovisionados através de pedidos do Dynamic Workload Scheduler não suportam a reparação automática. A reparação automática remove todas as cargas de trabalho de um nó e, por isso, impede a respetiva execução.

Todos os nós que usam o início flexível, o aprovisionamento em fila ou ambos usam atualizações de curta duração quando o plano de controlo do cluster executa a versão mínima para o início flexível, 1.32.2-gke.1652000 ou posterior.

As atualizações de curta duração atualizam um grupo de nós padrão ou um grupo de nós num cluster do Autopilot sem interromper os nós em execução. Os novos nós são criados com a nova configuração, substituindo gradualmente os nós existentes com a configuração antiga ao longo do tempo. As versões anteriores do GKE, que não suportam o início flexível nem as atualizações de curta duração, requerem diferentes práticas recomendadas.

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

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

Para minimizar as interrupções nas cargas de trabalho executadas em nós que usam atualizações de curta duração, execute as seguintes tarefas:

Configure períodos de manutenção e exclusões para definir quando o GKE deve e não deve realizar operações de atualização, como atualizações de nós, ao mesmo tempo que garante que o GKE continua a ter tempo para fazer a manutenção automática.
Desative a reparação automática de nós.

Para nós em clusters que executam versões anteriores a 1.32.2-gke.1652000 e, por isso, não usam atualizações 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 aprovisionamento em fila sem atualizações de curta duração

Os nós que usam o aprovisionamento em fila num cluster que executa uma versão do GKE anterior a 1.32.2-gke.1652000 não usam atualizações de curta duração. Os clusters atualizados para a versão 1.32.2-gke.1652000 ou posterior com nós de aprovisionamento existentes em fila são atualizados automaticamente para usar atualizações de curta duração.

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

Consoante a inscrição no canal de lançamento do cluster, use as seguintes práticas recomendadas para evitar que as atualizações automáticas de nós interrompam as suas cargas de trabalho:
- Se o seu cluster estiver inscrito num canal de lançamento, use janelas de manutenção e exclusões para impedir que o GKE atualize automaticamente os seus nós enquanto a sua carga de trabalho estiver em execução.
- Se o seu cluster não estiver inscrito num canal de lançamento, desative as atualizações automáticas dos nós. No entanto, recomendamos a utilização de canais de lançamento, onde pode usar exclusões de manutenção com âmbitos mais detalhados.
Desative a reparação automática de nós.
Use janelas de manutenção e exclusões para minimizar a interrupção das cargas de trabalho em execução, ao mesmo tempo que garante que o GKE continua a ter tempo para fazer a manutenção automática. Certifique-se de que agenda essa hora para quando não estiverem a ser executadas cargas de trabalho.
Para garantir que o node pool permanece atualizado, atualize manualmente o node pool quando não existirem pedidos do Dynamic Workload Scheduler ativos e o node pool estiver vazio.

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

O GKE atualiza os nós existentes através do aprovisionamento em fila para usar atualizações 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 definições, como a ativação das atualizações automáticas de nós, se as tiver desativado para um pool de nós específico.

Recomendamos que considere implementar as seguintes práticas recomendadas agora que os seus conjuntos de nós usam atualizações de curta duração:

Se desativou as atualizações automáticas de nós através da flag --no-enable-autoupgrade, esta migração não volta a ativar as atualizações automáticas de nós para o conjunto de nós. Recomendamos que ative as atualizações automáticas dos nós, porque as atualizações de curta duração não são disruptivas para os nós existentes e as cargas de trabalho que são executadas neles. Para mais informações, consulte o artigo Atualizações de curta duração.
Também recomendamos que, se o seu cluster ainda não estiver inscrito num canal de lançamento, inscreva o seu cluster para poder usar âmbitos de exclusão de manutenção mais detalhados.

Reciclagem de nós no flex-start

Para ajudar a garantir uma transição suave dos nós e evitar o tempo de inatividade dos trabalhos em execução, o início flexível suporta a reciclagem de nós. Quando um nó atinge o fim da respetiva duração, o GKE substitui automaticamente o nó por um novo para preservar as cargas de trabalho em execução.

Para usar a reciclagem de nós, tem de criar um perfil de classe de computação personalizado e incluir 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. Este parâmetro especifica quanto tempo antes (em segundos) de um nó atingir o fim da respetiva duração de sete dias deve ser iniciado um novo processo de aprovisionamento de nós para o substituir. Um tempo de processamento mais longo aumenta a probabilidade de o novo nó estar pronto antes de o antigo ser removido, mas pode incorrer em custos adicionais.

O processo de reciclagem de nós consiste nos seguintes passos:

Fase de reciclagem: o GKE valida se um nó aprovisionado 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 igual ou superior à diferença entre os valores dos seguintes campos:
- creationTimestamp mais maxRunDurationSeconds
- leadTimeSeconds
O indicador creationTimeStamp inclui a hora em que o nó foi criado. O campo maxRunDurationSeconds pode ser especificado na classe de cálculo personalizada e tem um valor predefinido de sete dias.
Criação de nós: o processo de criação do novo nó começa, passando pelas fases de colocação em fila e aprovisionamento. A duração da fase de colocação em fila pode variar dinamicamente consoante a zona e a capacidade específica do acelerador.
Isolar o nó que está a atingir o fim da respetiva duração de sete dias: depois de o novo nó estar em execução, o nó antigo é isolado. Esta ação impede que sejam agendados novos pods no nó. Os pods existentes nesse nó continuam a ser executados.
Desaprovisionamento de nós: o nó que está a atingir o fim da respetiva duração de sete dias é eventualmente desaprovisionado após um período adequado, o que ajuda a garantir que as cargas de trabalho em execução foram migradas para o novo nó.

O exemplo seguinte 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, experimente o tutorial Apresente LLMs no GKE com uma estratégia de aprovisionamento de GPUs de alta disponibilidade e otimizada em função dos custos.

Limitações

A antafinidade entre pods não é suportada. O redimensionador automático de clusters não considera as regras de antiafinidade entre pods durante o aprovisionamento de nós, o que pode levar a cargas de trabalho não agendáveis. Esta situação pode ocorrer quando os nós de dois ou mais objetos do Dynamic Workload Scheduler foram aprovisionados no mesmo conjunto de nós.
As reservas não são suportadas com o Dynamic Workload Scheduler. Tem de especificar a flag --reservation-affinity=none quando cria o node pool. O Dynamic Workload Scheduler requer e suporta apenas a ANY política de localização para a escala automática de clusters.
Um único pedido do Dynamic Workload Scheduler pode criar até 1000 máquinas virtuais (VMs), que é o número máximo de nós por zona para um único conjunto de nós.
O GKE usa a quota do Compute Engine para controlar o número de pedidos do Dynamic Workload Scheduler pendentes numa fila.ACTIVE_RESIZE_REQUESTS Por predefinição, esta quota tem um limite de 100 pedidos por Google Cloud projeto. Se tentar criar um pedido do Dynamic Workload Scheduler superior a esta quota, o novo pedido falha.
Os conjuntos de nós que usam o Dynamic Workload Scheduler são sensíveis a interrupções porque os nós são aprovisionados em conjunto. Para saber mais, consulte o artigo Faça a gestão da interrupção em cargas de trabalho que usam o Dynamic Workload Scheduler.
Pode ver VMs de curta duração adicionais listadas na Google Cloud consola. Este comportamento destina-se a ser assim porque o Compute Engine pode criar e, em seguida, remover rapidamente VMs até que a capacidade de aprovisionar todas as máquinas necessárias esteja disponível.
As VMs do Spot não são suportadas.
O Dynamic Workload Scheduler não suporta volumes efémeros. Tem de usar volumes persistentes para o armazenamento. Para selecionar o melhor tipo de armazenamento que usa volumes persistentes, consulte o artigo Vista geral do armazenamento para clusters do GKE.
Se a carga de trabalho usar a reciclagem de nós e for implementada por um Job, configure o Job com o modo de conclusão definido como Indexed.