Esegui il deployment dei carichi di lavoro TPU in GKE Standard

Standard

---

Questa pagina mostra come richiedere ed eseguire il deployment di carichi di lavoro di addestramento, ottimizzazione e inferenza di modelli di intelligenza artificiale (AI) e machine learning (ML) su larga scala utilizzando acceleratori TPU (TPU) Cloud TPU nei cluster Google Kubernetes Engine (GKE) Standard.

Prima di configurare ed eseguire il deployment di carichi di lavoro TPU in GKE, dovresti conoscere i seguenti concetti:

1. Introduzione a Cloud TPU.
2. Architettura di sistema Cloud TPU.
3. Informazioni sulle TPU in GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti località predefinite, puoi evitare errori in gcloud CLI, come quelli che seguono: One of [--zone, --region] must be supplied: Please specify location.

Disponibilità di TPU in GKE

Utilizza GKE per creare e gestire i pool di nodi con TPU. Puoi utilizzare questi acceleratori appositamente creati per eseguire l'addestramento, l'ottimizzazione e l'inferenza di modelli AI su larga scala.

Consulta un elenco delle versioni di TPU supportate in GKE.

Pianifica la configurazione di TPU

Pianifica la configurazione della TPU in base al modello di machine learning e alla quantità di memoria necessaria. Di seguito sono riportati i passaggi pertinenti per la pianificazione della configurazione di TPU:

1. Seleziona una versione e una topologia di TPU.
2. Seleziona il tipo di pool di nodi da utilizzare.

Assicurati di avere una quota sufficiente per le VM on demand o spot

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

La creazione di un pool di nodi della sezione TPU che utilizza una prenotazione TPU non richiede quota TPU.¹ Puoi saltare questa sezione per le TPU prenotate.

La creazione di un pool di nodi della sezione TPU on demand o Spot in GKE richiede una quota per l'API Compute Engine. La quota per l'API Compute Engine (compute.googleapis.com) è diversa dalla quota per l'API Cloud TPU (tpu.googleapis.com), necessaria per la creazione di TPU con l'API Cloud TPU.

Per controllare il limite e l'utilizzo attuale della tua 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 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 e al tipo di macchina della TPU. 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 Spot^2
      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

   4. 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 della sezione TPU nella zona us-west4-a. La quota TPU è a livello di regione, pertanto tutte le zone all'interno della stessa regione utilizzano la stessa quota TPU.

Se nessuna quota corrisponde al filtro inserito, al progetto non è stata concessa nessuna della quota specificata per la regione desiderata e devi richiedere un aumento della quota di TPU.

Nota :quando viene creata una prenotazione TPU, sia il limite sia i valori di utilizzo attuali per la quota corrispondente aumentano del numero di chip nella prenotazione di TPU. Ad esempio, quando viene creata una prenotazione per 16 chip TPU v5e il cui tipo di macchina inizia con ct5lp-, sia Limite che Utilizzo attuale per la quota TPU v5 Lite PodSlice chips nella regione pertinente aumentano di 16.

1. Quando crei un pool di nodi della sezione TPU, utilizza i flag --reservation e --reservation-affinity=specific per creare unistanza dedicata. Le prenotazioni TPU sono disponibili quando acquisti un impegno. ↩

2. Quando crei un pool di nodi della sezione TPU, utilizza il flag --spot per creare un'istanza Spot. ↩

Assicurati la disponibilità della prenotazione

La creazione di un pool di nodi della sezione TPU riservato, che utilizza una prenotazione, non richiede una quota TPU. Tuttavia, la prenotazione deve avere un numero sufficiente di chip TPU disponibili o utilizzati al momento della creazione del pool di nodi.

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

Per visualizzare quanti chip TPU sono disponibili in una prenotazione TPU, visualizza i dettagli di una prenotazione.

crea un cluster

Creare un cluster GKE in modalità Standard in una regione con le TPU disponibili. Ti consigliamo di utilizzare cluster a livello di regione, che offrono l'alta disponibilità del piano di controllo Kubernetes. Puoi utilizzare Google Cloud CLI o la console Google Cloud.

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 GKE, che deve supportare il tipo di macchina che vuoi utilizzare. Tieni presente che la versione GKE predefinita potrebbe non avere disponibilità per la TPU di destinazione. Per sapere quali sono le versioni GKE minime disponibili per tipo di macchina TPU, consulta Disponibilità delle TPU in GKE

Crea un pool di nodi

Sezione TPU con host singolo

Puoi creare un pool di nodi della sezione TPU con host singolo utilizzando Google Cloud CLI, Terraform o la console Google Cloud.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--num-nodes=NUM_NODES \]
    [--spot \]
    [--enable-autoscaling \]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME \]
    [--total-min-nodes TOTAL_MIN_NODES \]
    [--total-max-nodes TOTAL_MAX_NODES \]
    [--location-policy=ANY]

Sostituisci quanto segue:

• POOL_NAME: il nome del nuovo pool di nodi.

• LOCATION: il nome della zona in base alla versione della TPU che vuoi utilizzare:

  • Per TPU v4, usa us-central2-b.
  • Per i tipi di macchine TPU v5e che iniziano con ct5l-, utilizza us-central1-a o europe-west4-b.
  • Per i tipi di macchine TPU v5e che iniziano con ct5lp-, utilizza us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b o europe-west4-a.
  • Per TPU v5p, usa us-east1-d, us-east5-a o us-east5-c.

  Per scoprire di più, consulta Disponibilità delle TPU in GKE.

• CLUSTER_NAME: il nome del cluster.

• NODE_ZONE: l'elenco separato da virgole di una o più zone in cui GKE crea il pool di nodi.

• MACHINE_TYPE: il tipo di macchina da utilizzare per i nodi. Per ulteriori informazioni sui tipi di macchine compatibili con TPU, utilizza la tabella in Mappatura della configurazione TPU.

Facoltativamente, puoi anche utilizzare i seguenti flag:

• NUM_NODES: il numero iniziale di nodi nel pool di nodi in ogni zona. Se ometti questo flag, il valore predefinito è 3. Se la scalabilità automatica è abilitata per il pool di nodi utilizzando il flag --enable-autoscaling, ti consigliamo di impostare NUM_NODES su 0, poiché il gestore della scalabilità automatica esegue il provisioning di nodi aggiuntivi non appena i tuoi carichi di lavoro li richiedono.
• RESERVATION_NAME: il nome della prenotazione utilizzata da GKE durante la creazione del pool di nodi. Se ometti questo flag, GKE utilizza le TPU disponibili. Per scoprire di più sulle prenotazioni TPU, consulta la pagina relativa alla prenotazione TPU.
• --enable-autoscaling: crea un pool di nodi con scalabilità automatica abilitata.
  • TOTAL_MIN_NODES: numero minimo di tutti i nodi nel pool di nodi. Ometti questo campo a meno che non venga specificata anche la scalabilità automatica.
  • TOTAL_MAX_NODES: numero massimo di tutti i nodi nel pool di nodi. Ometti questo campo a meno che non venga specificata anche la scalabilità automatica.
• --spot: imposta il pool di nodi in modo che utilizzi VM spot per i nodi nel pool di nodi. Questo valore non può essere modificato dopo la creazione del pool di nodi.

Terraform

1. Assicurati di utilizzare la versione 4.84.0 o successive del provider google.
2. Aggiungi il blocco seguente alla tua configurazione Terraform:

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]
  initial_node_count = NUM_NODES
  autoscaling {
    total_min_node_count = TOTAL_MIN_NODES
    total_max_node_count = TOTAL_MAX_NODES
    location_policy      = "ANY"
  }

  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
  }
}

Sostituisci quanto segue:

• NODE_POOL_RESOURCE_NAME: il nome della risorsa del pool di nodi nel modello Terraform.
• PROJECT_ID: l'ID progetto.
• CLUSTER_NAME: il nome del cluster esistente.
• POOL_NAME: il nome del pool di nodi da creare.
• CLUSTER_LOCATION: le zona di computing del cluster. Specifica la regione in cui è disponibile la versione di TPU. Per scoprire di più, consulta Selezionare una versione e una topologia di TPU.
• NODE_ZONES: l'elenco separato da virgole di una o più zone in cui GKE crea il pool di nodi.
• NUM_NODES: il numero iniziale di nodi nel pool di nodi in ciascuna zona del pool di nodi. Se omesso, il valore predefinito è 3. Se la scalabilità automatica è abilitata per il pool di nodi utilizzando il modello di scalabilità automatica, ti consigliamo di impostare NUM_NODES su 0, poiché GKE esegue il provisioning di nodi della sezione TPU aggiuntivi non appena il carico di lavoro li richiede.
• MACHINE_TYPE: il tipo di macchina TPU da utilizzare. Per vedere i tipi di macchine compatibili con TPU, utilizza la tabella in Mappatura della configurazione TPU.

Facoltativamente, puoi anche utilizzare le seguenti variabili:

• autoscaling: crea un pool di nodi con scalabilità automatica abilitata. Per una sezione TPU con host singolo, GKE scala tra i valori TOTAL_MIN_NODES e TOTAL_MAX_NODES.
  • TOTAL_MIN_NODES: numero minimo di tutti i nodi nel pool di nodi. Questo campo è facoltativo, a meno che non venga specificata anche la scalabilità automatica.
  • TOTAL_MAX_NODES: numero massimo di tutti i nodi nel pool di nodi. Questo campo è facoltativo, a meno che non venga specificata anche la scalabilità automatica.
• RESERVATION_NAME: se utilizzi la prenotazione TPU, questo è l'elenco di etichette delle risorse di prenotazione da utilizzare durante la creazione del pool di nodi. Per scoprire di più su come compilare RESERVATION_LABEL_VALUES nel campo reservation_affinity, consulta Provider Terraform.
• spot: imposta il pool di nodi in modo da utilizzare le VM spot per i nodi TPU. Questo valore non può essere modificato dopo la creazione del pool di nodi. Per ulteriori informazioni, consulta VM spot.

Console

Per creare un pool di nodi con TPU:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. Fai clic su Aggiungi pool di nodi.

4. Nella sezione Dettagli del pool di nodi, seleziona la casella Specifica le località dei nodi.

5. Seleziona la zona in base alla versione della TPU che vuoi utilizzare:

   • Per TPU v4, usa us-central2-b.
   • Per i tipi di macchine TPU v5e che iniziano con ct5l-, utilizza us-central1-a o europe-west4-b.
   • Per i tipi di macchine TPU v5e che iniziano con ct5lp-, utilizza us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b o europe-west4-a.
   • Per TPU v5p, usa us-east1-d, us-east5-a o us-east5-c.

6. Nel riquadro di navigazione, fai clic su Nodi.

7. Nella sezione Configurazione macchina, seleziona TPU.

8. Nel menu a discesa Serie, seleziona una delle seguenti opzioni:

   • CT4P: TPU v4
   • CT5LP: TPU v5e
   • CT5P: TPU v5p

9. Nel menu a discesa Tipo di macchina, seleziona il nome della macchina da utilizzare per i nodi. Utilizza la tabella Mappatura della configurazione TPU per scoprire come definire il tipo di macchina e la topologia TPU che creano un pool di nodi della sezione TPU a host singolo.

10. Nel menu a discesa Topologia TPU, seleziona la topologia fisica per la sezione TPU.

11. Nella finestra di dialogo Modifiche necessarie, fai clic su Apporta modifiche.

12. Assicurati che il Tipo di disco di avvio sia Disco permanente standard o Disco permanente SSD.

13. (Facoltativo) Seleziona la casella di controllo Abilita nodi sulle VM spot per utilizzare le VM spot per i nodi nel pool di nodi.

14. Fai clic su Crea.

Sezione TPU multi-host

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

gcloud

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]

Sostituisci quanto segue:

• POOL_NAME: il nome del nuovo pool di nodi.

