Se usó la API de Cloud Translation para traducir esta página.

Implementa cargas de trabajo de TPU en GKE Standard

Estándar

En esta página, se proporciona una base para aprender a acelerar las cargas de trabajo de aprendizaje automático (AA) con TPU en Google Kubernetes Engine (GKE). Las TPU están diseñadas para el procesamiento de multiplicación de matrices, como el entrenamiento de modelos de aprendizaje profundo a gran escala. Las TPU están optimizadas para controlar los enormes conjuntos de datos y los modelos complejos del AA, por lo que son más rentables y eficientes en términos de energía para las cargas de trabajo de AA debido a su rendimiento superior. En esta guía, aprenderás a implementar cargas de trabajo de AA con aceleradores de Cloud TPU, configurar cuotas para las TPU, configurar actualizaciones para los grupos de nodos que ejecutan TPU y supervisar las métricas de las cargas de trabajo de TPU.

Este instructivo está dirigido a ingenieros de aprendizaje automático (AA) y administradores y operadores de plataformas que estén interesados en usar la organización de contenedores de Kubernetes para administrar cargas de trabajo de inferencia, ajuste y entrenamiento de modelos a gran escala con TPU. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que se hace referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con lo siguiente:

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Planifica tu configuración de TPU

Planifica tu configuración de TPU según el modelo y la cantidad de memoria que requiere. Antes de usar esta guía para implementar tus cargas de trabajo en la TPU, completa los pasos de planificación en Planifica tu configuración de TPU.

Asegúrate de tener cuota de TPU

En las siguientes secciones, se te ayudará a asegurarte de tener suficiente cuota cuando uses TPUs en GKE.

Cuota para VMs según demanda o Spot

Si creas un grupo de nodos de porción TPU con VMs según demanda o Spot, debes tener suficiente cuota de TPU disponible en la región que deseas usar.

Crear un grupo de nodos de porción de TPU que consuma una reserva de TPU no requiere ninguna cuota de TPU.¹ Puedes omitir esta sección de forma segura para las TPU reservadas.

La creación de un grupo de nodos de porción de TPU según demanda o Spot en GKE requiere cuota de la API de Compute Engine. La cuota de la API de Compute Engine (compute.googleapis.com) no es lo mismo que la cuota de la API de Cloud TPU (tpu.googleapis.com), que es necesaria cuando se crean TPU con la API de Cloud TPU.

Si deseas verificar el límite y el uso actual de la cuota de la API de Compute Engine para las TPUs, sigue estos pasos:

Ve a la página Cuotas en la consola de Google Cloud :

Ir a Cuotas

En la casilla Filtro, haz lo siguiente:

Usa la siguiente tabla para seleccionar y copiar la propiedad de la cuota según la versión de TPU y el tipo de máquina. Por ejemplo, si planeas crear nodos TPU v5e a pedido cuyo tipo de máquina comience con ct5lp-, ingresa Name: TPU v5 Lite PodSlice chips.

Versión de TPU, el tipo de máquina comienza con	Propiedad y nombre de la cuota para instancias bajo demanda	Propiedad y nombre de la cuota para las instancias Spot²
TPU v3, `ct3-`	Dimensions (e.g. location): tpu_family:CT3	No aplicable
TPU v3, `ct3p-`	Dimensions (e.g. location): tpu_family:CT3P	No aplicable
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

Selecciona la propiedad Dimensiones (p. ej., ubicaciones) y, luego, ingresa region: seguido del nombre de la región en la que planeas crear TPUs en GKE. Por ejemplo, ingresa region:us-west4 si planeas crear nodos de porción TPU en la zona us-west4-a. La cuota de TPU es regional, por lo que todas las zonas dentro de la misma región consumen la misma cuota de TPU.

Si ninguna cuota coincide con el filtro que ingresaste, no se le otorgó ninguna de las cuotas especificadas para la región que necesitas al proyecto y debes solicitar un ajuste de la cuota de TPU.

Cuando se crea una reserva de TPU, los valores de límite y de uso actuales para la cuota correspondiente aumentan según la cantidad de chips en la reserva de TPU. Por ejemplo, cuando se crea una reserva para 16 chips TPU v5e cuyo tipo de máquina comienza con ct5lp-, tanto el límite como el uso actual de la cuota de TPU v5 Lite PodSlice chips en la región pertinente aumentan en 16.

Cuando crees un grupo de nodos de porción de TPU, usa las marcas --reservation y --reservation-affinity=specific para crear una instancia reservada. Las reservas de TPU están disponibles cuando se compra un compromiso. ↩
Cuando crees un grupo de nodos de porción de TPU, usa la marca --spot para crear una instancia Spot. ↩

Cuotas para recursos adicionales de GKE

Es posible que debas aumentar las siguientes cuotas relacionadas con GKE en las regiones en las que GKE crea tus recursos.

Cuota de SSD de Persistent Disk (GB): El disco de arranque de cada nodo de Kubernetes requiere 100 GB de forma predeterminada. Por lo tanto, esta cuota debe establecerse al menos tan alta como el producto de la cantidad máxima de nodos de GKE que esperas crear y 100 GB (nodos * 100 GB).
Cuota de direcciones IP en uso: Cada nodo de Kubernetes consume una dirección IP. Por lo tanto, esta cuota debe establecerse al menos tan alta como la cantidad máxima de nodos de GKE que esperas crear.
Asegúrate de que max-pods-per-node se alinee con el rango de la subred: Cada nodo de Kubernetes usa rangos de IP secundarios para los Pods. Por ejemplo, un max-pods-per-node de 32 requiere 64 direcciones IP, lo que se traduce en una subred /26 por nodo. Ten en cuenta que este rango no se debe compartir con ningún otro clúster. Para evitar agotar el rango de direcciones IP, usa la marca --max-pods-per-node para limitar la cantidad de Pods que se pueden programar en un nodo. La cuota para max-pods-per-node debe establecerse al menos tan alta como la cantidad máxima de nodos de GKE que esperas crear.

Para solicitar un aumento de la cuota, consulta Solicita un ajuste de cuota.

Garantiza la disponibilidad de la reserva

Para crear un grupo de nodos de porción de TPU con una reserva, esta debe tener suficientes chips de TPU disponibles en el momento de la creación del grupo de nodos.

Para ver qué reservas existen dentro de un proyecto y cuántos chips de TPU dentro de una reserva de TPU están disponibles, consulta una lista de tus reservas.

Opciones para aprovisionar TPUs en GKE

