Sobre TPUs no GKE

Nesta página, apresentamos o Cloud TPU e ajudamos você a planejar sua configuração do Cloud TPU com o Google Kubernetes Engine (GKE), incluindo a reserva de instâncias de TPU, escalonamento automático, limitações da TPU e considerações sobre programação de carga de trabalho.

As Unidades de Processamento de Tensor (TPUs) são circuitos integrados de aplicação específica (ASICs, na sigla em inglês) desenvolvidos especialmente pelo Google. Elas são usadas para acelerar as cargas de trabalho de machine learning (ML) que usam frameworks como oTensorFlow, PyTorch e JAX.

Antes de usar TPUs no GKE, recomendamos que você conclua o seguinte programa de aprendizado:

  1. Saiba como os aceleradores de machine learning funcionam com a Introdução à Cloud TPU.
  2. Saiba mais sobre a disponibilidade atual da versão da TPU com a arquitetura do sistema do Cloud TPU.

Para saber como configurar a Cloud TPU no GKE, consulte os recursos a seguir:

Benefícios do uso de TPUs no GKE

O GKE oferece suporte completo para o gerenciamento do ciclo de vida de nós da TPU e do pool de nós, incluindo criação, configuração e exclusão de VMs de TPU. O GKE também oferece suporte a VMs do Spot e usa a Cloud TPU reservada. Os benefícios do uso de TPUs no GKE incluem:

  • Ambiente operacional consistente: é possível usar uma única plataforma para todo o machine learning e outras cargas de trabalho.
  • Upgrades automáticos: o GKE automatiza as atualizações de versão, o que reduz a sobrecarga operacional.
  • Balanceamento de carga: o GKE distribui a latência, reduzindo a carga e melhorando a confiabilidade.
  • Escalonamento responsivo: o GKE escalona automaticamente os recursos da TPU para atender às necessidades das cargas de trabalho.
  • Gerenciamento de recursos: comKueue, um sistema de enfileiramento de jobs nativo do Kubernetes, é possível gerenciar recursos em vários locatários na sua organização usando enfileiramento, preempção, priorização e compartilhamento justo.

Terminologia relacionada à TPU no GKE

Neste documento, usamos a seguinte terminologia relacionada às TPUs:

  • Tipo de TPU: o tipo de Cloud TPU, como v5e.
  • Nó de fração da TPU: um nó do Kubernetes que contém um conjunto de VMs com chips de TPU interconectados.
  • Pool de nós de fração de TPU: um grupo de nós do Kubernetes em um cluster que todos têm a mesma configuração de TPU.
  • Topologia de TPU: o número e a disposição física dos chips de TPU em uma fração de TPU.
  • Nós de fração de TPU de host único: um ou mais nós de fração de TPU independentes. As VMs em um nó de fração de TPU de host único não são conectadas umas às outras por interconexões de alta velocidade.
  • Nós de fração de TPU de vários hosts: dois ou mais nós de fração de TPU interconectados. As VMs em um nó de fração de TPU de vários hosts são conectadas por interconexões de alta velocidade. Os nós de fração da TPU de vários hosts têm as características a seguir:
    • Atômico: o GKE trata todos os nós interconectados como uma única unidade. Durante as operações de escalonamento, o GKE escalona todo o conjunto de nós para 0 e cria novos nós. Se uma máquina no grupo falhar ou for encerrada, o GKE recria todo o conjunto de nós como uma nova unidade.
    • Imutável: não é possível adicionar manualmente novos nós ao conjunto de nós interconectados. No entanto, é possível criar um novo pool de nós com a topologia de TPU desejada e programar cargas de trabalho no novo pool de nós.

Como funcionam as TPUs no GKE

O gerenciamento de recursos e a prioridade do Kubernetes tratam as VMs nas TPUs da mesma forma que os outros de VM. Você solicita chips de TPU por meio do nome do recurso google.com/tpu:

    resources:
        requests:
          google.com/tpu: 4
        limits:
          google.com/tpu: 4