• LOCATION: il nome della zona in base alla versione della TPU che vuoi utilizzare:

  • Per TPU v4, usa us-central2-b.
  • I tipi di macchine TPU v5e che iniziano con ct5l- non sono mai multi-host.
  • Per i tipi di macchine TPU v5e che iniziano con ct5lp-, utilizza us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b o europe-west4-a.
  • Per i tipi di macchine TPU v5p che iniziano con ct5p-, usa us-east1-d, us-east5-a o us-east5-c.

  Per scoprire di più, consulta Disponibilità delle TPU in GKE.

• CLUSTER_NAME: il nome del cluster.

• NODE_ZONE: l'elenco separato da virgole di una o più zone in cui GKE crea il pool di nodi.

• MACHINE_TYPE: il tipo di macchina da utilizzare per i nodi. Per scoprire di più sui tipi di macchine disponibili, consulta la pagina Mappatura della configurazione di TPU.

• TPU_TOPOLOGY: la topologia fisica per la sezione TPU. Il formato della topologia dipende dalla versione di TPU, come segue:

  • TPU v4 o v5p: definisci la topologia in 3 tuple ({A}x{B}x{C}), ad esempio 4x4x4.
  • TPU v5e: definisci la topologia in due tuple ({A}x{B}), ad esempio 2x2.

  Per scoprire di più, consulta Topologia.

• NUM_NODES: il numero di nodi nel pool di nodi. Deve essere zero o il prodotto dei valori definiti in TPU_TOPOLOGY ({A}x{B}x{C}) diviso per il numero di chip in ogni VM. Per TPU v4 multi-host e TPU v5e, il numero di chip in ogni VM è quattro. Pertanto, se il valore di TPU_TOPOLOGY è 2x4x4 (TPU v4 con quattro chip in ogni VM), il NUM_NODES è 32/4, ovvero 8.

Facoltativamente, puoi anche utilizzare i seguenti flag:

• RESERVATION_NAME: il nome della prenotazione utilizzata da GKE durante la creazione del pool di nodi. Se ometti questo flag, GKE utilizza i pool di nodi della sezione TPU disponibili. Per scoprire di più sulle prenotazioni TPU, consulta la pagina relativa alla prenotazione TPU.
• --spot: imposta il pool di nodi in modo da utilizzare le VM spot per i nodi della sezione TPU. Questo valore non può essere modificato dopo la creazione del pool di nodi. Per ulteriori informazioni, consulta VM spot.
• --enable-autoscaling: crea un pool di nodi con scalabilità automatica abilitata. Quando GKE scala un pool di nodi di sezioni TPU multi-host, fa lo scale up atomicamente del pool di nodi da zero alla dimensione massima.
  • MAX_NODES: la dimensione massima del pool di nodi. Il flag --max-nodes è obbligatorio se viene fornito il valore --enable-autoscaling e deve essere uguale al prodotto dei valori definiti in TPU_TOPOLOGY ({A}x{B}x{C}) diviso per il numero di chip in ogni VM.

Terraform

1. Assicurati di utilizzare la versione 4.84.0 o successive del provider google.

2. Aggiungi il blocco seguente alla tua configurazione Terraform:

   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]
     initial_node_count = NUM_NODES
   
     autoscaling {
       max_node_count = MAX_NODES
       location_policy      = "ANY"
     }
     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
     }
   
     placement_policy {
       type = "COMPACT"
       tpu_topology = TPU_TOPOLOGY
     }
   }
   

   Sostituisci quanto segue:

   • NODE_POOL_RESOURCE_NAME: il nome della risorsa del pool di nodi nel modello Terraform.
   • PROJECT_ID: l'ID progetto.
   • CLUSTER_NAME: il nome del cluster esistente a cui aggiungere il pool di nodi.
   • POOL_NAME: il nome del pool di nodi da creare.
   • CLUSTER_LOCATION: località di calcolo del cluster. Consigliamo di avere un cluster a livello di regione per una maggiore affidabilità del piano di controllo Kubernetes. Puoi anche usare un cluster a livello di zona. Per scoprire di più, consulta Selezionare una versione e una topologia di TPU.
   • NODE_ZONES: l'elenco separato da virgole di una o più zone in cui GKE crea il pool di nodi.
   • NUM_NODES: il numero di nodi nel pool. Deve essere zero o il prodotto del numero dei chip TPU diviso per quattro, perché nelle sezioni TPU multi-host ogni nodo della sezione TPU ha 4 chip. Ad esempio, se TPU_TOPOLOGY è 4x8, ci sono 32 chip, il che significa che NUM_NODES deve essere 8. Per ulteriori informazioni sulle topologie TPU, utilizza la tabella in Mappatura della configurazione TPU.
   • TPU_TOPOLOGY: indica la topologia fisica voluta per la sezione TPU. Il formato della topologia dipende dalla versione della TPU in uso:
     • Per TPU v4: definisci la topologia in 3 tuple ({A}x{B}x{C}), ad esempio 4x4x4.
     • Per TPU v5e: definisci la topologia in 2 tuple ({A}x{B}), ad esempio 2x2.

   Facoltativamente, puoi anche utilizzare le seguenti variabili:

   • RESERVATION_NAME: se utilizzi la prenotazione TPU, questo è l'elenco di etichette delle risorse di prenotazione da utilizzare durante la creazione del pool di nodi. Per scoprire di più su come compilare RESERVATION_LABEL_VALUES nel campo reservation_affinity, consulta Provider Terraform.
   • autoscaling: crea un pool di nodi con scalabilità automatica abilitata. Quando GKE scala un pool di nodi di sezioni TPU multi-host, fa lo scale up atomicamente del pool di nodi da zero alla dimensione massima.
     • MAX_NODES: è la dimensione massima del pool di nodi. Deve essere uguale al prodotto dei valori definiti in TPU_TOPOLOGY ({A}x{B}x{C}) diviso per il numero di chip in ogni VM.
   • spot: consente al pool di nodi di utilizzare le VM spot per i nodi della sezione TPU. Questo valore non può essere modificato dopo la creazione del pool di nodi. Per maggiori informazioni, consulta VM spot.

Console

Per creare un pool di nodi con TPU:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. Fai clic su Aggiungi pool di nodi.

4. Nella sezione Dettagli del pool di nodi, seleziona la casella Specifica le località dei nodi.

5. Seleziona la zona in base alla versione della TPU che vuoi utilizzare:

   • Per TPU v4, usa us-central2-b.
   • I tipi di macchine TPU v5e che iniziano con ct5l- non sono mai multi-host.
   • Per i tipi di macchine TPU v5e che iniziano con ct5lp-, utilizza us-west1-c, us-west4-a, us-west4-b, us-central1-a, us-east1-c, us-east5-b o europe-west4-a.
   • Per i tipi di macchine TPU v5p che iniziano con ct5p-, usa us-east1-d, us-east5-a o us-east5-c.

6. Nel riquadro di navigazione, fai clic su Nodi.

7. Nella sezione Configurazione macchina, seleziona TPU.

8. Nel menu a discesa Serie, seleziona una delle seguenti opzioni:

   • CT4P: per TPU v4.
   • CT5LP: per TPU v5e.

9. Nel menu a discesa Tipo di macchina, seleziona il nome della macchina da utilizzare per i nodi. Utilizza la tabella Mappatura della configurazione TPU per scoprire come definire il tipo di macchina e la topologia TPU che creano un pool di nodi della sezione TPU multi-host.

10. Nel menu a discesa Topologia TPU, seleziona la topologia fisica per la sezione TPU.

11. Nella finestra di dialogo Modifiche necessarie, fai clic su Apporta modifiche.

12. Assicurati che il Tipo di disco di avvio sia Disco permanente standard o Disco permanente SSD.

13. (Facoltativo) Seleziona la casella di controllo Abilita i nodi sulle VM Spot per utilizzare le VM spot per i nodi nel pool di nodi.

14. Fai clic su Crea.

Stato provisioning

