Esegui il deployment dei carichi di lavoro TPU su GKE Autopilot

Questa pagina descrive come accelerare i carichi di lavoro di machine learning (ML) utilizzando gli acceleratori Cloud TPU (TPU) nei cluster Google Kubernetes Engine (GKE) Autopilot. Queste indicazioni possono aiutarti a selezionare le librerie corrette per i framework delle applicazioni ML, a configurare i carichi di lavoro TPU per l'esecuzione ottimale su GKE e a monitorare i carichi di lavoro dopo il deployment.

Questa pagina è rivolta ad amministratori e operatori della piattaforma, specialisti di dati e AI e sviluppatori di applicazioni che vogliono preparare ed eseguire workload di ML su TPU. Per scoprire di più sui ruoli, sulle responsabilità e sulle attività di esempio comuni a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività utente GKE comuni.

Prima di leggere questa pagina, assicurati di avere familiarità con le seguenti risorse:

Come funzionano le TPU in Autopilot

Per utilizzare le TPU nei workload Autopilot, specifica quanto segue nel manifest del workload:

  • La versione di TPU nel campo spec.nodeSelector.
  • La topologia TPU nel campo spec.nodeSelector. La topologia deve essere supportata dalla versione della TPU specificata.
  • Il numero di chip TPU nei campi spec.containers.resources.requests e spec.containers.resources.limits.

Quando esegui il deployment del workload, GKE esegue il provisioning dei nodi con la configurazione TPU richiesta e pianifica i pod sui nodi. GKE posiziona ogni workload sul proprio nodo in modo che ogni pod possa accedere alle risorse complete del nodo con un rischio ridotto di interruzioni.

Le TPU in Autopilot sono compatibili con le seguenti funzionalità:

  1. Spot Pods
  2. Prenotazioni di capacità specifiche
  3. Pod con autonomia estesa
  4. Avvio flessibile

Pianificare la configurazione TPU

Prima di utilizzare questa guida per eseguire il deployment dei workload TPU, pianifica la configurazione della TPU in base al modello e alla quantità di memoria richiesta. Per maggiori dettagli, vedi Pianificare la configurazione della TPU.

Prezzi

Per informazioni sui prezzi, consulta Prezzi di Autopilot.

Prima di iniziare

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

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster Autopilot che esegue GKE versione 1.32.3-gke.1927000 o successive. Per istruzioni, consulta Crea un cluster Autopilot.
  • Per utilizzare le TPU riservate, assicurati di avere una prenotazione di capacità specifica esistente. Per le istruzioni, consulta Utilizzare una prenotazione.

Garantire la quota per le TPU e altre risorse GKE

Le sezioni seguenti ti aiutano ad assicurarti di avere una quota sufficiente quando utilizzi le TPU in GKE.

Per creare nodi slice TPU, devi disporre di una quota TPU disponibile, a meno che tu non stia utilizzando una prenotazione di capacità esistente. Se utilizzi TPU riservate, salta questa sezione.

La creazione di nodi slice TPU in GKE richiede la quota dell'API Compute Engine (compute.googleapis.com), non la quota dell'API Cloud TPU (tpu.googleapis.com). Il nome della quota è diverso nei pod Autopilot normali e nei pod spot.

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

  1. Vai alla pagina Quote nella console Google Cloud :

    Vai a Quote

  2. Nella casella Filtro , procedi nel seguente modo:

    1. Utilizza la tabella seguente per selezionare e copiare la proprietà della quota in base alla versione della TPU e al valore nel selettore di nodi cloud.google.com/gke-tpu-accelerator. Ad esempio, se prevedi di creare nodi TPU v5e on demand il cui valore nel selettore di nodi cloud.google.com/gke-tpu-accelerator è tpu-v5-lite-podslice, inserisci Name: TPU v5 Lite PodSlice chips.

      Versione TPU, cloud.google.com/gke-tpu-accelerator Proprietà e nome della quota per le istanze on demand Proprietà e nome della quota per le istanze Spot2
      TPU v3,
      tpu-v3-device 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Non applicabile
      TPU v3,
      tpu-v3-slice 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Non applicabile
      TPU v4,
      tpu-v4-podslice 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      tpu-v5-lite-podslice 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p,
      tpu-v5p-slice 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium,
      tpu-v6e-slice 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e
      Ironwood (TPU7x),
      tpu7x 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

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

