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 (ML) 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 fornisce il supporto completo per la gestione del ciclo di vita dei nodi TPU e del pool di nodi, incluse la creazione, la configurazione e l'eliminazione delle VM TPU. 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: puoi utilizzare un'unica piattaforma 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 così 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, con il numero a seconda del tipo di macchina TPU che scegli.
  • 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, quindi su un nodo:
      • Può eseguire il deployment di un pod GKE che richiede otto chip TPU.
      • Impossibile eseguire il deployment di due pod GKE che richiedono quattro chip TPU ciascuno.
    • 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. Con questo tipo di macchina:
      • Impossibile eseguire il deployment di un pod GKE che richiede otto chip TPU sui nodi in questo pool di nodi.
      • Può eseguire il deployment di due pod che richiedono quattro chip TPU ciascuno, ciascuno su uno dei due nodi in questo 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 una o quattro repliche.
  • Nei cluster Standard, è possibile pianificare più pod Kubernetes ma solo un container in ciascun pod può accedere ai chip TPU.
  • Per creare pod kube-system, come kube-dns, ogni modello il cluster deve avere almeno un pool di nodi con sezione non TPU.
  • Per impostazione predefinita, i nodi delle sezioni TPU hanno lo google.com/tpu incompatibilità che impedisce la pianificazione delle sezioni non TPU sui nodi delle sezioni TPU. I carichi di lavoro che non utilizzano TPU vengono eseguiti su nodi non TPU, liberando computing su nodi della sezione TPU per il codice che utilizza le TPU. Tieni presente che l'incompatibilità per garantire l'utilizzo completo delle risorse 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 TPU: il tipo di macchina, ad esempio ct5l-hightpu-8t. Ogni tipo di TPU ha funzionalità diverse, ad esempio rapporto prezzo-prestazioni, velocità effettiva di addestramento e latenza di pubblicazione. I tipi di TPU influiscono sulle capacità di CPU e memoria disponibili.
  • 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: indica se i nodi hanno interconnessioni ad alta velocità. Il tipo e la topologia di TPU determinano se puoi ottenere nodi sezione TPU multi-host, ovvero TPU in più nodi con interconnessioni ad alta velocità. Ti consigliamo di:

    • 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: sostituisce molte altre impostazioni di sicurezza in securityContext. Per accedere alle TPU, i container in esecuzione nei nodi GKE in:

    • Le versioni 1.28 e precedenti devono abilitare la modalità con privilegi.
    • Le versioni 1.28 o successive non richiedono la modalità con privilegi.

Scegli una configurazione TPU per la modalità GKE Autopilot

In modalità Autopilot, scegli un tipo di TPU e una topologia, quindi specificali 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 TPU nel Documentazione sui prezzi di Cloud TPU per aiutarti a decidere quale tipo di TPU usare.

Scegli una topologia per Autopilot

Dopo aver scelto un tipo di TPU, seleziona una topologia supportata da quel tipo di TPU. In base alla TPU tipo, la topologia è bidimensionale o tridimensionale. Parallelismo del modello aiutano a decidere una topologia. Puoi identificare il numero Chip TPU nella sezione calcolando il prodotto di ogni dimensione nella topologia. Ad esempio:

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

Se una topologia specifica supporta sia l'host singolo o nodi di sezione TPU multi-host, il numero di chip TPU richiesti dal tuo 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 nel carico di lavoro, ottieni un nodo multi-host che ha 4 chip TPU.
  • Richiedi 8 chip nel tuo carico di lavoro, ottieni un singolo host con 8 chip TPU.

La tabella seguente elenca ogni tipo di TPU, le relative topologie supportate e l'utilizzo note. Per ogni di queste topologie, la tabella elenca 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 sezioni seguenti descrivono le caratteristiche delle TPU da considerare 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 per ogni versione di TPU e tipo di macchina:

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. Puoi creare un pool di nodi TPU v5e a host singolo con un tipo di macchina che inizia con ct5lp- ma non inizia con ct5l- in determinate zone (europe-west4-a, us-central1-a, us-east5-b e us-west4-b). Puoi utilizzare ct5lp-hightpu-4t con con una topologia di almeno 2x4 o superiore in quelle zone. 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. Per creare una TPU con host singolo v5e nelle altre regioni elencate in questo paragrafo, utilizza tipi di macchina che iniziano con ct5l- (ad esempio come ct5l-hightpu-1t, ct5l-hightpu-4t o ct5l-hightpu-8t) e scegli la zona us-central1-a o europe-west4-b. Tieni presente che i tipi di macchina che iniziano con ct5l- richiede quota diversa rispetto ai tipi di macchina che iniziano con ct5lp-. ↩

Le sezioni seguenti descrivono le caratteristiche delle TPU da considerare 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 Compute Engine, 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 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 solo 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, a seconda 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 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 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 a 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

Tieni presente queste considerazioni quando pianifichi l'utilizzo delle TPU sulla tua piattaforma:

  • 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 la gestione dei container in Kubernetes. Le seguenti sezioni descrivono la programmazione migliore pratiche.

CPU per cluster standard

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 i cluster Standard, considera la migliore pianificazione riportata di seguito pratiche.

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. a dare priorità alla pianificazione ai pod che richiedono TPU. su altri pod sugli stessi nodi, e richiedere la CPU o la memoria massima per quelle sezioni TPU. Le sezioni TPU a bassa priorità dovrebbero 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 la burst e utilizzare tutte di cicli inutilizzati.
  3. Imposta limiti di memoria appropriati per garantire che i pod possano funzionare correttamente senza rischiare l'eliminazione della pressione dei nodi.

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ù sulle best practice, vedi 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 pod con 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.
di Gemini Advanced.

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