Informazioni sulle TPU in GKE

Questo documento descrive come funziona Cloud TPU con Google Kubernetes Engine (GKE), tra cui la terminologia, i vantaggi delle Tensor Processing Unit (TPU) e le considerazioni sulla pianificazione dei workload. Le TPU sono circuiti integrati specifici per applicazioni (ASIC) sviluppati da Google per accelerare i workload di ML che utilizzano framework come TensorFlow, PyTorch e JAX.

Questo documento è rivolto agli amministratori e agli operatori della piattaforma e agli specialisti di dati e AI che eseguono modelli di machine learning (ML) con caratteristiche quali l'esecuzione su larga scala, l'esecuzione prolungata o la dominanza di calcoli di matrici. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questo documento, assicurati di avere familiarità con il funzionamento degli acceleratori ML. Per maggiori dettagli, consulta Introduzione a Cloud TPU.

Vantaggi dell'utilizzo delle TPU in GKE

GKE fornisce il supporto completo per la gestione del ciclo di vita dei nodi e dei pool di nodi TPU, inclusa la creazione, la configurazione e l'eliminazione delle VM TPU. GKE supporta anche le VM spot e l'utilizzo di Cloud TPU prenotate. Per saperne di più, consulta Opzioni di consumo di Cloud TPU.

I vantaggi dell'utilizzo delle TPU in GKE includono:

  • Ambiente operativo coerente: puoi utilizzare una singola piattaforma per tutti i workload di machine learning e di altro tipo.
  • Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, riducendo l'overhead operativo.
  • Bilanciamento del carico: GKE distribuisce il carico, riducendo così la latenza e migliorando l'affidabilità.
  • Scalabilità automatica reattiva: GKE scala automaticamente le risorse TPU per soddisfare le esigenze dei tuoi workload.
  • Gestione delle risorse: con Kueue, un sistema di accodamento dei job nativo di Kubernetes, puoi gestire le risorse tra più tenant all'interno della tua organizzazione utilizzando l'accodamento, il prerilascio, la definizione delle priorità e la condivisione equa.
  • Opzioni di sandboxing: GKE Sandbox aiuta a proteggere i workload con gVisor. Per saperne di più, consulta GKE Sandbox.

Inizia a utilizzare Ironwood (TPU7x)

Ironwood (TPU7x) è la TPU di settima generazione di Google, progettata per workload AI su larga scala. Per saperne di più sui vantaggi di Ironwood (TPU7x), consulta Informazioni su Ironwood (TPU7x) in GKE.

Terminologia relativa alle TPU in GKE

Questo documento utilizza la seguente terminologia relativa alle TPU:

  • Resilienza ICI di Cloud TPU: una funzionalità che contribuisce a migliorare la tolleranza di errore dei link ottici e degli switch di circuiti ottici (OCS) che connettono le TPU tra i cubi. Per maggiori informazioni, consulta Architettura TPU.
  • Cubo TPU: una topologia 4x4x4 di chip TPU interconnessi. Questo vale solo per le topologie in 3-tuple ({A}x{B}x{C}).
  • Tipo di TPU: il tipo di Cloud TPU, ad esempio v5e.
  • Sezione TPU: una raccolta di chip che si trovano tutti all'interno dello stesso pod di TPU, collegati da interconnessioni inter-chip (ICI) ad alta velocità. Le sezioni sono descritte in termini di chip o TensorCore, a seconda della versione della TPU.
  • Nodo di sezione TPU: un nodo Kubernetes rappresentato da una singola VM con uno o più chip TPU interconnessi.
  • Pool di nodi di sezioni TPU: un gruppo di nodi Kubernetes all'interno di un cluster che condividono la stessa configurazione TPU.
  • Topologia TPU: il numero e la disposizione fisica dei chip TPU in una sezione TPU.
  • Atomico: GKE tratta tutti i nodi interconnessi come un'unica unità. Durante le operazioni di scalabilità, GKE scala l'intero insieme di nodi a 0 e crea nuovi nodi. Se una macchina del gruppo smette di funzionare o viene terminata, GKE ricrea l'intero set di nodi come nuova unità.
  • Immutabile: non puoi aggiungere manualmente nuovi nodi all'insieme di nodi interconnessi. Tuttavia, puoi creare un nuovo pool di nodi con la topologia TPU che preferisci e pianificare i workload sul nuovo pool di nodi.

Tipi di pool di nodi di sezioni TPU

GKE supporta due tipi di pool di nodi TPU:

