Pianificare le TPU in GKE

Questa pagina descrive come pianificare l'utilizzo delle Tensor Processing Unit (TPU) in Google Kubernetes Engine (GKE) per ridurre il rischio di errori di configurazione errata delle TPU, di non disponibilità o di interruzioni dovute al superamento della quota.

Prima di utilizzare le TPU in GKE, assicurati di conoscere le definizioni e la terminologia delle TPU in GKE.

Pianificare la configurazione TPU

Per lavorare con le TPU nei cluster GKE, devi pianificare la loro configurazione. Ti consigliamo di procedere nel seguente modo:

  1. Scegli una modalità operativa GKE: esegui i carichi di lavoro sulle TPU in un cluster GKE Autopilot o Standard.

    Best practice:

    Utilizza un cluster Autopilot per un'esperienza Kubernetes completamente gestita.

  2. Scegli la versione della TPU: i diversi tipi di TPU hanno capacità diverse, come rapporti prezzo/prestazioni, velocità effettiva di addestramento e latenza di servizio. I tipi di TPU influiscono sulle capacità di CPU e memoria disponibili.

  3. Verifica della disponibilità delle TPU: le TPU sono disponibili in regioni specifiche. Google CloudPer utilizzare un tipo di TPU nel tuo workload GKE, il cluster deve trovarsi in una regione supportata per quel tipo.

  4. Scegli la topologia TPU: la disposizione fisica delle TPU all'interno di una sezione di TPU. Seleziona una topologia che corrisponda ai requisiti di parallelismo del tuo modello.

Utilizza le tabelle di riferimento in questa pagina per identificare se i tuoi node pool sono nodi TPU slice single-host o multi-host.

Scegliere una modalità operativa di GKE

Puoi utilizzare le TPU nelle modalità operative di GKE disponibili per i cluster:

  • Modalità Autopilot (consigliata): GKE gestisce l'infrastruttura di base, ad esempio configurazione dei nodi, scalabilità automatica, upgrade automatici, configurazioni di base della sicurezza e configurazione di base del networking. In Autopilot, scegli un tipo e una topologia di TPU, quindi specificali nel manifest Kubernetes. GKE gestisce il provisioning dei nodi con le TPU e la pianificazione dei workload.
  • Modalità Standard: gestisci l'infrastruttura di base, inclusa la configurazione dei singoli nodi.

Per scegliere la modalità operativa GKE più adatta ai tuoi carichi di lavoro, consulta Scegliere una modalità operativa GKE.

Scegli la versione TPU

Le VM in uno slice TPU hanno le seguenti caratteristiche tecniche.

Autopilot

Versione TPU Tipo di macchina Numero di vCPU Memoria (GiB) Numero di nodi NUMA Numero massimo di chip TPU in un nodo di sezione TPU
TPU Trillium (v6e) tpu-v6e-slice Da 44 a 180 Da 176 a 1440 Da 1 a 2 256
TPU v5p
 tpu-v5p-slice 208 448 2 6144
TPU v5e
 tpu-v5-lite-podslice 24-224 da 48 a 384 1 256
TPU v4
 tpu-v4-podslice 240 407 2 4096
TPU v3 (solo single-host)
 tpu-v3-device 96 340 2 8
TPU v3
 tpu-v3-slice 48 340 1 256

Standard

Versione TPU Tipo di macchina Numero di vCPU Memoria (GiB) Numero di nodi NUMA Probabilità di prerilascio
TPU Trillium (v6e) ct6e-standard-1t 44 448 2 Maggiore
TPU Trillium (v6e) ct6e-standard-4t 180 720 1 Media
TPU Trillium (v6e) ct6e-standard-8t 180 1440 2 Meno
TPU v5p
 ct5p-hightpu-4t 208 448 2
TPU v5e
 ct5lp-hightpu-1t 24 48 1 Maggiore
TPU v5e
 ct5lp-hightpu-4t 112 192 1 Media
TPU v5e
 ct5lp-hightpu-8t 224 384 1 Bassa