GKE te permite usar TPUs directamente en cargas de trabajo individuales a través de nodeSelectors de Kubernetes en el manifiesto de tu carga de trabajo o creando grupos de nodos en modo estándar con TPUs.

Como alternativa, puedes solicitar TPU con clases de procesamiento personalizadas. Las clases de procesamiento personalizadas permiten que los administradores de la plataforma definan una jerarquía de configuraciones de nodos para que GKE las priorice durante las decisiones de escalamiento de nodos, de modo que las cargas de trabajo se ejecuten en el hardware seleccionado.

Para obtener instrucciones, consulta la sección Aprovisiona TPU con clases de procesamiento personalizadas.

Crea un clúster

Crea un clúster de GKE en modo estándar en una región con TPUs disponibles.

Práctica recomendada:

Usa clústeres regionales, que proporcionan alta disponibilidad del plano de control de Kubernetes.

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

Reemplaza lo siguiente:

CLUSTER_NAME el nombre del clúster nuevo.
LOCATION: la región con la capacidad de TPU disponible.
VERSION: la versión de GKE, que debe ser compatible con el tipo de máquina que deseas usar. Ten en cuenta que es posible que la versión predeterminada de GKE no tenga disponibilidad para la TPU de destino. Para obtener información sobre cuáles son las versiones mínimas de GKE disponibles por tipo de máquina de TPU, consulta la disponibilidad de TPU en GKE.

Crea un grupo de nodos

Puedes crear un grupo de nodos de porción de TPU de host único o de varios hosts.

Crea un grupo de nodos de porción de TPU de host único

Puedes crear un grupo de nodos de porción de TPU de host único con Google Cloud CLI, Terraform o la Google Cloud consola.

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]

Reemplaza lo siguiente:

NODE_POOL_NAME: el nombre del grupo de nodos nuevo.
LOCATION: Es el nombre de la zona en función de la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
CLUSTER_NAME: Es el nombre del clúster.
NODE_ZONES: la lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
MACHINE_TYPE: el tipo de máquina que se usará para los nodos. Para obtener más información sobre los tipos de máquinas compatibles con TPU, usa la tabla en Elige la versión de TPU.

De manera opcional, también puedes usar las siguientes marcas:

--num-nodes=NUM_NODES: Es la cantidad inicial de nodos en el grupo de nodos en cada zona. Si omites esta marca, GKE asigna el valor predeterminado de 3.

Práctica recomendada:
Si usas la marca enable-autoscaling para el grupo de nodos, establece num-nodes en 0 para que el escalador automático aprovisione nodos adicionales en cuanto tus cargas de trabajo los exijan.
--reservation=RESERVATION_NAME: el nombre de la reserva que GKE usa cuando crea el grupo de nodos. Si omites esta marca, GKE usa las TPU disponibles. Para obtener más información sobre las reservas de TPU, consulta Acerca de las reservas de Cloud TPU.
--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: Indica a GKE que el grupo de nodos de porción de TPU de un solo host forma parte de una colección. Usa esta marca si se cumplen las siguientes condiciones:
- El grupo de nodos ejecuta la carga de trabajo de inferencia en el grupo de nodos nuevo.
- El grupo de nodos usa TPU Trillium.
- El grupo de nodos no usa VMs Spot.
Para obtener más información sobre la administración de la programación de la recopilación, consulta Administra la programación de la recopilación en porciones de TPU de host único.
--enable-autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Se requieren las siguientes marcas adicionales:
- --total-min-nodes=TOTAL_MIN_NODES: Es la cantidad mínima de todos los nodos en el grupo de nodos.
- --total-max-nodes=TOTAL_MAX_NODES: Es la cantidad máxima de todos los nodos en el grupo de nodos.
- --location-policy=ANY: Prioriza el uso de reservas sin usar y reduce el riesgo de interrupción de las VMs Spot.
--spot: Configura el grupo de nodos para usar VMs Spot para los nodos del grupo de nodos. Esto no se puede cambiar después de la creación del grupo de nodos.
--flex-start: Configura el grupo de nodos para que use VMs de inicio flexible. Las VMs de inicio flexible se crean con la opción de consumo flex-start, que es compatible con la versión 1.33.0-gke.1712000 o posterior de GKE.
--sandbox=type=gvisor: Aprovisiona un nodo con GKE Sandbox habilitado. Requiere TPU v4 y versiones posteriores. Para obtener más información, consulta GKE Sandbox.

Para obtener una lista completa de todas las marcas que puedes especificar, consulta la referencia de gcloud container clusters create.

Terraform

Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.
Agrega el siguiente bloque a la configuración de 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
  }
}

Reemplaza lo siguiente:

NODE_POOL_RESOURCE_NAME: el nombre del recurso del grupo de nodos en la plantilla de Terraform.
PROJECT_ID: ID del proyecto
CLUSTER_NAME: el nombre del clúster existente.
POOL_NAME: el nombre del grupo de nodos que se creará.
CLUSTER_LOCATION: las zonas de procesamiento del clúster. Especifica la región en la que está disponible la versión de TPU. Para obtener más información, consulta Selecciona una versión y una topología de TPU.
NODE_ZONES: la lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
MACHINE_TYPE: el tipo de máquina de TPU que se usará. Para ver los tipos de máquinas compatibles con TPU, usa la tabla en Elige la versión de TPU.

De manera opcional, también puedes usar las siguientes variables:

autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Para una porción de TPU de host único, GKE escala entre los valores TOTAL_MIN_NODES y TOTAL_MAX_NODES.
- TOTAL_MIN_NODES: la cantidad mínima de todos los nodos en el grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste de escala automático.
- TOTAL_MAX_NODES: la cantidad máxima de todos los nodos en el grupo de nodos. Este campo es opcional, a menos que también se especifique el ajuste de escala automático.
RESERVATION_NAME: Si usas Acerca de las reservas de Cloud TPU, esta es la lista de etiquetas de los recursos de reserva que se usarán cuando se cree el grupo de nodos. Para obtener más información sobre cómo completar RESERVATION_LABEL_VALUES en el campo reservation_affinity, consulta Proveedor de Terraform Beta.
spot: configura el grupo de nodos a fin de usar VMs Spot para los nodos TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.
flex_start: Configura el grupo de nodos para usar la opción de consumo flex-start. No se puede establecer en true si spot está habilitado. Flex-start es compatible con la versión 1.33.0-gke.1712000 o posterior de GKE.