Il tipo e la topologia della TPU determinano se il nodo della sezione TPU può essere multi-host o single-host. Ti consigliamo di:

  • Per i modelli su larga scala, utilizza i nodi di sezioni TPU multi-host.
  • Per i modelli su scala ridotta, utilizza i nodi di sezioni TPU a host singolo.
  • Per l'addestramento su larga scala, utilizza Pathways. Pathways semplifica i calcoli di machine learning su larga scala consentendo a un singolo client JAX di orchestrare i workload su più sezioni TPU di grandi dimensioni. Per saperne di più, consulta Pathways.

Node pool di sezioni TPU multi-host

Un pool di nodi di sezioni TPU multi-host è un pool di nodi che contiene due o più VM TPU interconnesse. A ogni VM è connesso un dispositivo TPU. Le TPU in una sezione TPU multi-host sono connesse tramite un'interconnessione ad alta velocità (ICI). Dopo aver creato un pool di nodi di sezioni TPU multi-host, non puoi aggiungervi nodi. Ad esempio, non puoi creare un pool di nodi v4-32 e poi aggiungere un nodo Kubernetes (VM TPU) al pool di nodi. Per aggiungere una sezione TPU a un cluster GKE, devi creare un nuovo pool di nodi.

Le VM in un pool di nodi di sezioni TPU multi-host vengono trattate come un'unica unità atomica. Se GKE non è in grado di eseguire il deployment di un nodo nella sezione, non viene eseguito il deployment di nessun nodo nel nodo della sezione TPU.

Se un nodo all'interno di una sezione TPU multi-host deve essere riparato, GKE arresta tutte le VM nella sezione TPU, forzando l'espulsione di tutti i pod Kubernetes nel workload. Dopo che tutte le VM nella sezione TPU sono attive e funzionanti, i pod Kubernetes possono essere pianificati sulle VM nella nuova sezione TPU.

Il seguente diagramma mostra una sezione TPU multi-host v5litepod-16 (v5e). Questa sezione TPU ha quattro VM. Ogni VM nella sezione TPU ha quattro chip TPU v5e connessi con interconnessioni ad alta velocità (ICI) e ogni chip TPU v5e ha un TensorCore:

Diagramma di una sezione TPU multi-host

Il seguente diagramma mostra un cluster GKE che contiene una sezione TPU v5litepod-16 (v5e) (topologia: 4x4) e una sezione TPU v5litepod-8 (v5e) (topologia: 2x4):

Diagramma del pod TPU v5e

Pool di nodi di sezioni TPU single-host

Un pool di nodi di sezione a host singolo è un pool di nodi che contiene una o più VM TPU indipendenti. A ogni VM è connesso un dispositivo TPU. Sebbene le VM all'interno di un pool di nodi single-host possano comunicare tramite la rete del data center (DCN), le TPU collegate alle VM non sono interconnesse.

Il seguente diagramma mostra un esempio di una sezione TPU single-host contenente sette macchine v4-8:

Diagramma del pool di nodi di slice single-host

Caratteristiche delle TPU in GKE

Le TPU hanno caratteristiche uniche che richiedono una pianificazione e una configurazione speciali.

Consumo di TPU

Per ottimizzare l'utilizzo delle risorse e i costi, bilanciando al contempo le prestazioni dei workload, GKE supporta le seguenti opzioni di consumo delle TPU:

  • Flex-start: per eseguire il provisioning delle VM Flex-start per un massimo di sette giorni, con GKE che alloca automaticamente l'hardware secondo il criterio del "best effort" in base alla disponibilità. Per saperne di più, consulta Informazioni sul provisioning di GPU, TPU e H4D con la modalità di provisioning con avvio flessibile.
  • VM spot: per eseguire il provisioning di VM spot, puoi ottenere sconti significativi, ma le VM spot possono essere prerilasciate in qualsiasi momento, con un preavviso di 30 secondi. Per saperne di più, consulta VM spot.
  • Prenotazione futura per un massimo di 90 giorni (in modalità calendario): per eseguire il provisioning delle risorse TPU per un massimo di 90 giorni, per un periodo di tempo specificato. Per saperne di più, consulta Richiedi TPU con prenotazione futura in modalità calendario.
  • Prenotazioni di TPU: per richiedere una prenotazione futura per un anno o più.
  • On demand: per utilizzare le TPU senza organizzare la capacità in anticipo. Prima di richiedere le risorse, devi disporre di una quota on demand sufficiente per il tipo e la quantità specifici di VM TPU. On demand è l'opzione di consumo più flessibile, ma non è garantito che siano disponibili risorse on demand sufficienti per soddisfare la tua richiesta.

On demand è il modello di consumo predefinito per le TPU in GKE se non specifichi un'altra opzione. Per scegliere l'opzione di consumo che soddisfa i requisiti del tuo workload, consulta Informazioni sulle opzioni di consumo degli acceleratori per i workload AI/ML in GKE.

Prima di utilizzare le TPU in GKE, scegli l'opzione di consumo più adatta ai requisiti del tuo workload.

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 bidimensionali o tridimensionali, a seconda della versione della TPU. Specifica una topologia come numero di chip TPU in ogni dimensione, come segue:

Per TPU v4, v5p e Ironwood (TPU7x) pianificati in pool di nodi di sezioni TPU multi-host, definisci la topologia in tuple di 3 ({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 definire topologie di piccole dimensioni con meno di 64 chip TPU con forme di topologia come 2x2x2, 2x2x4 o 2x4x4. Se utilizzi topologie più grandi con più di 64 chip TPU, i valori che assegni ad {A}, {B} e {C} devono soddisfare le seguenti condizioni:

  • {A}, {B} e {C} devono essere multipli di quattro.
  • La topologia più grande supportata per v4 è 12x16x16 e per v5p è 16x16x24.
  • I valori assegnati devono mantenere il pattern A ≤ B ≤ C. Ad esempio: 4x4x8 o 8x8x8.

Denominazione dei tipi di macchina

La denominazione del tipo di macchina per le TPU in GKE varia a seconda della modalità del cluster e della versione della TPU:

  • GKE Standard: seleziona un tipo di macchina Compute Engine specifico, ad esempio ct6e-standard-1t per TPU Trillium (v6e).

  • GKE Autopilot: non selezioni direttamente i tipi di macchina. Devi invece richiedere le TPU utilizzando un tipo di acceleratore nel manifest del workload. Ad esempio, utilizza tpu-v6e-slice per TPU Trillium (v6e) o tpu-v5-lite-podslice per TPU v5e. GKE Autopilot esegue quindi il provisioning dei nodi sottostanti con i tipi di macchine appropriati per soddisfare la richiesta.

Per i tipi di macchine esatti disponibili per ogni versione di TPU, consulta le tabelle in Pianifica le TPU in GKE.

Modalità con privilegi

Se utilizzi versioni di GKE precedenti alla 1.28, devi configurare i container con funzionalità speciali per accedere alle TPU. Nei cluster in modalità Standard, puoi utilizzare la modalità con privilegi per concedere questo accesso. La modalità con privilegi esegue l'override di molte altre impostazioni di sicurezza in securityContext. Per maggiori dettagli, consulta Esegui i container senza la modalità con privilegi.

Le versioni 1.28 e successive non richiedono la modalità con privilegi o funzionalità speciali.

Come funzionano le TPU in GKE

La gestione e la definizione delle priorità delle risorse Kubernetes trattano le VM su TPU allo stesso modo degli altri tipi di VM. Per richiedere i chip TPU, utilizza il nome della risorsa google.com/tpu:

resources:
  requests:
    google.com/tpu: 4
  limits:
    google.com/tpu: 4

Quando utilizzi le TPU in GKE, tieni presente le seguenti caratteristiche delle TPU:

  • Una VM 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/tpu richiesti deve essere uguale al numero totale di chip TPU disponibili sul nodo della sezione TPU. Qualsiasi container in un pod GKE che richiede TPU deve utilizzare tutti i chip TPU nel nodo. In caso contrario, il deployment non va a buon fine perché GKE non può utilizzare parzialmente le risorse TPU. Considera i seguenti scenari:
    • Il tipo di macchina ct5lp-hightpu-4t con una topologia 2x4 contiene due nodi di sezioni 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, ogni pod su uno dei due nodi in questo pool di nodi.
    • TPU v5e con topologia 4x4 ha 16 chip TPU in quattro nodi. Il workload GKE Autopilot che seleziona questa configurazione deve richiedere quattro chip TPU in ogni replica, per una o quattro repliche.
  • Nei cluster Standard, è possibile pianificare più pod Kubernetes su una VM, ma solo un container in ogni pod può accedere ai chip TPU.
  • Per creare pod kube-system, come kube-dns, ogni cluster Standard deve avere almeno un pool di nodi di sezioni non TPU.
  • Per impostazione predefinita, i nodi di una sezione TPU hanno la taint google.com/tpu, che impedisce la pianificazione di workload non TPU sui nodi della sezione TPU. I workload che non utilizzano le TPU vengono eseguiti su nodi non TPU, liberando risorse di computing sui nodi delle sezioni TPU per il codice che utilizza le TPU. Tieni presente che la taint non garantisce che le risorse TPU vengano utilizzate completamente.
  • GKE raccoglie i log emessi dai container in esecuzione sui nodi di sezioni TPU. Per saperne di più, consulta Logging.
  • Le metriche di utilizzo della TPU, ad esempio le prestazioni di runtime, sono disponibili in Cloud Monitoring. Per saperne di più, consulta Osservabilità e metriche.
  • Puoi eseguire il sandboxing dei tuoi workload TPU con GKE Sandbox. GKE Sandbox funziona con i modelli TPU v4 e versioni successive. Per saperne di più, consulta GKE Sandbox.

Creazione automatica dei node pool con TPU

La creazione automatica dei pool di nodi supporta le seguenti Cloud TPU solo in versioni GKE specifiche:

  • TPU v3: 1.31.0 e versioni successive.
  • TPU v5 e TPU v4: 1.29.0 e versioni successive.
  • TPU Trillium: 1.32.0 e versioni successive.
  • Ironwood (TPU7x): 1.34.1-gke.2541000 o versioni successive.

Altri tipi di Cloud TPU sono supportati in tutte le versioni di GKE. Per scoprire di più sulle versioni GKE disponibili per le TPU, consulta Convalida la disponibilità delle TPU in GKE.

Scalabilità automatica del pool di nodi Cloud TPU

GKE scala i pool di nodi Cloud TPU creati automaticamente o manualmente che utilizzano il gestore della scalabilità automatica dei cluster in uno dei seguenti modi:

  • Node pool di sezioni TPU single-host: GKE aggiunge o rimuove nodi TPU nel pool di nodi esistente. Il pool di nodi potrebbe contenere un numero qualsiasi di nodi TPU compreso tra zero e la dimensione massima del pool di nodi, come determinato dai flag di scalabilità automatica --max-nodes e --total-max-nodes. Tutti i nodi TPU nel pool di nodi hanno lo stesso tipo di macchina e la stessa topologia. Per saperne di più su come creare un pool di nodi di sezioni TPU single-host, consulta Crea un node pool di sezioni TPU single-host.
  • Node pool di sezioni TPU multi-host: GKE esegue lo scale up atomico del pool di nodi da zero al numero di nodi richiesto per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con il tipo di macchina ct5lp-hightpu-4t e una topologia 16x16, il pool di nodi ha sempre 64 nodi o zero nodi. GKE riduce il pool di nodi se non sono presenti workload TPU nel pool di nodi. Per fare lo scale down del pool di nodi, GKE rimuove tutti i pod pianificati e tutti i nodi nel pool di nodi. Per saperne di più su come creare un pool di nodi di sezioni TPU multi-host, consulta Crea un node pool di sezioni TPU multi-host.

Pianificazione della raccolta

La pianificazione della raccolta è supportata solo per TPU Trillium.

In TPU Trillium, puoi utilizzare la pianificazione delle raccolte per raggruppare i nodi di sezioni TPU. Il raggruppamento di questi nodi di sezioni TPU semplifica la regolazione del numero di repliche per soddisfare la domanda del workload. Google Cloud controlla gli aggiornamenti software per garantire che siano sempre disponibili sezioni sufficienti all'interno della raccolta per gestire il traffico.

TPU Trillium supporta la pianificazione della raccolta per i node pool single-host e multi-host che eseguono workload di inferenza. Di seguito viene descritto come il comportamento di pianificazione della raccolta dipende dal tipo di sezione TPU che utilizzi:

  • Slice TPU multi-host: GKE raggruppa le slice TPU multi-host per formare una raccolta. Ogni pool di nodi GKE è una replica all'interno di questa raccolta. Per definire una raccolta, crea una sezione TPU multi-host e assegna un nome univoco alla raccolta. Per aggiungere altre sezioni TPU alla raccolta, crea un altro pool di nodi di sezioni TPU multi-host con lo stesso nome della raccolta e lo stesso tipo di workload.
  • Sezione TPU single-host: GKE considera l'intero pool di nodi della sezione TPU single-host come una raccolta. Per aggiungere altre sezioni TPU alla raccolta, puoi ridimensionare il pool di nodi di sezioni TPU single-host.

La pianificazione della raccolta presenta le seguenti limitazioni:

  • Puoi pianificare le raccolte solo per TPU Trillium.
  • Puoi definire le raccolte solo durante la creazione del pool di nodi.
  • Le VM spot non sono supportate.
  • Le raccolte che contengono pool di nodi di sezioni TPU multi-host devono utilizzare lo stesso tipo di macchina, la stessa topologia e la stessa versione per tutti i pool di nodi all'interno della raccolta.

Puoi configurare la pianificazione della raccolta nei seguenti scenari:

Passaggi successivi

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