Informazioni sulle TPU in GKE

Questa pagina introduce Cloud TPU e ti aiuta a pianificare Configurazione di Cloud TPU con Google Kubernetes Engine (GKE), tra cui prenotazione di istanze TPU, scalabilità automatica, limitazioni di TPU e considerazioni sulla pianificazione dei carichi di lavoro.

Elaborazione del tensore Le TPU (TPU) sono gli strumenti integrati per applicazioni (ASIC) 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 nel seguente percorso di apprendimento:

  1. Scopri come funzionano gli acceleratori di machine learning con Introduzione a Cloud TPU.
  2. Scopri di più sulla disponibilità attuale della versione di TPU con il Architettura di sistema Cloud TPU.

Per scoprire come configurare Cloud TPU in GKE, consulta le seguenti risorse:

Vantaggi dell'utilizzo delle TPU in GKE

GKE offre il supporto completo per la gestione del ciclo di vita dei nodi TPU e dei pool di nodi. GKE supporta anche le VM spot e l'uso di Cloud TPU. La i vantaggi dell'utilizzo delle TPU in GKE includono:

  • Ambiente operativo coerente: una piattaforma unica per tutto il machine learning. e altri carichi di lavoro.
  • Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, riduce i costi operativi.
  • Bilanciamento del carico: GKE distribuisce il carico riducendo la latenza. e il miglioramento dell'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 accodamento dei job nativo di Kubernetes, puoi gestire le risorse a più tenant all'interno dell'organizzazione usando accodamento, prerilascio priorità ed equa condivisione.

Terminologia relativa a TPU in GKE

Questo documento utilizza la seguente terminologia relativa alle TPU:

  • Tipo TPU: il tipo di Cloud TPU, ad esempio v5e.
  • Nodo della sezione TPU:un nodo Kubernetes che contiene un insieme di VM con chip TPU interconnessi.
  • Pool di nodi della sezione TPU:un gruppo di nodi Kubernetes all'interno di un cluster che che hanno la stessa configurazione TPU.
  • Topologia TPU: il numero e la disposizione fisica dei chip TPU in una sezione TPU.
  • Nodi della sezione TPU con host singolo: uno o più nodi della sezione TPU indipendenti. La Le VM in un nodo di sezione TPU con un host singolo non sono connesse tra loro tramite interconnessioni ad alta velocità.
  • Nodi della sezione TPU multi-host: due o più nodi della sezione TPU interconnessi. Le VM in un nodo TPU multi-host sono collegate da interconnessioni ad alta velocità. Multi-host I nodi della sezione TPU hanno le seguenti caratteristiche:
    • Atomico: GKE tratta tutti i nodi interconnessi come un una singola unità. Durante le operazioni di scalabilità, GKE scala l'intero di nodi a 0 e ne crea di nuovi. Se una macchina nel gruppo presenta errori GKE ricrea l'intero set di nodi come nuovo unità.
    • Immutabile: non puoi aggiungere manualmente nuovi nodi al set di nodi interconnessi nodi. Tuttavia, puoi creare un nuovo pool di nodi con la topologia TPU che preferisci e pianificare i carichi di lavoro sul nuovo pool di nodi.

Come funzionano le TPU in GKE

La gestione e la priorità delle risorse di Kubernetes tratta le VM sulle TPU come le altre VM di testo. Richiedi 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 GKE, devi considerare le seguenti caratteristiche di TPU:

  • Una VM può accedere a un massimo di 8 chip TPU.
  • Una sezione TPU contiene un numero fisso di chip TPU che dipende dalla TPU del tipo di macchina scelto.
  • Il numero di richieste google.com/tpu deve essere uguale al numero totale di chip TPU disponibili sul nodo della sezione TPU. Qualsiasi container in un pod GKE che richiede le TPU, deve consumare all dai chip TPU nel nodo. In caso contrario, il deployment non va a buon fine, GKE non può consumare parzialmente le risorse TPU. Ad esempio, vedi i seguenti scenari:
    • Il tipo di macchina ct5l-hightpu-8t ha un singolo nodo della sezione TPU con 8 chip TPU. È possibile eseguire il deployment di un pod GKE che richiede otto chip TPU ma due pod GKE che richiedono quattro chip TPU non possono essere sottoposti a deployment su un nodo.
    • Il tipo di macchina ct5lp-hightpu-4t con una topologia 2x4 contiene due Nodi della sezione TPU con quattro chip TPU ciascuno, per un totale di otto chip TPU. un pod GKE richiede che il deployment di otto chip TPU non possa essere eseguito in nessuno dei nodi ma è possibile eseguire il deployment di due pod che richiedono quattro chip TPU ciascuno tra i due nodi nel pool di nodi.
    • TPU v5e con topologia 4x4 ha 16 chip TPU in quattro nodi. Lo strumento GKE Il carico di lavoro Autopilot che seleziona questa configurazione deve richiederne quattro Chip TPU in ogni replica, per un massimo di quattro repliche.
  • Nei cluster Standard, è possibile pianificare 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 con sezione non TPU per per creare pod kube-system, ad esempio kube-dns.
  • Per impostazione predefinita, i nodi delle sezioni TPU hanno lo google.com/tpu incompatibilità che impedisce la pianificazione delle sezioni non TPU. L'incompatibilità non per garantire l'utilizzo completo delle risorse TPU. Ti permette di eseguire carichi di lavoro Non utilizzano TPU sui nodi delle sezioni non TPU, liberando risorse di calcolo sui nodi delle sezioni TPU per il codice. che utilizza le TPU.
  • GKE raccoglie i log emessi dai container in esecuzione sui nodi delle sezioni TPU. Per saperne di più, vedi Logging.
  • Le metriche di utilizzo delle TPU, ad esempio le prestazioni di runtime, sono disponibili in e configurazione in Cloud Monitoring. Per saperne di più, vedi Osservabilità e metriche.

Pianifica la configurazione di TPU

Per utilizzare le TPU nei cluster GKE, devi decidere seguenti parametri:

  • Tipo di TPU: i vari tipi di TPU hanno funzionalità diverse, ad esempio rapporto prezzo-prestazioni, velocità effettiva di addestramento e latenza di pubblicazione. e le capacità di memoria variano in base al tipo di macchina utilizzata.
  • Topologia: la disposizione fisica delle TPU all'interno di una sezione TPU. Ogni tipo di TPU supporta Topologia TPU 2D o 3D. Seleziona una topologia corrispondente ai requisiti di parallelismo del modello.

  • Interconnessione TPU: il tipo e la topologia di TPU determinano se le TPU si trovano in più nodi con interconnessioni ad alta velocità. Questo determina se vuoi nodi con sezione TPU a host singolo o multi-host.

    • Per i modelli su larga scala, utilizza nodi delle sezioni TPU multi-host
    • Per i modelli su scala ridotta, utilizza nodi sezione TPU con host singolo

  • Modalità con privilegi: i container in esecuzione nei nodi GKE versione 1.28 e precedenti devono abilitare la modalità con privilegi. Per le versioni 1.28 o successive non è necessario attivare la modalità con privilegi per accedere alle TPU.

Scegli una configurazione TPU per la modalità GKE Autopilot

In Autopilot, scegli un tipo di TPU e una topologia e li specifichi in del tuo manifest di Kubernetes. GKE gestisce i nodi di provisioning TPU e pianificazione dei carichi di lavoro.

Disponibilità di TPU in GKE Autopilot

Le TPU sono disponibili in regioni specifiche di Google Cloud. Per utilizzare un tipo di TPU del 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 nodi NUMA Numero massimo di chip TPU in una sezione
TPU v5p
tpu-v5p-slice		 208 448 2 6144
TPU v5e
tpu-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 v4
tpu-v4-podslice		 240 407 2 4096

Esamina le specifiche e i prezzi del chip nel Documentazione di Cloud TPU per aiutarti a decidere quale versione utilizzare.

Scegli una topologia per Autopilot

La topologia è il layout fisico dei chip in una sezione TPU. In base alla TPU tipo, la topologia è bidimensionale o tridimensionale. Dopo aver scelto un tipo di TPU, seleziona una topologia supportata da quel tipo di TPU. Parallelismo del modello aiutano a decidere una topologia. Il prodotto delle dimensioni di ogni in una topologia è il numero di chip TPU nella sezione. Ad esempio:

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

La topologia selezionata per un tipo di TPU determina se si ottiene o nodi di sezioni TPU multi-host. Se una topologia specifica supporta sia l'host singolo e le sezioni multi-host, il numero di chip TPU richiesti dal carico di lavoro determina il tipo di host che ottieni. Ad esempio, TPU v5e (tpu-v5-lite-podslice) supporta la topologia 2x4 sia come single che con multi-host. Se richiedi 4 chip TPU nel carico di lavoro, ottieni un nodo multi-host che ha 4 chip TPU. Se richiedi 8 chip TPU nel tuo carico di lavoro, ottieni un host singolo con 8 chip TPU.

La tabella seguente descrive le topologie supportate in ogni tipo di TPU e numero di chip TPU, 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
tpu-v5p-slice		 2x2x1 4 1 Host singolo

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

  • Per più di 64 chip, {A}, {B} e {C} deve essere multipli di 4
  • La topologia più grande è 16x16x24
  • I valori devono essere {A}≤{B}≤{C}, come 8x12x16.
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
4x4x4 64 16 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
TPU v5e
tpu-v5-lite-podslice		 1x1 1 1 Host singolo Le topologie personalizzate non sono supportate.
2x2 4 1
2x4 8 1
2x4 2 1 Multi-host
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 v4
tpu-v4-podslice		 2x2x1 4 1 Host singolo

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

  • Per più di 64 chip, {A}, {B} e {C} deve essere multipli di 4
  • La topologia più grande è 12x16x16
  • I valori devono essere {A}≤{B}≤{C}, come 8x12x16.
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
4x4x4 64 16 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host

  1. Viene calcolato in base al prodotto di topologia diviso per quattro. ↩

Dopo aver scelto un tipo e una topologia TPU, specificali nel carico di lavoro del file manifest. Per istruzioni, vedi Esegui 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 di TPU che valuti quando e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli sulle versioni disponibili, sui tipi di macchina, sulle topologie valide e sul loro numero di CPU, fai riferimento alla sezione Mappatura delle configurazioni TPU in questo documento.

Disponibilità di TPU in modalità GKE Standard

La tabella seguente elenca la disponibilità di TPU in base al tipo di macchina e versione:

Versione TPU Tipo di macchina che inizia con Versione GKE minima 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 Generalmente disponibile us-east1-d
us-east5-a
us-east5-c

  1. Quando si crea una TPU v5e con un tipo di macchina che inizia con ct5lp- in una qualsiasi delle zone europe-west4-a, us-central1-a, us-east5-b o us-west4-b, i pool di nodi TPU v5e con host singolo non sono supportati. In altre parole, quando crei un pool di nodi TPU v5e in una di queste zone, solo il tipo di macchina ct5lp-hightpu-4t con una topologia pari a almeno 2x4 o superiore. Per creare una TPU con host singolo v5e in us-central1 o europe-west4, scegli zone us-central1-a o europe-west4-b, e utilizzano tipi di macchina che iniziano con ct5l- come come ct5l-hightpu-1t, ct5l-hightpu-4t o ct5l-hightpu-8t. Per creare una TPU v5e con host singolo in us-west4, scegli la zona us-west4-a e utilizza tipi di macchine che iniziano con ct5lp- come ct5lp-hightpu-1t. Prendi nota dei tipi di macchina che iniziano con ct5l- richiede quota diversa rispetto ai tipi di macchina che iniziano con ct5lp-. ↩

Le seguenti sezioni descrivono le caratteristiche di TPU che valuti quando e la configurazione dei carichi di lavoro TPU in GKE. Per maggiori dettagli sulle versioni disponibili, sui tipi di macchina, sulle topologie valide e sul loro numero di CPU, fai riferimento alla 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 di TPU e il numero di chip TPU per nodo, come ct<version>-hightpu-<node-chip-count>t. Ad esempio, la macchina il tipo ct5lp-hightpu-1t supporta TPU v5e e contiene in totale un chip TPU.

Topologia

