Questa pagina presenta Cloud TPU e mostra dove trovare informazioni sull'utilizzo di Cloud TPU con Google Kubernetes Engine (GKE). Le TPU (Tensor Processing Unit) sono circuiti integrati per applicazioni specifiche (ASIC) sviluppati da Google e utilizzati per accelerare i carichi di lavoro di machine learning che utilizzano framework come TensorFlow, PyTorch e JAX.
Prima di utilizzare le TPU in GKE, ti consigliamo di completare il seguente percorso di apprendimento:
- Scopri come funzionano gli acceleratori di machine learning con Introduzione a Cloud TPU.
- Scopri di più sulla disponibilità attuale delle versioni di TPU con l'architettura di sistema di Cloud TPU.
Per scoprire come configurare Cloud TPU in GKE, consulta le seguenti risorse:
- Esegui il deployment dei carichi di lavoro TPU in GKE Autopilot
- Esegui il deployment dei carichi di lavoro TPU in GKE Standard
Vantaggi dell'utilizzo delle TPU in GKE
GKE offre supporto completo per la gestione del ciclo di vita delle VM TPU, incluse creazione, configurazione ed eliminazione delle VM TPU. GKE supporta anche le VM spot e l'utilizzo di Cloud TPU prenotate. I vantaggi dell'utilizzo delle TPU in GKE includono:
- Ambiente operativo coerente: un'unica piattaforma per tutti i carichi di lavoro e di machine learning.
- Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, riducendo i costi operativi.
- Bilanciamento del carico: GKE distribuisce il carico riducendo la latenza e migliorando l'affidabilità.
- Scalabilità reattiva: GKE scala automaticamente le risorse TPU per soddisfare le esigenze dei tuoi carichi di lavoro.
- Gestione delle risorse: con Kueue, un sistema di coda dei job nativo di Kubernetes, puoi gestire le risorse di più tenant all'interno della tua organizzazione utilizzando la coda, il prerilascio, l'assegnazione delle priorità e la condivisione equa.
Terminologia relativa alle TPU in GKE
Questo documento utilizza la seguente terminologia relativa alle TPU:
- Tipo di TPU: il tipo di Cloud TPU, ad esempio v5e.
- Sezione TPU: un insieme di chip TPU interconnessi.
- Topologia TPU: il numero e la disposizione fisica dei chip TPU in una sezione TPU.
- Nodi sezione TPU con singolo host: uno o più nodi TPU indipendenti. Le TPU collegate alle VM non sono connesse tra loro da interconnessioni ad alta velocità.
- Nodi sezione TPU multi-host: due o più nodi TPU interconnessi. Le TPU collegate alle VM sono collegate da interconnessioni ad alta velocità. I nodi TPU multi-host hanno le seguenti caratteristiche:
- Atomico: GKE tratta tutti i nodi interconnessi come una singola unità. Durante le operazioni di scalabilità, GKE scala l'intero set di nodi a 0 e ne crea di nuovi. Se una macchina del gruppo si guasta o termina, GKE ricrea l'intero set di nodi come una nuova unità.
- Immutabile: non puoi aggiungere manualmente nuovi nodi al set di nodi interconnessi.
Come funzionano le TPU in GKE
La gestione e la priorità delle risorse di Kubernetes trattano le VM TPU come se fossero altri tipi di VM. Puoi richiedere i chip TPU utilizzando il nome della risorsa google.com/tpu:
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Quando utilizzi le TPU in GKE, devi considerare le seguenti caratteristiche delle TPU:
- Una VM TPU può accedere a un massimo di 8 chip TPU.
- Una sezione TPU contiene un numero fisso di chip TPU che dipende dal tipo di macchina TPU scelto.
- Il numero di
google.com/tpurichiesti deve essere uguale al numero totale di chip disponibili sul nodo TPU. Qualsiasi container in un pod GKE che richiede le TPU deve consumare tutti i chip TPU nel nodo. In caso contrario, il deployment non riesce perché GKE non può utilizzare parzialmente le risorse TPU. Ad esempio, consulta i seguenti scenari:- Il tipo di macchina
ct5l-hightpu-8tha un singolo nodo TPU con 8 chip TPU. È possibile eseguire il deployment sul nodo di un pod GKE che richiede otto chip TPU, ma non è possibile eseguire il deployment di due pod GKE che richiedono quattro chip TPU. - Il tipo di macchina
ct5lp-hightpu-4tcon topologia2x4contiene due nodi TPU con quattro chip ciascuno, per un totale di otto chip TPU. Non è possibile eseguire il deployment di un pod GKE che richiede otto chip TPU in nessuno dei nodi in questo pool di nodi, ma è possibile eseguire il deployment di due pod che richiedono quattro chip TPU su ciascuno dei due nodi nel pool. - TPU v5e con topologia 4x4 ha 16 chip in quattro nodi. Il carico di lavoro GKE Autopilot che seleziona questa configurazione deve richiedere quattro chip in ogni replica, per un massimo di quattro.
- Il tipo di macchina
- Nei cluster Standard, su una VM TPU possono essere pianificati più pod Kubernetes, ma solo un container in ciascun pod può accedere ai chip TPU.
- Ogni cluster standard deve avere almeno un pool di nodi non TPU per creare pod kube-system, ad esempio kube-dns.
- Per impostazione predefinita, i nodi TPU hanno
google.com/tpuincompatibilità che impedisce la pianificazione dei pod non TPU. L'incompatibilità non garantisce che le risorse TPU siano pienamente utilizzate. Consente di eseguire carichi di lavoro che non utilizzano TPU su nodi non TPU, liberando risorse di calcolo sui nodi TPU per il codice che utilizza le TPU. - GKE raccoglie i log emessi dai container in esecuzione sulle VM TPU. Per scoprire di più, consulta Logging.
- Le metriche di utilizzo delle TPU, come le prestazioni di runtime, sono disponibili in Cloud Monitoring. Per scoprire di più, consulta Osservabilità e metriche.
Pianifica la configurazione TPU
Per lavorare con le TPU nei cluster GKE, devi decidere i seguenti parametri:
- Tipo di TPU: i diversi tipi di TPU hanno funzionalità diverse come rapporto prezzo-prestazioni, velocità effettiva di addestramento e latenza di gestione. Le VM a cui sono collegate le TPU hanno capacità di CPU e memoria diverse.
- Topologia: il layout dei chip nel tipo di TPU. Ogni tipo di TPU supporta un layout di chip 2D o 3D e disposizioni specifiche. Seleziona una topologia che corrisponda ai requisiti di parallelismo del modello.
Interconnessione TPU: il tipo e la topologia di TPU determinano se ricevi o meno le TPU in più nodi con interconnessioni ad alta velocità. Questo determina se vuoi nodi di sezione TPU con host singolo o multi-host.
- Per i modelli su larga scala, utilizza nodi di sezione TPU multi-host
- Per i modelli su scala ridotta, utilizza nodi di sezione TPU con singolo host
Scegli una configurazione TPU per la modalità GKE Autopilot
In Autopilot, scegli un tipo di TPU e una topologia e li specifichi nel manifest di Kubernetes. GKE gestisce il provisioning dei nodi con TPU e la pianificazione dei carichi di lavoro.
Disponibilità di TPU in GKE Autopilot
Le TPU sono disponibili in regioni Google Cloud specifiche. Per utilizzare un tipo di TPU nel tuo carico di lavoro GKE, il cluster deve trovarsi in una regione supportata per quel tipo. Per maggiori dettagli, consulta Regioni e zone TPU nella documentazione di Cloud TPU.
Scegli un tipo di TPU in Autopilot
| Tipo di TPU | Numero di vCPU | Memoria (GiB) | Numero di NUMA nodi | Numero massimo di chip TPU in una sezione |
|---|---|---|---|---|
TPU v5p (anteprima)tpu-v5p-slice |
208 | 448 | 2 | 6.144 |
TPU v5etpu-v5-lite-podslice |
Da 24 a 224 | Da 48 a 384 | 1 | 256 |
TPU v5e (solo host singolo)tpu-v5-lite-device |
Da 24 a 224 | Da 48 a 384 | Da 1 a 2 | 8 |
TPU v4tpu-v4-podslice |
240 | 407 | 2 | 4096 |
Esamina le specifiche e i prezzi dei chip nella documentazione di Cloud TPU per decidere quale versione utilizzare.
Scegli una topologia per Autopilot
La topologia è il layout fisico dei chip in una sezione TPU. A seconda del tipo di TPU, la topologia è bidimensionale o tridimensionale. Dopo aver deciso il tipo di TPU, seleziona una topologia supportata da quel tipo. I requisiti di parallelismo del modello ti aiuteranno a scegliere una topologia. Il prodotto della topologia è il numero di chip nella sezione. Ad esempio:
2x2x2è una sezione TPU v4 multi-host a 8 chip2x2è una sezione TPU v5e con host singolo a 4 chip
La topologia selezionata per un tipo di TPU determina la presenza di nodi di sezione TPU con singolo
o più host. Se una topologia specifica supporta sezioni con host singolo e multi-host, il tipo di host ottenuto dipende dal numero di chip TPU richiesti dal carico di lavoro. Ad esempio, TPU v5e
(tpu-v5-lite-podslice) supporta la topologia 2x4 come host singolo e multi-host. Se richiedi 4 chip nel tuo carico di lavoro, ottieni un nodo multi-host con 4 chip. Se richiedi 8 chip nel tuo carico di lavoro, ottieni un nodo host singolo con 8 chip.
La seguente tabella descrive le topologie supportate in ogni tipo di TPU e il numero di chip, il numero di nodi e il tipo di host:
| Tipo di TPU | Topologia | Chip TPU in una sezione | Numero di nodi | Tipo di host | Note |
|---|---|---|---|---|---|
TPU v5p (anteprima)tpu-v5p-slice |
2x2x1 | 4 | 1 | Host singolo | Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:
|
| 2x2x2 | 8 | 2 | Host multipli | ||
| 2x2x4 | 16 | 4 | Host multipli | ||
| 2x4x4 | 32 | 8 | Host multipli | ||
| 4x4x4 | 64 | 16 | Host multipli | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Host multipli | ||
TPU v5etpu-v5-lite-podslice |
1x1 | 1 | 1 | Host singolo | Le topologie personalizzate non sono supportate. |
| 2x2 | 4 | 1 | |||
| 2x4 | 8 | 1 | |||
| 2x4 | 2 | 1 | Host multipli | ||
| 4x4 | 16 | 4 | |||
| 4x8 | 32 | 8 | |||
| 8x8 | 64 | 16 | |||
| 8x16 | 128 | 32 | |||
| 16x16 | 256 | 64 | |||
TPU v5e (solo host singolo)tpu-v5-lite-device |
1x1 | 1 | 1 | Host singolo | Le topologie personalizzate non sono supportate |
| 2x2 | 4 | 1 | |||
| 2x4 | 8 | 1 | |||
TPU v4tpu-v4-podslice |
2x2x1 | 4 | 1 | Host singolo | Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:
|
| 2x2x2 | 8 | 2 | Host multipli | ||
| 2x2x4 | 16 | 4 | Host multipli | ||
| 2x4x4 | 32 | 8 | Host multipli | ||
| 4x4x4 | 64 | 16 | Host multipli | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Host multipli |
-
Viene calcolato dividendo il prodotto della topologia per quattro. ↩
Dopo aver scelto un tipo di TPU e una topologia, specificali nel manifest dei carichi di lavoro. Per le istruzioni, consulta Eseguire il deployment dei carichi di lavoro TPU su GKE Autopilot.
Scegli una configurazione TPU per la modalità GKE Standard
Le seguenti sezioni descrivono le caratteristiche delle TPU che valuti durante la pianificazione e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli sulle versioni disponibili, i tipi di macchina, le topologie valide e il numero di chip, consulta la sezione Mappatura delle configurazioni TPU in questo documento.
Disponibilità delle TPU in modalità GKE Standard
La seguente tabella elenca la disponibilità della TPU in base al tipo e alla versione della macchina:
| Versione TPU | Tipo di macchina che inizia con | Versione minima di GKE | Disponibilità | Zona |
|---|---|---|---|---|
| TPU v4 | ct4p- |
1.26.1-gke.1500 | Generalmente disponibile | us-central2-b |
| TPU v5e | ct5l- |
1.27.2-gke.2100 | Generalmente disponibile | europe-west4-b |
us-central1-a |
||||
| TPU v5e | ct5lp- |
1.27.2-gke.2100 | Generalmente disponibile | europe-west4-a1 |
us-central1-a1 |
||||
us-east1-c |
||||
us-east5-b1 |
||||
us-west1-c |
||||
us-west4-a |
||||
us-west4-b1 |
||||
| TPU v5p | ct5p- |
1.28.3-gke.1024000 | Anteprima | us-east1-d |
us-east5-a |
||||
us-east5-c |
-
Quando crei una TPU v5e con un tipo di macchina che inizia con
ct5lp-in una delle zoneeurope-west4-a,us-central1-a,us-east5-bous-west4-b, i pool di nodi TPU v5e con singolo host non sono supportati. In altre parole, quando crei un pool di nodi TPU v5e in una di queste zone, è supportato solo il tipo di macchinact5lp-hightpu-4tcon una topologia di almeno2x4o superiore. Per creare una TPU v5e con singolo host inus-central1oeurope-west4, scegli rispettivamente le zoneus-central1-aoeurope-west4-be utilizza i tipi di macchina che iniziano conct5l-, comect5l-hightpu-1t,ct5l-hightpu-4toct5l-hightpu-8t. Per creare una TPU v5e con singolo host nella regioneus-west4, scegli la zonaus-west4-ae utilizza i tipi di macchine che iniziano conct5lp-comect5lp-hightpu-1t. Tieni presente che i tipi di macchine che iniziano conct5l-richiedono una quota diversa rispetto ai tipi di macchine che iniziano conct5lp-. ↩
Le seguenti sezioni descrivono le caratteristiche delle TPU che valuti durante la pianificazione e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli sulle versioni disponibili, i tipi di macchina, le topologie valide e il numero di chip, consulta la sezione Mappatura delle configurazioni TPU in questo documento.
Tipo di macchina
I tipi di macchina che supportano le risorse TPU seguono una convenzione di denominazione che include la versione TPU e il numero di chip per nodo, ad esempio ct<version>-hightpu-<node-chip-count>t. Ad esempio, il tipo di macchina ct5lp-hightpu-1t supporta TPU v5e e contiene un chip TPU in totale.
Topologia
La topologia definisce la disposizione fisica delle TPU all'interno di una sezione TPU. GKE esegue il provisioning di una sezione TPU in topologie bi o tridimensionali a seconda della versione TPU. Devi specificare una topologia come numero di chip TPU in ogni dimensione:
Per TPU v4 e v5p pianificate in pool di nodi della sezione TPU multi-host, definisci la topologia in tre tuppi (
{A}x{B}x{C}), ad esempio4x4x4. Il prodotto di{A}x{B}x{C}definisce il numero di chip nel pool di nodi. Ad esempio, puoi definire piccole topologie di dimensioni inferiori a 64 chip con forme di topologia come2x2x2,2x2x4o2x4x4. Se utilizzi topologie superiori a 64 chip, i valori che assegni a {A}, {B} e {C} devono soddisfare le seguenti condizioni:- {A}, {B} e {C} sono multipli di quattro.
- La topologia più grande supportata per la versione 4 è
12x16x16, mentre la versione 5p è16x16x24. - I valori assegnati mantengono il pattern A ≤ B ≤ C. Ad esempio,
4x4x8o8x8x8.
Mappatura della configurazione TPU
Utilizza la seguente tabella per definire il tipo di macchina e la topologia TPU da utilizzare in base al tuo caso d'uso:
- Per l'addestramento o l'inferenza di modelli su scala ridotta, utilizza TPU v4 o TPU v5e con pool di nodi di sezione TPU con singolo host.
- Per l'addestramento o l'inferenza di modelli su larga scala, utilizza TPU v4 o TPU v5e con pool di nodi della sezione TPU multi-host.
| Versione TPU | Tipo di macchina | Topologia | Numero di chip TPU | Numero di VM | Tipo di pool di nodi |
|---|---|---|---|---|---|
| TPU v4 | ct4p-hightpu-4t |
2x2x1 | 4 | 1 | Host singolo |
| 2x2x2 | 8 | 2 | Host multipli | ||
| 2x2x4 | 16 | 4 | Host multipli | ||
| 2x4x4 | 32 | 8 | Host multipli | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Host multipli | ||
| TPU v5p | ct5p-hightpu-4t |
2x2x1 | 4 | 1 | Host singolo |
| 2x2x2 | 8 | 2 | Host multipli | ||
| 2x2x4 | 16 | 4 | Host multipli | ||
| 2x4x4 | 32 | 8 | Host multipli | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Host multipli | ||
| TPU v5e | ct5l-hightpu-1t |
1x1 | 1 | 1 | Host singolo |
ct5l-hightpu-4t |
2x2 | 4 | 1 | Host singolo | |
ct5l-hightpu-8t |
2x4 | 8 | 1 | Host singolo | |
ct5lp-hightpu-1t |
1x1 | 1 | 1 | Host singolo | |
ct5lp-hightpu-4t |
2x2 | 4 | 1 | Host singolo | |
ct5lp-hightpu-8t |
2x4 | 8 | 1 | Host singolo | |
ct5lp-hightpu-4t |
2x4 | 8 | 2 | Host multipli | |
| 4x4 | 16 | 4 | Host multipli | ||
| 4x8 | 32 | 8 | Host multipli | ||
| 8x8 | 64 | 16 | Host multipli | ||
| 8x16 | 128 | 32 | Host multipli | ||
| 16x16 | 256 | 64 | Host multipli |
-
Viene calcolato dividendo il prodotto della topologia per quattro. ↩
Caratteristiche di TPU v5e
Le macchine TPU v5e hanno le seguenti caratteristiche tecniche:
| Tipo di macchina | Numero di vCPU | Memoria (GB) | Numero di NUMA nodi | Probabilità di prerilascio |
|---|---|---|---|---|
ct5l-hightpu-1t |
24 | 48 | 1 | Superiore |
ct5l-hightpu-4t |
112 | 192 | 1 | Medio |
ct5l-hightpu-8t |
224 | 384 | 2 | Meno |
ct5lp-hightpu-1t |
24 | 48 | 1 | Superiore |
ct5lp-hightpu-4t |
112 | 192 | 1 | Medio |
ct5lp-hightpu-8t |
224 | 384 | 1 | Basso |
Caratteristiche di TPU v4 e v5p
Le macchine TPU v4p e v5p hanno le seguenti caratteristiche tecniche:
| Tipo di macchina | Numero di vCPU | Memoria (GB) | Numero di NUMA nodi |
|---|---|---|---|
ct4p-hightpu-4t |
240 | 407 | 2 |
ct5p-hightpu-4t |
208 | 448 | 2 |
Prenotazione TPU
Le prenotazioni TPU sono disponibili quando acquisti un impegno. Qualsiasi prenotazione TPU può essere utilizzata con GKE.
Quando crei un pool di nodi TPU, utilizza i flag --reservation e --reservation-affinity=specific per consumare un'istanza TPU riservata.
TPU con scalabilità automatica in GKE
GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia il pool di nodi della sezione TPU con singolo host sia il pool di nodi della sezione TPU multi-host supportano la scalabilità automatica e il provisioning automatico.
Con il flag --enable-autoprovisioning su un cluster GKE, GKE crea o elimina i pool di nodi delle sezioni TPU con singolo 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 tipo, come segue:
Pool di nodi della sezione TPU host singolo: GKE aggiunge o rimuove nodi TPU nel pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi, come stabilito dai flag --max-nodes e --total-max-nodes. Quando il pool di nodi è scalabile, tutti i nodi TPU nel pool hanno lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare un pool di nodi della sezione TPU con singolo host, consulta Creare un pool di nodi.
Pool di nodi della sezione TPU multi-host: GKE fa lo scale up atomico del pool di nodi da zero al numero di nodi richiesti per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con tipo di macchina
ct5lp-hightpu-4te topologia16x16, il pool di nodi contiene 64 nodi. Il gestore della scalabilità automatica di GKE assicura che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante lo scale down, GKE rimuove 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 della sezione TPU multi-host, consulta Creare un pool di nodi.
Limitazioni
- Per le prenotazioni di capacità, devi utilizzare una prenotazione specifica.
- L'allocazione dei costi e la misurazione dell'utilizzo di GKE non includono dati sull'utilizzo o sui costi della TPU v4 prenotata.
- TPU v5p e v5e non supportano riptide/streaming di immagini in us-east5.
- La scalabilità automatica di TPU v5p è supportata sui cluster GKE con piani di controllo che eseguono almeno 1.29.2-gke.1035000 o almeno 1.28.7-gke.1020000.
Considerazioni sulla pianificazione del carico di lavoro
Le TPU hanno caratteristiche uniche che richiedono una pianificazione e una gestione speciali dei carichi di lavoro in Kubernetes. Le seguenti sezioni descrivono le best practice di pianificazione.
CPU
Questa sezione non si applica ai cluster Autopilot perché GKE posiziona ciascun pod di TPU sul proprio nodo.
Per pianificare un carico di lavoro sulla CPU integrata su una VM TPU, assicurati che il pod GKE possa tollerare l'incompatibilità google.com/tpu. Se vuoi che venga eseguito il deployment del carico di lavoro in nodi specifici, utilizza i selettori di nodi.
La gestione e la priorità delle risorse di Kubernetes trattano le VM TPU come se fossero altri tipi di VM. Per assegnare la priorità ai pod che richiedono le TPU di pianificazione rispetto ad altri pod sugli stessi nodi, richiedi il numero massimo di CPU o memoria per i pod TPU. I pod a bassa priorità devono:
- Imposta richieste di CPU e memoria basse per garantire che il nodo abbia risorse allocabili sufficienti per i carichi di lavoro TPU. Per saperne di più, consulta In che modo Kubernetes applica richieste e limiti di risorse.
- Non impostare un limite di CPU (illimitato) per garantire che i pod possano eseguire il burst per utilizzare tutti i cicli inutilizzati.
- Imposta un limite di memoria elevato per garantire che i pod possano utilizzare la maggior parte della memoria inutilizzata, mantenendo la stabilità dei nodi.
Se un pod Kubernetes non richiede CPU e memoria (anche se richiede TPU), Kubernetes lo considera un pod "best effort" e non c'è alcuna garanzia che abbia bisogno di CPU e memoria. Solo i pod che richiedono esplicitamente CPU e memoria hanno queste garanzie. Per maggiori informazioni, consulta Gestione delle risorse per pod e container.
Per saperne di più, consulta Best practice per Kubernetes: richieste e limiti delle risorse.
Riduci le interruzioni dei carichi di lavoro
Se utilizzi le TPU per addestrare un modello di machine learning e il carico di lavoro viene interrotto, tutto il lavoro eseguito dall'ultimo checkpoint andrà perso. Per ridurre la probabilità che il carico di lavoro venga interrotto:
- Imposta per questo job una priorità più elevata rispetto a tutti gli altri job: se le risorse sono scarse, lo scheduler GKE prerilascia i job a priorità inferiore per pianificare un job con priorità più alta. Ciò garantisce inoltre che il carico di lavoro con priorità più elevata riceva tutte le risorse di cui ha bisogno (fino a quelle totali disponibili nel cluster). Per scoprire di più, consulta Priorità e prerilascio dei pod.
- Configura l'esclusione della manutenzione: un'esclusione dalla manutenzione è un periodo di tempo non ripetuto durante il quale è vietata la manutenzione automatica. Per scoprire di più, consulta Esclusioni dalla manutenzione.
- Usa i pod con tempo di esecuzione esteso in Autopilot: usa i pod con tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima che GKE arresti i tuoi pod per gli scale down o gli upgrade dei nodi.
Gestire l'interruzione dovuta alla manutenzione dei nodi
Tutti i nodi GKE, inclusi quelli che ospitano VM TPU, sono soggetti a eventi di manutenzione o altre interruzioni che potrebbero causare l'arresto dei nodi. Puoi ridurre le interruzioni dei carichi di lavoro in esecuzione nei cluster GKE con il piano di controllo che esegue la versione 1.29.1-gke.1425000 o successive.
GKE avvisa i nodi di un arresto imminente inviando un segnale SIGTERM al nodo fino a cinque minuti prima dell'eliminazione. Se il carico di lavoro utilizza un framework ML come MaxText, Pax o JAX con Orbax, i carichi di lavoro possono acquisire il segnale SIGTERM e avviare un processo di checkpoint.
Configura GKE per terminare i carichi di lavoro ML
con il tempo massimo di notifica. Nel manifest del pod, imposta il campo spec.terminationGracePeriodSeconds su 300 secondi (cinque minuti).
GKE fa il possibile per terminare correttamente questi pod e per eseguire l'azione di terminazione da te definita, ad esempio salvando uno stato di addestramento. GKE rispetta qualsiasi configurazione, fino a un massimo di cinque minuti, per le impostazioni PodDisruptionBudget o terminationGracePeriodSeconds.
Il campo spec.terminationGracePeriodSeconds gestisce solo le interruzioni dovute a eventi di manutenzione e deframmentazione che si verificano sulle VM non prerilasciabili. GKE non gestisce interruzioni involontarie, come guasti hardware.
Per saperne di più, consulta Configurare la terminazione controllata dei nodi TPU.
Massimizza l'utilizzo di TPU
Per massimizzare l'investimento nelle TPU, pianifica una combinazione di priorità dei job e mettile in coda per massimizzare il tempo di funzionamento delle TPU. Se vuoi pianificare e prerilasciare a livello di job, devi utilizzare un componente aggiuntivo di Kubernetes che orchestra i job in code. Ti consigliamo di usare Kueue per quel caso d'uso.
Passaggi successivi
- Segui Eseguire il deployment dei carichi di lavoro TPU in GKE per configurare Cloud TPU con GKE.
- Scopri le best practice per l'utilizzo di Cloud TPU per le tue attività di machine learning.
- Crea machine learning su larga scala sulle Cloud TPU con GKE
- Gestire modelli linguistici di grandi dimensioni (LLM) con KubeRay su TPU