Informazioni sulle TPU in GKE

Questa pagina descrive come funziona Cloud TPU 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 è destinata 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, a lungo termine o dominata da calcoli matriciali. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, Google Cloud consulta Ruoli utente e attività comuni di GKE.

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 workload con gVisor. Per maggiori informazioni, consulta GKE Sandbox.

Inizia a utilizzare Ironwood (TPU7x)

Ironwood (TPU7x) è la TPU di settima generazione di Google, progettata per carichi di lavoro di AI su larga scala. Per saperne di più su Ironwood (TPU7x), consulta le seguenti risorse:

Ognuna delle seguenti opzioni per la creazione di cluster offre diversi livelli di facilità e flessibilità nella configurazione del cluster e nella pianificazione del workload:

  • Utilizza Accelerated Processing Kit (XPK) per creare rapidamente cluster GKE ed eseguire carichi di lavoro per prove concettuali e test. Per saperne di più, consulta la documentazione di XPK.
  • Utilizza Google Cloud CLI per creare manualmente l'istanza del cluster GKE per la personalizzazione precisa o l'espansione degli ambienti GKE di produzione esistenti

Terminologia relativa alle TPU in GKE

Questa pagina utilizza la seguente terminologia relativa alle TPU:

  • Resilienza ICI di Cloud TPU: una funzionalità che contribuisce a migliorare la tolleranza agli errori dei collegamenti ottici e degli interruttori di circuiti ottici (OCS) che collegano le TPU tra i cubi. Per maggiori informazioni, vedi Architettura TPU.
  • Cubo TPU:una topologia 4x4x4 di chip TPU interconnessi. Questo vale solo per le topologie in tuple di tre elementi ({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 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 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 termina, 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 nuovopool di nodil.

Tipi di node pool 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 monohost. 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 delle sezioni TPU a host singolo.
  • 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 nel nodo della 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 slice 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. Mentre 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 TPU v4, v5p e Ironwood (TPU7x) (anteprima) pianificate nei node pool 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 tpu7x-standard-4t supporta Ironwood (TPU7x) e contiene quattro 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 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 contaminazione 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 le prestazioni 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 Sandbox di GKE.

Creazione automatica del node pool con le TPU

La creazione automatica del 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.31.1-gke.1146000 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.

Scalabilità automatica del pool di nodi Cloud TPU

GKE esegue lo scale dei pool di nodi Cloud TPU creati automaticamente o manualmente che utilizzano lo strumento di scalabilità automatica del cluster in uno dei seguenti modi:

  • Pool di nodi della sezione TPU a singolo host: GKE aggiunge o rimuove nodi TPU nel node pool esistente. Il pool di nodi può contenere un numero qualsiasi di nodi TPU compreso tra zero e le dimensioni massime 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 TPU slice single-host, consulta Crea un node pool TPU slice single-host.
  • Node pool di sezioni TPU multi-host: GKE aumenta in modo atomico ilpool di nodil da zero al numero di nodi richiesti 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 workload 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 saperne di più su come creare un pool di nodi TPU slice multi-host, consulta Crea un node pool TPU slice multi-host.

Policy del workload

Il criterio del workload è supportato solo per Ironwood (TPU7x).

Una policy del carico di lavoro è un tipo di policy delle risorse che consente di configurare il posizionamento fisico dell'infrastruttura sottostante. Un criterio del carico di lavoro fornisce opzioni di configurazione gerarchiche per un controllo più granulare.

Ironwood (TPU7x) supporta la policy del workload High throughput. Questa norma ti consente di:

  • Esegui workload distribuiti che richiedono un'elevata velocità effettiva, come l'addestramento di computing ad alte prestazioni (HPC) o di machine learning (ML). L'infrastruttura sottostante è configurata per collocare le VM TPU per ridurre la latenza di rete tra le VM.
  • Definisci la strategia di manutenzione per le VM TPU per ridurre al minimo le interruzioni del workload.

Pianificazione della raccolta

La pianificazione della raccolta è supportata solo per le TPU Trillium.

In TPU Trillium, puoi utilizzare la pianificazione delle raccolte 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 nodil 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 di 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: