Esta página foi traduzida pela API Cloud Translation.

Implantar cargas de trabalho de TPU no GKE Standard

Standard

Esta página oferece uma base para aprender a acelerar cargas de trabalho de machine learning (ML) usando TPUs no Google Kubernetes Engine (GKE). As TPUs são projetadas para processamento de multiplicação de matrizes, como treinamento de modelos de aprendizado profundo em grande escala. As TPUs são otimizadas para processar os enormes conjuntos de dados e modelos complexos de ML. Por isso, são mais econômicas e eficientes em termos de energia para cargas de trabalho de ML devido ao desempenho superior. Neste guia, você vai aprender a implantar cargas de trabalho de ML usando aceleradores da Cloud TPU, configurar cotas para TPUs, configurar upgrades para pools de nós que executam TPUs e monitorar métricas de carga de trabalho de TPU.

Este tutorial é destinado a engenheiros de machine learning (ML) e administradores e operadores de plataforma interessados em usar a orquestração de contêineres do Kubernetes para gerenciar treinamento, ajuste e inferência de modelos em grande escala usando TPUs. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Antes de ler esta página, confira se você conhece os seguintes conceitos:

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação: em instalações prévias da gcloud CLI, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na gcloud CLI como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Planejar a configuração da TPU

Planeje a configuração de TPU com base no modelo e na quantidade de memória necessária. Antes de usar este guia para implantar suas cargas de trabalho na TPU, conclua as etapas de planejamento em Planejar a configuração da TPU.

Verifique se você tem uma cota de TPU

As seções a seguir ajudam a garantir que você tenha cota suficiente ao usar TPUs no GKE.

Cota para VMs spot ou sob demanda

Se você estiver criando um pool de nós de fração de TPU com VMs spot ou sob demanda, é preciso ter cota de TPU suficiente disponível na região que você quer usar.

A criação de um pool de nós de fração de TPU que consome uma reserva de TPU não exige nenhuma cota de TPU.¹ É possível pular essa etapa com segurança para TPUs reservadas.

Criar um pool de nós de fração de TPU sob demanda ou Spot no GKE requer cota da API Compute Engine. A cota da API Compute Engine (compute.googleapis.com) não é igual à cota da API Cloud TPU (tpu.googleapis.com), que é necessária para criar TPUs com a API Cloud TPU.

Para verificar o limite e o uso atual da sua cota da API Compute Engine para TPUs, siga estas etapas:

Acesse a página Cotas no console do Google Cloud :

Acessar "Cotas"

Na caixa Filtro , faça o seguinte:

Use a tabela a seguir para selecionar e copiar a propriedade da cota com base na versão da TPU e no tipo de máquina. Por exemplo, se você planeja criar nós da TPU v5e sob demanda com o tipo de máquina que começa com ct5lp-, digite Name: TPU v5 Lite PodSlice chips.

Versão da TPU, o tipo de máquina começa com	Propriedade e nome da cota para instâncias sob demanda	Propriedade e nome da cota para instâncias Spot²
TPU v3, `ct3-`	Dimensions (e.g. location): tpu_family:CT3	Não relevante
TPU v3, `ct3p-`	Dimensions (e.g. location): tpu_family:CT3P	Não relevante
TPU v4, `ct4p-`	Name: TPU v4 PodSlice chips	Name: Preemptible TPU v4 PodSlice chips
TPU v5e, `ct5lp-`	Name: TPU v5 Lite PodSlice chips	Name: Preemptible TPU v5 Lite Podslice chips
TPU v5p, `ct5p-`	Name: TPU v5p chips	Name: Preemptible TPU v5p chips
TPU Trillium, `ct6e-`	Dimensions (e.g. location): tpu_family:CT6E	Name: Preemptible TPU slices v6e

Selecione a propriedade Dimensões (por exemplo, locais) e insira region: seguido do nome da região em que você planeja criar TPUs no GKE. Por exemplo, insira region:us-west4 se planeja criar nós de fração da TPU na zona us-west4-a. A cota de TPU é regional, portanto, todas as zonas na mesma região consomem a mesma cota de TPU.

Se nenhuma cota corresponder ao filtro inserido, isso significa que o projeto não recebeu nenhuma das cotas especificadas para a região desejada. Você precisará solicitar um ajuste de cota de TPU.

Quando uma reserva de TPU é criada, os valores de limite e de uso atual da cota correspondente aumentam pelo número de ícones na reserva da TPU. Por exemplo, quando uma reserva é criada para 16 chips de TPU v5e com tipo de máquina que começa com ct5lp-, o Limite e o Uso atual para a cota de TPU v5 Lite PodSlice chips na região relevante aumentam em 16.

Ao criar um pool de nós de fração de TPU, use as flags --reservation e --reservation-affinity=specific para criar uma instância reservada. As reservas de TPU estão disponíveis ao comprar um compromisso. ↩
Ao criar um pool de nós de fração de TPU, use a flag --spot para criar uma instância de Spot. ↩

Cotas para outros recursos do GKE

Talvez seja necessário aumentar as seguintes cotas relacionadas ao GKE nas regiões em que o GKE cria seus recursos.

Cota de SSD de disco permanente (GB): o disco de inicialização de cada nó do Kubernetes requer 100 GB por padrão. Portanto, essa cota precisa ser definida pelo menos tão alta quanto o produto do número máximo de nós do GKE que você espera criar e 100 GB (nós * 100 GB).
Cota de endereços IP em uso: cada nó do Kubernetes consome um endereço IP. Portanto, essa cota precisa ser definida pelo menos tão alta quanto o número máximo de nós do GKE que você prevê que serão criados.
Verifique se max-pods-per-node está alinhado com o intervalo da sub-rede: cada nó do Kubernetes usa intervalos de IP secundários para pods. Por exemplo, max-pods-per-node de 32 requer 64 endereços IP, o que se traduz em uma sub-rede /26 por nó. Esse intervalo não pode ser compartilhado com nenhum outro cluster. Para evitar o esgotamento do intervalo de endereços IP, use a flag --max-pods-per-node para limitar o número de pods que podem ser programados em um nó. A cota para max-pods-per-node precisa ser definida pelo menos tão alta quanto o número máximo de nós do GKE que você prevê que serão criados.

Para solicitar um aumento de cota, consulte Solicitar um ajuste de cota.

Garantir a disponibilidade de reserva

Para criar um pool de nós de fração de TPU usando uma reserva, ela precisa ter chips de TPU disponíveis suficientes no momento da criação do pool de nós.

Para ver quais reservas existem em um projeto e quantos chips de TPU estão disponíveis em uma reserva de TPU, confira uma lista de suas reservas.

