Planificar TPUs en GKE


En esta página se describe cómo planificar el uso de unidades de procesamiento tensorial (TPUs) en Google Kubernetes Engine (GKE) para reducir el riesgo de que se produzcan errores de configuración, de no disponibilidad o interrupciones por haber superado la cuota.

Antes de usar TPUs en GKE, asegúrate de conocer las definiciones y la terminología de las TPUs en GKE.

Planificar la configuración de la TPU

Para trabajar con TPUs en clústeres de GKE, debes planificar su configuración. Te recomendamos que sigas estos pasos:

  1. Elige un modo de funcionamiento de GKE: ejecuta tus cargas de trabajo en TPUs en un clúster Autopilot o Estándar de GKE.

    Práctica recomendada:

    Usa un clúster de Autopilot para disfrutar de una experiencia de Kubernetes totalmente gestionada.

  2. Elige la versión de TPU: los diferentes tipos de TPU tienen distintas funciones, como la relación calidad-precio, el rendimiento del entrenamiento y la latencia de servicio. Los tipos de TPU influyen en las capacidades de CPU y memoria disponibles.

  3. Validar la disponibilidad de las TPUs: las TPUs están disponibles en determinadas Trusted Cloud by S3NS regiones. Para usar un tipo de TPU en tu carga de trabajo de GKE, tu clúster debe estar en una región admitida para ese tipo.

  4. Elige la topología de la TPU: la disposición física de las TPUs en un segmento de TPU. Selecciona una topología que se ajuste a los requisitos de paralelismo de tu modelo.

Usa las tablas de referencia de esta página para identificar si tus grupos de nodos son de un solo host o de varios hosts.

Elegir un modo de funcionamiento de GKE

Puedes usar las TPUs en los modos de funcionamiento de GKE disponibles para los clústeres:

  • Modo Autopilot (recomendado): GKE gestiona la infraestructura subyacente, como la configuración de los nodos, el escalado automático, las actualizaciones automáticas, las configuraciones de seguridad básicas y la configuración de red básica. En Autopilot, eliges un tipo y una topología de TPU y, a continuación, los especificas en tu manifiesto de Kubernetes. GKE gestiona el aprovisionamiento de nodos con TPUs y la programación de tus cargas de trabajo.
  • Modo estándar: gestionas la infraestructura subyacente, lo que incluye configurar los nodos individuales.

Para elegir el modo de funcionamiento de GKE que mejor se adapte a tus cargas de trabajo, consulta Elegir un modo de funcionamiento de GKE.

Elegir una opción de consumo de TPU

Cuando planifiques la configuración de TPU en GKE, selecciona una opción de consumo que se ajuste a las necesidades de tu carga de trabajo. La opción de consumo que elijas afectará a las versiones de TPU disponibles y a la cuota que debas configurar. GKE ofrece las siguientes opciones de consumo de TPU para ayudarte a optimizar la asignación de recursos y los costes, al tiempo que mantienes el rendimiento de las cargas de trabajo:

Para elegir la opción de consumo que se adapte a los requisitos de tu carga de trabajo, consulta Acerca de las opciones de consumo de aceleradores para cargas de trabajo de IA y aprendizaje automático en GKE.

Elige la versión de TPU

Las VMs de un segmento de TPU tienen las siguientes características técnicas.

Autopilot

Versión de TPU Tipo de máquina Número de vCPUs Memoria (GiB) Número de nodos NUMA Número máximo de chips de TPU en un nodo de segmento de TPU
TPU Trillium (versión 6e) tpu-v6e-slice De 44 a 180 De 176 a 1440 De 1 a 2 256
TPU v5p
tpu-v5p-slice 208 448 2 6144
TPU v5e
tpu-v5-lite-podslice De 24 a 224 De 48 a 384 1 256
TPU v4
tpu-v4-podslice 240 407 2 4096
TPU v3 (solo de un host)
tpu-v3-device 96 340 2 8
TPU v3
tpu-v3-slice 48 340 1 256

Estándar

Versión de TPU Tipo de máquina Número de vCPUs Memoria (GiB) Número de nodos NUMA Probabilidad de que se produzca una interrupción
TPU Trillium (versión 6e) ct6e-standard-1t 44 448 2 Superior
TPU Trillium (versión 6e) ct6e-standard-4t 180 720 1 Medio
TPU Trillium (versión 6e) ct6e-standard-8t 180 1440 2 Inferior
TPU v5p
ct5p-hightpu-4t 208 448 2
TPU v5e
ct5lp-hightpu-1t 24 48 1 Superior
TPU v5e
ct5lp-hightpu-4t 112 192 1 Medio
TPU v5e
ct5lp-hightpu-8t 224 384 1 Bajo
TPU v4
ct4p-hightpu-4t 240 407 2
TPU v3 (solo de un host)
ct3-hightpu-4t 96 340 2
TPU v3
ct3p-hightpu-4t 48 340 1

Los tipos de máquinas ct5lp- multihost son más adecuados para servir modelos grandes o para el entrenamiento. Las máquinas ct5lp- multihost están interconectadas con enlaces de alta velocidad.

Consulta las especificaciones y los precios de las TPU en la documentación de precios de TPU de Cloud para decidir qué configuración de TPU usar.

Limitaciones

Ten en cuenta estas limitaciones al elegir la TPU que vas a usar:

  • TPU Trillium está disponible en las siguientes versiones:
    • Clústeres estándar con la versión 1.31.1-gke.1846000 o posterior.
    • Clústeres de Autopilot con la versión 1.31.2-gke.1115000 o posterior.
  • La TPU Trillium no admite la configuración de SMT en 2 en ct6e-standard-8t.
  • El autoescalado de TPU v5p se admite en clústeres de GKE con planos de control que ejecuten al menos la versión 1.29.2-gke.1035000 o la 1.28.7-gke.1020000.
  • En el caso de las reservas de capacidad, utiliza una reserva específica.
  • Puedes ejecutar un máximo de 256 pods en una sola VM de TPU.
  • La asignación de costes de GKE y la medición del uso no incluyen datos sobre el uso ni los costes de las TPUs.
  • El autoescalador de clústeres cancela las operaciones de escalado vertical de grupos de nodos de TPU que permanecen en estado de espera durante más de 10 horas. La herramienta de ajuste automático de clústeres vuelve a intentar estas operaciones de escalado vertical cuando hay recursos disponibles. Este comportamiento puede reducir la disponibilidad de las TPU si no usas reservas.
  • No se admiten nodos de Ubuntu.
  • La arquitectura de nodos de TPU está obsoleta. La versión 3 de TPU es la única que sigue admitiendo la arquitectura de nodos de TPU en GKE.

Validar la disponibilidad de TPU en GKE

Las TPUs están disponibles en Trusted Cloud regiones Trusted Cloud concretas. Para usar un tipo de TPU en tu clúster de GKE, este debe estar en una región admitida para ese tipo.

Autopilot

Versión de TPU cloud.google.com/gke-tpu-accelerator Versión mínima de GKE Disponibilidad Zona
TPU Trillium (v6e) tpu-v6e-slice 1.31.2-gke.1384000 GA
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
TPU v5e tpu-v5-lite-podslice 1.27.2-gke.2100 GA
  • europe-west4-b
  • us-central1-a
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p tpu-v5p-slice 1.28.3-gke.1024000 GA
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 tpu-v4-podslice 1.26.1-gke.1500 GA
  • us-central2-b
TPU v3 tpu-v3-slice 1.31.1-gke.1146000 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 tpu-v3-device 1.31.0-gke.1500 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a

Estándar

Versión de TPU Tipo de máquina que empieza por Versión mínima de GKE Disponibilidad Zona
TPU Trillium (v6e) ct6e- 1.31.2-gke.1115000 GA
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
TPU v5e ct5lp- 1.27.2-gke.2100 GA
  • europe-west4-b
  • us-central1-a
  • us-south1-a
  • us-west1-c
  • us-west4-a
TPU v5p ct5p- 1.28.3-gke.1024000 GA
  • europe-west4-b
  • us-central1-a
  • us-east5-a
TPU v4 ct4p- 1.26.1-gke.1500 GA
  • us-central2-b
TPU v3 ct3p- 1.31.1-gke.1146000 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 ct3- 1.31.0-gke.1500 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a

Elige una topología

Una vez que hayas elegido una versión de TPU, selecciona una topología compatible con ese tipo de TPU. Según el tipo de TPU, la topología es bidimensional o tridimensional. Los requisitos de paralelismo de tu modelo te ayudan a decidir la topología. Para saber cuántos chips de TPU hay en el segmento, calcula el producto de cada tamaño de la topología. Por ejemplo:

  • 2x2x2 es una porción de TPU v4 multihost de 8 chips
  • 2x2 es una porción de TPU v5e de un solo host con 4 chips.

Si una topología específica admite nodos de segmento de TPU de un solo host y de varios hosts, el número de chips de TPU que solicite tu carga de trabajo determinará el tipo de host.

Por ejemplo, la versión 5e de TPU (tpu-v5-lite-podslice) admite la topología 2x4 como host único y como multihost. Si:

  • Si solicitas 4 chips en tu carga de trabajo, obtendrás un nodo multihost que tiene 4 chips de TPU.
  • Si solicitas 8 chips en tu carga de trabajo, obtendrás un nodo de un solo host que tiene 8 chips de TPU.

Usa la siguiente tabla para elegir el tipo de máquina TPU y la topología que se adapten a tu caso práctico:

  • Para el entrenamiento o la inferencia de modelos a pequeña escala, usa la versión 4 o la 5e de TPU con grupos de nodos de segmento de TPU de un solo host.
  • Para el entrenamiento o la inferencia de modelos a gran escala, usa TPU v4 o TPU v5e con grupos de nodos de segmentos de TPU multihost.
  • Para el entrenamiento o la inferencia a gran escala, usa Pathways. Pathways simplifica los cálculos de aprendizaje automático a gran escala al permitir que un solo cliente JAX coordine las cargas de trabajo en varios sectores de TPU grandes. Para obtener más información, consulta Pathways.

Autopilot

Después de elegir un tipo y una topología de TPU, especifícalos en el manifiesto de tu carga de trabajo. Para obtener instrucciones, consulta Desplegar cargas de trabajo de TPUs en Autopilot de GKE.

Versión de TPU Tipo de máquina Tipo de grupo de nodos Especificaciones técnicas
TPU Trillium (v6e) tpu-v6e-slice Un solo host
  • Topología: 1x1
  • Número de chips de TPU: 1
  • Número de VMs: 1
TPU Trillium (v6e) tpu-v6e-slice Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 4
TPU Trillium (v6e) tpu-v6e-slice Un solo host
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 8
TPU Trillium (v6e) tpu-v6e-slice Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU Trillium (v6e) tpu-v6e-slice Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU Trillium (v6e) tpu-v6e-slice Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU Trillium (v6e) tpu-v6e-slice Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 32
TPU Trillium (v6e) tpu-v6e-slice Varios hosts
  • Topología: 16x16
  • Número de chips de TPU: 256
  • Número de VMs: 64
TPU v5p tpu-v5p-slice Un solo host
  • Topología: 2x2x1
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v5p tpu-v5p-slice Varios hosts
  • Topología: 2x2x2
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v5p tpu-v5p-slice Varios hosts
  • Topología: 2x2x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v5p tpu-v5p-slice Varios hosts
  • Topología: 2x4x4
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v5p tpu-v5p-slice Varios hosts
  • Topología: 4x4x4
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU v5p tpu-v5p-slice Varios hosts
  • Topología: {A}x{B}x{C}
  • Número de chips de TPU: {A}*{B}*{C}
  • Número de VMs: (A*B*C/4)1
TPU v5e tpu-v5-lite-podslice Un solo host
  • Topología: 1x1
  • Número de chips de TPU: 1
  • Número de VMs: 1
TPU v5e tpu-v5-lite-podslice Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v5e tpu-v5-lite-podslice Un solo host
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 1
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 32
TPU v5e tpu-v5-lite-podslice Varios hosts
  • Topología: 16x16
  • Número de chips de TPU: 256
  • Número de VMs: 64
TPU v5e (solo de un host) tpu-v5-lite-device Un solo host
  • Topología: 1x1
  • Número de chips de TPU: 1
  • Número de VMs: 1