Ao usar TPUs no GKE, considere as seguintes características da TPU:

  • Uma VM pode acessar até oito chips de TPU.
  • Uma fração de TPU contém um número fixo de chips de TPU, com o número dependendo do tipo de máquina TPU escolhido.
  • O número solicitado de google.com/tpu precisa ser igual ao número total de chips TPU disponíveis no nó de fração da TPU. Qualquer contêiner em um pod do GKE que solicite TPUs precisa consumir todos os chips TPU no nó. Caso contrário, a implantação falhará, porque o GKE não pode consumir parcialmente os recursos de TPU. Por exemplo, veja os seguintes cenários:
    • O tipo de máquina ct5l-hightpu-8t tem um único nó de fração de TPU com oito chips de TPU. Assim, em um nó, você:
      • Pode implantar um pod do GKE que requer oito chips de TPU.
      • Não é possível implantar dois pods do GKE que exigem quatro chips de TPU cada.
    • O tipo de máquina ct5lp-hightpu-4t com uma topologia 2x4 contém dois nós de fração de TPU com quatro chips de TPU cada, um total de oito chips de TPU. Com esse tipo de máquina:
      • Não é possível implantar um pod do GKE que requer oito chips do TPU nos nós deste pool.
      • Você pode implantar dois pods que exigem quatro chips de TPU cada, cada um em um dos dois nós neste pool de nós.
    • A TPU v5e com topologia 4x4 tem 16 chips de TPU em quatro nós. A carga de trabalho do GKE Autopilot que seleciona essa configuração precisa solicitar quatro chips de TPU em cada réplica, para de um a quatro réplicas.
  • Em clusters padrão, vários pods do Kubernetes podem ser programados em uma VM, mas apenas um contêiner em cada pod pode acessar os ícones da TPU.
  • Para criar pods do kube-system, como o kube-dns, cada cluster padrão precisa ter pelo menos um pool de nós de fração não TPU.
  • Por padrão, os nós de fração de TPU têm o google.com/tpu taint, que impede que frações de não TPU sejam programadas nos nós de fração de TPU. Cargas de trabalho que não usam TPUs são executadas em nós não TPU, liberando computação em nós de fatias TPU para código que usa TPUs. O taint não garante que os recursos da TPU sejam totalmente utilizados.
  • O GKE coleta os registros emitidos por contêineres em execução em nós de fração da TPU. Para saber mais, consulte Logging.
  • As métricas de inicialização da TPU, como o desempenho do ambiente de execução, estão disponíveis no Cloud Monitoring. Para saber mais, consulte Observabilidade e métricas.

Planejar a configuração da TPU

Para trabalhar com TPUs em clusters do GKE, é preciso decidir os seguintes parâmetros:

  • Tipo de TPU: o tipo de máquina, como ct5l-hightpu-8t. Diferentes tipos de TPU têm diferentes recursos, proporções de preço-desempenho, capacidade de processamento de treinamento e latência de disponibilização. Os tipos de TPU afetam a CPU e as capacidades de memória disponíveis.
  • Topologia: a disposição física das TPUs em uma fração de TPU. Cada tipo de TPU aceita uma topologia de TPU 2D ou 3D. Selecione uma topologia que corresponda aos requisitos de paralelismo do modelo.

  • Interconexão com TPU: se os nós têm interconexões de alta velocidade. O tipo e a topologia da TPU determinam se é possível ter nós de fração de TPU com vários hosts, que são TPUs em vários nós com interconexões de alta velocidade. Recomendamos o seguinte:

    • Para modelos em grande escala, use nós de fração de TPU de vários hosts
    • Para modelos de pequena escala, use nós de fração de TPU de host único

  • Modo privilegiado: substitui muitas das outras configurações de segurança no securityContext. Para acessar TPUs, os contêineres em execução nos nós do GKE em:

    • A versão 1.28 e anteriores precisam ativar o modo privilegiado.
    • As versões 1.28 ou mais recentes não precisam do modo privilegiado.

Escolher uma configuração de TPU para o modo Autopilot do GKE

No modo Autopilot, você escolhe um tipo de TPU e uma topologia e os especifica no manifesto do Kubernetes. O GKE gerencia nós de provisionamento com TPUs e programa suas cargas de trabalho.

Disponibilidade da TPU no Autopilot do GKE

As TPUs estão disponíveis em regiões específicas do Google Cloud. Para usar um tipo de TPU na carga de trabalho do GKE, o cluster precisa estar em uma região compatível com esse tipo. Para detalhes, consulte Regiões e zonas de TPU na documentação do Cloud TPU.

Escolher um tipo de TPU no Autopilot