La topologia definisce la disposizione fisica delle TPU all'interno di una sezione TPU. GKE esegue il provisioning di una sezione TPU topologie bidimensionali o tridimensionali in base a la versione di TPU. Specifica una topologia come il numero di chip TPU in ogni dimensione:

  • Per TPU v4 e v5p pianificati nei pool di nodi delle sezioni TPU multi-host, devi definire a tre tuple ({A}x{B}x{C}), ad esempio 4x4x4. Il prodotto di {A}x{B}x{C} definisce il numero di chip TPU nel pool di nodi. Ad esempio, puoi definiscono topologie piccole più piccole di 64 chip TPU con forme di topologia come 2x2x2, 2x2x4 o 2x4x4. Se utilizzi topologie più grandi di 64 chip TPU, I valori assegnati 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 topologia v5p è 16x16x24.
    • I valori assegnati mantengono A ≤ B ≤ C pattern. Ad esempio, 4x4x8 o 8x8x8.

Mappatura della configurazione TPU

Utilizza la tabella seguente per definire il tipo di macchina TPU e la topologia 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 host singolo.
  • Per l'addestramento o l'inferenza di modelli su larga scala, utilizza TPU v4 o TPU v5e con multi-host Pool di nodi della sezione TPU.
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 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
TPU v5p ct5p-hightpu-4t 2x2x1 4 1 Host singolo
2x2x2 8 2 Multi-host
2x2x4 16 4 Multi-host
2x4x4 32 8 Multi-host
{A}x{B}x{C} A*B*C (A*B*C/4)1 Multi-host
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 Multi-host
4x4 16 4 Multi-host
4x8 32 8 Multi-host
8x8 64 16 Multi-host
8x16 128 32 Multi-host
16x16 256 64 Multi-host

  1. Viene calcolato in base al prodotto di topologia diviso 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 Bassa

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 TPU può essere utilizzata con GKE.

Quando crei un pool di nodi della sezione TPU, utilizza il metodo --reservation e --reservation-affinity=specific di flag per utilizzare un modello di Cloud Shell.

Scalabilità automatica delle TPU in GKE

GKE supporta le TPU (Tensor Processing Unit) per accelerare i carichi di lavoro di machine learning. Sia pool di nodi della sezione TPU con host singolo sia Il pool di nodi della sezione TPU multi-host supporta la scalabilità automatica e il provisioning automatico.

Con --enable-autoprovisioning su un cluster GKE, GKE crea o elimina i pool di nodi delle sezioni TPU a host singolo o multi-host con una TPU la versione e la topologia 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 con host singolo: GKE aggiunge o rimuove i nodi TPU nella pool di nodi esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU tra zero e la dimensione massima del pool di nodi come determinato dalla --max-nodes e il --total-max-nodes e i flag facoltativi. Quando il pool di nodi viene scalato, tutti i nodi TPU nel pool ricevono lo stesso tipo di macchina e la stessa topologia. Per scoprire di più su come creare una TPU con host singolo una sezione del pool di nodi, consulta Creare un nodo pool.

  • Pool di nodi della sezione TPU multi-host: GKE fa lo scale up atomico del pool di nodi da zero al numero di nodi necessario per soddisfare la topologia TPU. Per esempio, con un pool di nodi TPU con un tipo di macchina ct5lp-hightpu-4t e di 16x16, il pool di nodi contiene 64 nodi. Lo strumento GKE il gestore della scalabilità automatica garantisce che questo pool di nodi abbia esattamente 0 o 64 nodi. Durante la scalabilità di nuovo, GKE rimuove tutti i pod pianificati e svuota l'intera pool di nodi a zero. Per scoprire di più su come creare un nodo della sezione TPU multi-host consulta Creare un pool di nodi.

Limitazioni

  • Per le prenotazioni di capacità, devi utilizzare una prenotazione specifica.
  • Allocazione e utilizzo dei costi di GKE Il monitoraggio non include i dati sull'utilizzo o sui costi della TPU v4 prenotata.
  • TPU v5p e v5e non supportano lo streaming di riptide/immagine in us-east5.
  • La scalabilità automatica v5p TPU è supportata sui cluster GKE con piani di controllo in esecuzione 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 dei carichi di lavoro e e la gestione dei container in Kubernetes. Le seguenti sezioni descrivono la programmazione migliore pratiche.

CPU

Questa sezione non si applica ai cluster Autopilot perché GKE posiziona ciascuna sezione TPU sul proprio nodo. Per scoprire di più, consulta Come funzionano le TPU in modalità Autopilot

Per pianificare un carico di lavoro non TPU su una VM in un nodo di sezione TPU, assicurati che Il pod GKE può tollerare l'incompatibilità di google.com/tpu. Se desideri del carico di lavoro in nodi specifici, usa selettori di nodi.