Opções para provisionar TPUs no GKE

O GKE permite usar TPUs diretamente em cargas de trabalho individuais usando nodeSelectors do Kubernetes no manifesto da carga de trabalho ou criando pools de nós do modo Standard com TPUs.

Como alternativa, é possível solicitar TPUs usando classes de computação personalizadas. Com as classes de computação personalizadas, os administradores de plataforma podem definir uma hierarquia de configurações de nós para o GKE priorizar durante as decisões de escalonamento de nós, para que as cargas de trabalho sejam executadas no hardware selecionado.

Para instruções, consulte a seção Provisionar TPUs usando classes de computação personalizadas.

Criar um cluster

Crie um cluster do GKE no modo padrão em uma região com TPUs disponíveis.

Prática recomendada:

Use clusters regionais, que fornecem alta disponibilidade do plano de controle do Kubernetes.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Substitua:

CLUSTER_NAME: o nome do novo cluster;
LOCATION: a região com sua capacidade de TPU disponível.
VERSION: a versão do GKE, que precisa ser compatível com o tipo de máquina que você quer usar. A versão padrão do GKE pode não ter disponibilidade para sua TPU de destino. Para saber quais são as versões mínimas do GKE disponíveis por tipo de máquina de TPU, consulte Disponibilidade de TPU no GKE.

Crie um pool de nós.

É possível criar um pool de nós de fração de TPU de host único ou de vários hosts.

Criar um pool de nós de fração de TPU de host único

É possível criar um pool de nós de fatia da TPU de host único usando a Google Cloud CLI, o Terraform ou o console Google Cloud .

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

Substitua:

NODE_POOL_NAME: o nome do novo pool de nós.
LOCATION: o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
CLUSTER_NAME: o nome do cluster.
NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
MACHINE_TYPE: o tipo de máquina a ser usado para nós. Para mais informações sobre os tipos de máquinas compatíveis com TPU, use a tabela em Escolher a versão da TPU.

Opcionalmente, é possível usar as seguintes sinalizações:

--num-nodes=NUM_NODES: o número inicial de nós no pool de nós em cada zona. Se você omitir essa flag, o GKE vai atribuir o padrão 3.

Prática recomendada:
Se você usar a flag enable-autoscaling para o pool de nós, defina num-nodes como 0 para que o escalonador automático provisione nós adicionais assim que suas cargas de trabalho exigirem.
--reservation=RESERVATION_NAME: o nome da reserva que o GKE usa ao criar o pool de nós. Se você omitir essa sinalização, o GKE usará as TPUs disponíveis. Para saber mais sobre reservas de TPU, consulte Sobre reservas de Cloud TPU.
--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: informa ao GKE que o pool de nós de fração de TPU de host único faz parte de uma coleção. Use essa flag se as seguintes condições forem verdadeiras:
- O pool de nós executa a carga de trabalho de inferência no novo pool.
- O pool de nós usa a TPU Trillium.
- O pool de nós não usa VMs spot.
Para saber mais sobre o gerenciamento de programação de coleta, consulte Gerenciar a programação de coleta em frações de TPU de host único.
--enable-autoscaling: adicionar um pool de nós com escalonamento automático ativado. Requer as seguintes flags adicionais:
- --total-min-nodes=TOTAL_MIN_NODES: o número mínimo de nós no pool de nós.
- --total-max-nodes=TOTAL_MAX_NODES: o número máximo de todos os nós no pool de nós.
- --location-policy=ANY: prioriza o uso de reservas não utilizadas e reduz o risco de preempção das VMs spot.
--spot: define o pool de nós para usar VMs spot para os nós no pool de nós. Isso não pode ser alterado após a criação do pool de nós.
--flex-start: define o pool de nós para usar VMs de início flexível. As VMs de início flexível são criadas usando a opção de consumo flex-start, que é compatível com a versão 1.33.0-gke.1712000 ou mais recente do GKE.
--sandbox=type=gvisor: provisiona um nó com o GKE Sandbox ativado. Requer TPU v4 e versões mais recentes. Para mais informações, consulte GKE Sandbox.

Para uma lista completa de todas as flags que podem ser especificadas, consulte a referência gcloud container clusters create.

Terraform

Use a versão 4.84.0 ou mais recente do provedor google.
Adicione o seguinte bloco à configuração do Terraform:

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Substitua:

NODE_POOL_RESOURCE_NAME: o nome do recurso do pool de nós no modelo do Terraform.
PROJECT_ID: o ID do projeto.
CLUSTER_NAME: o nome do cluster existente.
POOL_NAME: o nome do pool de nós a ser criado.
CLUSTER_LOCATION: as zonas de computação do cluster. Especifique a região em que a versão da TPU está disponível. Para saber mais, consulte Selecionar uma versão de TPU e topologia.
NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
MACHINE_TYPE: o tipo de máquina da TPU a ser usada. Para ver os tipos de máquina compatíveis com a TPU, use a tabela em Escolher a versão da TPU.

Também é possível usar as seguintes variáveis:

autoscaling: Adicionar um pool de nós com escalonamento automático ativado. Para uma fração de TPU de host único, o GKE faz o escalonamento entre os valores TOTAL_MIN_NODES e TOTAL_MAX_NODES.
- TOTAL_MIN_NODES: O número mínimo de nós no pool. Esse campo é opcional, a menos que o escalonamento automático também seja especificado.
- TOTAL_MAX_NODES: o número máximo de todos os nós no pool. Esse campo é opcional, a menos que o escalonamento automático também seja especificado.
RESERVATION_NAME: se você usar Sobre as reservas do Cloud TPU, esta será a lista de rótulos dos recursos de reserva a serem usados ao criar o pool de nós. Para saber como preencher o RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte Provedor do Terraform.
spot: define o pool de nós para usar VMs do Spot nos nós da TPU. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.
flex_start: define o pool de nós para usar a opção de consumo flex-start. Não pode ser definido como true se spot estiver ativado. O início flexível é compatível com a versão 1.33.0-gke.1712000 ou mais recente do GKE.

Console

Para criar um pool de nós com TPUs:

Acesse a página do Google Kubernetes Engine no Google Cloud console.