Tipo de TPU Número de vCPUs Memória (GiB) Número de nós NUMA Máximo de chips de TPU em uma fração
TPU v5p
tpu-v5p-slice		 208 448 2 6.144
TPU v5e
tpu-v5-lite-podslice		 24 a 224 48 a 384 1 256
TPU v5e (somente host único)
tpu-v5-lite-device		 24 a 224 48 a 384 1 a 2 8
TPU v4
tpu-v4-podslice		 240 407 2 4.096

Confira as especificações e os preços do chip de TPU na Documentação de preços do Cloud TPU para ajudar a decidir qual tipo de TPU usar.

Escolher uma topologia para o Autopilot

Depois de escolher um tipo de TPU, selecione uma topologia compatível com ele. Dependendo do tipo de TPU, a topologia é bidimensional ou tridimensional. Os requisitos de paralelismo do modelo ajudarão você a decidir sobre uma topologia. É possível identificar o número de chips de TPU na fração ao calcular o produto de cada tamanho na topologia. Exemplo:

  • 2x2x2 é uma fração de TPU v4 com vários hosts com oito chips
  • 2x2 é uma fração da TPU v5e de host único com quatro chips

Se uma topologia específica oferecer suporte a nós de frações de TPU de host único e de vários hosts, o número de chips TPU solicitados pela sua carga de trabalho determinará o tipo de host que você receberá.

Por exemplo, a TPU v5e (tpu-v5-lite-podslice) é compatível com a topologia 2x4 como host único e de vários hosts. Veja o que acontecerá nestes casos:

  • Solicite quatro ícones na sua carga de trabalho para receber um nó de vários hosts com quatro chips de TPU.
  • Solicite oito ícones na sua carga de trabalho e receba um host único com 8 chips de TPU.

A tabela a seguir lista cada tipo de TPU, as topologias compatíveis e anotações de uso. Para cada uma dessas topologias, a tabela lista o número de chips de TPU, o número de nós e o tipo de host:

Tipo de TPU topologia Chips de TPU em uma fração Número de nós Tipo de host Observações
TPU v5p
tpu-v5p-slice		 2x2x1 4 1 Host único

Topologias personalizadas para mais de 64 chips são aceitas. Aplicam-se as seguintes condições:

  • Para mais de 64 ícones, {A}, {B} e {C} precisam ser múltiplos de 4
  • A maior topologia é 16x16x24
  • Os valores precisam ser {A}≤{B}≤{C}, como 8x12x16.
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
4x4x4 64 16 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5e
tpu-v5-lite-podslice		 1x1 1 1 Host único Não há suporte para topologias personalizadas.
2x2 4 1
2x4 8 1
2x4 2 1 Vários hosts
4x4 16 4
4x8 32 8
8x8 64 16
8x16 128 32
16x16 256 64
TPU v5e (somente host único)
tpu-v5-lite-device		 1x1 1 1 Host único Topologias personalizadas não são compatíveis
2x2 4 1
2x4 8 1
TPU v4
tpu-v4-podslice		 2x2x1 4 1 Host único

Topologias personalizadas para mais de 64 chips são aceitas. Aplicam-se as seguintes condições:

  • Para mais de 64 ícones, {A}, {B} e {C} precisam ser múltiplos de 4
  • A maior topologia é 12x16x16
  • Os valores precisam ser {A}≤{B}≤{C}, como 8x12x16.
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
4x4x4 64 16 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts

  1. Calculado pelo produto de topologia dividido por quatro. ↩

Depois de escolher um tipo de TPU e uma topologia, especifique-os no manifesto da carga de trabalho. Para instruções, consulte Implantar cargas de trabalho de TPU no Autopilot do GKE.

Escolher uma configuração de TPU para o modo GKE Standard

As seções a seguir descrevem as características da TPU a serem consideradas ao planejar e configurar suas cargas de trabalho de TPU no GKE. Para detalhes sobre versões disponíveis, tipos de máquina, topologias válidas e o número de chips de TPU, consulte Mapeamento de configurações de TPU neste documento.

Disponibilidade da TPU no modo GKE Standard

A tabela a seguir lista a disponibilidade de TPU para cada versão de TPU e tipo de máquina:

Versão da TPU Tipo de máquina começando com Versão mínima do GKE Disponibilidade Zona
TPU v4 ct4p- 1.26.1-gke.1500 Disponibilidade geral us-central2-b
TPU v5e ct5l- 1.27.2-gke.2100 Disponibilidade geral europe-west4-b
us-central1-a
TPU v5e ct5lp- 1.27.2-gke.2100 Disponibilidade geral europe-west4-a1
us-central1-a1
us-east1-c
us-east5-b1
us-west1-c
us-west4-a
us-west4-b1
TPU v5p ct5p- 1.28.3-gke.1024000 Disponibilidade geral us-east1-d
us-east5-a
us-east5-c

  1. É possível criar um pool de nós da TPU v5e de host único com um tipo de máquina que começa com ct5lp-, mas não começa com ct5l- em determinadas zonas (europe-west4-a, us-central1-a, us-east5-b e us-west4-b). Você pode usar ct5lp-hightpu-4t com uma topologia de pelo menos 2x4 ou maior nessas zonas. Para criar uma TPU v5e de host único na região us-west4, escolha a zona us-west4-a e use tipos de máquina que começam com ct5lp-, como ct5lp-hightpu-1t. Para criar uma TPU v5e de host único nas outras regiões listadas neste parágrafo, use tipos de máquina que comecem com ct5l- (como ct5l-hightpu-1t, ct5l-hightpu-4t ou ct5l-hightpu-8t) e selecione a zona us-central1-a ou europe-west4-b. Os tipos de máquinas que começam com ct5l- exigem cotas diferentes dos tipos que começam com ct5lp-. ↩

As seções a seguir descrevem as características da TPU a serem consideradas ao planejar e configurar suas cargas de trabalho de TPU no GKE. Para detalhes sobre versões disponíveis, tipos de máquina, topologias válidas e o número de chips de TPU, consulte a seção Mapeamento de configurações de TPU neste documento.

Tipo de máquina

Os tipos de máquinas que oferecem suporte aos recursos de TPU seguem uma convenção de nomenclatura que inclui a versão da TPU e o número de chips de TPU por nó, como ct<version>-hightpu-<node-chip-count>t. Por exemplo, o tipo de máquina ct5lp-hightpu-1t é compatível com TPU v5e e contém apenas um chip de TPU.

topologia

A topologia define a disposição física das TPUs dentro de uma fração da TPU. O GKE provisiona uma fração da TPU em topologias bidimensionais ou tridimensionais, dependendo da versão da TPU. Especifique uma topologia como o número de chips de TPU em cada dimensão:

  • Para a TPU v4 e v5p programada em pools de nós de fração da TPU de vários hosts, defina a topologia em três tuplas ({A}x{B}x{C}), por exemplo, 4x4x4. O produto de {A}x{B}x{C} define o número de chips de TPU no pool de nós. Por exemplo, é possível definir topologias pequenas menores que 64 chips de TPU com formulários de topologia, como 2x2x2, 2x2x4 ou 2x4x4. Se você usar topologias maiores que 64 chips de TPU, os valores atribuídos a {A}, {B} e {C} precisarão atender às seguintes condições:

    • {A}, {B} e {C} são múltiplos de quatro.
    • A maior topologia compatível com v4 é 12x16x16 e v5p é 16x16x24.
    • Os valores atribuídos mantêm o padrão A ≤ B ≤ C. Por exemplo, 4x4x8 ou 8x8x8.

Mapeamento da configuração de TPU

Use a tabela a seguir para escolher o tipo de máquina e a topologia de TPU para seu caso de uso:

  • Para treinamento ou inferência de modelos em pequena escala, use a TPU v4 ou a TPU v5e com pools de nós de frações de TPU de host único.
  • Para treinamento ou inferência de modelos em grande escala, use a TPU v4 ou a TPU v5e com pools de nós de frações de TPU de vários hosts.
Versão da TPU Tipo de máquina Topologia Número de chips do TPU Número de VMs Tipo de pool de nós
TPU v4 ct4p-hightpu-4t 2x2x1 4 1 Host único
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5p ct5p-hightpu-4t 2x2x1 4 1 Host único
2x2x2 8 2 Vários hosts
2x2x4 16 4 Vários hosts
2x4x4 32 8 Vários hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Vários hosts
TPU v5e ct5l-hightpu-1t 1x1 1 1 Host único
ct5l-hightpu-4t 2x2 4 1 Host único
ct5l-hightpu-8t 2x4 8 1 Host único
ct5lp-hightpu-1t 1x1 1 1 Host único
ct5lp-hightpu-4t 2x2 4 1 Host único
ct5lp-hightpu-8t 2x4 8 1 Host único
ct5lp-hightpu-4t 2x4 8 2 Vários hosts
4x4 16 4 Vários hosts
4x8 32 8 Vários hosts
8x8 64 16 Vários hosts
8x16 128 32 Vários hosts
16x16 256 64 Vários hosts

  1. Calculado pelo produto de topologia dividido por quatro. ↩