Console

Para crear un grupo de nodos con TPUs, haz lo siguiente:

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

Ir a Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
Haz clic en Agregar grupo de nodos.
En la sección Detalles del grupo de nodos, marca la casilla Especificar las ubicaciones de los nodos.
Selecciona la zona según la versión de TPU que deseas usar. Para identificar una zona disponible, consulta Disponibilidad de TPU en GKE.
Desde el panel de navegación, haz clic en Nodos.
En la sección Configuración de la máquina, selecciona TPUs.
En el menú desplegable Serie, selecciona una de las siguientes opciones:
- CT3: TPU v3, dispositivo host único
- CT3P: TPU v3, porción de Pod de varios hosts
- CT4P: TPU v4
- CT5LP: TPU v5e
- CT5P: TPU v5p
- CT6E: TPU Trillium (v6e)
En el menú desplegable Tipo de máquina, elige el nombre de la máquina que se usará para los nodos. Usa la tabla Elige la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un grupo de nodos de porción de TPU de host único.
En el menú desplegable Topología de TPU, elige la topología física para la porción de TPU.
En el diálogo Cambios necesarios, haz clic en Hacer cambios.
Asegúrate de que el Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.
De manera opcional, selecciona la casilla de verificación Habilitar nodos en VMs Spot a fin de usar VMs Spot para los nodos en el grupo de nodos.
Haz clic en Crear.

Crea un grupo de nodos de porción de TPU de varios hosts

Puedes crear un grupo de nodos de porción de TPU de varios hosts con Google Cloud CLI, Terraform o la Google Cloud consola.

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]

Reemplaza lo siguiente:

POOL_NAME: el nombre del grupo de nodos nuevo.
LOCATION: Es el nombre de la zona en función de la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
CLUSTER_NAME: Es el nombre del clúster.
NODE_ZONES: la lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
MACHINE_TYPE: el tipo de máquina que se usará para los nodos. Para obtener más información sobre los tipos de máquinas disponibles, consulta Elige la versión de TPU.
TPU_TOPOLOGY: la topología física para la porción de TPU. El formato de la topología depende de la versión de la TPU. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige una topología.

Para obtener más información, consulta Topología.

De manera opcional, también puedes usar las siguientes marcas:

NUM_NODES: la cantidad de nodos en el grupo de nodos. Debe ser cero o el producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) divididos por la cantidad de chips en cada VM. Para TPU v4 y TPU v5e de varios hosts, el número de chips en cada VM es cuatro. Por lo tanto, si tu TPU_TOPOLOGY es 2x4x4 (TPU v4 con cuatro chips en cada VM), la NUM_NODES es 32/4, que es igual a 8. Si omites esta marca, la cantidad de nodos se calcula y se establece de forma predeterminada según la topología y el tipo de máquina.
RESERVATION_NAME: el nombre de la reserva que GKE usa cuando crea el grupo de nodos. Si omites esta marca, GKE usa los grupos de nodos de porción de TPU disponibles. Para obtener más información sobre las reservas de TPU, consulta Reserva de TPU.
--spot: configura el grupo de nodos a fin de usar VMs Spot para los nodos de porción de TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.
--flex-start: Configura el grupo de nodos para que use VMs de inicio flexible. Las VMs de inicio flexible se crean con la opción de consumo flex-start, que es compatible con la versión 1.33.0-gke.1712000 o posterior de GKE.
--enable-autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Cuando GKE escala un grupo de nodos de porción de TPU de varios hosts, escala de forma atómica desde el cero hasta el tamaño máximo.
- MAX_NODES: el tamaño máximo del grupo de nodos. La marca --max-nodes es obligatoria si se proporciona --enable-autoscaling y debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) divididos por la cantidad de chips en cada VM.
--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: Indica a GKE que el grupo de nodos de porción de TPU de varios hosts es una colección. Usa esta marca si se cumplen las siguientes condiciones:
- El grupo de nodos ejecuta cargas de trabajo de inferencia en el grupo de nodos nuevo.
- El grupo de nodos usa TPU Trillium.
- Las VMs Spot no admiten la programación de la recopilación.
Para obtener más información sobre la administración de la programación de la recopilación, consulta Administra la programación de la recopilación en porciones de TPU de varios hosts.
--placement-type=COMPACT: Crea un grupo de nodos con la posición de compactación habilitada. Esta opción se debe usar con la marca --tpu-topology. Para obtener más información, consulta Crea una política de posición compacta y Topología de TPU.

Terraform