Se GKE non può creare il pool di nodi della sezione TPU a causa di una capacità TPU disponibile insufficiente, GKE 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 della sezione TPU con host singolo, il messaggio di errore è simile a questo:

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 della sezione TPU multi-host, il messaggio di errore sarà simile a questo:

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 tua richiesta di provisioning della TPU potrebbe rimanere in coda per molto tempo e rimanere in stato "Provisioning" mentre è in coda.

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

Se hai bisogno di capacità prima, puoi provare a utilizzare le VM spot, ma 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 della sezione TPU.

Esegui il carico di lavoro sui nodi sezione TPU

Preparazione del carico di lavoro

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

1. I 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 utilizzare le TPU in GKE, assicurati di utilizzare le seguenti versioni:

   Tipo di TPU	Versione di libtpu.so
   TPU v5e tpu-v5-lite-podslice tpu-v5-lite-device	Versione jax[tpu] consigliata: v0.4.9 o successiva Versione consigliata di torchxla[tpuvm]: v2.1.0 o successiva
   TPU v5p tpu-v5p-slice	Versione jax[tpu] consigliata: 0.4.19 o successive. Versione torchxla[tpuvm] consigliata: ti consigliamo di utilizzare una build notturna per il 23 ottobre 2023.
   TPU v4 tpu-v4-podslice	jax[tpu]: v0.4.4 o successiva torchxla[tpuvm]: v2.0.0 o successiva

2. Imposta le seguenti variabili di ambiente per il container che richiede le risorse TPU:
   • TPU_WORKER_ID: un numero intero univoco per ogni pod. Questo ID indica un ID worker univoco nella sezione 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 VM TPU o indirizzi IP che devono comunicare tra loro all'interno della sezione. Dovrebbe esserci un nome host o un indirizzo IP per ogni VM TPU nella sezione. L'elenco di indirizzi IP o nomi host è in ordine e non viene indicizzato da TPU_WORKER_ID.

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

   Durante il deployment di risorse multi-host TPU con Kuberay, GKE fornisce un webhook di cui è possibile eseguire il deployment come parte dei modelli Terraform per l'esecuzione di Ray su GKE. Le istruzioni per l'esecuzione di Ray su GKE con TPU sono disponibili nella guida dell'utente per TPU. Il webhook mutante inserisce queste variabili di ambiente nei cluster Ray che richiedono le 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:
       • Per TPU v4, usa tpu-v4-podslice
       • Per i tipi di macchine TPU v5e che iniziano con ct5l-, usa tpu-v5-lite-device
       • Per i tipi di macchine TPU v5e che iniziano con ct5lp-, usa tpu-v5-lite-podslice
       • Per TPU v5p, usa tpu-v5p-slice
     • TPU_TOPOLOGY: la topologia fisica per la sezione TPU. Il formato della topologia dipende dalla versione di TPU, come segue:
       • TPU v4: definisci la topologia in 3 tuple ({A}x{B}x{C}), ad esempio 4x4x4.
       • TPU v5e: definisci la topologia in due tuple ({A}x{B}), ad esempio 2x2.
       • TPU v5p: definisci la topologia in 3 tuple ({A}x{B}x{C}), ad esempio 4x4x4.

Dopo aver completato la preparazione del carico di lavoro, puoi eseguire un job che utilizza le TPU.

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

Esempio 1: eseguire un carico di lavoro che visualizza il numero di chip TPU disponibili in un pool di nodi della sezione TPU

Il seguente carico di lavoro restituisce il numero di chip TPU in tutti i nodi in una sezione TPU multi-host. Per creare una sezione con più host, il carico di lavoro prevede i seguenti parametri:

• Versione TPU: TPU v4
• Topologia: 2 x 2 x 4

Questa versione e selezione della topologia generano una sezione con più 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: eseguire un carico di lavoro che visualizza 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 host singolo, il carico di lavoro prevede i seguenti parametri:

• Versione TPU: TPU v5e
• Topologia: 2 x 4

Questa versione e selezione della topologia generano una sezione con host singolo.

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 dei nodi con otto sezioni TPU a host singolo che utilizzano TPU v5e. Ogni nodo TPU ha otto chip TPU (sezione TPU con host singolo).

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 acceleratori (GPU e TPU)