TPU v5e (solo de un host) tpu-v5-lite-device Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v5e (solo de un host) tpu-v5-lite-device Un solo host
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 1
TPU v4 tpu-v4-podslice Un solo host
  • Topología: 2x2x1
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v4 tpu-v4-podslice Varios hosts
  • Topología: 2x2x2
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v4 tpu-v4-podslice Varios hosts
  • Topología: 2x2x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v4 tpu-v4-podslice Varios hosts
  • Topología: 2x4x4
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v4 tpu-v4-podslice Varios hosts
  • Topología: 4x4x4
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU v4 tpu-v4-podslice Varios hosts
  • Topología: {A}x{B}x{C}
  • Número de chips de TPU: {A}*{B}*{C}
  • Número de VMs: (A*B*C/4)1
TPU v3 tpu-v3-slice Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 2
TPU v3 tpu-v3-slice Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 4
TPU v3 tpu-v3-slice Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 8
TPU v3 tpu-v3-slice Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 16
TPU v3 tpu-v3-slice Varios hosts
  • Topología: 16x16
  • Número de chips de TPU: 256
  • Número de VMs: 32
TPU v3 tpu-v3-device Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
  1. Se calcula dividiendo el producto de la topología entre cuatro.

    Se admiten topologías personalizadas para más de 64 chips. Se aplican las siguientes condiciones:

    • Si hay más de 64 chips, {A}, {B} y {C} deben ser múltiplos de 4.
    • La topología más grande es 16x16x24
    • Los valores deben ser {A}{B}{C}, como 8x12x16.
  2. No se admiten topologías personalizadas.

Estándar

Después de elegir un tipo y una topología de TPU, especifícalos en el manifiesto de tu carga de trabajo. Para obtener instrucciones, consulta Desplegar cargas de trabajo de TPU en GKE Standard.

Versión de TPU Tipo de máquina Tipo de grupo de nodos Especificaciones técnicas
TPU Trillium (v6e) ct6e-standard-1t Un solo host
  • Topología: 1x1
  • Número de chips de TPU: 1
  • Número de VMs: 1
TPU Trillium (v6e) ct6e-standard-8t Un solo host
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 1
TPU Trillium (v6e) ct6e-standard-4t Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 32
TPU Trillium (v6e) ct6e-standard-4t Varios hosts
  • Topología: 16x16
  • Número de chips de TPU: 256
  • Número de VMs: 64
TPU v5p ct5p-hightpu-4t Un solo host
  • Topología: 2x2x1
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v5p ct5p-hightpu-4t Varios hosts
  • Topología: 2x2x2
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v5p ct5p-hightpu-4t Varios hosts
  • Topología: 2x2x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v5p ct5p-hightpu-4t Varios hosts
  • Topología: 2x4x4
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v5p ct5p-hightpu-4t Varios hosts
  • Topología: {A}x{B}x{C}
  • Número de chips de TPU: A*B*C
  • Número de VMs: (A*B*C/4)1
TPU v5e ct5lp-hightpu-1t Un solo host
  • Topología: 1x1
  • Número de chips de TPU: 1
  • Número de VMs: 1
TPU v5e ct5lp-hightpu-4t Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v5e ct5lp-hightpu-8t Un solo host
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 1
TPU v5e ct5lp-hightpu-4t Varios hosts
  • Topología: 2x4
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v5e ct5lp-hightpu-4t Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v5e ct5lp-hightpu-4t Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v5e ct5lp-hightpu-4t Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU v5e ct5lp-hightpu-4t Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 32
TPU v5e ct5p-hightpu-4t Varios hosts
  • Topología: 2x4x4
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v5e ct5p-hightpu-4t Un solo host
  • Topología: 2x2x1
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v4 ct4p-hightpu-4t Varios hosts
  • Topología: 2x2x2
  • Número de chips de TPU: 8
  • Número de VMs: 2
TPU v4 ct4p-hightpu-4t Varios hosts
  • Topología: 2x2x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v4 ct4p-hightpu-4t Varios hosts
  • Topología: 2x4x4
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v4 ct4p-hightpu-4t Varios hosts
  • Topología: {A}x{B}x{C}
  • Número de chips de TPU: A*B*C
  • Número de VMs: (A*B*C/4)1
TPU v3 ct3-hightpu-4t Un solo host
  • Topología: 2x2
  • Número de chips de TPU: 4
  • Número de VMs: 1
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 4x4
  • Número de chips de TPU: 16
  • Número de VMs: 4
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 4x8
  • Número de chips de TPU: 32
  • Número de VMs: 8
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 8x8
  • Número de chips de TPU: 64
  • Número de VMs: 16
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 8x16
  • Número de chips de TPU: 128
  • Número de VMs: 32
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 16x16
  • Número de chips de TPU: 256
  • Número de VMs: 64
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 16x32
  • Número de chips de TPU: 512
  • Número de VMs: 128