Asegúrate de usar la versión 4.84.0 o una posterior del proveedor google.
Agrega el siguiente bloque a la configuración de 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
  }
}
```
Reemplaza lo siguiente:
- NODE_POOL_RESOURCE_NAME: el nombre del recurso del grupo de nodos en la plantilla de Terraform.
- PROJECT_ID: ID del proyecto
- CLUSTER_NAME: el nombre del clúster existente al que se agregará el grupo de nodos.
- POOL_NAME: el nombre del grupo de nodos que se creará.
- CLUSTER_LOCATION: la ubicación de procesamiento del clúster. Recomendamos tener un clúster regional para obtener una mayor confiabilidad del plano de control de Kubernetes. También puedes usar un clúster zonal. Para obtener más información, consulta Selecciona una versión y una topología de TPU.
- NODE_ZONES: la lista separada por comas de una o más zonas en las que GKE crea el grupo de nodos.
- NUM_NODES: la cantidad de nodos en el grupo de nodos. Debe ser cero o el producto del número de chips TPU dividido por cuatro, ya que en las porciones de TPU multihost cada nodo de porción de TPU tiene 4 chips. Por ejemplo, si TPU_TOPOLOGY es 4x8, entonces hay 32 chips, lo que significa que NUM_NODES debe ser 8. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige la versión de TPU.
- TPU_TOPOLOGY: indica la topología física deseada para la porción de TPU. El formato de la topología depende de la versión de la TPU que usas. Para obtener más información sobre las topologías de TPU, usa la tabla de Elige una topología.
De manera opcional, también puedes usar las siguientes variables:
- RESERVATION_NAME: si usas la reserva de TPU, esta es la lista de etiquetas de los recursos de reserva que se usarán cuando se cree el grupo de nodos. Para obtener más información sobre cómo completar RESERVATION_LABEL_VALUES en el campo reservation_affinity, consulta Proveedor de Terraform Beta.
- autoscaling: Crea un grupo de nodos con el ajuste de escala automático habilitado. Cuando GKE escala un grupo de nodos de porción de TPU de varios hosts, escala de forma atómica desde el cero hasta el tamaño máximo.
  - MAX_NODES: Es el tamaño máximo del grupo de nodos. Debe ser igual al producto de los valores definidos en TPU_TOPOLOGY ({A}x{B}x{C}) divididos por la cantidad de chips en cada VM.
- spot: permite que el grupo de nodos use VMs Spot para los nodos de porción de TPU. Esto no se puede cambiar después de la creación del grupo de nodos. Para obtener más información, consulta VMs Spot.
- flex_start: Configura el grupo de nodos para usar la opción de consumo flex-start. No se puede establecer en true si spot está habilitado.

Console

Para crear un grupo de nodos con TPUs, haz lo siguiente:

Ve a la página de Google Kubernetes Engine en la consola de Google Cloud .

Ir a Google Kubernetes Engine
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
Haz clic en Agregar grupo de nodos.
En la sección Detalles del grupo de nodos, marca la casilla Especificar las ubicaciones de los nodos.
Selecciona el nombre de la zona según la versión de TPU que deseas usar. Para identificar una ubicación disponible, consulta Disponibilidad de TPU en GKE.
Desde el panel de navegación, haz clic en Nodos.
En la sección Configuración de la máquina, selecciona TPUs.
En el menú desplegable Serie, selecciona una de las siguientes opciones:
- CT3P: Para TPU v3.
- CT4P: para TPU v4.
- CT5LP: para TPU v5e
En el menú desplegable Tipo de máquina, elige el nombre de la máquina que se usará para los nodos. Usa la tabla Elige la versión de TPU para saber cómo definir el tipo de máquina y la topología de TPU que crean un grupo de nodos de porción de TPU de varios hosts.
En el menú desplegable Topología de TPU, elige la topología física para la porción de TPU.
En el diálogo Cambios necesarios, haz clic en Hacer cambios.
Asegúrate de que el Tipo de disco de arranque sea Disco persistente estándar o Disco persistente SSD.
De manera opcional, selecciona la casilla de verificación Habilitar nodos en VMs Spot a fin de usar VMs Spot para los nodos en el grupo de nodos.
Haz clic en Crear.

Cómo GKE controla los problemas de capacidad

Si GKE no puede crear tu grupo de nodos de porción de TPU debido a la capacidad de TPU insuficiente, GKE devuelve un mensaje de error que indica que los nodos de porción de TPU no se pueden crear debido a la falta de capacidad.

Si creas un grupo de nodos de porción de TPU de host único, el mensaje de error será similar al siguiente:

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.

Si creas un grupo de nodos de porción de TPU de varios hosts, el mensaje de error será similar al siguiente:

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.

Tu solicitud de aprovisionamiento de TPU puede permanecer en la cola durante mucho tiempo y permanecerá en el estado "Aprovisionamiento" mientras está en la fila.

Una vez que la capacidad está disponible, GKE crea los nodos restantes que no se crearon.

Si necesitas capacidad antes, considera probar las VMs Spot, aunque ten en cuenta que las VMs Spot consumen una cuota diferente que las instancias bajo demanda.

Puedes borrar la solicitud de TPU en cola con la eliminación del grupo de nodos de porción de TPU.

Ejecuta tu carga de trabajo en nodos de porción de TPU

En esta sección, se explica cómo preparar tus cargas de trabajo y se incluyen ejemplos de cómo puedes ejecutarlas.

Prepara tus cargas de trabajo

Las cargas de trabajo de TPU tienen los siguientes requisitos de preparación.

Los frameworks como JAX, PyTorch y TensorFlow acceden a las VMs de TPU con la biblioteca compartida libtpu. libtpu incluye el compilador XLA, el software del entorno de ejecución de TPU y el controlador de TPU. Cada versión de PyTorch y JAX requiere una versión determinada de libtpu.so. Para evitar conflictos de versiones de paquetes, te recomendamos que uses una imagen de JAX AI. Para usar las TPUs en GKE, asegúrate de usar las siguientes versiones:

Tipo de TPU	`libtpu.so` versión
TPU Trillium (v6e) `tpu-v6e-slice`	Imagen de JAX AI recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.9 o posterior Versión recomendada de torchxla[tpuvm]: v2.1.0 o posterior
TPU v5e `tpu-v5-lite-podslice`	Imagen de JAX AI recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.9 o posterior Versión recomendada de torchxla[tpuvm]: v2.1.0 o posterior
TPU v5p `tpu-v5p-slice`	Imagen de JAX AI recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: 0.4.19 o posterior. Versión recomendada de torchxla[tpuvm]: Se sugiere usar una versión de compilación nocturna del 23 de octubre de 2023.
TPU v4 `tpu-v4-podslice`	Imagen de JAX AI recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.4 o posterior torchxla[tpuvm] recomendado: v2.0.0 o posterior
TPU v3 `tpu-v3-slice` `tpu-v3-device`	Imagen de JAX AI recomendada: jax0.4.35-rev1 o posterior Versión recomendada de jax[tpu]: v0.4.4 o posterior torchxla[tpuvm] recomendado: v2.0.0 o posterior

Configura las siguientes variables de entorno para el contenedor que solicita los recursos TPU:
- TPU_WORKER_ID: un número entero único para cada Pod. Este ID denota un ID de trabajador único en la porción de TPU. Los valores admitidos para este campo varían de cero a la cantidad de pods menos uno.
- TPU_WORKER_HOSTNAMES: una lista separada por comas de nombres de host de VM de TPU o direcciones IP que deben comunicarse entre sí dentro de la porción. Debe haber un nombre de host o una dirección IP para cada VM de TPU en la porción. El TPU_WORKER_ID ordena y cero indexa la lista de direcciones IP o nombres de host.
- En el manifiesto de la carga de trabajo, agrega un selector de nodos de Kubernetes para asegurarte de que GKE programe la carga de trabajo de TPU en el tipo de máquina de TPU y la topología de TPU que definiste:
```
  nodeSelector:
    cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
    cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
  