TPU v4
 ct4p-hightpu-4t 240 407 2
TPU v3 (solo single-host)
 ct3-hightpu-4t 96 340 2
TPU v3
 ct3p-hightpu-4t 48 340 1

I tipi di macchine ct5lp- multi-host sono più adatti per l'utilizzo di modelli di grandi dimensioni o per l'addestramento. Le macchine ct5lp- multi-host sono interconnesse con link ad alta velocità.

Esamina le specifiche e i prezzi delle TPU nella documentazione sui prezzi di Cloud TPU per decidere quale configurazione TPU utilizzare.

Limitazioni

Tieni presenti queste limitazioni quando scegli la TPU da utilizzare:

  • TPU Trillium è disponibile nelle seguenti versioni:
    • Cluster standard nella versione 1.31.1-gke.1846000 e successive.
    • Cluster Autopilot nella versione 1.31.2-gke.1115000 e successive.
  • TPU Trillium non supporta la configurazione di SMT impostato su 2 su ct6e-standard-8t.
  • La ripartizione dei costi GKE e la misurazione dell'utilizzo non includono dati sull'utilizzo o sui costi delle TPU v4 riservate.
  • La scalabilità automatica delle TPU v5p è supportata sui cluster GKE con piani di controllo che eseguono almeno la versione 1.29.2-gke.1035000 o 1.28.7-gke.1020000.
  • Per le prenotazioni di capacità, utilizza una prenotazione specifica.
  • Puoi eseguire un massimo di 256 pod in una singola VM TPU.
  • La misurazione dell'utilizzo e l'allocazione dei costi di GKE non includono dati sull'utilizzo o sui costi delle TPU.
  • Il gestore della scalabilità automatica del cluster annulla le operazioni di scale up del pool di nodi TPU che rimangono in stato di attesa per più di 10 ore. Il gestore della scalabilità automatica dei cluster riprova queste operazioni di scalabilità verticale quando le risorse sono disponibili. Questo comportamento potrebbe ridurre la disponibilità di TPU se non utilizzi le prenotazioni.
  • I nodi Ubuntu non sono supportati.
  • L'architettura del nodo TPU è deprecata. TPU v3 è l'unica versione di TPU che supporta ancora l'architettura dei nodi TPU in GKE.

Convalida la disponibilità di TPU in GKE

Le TPU sono disponibili in regioni Google Cloud specifiche. Per utilizzare un tipo di TPU nel cluster GKE, il cluster deve trovarsi in una regione supportata per quel tipo.

Autopilot

Versione TPU cloud.google.com/gke-tpu-accelerator Versione GKE minima Disponibilità 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

Standard

Versione TPU Tipo di macchina che inizia con Versione GKE minima Disponibilità 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
Quando configuri una TPU, tieni presente i seguenti avvisi:
  • Puoi creare un pool di nodi TPU v5e a singolo host con un tipo di macchina che inizia con ct5lp- in determinate zone (europe-west4-a, us-east5-b e us-west4-b). Puoi utilizzare ct5lp-hightpu-4t con una topologia di almeno 2x4 o superiore in queste zone.
  • Per creare una TPU v5e a singolo host nella regione us-west4, scegli la zona us-west4-a e utilizza tipi di macchina che iniziano con ct5lp-, ad esempio ct5lp-hightpu-1t.

Scegli una topologia

Dopo aver scelto una versione di TPU, seleziona una topologia supportata da quel tipo di TPU. A seconda del tipo di TPU, la topologia è bidimensionale o tridimensionale. I requisiti di parallelismo del modello ti aiutano a decidere una topologia. Puoi identificare il numero di chip TPU nella sezione calcolando il prodotto di ogni dimensione nella topologia. Ad esempio:

  • 2x2x2 è una sezione TPU v4 multi-host da 8 chip
  • 2x2 è una sezione TPU v5e a 4 chip con un singolo host

Se una topologia specifica supporta nodi TPU slice sia single-host che multi-host, il tipo di host viene determinato dal numero di chip TPU richiesti dal carico di lavoro.