GKE esegue gli upgrade automatici dei cluster standard, inclusi i pool di nodi. Puoi anche eseguire l'upgrade manuale dei pool di nodi se vuoi che i nodi vengano aggiornati prima in una versione successiva. Per controllare il funzionamento degli upgrade per il tuo cluster, utilizza canali di rilascio, periodi di manutenzione ed esclusioni e sequenze di implementazione.

Puoi anche configurare una strategia di upgrade dei nodi per il tuo pool di nodi, ad esempio upgrade di sovraccarico o upgrade blu/verde. Configurando queste strategie, puoi garantire che l'upgrade dei pool di nodi venga eseguito in modo da raggiungere l'equilibrio ottimale tra velocità e interruzione per il tuo ambiente. Per i pool di nodi della sezione TPU multi-host, invece di utilizzare la strategia di upgrade dei nodi configurati, GKE ricrea a livello atomico l'intero pool di nodi in un unico passaggio. Per ulteriori informazioni, consulta la definizione di atomicità in Terminologia relativa alle TPU in GKE.

L'utilizzo di una strategia di upgrade dei nodi richiede temporaneamente GKE per 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, riscontri errori di disponibilità delle risorse quando cerchi di creare più 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 pool di nodi della sezione TPU che non hanno più carichi di lavoro pianificati. Se i carichi di lavoro in esecuzione devono essere terminati correttamente, utilizza kubectl drain per pulire i carichi di lavoro prima di eliminare il nodo.

1. Elimina un pool di nodi della sezione 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 località di computing del cluster.

Configurazioni aggiuntive

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

Più sezioni

Puoi aggregare le sezioni più piccole in una sezione multipla per gestire carichi di lavoro di addestramento più grandi. Per maggiori informazioni, consulta TPU multisezione in GKE.

Esegui la migrazione della prenotazione TPU

Se disponi di prenotazioni TPU esistenti, 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 di GKE, inviati a Logging e sono visibili in Logging.

Usa il provisioning automatico dei nodi GKE

Puoi configurare GKE in modo da creare ed eliminare automaticamente i pool di nodi per soddisfare le esigenze di risorse dei carichi di lavoro TPU. Per ulteriori informazioni, consulta Configurazione di Cloud TPU.

Riparazione automatica dei nodi della sezione TPU

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

Le condizioni che comportano nodi della sezione TPU non integro includono quanto segue:

• Qualsiasi nodo della sezione TPU con conditions comuni dei nodi.
• Qualsiasi nodo della sezione TPU con un numero di TPU non allocabili maggiore di zero.
• Qualsiasi istanza VM in una sezione TPU che è stata arrestata (a causa del prerilascio) o terminata.
• Manutenzione dei nodi: se un nodo della sezione TPU all'interno di un pool di nodi della sezione TPU multi-host non è disponibile per la manutenzione dell'host, GKE ricrea l'intero pool di nodi della sezione TPU.

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

Configura la terminazione controllata del nodo della sezione TPU

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Nei cluster GKE con il piano di controllo in esecuzione 1.29.1-gke.1425000 o versioni successive, i nodi della sezione TPU supportano indicatori SIGTERM che avvisano il nodo di un arresto imminente. La notifica di arresto imminente è configurabile per un massimo di cinque minuti nei nodi delle sezioni TPU.

Puoi configurare GKE in modo da terminare i carichi di lavoro ML in modo controllato entro questo periodo di tempo per le notifiche. Durante la terminazione controllata, i carichi di lavoro possono eseguire processi di pulizia, come l'archiviazione dei dati dei carichi di lavoro per ridurre la perdita di dati. Per ottenere il tempo massimo di notifica, nel manifest del pod imposta il campo spec.terminationGracePeriodSeconds su 300 secondi (cinque minuti) come segue:

    spec:
      terminationGracePeriodSeconds: 300

GKE fa il possibile per terminare questi pod in modo controllato e eseguire l'azione di terminazione che hai definito, ad esempio salvando lo stato di addestramento.