```
  Reemplaza lo siguiente:
  - TPU_ACCELERATOR: Es el nombre del acelerador de TPU.
  - TPU_TOPOLOGY: la topología física para la porción de TPU. El formato de la topología depende de la versión de la TPU. Para obtener más información, consulta Planifica el uso de TPU en GKE.

Después de completar la preparación de la carga de trabajo, puedes ejecutar un trabajo que use TPUs.

En las siguientes secciones, se muestran ejemplos sobre cómo ejecutar un trabajo que realiza procesamiento básico con las TPUs.

Ejemplo 1: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en un grupo de nodos de porción TPU

La siguiente carga de trabajo devuelve la cantidad de chips TPU en todos los nodos de una porción de TPU de varios hosts. Para crear una porción de varios hosts, la carga de trabajo tiene los siguientes parámetros:

Versión de TPU: TPU v4
Topología: 2 x 2 x 4

Esta elección de versión y topología dan como resultado una porción de varios hosts.

Guarda el siguiente manifiesto 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.

Implementa el manifiesto:
```
kubectl create -f available-chips-multihost.yaml
```
GKE ejecuta una porción de TPU v4 con cuatro VMs de TPU (porción de TPU de varios hosts). La porción tiene 16 chips TPU interconectados.

Verifica que el trabajo haya creado cuatro pods:

kubectl get pods

El resultado es similar a este:

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

Obtén los registros de uno de los Pods:
```
kubectl logs POD_NAME
```
Reemplaza POD_NAME por el nombre de uno de los Pods creados. Por ejemplo, tpu-job-podslice-0-5cd8r

El resultado es similar a este:
```
TPU cores: 16
```

Opcional: Quita la carga de trabajo:

kubectl delete -f available-chips-multihost.yaml

Ejemplo 2: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en la porción de TPU

La siguiente carga de trabajo es un Pod estático que muestra la cantidad de chips TPU adjuntos a un nodo específico. Para crear un nodo de host único, la carga de trabajo tiene los siguientes parámetros:

Versión de TPU: TPU v5e
Topología: 2 x 4

Esta elección de versión y topología da como resultado una porción de host único.

Guarda el siguiente manifiesto 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.

Implementa el manifiesto:
```
kubectl create -f available-chips-singlehost.yaml
```
GKE aprovisiona nodos con ocho porciones de TPU de host único que usan TPU v5e. Cada nodo TPU tiene ocho chips TPU (porción de TPU de host único).
Obtén los registros del pod:
```
kubectl logs tpu-job-jax-v5
```
El resultado es similar a este:
```
Total TPU chips: 8
```

Opcional: Quita la carga de trabajo:

  kubectl delete -f available-chips-singlehost.yaml

Actualiza los grupos de nodos mediante aceleradores (GPU y TPU)

GKE actualiza de forma automática los clústeres de Standard, incluidos los grupos de nodos. También puedes actualizar manualmente los grupos de nodos si deseas que los nodos se usen en una versión posterior antes. Para controlar cómo funcionan las actualizaciones de tu clúster, usa canales de versiones, períodos de mantenimiento y exclusiones, y secuenciación de lanzamientos.

También puedes configurar una estrategia de actualización de nodos para tu grupo de nodos, como actualizaciones de aumento, actualizaciones azul-verde o actualizaciones de corta duración. Si configuras estas estrategias, puedes asegurarte de que los grupos de nodos se actualicen de una manera que logre el equilibrio óptimo entre velocidad e interrupción de tu entorno. Para los grupos de nodos de porción de TPU de varios hosts, en lugar de usar la estrategia de actualización de nodos configurada, GKE vuelve a crear de forma atómica todo el grupo de nodos en un solo paso. Para obtener más información, consulta la definición de atomicidad en Terminología relacionada con la TPU en GKE.

El uso de una estrategia de actualización de nodos requiere que GKE aprovisione de forma temporal recursos adicionales, según la configuración. Si Google Cloud tiene capacidad limitada para los recursos de tu grupo de nodos, por ejemplo, si ves errores de disponibilidad de recursos cuando intentas crear más nodos con GPU o TPU, consulta Actualiza en un entorno con recursos restringidos.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos que usaste en esta guía, considera borrar los grupos de nodos de segmentos de TPU que ya no tengan cargas de trabajo programadas. Si las cargas de trabajo que se ejecutan deben finalizarse de forma correcta, usa kubectl drain para limpiar las cargas de trabajo antes de borrar el nodo.

Borra un grupo de nodos de porción de TPU:
```
gcloud container node-pools delete POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME
```
Reemplaza lo siguiente:
- POOL_NAME: Es el nombre del grupo de nodos.
- CLUSTER_NAME: Es el nombre del clúster.
- LOCATION: Es la ubicación de procesamiento del clúster.

Configura los parámetros adicionales

En las siguientes secciones, se describen las configuraciones adicionales que puedes aplicar a tus cargas de trabajo de TPU.

Administra la programación de la recopilación

En la TPU Trillium, puedes usar la programación de recopilación para agrupar los nodos de porción de TPU. Agrupar estos nodos de segmentación de TPU facilita el ajuste de la cantidad de réplicas para satisfacer la demanda de la carga de trabajo. Google Cloud controla las actualizaciones de software para garantizar que siempre haya suficientes segmentaciones disponibles en la colección para atender el tráfico.

La TPU Trillium admite la programación de recopilación para grupos de nodos de host único y varios hosts que ejecutan cargas de trabajo de inferencia. A continuación, se describe cómo se comporta la programación de la recopilación según el tipo de porción de TPU que uses:

Porción de TPU de varios hosts: GKE agrupa las porciones de TPU de varios hosts para formar una colección. Cada grupo de nodos de GKE es una réplica dentro de esta colección. Para definir una colección, crea una porción de TPU de varios hosts y asígnale un nombre único. Para agregar más porciones de TPU a la colección, crea otro grupo de nodos de porción de TPU de varios hosts con el mismo nombre de colección y tipo de carga de trabajo.
Porción de TPU de host único: GKE considera todo el grupo de nodos de porción de TPU de host único como una colección. Para agregar más porciones de TPU a la colección, puedes cambiar el tamaño del grupo de nodos de porción de TPU de host único.

Para administrar una colección, realiza cualquiera de estas acciones según el tipo de grupo de nodos que uses.

Administra la programación de la recopilación en grupos de nodos de porciones de TPU de varios hosts

Usa las siguientes tareas para administrar grupos de nodos de porción de TPU de varios hosts.

Para verificar si un grupo de porciones de TPU de varios hosts forma parte de una colección, ejecuta el siguiente 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"] // "")"'

El resultado es similar a este:

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

Si el grupo de porciones de TPU de varios hosts forma parte de una colección, el resultado tendrá las siguientes etiquetas:

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

Para obtener la lista de colecciones del clúster, ejecuta el siguiente 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

El resultado es similar a este:

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

Para obtener una lista de los grupos de nodos que pertenecen a una colección, ejecuta el siguiente 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

El resultado es similar a este:

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

Para aumentar la escala de la colección, crea otro grupo de nodos de porción de TPU de varios hosts y agrega cloud.google.com/gke-workload-type y cloud.google.com/gke-nodepool-group-name. Usa el mismo nombre de colección en cloud.google.com/gke-nodepool-group-name y ejecuta el mismo tipo de carga de trabajo. Si el aprovisionamiento automático de nodos está habilitado en el clúster, GKE crea automáticamente grupos según las demandas de la carga de trabajo.
Para reducir la escala de la colección, borra el grupo de nodos.
Para borrar la colección, quita todos los grupos de nodos adjuntos. Puedes borrar el grupo de nodos o borrar el clúster. Si borras el clúster, se quitarán todas las colecciones que contiene.

Administra la programación de la recopilación en grupos de nodos de porción de TPU de host único

Usa las siguientes tareas para administrar grupos de nodos de porción de TPU de host único.

Para verificar si un grupo de porciones de TPU de host único tiene habilitada la programación de recopilación, ejecuta el siguiente 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"]'
```
El resultado es similar a este:
```
gke-workload-type: HIGH_AVAILABILITY
```
Si el grupo de porciones de TPU de host único forma parte de una colección, el resultado tendrá la etiqueta cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.
Para aumentar la escala de la recopilación, cambia el tamaño del grupo de nodos manualmente o automáticamente con el aprovisionamiento automático de nodos.
Para reducir la escala de la colección, borra el grupo de nodos.
Para borrar la colección, quita todos los grupos de nodos adjuntos. Puedes borrar el grupo de nodos o borrar el clúster. Si borras el clúster, se quitarán todas las colecciones que contiene.