Ad esempio, TPU v5e (tpu-v5-lite-podslice) supporta la topologia 2x4 sia come host singolo che multi-host. Se:

  • Se richiedi 4 chip nel tuo workload, ottieni un nodo multi-host con 4 chip TPU.
  • Se richiedi 8 chip nel tuo carico di lavoro, riceverai un nodo single-host con 8 chip TPU.

Utilizza la seguente tabella per scegliere il tipo di macchina TPU e la topologia per il tuo caso d'uso:

  • Per l'addestramento o l'inferenza di modelli su piccola scala, utilizza TPU v4 o TPU v5e con pool di nodi di slice TPU a host singolo.
  • Per l'addestramento o l'inferenza di modelli su larga scala, utilizza TPU v4 o TPU v5e con node pool di slice TPU multi-host.
  • Per l'addestramento o l'inferenza su larga scala, utilizza Pathways. Pathways semplifica i calcoli di machine learning su larga scala consentendo a un singolo client JAX di orchestrare i carichi di lavoro su più sezioni di TPU di grandi dimensioni. Per saperne di più, consulta Percorsi.

Autopilot

Dopo aver scelto un tipo e una topologia di TPU, specificali nel manifest del workload. Per istruzioni, consulta Esegui il deployment dei carichi di lavoro TPU in GKE Autopilot.

Versione TPU Tipo di macchina Tipo di node pool Specifiche tecniche
TPU Trillium (v6e) tpu-v6e-slice Host singolo
  • Topologia: 1x1
  • Numero di chip TPU: 1
  • Numero di VM: 1
TPU Trillium (v6e) tpu-v6e-slice Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 4
TPU Trillium (v6e) tpu-v6e-slice Host singolo
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 8
TPU Trillium (v6e) tpu-v6e-slice Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU Trillium (v6e) tpu-v6e-slice Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU Trillium (v6e) tpu-v6e-slice Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU Trillium (v6e) tpu-v6e-slice Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 32
TPU Trillium (v6e) tpu-v6e-slice Multi-host
  • Topologia: 16x16
  • Numero di chip TPU: 256
  • Numero di VM: 64
TPU v5p tpu-v5p-slice Host singolo
  • Topologia: 2x2x1
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v5p tpu-v5p-slice Multi-host
  • Topologia: 2x2x2
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v5p tpu-v5p-slice Multi-host
  • Topologia: 2x2x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v5p tpu-v5p-slice Multi-host
  • Topologia: 2x4x4
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v5p tpu-v5p-slice Multi-host
  • Topologia: 4x4x4
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU v5p tpu-v5p-slice Multi-host
  • Topologia: {A}x{B}x{C}
  • Numero di chip TPU: {A}*{B}*{C}
  • Numero di VM: (A*B*C/4)1
TPU v5e tpu-v5-lite-podslice Host singolo
  • Topologia: 1x1
  • Numero di chip TPU: 1
  • Numero di VM: 1
TPU v5e tpu-v5-lite-podslice Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v5e tpu-v5-lite-podslice Host singolo
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 1
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 32
TPU v5e tpu-v5-lite-podslice Multi-host
  • Topologia: 16x16
  • Numero di chip TPU: 256
  • Numero di VM: 64
TPU v5e (solo single-host) tpu-v5-lite-device Host singolo
  • Topologia: 1x1
  • Numero di chip TPU: 1
  • Numero di VM: 1
TPU v5e (solo single-host) tpu-v5-lite-device Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v5e (solo single-host) tpu-v5-lite-device Host singolo
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 1
TPU v4 tpu-v4-podslice Host singolo
  • Topologia: 2x2x1
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v4 tpu-v4-podslice Multi-host
  • Topologia: 2x2x2
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v4 tpu-v4-podslice Multi-host
  • Topologia: 2x2x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v4 tpu-v4-podslice Multi-host
  • Topologia: 2x4x4
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v4 tpu-v4-podslice Multi-host
  • Topologia: 4x4x4
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU v4 tpu-v4-podslice Multi-host
  • Topologia: {A}x{B}x{C}
  • Numero di chip TPU: {A}*{B}*{C}
  • Numero di VM: (A*B*C/4)1
