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:
- Scopri come funzionano gli acceleratori di machine learning con Introduzione a Cloud TPU.
- 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:
- 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 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 topologia2x4
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.
- Il tipo di macchina
- 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 v5ptpu-v5p-slice |
208 | 448 | 2 | 6144 |
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 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 chip2x2
è 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 v5ptpu-v5p-slice |
2x2x1 | 4 | 1 | Host singolo | Sono supportate topologie personalizzate per più di 64 chip. Si applicano le seguenti condizioni:
|
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 v5etpu-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 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 | 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 |
-
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-a 1 |
us-central1-a 1 |
||||
us-east1-c |
||||
us-east5-b 1 |
||||
us-west1-c |
||||
us-west4-a |
||||
us-west4-b 1 |
||||
TPU v5p | ct5p- |
1.28.3-gke.1024000 | Generalmente disponibile | us-east1-d |
us-east5-a |
||||
us-east5-c |
-
Quando si crea una TPU v5e con un tipo di macchina che inizia con
ct5lp-
in una qualsiasi delle zoneeurope-west4-a
,us-central1-a
,us-east5-b
ous-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 macchinact5lp-hightpu-4t
con una topologia pari a almeno2x4
o superiore. Per creare una TPU con host singolo v5e inus-central1
oeurope-west4
, scegli zoneus-central1-a
oeurope-west4-b
, e utilizzano tipi di macchina che iniziano conct5l-
come comect5l-hightpu-1t
,ct5l-hightpu-4t
oct5l-hightpu-8t
. Per creare una TPU v5e con host singolo inus-west4
, scegli la zonaus-west4-a
e utilizza tipi di macchine che iniziano conct5lp-
comect5lp-hightpu-1t
. Prendi nota dei tipi di macchina che iniziano conct5l-
richiede quota diversa rispetto ai tipi di macchina che iniziano conct5lp-
. ↩
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 esempio4x4x4
. 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 come2x2x2
,2x2x4
o2x4x4
. 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
o8x8x8
.
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 |
-
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 di16x16
, 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:
- 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.
- Imposta nessun limite di CPU (illimitato) per assicurarti che i pod possano eseguire il burst per utilizzare tutte di cicli inutilizzati.
- 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
- Segui Deployment di carichi di lavoro TPU in GKE per configurare Cloud TPU con GKE.
- Scopri le best practice per l'utilizzo di Cloud TPU per per le attività di machine learning.
- Crea machine learning su larga scala sulle Cloud TPU con GKE
- Gestione di modelli linguistici di grandi dimensioni (LLM) con KubeRay su TPU