Esegui il deployment dei carichi di lavoro TPU in GKE Standard

Questa pagina fornisce le nozioni di base per imparare ad accelerare i carichi di lavoro di machine learning (ML) utilizzando le TPU in Google Kubernetes Engine (GKE). Le TPU sono progettate per l'elaborazione della moltiplicazione di matrici, ad esempio l'addestramento di modelli di deep learning su larga scala. Le TPU sono ottimizzate per gestire gli enormi set di dati e i modelli complessi del machine learning e, di conseguenza, sono più convenienti ed efficienti dal punto di vista energetico per i carichi di lavoro di ML grazie alle loro prestazioni superiori. In questa guida scoprirai come eseguire il deployment dei workload di ML utilizzando gli acceleratori Cloud TPU, configurare le quote per le TPU, configurare gli upgrade per i pool di nodi che eseguono le TPU e monitorare le metriche dei workload TPU.

Questo tutorial è rivolto a sviluppatori di machine learning (ML), nonché ad amministratori e operatori della piattaforma interessati a utilizzare l'orchestrazione dei container Kubernetes per gestire carichi di lavoro di addestramento, ottimizzazione e inferenza dei modelli su larga scala utilizzando le TPU. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui si fa riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere quanto segue:

• Cloud TPU
• Architettura di sistema di Cloud TPU
• TPU in GKE

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Pianifica la configurazione della TPU

Pianifica la configurazione della TPU in base al modello e alla quantità di memoria richiesta. Prima di utilizzare questa guida per eseguire il deployment dei tuoi carichi di lavoro su TPU, completa i passaggi di pianificazione descritti in Pianificare la configurazione della TPU.

Assicurati di disporre della quota TPU

Quota per VM on demand o spot

Se stai creando un pool di nodi di sezioni TPU con VM on demand o spot, devi avere una quota TPU sufficiente disponibile nella regione che vuoi utilizzare.

La creazione di un pool di nodi di sezioni TPU che utilizza una prenotazione TPU non richiede alcuna quota TPU.¹ Puoi saltare questa sezione in tutta sicurezza per le TPU riservate.

La creazione di un pool di nodi di slice TPU on demand o spot in GKE richiede una quota dell'API Compute Engine. La quota dell'API Compute Engine (compute.googleapis.com) non è uguale alla quota dell'API Cloud TPU (tpu.googleapis.com), necessaria quando si creano TPU con l'API Cloud TPU.

Per controllare il limite e l'utilizzo corrente della quota dell'API Compute Engine per le TPU, segui questi passaggi:

1. Vai alla pagina Quote nella console Google Cloud:

   Vai a Quote

2. Nella casella filter_list Filtro, procedi nel seguente modo:

   1. Seleziona la proprietà Servizio, inserisci API Compute Engine e premi Invio.

   2. Seleziona la proprietà Tipo e scegli Quota.

   3. Seleziona la proprietà Nome e inserisci il nome della quota in base alla versione TPU e al tipo di macchina. Ad esempio, se prevedi di creare nodi TPU v5e on demand il cui tipo di macchina inizia con ct5lp-, inserisci TPU v5 Lite PodSlice chips.

      Versione TPU	Il tipo di macchina inizia con	Nome della quota per le istanze on demand	Nome della quota per le istanze Spot2
      TPU v3	ct3-	TPU v3 Device chips	Preemptible TPU v3 Device chips
      TPU v3	ct3p-	TPU v3 PodSlice chips	Preemptible TPU v3 PodSlice chips
      TPU v4	ct4p-	TPU v4 PodSlice chips	Preemptible TPU v4 PodSlice chips
      TPU v5e	ct5l-	TPU v5 Lite Device chips	Preemptible TPU v5 Lite Device chips
      TPU v5e	ct5lp-	TPU v5 Lite PodSlice chips	Preemptible TPU v5 Lite PodSlice chips
      TPU v5p	ct5p-	TPU v5p chips	Preemptible TPU v5p chips
      TPU v6e	ct6e-	TPU v6e Slice chips	Preemptible TPU v6e Lite PodSlice chips

   4. Seleziona la proprietà Dimensioni (ad es. località) e inserisci region: seguito dal nome della regione in cui prevedi di creare le TPU in GKE. Ad esempio, inserisci region:us-west4 se prevedi di creare nodi di slice TPU nella zona us-west4-a. La quota TPU è regionale, pertanto tutte le zone all'interno della stessa regione consumano la stessa quota TPU.

Se nessuna quota corrisponde al filtro inserito, significa che al progetto non è stata assegnata alcuna quota specificata per la regione di cui hai bisogno e devi richiedere un aumento della quota TPU.

Quando viene creata una prenotazione TPU, sia il limite sia i valori di utilizzo corrente per la quota corrispondente aumentano in base al numero di chip nella prenotazione TPU. Ad esempio, quando viene creata una prenotazione per 16 chip TPU v5e il cui tipo di macchina inizia con ct5lp-, sia il limite sia l'utilizzo corrente per la quota TPU v5 Lite PodSlice chips nella regione pertinente aumentano di 16.

Quote per risorse GKE aggiuntive

Potresti dover aumentare le seguenti quote relative a GKE nelle regioni in cui GKE crea le tue risorse.

• Quota SSD (GB) di Persistent Disk: il disco di avvio di ogni nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata su un valore almeno uguale al prodotto del numero massimo di nodi GKE che prevedi di creare e 100 GB (nodi * 100 GB).
• Quota indirizzi IP in uso: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno sul numero massimo di nodi GKE che prevedi di creare.
• Assicurati che max-pods-per-node sia in linea con l'intervallo della subnet: ogni nodo Kubernetes utilizza intervalli IP secondari per i pod. Ad esempio, max-pods-per-node di 32 richiede 64 indirizzi IP, che si traducono in una subnet /26 per nodo. Tieni presente che questo intervallo non deve essere condiviso con nessun altro cluster. Per evitare di esaurire l'intervallo di indirizzi IP, utilizza il flag --max-pods-per-node per limitare il numero di pod che è consentito pianificare su un nodo. La quota per max-pods-per-node deve essere impostata su un valore almeno pari al numero massimo di nodi GKE che prevedi di creare.

Per richiedere un aumento della quota, vedi Richiedere una quota superiore.

Garantire la disponibilità delle prenotazioni

La creazione di un pool di nodi di sezioni TPU riservate, che utilizza una prenotazione, non richiede alcuna quota TPU. Tuttavia, la prenotazione deve avere chip TPU disponibili o non utilizzati sufficienti al momento della creazione del pool di nodi.

Per vedere quali prenotazioni esistono all'interno di un progetto, visualizza un elenco delle tue prenotazioni.

Per visualizzare il numero di chip TPU disponibili all'interno di una prenotazione TPU, visualizza i dettagli di una prenotazione.

Crea un cluster

Crea un cluster GKE in modalità standard in una regione con TPU disponibili.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del nuovo cluster.
• LOCATION: la regione con la capacità TPU disponibile.
• VERSION: la versione di GKE, che deve supportare il tipo di macchina che vuoi utilizzare. Tieni presente che la versione GKE predefinita potrebbe non essere disponibile per la TPU di destinazione. Per scoprire quali sono le versioni minime di GKE disponibili in base al tipo di macchina TPU, consulta la sezione Disponibilità di TPU in GKE.

Crea un node pool

Sezione TPU a host singolo

Puoi creare un pool di nodi di slice TPU a un solo host utilizzando Google Cloud CLI, Terraform o la console Google Cloud.

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
  }
}

Sezione TPU multi-host