TPU v3 tpu-v3-slice Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 2
TPU v3 tpu-v3-slice Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 4
TPU v3 tpu-v3-slice Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 8
TPU v3 tpu-v3-slice Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 16
TPU v3 tpu-v3-slice Multi-host
  • Topologia: 16x16
  • Numero di chip TPU: 256
  • Numero di VM: 32
TPU v3 tpu-v3-device Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1

  1. Calcolato dividendo il prodotto della topologia per quattro. ↩

    Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:

    • Per più di 64 chip, {A}, {B} e {C} devono essere multipli di 4
    • La topologia più grande è 16x16x24
    • I valori devono essere {A}≤{B}≤{C}, come 8x12x16.

  2. Le topologie personalizzate non sono supportate.

Standard

Dopo aver scelto un tipo e una topologia di TPU, specificali nel manifest del workload. Per istruzioni, vedi Esegui il deployment dei carichi di lavoro TPU su GKE Standard.

Versione TPU Tipo di macchina Tipo di node pool Specifiche tecniche
TPU Trillium (v6e) ct6e-standard-1t Host singolo
  • Topologia: 1x1
  • Numero di chip TPU: 1
  • Numero di VM: 1
TPU Trillium (v6e) ct6e-standard-8t Host singolo
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 1
TPU Trillium (v6e) ct6e-standard-4t Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 32
TPU Trillium (v6e) ct6e-standard-4t Multi-host
  • Topologia: 16x16
  • Numero di chip TPU: 256
  • Numero di VM: 64
TPU v5p ct5p-hightpu-4t Host singolo
  • Topologia: 2x2x1
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v5p ct5p-hightpu-4t Multi-host
  • Topologia: 2x2x2
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v5p ct5p-hightpu-4t Multi-host
  • Topologia: 2x2x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v5p ct5p-hightpu-4t Multi-host
  • Topologia: 2x4x4
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v5p ct5p-hightpu-4t Multi-host
  • Topologia: {A}x{B}x{C}
  • Numero di chip TPU: A*B*C
  • Numero di VM: (A*B*C/4)1
TPU v5e ct5lp-hightpu-1t Host singolo
  • Topologia: 1x1
  • Numero di chip TPU: 1
  • Numero di VM: 1
TPU v5e ct5lp-hightpu-4t Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v5e ct5lp-hightpu-8t Host singolo
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 1
TPU v5e ct5lp-hightpu-4t Multi-host
  • Topologia: 2x4
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v5e ct5lp-hightpu-4t Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v5e ct5lp-hightpu-4t Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v5e ct5lp-hightpu-4t Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU v5e ct5lp-hightpu-4t Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 32
TPU v5e ct5p-hightpu-4t Multi-host
  • Topologia: 2x4x4
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v5e ct5p-hightpu-4t Host singolo
  • Topologia: 2x2x1
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v4 ct4p-hightpu-4t Multi-host
  • Topologia: 2x2x2
  • Numero di chip TPU: 8
  • Numero di VM: 2
TPU v4 ct4p-hightpu-4t Multi-host
  • Topologia: 2x2x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v4 ct4p-hightpu-4t Multi-host
  • Topologia: 2x4x4
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v4 ct4p-hightpu-4t Multi-host
  • Topologia: {A}x{B}x{C}
  • Numero di chip TPU: A*B*C
  • Numero di VM: (A*B*C/4)1
TPU v3 ct3-hightpu-4t Host singolo
  • Topologia: 2x2
  • Numero di chip TPU: 4
  • Numero di VM: 1
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 4x4
  • Numero di chip TPU: 16
  • Numero di VM: 4
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 4x8
  • Numero di chip TPU: 32
  • Numero di VM: 8
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 8x8
  • Numero di chip TPU: 64
  • Numero di VM: 16
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 8x16
  • Numero di chip TPU: 128
  • Numero di VM: 32
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 16x16
  • Numero di chip TPU: 256
  • Numero di VM: 64
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 16x32
  • Numero di chip TPU: 512
  • Numero di VM: 128
