Informazioni sulle TPU in GKE

Questo documento descrive il funzionamento di Cloud TPU con Google Kubernetes Engine (GKE), inclusa la terminologia, i vantaggi delle TPU (Tensor Processing Unit) e le considerazioni sulla pianificazione dei carichi di lavoro. Le TPU sono circuiti integrati specifici per le applicazioni (ASIC), sviluppati da Google, e utilizzati per accelerare i carichi di lavoro di machine learning che utilizzano framework come TensorFlow, PyTorch e JAX.

Questo documento è destinato agli amministratori e agli operatori di piattaforme e agli specialisti di dati e AI che eseguono modelli di machine learning (ML) con caratteristiche come la scalabilità, la lunga durata o la prevalenza di calcoli matriciali. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questo documento, assicurati di conoscere il funzionamento degli acceleratori di 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 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 riservate. Per ulteriori informazioni, 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 carichi di lavoro di machine learning e di altro tipo.
  • Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, riducendo il sovraccarico operativo.
  • 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 carichi di lavoro.
  • 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 contribuisce a proteggere i carichi di lavoro con gVisor. Per ulteriori informazioni, consulta GKE Sandbox.

Inizia a utilizzare Ironwood (TPU7x)

Ironwood (TPU7x) è la TPU di settima generazione di Google, progettata per i carichi di lavoro AI su larga scala. Per ulteriori informazioni 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 agli errori dei link ottici e degli switch di circuiti ottici (OCS) che collegano le TPU tra i cubi. Per ulteriori informazioni, consulta Architettura TPU.
  • Cubo TPU: una topologia 4x4x4 di chip TPU interconnessi. Questo è applicabile solo alle 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 tutti situati all'interno dello stesso pod di TPU connessi da interconnessioni interchip ad alta velocità (ICI). Le sezioni sono descritte in termini di chip o TensorCore, a seconda della versione della TPU.
  • Nodo della sezione TPU: un nodo Kubernetes rappresentato da una singola VM che ha uno o più chip TPU interconnessi.
  • Node pool di nodi 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 considera tutti i nodi interconnessi come una singola unità. Durante le operazioni di scalabilità, GKE riduce l'intera serie di nodi a 0 e crea nuovi nodi. Se una macchina nel gruppo non funziona o viene terminata, GKE ricrea l'intera serie di nodi come una nuova unità.
  • Immutabile: non puoi aggiungere manualmente nuovi nodi alla serie di nodi interconnessi. Tuttavia, puoi creare un nuovo pool di nodi con la topologia TPU che preferisci e pianificare i carichi di lavoro nel nuovo pool di nodi.

Tipi di node pool della sezione TPU

GKE supporta due tipi di node pool 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 della sezione TPU multi-host.
  • Per i modelli su piccola scala, utilizza i nodi della sezione TPU single-host.
  • Per l'addestramento o l'inferenza su larga scala, utilizza Pathways. Pathways semplifica i calcoli di machine learning su larga scala consentendo a un singolo JAX di orchestrare i carichi di lavoro su più sezioni TPU di grandi dimensioni. Per ulteriori informazioni, consulta Pathways.

Node pool della sezione TPU multi-host

Un node pool della sezione TPU multi-host è un pool di nodi che contiene due o più VM TPU interconnesse. A ogni VM è collegato 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 della sezione TPU multi-host, non puoi aggiungere nodi. Ad esempio, non puoi creare un v4-32 pool di nodi 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 della sezione TPU multi-host vengono trattate come una singola unità atomica. Se GKE non è in grado di eseguire il deployment di un nodo nella sezione, non viene eseguito il deployment di alcun nodo nella sezione TPU.

Se un nodo all'interno di una sezione TPU multi-host richiede la riparazione, GKE arresta tutte le VM nella sezione TPU, forzando l'eliminazione di tutti i pod Kubernetes nel carico di lavoro. Una volta che tutte le VM nella sezione TPU sono attive e in esecuzione, 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 della slice 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

Node pool della sezione TPU single-host

Un pool di nodi della sezione single-host è un pool di nodi che contiene una o più VM TPU indipendenti. A ogni VM è collegato un dispositivo TPU. Sebbene le VM all'interno di un pool di nodi della sezione 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 sezione TPU single-host che contiene sette macchine v4-8:

Diagramma del pool di nodi della sezione a singolo 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 le prestazioni dei carichi di lavoro, GKE supporta le seguenti opzioni di consumo di TPU:

  • Avvio flessibile: per eseguire il provisioning delle VM con avvio flessibile per un massimo di sette giorni, con GKE che alloca automaticamente l'hardware in base alla disponibilità. Per ulteriori informazioni, consulta Informazioni sul provisioning di GPU, TPU e H4D con la modalità di provisioning con avvio flessibile.
  • VM spot: per eseguire il provisioning delle VM spot, puoi ottenere sconti significativi, ma le VM spot possono essere prerilasciate in qualsiasi momento, con un avviso di 30 secondi. Per ulteriori informazioni, 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 ulteriori informazioni, consulta Richiedere TPU con prenotazione futura in modalità calendario.
  • Prenotazioni 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. L'opzione on demand è la più flessibile, ma non è garantita la disponibilità di risorse on demand sufficienti per soddisfare la tua richiesta.

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

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

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. Specifichi una topologia come il numero di chip TPU in ogni dimensione nel seguente modo:

Per le TPU v4, v5p e Ironwood (TPU7x) (anteprima) pianificate nei node pool della sezione TPU multi-host, definisci la topologia in 3-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 definire topologie piccole 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 assegnati a {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 del tipo 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 macchine. Richiedi invece le TPU utilizzando un tipo di acceleratore nel manifest del carico di lavoro. 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 della TPU, consulta le tabelle in Pianificare 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 sostituisce molte delle altre impostazioni di sicurezza in securityContext. Per maggiori dettagli, consulta Eseguire container senza 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 sulle 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 riesce 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 della sezione TPU con quattro chip TPU ciascuno, per un totale di otto chip TPU. Con questo tipo di macchina:
    • Non puoi eseguire il deployment di un pod GKE che richiede otto chip TPU sui nodi in questo pool di nodi.
    • Puoi 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 carico di lavoro GKE Autopilot che seleziona questa configurazione deve richiedere quattro chip TPU in ogni replica, per un massimo di 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 non della sezione TPU.
  • Per impostazione predefinita, i nodi della sezione TPU hanno il google.com/tpu taint che impedisce la pianificazione dei carichi di lavoro non TPU sui nodi della sezione TPU. I carichi di lavoro che non utilizzano le TPU vengono eseguiti su nodi non TPU, liberando risorse di calcolo sui nodi della sezione TPU per il codice che utilizza le TPU. Tieni presente che il taint non garantisce l'utilizzo completo delle risorse TPU.
  • GKE raccoglie i log emessi dai container in esecuzione sui nodi della sezione TPU. Per scoprire di più, consulta la sezione Logging.
  • Le metriche di utilizzo delle TPU, come il rendimento di runtime, sono disponibili in Cloud Monitoring. Per scoprire di più, consulta Osservabilità e metriche.
  • Puoi eseguire il sandboxing dei carichi di lavoro TPU con GKE Sandbox. GKE Sandbox funziona con i modelli TPU v4 e successivi. Per scoprire di più, consulta GKE Sandbox.

Creazione automatica di node pool con TPU

La creazione automatica di node pool 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) (anteprima): 1.34.1-gke.2541000 o versioni successive.

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

Scalabilità automatica del pool di nodi Cloud TPU

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

  • Node pool della sezione TPU single-host: GKE aggiunge o rimuove i 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 determinato da i --max-nodes e da --total-max-nodes flag di scalabilità automatica. Tutti i nodi TPU nel pool di nodi hanno lo stesso tipo di macchina e la stessa topologia. Per ulteriori informazioni su come creare un pool di nodi della sezione TPU single-host, consulta Creare un node pool della sezione TPU single-host.
  • Node pool della sezione TPU multi-host: GKE esegue la scalabilità automatica del pool di nodi da zero al numero di nodi necessari per soddisfare la topologia TPU. Ad esempio, con un pool di nodi TPU con il tipo di macchina ct5lp-hightpu-4t e una topologia di 16x16, il pool di nodi ha sempre 64 nodi o zero nodi. GKE riduce le dimensioni del pool di nodi se non sono presenti carichi di lavoro TPU nel pool di nodi. Per ridurre le dimensioni del pool di nodi, GKE elimina tutti i pod pianificati e rimuove tutti i nodi nel pool di nodi. Per ulteriori informazioni su come creare un pool di nodi della sezione TPU multi-host, consulta Creare un node pool della sezione TPU multi-host.

Pianificazione delle raccolte

La pianificazione delle raccolte è supportata solo per TPU Trillium.

In TPU Trillium, puoi utilizzare la pianificazione delle raccolte per raggruppare i nodi della sezione TPU. Il raggruppamento di questi nodi della sezione TPU semplifica la regolazione del numero di repliche per soddisfare la domanda del carico di lavoro. 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 delle raccolte per i node pool single-host e multi-host che eseguono carichi di lavoro di inferenza. Di seguito viene descritto come il comportamento di pianificazione delle raccolte dipende dal tipo di sezione TPU utilizzata:

  • Sezione TPU multi-host: GKE raggruppa le sezioni 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 della sezione TPU multi-host con lo stesso nome della raccolta e lo stesso tipo di carico di lavoro.
  • 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 della sezione TPU single-host.

La pianificazione delle raccolte presenta le seguenti limitazioni:

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

Puoi configurare la pianificazione delle raccolte nei seguenti scenari:

Passaggi successivi

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