Usa Multislice

Puedes hacer una agregación de porciones más pequeñas que formen una porción múltiple para manejar cargas de trabajo de entrenamiento más grandes. Para obtener más información, consulta TPUs de porciones múltiples en GKE.

Migra tu reserva de TPU

Si tienes reservas de TPU existentes, primero debes migrar tu reserva de TPU a un sistema de reserva nuevo basado en Compute Engine. También puedes crear un sistema de reserva basado en Compute Engine en el que no se necesite migración. Para obtener información sobre cómo migrar tus reservas de TPU, consulta Reserva de TPU.

Habilitar registro

Los registros que emiten los contenedores que se ejecutan en nodos de GKE, incluidas las VMs de TPU, son recopiladas por el agente de Logging de GKE, se envían a Logging y son visibles en Logging.

Usa el aprovisionamiento automático de nodos de GKE

Puedes configurar GKE a fin de crear y borrar grupos de nodos de forma automática para satisfacer las demandas de recursos de tus cargas de trabajo de TPU. Para obtener más información, consulta Configura Cloud VPN.

Aprovisiona TPU con clases de procesamiento personalizadas

También puedes configurar GKE para que solicite TPUs durante las operaciones de ajuste de escala que crean nodos nuevos con clases de procesamiento personalizadas.

Puedes especificar opciones de configuración de TPU en la especificación de tu clase de procesamiento personalizada. Cuando una carga de trabajo de GKE usa esa clase de procesamiento personalizada, GKE intenta aprovisionar TPU que usen la configuración especificada cuando se realiza el ajuste de escala.

Para aprovisionar TPU con una clase de procesamiento personalizada que siga las reglas de TPU y, luego, implementar la carga de trabajo, completa los siguientes pasos:

Guarda el siguiente manifiesto 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

Implementa la clase de procesamiento:
```
kubectl apply -f tpu-compute-class.yaml
```
Para obtener más información sobre las clases de procesamiento personalizadas y las TPU, consulta Configuración de TPU.

Guarda el siguiente manifiesto 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

Reemplaza lo siguiente:

NUMBER_OF_CHIPS: Es la cantidad de chips TPU que usará el contenedor. Debe ser el mismo valor para limits y requests, y debe ser igual al valor del campo tpu.count en la clase de procesamiento personalizada seleccionada.
MEMORY_SIZE: Es la cantidad máxima de memoria que usa la TPU. Los límites de memoria dependen de la versión y la topología de TPU que uses. Para obtener más información, consulta Valores mínimos y máximos para los aceleradores.
NUMBER_OF_CHIPS: Es la cantidad de chips TPU que usará el contenedor. Debe ser el mismo valor para limits y requests.

Implementa el trabajo:
```
kubectl create -f tpu-job.yaml
```
Cuando creas este trabajo, GKE hace automáticamente lo siguiente:
- Aprovisiona nodos para ejecutar los Pods. Según el tipo de TPU, la topología y las solicitudes de recursos que especificaste, estos nodos son porciones de host único o de varios hosts. Según la disponibilidad de los recursos de TPU en la prioridad más alta, es posible que GKE recurra a prioridades más bajas para maximizar la capacidad de obtención.
- Agrega taints a los Pods y tolerancias a los nodos para evitar que otras cargas de trabajo se ejecuten en los mismos nodos que las cargas de trabajo de TPU.
Para obtener más información, consulta Acerca de las clases de procesamiento personalizadas.
Cuando termines esta sección, puedes borrar los recursos que creaste para evitar que se te siga facturando:
```
kubectl delete -f tpu-job.yaml
```

Configura la reparación automática para los nodos de porción de TPU

Si un nodo de porción de TPU en un grupo de nodos de porción de TPU de varios hosts está en mal estado, se vuelve a crear todo el grupo de nodos. En cambio, en un grupo de nodos de porción de TPU de host único, solo se repara automáticamente el nodo TPU en mal estado.

Las condiciones que dan como resultado nodos de porción de TPU en mal estado incluyen las siguientes:

Cualquier nodo de porción de TPU con condiciones de nodo comunes
Cualquier nodo de porción de TPU con un recuento de TPU no asignables superior a cero
Cualquier instancia de VM en una porción de TPU que se detenga (debido a una interrupción) o que se cierre
Mantenimiento de nodos: Si algún nodo de porción de TPU dentro de un grupo de nodos de porción de TPU de varios hosts queda inactivo para el mantenimiento del host, GKE vuelve a crear todo el grupo de nodos de porción de TPU.

Puedes ver el estado de reparación (incluido el motivo de la falla) en el historial de operaciones. Si la falla se debe a una cuota insuficiente, comunícate con tu representante de cuenta deGoogle Cloud para aumentar la cuota correspondiente.