TPU v3 ct3p-hightpu-4t Multi-host
  • Topologia: 32x32
  • Numero di chip TPU: 1024
  • Numero di VM: 256

  1. Calcolato dividendo il prodotto della topologia per quattro. ↩

Configurazioni avanzate

Le sezioni seguenti descrivono le best practice di pianificazione per le configurazioni TPU avanzate.

Prenotazione TPU

Le prenotazioni TPU sono disponibili al momento dell'acquisto di un impegno. Qualsiasi prenotazione TPU può essere utilizzata con GKE.

Quando crei un pool di nodi di slice TPU, utilizza i flag --reservation e --reservation-affinity=specific per utilizzare un'istanza TPU riservata.

Scalabilità automatica delle TPU in GKE

GKE supporta le Tensor Processing Unit (TPU) per accelerare i carichi di lavoro di machine learning. Sia il node pool di sezioni TPU single-host sia il node pool di sezioni TPU multi-host supportano la scalabilità automatica e il provisioning automatico.

Con il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina node pool di sezioni TPU single-host o multi-host con una versione e una topologia TPU che soddisfano i requisiti dei carichi di lavoro in attesa.

Quando utilizzi --enable-autoscaling, GKE scala il pool di nodi in base al suo tipo, come segue:

  • Pool di nodi della sezione TPU single-host: GKE aggiunge o rimuove i nodi TPU nel node pool esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi determinata dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool di nodi hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi TPU a host singolo, consulta Creare un node pool.

  • Pool di nodi della sezione TPU multi-host: GKE aumenta in modo atomico il pool di nodi da zero al numero di nodi necessari per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con un tipo di macchina ct5lp-hightpu-4t e una topologia 16x16, il pool di nodi contiene 64 nodi. Lo strumento di scalabilità automatica di GKE garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Quando esegui lo scale down, GKE espelle tutti i pod pianificati e svuota l'intero pool di nodi fino a zero. Per scoprire di più su come creare un pool di nodi TPU multi-host, consulta Crea un pool di nodi.

Esegui il provisioning di spazio di archiviazione aggiuntivo per una sezione TPU

Una VM in una sezione TPU include un disco di avvio da 100 GiB. Se la tua slice TPU ha bisogno di spazio di archiviazione aggiuntivo per l'addestramento o il pre-elaborazione oppure se devi salvare i checkpoint, puoi utilizzare lo spazio di archiviazione Google Cloud Hyperdisk o Balanced Persistent Disk, se disponibile per la tua TPU. Per saperne di più sui tipi di dischi supportati per ogni versione della TPU, consulta Supporto della TPU per Hyperdisk e Persistent Disk.

CPU per i cluster Standard

Questa sezione non si applica ai cluster Autopilot perché GKE inserisce ogni slice TPU sul proprio nodo. Per saperne di più, consulta l'articolo Come funzionano le TPU in modalità Autopilot.

Per i cluster Standard, considera le seguenti best practice di pianificazione.

Per pianificare un carico di lavoro non TPU su una VM in un nodo di sezione TPU, assicurati che il pod GKE possa tollerare l'incompatibilità google.com/tpu. Se vuoi che il carico di lavoro venga distribuito su nodi specifici, utilizza i selettori di nodi.

La gestione e la priorità delle risorse Kubernetes trattano le VM nelle TPU allo stesso modo degli altri tipi di VM. Per dare la priorità di pianificazione ai pod che richiedono TPU rispetto ad altri pod sugli stessi nodi, richiedi la CPU o la memoria massima per queste sezioni di TPU. Le sezioni TPU a bassa priorità devono:

  1. Imposta richieste di CPU e memoria basse per assicurarti che il nodo disponga di risorse allocabili sufficienti per i carichi di lavoro TPU. Per saperne di più, consulta Come Kubernetes applica richieste e limiti delle risorse.
  2. Imposta nessun limite di CPU (illimitato) per garantire che i pod possano aumentare per utilizzare tutti i cicli inutilizzati.
  3. Imposta limiti di memoria appropriati per garantire che i pod possano funzionare correttamente senza rischiare l'eliminazione per pressione del nodo.