Se nessuna quota corrisponde al filtro inserito, al progetto non è stata concessa nessuna delle quote specificate per la regione di cui hai bisogno e devi richiedere un aggiustamento della quota TPU.

Quando viene creata una prenotazione TPU, sia il limite che i valori di utilizzo attuali per la quota corrispondente aumentano del numero di chip nella prenotazione TPU. Ad esempio, quando viene creata una prenotazione per 16 chip TPU v5e il cui valore nel selettore di nodi cloud.google.com/gke-tpu-accelerator è tpu-v5-lite-podslice, sia il limite che 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 correlate a GKE nelle regioni in cui GKE crea le risorse.

  • Quota SSD Persistent Disk (GB): il disco di avvio di ogni nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata almeno sul prodotto del numero massimo di nodi GKE che prevedi di creare e 100 GB (nodi * 100 GB).
  • Quota di 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 di subnet: ogni nodo Kubernetes utilizza intervalli IP secondari per i pod. Ad esempio, max-pods-per-node di 32 richiede 64 indirizzi IP, il che si traduce 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 di cui è consentita la pianificazione su un nodo. La quota per max-pods-per-node deve essere impostata almeno sul numero massimo di nodi GKE che prevedi di creare.

Per richiedere un aumento della quota, consulta Richiedi un aggiustamento delle quote.

Prepara l'applicazione TPU

I workload TPU hanno i seguenti requisiti di preparazione.

  1. Framework come JAX, PyTorch e TensorFlow accedono alle VM TPU utilizzando la libreria condivisa libtpu. 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 evitare conflitti tra le versioni dei pacchetti, ti consigliamo di utilizzare un'immagine JAX AI. Per utilizzare le TPU in GKE, assicurati di utilizzare le seguenti versioni: tpu7x
    Tipo di TPU libtpu.so versione
    Ironwood (TPU7x)
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. Nel manifest del workload, aggiungi i selettori dei nodi Kubernetes per assicurarti che GKE pianifichi il workload 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
    cloud.google.com/placement-policy-name: WORKLOAD_POLICY # Required only for Ironwood (TPU7x)

    Sostituisci quanto segue:

    • TPU_ACCELERATOR: il nome dell'acceleratore TPU. Ad esempio, utilizza tpu7x-standard-4t.
    • TPU_TOPOLOGY: la topologia fisica per la sezione TPU. Il formato della topologia dipende dalla versione della TPU. Ad esempio, utilizza 2x2x2. Per saperne di più, consulta Pianificare le TPU in GKE.
    • WORKLOAD_POLICY: il nome della policy del workload che vuoi utilizzare per posizionare i pod di TPU. Questo selettore di nodi è richiesto solo per Ironwood (TPU7x).

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

Opzioni per il provisioning delle TPU in GKE

Per eseguire il provisioning delle TPU in GKE, hai a disposizione le seguenti opzioni di configurazione:
  • Richiesta del carico di lavoro: specifichi la versione e la topologia della TPU nel campo spec.nodeSelector e il numero di chip TPU nella sezione spec.containers.resources. Quando esegui il deployment del workload, GKE esegue automaticamente il provisioning dei nodi con la configurazione TPU corretta e posiziona ogni workload sul proprio nodo dedicato per garantire l'accesso completo alle risorse del nodo. Per istruzioni, consulta la sezione Richiedere TPU in un carico di lavoro.

    • Esegui il provisioning centralizzato delle TPU con classi di computing personalizzate

    Le sezioni seguenti mostrano come creare una ComputeClass personalizzata e poi creare un job che utilizzi le TPU definite in ComputeClass.

    Crea una classe ComputeClass personalizzata

    I passaggi per creare una ComputeClass personalizzata che rispetti le regole della TPU variano a seconda che utilizzi Ironwood (TPU7x) o una versione precedente della TPU.

    Ironwood (TPU7x)

    1. Crea una policy del workload. Questo passaggio è obbligatorio solo se stai creando un pool di nodi multihost, che dipende dalla topologia che scegli. Se utilizzi un pool di nodi single-host, salta questo passaggio.

      gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

      Sostituisci quanto segue:

      • WORKLOAD_POLICY_NAME: un nome per la policy del workload.
      • TPU_TOPOLOGY: la topologia TPU Ironwood (TPU7x). Ad esempio, utilizza 2x2x2. Per maggiori informazioni su tutte le topologie Ironwood (TPU7x) supportate, consulta la sezione relativa alla topologia.
      • PROJECT_ID: l'ID progetto Google Cloud .
      • REGION: la regione della policy del workload. Una policy del workload è una risorsa di regione e puoi utilizzarla in tutti i pool di nodi.

    2. Salva il seguente manifest come tpu-compute-class.yaml:

      apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
    - tpu:
        type: tpu7x
        topology: TPU_TOPOLOGY
        count: 4
      placement:
        policyName: WORKLOAD_POLICY_NAME
  nodePoolAutoCreation:
    enabled: true

    3. (Facoltativo) Puoi utilizzare una prenotazione o un blocco secondario specifico. Ad esempio, puoi aggiungere il seguente specs al manifest ComputeClass:

        reservations:
    affinity: Specific
    specific:
      - name: RESERVATION_NAME
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
          reservationSubBlock:
            name: RESERVATION_SUB_BLOCK_NAME

      Sostituisci quanto segue:

      • RESERVATION_NAME: il nome della prenotazione della capacità di Compute Engine.
      • RESERVATION_BLOCK_NAME: il nome del blocco di prenotazione della capacità di Compute Engine.
      • RESERVATION_SUB_BLOCK_NAME: il nome del sub-block di prenotazione della capacità di Compute Engine.

      Per saperne di più, consulta Utilizzo di risorse di zona prenotate.

    Altre versioni di TPU

    Per eseguire il provisioning di TPU v3, v4, v5p, v5e o v6e (Trillium) utilizzando una classe ComputeClass personalizzata configurata per le TPU, completa i seguenti passaggi:

    1. Salva il seguente manifest come tpu-compute-class.yaml:

      apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - spot: true
    tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - flexStart:
      enabled: true
    tpu:
      type: TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  nodePoolAutoCreation:
    enabled: true

      Sostituisci quanto segue:

      • TPU_TYPE: il tipo di TPU da utilizzare, ad esempio tpu-v4-podslice. Deve essere un valore supportato da GKE.
      • TOPOLOGY: la disposizione dei chip TPU nella slice, ad esempio 2x2x4. Deve essere una topologia supportata per il tipo di TPU selezionato.
      • NUMBER_OF_CHIPS: il numero di chip TPU da utilizzare per il container. Deve essere lo stesso valore per limits e requests.

    2. Esegui il deployment di ComputeClass:

      kubectl apply -f tpu-compute-class.yaml

      Per ulteriori informazioni sulle classi ComputeClass e sulle TPU personalizzate, consulta Configurazione TPU.

    Crea un job che utilizza le TPU

    1. Salva il seguente manifest come tpu-job.yaml:

      apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/compute-class: tpu-class
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

      Sostituisci quanto segue:

      • NUMBER_OF_CHIPS: il numero di chip TPU da utilizzare per il container. Deve essere lo stesso valore per limits e requests, uguale al valore CHIP_COUNT nella classe ComputeClass personalizzata selezionata.
      • MEMORY_SIZE: la quantità massima di memoria utilizzata dalla TPU. I limiti di memoria dipendono dalla versione e dalla topologia della TPU che utilizzi. Per saperne di più, consulta Valori minimi e massimi per gli acceleratori.
      • NUMBER_OF_CHIPS: il numero di chip TPU da utilizzare per il container. Deve essere lo stesso valore per limits e requests.

    2. Esegui il deployment del job:

      kubectl create -f tpu-job.yaml

      Quando crei questo job, GKE esegue automaticamente le seguenti operazioni:

      • Esegue il provisioning dei nodi per eseguire i pod. A seconda del tipo di TPU, della topologia e delle richieste di risorse che hai specificato, questi nodi sono sezioni single-host o multi-host. A seconda della disponibilità delle risorse TPU nella priorità più alta, GKE potrebbe eseguire il failover a priorità inferiori per massimizzare la flessibilità, l'efficienza e la disponibilità della capacità dell'acceleratore.
      • Aggiunge incompatibilità ai pod e tolleranze ai nodi per impedire l'esecuzione di altri carichi di lavoro sugli stessi nodi dei carichi di lavoro TPU.

      Per saperne di più, consulta Informazioni sulle classi di computing personalizzate.

    3. Al termine di questa sezione, puoi evitare l'addebito di ulteriori costi eliminando le risorse create:

      kubectl delete -f tpu-job.yaml

    Richiedere TPU in un workload

    Questa sezione mostra come creare un job che richiede TPU in Autopilot. In qualsiasi workload che richiede TPU, devi specificare quanto segue:

    • Selettori di nodi per la versione e la topologia TPU
    • Il numero di chip TPU per un container nel tuo carico di lavoro

    Per un elenco delle versioni e delle topologie TPU supportate e del numero corrispondente di chip e nodi TPU in una sezione, consulta Scegli la versione TPU.

    Considerazioni per le richieste TPU nei workload

    Solo un container in un pod può utilizzare le TPU. Il numero di chip TPU richiesti da un container deve essere uguale al numero di chip TPU collegati a un nodo nella sezione. Ad esempio, se richiedi TPU v5e (tpu-v5-lite-podslice) con una topologia 2x4, puoi richiedere una delle seguenti:

    • Chip 4, che creano due nodi multi-host con 4 chip TPU ciascuno
    • Chip 8, che crea un nodo host singolo con 8 chip TPU

    Come best practice per massimizzare l'efficienza dei costi, utilizza sempre tutta la TPU nello slice che richiedi. Se richiedi una sezione multi-host di due nodi con 4 chip TPU ciascuno, devi eseguire il deployment di un workload che viene eseguito su entrambi i nodi e utilizza tutti gli 8 chip TPU nella sezione.

    Crea un workload che richieda TPU

    I passaggi seguenti creano un job che richiede TPU. Se hai carichi di lavoro che vengono eseguiti su sezioni TPU multi-host, devi anche creare un servizio headless che selezioni il tuo carico di lavoro per nome. Questo servizio headless consente ai pod su nodi diversi nella sezione multihost di comunicare tra loro aggiornando la configurazione DNS di Kubernetes in modo che punti ai pod nel workload.

    1. Salva il seguente manifest come tpu-autopilot.yaml:

      apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job