Acessar o Google Kubernetes Engine
Na lista de clusters, clique no nome do cluster que você quer modificar.
Clique em Adicionar pool de nós.
Na seção Detalhes do pool de nós, marque a caixa Especificar locais do nó.
Selecione a zona com base na versão de TPU que você quer usar. Para identificar uma zona disponível, consulte Disponibilidade da TPU no GKE.
No painel de navegação, clique em Nós.
Na seção Configuração da máquina, selecione TPUs.
No menu suspenso Série, selecione uma das seguintes opções:
- CT3: TPU v3, dispositivo de host único
- CT3P: TPU v3, fração de pod de vários hosts
- CT4P: TPU v4.
- CT5LP: TPU v5e
- CT5P: TPU v5p
- CT6E: TPU Trillium (v6e)
No menu suspenso Tipo de máquina, selecione o nome da máquina que será usada para os nós. Use a tabela Escolher a versão da TPU para saber como definir o tipo de máquina e a topologia de TPU que criam um pool de nós de fração de TPU de host único.
No menu suspenso Topologia da TPU, selecione a topologia física para a fatia da TPU.
Na caixa de diálogo Alterações necessárias, clique em Fazer alterações.
Certifique-se de que o Tipo de disco de inicialização seja Disco permanente padrão ou Disco permanente SSD.
Se quiser, marque a caixa de seleção Ativar nós em VMs do Spot para usar as VMs do Spot nos nós do pool.
Clique em Criar.

Criar um pool de nós de fração de TPU com vários hosts

É possível criar um pool de nós de fração de TPU de vários hosts usando a Google Cloud CLI, o Terraform ou o console do Google Cloud .

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    [--num-nodes=NUM_NODES] \
    [--spot \]
    [--flex-start \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
    [--placement-type=COMPACT]

Substitua:

POOL_NAME: o nome do novo pool de nós.
LOCATION: o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
CLUSTER_NAME: o nome do cluster.
NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
MACHINE_TYPE: o tipo de máquina a ser usado para nós. Para saber mais sobre os tipos de máquina disponíveis, consulte Escolher a versão da TPU.
TPU_TOPOLOGY: a topologia física da fatia de TPU. O formato da topologia depende da versão da TPU. Para saber mais sobre topologias de TPU, use a tabela em Escolher uma topologia.

Para saber mais, consulte Topologia.

Opcionalmente, é possível usar as seguintes sinalizações:

NUM_NODES: o número de nós no pool de nós. Precisa ser zero ou o produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada VM. Para a TPU v4e de vários hosts e a TPU v5e, o número de chips em cada VM é quatro. Portanto, se a TPU_TOPOLOGY for 2x4x4 (TPU v4 com quatro chips em cada VM), a NUM_NODES será 32/4, que é igual a 8. Se você omitir essa flag, o número de nós será calculado e definido como padrão com base na topologia e no tipo de máquina.
RESERVATION_NAME: o nome da reserva que o GKE usa ao criar o pool de nós. Se você omitir essa sinalização, o GKE usará pools de nós da TPU de fração disponíveis. Para saber mais sobre reservas de TPU, consulte Reserva de TPU.
--spot: define o pool de nós para usar VMs do Spot nos nós da TPU de nós de fração. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.
--flex-start: define o pool de nós para usar VMs de início flexível. As VMs de início flexível são criadas usando a opção de consumo flex-start, que é compatível com a versão 1.33.0-gke.1712000 ou mais recente do GKE.
--enable-autoscaling: adicionar um pool de nós com escalonamento automático ativado. Quando o GKE escalona um pool de nós de uma fração da TPU de vários hosts, ele escalona horizontalmente e de maneira atomizada esse pool de nós de zero até o tamanho máximo.
- MAX_NODES: o tamanho máximo do pool de nós. A flag --max-nodes será obrigatória se --enable-autoscaling for fornecido e precisar ser igual ao produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de ícones para cada VM.
--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: informa ao GKE que o pool de nós de fração de TPU de vários hosts é uma coleção. Use essa flag se as seguintes condições forem verdadeiras:
- O pool de nós executa cargas de trabalho de inferência no novo pool de nós.
- O pool de nós usa a TPU Trillium.
- As VMs spot não são compatíveis com o agendamento de coleta.
Para saber mais sobre o gerenciamento da programação de coleta, consulte Gerenciar a programação de coleta em frações de TPU de vários hosts.
--placement-type=COMPACT: crie um pool de nós com o posicionamento compacto ativado. Essa opção precisa ser usada com a flag --tpu-topology. Para mais informações, consulte Criar uma política de posicionamento compacto e Topologia de TPU.

Terraform

Use a versão 4.84.0 ou mais recente do provedor google.
Adicione o seguinte bloco à configuração do Terraform:
```
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]
  initial_node_count = NUM_NODES

  autoscaling {
    max_node_count = MAX_NODES
    location_policy      = "ANY"
  }
  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }

  placement_policy {
    type = "COMPACT"
    tpu_topology = TPU_TOPOLOGY
  }
}
```
Substitua:
- NODE_POOL_RESOURCE_NAME: o nome do recurso do pool de nós no modelo do Terraform.
- PROJECT_ID: o ID do projeto.
- CLUSTER_NAME: o nome do cluster atual ao qual o pool de nós será adicionado.
- POOL_NAME: o nome do pool de nós a ser criado.
- CLUSTER_LOCATION: local do Compute do cluster. Recomendamos ter um cluster regional para aumentar a confiabilidade do plano de controle do Kubernetes. Também é possível usar um cluster zonal. Para saber mais, consulte Selecionar uma versão de TPU e topologia.
- NODE_ZONES: a lista separada por vírgulas de uma ou mais zonas em que o GKE cria o pool de nós.
- NUM_NODES: o número de nós no pool de nós. Esse valor precisa ser zero ou o produto do número de chips de TPU dividido por quatro. Isso acontece porque, nas frações da TPU de vários hosts, cada nó de TPU de fração tem quatro chips. Por exemplo, se TPU_TOPOLOGY for 4x8, haverá 32 chips, o que significa que NUM_NODES precisa ser 8. Para saber mais sobre topologias de TPU, use a tabela em Escolher a versão da TPU.
- TPU_TOPOLOGY: indica a topologia física desejada para a fração de TPU. O formato da topologia depende da versão da TPU usada. Para saber mais sobre topologias de TPU, use a tabela em Escolher uma topologia.
Também é possível usar as seguintes variáveis:
- RESERVATION_NAME: se você usar a reserva de TPU, esta será a lista de rótulos dos recursos de reserva a serem usados ao criar o pool de nós. Para saber como preencher o RESERVATION_LABEL_VALUES no campo reservation_affinity, consulte Provedor do Terraform.
- autoscaling: adicionar um pool de nós com escalonamento automático ativado. Quando o GKE escalona um pool de nós de uma fração da TPU de vários hosts, ele escalona horizontalmente e de maneira atomizada esse pool de nós de zero até o tamanho máximo.
  - MAX_NODES: o tamanho máximo do pool de nós. Ele precisa ser zero ou o produto dos valores definidos em TPU_TOPOLOGY ({A}x{B}x{C}) dividido pelo número de chips em cada VM.
- spot: permite que o pool de nós use VMs spot para os nós de fração de TPU. Isso não pode ser alterado após a criação do pool de nós. Para mais informações, consulte VMs spot.
- flex_start: define o pool de nós para usar a opção de consumo flex-start. Não pode ser definido como true se spot estiver ativado.

Console

Para criar um pool de nós com TPUs:

Acesse a página do Google Kubernetes Engine no Google Cloud console.

Acessar o Google Kubernetes Engine
Na lista de clusters, clique no nome do cluster que você quer modificar.
Clique em Adicionar pool de nós.
Na seção Detalhes do pool de nós, marque a caixa Especificar locais do nó.
Selecione o nome da zona com base na versão da TPU que você quer usar. Para identificar um local disponível, consulte Disponibilidade da TPU no GKE.
No painel de navegação, clique em Nós.
Na seção Configuração da máquina, selecione TPUs.
No menu suspenso Série, selecione uma das seguintes opções:
- CT3P: para a TPU v3.
- CT4P: para a TPU v4.
- CT5LP: para a TPU v5e.
No menu suspenso Tipo de máquina, selecione o nome da máquina que será usada para os nós. Use a tabela Escolher a versão da TPU para saber como definir o tipo de máquina e a topologia de TPU que criam um pool de nós de fração de TPU de vários hosts.
No menu suspenso Topologia da TPU, selecione a topologia física para a fatia da TPU.
Na caixa de diálogo Alterações necessárias, clique em Fazer alterações.
Certifique-se de que o Tipo de disco de inicialização seja Disco permanente padrão ou Disco permanente SSD.
Como opção, marque a caixa de seleção Ativar nós em VMs do Spot para usar VMs do Spot nos nós do pool de nós.
Clique em Criar.

Como o GKE lida com problemas de capacidade

Se o GKE não conseguir criar o pool de nós de fração de TPU devido à capacidade insuficiente de TPU, o GKE retornará uma mensagem de erro indicando que não é possível criar os nós de fração de TPU por falta de capacidade.

Se você estiver criando um pool de nós de fração de TPU de host único, a mensagem de erro será semelhante a esta:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Se você estiver criando um pool de nós de fração de TPU com vários hosts, a mensagem de erro será semelhante a esta:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

Sua solicitação de provisionamento de TPU pode permanecer na fila por muito tempo e permanece no estado "Provisionando" enquanto está na fila.

Quando a capacidade fica disponível, o GKE cria os nós restantes que não foram criados.

Caso você precise de capacidade antes, teste as VMs spot. No entanto, é importante lembrar que as VMs spot consomem uma cota diferente das instâncias sob demanda.

É possível excluir a solicitação de TPU na fila excluindo o pool de nós de fatias de TPU.

Executar a carga de trabalho em nós de fração da TPU

Esta seção explica como preparar suas cargas de trabalho e exemplos de como executá-las.

Preparar suas cargas de trabalho

As cargas de trabalho de TPU têm os requisitos de preparação a seguir.

Frameworks como JAX, PyTorch e TensorFlow acessam VMs de TPU usando a biblioteca compartilhada libtpu. libtpu inclui o compilador XLA, o software do ambiente de execução da TPU e o driver da TPU. Cada versão do PyTorch e do JAX requer uma determinada versão de libtpu.so. Para evitar conflitos de versão de pacote, recomendamos usar uma imagem de IA do JAX. Para usar TPUs no GKE, use as seguintes versões:

Tipo de TPU	Versão do `libtpu.so`
TPU Trillium (v6e) `tpu-v6e-slice`	Imagem de IA do JAX recomendada: jax0.4.35-rev1 ou mais recente Versão recomendada do jax[tpu]: v0.4.9 ou posterior Versão recomendada do torchxla[tpuvm]: v2.1.0 ou mais recente
TPU v5e `tpu-v5-lite-podslice`	Imagem de IA do JAX recomendada: jax0.4.35-rev1 ou mais recente Versão recomendada do jax[tpu]: v0.4.9 ou posterior Versão recomendada do torchxla[tpuvm]: v2.1.0 ou mais recente
TPU v5p `tpu-v5p-slice`	Imagem de IA do JAX recomendada: jax0.4.35-rev1 ou mais recente Versão recomendada do jax[tpu]: 0.4.19 ou mais recente. Versão recomendada do torchxla[tpuvm]: sugestão de uso de um build de versão noturno em 23 de outubro de 2023.
TPU v4 `tpu-v4-podslice`	Imagem de IA do JAX recomendada: jax0.4.35-rev1 ou mais recente jax[tpu] recomendado: v0.4.4 ou mais recente Versão recomendada do torchxla[tpuvm]: v2.0.0 ou mais recente
TPU v3 `tpu-v3-slice` `tpu-v3-device`	Imagem de IA do JAX recomendada: jax0.4.35-rev1 ou mais recente jax[tpu] recomendado: v0.4.4 ou mais recente Versão recomendada do torchxla[tpuvm]: v2.0.0 ou mais recente

Defina as variáveis de ambiente a seguir para o contêiner que solicita os recursos da TPU:
- TPU_WORKER_ID: um número inteiro exclusivo para cada pod. Esse ID denota um código de worker exclusivo na fatia de TPU. Os valores aceitos para esse campo variam de zero ao número de pods menos um.
- TPU_WORKER_HOSTNAMES: uma lista separada por vírgulas de nomes de host ou endereços IP de VM da TPU que precisam se comunicar entre si na fatia. É necessário que haja um nome do host ou endereço IP para cada VM da TPU na fatia. A lista de endereços IP ou nomes do host é ordenada e zero indexada pelo TPU_WORKER_ID.
- No manifesto da carga de trabalho, adicione seletores de nós do Kubernetes para garantir que o GKE programe a carga de trabalho da TPU no tipo de máquina e na topologia de TPU definidos:
```
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  
```
  Substitua:
  - TPU_ACCELERATOR: o nome do acelerador de TPU.
  - TPU_TOPOLOGY: a topologia física da fração da TPU. O formato da topologia depende da versão da TPU. Para saber mais, consulte Planejar TPUs no GKE.

Depois de concluir a preparação da carga de trabalho, é possível executar um job que usa TPUs.

As seções a seguir mostram exemplos de como executar um job que realiza computação básica com TPUs.

Exemplo 1: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis em um pool de nós de fração da TPU

A carga de trabalho a seguir retorna o número de chips de TPU em todos os nós em uma fração de TPU de vários hosts. Para criar uma fração de vários hosts, a carga de trabalho tem os seguintes parâmetros:

Versão do TPU: TPU v4
Topologia: 2x2x4

Essa seleção de versão e topologia resultam em uma fração de vários hosts.

Salve o seguinte manifesto como available-chips-multihost.yaml:

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-available-chips
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-available-chips
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.

Implante o manifesto:
```
kubectl create -f available-chips-multihost.yaml
```
O GKE executa uma fatia da TPU v4 com quatro VMs (fatia da TPU de vários hosts). A fração tem 16 chips de TPU interconectados.

Verifique se o job criou quatro pods:

kubectl get pods

O resultado será assim:

NAME                       READY   STATUS      RESTARTS   AGE
tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s

Consiga os registros de um dos pods:
```
kubectl logs POD_NAME
```
Substitua POD_NAME pelo nome de um dos pods criados. Por exemplo, tpu-job-podslice-0-5cd8r.

O resultado será assim:
```
TPU cores: 16
```

Opcional: remova a carga de trabalho:

kubectl delete -f available-chips-multihost.yaml

Exemplo 2: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis na fração de TPU

A carga de trabalho a seguir é um pod estático que exibe o número de chips de TPU anexados a um nó específico. Para criar um nó de host único, a carga de trabalho tem os seguintes parâmetros:

Versão do TPU: TPU v5e
Topologia: 2x4

Essa seleção de versão e topologia resultam em uma fração de host único.

Salve o seguinte manifesto como available-chips-singlehost.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: tpu-job-jax-v5
spec:
  restartPolicy: Never
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    securityContext:
      privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.

Implante o manifesto:
```
kubectl create -f available-chips-singlehost.yaml
```
O GKE provisiona nós com oito frações de TPU de host único que usam a TPU v5e. Cada nó de TPU tem oito chips de TPU (fração de TPU de host único).
Consiga os registros do pod:
```
kubectl logs tpu-job-jax-v5
```
O resultado será assim:
```
Total TPU chips: 8
```

Opcional: remova a carga de trabalho:

  kubectl delete -f available-chips-singlehost.yaml

Fazer upgrade de pools de nós usando aceleradores (GPUs e TPUs)

O GKE faz upgrade automático de clusters Padrão, incluindo pools de nós. Também é possível fazer upgrade manual dos pools de nós se quiser que seus nós usem uma versão mais recente antecipadamente. Para controlar como os upgrades funcionam no cluster, use os canais de lançamento, janelas de manutenção e exclusões e sequenciamento de lançamento.

Também é possível configurar uma estratégia de upgrade de nós para o pool de nós, como upgrades súbitos, upgrades azul-verde ou upgrades de curta duração. Ao configurar essas estratégias, é possível garantir que o upgrade dos pools de nós ocorra de uma maneira que atinja o equilíbrio ideal entre velocidade e interrupção do seu ambiente. Para pools de nós de fração de TPU de vários hosts, em vez de usar a estratégia de upgrade de nós configurada, o GKE recria atomicamente todo o pool de nós em uma única etapa. Para saber mais, consulte a definição de atomicidade em Terminologia relacionada à TPU no GKE.

O uso de uma estratégia de upgrade de nó exige temporariamente que o GKE provisione recursos adicionais, dependendo da configuração. Se Google Cloud tiver capacidade limitada para os recursos do pool de nós, por exemplo, se você estiver enfrentando erros de disponibilidade de recursos ao tentar criar mais nós com GPUs ou TPUs, consulte Fazer upgrade em um ambiente limitado de recursos.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste guia, considere excluir os pools de nós de fração de TPU que não têm mais cargas de trabalho programadas. Se as cargas de trabalho em execução precisarem ser encerradas normalmente, use kubectl drain para limpá-las antes de excluir o nó.

Exclua um pool de nós de fração da TPU:
```
gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME
```
Substitua:
- POOL_NAME: o nome do pool de nós.
- CLUSTER_NAME: o nome do cluster.
- LOCATION: o local de computação do cluster.

Definir outras configurações

Nas seções a seguir, descrevemos as configurações adicionais que você pode aplicar às cargas de trabalho da TPU.

Gerenciar o agendamento de coleta

No TPU Trillium, é possível usar o agendamento de coleta para agrupar nós de fração de TPU. Agrupar esses nós de fração de TPU facilita o ajuste do número de réplicas para atender à demanda da carga de trabalho.O Google Cloud controla as atualizações de software para garantir que sempre haja frações suficientes disponíveis na coleção para atender ao tráfego.

A TPU Trillium oferece suporte ao agendamento de coleta para pools de nós de host único e vários hosts que executam cargas de trabalho de inferência. A seguir, descrevemos como o comportamento do agendamento de coleta depende do tipo de fração de TPU usada:

Fração de TPU de vários hosts:o GKE agrupa frações de TPU de vários hosts para formar uma coleção. Cada pool de nós do GKE é uma réplica nessa coleção. Para definir uma coleção, crie uma fração de TPU de vários hosts e atribua um nome exclusivo a ela. Para adicionar mais frações de TPU à coleção, crie outro pool de nós de fração de TPU de vários hosts com o mesmo nome de coleção e tipo de carga de trabalho.
Fração de TPU de host único:o GKE considera todo o pool de nós de fração de TPU de host único como uma coleção. Para adicionar mais frações de TPU à coleção, redimensione o pool de nós de fração de TPU de host único.

Para gerenciar uma coleção, realize uma destas ações com base no tipo de pool de nós que você usa.

Gerenciar o agendamento de coleta em pools de nós de frações de TPU de vários hosts

Use as tarefas a seguir para gerenciar pools de nós de frações de TPU com vários hosts.

Para verificar se um pool de fração de TPU de vários hosts faz parte de uma coleção, execute o seguinte comando:

gcloud container node-pools describe NODE_POOL_NAME \
    --location LOCATION \
    --cluster CLUSTER_NAME \
    --format="json" | jq -r \
    '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'

O resultado será assim:

nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
gke-workload-type: HIGH_AVAILABILITY

Se o pool de fração de TPU de vários hosts fizer parte de uma coleção, a saída terá os seguintes rótulos:

cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>

Para receber a lista de coleções no cluster, execute o seguinte comando:

#!/bin/bash

# Replace with your cluster name, project, and location
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

declare -A collection_names

node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Describe the node pool and extract labels using jq
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Add the collection name to the associative array if it's not empty
    if [[ -n "$collection_name" ]]; then
        collection_names["$collection_name"]=1
    fi
done

# Print the unique node pool collection names
echo "Unique cloud.google.com/gke-nodepool-group-name values:"
for name in "${!collection_names[@]}"; do
    echo "$name"
done

O resultado será assim:

Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}