TPU v3 ct3p-hightpu-4t Varios hosts
  • Topología: 32x32
  • Número de chips de TPU: 1024
  • Número de VMs: 256
  1. Se calcula dividiendo el producto de la topología entre cuatro.

Configuración avanzada

En las siguientes secciones se describen las prácticas recomendadas de programación para configuraciones avanzadas de TPU.

Autoescalar TPUs en GKE

GKE admite unidades de procesamiento de tensor (TPUs) para acelerar las cargas de trabajo de aprendizaje automático. Tanto el grupo de nodos de segmento de TPU de un solo host como el grupo de nodos de segmento de TPU de varios hosts admiten el autoescalado y el aprovisionamiento automático.

Con la marca --enable-autoprovisioning en un clúster de GKE, GKE crea o elimina grupos de nodos de slices de TPU de un solo host o de varios hosts con una versión y una topología de TPU que cumplan los requisitos de las cargas de trabajo pendientes.

Cuando usas --enable-autoscaling, GKE escala el grupo de nodos en función de su tipo, de la siguiente manera:

  • Grupo de nodos de segmento de TPU de un solo host: GKE añade o elimina nodos de TPU en el grupo de nodos que ya existe. El grupo de nodos puede contener cualquier número de nodos de TPU entre cero y el tamaño máximo del grupo de nodos, determinado por las marcas --max-nodes y --total-max-nodes. Cuando se escala el grupo de nodos, todos los nodos de TPU del grupo de nodos tienen el mismo tipo de máquina y la misma topología. Para obtener más información sobre cómo crear un grupo de nodos de una porción de TPU de un solo host, consulta Crear un grupo de nodos.

  • Grupo de nodos de un segmento de TPU multihost: GKE escala de forma atómica el grupo de nodos de cero al número de nodos necesarios para cumplir la topología de la TPU. Por ejemplo, si tienes un grupo de nodos de TPU con el tipo de máquina ct5lp-hightpu-4t y una topología 16x16, el grupo de nodos contendrá 64 nodos. El escalador automático de GKE se asegura de que este grupo de nodos tenga exactamente 0 o 64 nodos. Cuando se reduce la escala, GKE expulsa todos los pods programados y reduce a cero todo el grupo de nodos. Para obtener más información sobre cómo crear un grupo de nodos de una porción de TPU de varios hosts, consulta Crear un grupo de nodos.

Aprovisionar almacenamiento adicional en un segmento de TPU

Una VM de una porción de TPU incluye un disco de arranque de 100 GiB. Si tu segmento de TPU necesita almacenamiento adicional para el entrenamiento o el preprocesamiento, o si necesitas guardar puntos de control, puedes usar el almacenamiento de Hyperdisk de Google Cloud o de Persistent Disk equilibrado si está disponible para tu TPU. Para obtener más información sobre los tipos de disco admitidos en cada versión de TPU, consulta el artículo sobre la compatibilidad de TPU con Hyperdisk y el disco persistente.

CPU para clústeres estándar

Esta sección no se aplica a los clústeres de Autopilot porque GKE coloca cada porción de TPU en su propio nodo. Para obtener más información, consulta Cómo funcionan las TPU en el modo Autopilot.

En los clústeres estándar, ten en cuenta las siguientes prácticas recomendadas de programación.

Para programar una carga de trabajo que no sea de TPU en una VM de un nodo de segmento de TPU, asegúrate de que tu pod de GKE pueda tolerar el taint google.com/tpu. Si quieres que la carga de trabajo se despliegue en nodos específicos, usa selectores de nodos.