spec:
  backoffLimit: 0
  parallelism: NUM_OF_VMS
  completions: NUM_OF_VMS
  completionMode: Indexed
  template:
    spec:
      # Optional: Run in GKE Sandbox
      # runtimeClassName: gvisor
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: TPU_TYPE
        cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
        topology.kubernetes.io/zone: LOCATION
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
        resources:
          requests:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: MEMORY_SIZE
            google.com/tpu: NUMBER_OF_CHIPS

      Sostituisci i seguenti valori in questo ordine:

      1. TPU_TYPE: scegli la versione TPU da utilizzare, ad esempio tpu-v5-lite-podslice. Il valore deve essere supportato da GKE.
      2. LOCATION: valida la zona in cui GKE posiziona le VM TPU.

        (Facoltativo) Utilizza una zona AI, ad esempio us-central1-ai1a. Le zone AI sono località specializzate ottimizzate per i workload AI/ML all'interno delle Google Cloud regioni.

      3. TPU_TOPOLOGY: scegli la disposizione dei chip TPU nella fetta, ad esempio 4x4. La topologia deve essere supportata per il tipo di TPU selezionato.
      4. Trova TPU_TYPE e TPU_TOPOLOGY selezionati nella tabella della sezione Scegli una topologia:
        • NUM_OF_VMS: utilizza il valore della colonna "Numero di VM" nella colonna "Specifiche tecniche". Imposta questo valore per i campi parallelism e completions nella specifica del job.
        • NUMBER_OF_CHIPS: inserisci il numero di chip per VM. Calcola questo valore dividendo il valore in "Numero di chip TPU per la topologia" per il valore in "Numero di VM" per la riga selezionata. Imposta questo valore per la richiesta di risorse google.com/tpu.
      5. MEMORY_SIZE: la quantità massima di memoria utilizzata dalla TPU. I limiti di memoria dipendono dalla versione e dalla topologia della TPU che utilizzi. Per saperne di più, consulta Valori minimi e massimi per gli acceleratori.

      Se vuoi, puoi anche modificare i seguenti campi:

      • image: definisce l'immagine AI JAX da utilizzare. Il manifest di esempio imposta questo campo sull'ultima immagine JAX AI. Per impostare una versione diversa, consulta l'elenco delle immagini AI JAX attuali.
      • runtimeClassname: gvisor: utilizza questo flag per eseguire questo pod in GKE Sandbox. Per utilizzarla, rimuovi il commento da questa riga. GKE Sandbox supporta le TPU versione v4 e successive. Per saperne di più, consulta Sandbox GKE.

      Ad esempio, considera un tpu-v5-lite-podslice con una topologia 4x4. Questa configurazione significa che:

      • La topologia ha 16 chip in totale (4*4=16).
      • tpu-v5-lite-podslice viene implementato in macchine ct5lp-hightpu-4t che hanno quattro chip per VM. Ciò significa che per avere una topologia 4x4, devi avere quattro VM (16/4=4). Pertanto, imposta i campi parallelism e completions su 4.
      • Ogni container nel pod richiede quattro chip TPU, che corrispondono al numero di chip per VM. Il file manifest lo specifica con la riga google.com/tpu: 4.

    2. Esegui il deployment del job:

      kubectl create -f tpu-autopilot.yaml

      Quando crei questo job, GKE esegue automaticamente le seguenti operazioni:

      1. Esegue il provisioning dei nodi per eseguire i pod. A seconda del tipo di TPU, della topologia e delle richieste di risorse specificate, questi nodi sono sezioni single-host o multi-host.
      2. Aggiunge incompatibilità ai pod e tolleranze ai nodi per impedire l'esecuzione di altri carichi di lavoro sugli stessi nodi dei carichi di lavoro TPU.

    3. Al termine di questa sezione, puoi evitare l'addebito di ulteriori costi eliminando il carico di lavoro che hai creato:

      kubectl delete -f tpu-autopilot.yaml

    Crea un workload che richiede TPU e pianificazione delle raccolte

    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 nodil 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 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.
    • Slice TPU single-host:GKE considera l'intero pool di nodi slice TPU single-host come una raccolta. Per aggiungere altre slice TPU alla raccolta, puoi ridimensionare il pool di nodi di slice TPU single-host.

    Per informazioni sulla limitazione della pianificazione della raccolta, vedi Come funziona la pianificazione della raccolta

    Utilizza una sezione TPU multi-host

    La pianificazione della raccolta nei nodi slice TPU multi-host è disponibile per i cluster Autopilot nella versione 1.31.2-gke.1537000 e successive. I nodi slice TPU multi-host con topologia 2x4 sono supportati solo nella versione 1.31.2-gke.1115000 o successive. Per creare nodi di sezioni TPU multi-host e raggrupparli in una raccolta, aggiungi le seguenti etichette Kubernetes alla specifica del workload:

    • cloud.google.com/gke-nodepool-group-name: ogni raccolta deve avere un nome univoco a livello di cluster. Il valore nell'etichetta cloud.google.com/gke-nodepool-group-name deve rispettare i requisiti per le etichette dei cluster.

    • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY

      Ad esempio, il seguente blocco di codice definisce una raccolta con una sezione TPU multi-host:

        nodeSelector:
    cloud.google.com/gke-nodepool-group-name: ${COLLECTION_NAME}
    cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
    cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
    cloud.google.com/gke-tpu-topology: 4x4