Características da TPU v5e

As máquinas TPU v5e têm as seguintes características técnicas:

Tipo de máquina Número de vCPUs Memória (GB) Número de nós NUMA Probabilidade de ser interrompido
ct5l-hightpu-1t 24 48 1 Alto
ct5l-hightpu-4t 112 192 1 Médio
ct5l-hightpu-8t 224 384 2 Inferior
ct5lp-hightpu-1t 24 48 1 Alto
ct5lp-hightpu-4t 112 192 1 Médio
ct5lp-hightpu-8t 224 384 1 Baixa

Características da TPU v4 e v5p

As máquinas TPU v4p e v5p têm as seguintes características técnicas:

Tipo de máquina Número de vCPUs Memória (GB) Número de nós NUMA
ct4p-hightpu-4t 240 407 2
ct5p-hightpu-4t 208 448 2

Reserva da TPU

As reservas de TPU estão disponíveis ao comprar um compromisso. Qualquer reserva de TPU pode ser usada com o GKE.

Ao criar um pool de nós de fração de TPU, use as sinalizações --reservation e --reservation-affinity=specific para consumir uma instância de TPU reservada.

Como fazer o escalonamento automático de TPUs no GKE

O GKE é compatível com Unidades de Processamento de Tensor (TPUs) para acelerar as cargas de trabalho de machine learning. O pool de nós de fração de TPU de host único e o pool de nós de frações de TPU de vários hosts são compatíveis com escalonamento automático e provisionamento automático.

Com a sinalização --enable-autoprovisioning em um cluster do GKE, o GKE cria ou exclui pools de nós de frações de TPU de host único ou de vários hosts com uma versão e topologia de TPU que atende aos requisitos das cargas de trabalho pendentes.

Quando você usa --enable-autoscaling, o GKE escalona o pool de nós com base no tipo, da seguinte maneira:

  • Pool de nós da fração de TPU de host único: o GKE adiciona ou remove nós da TPU no pool de nós atual. O pool de nós pode conter qualquer número de nós da TPU entre zero e o tamanho máximo dele, conforme determinado por --max-nodes e os --total-max-nodes. Quando o pool de nós é escalonado, todos os nós da TPU nele têm o mesmo tipo de máquina e topologia. Para saber mais sobre como criar um pool de nós de fatia de TPU de host único, consulte Criar um pool de nós.

  • Pool de nós de fração de TPU de vários hosts: o GKE escalona atomicamente o pool de nós de zero para o número de nós necessários para satisfazer a topologia de TPU. Por exemplo, com um pool de nós de TPU com um tipo de máquina ct5lp-hightpu-4t e uma topologia de 16x16, o pool de nós contém 64 nós. O escalonador automático do GKE garante que esse pool de nós tenha exatamente 0 ou 64 nós. Ao reduzir o escalonamento, o GKE remove todos os pods programados e drena todo o pool de nós para zero. Para saber mais como criar um pool de nós de fração de TPU de vários hosts, consulte Criar um pool de nós.

Limitações

Use estas considerações ao planejar o uso de TPUs na sua plataforma:

  • Para reservas de capacidade, é preciso usar uma reserva específica.
  • A alocação de custos e a medição de uso do GKE não incluem dados sobre o uso ou os custos da TPU v4 reservada.
  • As TPUs v5p e v5e não são compatíveis com riptide/image streaming em us-east5.
  • O escalonamento automático da TPU v5p é compatível com clusters do GKE com planos de controle que executam pelo menos 1.29.2-gke.1035000 ou 1.28.7-gke.1020000.

Considerações sobre a programação da carga de trabalho

As TPUs têm características únicas que exigem programação e gerenciamento especiais de cargas de trabalho no Kubernetes. Nas seções a seguir, descrevemos as práticas recomendadas de programação.

CPU para clusters padrão

Esta seção não se aplica aos clusters do Autopilot porque o GKE coloca cada fração de TPU no próprio nó. Para saber mais, consulte Como as TPUs funcionam no modo Autopilot.

Para clusters padrão, considere as seguintes práticas recomendadas de programação.

Para programar uma carga de trabalho que não seja de TPU em uma VM em um nó de fração de TPU, verifique se o pod do GKE pode tolerar o taint google.com/tpu. Se você quiser que a carga de trabalho seja implantada em nós específicos, use seletores de nó.