Configura la finalización correcta para los nodos de porción de TPU

En los clústeres de GKE con el plano de control que ejecuta 1.29.1-gke.1425000 o una versión posterior, los nodos de la división de TPU admiten los indicadores SIGTERM que alertan al nodo de un cierre inminente. La notificación de cierre inminente se puede configurar hasta cinco minutos en nodos TPU.

Para configurar GKE para finalizar tus cargas de trabajo de forma ordenada en el plazo de este período de notificación, sigue los pasos que se indican en Administra la interrupción de nodos de GKE para GPUs y TPUs.

Ejecutar contenedores sin modo privilegiado

Los contenedores que se ejecutan en nodos en la versión 1.28 de GKE o versiones posteriores no necesitan tener habilitado el modo privilegiado para acceder a las TPU. Los nodos en GKE versión 1.28 y anteriores requieren modo privilegiado.

Si tu nodo de segmento de TPU ejecuta versiones anteriores a la 1.28, lee la siguiente sección:

Un contenedor que se ejecuta en una VM en una porción de TPU necesita acceso a límites más altos en la memoria bloqueada para que el controlador pueda comunicarse con los chips TPU a través del acceso directo a la memoria (DMA). Para habilitar esto, debes configurar un ulimit más alto. Si deseas reducir el permiso de permisos en tu contenedor, completa los siguientes pasos:

Edita securityContext para que incluya los siguientes campos:

securityContext:
  capabilities:
    add: ["SYS_RESOURCE"]

Aumenta ulimit mediante la ejecución del siguiente comando dentro del contenedor antes de configurar las cargas de trabajo para que usen recursos TPU:
```
ulimit -l 68719476736
```

En el caso de las TPU v5e, la ejecución de contenedores sin modo privilegiado está disponible en los clústeres en la versión 1.27.4-gke.900 y posteriores.

Observabilidad y métricas

Panel

La observabilidad del grupo de nodos en la Google Cloud consola está disponible de forma general. Para ver el estado de tus grupos de nodos de TPU de varios hosts en GKE, ve al panel Estado del grupo de nodos de TPU de GKE que proporciona Cloud Monitoring:

Ir al estado del grupo de nodos de TPU de GKE

Este panel te brinda estadísticas integrales sobre el estado de tus grupos de nodo TPU de varios hosts. Para obtener más información, consulta Supervisa las métricas de estado de los nodos y los grupos de nodos de TPU.

En la página Clústeres de Kubernetes de laGoogle Cloud consola, la pestaña Observabilidad también muestra las métricas de observabilidad de TPU, como el uso de TPU, en el encabezado Aceleradores > TPU. Para obtener más información, consulta Visualiza métricas de observabilidad.

El panel de TPU solo se propaga si tienes las métricas del sistema habilitadas en tu clúster de GKE.

Métricas del entorno de ejecución

En la versión 1.27.4-gke.900 o posterior de GKE, las cargas de trabajo de TPU que usan la versión 0.4.14 o posterior de JAX y especifican containerPort: 8431 exportan las métricas de uso de TPU como métricas del sistema de GKE. Las siguientes métricas están disponibles en Cloud Monitoring para supervisar el rendimiento del entorno de ejecución de tu carga de trabajo de TPU:

Ciclo de trabajo: Porcentaje de tiempo durante el último período de muestreo (60 segundos) durante el cual los TensorCores se procesaron de forma activa en un chip TPU. Un porcentaje mayor significa un mejor uso de TPU.
Memoria usada: Cantidad de memoria del acelerador asignada en bytes. Se tomaron muestras cada 60 segundos.
Memoria total: Memoria total del acelerador en bytes. Se hace un muestreo cada 60 segundos.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedor de Kubernetes (k8s_container).

Contenedor de Kubernetes:

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

Nodo de Kubernetes:

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

Supervisa las métricas de estado de los nodos y grupos de nodos de TPU

Cuando un trabajo de entrenamiento tiene un error o finaliza con una falla, puedes verificar las métricas relacionadas con la infraestructura subyacente para determinar si la interrupción se debió a un problema con el nodo o el grupo de nodos subyacente.

Estado del nodo

En la versión 1.32.1-gke.1357001 o posterior de GKE, la siguiente métrica del sistema de GKE expone la condición de un nodo de GKE:

kubernetes.io/node/status_condition

El campo condition informa las condiciones del nodo, como Ready, DiskPressure y MemoryPressure. El campo status muestra el estado informado de la condición, que puede ser True, False o Unknown. Esta es una métrica con el tipo de recurso supervisado k8s_node.

Esta consulta de PromQL muestra si un nodo en particular es Ready:

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

Para ayudarte a solucionar problemas en un clúster, es posible que desees observar los nodos que hayan presentado otras condiciones:

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

Es posible que desees observar específicamente los nodos que no son Ready:

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

Si no hay datos, los nodos están listos. La condición de estado se muestrea cada 60 segundos.

Puedes usar la siguiente consulta para comprender el estado de los nodos en toda la flota:

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

Estado del grupo de nodos

La siguiente métrica del sistema de GKE para el recurso supervisado k8s_node_pool expone el estado de un grupo de nodos de GKE:

kubernetes.io/node_pool/status

Esta métrica solo se informa para los grupos de nodo TPU de varios hosts.

El campo status informa el estado del grupo de nodos, como Provisioning, Running, Error, Reconciling o Stopping. Las actualizaciones de estado se realizan después de que se completan las operaciones de la API de GKE.

Para verificar si un grupo de nodos en particular tiene el estado Running, usa la siguiente consulta de PromQL:

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

Para supervisar la cantidad de grupos de nodos en tu proyecto agrupados por su estado, usa la siguiente consulta de PromQL:

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

Disponibilidad del grupo de nodos

La siguiente métrica del sistema de GKE muestra si hay disponible un grupo de nodo TPU de varios hosts:

kubernetes.io/node_pool/multi_host/available

La métrica tiene un valor de True si todos los nodos del grupo de nodos están disponibles y False en caso contrario. La métrica se muestrea cada 60 segundos.

Para verificar la disponibilidad de los grupos de nodo TPU de varios hosts en tu proyecto, usa la siguiente consulta de 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}]))

Recuento de interrupciones de nodos

La siguiente métrica del sistema de GKE informa el recuento de interrupciones de un nodo de GKE desde la última muestra (la métrica se muestrea cada 60 segundos):