Nota: i pod rimossi mediante terminazione controllata del nodo vengono conteggiati ai fini delle eliminazioni consentite configurate nel PDB. Se imposti PodDisruptionBudget, imposta un valore maxUnavailable sufficientemente alto o minAvailable sufficientemente basso da consentire a GKE di completare l'eliminazione del pod entro la finestra temporale della notifica di arresto. In caso contrario, GKE potrebbe dover violare i parametri di disponibilità del PDB quando rimuove i pod per consentire il proseguimento dell'arresto.

Esegui container senza modalità con privilegi

Nota: per i container in esecuzione nei nodi in GKE 1.28 o versioni successive non è necessario che la modalità con privilegi sia abilitata per accedere alle TPU. I nodi in GKE 1.28 e versioni precedenti richiedono la modalità con privilegi.

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

Un container 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 abilitare questa funzionalità, devi configurare una versione ulimit superiore. Se vuoi ridurre l'ambito delle autorizzazioni sul tuo container, completa questi passaggi:

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

   securityContext:
     capabilities:
       add: ["SYS_RESOURCE"]
   

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

   ulimit -l 68719476736
   

Nota: per TPU v5e, l'esecuzione di container senza modalità con privilegi è 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à TPU. Per ulteriori informazioni, consulta Metriche di osservabilità di GKE.

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

Metriche di runtime

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

• Ciclo di servizio: 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 maggiore significa un migliore utilizzo della TPU.
• Memoria utilizzata: quantità di memoria dell'acceleratore allocata in byte. Campionamento eseguito ogni 60 secondi.
• Memoria totale: memoria dell'acceleratore totale in byte. Campionamento eseguito ogni 60 secondi.

Queste metriche si trovano nel nodo Kubernetes (k8s_node) e nello schema 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 versione 1.28.1-gke.1066000 o successive, le VM in una sezione 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: percentuale attuale del TensorCore utilizzato. Il valore TensorCore equivale alla somma delle unità di moltiplicazione matriciale (MXU) più l'unità vettoriale. Il valore di utilizzo TensorCore è la divisione delle operazioni TensorCore eseguite nell'ultimo periodo di campionamento (60 secondi) per il numero supportato di operazioni TensorFlow nello stesso periodo. Un valore maggiore corrisponde a un utilizzo migliore.
• Utilizzo larghezza di banda memoria: la percentuale attuale della larghezza di banda della memoria dell'acceleratore in uso. Viene calcolata 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 nel nodo Kubernetes (k8s_node) e nello schema 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, vedi Metriche Kubernetes e metriche di sistema GKE.

Problemi noti

• Il gestore della scalabilità automatica dei cluster potrebbe calcolare in modo errato la capacità per i nuovi nodi della sezione TPU prima che quei nodi segnalino le TPU disponibili. Il gestore della scalabilità automatica dei cluster potrebbe quindi eseguire ulteriori scale up e, di conseguenza, creare più nodi del necessario. Il gestore della scalabilità automatica del cluster esegue lo scale down di nodi aggiuntivi, se non necessari, dopo una normale operazione di fare lo scale down.
• Il gestore della scalabilità automatica dei cluster annulla lo scale up dei pool di nodi delle sezioni TPU che rimangono in stato di attesa per più di 10 ore. Il gestore della scalabilità automatica del cluster riprova in un secondo momento. Questo comportamento potrebbe ridurre l'ottenimento della TPU per i clienti che non utilizzano le prenotazioni.
• I carichi di lavoro non TPU che hanno una tolleranza per l'incompatibilità della TPU possono impedire fare lo scale down del pool di nodi se vengono ricreati durante lo svuotamento del pool di nodi della sezione TPU.

Passaggi successivi

• Gestione di modelli linguistici di grandi dimensioni (LLM) con Saxml sulle TPU
• Scopri di più sulla configurazione di Ray su GKE con TPU
• Crea machine learning su larga scala sulle Cloud TPU con GKE
• Gestisci modelli linguistici di grandi dimensioni (LLM) con KubeRay sulle TPU
• Risolvere i problemi delle TPU in GKE