O gerenciamento de recursos e a prioridade do Kubernetes tratam as VMs nas TPUs da mesma forma que os outros de VM. Para dar prioridade de agendamento a Pods que exigem TPUs em relação a outros Pods nos mesmos nós, solicite a CPU ou memória máxima para essas fatias de TPU. Frações de TPU de baixa prioridade devem fazer o seguinte:

  1. Defina solicitações baixas de CPU e memória para garantir que o nó tenha recursos alocáveis suficientes para as cargas de trabalho da TPU. Para saber mais, consulte Como o Kubernetes aplica solicitações e limites de recursos.
  2. Não há limite de CPU (ilimitado) para garantir que os pods possam ter um burst para usar todos os ciclos não utilizados.
  3. Defina limites de memória adequados para garantir que os pods funcionem corretamente sem o risco de remoção da pressão do nó.

Se um pod do Kubernetes não solicitar CPU e memória (mesmo que esteja solicitando TPUs), o Kubernetes o considerará um pod de melhor esforço e não haverá garantia de que ele precisará de CPU e memória. Somente os pods que solicitam explicitamente a CPU e a memória têm essas garantias. Para mais informações, consulte Gerenciamento de recursos para pods e contêineres.

Para saber mais sobre as práticas recomendadas, consulte Práticas recomendadas do Kubernetes: solicitações e limites de recursos.

Reduzir a interrupção da carga de trabalho

Se você estiver usando TPUs para treinar um modelo de machine learning e a carga de trabalho for interrompida, todo o trabalho realizado desde o último checkpoint será perdido. Para diminuir a probabilidade de interrupção da carga de trabalho, faça o seguinte:

  • Defina uma prioridade mais alta para este job do que todos os outros jobs: se os recursos forem escassos, o programador do GKE antecipa os jobs de menor prioridade para programar um job de prioridade mais alta. Isso também garante que a carga de trabalho com prioridade mais alta receba todos os recursos necessários (até o total de recursos disponíveis no cluster). Para saber mais, consulte Prioridade e preempção do pod.
  • Configurar a exclusão de manutenção: uma exclusão de manutenção é uma janela de tempo não recorrente durante a qual a manutenção automática é proibida. Para saber mais, consulte Exclusões de manutenção.
  • Use pods de tempo de execução prolongado no Autopilot: use pods de tempo de execução estendido por um período de carência de até sete dias antes que o GKE encerre seus pods para redução de escala ou upgrade de nós.

Lidar com interrupções devido à manutenção do nó

Todos os nós do GKE, incluindo aqueles que contêm TPUs, estão sujeitos a eventos de manutenção ou outras interrupções que podem causar o encerramento do nó. É possível reduzir as interrupções nas cargas de trabalho em execução nos clusters do GKE com o plano de controle executando a versão 1.29.1-gke.1425000 e posterior. O GKE alerta os nós de um encerramento iminente enviando um sinal SIGTERM ao nó até 5 minutos antes das remoções. Se a carga de trabalho usar um framework de ML, como MaxText, Pax ou JAX com o Orbax, as cargas de trabalho vão poder capturar o sinal SIGTERM e iniciar um processo de checkpoint.

É possível configurar o GKE para encerrar as cargas de trabalho de ML de maneira otimizada com o tempo máximo de notificação. No manifesto do pod, defina o campo spec.terminationGracePeriodSeconds como 300 segundos (cinco minutos). O GKE se esforça para encerrar esses pods da melhor maneira possível e executar a ação de encerramento definida por você, por exemplo, salvando um estado de treinamento. O GKE respeita qualquer configuração de até 5 minutos para as configurações PodDisruptionBudget ou terminationGracePeriodSeconds. ,

O campo spec.terminationGracePeriodSeconds gerencia apenas interrupções devido a eventos de manutenção e desfragmentação que ocorrem em VMs não preemptivas. O GKE não processa interrupções involuntárias, como falhas de hardware.

Para saber mais, consulte Configurar o encerramento automático do nó de fração da TPU.

Maximize a utilização da TPU

Para maximizar seu investimento em TPUs, programe uma combinação de prioridades de job e coloque-as em fila para maximizar o tempo de operação das TPUs. Se você quiser a programação e a preempção no nível do job, será necessário usar um complemento para o Kubernetes que organize os jobs em filas. Recomendamos usar o Kueue para esse caso de uso.

A seguir