kubernetes.io/node/interruption_count

Los campos interruption_type (como TerminationEvent, MaintenanceEvent o PreemptionEvent) y interruption_reason (como HostError, Eviction o AutoRepair) pueden ayudar a proporcionar el motivo por el que se interrumpió un nodo.

Para obtener un desglose de las interrupciones y sus causas en los nodos de TPU de los clústeres de tu proyecto, usa la siguiente consulta de PromQL:

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

Para ver solo los eventos de mantenimiento del host, actualiza la consulta para filtrar el valor HW/SW Maintenance para el interruption_reason. Usa la siguiente consulta de 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 el recuento de interrupciones agregado por grupo de nodos, usa la siguiente consulta de 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}]))

Tiempos de recuperación (TTR) del grupo de nodos

La siguiente métrica del sistema de GKE informa la distribución de las duraciones del período de recuperación para los grupos de nodo TPU de varios hosts de GKE:

kubernetes.io/node_pool/accelerator/times_to_recover

Cada muestra registrada en esta métrica indica un solo evento de recuperación del grupo de nodos a partir de un período de inactividad.

Esta métrica es útil para hacer un seguimiento del tiempo de recuperación y el tiempo entre interrupciones del grupo de nodo TPU de varios hosts.

Puedes usar la siguiente consulta de PromQL para calcular el tiempo medio de recuperación (MTTR) de los últimos 7 días en tu clúster:

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]))

Tiempos entre interrupciones (TBI) del grupo de nodos

Los tiempos entre interrupciones del grupo de nodos miden cuánto tiempo se ejecuta tu infraestructura antes de experimentar una interrupción. Se calcula como el promedio en un período, en el que el numerador mide el tiempo total en que estuvo activa tu infraestructura y el denominador mide las interrupciones totales de tu infraestructura.

En el siguiente ejemplo de PromQL, se muestra el tiempo medio entre interrupciones (MTBI) de 7 días para el clúster determinado:

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 host

En la versión 1.28.1-gke.1066000 o posterior de GKE, las VMs de una porción de TPU exportan las métricas de uso de TPU como métricas del sistema de GKE. Las siguientes métricas están disponibles en Cloud Monitoring para supervisar el rendimiento de tu host TPU:

Uso de TensorCore: Porcentaje actual del TensorCore que se usa. El valor de TensorCore es igual a la suma de las unidades de multiplicación de matriz (MXUs) más la unidad vectorial. El valor de uso de TensorCore es la división de las operaciones de TensorCore que se llevaron a cabo durante el último período de muestra (60 segundos) por la cantidad compatible de operaciones de TensorCore durante el mismo período. Un valor mayor significa un mejor uso.
Uso de ancho de banda de memoria: Porcentaje actual del ancho de banda de memoria del acelerador que se usa. Se calcula dividiendo el ancho de banda de memoria usado durante un período de muestra (60 s) por el ancho de banda máximo admitido durante el mismo período de muestra.

Estas métricas se encuentran en el esquema de nodos de Kubernetes (k8s_node) y de contenedor de Kubernetes (k8s_container).

Contenedor de Kubernetes:

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

Nodo de Kubernetes:

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

Para obtener más información, consulta Métricas de Kubernetes y Métricas del sistema de GKE.

Problemas conocidos

El escalador automático del clúster podría calcular de forma incorrecta la capacidad de los nodos de porción TPU nuevos antes de que esos nodos informen las TPUs disponibles. Luego, el escalador automático del clúster puede realizar un escalamiento vertical adicional y, como resultado, crear más nodos de los necesarios. El escalador automático del clúster reduce la escala verticalmente de los nodos adicionales, si no son necesarios, después de la operación de reducción de escala vertical regular.
El escalador automático de clústeres cancela el escalamiento vertical de los grupos de nodos de la porción de TPU que permanecen en estado de espera durante más de 10 horas. El escalador automático del clúster volverá a intentar esas operaciones de escalamiento vertical más adelante. Este comportamiento puede reducir la capacidad de obtención de TPUs para los clientes que no usan reservas.
Las cargas de trabajo que no sean de TPU y tengan tolerancia al taint de TPU pueden impedir la reducción de la escala vertical del grupo de nodos si se vuelven a crear durante el vaciado del grupo de nodos de la porción de TPU.
La métrica de utilización del ancho de banda de la memoria no está disponible para las TPU v5e.

Implementa cargas de trabajo de TPU en GKE Standard Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Antes de comenzar

Planifica tu configuración de TPU

Asegúrate de tener cuota de TPU

Cuota para VMs según demanda o Spot

Cuotas para recursos adicionales de GKE

Garantiza la disponibilidad de la reserva

Opciones para aprovisionar TPUs en GKE

Crea un clúster

Crea un grupo de nodos

Crea un grupo de nodos de porción de TPU de host único

gcloud

Terraform

Console

Crea un grupo de nodos de porción de TPU de varios hosts

gcloud

Terraform

Console

Cómo GKE controla los problemas de capacidad

Ejecuta tu carga de trabajo en nodos de porción de TPU

Prepara tus cargas de trabajo

Ejemplo 1: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en un grupo de nodos de porción TPU

Ejemplo 2: Ejecuta una carga de trabajo que muestre la cantidad de chips TPU disponibles en la porción de TPU

Actualiza los grupos de nodos mediante aceleradores (GPU y TPU)

Limpia

Configura los parámetros adicionales

Administra la programación de la recopilación

Administra la programación de la recopilación en grupos de nodos de porciones de TPU de varios hosts

Administra la programación de la recopilación en grupos de nodos de porción de TPU de host único

Usa Multislice

Migra tu reserva de TPU

Habilitar registro

Usa el aprovisionamiento automático de nodos de GKE

Aprovisiona TPU con clases de procesamiento personalizadas

Configura la reparación automática para los nodos de porción de TPU

Configura la finalización correcta para los nodos de porción de TPU

Ejecutar contenedores sin modo privilegiado

Observabilidad y métricas

Panel

Métricas del entorno de ejecución

Supervisa las métricas de estado de los nodos y grupos de nodos de TPU

Estado del nodo

Estado del grupo de nodos

Disponibilidad del grupo de nodos

Recuento de interrupciones de nodos

Tiempos de recuperación (TTR) del grupo de nodos

Tiempos entre interrupciones (TBI) del grupo de nodos

Métricas de host

Problemas conocidos

¿Qué sigue?

Implementa cargas de trabajo de TPU en GKE Standard