Se un pod Kubernetes non richiede CPU e memoria (anche se richiede TPU), Kubernetes lo considera un pod di tipo best-effort e non è garantito che abbia bisogno di CPU e memoria. Solo i pod che richiedono esplicitamente CPU e memoria hanno queste garanzie. Per una pianificazione Kubernetes specifica, configura le esigenze del pod con una richiesta esplicita di CPU e memoria. Per saperne di più, consulta Gestione delle risorse per pod e container.

Per scoprire altre best practice, consulta Best practice di Kubernetes: richieste e limiti delle risorse.

Ridurre le interruzioni del workload

Se utilizzi le TPU per addestrare un modello di machine learning e il tuo carico di lavoro viene interrotto, tutto il lavoro eseguito dall'ultimo checkpoint viene perso. Per ridurre la probabilità che il tuo workload venga interrotto:

  • Imposta una priorità più alta per questo job rispetto a tutti gli altri job: se le risorse sono scarse, lo scheduler GKE esegue la preemption dei job con priorità più bassa per pianificare un job con priorità più alta. In questo modo, il carico di lavoro con priorità più alta riceve tutte le risorse di cui ha bisogno (fino al totale delle risorse disponibili nel cluster). Per scoprire di più, consulta Priorità e prerilascio dei pod.
  • Configura l'esclusione di manutenzione: un'esclusione di manutenzione è un periodo di tempo non ricorrente durante il quale è vietata la manutenzione automatica. Per scoprire di più, consulta Esclusioni dalla manutenzione.
  • Utilizza i pod con tempo di esecuzione esteso in Autopilot: utilizza i pod con tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima che GKE termini i pod per ridimensionamenti o upgrade dei nodi.
  • Utilizza la pianificazione delle raccolte in TPU Trillium: utilizza le raccolte per indicare che un pool di nodi di sezioni TPU fa parte di un workload di servizio. Google Cloud limita e semplifica le interruzioni delle operazioni dei workload di inferenza. Per scoprire di più, vedi Come funziona la pianificazione della raccolta.

Questi consigli aiutano a ridurre al minimo le interruzioni, ma non a evitarle. Ad esempio, può comunque verificarsi un'interruzione dovuta a un guasto hardware o un'interruzione per la deframmentazione. Allo stesso modo, l'impostazione di un'esclusione dalla manutenzione di GKE non impedisce gli eventi di manutenzione di Compute Engine.

Best practice:

Salva spesso i checkpoint e aggiungi codice allo script di addestramento per riprendere dall'ultimo checkpoint quando viene ripreso.

Gestire l'interruzione dovuta alla manutenzione dei nodi

I nodi GKE che ospitano le TPU sono soggetti a eventi di manutenzione o ad altre interruzioni che potrebbero causare l'arresto del nodo. Nei cluster GKE con il control plane che esegue la versione 1.29.1-gke.1425000 e successive, puoi ridurre le interruzioni dei workload configurando GKE in modo che li termini in modo controllato.

Per comprendere, configurare e monitorare gli eventi di interruzione che potrebbero verificarsi sui nodi GKE che eseguono carichi di lavoro AI/ML, consulta Gestire l'interruzione dei nodi GKE per GPU e TPU.

Massimizzare l'utilizzo della TPU

Per massimizzare l'investimento nelle TPU, pianifica una combinazione di priorità dei job e mettili in coda per massimizzare il tempo di funzionamento delle TPU. Per la pianificazione e la preemption a livello di job, devi utilizzare un componente aggiuntivo di Kubernetes che orchestra i job in code.

Best practice:

Utilizza Kueue per orchestrare i job nelle code.

Passaggi successivi