La gestione e la priorità delle risorse di Kubernetes tratta le VM nelle TPU come le altre VM di testo. Per assegnare la priorità ai pod che richiedono la pianificazione delle TPU rispetto ad altri pod sugli stessi nodi, e richiedere la CPU o la memoria massima per quelle sezioni TPU. Le sezioni TPU a bassa priorità devono eseguire seguenti:

  1. Imposta richieste di CPU e memoria basse per garantire che il nodo abbia abbastanza alle risorse allocabili per i carichi di lavoro TPU. Per saperne di più, vedi In che modo Kubernetes applica richieste e limiti delle risorse.
  2. Imposta nessun limite di CPU (illimitato) per assicurarti che i pod possano eseguire il burst per utilizzare tutte di cicli inutilizzati.
  3. Imposta un limite di memoria elevato per garantire che i pod possano utilizzare la maggior parte della memoria inutilizzata mantenendo la stabilità del nodo.

Se un pod Kubernetes non richiede CPU e memoria (anche se richiede TPU), Kubernetes lo considera un pod "best effort" e non garantisce che fossero necessarie CPU e memoria. Solo i pod che eseguono esplicitamente per le richieste di CPU e memoria hanno tali garanzie. Per ulteriori informazioni, vedi Gestione delle risorse per pod e container.

Per saperne di più, consulta Best practice di 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 tuo carico di lavoro è interrotto, tutto il lavoro eseguito dall'ultimo checkpoint andrà perso. Per diminuire la probabilità che il carico di lavoro venga interrotto:

  • Imposta una priorità più alta per questo job rispetto a tutti gli altri job: se le risorse sono scarse, lo scheduler GKE prerilascia i job con priorità più bassa per pianificare un job con priorità più alta. In questo modo, viene garantito anche che il carico di lavoro prioritario riceve tutte le risorse di cui ha bisogno (fino al di risorse disponibili nel cluster). Per saperne di più, vedi Priorità e prerilascio dei pod.
  • Configura l'esclusione della manutenzione: un'esclusione della manutenzione non è ripetuta periodo di tempo durante il quale è vietata la manutenzione automatica. Per saperne di più, consulta la sezione Esclusioni di manutenzione.
  • Usa i pod a tempo di esecuzione esteso in Autopilot: usa pod a tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima della terminazione di GKE per gli scale down o gli upgrade dei nodi.

Gestisci l'interruzione dovuta alla manutenzione del nodo

Tutti i nodi GKE, inclusi quelli che contengono TPU, sono soggetti alle eventi di manutenzione o altre interruzioni che potrebbero causare l'arresto del nodo. Puoi Ridurre le interruzioni dei carichi di lavoro in esecuzione nei cluster GKE con il piano di controllo con la versione 1.29.1-gke.1425000 o successiva. GKE avvisa i nodi di un arresto imminente inviando SIGTERM segnala 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 l'indicatore SIGTERM e avviare un processo di checkpoint.

Puoi configurare GKE per terminare i tuoi carichi di lavoro ML con il tempo massimo di notifica. Nel manifest del pod, imposta spec.terminationGracePeriodSeconds su 300 secondi (cinque minuti). GKE fa il possibile per terminare questi pod in modo controllato eseguire l'azione di chiusura da te definita, ad esempio, salvando un lo stato dell'addestramento. GKE rispetta qualsiasi configurazione fino a cinque minuti Impostazioni di PodDisruptionBudget o terminationGracePeriodSeconds.

Il campo spec.terminationGracePeriodSeconds gestisce solo a causa di eventi di manutenzione e deframmentazione che si verificano sulle non prerilasciabili. GKE non gestisce la gestione ad esempio guasti hardware.

Per saperne di più, vedi Configura la terminazione controllata del nodo della sezione TPU.

Massimizza l'utilizzo della TPU

Per massimizzare l'investimento nelle TPU, pianifica un mix di priorità e coda del job per massimizzare il tempo di funzionamento delle TPU. Se vuoi il job la pianificazione e il prerilascio a livello, devi usare un componente aggiuntivo che orchestra i job in code. È consigliabile utilizzare Kueue per quel caso d'uso.

Passaggi successivi