Para conferir uma lista de pools de nós que pertencem a uma coleção, execute o seguinte comando:

#!/bin/bash

TARGET_COLLECTION_NAME=COLLECTION_NAME
CLUSTER_NAME=CLUSTER_NAME
PROJECT=PROJECT_ID
LOCATION=LOCATION

matching_node_pools=()

# Get the list of all node pools in the cluster
node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")

# Iterate over each node pool
for pool in $node_pools; do
    # Get the value of the cloud.google.com/gke-nodepool-group-name label
    collection_name=$(gcloud container node-pools describe "$pool" \
        --cluster "$CLUSTER_NAME" \
        --project "$PROJECT" \
        --location "$LOCATION" \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')

    # Check if the group name matches the target value
    if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
        matching_node_pools+=("$pool")
    fi
done

# Print the list of matching node pools
echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
for pool in "${matching_node_pools[@]}"; do
    echo "$pool"
done

O resultado será assim:

Node pools with collection name 'COLLECTION_NAME':
{NODE_POOL_NAME_1}
{NODE_POOL_NAME_2}
{NODE_POOL_NAME_3}

Para escalonar verticalmente da coleta, crie outro pool de nós de fração de TPU de vários hosts e adicione cloud.google.com/gke-workload-type e cloud.google.com/gke-nodepool-group-name. Use o mesmo nome de coleção em cloud.google.com/gke-nodepool-group-name e execute o mesmo tipo de carga de trabalho. Se o provisionamento automático de nós estiver ativado no cluster, o GKE vai criar pools automaticamente com base nas demandas de carga de trabalho.
Para reduzir escala vertical da coleta, exclua o pool de nós.
Para excluir a coleção, remova todos os pools de nós anexados. É possível excluir o pool de nós ou excluir o cluster. A exclusão do cluster remove todas as coleções nele.

Gerenciar o agendamento de coleta em pools de nós de fração de TPU de host único

Use as tarefas a seguir para gerenciar pools de nós de fração de TPU de host único.

Para verificar se um pool de fração de TPU de host único tem o agendamento de coleta ativado, execute o seguinte comando:
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --project PROJECT_NAME \
    --location LOCATION \
    --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
```
O resultado será assim:
```
gke-workload-type: HIGH_AVAILABILITY
```
Se o pool de fração de TPU de host único fizer parte de uma coleção, a saída terá o rótulo cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.
Para escalonar verticalmente da coleta, redimensione o pool de nós manualmente ou automaticamente com o provisionamento automático de nós.
Para reduzir escala vertical da coleta, exclua o pool de nós.
Para excluir a coleção, remova todos os pools de nós anexados. É possível excluir o pool de nós ou excluir o cluster. A exclusão do cluster remove todas as coleções dele.

Usar Multislice

É possível agregar frações menores em um Multislice para lidar com cargas de trabalho de treinamento maiores. Para mais informações, consulte TPUs com vários setores no GKE.

Migrar sua reserva da TPU

Se você tiver reservas de TPU atuais, primeiro será necessário migrá-las para um novo sistema de reservas do Compute Engine. Também é possível criar um sistema de reservas com base no Compute Engine, em que nenhuma migração é necessária. Para saber como migrar suas reservas de TPU, consulte Reserva de TPU.

Ativar a geração de registros

Os registros emitidos por contêineres em execução em nós do GKE, incluindo VMs de TPU, sãocoletou pelo agente do Logging do GKE, enviado para o Logging e sãovisível no Logging do Google Analytics.

Usar o provisionamento automático de nós do GKE

É possível configurar o GKE para criar e excluir automaticamente pools de nós e atender às demandas de recursos das cargas de trabalho de TPU. Para mais informações, consulte Como configurar Cloud TPUs.

Provisionar TPUs usando classes de computação personalizadas

Também é possível configurar o GKE para solicitar TPUs durante operações de escalonamento que criam novos nós usando classes de computação personalizadas.

É possível especificar opções de configuração de TPU na especificação da classe de computação personalizada. Quando uma carga de trabalho do GKE usa essa classe de computação personalizada, o GKE tenta provisionar TPUs que usam a configuração especificada ao fazer escalonamento vertical.

Para provisionar TPUs com uma classe de computação personalizada que segue as regras de TPU e implantar a carga de trabalho, siga estas etapas:

Salve o seguinte manifesto como tpu-compute-class.yaml:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - spot: true
    tpu:
      type: tpu-v5-lite-podslice
      count: 4
      topology: 2x4
  - flexStart:
      enabled: true
    tpu:
      type: tpu-v6e-slice
      count: 4
      topology: 2x4
  nodePoolAutoCreation:
    enabled: true

Implante a classe de computação:
```
kubectl apply -f tpu-compute-class.yaml
```
Para mais informações sobre classes de computação personalizadas e TPUs, consulte Configuração de TPU.

Salve o seguinte manifesto como tpu-job.yaml:

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

Substitua:

NUMBER_OF_CHIPS: o número de chips de TPU para o contêiner usar. Precisa ser o mesmo valor para limits e requests, igual ao valor no campo tpu.count na classe de computação personalizada selecionada.
MEMORY_SIZE: a quantidade máxima de memória que a TPU usa. Os limites de memória dependem da versão e da topologia da TPU que você usa. Para saber mais, consulte Mínimos e máximos para aceleradores.
NUMBER_OF_CHIPS: o número de chips de TPU para o contêiner usar. Precisa ser o mesmo valor para limits e requests.

Implante o job:
```
kubectl create -f tpu-job.yaml
```
Quando você cria esse job, o GKE faz automaticamente o seguinte:
- Provisiona nós para executar os pods. Dependendo do tipo de TPU, topologia e solicitações de recursos especificados, esses nós são frações de host único ou de vários hosts. Dependendo da disponibilidade de recursos de TPU na prioridade mais alta, o GKE pode voltar a prioridades mais baixas para maximizar a capacidade de obtenção.
- Adiciona taints aos pods e tolerâncias aos nós para evitar que outras cargas de trabalho sejam executadas nos mesmos nós que as cargas de trabalho da TPU.
Para saber mais, consulte Sobre as classes de computação personalizadas.
Ao concluir esta seção, exclua os recursos criados para evitar o faturamento contínuo:
```
kubectl delete -f tpu-job.yaml
```

Configurar o reparo automático para nós de fração da TPU

Se um nó de fração da TPU em um pool de nós de fração da TPU com vários hosts não estiver íntegro, todo o pool de nós será recriado. Já em um pool de nós de fração de TPU de host único, apenas o nó de TPU não íntegro é reparado automaticamente.

As condições que resultam em nós de fração da TPU não íntegros incluem:

Qualquer nó de fração de TPU com condições de nó comuns.
Qualquer nó de fração de TPU com uma TPU não alocável é maior que zero.
Qualquer instância de VM em uma fração de TPU que seja interrompida (devido à preempção) ou encerrada.
Manutenção do nó: se algum nó da fração de TPU em um pool de nós da fração de TPU de vários hosts ficar inativo para manutenção do host, o GKE recriará todo o pool de nós da fração de TPU.

Veja o status do reparo (incluindo o motivo da falha) no histórico de operações. Se a falha for causada por cota insuficiente, entre em contato com o representante da conta doGoogle Cloud para aumentar a cota correspondente.

Configurar o encerramento automático para nós de fração da TPU

Nos clusters do GKE com o plano de controle em execução na versão 1.29.1-gke.1425000 ou posterior, os nós de fração da TPU são compatíveis com sinais SIGTERM que alertam o nó sobre um encerramento iminente. A notificação de encerramento iminente pode ser configurada em até cinco minutos em nós da TPU.

Para configurar o GKE para encerrar as cargas de trabalho normalmente dentro desse período de notificação, siga as etapas em Gerenciar a interrupção de nós do GKE para GPUs e TPUs.

Executar contêineres sem o modo privilegiado

Os contêineres em execução nos nós do GKE 1.28 ou mais recente não precisam ter o modo privilegiado ativado para acessar TPUs. Os nós no GKE 1.28 e anteriores exigem o modo privilegiado.

Se o nó da fração de TPU estiver executando versões anteriores à 1.28, leia a seguinte seção:

Um contêiner em execução em uma VM em uma fração de TPU precisa de acesso a limites mais altos de memória bloqueada para que o driver possa se comunicar com os chips de TPU por acesso direto à memória (DMA). Para ativar esse recurso, é preciso configurar uma ulimit mais alta. Se você quiser reduzir o escopo de permissão no contêiner, siga estas etapas:

Edite o securityContext para incluir os seguintes campos:

securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

Aumente o ulimit executando o seguinte comando dentro do contêiner antes de configurar as cargas de trabalho para usar os recursos da TPU:
```
ulimit -l 68719476736
```

Na TPU v5e, a execução de contêineres sem o modo privilegiado está disponível em clusters nas versões 1.27.4-gke.900 e posteriores.

Observabilidade e métricas

Painel

A capacidade de observação do pool de nós no consoleGoogle Cloud está em disponibilidade geral. Para conferir o status dos pools de nós de vários hosts da TPU no GKE, acesse o painel Status do pool de nós de TPU do GKE fornecido pelo Cloud Monitoring:

Acessar o status do pool de nós de TPU do GKE

Esse painel oferece insights abrangentes sobre a integridade dos seus pools de nós de TPU de vários hosts. Para mais informações, consulte Monitorar métricas de integridade para nós e pools de nós de TPU.

Na página Clusters do Kubernetes no consoleGoogle Cloud , a guia Observabilidade também mostra métricas de observabilidade da TPU, como o uso da TPU, no cabeçalho Aceleradores > TPU. Para mais informações, consulte Conferir métricas de observabilidade.

O painel da TPU será preenchido apenas se você tiver métricas do sistema ativadas no cluster do GKE.

Métricas do ambiente de execução

No GKE 1.27.4-gke.900 ou mais recente, as cargas de trabalho da TPU que usam o JAX 0.4.14 ou mais recente e especificam containerPort: 8431 exportam as métricas de utilização da TPU como métricas do sistema do GKE. As métricas a seguir estão disponíveis no Cloud Monitoring para monitorar o desempenho do ambiente de execução da carga de trabalho da TPU

Ciclo de trabalho: porcentagem de tempo durante o período de amostragem anterior (60 segundos) em que os TensorCores estavam ativamente em processamento em um chip de TPU. Uma porcentagem maior significa melhor uso da TPU.
Memória usada: quantidade de memória do acelerador alocada em bytes. Amostras coletadas a cada 60 segundos.
Memória total: memória total do acelerador em bytes. Amostras coletadas a cada 60 segundos.

Essas métricas estão localizadas no esquema de nó (k8s_node) e contêiner de contêiner (k8s_container) do Kubernetes.

Contêiner do Kubernetes:

kubernetes.io/container/accelerator/duty_cycle
kubernetes.io/container/accelerator/memory_used
kubernetes.io/container/accelerator/memory_total

Nó do Kubernetes:

kubernetes.io/node/accelerator/duty_cycle
kubernetes.io/node/accelerator/memory_used
kubernetes.io/node/accelerator/memory_total

Monitorar métricas de integridade para nós e pools de nós de TPU

Quando um job de treinamento tem um erro ou termina com falha, é possível verificar as métricas relacionadas à infraestrutura subjacente para descobrir se a interrupção foi causada por um problema com o nó ou o pool de nós subjacente.

Status do nó

No GKE 1.32.1-gke.1357001 ou mais recente, a seguinte métrica do sistema do GKE expõe a condição de um nó do GKE:

kubernetes.io/node/status_condition

O campo condition informa condições no nó, como Ready, DiskPressure e MemoryPressure. O campo status mostra o status informado da condição, que pode ser True, False ou Unknown. Essa é uma métrica com o tipo de recurso monitorado k8s_node.

Essa consulta PromQL mostra se um nó específico está Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Para ajudar a resolver problemas em um cluster, confira os nós que apresentaram outras condições:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Talvez você queira analisar especificamente os nós que não são Ready:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Se não houver dados, os nós estarão prontos. A condição de status é amostrada a cada 60 segundos.

Use a consulta a seguir para entender o status do nó em toda a frota:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

Status do pool de nós

A seguinte métrica de sistema do GKE para o recurso monitorado k8s_node_pool expõe o status de um pool de nós do GKE:

kubernetes.io/node_pool/status

Essa métrica é informada apenas para pools de nós de TPU de vários hosts.

O campo status informa o status do pool de nós, como Provisioning, Running, Error, Reconciling ou Stopping. As atualizações de status acontecem depois que as operações da API do GKE são concluídas.

Para verificar se um pool de nós específico tem o status Running, use esta consulta em PromQL:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Para monitorar o número de pools de nós no seu projeto agrupados por status, use a seguinte consulta PromQL:

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Disponibilidade do pool de nós

A seguinte métrica do sistema do GKE mostra se um pool de nós da TPU de vários hosts está disponível:

kubernetes.io/node_pool/multi_host/available

A métrica tem um valor de True se todos os nós do pool de nós estiverem disponíveis e False caso contrário. A métrica é amostrada a cada 60 segundos.

Para verificar a disponibilidade de pools de nós de TPU de vários hosts no seu projeto, use a seguinte consulta PromQL:

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Contagem de interrupções de nós

A métrica do sistema do GKE a seguir informa a contagem de interrupções de um nó do GKE desde a última amostra. A métrica é amostrada a cada 60 segundos:

kubernetes.io/node/interruption_count

Os campos interruption_type (como TerminationEvent, MaintenanceEvent ou PreemptionEvent) e interruption_reason (como HostError, Eviction ou AutoRepair) podem ajudar a explicar por que um nó foi interrompido.

Para conferir um detalhamento das interrupções e das causas nos nós da TPU nos clusters do seu projeto, use a seguinte consulta do PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Para ver apenas os eventos de manutenção do host, atualize a consulta para filtrar o valor HW/SW Maintenance de interruption_reason. Use a seguinte consulta em PromQL:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Para ver a contagem de interrupções agregada por pool de nós, use a seguinte consulta do PromQL:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Tempos de recuperação (TTR) do pool de nós

A métrica do sistema do GKE a seguir informa a distribuição das durações do período de recuperação para pools de nós da TPU de vários hosts do GKE:

kubernetes.io/node_pool/accelerator/times_to_recover

Cada amostra registrada nessa métrica indica um único evento de recuperação do pool de nós de um período de inatividade.

Essa métrica é útil para rastrear o tempo de recuperação e o tempo entre interrupções do pool de nós de TPU de vários hosts.

Use a seguinte consulta do PromQL para calcular o tempo médio de recuperação (MTTR) nos últimos sete dias no seu cluster:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Tempos entre interrupções (TBI) do pool de nós

Os tempos entre interrupções do pool de nós medem quanto tempo sua infraestrutura é executada antes de sofrer uma interrupção. Ele é calculado como a média em uma janela de tempo, em que o numerador mede o tempo total em que sua infraestrutura ficou ativa e o denominador mede o total de interrupções na sua infraestrutura.

O exemplo de PromQL a seguir mostra o tempo médio entre interrupções (MTBI, na sigla em inglês) de sete dias para o cluster especificado:

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Métricas de hospedagem

No GKE 1.28.1-gke.1066000 ou mais recente, as VMs em uma fração da TPU exportam as métricas de utilização da TPU como métricas do sistema do GKE. As seguintes métricas estão disponíveis no Cloud Monitoring para monitorar o desempenho do host da TPU:

Uso do TensorCore: porcentagem atual do TensorCore que está sendo utilizada. O valor do TensorCore é igual à soma das unidades de multiplicação de matriz (MXUs) mais a unidade vetorial. O valor de utilização do TensorCore é a divisão das operações do TensorCore que foram realizadas no período de amostragem anterior (60 segundos) pelo número de operações do TensorCore com suporte no mesmo período. Um valor maior significa melhor utilização.
Uso de largura de banda da memória: porcentagem atual da largura de banda da memória do acelerador que está sendo usada. Calculada pela divisão da largura de banda da memória usada durante um período de amostragem (60 segundos) pela largura de banda máxima aceita no mesmo período.

Essas métricas estão localizadas no esquema de nó (k8s_node) e contêiner de contêiner (k8s_container) do Kubernetes.

Contêiner do Kubernetes:

kubernetes.io/container/accelerator/tensorcore_utilization
kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nó do Kubernetes:

kubernetes.io/node/accelerator/tensorcore_utilization
kubernetes.io/node/accelerator/memory_bandwidth_utilization

Para mais informações, consulte Métricas do Kubernetes e Métricas do sistema do GKE.

Problemas conhecidos

O escalonador automático de cluster pode calcular incorretamente a capacidade de novos nós de fração de TPU antes que esses nós informem as TPUs disponíveis. Em seguida, o escalonador automático de cluster pode realizar um escalonamento adicional e, como resultado, criar mais nós do que o necessário. O escalonador automático de cluster reduz os nós adicionais, se eles não forem necessários, após a operação de reduzir escala vertical regular.
O escalonador automático de cluster cancela o escalonamento vertical de pools de nós de fração de TPU que permanecem em espera por mais de 10 horas. O autoescalador de cluster tentará realizar essas operações de escalonar verticalmente posteriormente. Esse comportamento pode reduzir a capacidade de obtenção de TPU para clientes que não usam reservas.
As cargas de trabalho que não são da TPU e têm tolerância para o taint da TPU podem impedir reduzir escala vertical do pool de nós se estiverem sendo recriadas durante a diminuição do pool de nós de fração da TPU.
A métrica de utilização da largura de banda da memória não está disponível para TPUs v5e.

Implantar cargas de trabalho de TPU no GKE Standard Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Planejar a configuração da TPU

Verifique se você tem uma cota de TPU

Cota para VMs spot ou sob demanda

Cotas para outros recursos do GKE

Garantir a disponibilidade de reserva

Opções para provisionar TPUs no GKE

Criar um cluster

Crie um pool de nós.

Criar um pool de nós de fração de TPU de host único

gcloud

Terraform

Console

Criar um pool de nós de fração de TPU com vários hosts

gcloud

Terraform

Console

Como o GKE lida com problemas de capacidade

Executar a carga de trabalho em nós de fração da TPU

Preparar suas cargas de trabalho

Exemplo 1: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis em um pool de nós de fração da TPU

Exemplo 2: executar uma carga de trabalho que exibe o número de chips de TPU disponíveis na fração de TPU

Fazer upgrade de pools de nós usando aceleradores (GPUs e TPUs)

Limpar

Definir outras configurações

Gerenciar o agendamento de coleta

Gerenciar o agendamento de coleta em pools de nós de frações de TPU de vários hosts

Gerenciar o agendamento de coleta em pools de nós de fração de TPU de host único

Usar Multislice

Migrar sua reserva da TPU

Ativar a geração de registros

Usar o provisionamento automático de nós do GKE

Provisionar TPUs usando classes de computação personalizadas

Configurar o reparo automático para nós de fração da TPU

Configurar o encerramento automático para nós de fração da TPU

Executar contêineres sem o modo privilegiado

Observabilidade e métricas

Painel

Métricas do ambiente de execução

Monitorar métricas de integridade para nós e pools de nós de TPU

Status do nó

Status do pool de nós

Disponibilidade do pool de nós

Contagem de interrupções de nós

Tempos de recuperação (TTR) do pool de nós

Tempos entre interrupções (TBI) do pool de nós

Métricas de hospedagem

Problemas conhecidos

A seguir

Implantar cargas de trabalho de TPU no GKE Standard