La gestión de recursos y la prioridad de Kubernetes tratan las máquinas virtuales de las TPUs de la misma forma que otros tipos de máquinas virtuales. Para dar prioridad de programación a los pods que requieren TPUs sobre otros pods de los mismos nodos, solicita la CPU o la memoria máximas para esos segmentos de TPU. Los sectores de TPU de baja prioridad deben hacer lo siguiente:

  1. Define solicitudes de CPU y memoria bajas para asegurarte de que el nodo tenga suficientes recursos asignables para las cargas de trabajo de TPU. Para obtener más información, consulta Cómo aplica Kubernetes las solicitudes y los límites de recursos.
  2. No definas ningún límite de CPU (ilimitado) para asegurarte de que los pods puedan aumentar para usar todos los ciclos no utilizados.
  3. Define límites de memoria adecuados para asegurarte de que los pods puedan funcionar correctamente sin riesgo de desalojo por presión del nodo.

Si un pod de Kubernetes no solicita CPU ni memoria (aunque solicite TPUs), Kubernetes lo considera un pod de mejor esfuerzo y no hay ninguna garantía de que necesite CPU ni memoria. Solo los pods que soliciten explícitamente CPU y memoria tienen estas garantías. Para una programación específica de Kubernetes, configura las necesidades del pod con solicitudes explícitas de CPU y memoria. Para obtener más información, consulta Gestión de recursos para pods y contenedores.

Para obtener más información sobre las prácticas recomendadas, consulta Prácticas recomendadas de Kubernetes: solicitudes y límites de recursos.

Reducir las interrupciones de las cargas de trabajo

Si usas TPUs para entrenar un modelo de aprendizaje automático y tu carga de trabajo se interrumpe, se perderá todo el trabajo realizado desde el último punto de control. Para reducir la probabilidad de que se interrumpa tu carga de trabajo, haz lo siguiente:

  • Asigna una prioridad más alta a este trabajo que a todos los demás: si los recursos son escasos, el programador de GKE expropia los trabajos de menor prioridad para programar un trabajo de mayor prioridad. De esta forma, también te aseguras de que tu carga de trabajo de mayor prioridad reciba todos los recursos que necesita (hasta el total de recursos disponibles en el clúster). Para obtener más información, consulta Prioridad y preferencia de los pods.
  • Configurar una exclusión de mantenimiento: una exclusión de mantenimiento es un periodo de tiempo durante el cual no está permitido ejecutar tareas de mantenimiento automático. Para obtener más información, consulta Exclusiones de mantenimiento.
  • Usar pods con tiempo de ejecución ampliado en Autopilot: usa pods con tiempo de ejecución ampliado para disfrutar de un periodo de gracia de hasta siete días antes de que GKE finalice tus pods por reducciones o actualizaciones de nodos.
  • Usar la programación de colecciones en TPU Trillium: usa colecciones para indicar que un grupo de nodos de segmento de TPU forma parte de una carga de trabajo de servicio. Trusted Cloud limita y optimiza las interrupciones de las operaciones de las cargas de trabajo de inferencia. Para obtener más información, consulta Cómo funciona la programación de recogidas.

Estas recomendaciones ayudan a minimizar las interrupciones, pero no a evitarlas. Por ejemplo, se puede producir una expropiación debido a un fallo de hardware o una expropiación para la desfragmentación. Del mismo modo, si se define una exclusión de mantenimiento de GKE, no se evitarán los eventos de mantenimiento de Compute Engine.

Práctica recomendada:

Guarda los puntos de control con frecuencia y añade código a tu secuencia de comandos de entrenamiento para empezar desde el último punto de control cuando se reanude.

Gestionar las interrupciones debidas al mantenimiento de nodos

Los nodos de GKE que alojan las TPUs están sujetos a eventos de mantenimiento u otras interrupciones que pueden provocar que se apaguen. En los clústeres de GKE con el plano de control que ejecutan la versión 1.29.1-gke.1425000 y posteriores, puedes reducir las interrupciones de las cargas de trabajo configurando GKE para que finalice tus cargas de trabajo correctamente.

Para comprender, configurar y monitorizar los eventos de interrupción que pueden producirse en los nodos de GKE que ejecutan cargas de trabajo de IA o aprendizaje automático, consulta Gestionar interrupciones de nodos de GKE para GPUs y TPUs.

Maximizar la utilización de la TPU

Para maximizar tu inversión en TPUs, programa una combinación de prioridades de tareas y ponlas en cola para maximizar el tiempo que operan tus TPUs. Para la programación y la apropiación a nivel de tarea, debes usar un complemento de Kubernetes que organice las tareas en colas.

Práctica recomendada:

Usa Kueue para orquestar trabajos en colas.

Siguientes pasos