...

    Utilizza una sezione TPU single-host

    La pianificazione della raccolta nei nodi delle sezioni TPU a host singolo è disponibile per i cluster Autopilot nella versione 1.31.2-gke.1088000 e successive. Per creare nodi slice TPU a singolo host e raggrupparli come raccolta, aggiungi l'etichetta cloud.google.com/gke-workload-type:HIGH_AVAILABILITY nella specifica del workload.

    Ad esempio, il seguente blocco di codice definisce una raccolta con uno slice TPU single-host:

      nodeSelector:
    cloud.google.com/gke-tpu-accelerator: tpu-v6e-slice
    cloud.google.com/gke-tpu-topology: 2x2
    cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
  ...

    Utilizza classi di computing personalizzate per eseguire il deployment di una raccolta

    Per saperne di più sul deployment di un workload che richiede la pianificazione della raccolta e del workload TPU utilizzando classi di computing personalizzate, consulta Raccolta multi-host TPU e Definisci il tipo di workload per lo SLO TPU.

    Esempio: visualizza il numero totale di chip TPU in uno slice multi-host

    Il seguente workload restituisce il numero di chip TPU in tutti i nodi di uno slice TPU multi-host. Per creare una sezione multi-host, il workload ha i seguenti parametri:

    • Versione TPU: TPU v4
    • Topologia: 2x2x4

    La selezione di questa versione e di questa topologia genera 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 # Node selector to target TPU v4 slice nodes.
        cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8471 # Default port using which TPU VMs communicate
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
        resources:
          requests:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Request 4 TPU chips for this workload.
          limits:
            cpu: 10
            memory: 407Gi
            google.com/tpu: 4 # Limit to 4 TPU chips for this workload.
    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
    5. (Facoltativo) Rimuovi il workload: 
      kubectl delete -f available-chips-multihost.yaml

    Esempio: visualizza i chip TPU in un singolo nodo

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

    • Versione TPU: TPU v5e
    • Topologia: 2x4

    Questa selezione di versione e topologia comporta una sezione a singolo 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 # Node selector to target TPU v5e slice nodes.
    cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
  containers:
  - name: tpu-job
    image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
    ports:
    - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
    command:
    - bash
    - -c
    - |
      python -c 'import jax; print("Total TPU chips:", jax.device_count())'
    resources:
      requests:
        google.com/tpu: 8 # Request 8 TPU chips for this container.
      limits:
        google.com/tpu: 8 # Limit to 8 TPU chips for this container.
    2. Esegui il deployment del manifest: 
      kubectl create -f available-chips-singlehost.yaml

      GKE esegue il provisioning dei nodi con otto sezioni TPU single-host che utilizzano TPU v5e. Ogni nodo TPU ha otto chip TPU (slice TPU single-host).

    3. Recupera i log del pod: 
      kubectl logs tpu-job-jax-v5

      L'output è simile al seguente: 

      Total TPU chips: 8
    4. (Facoltativo) Rimuovi il workload: 
        kubectl delete -f available-chips-singlehost.yaml

    Osserva e monitora le TPU

    Dashboard

    L'osservabilità dei node pool nella consoleGoogle Cloud è in disponibilità generale. Per visualizzare lo stato dei tuoi pool di nodi multi-host TPU su GKE, vai alla dashboard Stato del pool di nodi TPU GKE fornita da Cloud Monitoring:

    Vai a Stato del node pool TPU GKE

    Questa dashboard fornisce informazioni complete sull'integrità dei tuoi node pool TPU multi-host. Per saperne di più, consulta Monitora le metriche di integrità per i nodi TPU e i pool di nodi.

    Nella pagina Cluster Kubernetes della consoleGoogle Cloud , la scheda Osservabilità mostra anche le metriche di osservabilità di TPU, come l'utilizzo di TPU, nell'intestazione Acceleratori > TPU. Per saperne di più, consulta Visualizzare le metriche di osservabilità.

    La dashboard TPU viene compilata solo se hai abilitato le metriche di sistema nel 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 della TPU come metriche di sistema GKE. In Cloud Monitoring sono disponibili le seguenti metriche per monitorare le prestazioni di runtime del workload TPU:

    • Ciclo di lavoro: percentuale di tempo nell'ultimo periodo di campionamento (60 secondi) durante il quale i Tensor Core hanno eseguito attivamente l'elaborazione su un chip TPU. Una percentuale maggiore indica un migliore utilizzo della TPU.
    • Memoria utilizzata: quantità di memoria dell'acceleratore allocata in byte. Campionamento eseguito ogni 60 secondi.
    • Memoria totale: memoria totale dell'acceleratore 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

    Monitora le metriche di integrità per i nodi TPU e i pool di nodi

    Quando un job di addestramento presenta un errore o termina con un errore, puoi controllare le metriche relative all'infrastruttura sottostante per capire se l'interruzione è stata causata da un problema con il nodo o il pool di nodi sottostante.

    Stato nodo

    In GKE versione 1.32.1-gke.1357001 o successive, la seguente metrica di sistema GKE mostra la condizione di un nodo GKE:

    • kubernetes.io/node/status_condition

    Il campo condition riporta le condizioni del nodo, ad esempio Ready, DiskPressure e MemoryPressure. Il campo status mostra lo stato segnalato della condizione, che può essere True, False o Unknown. Si tratta di una metrica con il tipo di risorsa monitorata k8s_node.

    Questa query PromQL mostra se un determinato nodo è Ready:

    kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

    Per risolvere i problemi in un cluster, potresti voler esaminare i nodi che hanno mostrato altre condizioni:

    kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

    Potresti voler esaminare in modo specifico i nodi che non sono Ready:

    kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

    Se non sono presenti dati, i nodi sono pronti. La condizione di stato viene campionata ogni 60 secondi.

    Puoi utilizzare la seguente query per comprendere lo stato dei nodi in tutto il parco risorse:

    avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

    Stato del node pool

    La seguente metrica di sistema GKE per la risorsa monitorata k8s_node_pool mostra lo stato di unpool di nodil GKE:

    • kubernetes.io/node_pool/status

    Questa metrica viene segnalata solo per i node pool TPU multi-host.

    Il campo status indica lo stato del pool di nodi, ad esempio Provisioning, Running, Error, Reconciling o Stopping. Gli aggiornamenti dello stato vengono eseguiti al termine delle operazioni dell'API GKE.

    Per verificare se un determinato pool di nodi ha lo stato Running, utilizza la seguente query PromQL:

    kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

    Per monitorare il numero di pool di nodi nel tuo progetto raggruppati in base al loro stato, utilizza la seguente query PromQL:

    count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

    Disponibilità del node pool

    La seguente metrica di sistema GKE mostra se un pool di nodi TPU multi-host è disponibile:

    • kubernetes.io/node_pool/multi_host/available

    La metrica ha un valore pari a True se tutti i nodi nel pool di nodi sono disponibili, e False in caso contrario. La metrica viene campionata ogni 60 secondi.

    Per controllare la disponibilità dei node pool TPU multi-host nel tuo progetto, utilizza la seguente query PromQL:

    avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

    Conteggio interruzioni nodi

    La seguente metrica di sistema GKE riporta il conteggio delle interruzioni per un nodo GKE dall'ultimo campione (la metrica viene campionata ogni 60 secondi):

    • kubernetes.io/node/interruption_count

    I campi interruption_type (ad esempio TerminationEvent, MaintenanceEvent o PreemptionEvent) e interruption_reason (come HostError, Eviction o AutoRepair) possono aiutarti a capire il motivo per cui un nodo è stato interrotto.

    Per ottenere una suddivisione delle interruzioni e delle relative cause nei nodi TPU nei cluster del tuo progetto, utilizza la seguente query PromQL:

      sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

    Per visualizzare solo gli eventi di manutenzione dell'host, aggiorna la query per filtrare il valore HW/SW Maintenance per interruption_reason. Utilizza la seguente query PromQL:

      sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

    Per visualizzare il conteggio delle interruzioni aggregate per pool di nodi, utilizza la seguente query PromQL:

      sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

    Tempi di ripristino (TTR) del node pool

    La seguente metrica di sistema GKE riporta la distribuzione delle durate del periodo di recupero per i node pool TPU multi-host GKE:

    • kubernetes.io/node_pool/accelerator/times_to_recover

    Ogni campione registrato in questa metrica indica un singolo evento di recupero del pool di nodi da un periodo di inattività.

    Questa metrica è utile per monitorare il tempo di recupero e il tempo tra le interruzioni del pool di nodi TPU multi-host.

    Puoi utilizzare la seguente query PromQL per calcolare il tempo medio di ripristino (MTTR) degli ultimi 7 giorni nel tuo cluster:

    sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

    Tempo tra le interruzioni (TBI) del node pool

    La seguente metrica di sistema GKE riporta la distribuzione dei tempi tra la fine dell'interruzione più recente e l'inizio dell'interruzione corrente per i node pool TPU multi-host GKE:

    • kubernetes.io/node_pool/accelerator/times_between_interruptions

    Ogni campione registrato in questa metrica indica una singola durata tra l'interruzione più recente e quella attuale.

    Utilizza la seguente query PromQL per calcolare il tempo medio tra le interruzioni (MTBI) nel tuo cluster per i 7 giorni precedenti:

    sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_between_interruptions_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_between_interruptions_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

    Metriche host

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

    • Utilizzo di TensorCore: 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 eseguite nel periodo di campionamento precedente (60 secondi) per il numero di operazioni TensorCore supportate nello stesso periodo. Un valore più alto indica un utilizzo migliore.
    • Utilizzo larghezza di banda memoria: percentuale attuale della larghezza di banda della memoria dell'acceleratore in uso. Questo valore viene calcolato dividendo la larghezza di banda della memoria utilizzata 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/node/accelerator/tensorcore_utilization
    • kubernetes.io/node/accelerator/memory_bandwidth_utilization

    Per saperne di più, consulta Metriche di Kubernetes e Metriche di sistema GKE.

    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.

    Consigli per i carichi di lavoro TPU in Autopilot

    I seguenti suggerimenti potrebbero migliorare l'efficienza dei tuoi workload TPU:

    • Utilizza i pod con tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima che GKE termini i pod per lo scale down o l'upgrade dei nodi. Puoi utilizzare periodi di manutenzione ed esclusioni con pod con runtime esteso per ritardare ulteriormente gli upgrade automatici dei nodi.
    • Utilizza le prenotazioni di capacità per garantire che i tuoi workload ricevano le TPU richieste senza essere inseriti in una coda per la disponibilità.

    Evitare deadlock di pianificazione

    Quando esegui più job TPU o più repliche di un job, i pod di job diversi possono essere pianificati nello stesso pool di nodi TPU. Ciò può causare un deadlock di pianificazione in cui nessuno dei job può proteggere un numero sufficiente di nodi per completare la propria topologia.

    Per ridurre il rischio di deadlock di pianificazione, applica una delle seguenti configurazioni:

    • Utilizza le regole di anti-affinità dei pod per assicurarti che i pod di job diversi non vengano pianificati nello stesso pool di nodi TPU o nello stesso dominio di topologia.
    • Utilizza l'annotazione jobset.sigs.k8s.io/exclusive-topology, che fa sì che JobSet rivendichi il dominio di topologia specificato (come un pool di nodi) esclusivamente per i propri pod.

    Per esempi di configurazione dettagliati e passaggi per la risoluzione dei problemi, consulta Deadlock di pianificazione.

    Passaggi successivi