Puoi creare un pool di nodi di slice TPU multi-host utilizzando Google Cloud CLI, Terraform o la console Google Cloud.

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONE \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    [--spot \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    

Stato del provisioning

Se GKE non riesce a creare il node pool della sezione TPU a causa di una capacità TPU insufficiente, restituisce un messaggio di errore che indica che i nodi della sezione TPU non possono essere creati a causa della mancanza di capacità.

Se stai creando un pool di nodi di sezioni TPU con un solo host, il messaggio di errore sarà simile al seguente:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Se stai creando un pool di nodi di sezioni TPU multi-host, il messaggio di errore sarà simile al seguente:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

La richiesta di provisioning di TPU può rimanere in coda per molto tempo e rimane nello stato "Provisioning" mentre è in coda.

Una volta che la capacità è disponibile, GKE crea i nodi rimanenti che non sono stati creati.

Se hai bisogno di capacità prima, ti consigliamo di provare le VM spot, anche se tieni presente che le VM spot consumano una quota diversa rispetto alle istanze on demand.

Puoi eliminare la richiesta TPU in coda eliminando il pool di nodi del segmento TPU.

Esegui il carico di lavoro sui nodi delle sezioni TPU

Preparazione del workload

I carichi di lavoro TPU hanno i seguenti requisiti di preparazione.

1. Framework come JAX, PyTorch e TensorFlow accedono alle VM TPU utilizzando la libtpu libreria condivisa. libtpu include il compilatore XLA, il software di runtime TPU e il driver TPU. Ogni release di PyTorch e JAX richiede una determinata versione di libtpu.so. Per utilizzare le TPU in GKE, assicurati di utilizzare le seguenti versioni:

   Tipo di TPU	libtpu.so versione
   TPU v6e tpu-v6e-slice	Versione jax[tpu] consigliata: v0.4.9 o successive Versione consigliata di torchxla[tpuvm]: v2.1.0 o successive
   TPU v5e tpu-v5-lite-podslice tpu-v5-lite-device	Versione jax[tpu] consigliata: v0.4.9 o successive Versione consigliata di torchxla[tpuvm]: v2.1.0 o successive
   TPU v5p tpu-v5p-slice	Versione consigliata di jax[tpu]: 0.4.19 o successive. Versione torchxla[tpuvm] consigliata: è consigliabile utilizzare una compilazione della versione nightly del 23 ottobre 2023.
   TPU v4 tpu-v4-podslice	Jax[tpu] consigliato: v0.4.4 o successive torchxla[tpuvm] consigliato: v2.0.0 o successive
   TPU v3 tpu-v3-slice tpu-v3-device	Jax[tpu] consigliato: v0.4.4 o successive torchxla[tpuvm] consigliato: v2.0.0 o successive

2. Imposta le seguenti variabili di ambiente per il contenitore che richiede le risorse TPU:
   • TPU_WORKER_ID: un numero intero univoco per ogni pod. Questo ID indica un ID worker univoco nel segmento TPU. I valori supportati per questo campo vanno da zero al numero di pod meno uno.
   • TPU_WORKER_HOSTNAMES: un elenco separato da virgole di nomi host o indirizzi IP delle VM TPU che devono comunicare tra loro all'interno del segmento. Deve essere presente un nome host o un indirizzo IP per ogni VM TPU nel segmento. L'elenco di indirizzi IP o nomi host è ordinato e ha indice zero per TPU_WORKER_ID.

   GKE inietta automaticamente queste variabili di ambiente utilizzando un webhook con mutazioni quando viene creato un job con le proprietà completionMode: Indexed, subdomain, parallelism > 1 e google.com/tpu di richiesta. GKE aggiunge un servizio senza interfaccia in modo che i record DNS vengano aggiunti per i pod che supportano il servizio.

   Quando esegui il deployment di risorse multi-host TPU con Kuberay, GKE fornisce un webhook disponibile come parte dei modelli Terraform per l'esecuzione di Ray su GKE. Le istruzioni per eseguire Ray su GKE con le TPU sono disponibili nella Guida utente di TPU. Il webhook con mutazioni inietta queste variabili di ambiente nei cluster Ray che richiedono proprietà google.com/tpu e un selettore di nodi cloud.google.com/gke-tpu-topology multi-host.

   • Nel manifest del carico di lavoro, aggiungi i selettori dei nodi Kubernetes per assicurarti che GKE pianifichi il carico di lavoro TPU sul tipo di macchina TPU e sulla topologia TPU che hai definito:

       nodeSelector:
         cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
         cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
       

     Sostituisci quanto segue:

     • TPU_ACCELERATOR: il nome dell'acceleratore TPU.
     • TPU_TOPOLOGY: la topologia fisica per la sezione TPU. Il formato della topologia dipende dalla versione della TPU. Per scoprire di più, consulta Pianificare le TPU in GKE.

Una volta completata la preparazione del carico di lavoro, puoi eseguire un job che utilizza le TPU.

Le sezioni seguenti mostrano esempi di come eseguire un job che esegue calcoli semplici con le TPU.

Esempio 1: esegui un carico di lavoro che mostra il numero di chip TPU disponibili in un pool di nodi di sezioni TPU

Il seguente carico di lavoro restituisce il numero di chip TPU su tutti i nodi di uno slice TPU multi-host. Per creare uno slice multi-host, il carico di lavoro ha i seguenti parametri:

• Versione TPU: TPU v4
• Topologia: 2x2x4

Questa versione e la selezione della topologia generano uno slice multi-host.

1. Salva il seguente manifest come available-chips-multihost.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: headless-svc
   spec:
     clusterIP: None
     selector:
       job-name: tpu-available-chips
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: tpu-available-chips
   spec:
     backoffLimit: 0
     completions: 4
     parallelism: 4
     completionMode: Indexed
     template:
       spec:
         subdomain: headless-svc
         restartPolicy: Never
         nodeSelector:
           cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
           cloud.google.com/gke-tpu-topology: 2x2x4
         containers:
         - name: tpu-job
           image: python:3.10
           ports:
           - containerPort: 8471 # Default port using which TPU VMs communicate
           - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
           securityContext:
             privileged: true
           command:
           - bash
           - -c
           - |
             pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
             python -c 'import jax; print("TPU cores:", jax.device_count())'
           resources:
             requests:
               cpu: 10
               memory: 500Gi
               google.com/tpu: 4
             limits:
               cpu: 10
               memory: 500Gi
               google.com/tpu: 4

2. Esegui il deployment del manifest:

   kubectl create -f available-chips-multihost.yaml
   

   GKE esegue una sezione TPU v4 con quattro VM (sezione TPU multi-host). La sezione ha 16 chip TPU interconnessi.

3. Verifica che il job abbia creato quattro pod:

   kubectl get pods
   

   L'output è simile al seguente:

   NAME                       READY   STATUS      RESTARTS   AGE
   tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
   tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
   tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
   tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
   

4. Recupera i log di uno dei pod:

   kubectl logs POD_NAME
   

   Sostituisci POD_NAME con il nome di uno dei pod creati. Ad esempio, tpu-job-podslice-0-5cd8r.

   L'output è simile al seguente:

   TPU cores: 16
   

Esempio 2: esegui un carico di lavoro che mostra il numero di chip TPU disponibili nella sezione TPU

Il seguente carico di lavoro è un pod statico che mostra il numero di chip TPU collegati a un nodo specifico. Per creare un nodo a host singolo, il carico di lavoro ha i seguenti parametri:

• Versione TPU: TPU v5e
• Topologia: 2x4

Questa versione e la selezione della topologia generano uno slice con un solo host.

1. Salva il seguente manifest come available-chips-singlehost.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: tpu-job-jax-v5
   spec:
     restartPolicy: Never
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
       cloud.google.com/gke-tpu-topology: 2x4
     containers:
     - name: tpu-job
       image: python:3.10
       ports:
       - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
       securityContext:
         privileged: true
       command:
       - bash
       - -c
       - |
         pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
         python -c 'import jax; print("Total TPU chips:", jax.device_count())'
       resources:
         requests:
           google.com/tpu: 8
         limits:
           google.com/tpu: 8

2. Esegui il deployment del manifest:

   kubectl create -f available-chips-singlehost.yaml
   

   GKE esegue il provisioning di nodi con otto sezioni TPU a host singolo che utilizzano TPU v5e. Ogni nodo TPU ha otto chip TPU (sezione TPU con un solo host).

3. Recupera i log del pod:

   kubectl logs tpu-job-jax-v5
   

   L'output è simile al seguente:

   Total TPU chips: 8
   

Esegui l'upgrade dei pool di nodi utilizzando gli acceleratori (GPU e TPU)

GKE esegue automaticamente l'upgrade dei cluster standard, inclusi i pool di nodi. Puoi anche eseguire manualmente l'upgrade dei pool di nodi se vuoi che i tuoi nodi passino a una versione successiva prima. Per controllare il funzionamento degli upgrade per il tuo cluster, utilizza i canali di rilascio, i periodi di manutenzione ed esclusioni e la sequenziazione del rollout.

Puoi anche configurare una strategia di upgrade dei nodi per il tuo pool di nodi, ad esempio gli upgrade per picchi di domanda o gli upgrade blue-green. Configurando queste strategie, puoi assicurarti che l'upgrade dei pool di nodi venga eseguito in modo da ottenere un equilibrio ottimale tra velocità e interruzione per il tuo ambiente. Per i pool di nodi con sezioni TPU multi-host, anziché utilizzare la strategia di upgrade dei nodi configurata, GKE ricrea l'intero pool di nodi in un unico passaggio. Per scoprire di più, consulta la definizione di atomicità in Terminologia relativa alle TPU in GKE.

L'utilizzo di una strategia di upgrade dei nodi richiede temporaneamente a GKE di eseguire il provisioning di risorse aggiuntive, a seconda della configurazione. Se Google Cloud ha una capacità limitata per le risorse del tuo pool di nodi, ad esempio visualizzi errori di disponibilità delle risorse quando provi a creare altri nodi con GPU o TPU, consulta Eseguire l'upgrade in un ambiente con risorse limitate.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questa guida, ti consigliamo di eliminare i node pool di slice TPU che non hanno più carichi di lavoro pianificati. Se i workload in esecuzione devono essere terminati in modo corretto, utilizza kubectl drain per ripulire i workload prima di eliminare il nodo.

1. Elimina un pool di nodi di slice TPU:

   gcloud container node-pools delete POOL_NAME \
       --location=LOCATION \
       --cluster=CLUSTER_NAME
   

   Sostituisci quanto segue:

   • POOL_NAME: il nome del pool di nodi.
   • CLUSTER_NAME: il nome del cluster.
   • LOCATION: la posizione di calcolo del cluster.

Configurazioni aggiuntive

Le seguenti sezioni descrivono le configurazioni aggiuntive che puoi applicare ai carichi di lavoro TPU.

Gestire la pianificazione delle raccolte

In TPU v6e, puoi utilizzare la pianificazione delle raccolte per raggruppare i nodi di slice TPU. Il raggruppamento di questi nodi di 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 all'interno della raccolta siano sempre disponibili slice sufficienti per gestire il traffico.

Utilizza le seguenti attività per gestire i pool di nodi di sezioni TPU a host singolo.

• Per verificare se in un pool di slice TPU a un solo host è abilitata la pianificazione della raccolta, esegui il seguente comando:

  gcloud container node-pools describe NODE_POOL_NAME \
      --cluster CLUSTER_NAME \
      --project PROJECT_NAME \
      --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
  

  L'output è simile al seguente:

  gke-workload-type: HIGH_AVAILABILITY
  

  Se il pool di sezioni TPU a host singolo fa parte di una raccolta, l'output ha l'etichetta cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

• Per eseguire lo scale up della raccolta, ridimensiona il pool di nodi manualmente o automaticamente con il provisioning automatico dei nodi.

• Per fare lo scale down la raccolta, elimina il node pool.

• Per eliminare la raccolta, rimuovi tutti i pool di nodi collegati. Puoi eliminare il pool di nodi o eliminare il cluster. L'eliminazione del clusterrimuove tutte le raccolte al suo interno.

Multislice

Puoi aggregare più sezioni più piccole in un multislice per gestire carichi di lavoro di addestramento più grandi. Per ulteriori informazioni, consulta TPU multislice in GKE.

Esegui la migrazione della prenotazione TPU

Se hai già prenotazioni TPU, devi prima eseguire la migrazione della prenotazione TPU a un nuovo sistema di prenotazione basato su Compute Engine. Puoi anche creare un sistema di prenotazione basato su Compute Engine in cui non è necessaria alcuna migrazione. Per scoprire come eseguire la migrazione delle prenotazioni TPU, consulta Prenotazione TPU.

Logging

I log emessi dai container in esecuzione sui nodi GKE, incluse le VM TPU, vengono raccolti dall'agente di logging GKE, inviati a Logging e sono visibili in Logging.

Utilizzare il provisioning automatico dei nodi GKE

Puoi configurare GKE in modo da creare ed eliminare automaticamente i node pool per soddisfare le richieste di risorse dei tuoi workload TPU. Per ulteriori informazioni, consulta la pagina sulla configurazione di Cloud TPU.

Riparazione automatica dei nodi della sezione TPU

Se un nodo di sezione TPU in un pool di nodi di sezione TPU multi-host non è in stato di esecuzione, l'intero pool di nodi viene ricreato. Invece, in un pool di nodi di sezione TPU con un solo host, solo il nodo TPU non funzionante viene riparato automaticamente.

Le condizioni che determinano nodi di sezioni TPU non operativi includono quanto segue:

• Qualsiasi nodo della sezione TPU con condizioni del nodo comuni.
• Qualsiasi nodo della sezione TPU con un numero di TPU non allocabili maggiore di zero.
• Qualsiasi istanza VM in uno slice TPU che è stata arrestata (a causa della preemption) o è stata interrotta.
• Manutenzione dei nodi: se un nodo della sezione TPU all'interno di un node pool della sezione TPU multi-host si arresta per la manutenzione dell'host, GKE ricrea l'intero pool di nodi della sezione TPU.

Puoi vedere lo stato della riparazione (incluso il motivo dell'errore) nella cronologia delle operazioni. Se l'errore è causato da una quota insufficiente, contatta il rappresentante dell'account Google Cloud per aumentare la quota corrispondente.

Configura l'interruzione controllata del nodo del segmento TPU

Nei cluster GKE con il piano di controllo in esecuzione nella versione 1.29.1-gke.1425000 o successive, i nodi della sezione TPU supportano gli indicatori SIGTERM che avvisano il nodo di un imminente scollegamento. La notifica di arresto imminente è configurabile fino a cinque minuti nei nodi TPU.

Per configurare GKE in modo che termini i carichi di lavoro in modo corretto in questo periodo di tempo della notifica, segui i passaggi descritti in Gestire l'interruzione dei nodi GKE per GPU e TPU.

Esegui i container senza modalità privilegiata

I contenitori in esecuzione nei nodi di GKE 1.28 o versioni successive non devono avere la modalità privilegiata abilitata per accedere alle TPU. I nodi nella versione 1.28 e precedenti di GKE richiedono la modalità privilegiata.

Se il nodo del segmento TPU esegue versioni precedenti alla 1.28, leggi la sezione seguente:

Un contenitore in esecuzione su una VM in una sezione TPU deve accedere a limiti più elevati per la memoria bloccata in modo che il driver possa comunicare con i chip TPU tramite accesso diretto alla memoria (DMA). Per attivare questa opzione, devi configurare un valore ulimit più elevato. Se vuoi ridurre l'ambito delle autorizzazioni nel contenitore, completa i seguenti passaggi:

1. Modifica securityContext in modo da includere i seguenti campi:

   securityContext:
     capabilities:
       add: ["SYS_RESOURCE"]
   

2. Aumenta ulimit eseguendo il seguente comando all'interno del contenitore prima di configurare i carichi di lavoro per l'utilizzo delle risorse TPU:

   ulimit -l 68719476736
   

Per TPU v5e, l'esecuzione di contenitori senza modalità privilegiata è disponibile nei cluster nella versione 1.27.4-gke.900 e successive.

Osservabilità e metriche

Dashboard

Nella pagina Cluster Kubernetes della console Google Cloud, la scheda Osservabilità mostra le metriche di osservabilità di TPU. Per ulteriori informazioni, consulta le metriche di osservabilità di GKE.

La dashboard TPU viene compilata solo se hai attivato le metriche di sistema nel tuo cluster GKE.

Metriche di runtime

In GKE 1.27.4-gke.900 o versioni successive, i carichi di lavoro TPU che utilizzano JAX versione 0.4.14 o successive e specificano containerPort: 8431 esportano le metriche di utilizzo delle TPU come GKE metriche di sistema. In Cloud Monitoring sono disponibili le seguenti metriche per monitorare le prestazioni di runtime del tuo carico di lavoro TPU:

• Ciclo di lavoro: percentuale di tempo nell'ultimo periodo di campionamento (60 secondi) durante il quale i TensorCore hanno eseguito attivamente l'elaborazione su un chip TPU. Una percentuale più elevata indica un migliore utilizzo della TPU.
• Memoria utilizzata: quantità di memoria dell'acceleratore allocata in byte. Campionamento eseguito ogni 60 secondi.
• Totale memoria: memoria acceleratore totale in byte. Campionamento eseguito ogni 60 secondi.

Queste metriche si trovano nello schema del nodo Kubernetes (k8s_node) e del container Kubernetes (k8s_container).

Container Kubernetes:

• kubernetes.io/container/accelerator/duty_cycle
• kubernetes.io/container/accelerator/memory_used
• kubernetes.io/container/accelerator/memory_total

Nodo Kubernetes:

• kubernetes.io/node/accelerator/duty_cycle
• kubernetes.io/node/accelerator/memory_used
• kubernetes.io/node/accelerator/memory_total

Metriche host

In GKE 1.28.1-gke.1066000 o versioni successive, le VM in uno slice TPU esportano le metriche di utilizzo delle TPU come metriche di sistema GKE. In Cloud Monitoring sono disponibili le seguenti metriche per monitorare le prestazioni dell'host TPU:

• Utilizzo TensorCore: la percentuale attuale di TensorCore utilizzata. Il valore di TensorCore è uguale alla somma delle unità di moltiplicazione a matrice (MXU) più l'unità vettoriale. Il valore di utilizzo di TensorCore è la divisione delle operazioni TensorCore che sono state eseguite nell'ultimo periodo di campionamento (60 secondi) per il numero di operazioni TensorCore supportate nello stesso periodo. Un valore più elevato indica un utilizzo migliore.
• Utilizzo larghezza di banda memoria: percentuale corrente della larghezza di banda della memoria dell'acceleratore in uso. Calcolata dividendo la larghezza di banda della memoria impiegata in un periodo di campionamento (60 secondi) per la larghezza di banda massima supportata nello stesso periodo di campionamento.

Queste metriche si trovano nello schema del nodo Kubernetes (k8s_node) e del container Kubernetes (k8s_container).

Container Kubernetes:

• kubernetes.io/container/accelerator/tensorcore_utilization
• kubernetes.io/container/accelerator/memory_bandwidth_utilization

Nodo Kubernetes:

• kubernetes.io/container/node/tensorcore_utilization
• kubernetes.io/container/node/memory_bandwidth_utilization

Per ulteriori informazioni, consulta le metriche di Kubernetes e le metriche di sistema GKE.

Problemi noti

• Il gestore della scalabilità automatica del cluster potrebbe calcolare erroneamente la capacità per i nuovi nodi di slice TPU prima che questi nodi segnalino le TPU disponibili. Il gestore della scalabilità automatica dei cluster potrebbe quindi eseguire un ulteriore scale up e creare più nodi del necessario. Il gestore della scalabilità automatica del cluster esegue lo scale down di altri nodi, se non sono necessari, dopo l'operazione di fare lo scale down regolare.
• Il gestore della scalabilità automatica dei cluster annulla il ridimensionamento dei pool di nodi dei slice TPU che rimangono in stato di attesa per più di 10 ore. Il gestore della scalabilità automatica dei cluster riprova queste operazioni di scale up in un secondo momento. Questo comportamento potrebbe ridurre la disponibilità delle TPU per i clienti che non utilizzano le prenotazioni.
• I carichi di lavoro non TPU che tollerano l'alterazione TPU possono impedire fare lo scale down del pool di nodi se vengono ricreati durante lo svuotamento del pool di nodi della sezione TPU.
• La metrica Utilizzo larghezza di banda memoria non è disponibile per le TPU v5e.

Passaggi successivi

• Scopri di più sulla configurazione di Ray su GKE con le TPU
• Creare modelli di machine learning su larga scala su Cloud TPU con GKE
• Pubblicare modelli linguistici di grandi dimensioni con KubeRay su TPU
• Risolvere i problemi relativi alle TPU in GKE