Informazioni sulle TPU in GKE

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

Questa pagina è dedicata agli amministratori e agli operatori della piattaforma e agli specialisti di dati e AI che eseguono modelli di machine learning (ML) con caratteristiche quali larga scala, lunga durata o dominati da calcoli matriciali. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli utente e attività comuni di GKE. Google Cloud

Prima di leggere questa pagina, assicurati di avere familiarità con il funzionamento degli acceleratori ML. Per maggiori dettagli, vedi 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 TPU e pool di nodi, 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 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 carichi di lavoro di machine learning e altri.
  • Upgrade automatici: GKE automatizza gli aggiornamenti delle versioni, il che riduce 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 tuoi carichi di lavoro.
  • Gestione delle risorse:con Kueue, un sistema di gestione delle code dei job nativo di Kubernetes, puoi gestire le risorse in più tenant all'interno della tua organizzazione utilizzando la gestione delle code, la preemption, la definizione delle priorità e la condivisione equa.
  • Opzioni di sandbox:GKE Sandbox contribuisce a proteggere i tuoi carichi di lavoro con gVisor. Per maggiori informazioni, consulta GKE Sandbox.

Vantaggi dell'utilizzo di TPU Trillium

Trillium è la TPU di sesta generazione di Google. Trillium offre i seguenti vantaggi:

  • Trillium aumenta le prestazioni di calcolo per chip rispetto a TPU v5e.
  • Trillium aumenta la capacità e la larghezza di banda della High Bandwidth Memory (HBM) e anche la larghezza di banda dell'interconnessione interchip (ICI) rispetto alla TPU v5e.
  • Trillium è dotato di SparseCore di terza generazione, un acceleratore specializzato per l'elaborazione di incorporamenti di dimensioni molto grandi comuni nei carichi di lavoro di classificazione e raccomandazione avanzati.
  • Trillium è oltre il 67% più efficiente dal punto di vista energetico rispetto a TPU v5e.
  • Trillium può scalare fino a 256 TPU in una singola sezione TPU a bassa latenza e larghezza di banda elevata.
  • Trillium supporta la pianificazione della raccolta. La pianificazione della raccolta ti consente di dichiarare un gruppo di TPU (node pool TPU single-host e multi-host) per garantire l'alta disponibilità per le esigenze dei tuoi workload di inferenza.

In tutte le superfici tecniche come API e log e in parti specifiche della documentazione di GKE, utilizziamo v6e o TPU Trillium (v6e) per fare riferimento alle TPU Trillium. Per scoprire di più sui vantaggi di Trillium, leggi il post del blog sull'annuncio di Trillium. Per iniziare la configurazione delle TPU, consulta Pianificare le TPU in GKE.

Terminologia relativa alle TPU in GKE

Questa pagina utilizza la seguente terminologia relativa alle TPU:

  • Tipo di TPU:il tipo di Cloud TPU, ad esempio v5e.
  • Nodo sezione TPU: un nodo Kubernetes rappresentato da una singola VM con uno o più chip TPU interconnessi.
  • Pool di nodi di sezioni di 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 ridimensiona l'intero insieme di nodi a 0 e crea nuovi nodi. Se una macchina nel gruppo non funziona o viene terminata, GKE ricrea l'intero insieme 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 ti interessa e pianificare i carichi di lavoro nel nuovo pool di nodi.

Tipi di pool di nodi di sezioni TPU

GKE supporta due tipi di node pool TPU:

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

  • Per i modelli su larga scala, utilizza i nodi slice TPU multi-host.
  • Per i modelli su piccola scala, utilizza i nodi slice TPU a singolo 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 client JAX di orchestrare i workload su più sezioni di TPU di grandi dimensioni. Per saperne di più, consulta Pathways.

Node pool TPU multi-host

Un node pool di sezioni 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 multihost sono connesse tramite un'interconnessione ad alta velocità (ICI). Dopo aver creato un pool di nodi 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 nuovopool di nodil.

Le VM in un pool di nodi di sezioni TPU multi-host vengono trattate come una singola unità atomica. Se GKE non riesce a 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 multihost richiede la riparazione, 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 in esecuzione, i pod Kubernetes possono essere pianificati sulle VM nella nuova sezione TPU.

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

Diagramma della 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 single-host slice è un pool di nodi che contiene una o più VM TPU indipendenti. A ogni VM è collegato un dispositivo TPU. Anche se le VM all'interno di un pool di nodi slice a singolo host possono comunicare tramite la rete del data center (DCN), le TPU collegate alle VM non sono interconnesse.

Il seguente diagramma mostra un esempio di slice TPU a un solo host che contiene sette macchine v4-8:

Diagramma del pool di nodi di una sezione 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 le prestazioni del carico di lavoro, GKE supporta le seguenti opzioni di consumo di TPU:

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

Per le TPU v4 e v5p pianificate nei pool di nodi delle sezioni TPU multi-host, definisci la topologia in tuple di tre elementi ({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 che assegni 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.

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 sezione di nodi, ad esempio ct<version>-hightpu-<node-chip-count>t. Ad esempio, il tipo di macchina ct5lp-hightpu-1t supporta TPU v5e e contiene un solo chip TPU.

Modalità con privilegi

Se utilizzi versioni di GKE precedenti alla 1.28, devi configurare i tuoi 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 ignora molte delle altre impostazioni di sicurezza in securityContext. Per maggiori dettagli, vedi Esegui 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 chip TPU, utilizza il nome 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 slice TPU con quattro chip TPU ciascuno, per un totale di otto chip TPU. Con questo tipo di macchina, puoi:
    • 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 di 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 node pool di nodi di slice non TPU.
  • Per impostazione predefinita, i nodi della sezione TPU hanno il google.com/tpu taint 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 calcolo 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 slice TPU. Per saperne di più, vedi Logging.
  • Le metriche di utilizzo della TPU, come il rendimento del runtime, sono disponibili in Cloud Monitoring. Per scoprire di più, consulta Osservabilità e metriche.
  • Puoi mettere in sandbox i tuoi carichi di lavoro TPU con GKE Sandbox. GKE Sandbox funziona con i modelli TPU v4 e versioni successive. Per saperne di più, consulta GKE Sandbox.

Come funziona la pianificazione della raccolta

In TPU Trillium, puoi utilizzare la pianificazione della raccolta per raggruppare i nodi delle sezioni TPU. Il raggruppamento di questi nodi slice 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 slice 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 carichi di lavoro di inferenza. Di seguito viene descritto come il comportamento di pianificazione della raccolta dipende dal tipo di sezione TPU che utilizzi:

  • 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 uno slice TPU multi-host e assegna un nome univoco alla raccolta. Per aggiungere altre sezioni di TPU alla raccolta, crea un altro pool di nodi di sezioni di TPU multi-host con lo stesso nome della raccolta e 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 ilpool di nodil 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 node pool di sezioni TPU multi-host devono utilizzare lo stesso tipo di macchina, topologia e versione per tutti i node pool 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: