Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment dei carichi di lavoro TPU su GKE Autopilot

Autopilot

Questa pagina descrive come accelerare i carichi di lavoro di machine learning (ML) tramite Deployment tramite acceleratori Cloud TPU (TPU) nei cluster Autopilot di Google Kubernetes Engine (GKE). Dovresti hai già familiarità con i seguenti concetti:

Come funzionano le TPU in Autopilot

Per utilizzare le TPU nei carichi di lavoro Autopilot, richiedi una versione di TPU per quella versione TPU nel manifest del carico di lavoro. Quindi utilizzi i campi resources.requests di Kubernetes e resources.limits da specificare il numero di chip TPU che il carico di lavoro può utilizzare. Quando esegui il deployment del carico di lavoro, GKE esegue il provisioning dei nodi che hanno la configurazione TPU richiesta e pianifica i pod sui nodi. GKE posiziona ogni carico di lavoro il proprio nodo, in modo che ogni pod possa accedere alle risorse complete del nodo il rischio di interruzioni.

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

Pianifica la configurazione di TPU

Prima di richiedere le TPU, decidi la configurazione che preferisci in base alle i requisiti di CPU e memoria per i carichi di lavoro. Devi decidere quanto segue:

Versione TPU: la versione specifica di Cloud TPU, ad esempio v5e.
Topologia per la versione di TPU selezionata: la disposizione e il numero di TPU.

La versione TPU e la topologia selezionata determinano se GKE esegue il provisioning dei nodi come sezioni con host singolo o sezioni con più host. In host singolo ogni nodo è indipendente dagli altri nodi delle sezioni TPU. Nelle sezioni con più host, GKE crea un gruppo di nodi con VM interconnesse in una sezione TPU. Le sezioni con più host sono atomico, il che significa che GKE fa lo scale up o lo scale down dell'intero gruppo di nodi interconnessi come una singola unità.

Per informazioni sulle versioni di TPU disponibili, le topologie corrispondenti, la capacità di CPU e memoria e il tipo risultante di sezione, vedi Scegli una configurazione TPU Autopilot.

Prezzi

Per informazioni sui prezzi, vedi Prezzi di Autopilot.

Prima di iniziare

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

Attiva l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare i compute/region e compute/zone proprietà. Impostando località predefinite, puoi evitare errori in gcloud CLI come i seguenti: One of [--zone, --region] must be supplied: Please specify location.

Assicurati di avere un cluster Autopilot che esegue GKE versione 1.29.2-gke.1521000 o successive.
Per utilizzare TPU prenotate, assicurati di avere una capacità specifica esistente prenotazione. Per istruzioni, vedi Utilizzo di risorse di zona riservate.

Assicurati di avere una quota TPU

Per creare nodi sezione TPU, devi disporre di una quota TPU, a meno che non utilizzi un'istanza la prenotazione di capacità esistente. Se utilizzi TPU riservate, salta questa sezione.

La creazione di nodi sezione TPU in GKE richiede una quota API Compute Engine (compute.googleapis.com), non quota API Cloud TPU (tpu.googleapis.com). La della quota sia diverso nei pod Autopilot regolari Spot pod.

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

Vai alla pagina Quote nella console Google Cloud:

Vai a Quote
Nella casella Filtro di , esegui le seguenti:
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 un nome per la quota in base al tipo di TPU desiderato, come segue:
  - TPU v5p (tpu-v5p-slice): chip TPU v5p
  - TPU v5e (tpu-v5-lite-podslice): chip sezione di pod TPU v5 Lite
  - TPU v5e (tpu-v5-lite-device): chip del dispositivo TPU v5 Lite
  - TPU v4 (tpu-v4-podslice): chip sezione di pod TPU v4
  Per i pod Spot, seleziona il valore "Prerilasciabile" quota.
4. Seleziona la proprietà Dimensioni (ad es.località) e inserisci region:. seguito dal nome della regione in cui prevedi di creare le TPU con GKE. Ad esempio, inserisci region:us-west4 se prevedi di crea nodi della sezione TPU nella zona us-west4-a. La quota TPU è a livello di regione, di altre zone all'interno della stessa regione consumano la stessa quota di TPU.

Se nessuna quota corrisponde al filtro inserito, il progetto non è stato a una delle quote specificate per la regione desiderata e devi richiedere un aumento della quota di TPU.

Prepara l'applicazione TPU

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

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

Tipo di TPU	`libtpu.so` versione
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: l'utilizzo di una versione consigliata per la notte il 23 ottobre 2023.
TPU v4 `tpu-v4-podslice`	jax[tpu]: v0.4.4 o successiva torchxla[tpuvm]: v2.0.0 o successiva

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 univoco worker-id nella sezione TPU. I valori supportati per questo campo vanno da zero a di pod meno uno.
- TPU_WORKER_HOSTNAMES: un elenco separato da virgole di nomi host o IP delle VM TPU che devono comunicare tra loro all'interno della sezione. Deve essere presente un o un indirizzo IP per ogni VM TPU nella sezione. L'elenco di indirizzi IP o nomi host vengono ordinati e il valore TPU_WORKER_ID è indicizzato a zero.

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

Richiedi TPU in un carico di lavoro

Questa sezione mostra come creare un job che richiede TPU Autopilot. In qualsiasi carico di lavoro che richiede TPU, devi specificare seguenti:

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

Per un elenco di versioni di TPU supportate, topologie e il numero corrispondente di chip e nodi TPU in una sezione, vedi Scegli una configurazione TPU Autopilot.

Considerazioni sulle richieste di TPU nei carichi di lavoro

Le TPU possono essere utilizzate da un solo container in un pod. Il numero di chip TPU che un container devono essere uguali al numero di chip TPU collegati a un nodo nella sezione. Ad esempio, se richiedi TPU v5e (tpu-v5-lite-podslice) con un 2x4 topologia, puoi richiedere una delle seguenti opzioni:

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

Come best practice per massimizzare l'efficienza in termini di costi, utilizza sempre tutte le TPU nella sezione che richiedi. Se richiedi una sezione di due host multi-host nodi con 4 chip TPU ciascuno, dovresti eseguire il deployment di un carico di lavoro in esecuzione nodi e consuma tutti e 8 i chip TPU nella sezione.

Crea un carico di lavoro che richiede le TPU

I passaggi seguenti creano un job che richiede le TPU. Se hai carichi di lavoro su sezioni TPU multi-host, devi anche creare un servizio headless che seleziona il carico di lavoro per nome. Questo servizio headless consente ai pod su diverse ai nodi nella sezione multi-host di comunicare tra loro aggiornando Configurazione DNS di Kubernetes in modo che punti ai pod nel carico di lavoro.

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
  completions: 4
  parallelism: 4
  completionMode: Indexed
  template:
    spec:
      subdomain: headless-svc
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: TPU_TYPE
        cloud.google.com/gke-tpu-topology: TOPOLOGY
      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.
        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: NUMBER_OF_CHIPS
          limits:
            cpu: 10
            memory: 500Gi
            google.com/tpu: NUMBER_OF_CHIPS

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 sezione, come 2x2x4. Deve essere una topologia supportata per la TPU selezionata di testo.
NUMBER_OF_CHIPS: il numero di chip TPU per il container da utilizzare. Deve essere lo stesso valore per limits e requests.

Esegui il deployment del job:
```
kubectl create -f tpu-autopilot.yaml
```

Quando crei questo job, GKE esegue automaticamente quanto segue:

Esegue il provisioning dei nodi per eseguire i pod. In base al tipo di TPU, alla topologia e alle richieste di risorse specificate, questi nodi sono a host singolo o sezioni con più host.
Aggiunge incompatibilità ai pod e tolleranze ai nodi per prevenire qualsiasi l'esecuzione di altri carichi di lavoro sugli stessi nodi dei carichi di lavoro TPU.

Esempio: visualizzare i chip TPU totali in una sezione multi-host

Il carico di lavoro seguente restituisce il numero di chip TPU in tutti i nodi in un host multi-host Sezione TPU. 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.

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

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.

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

Recupera i log di uno dei pod:
```
kubectl logs POD_NAME
```
Sostituisci POD_NAME con il nome di uno dei di pod. Ad esempio, tpu-job-podslice-0-5cd8r.

L'output è simile al seguente:
```
TPU cores: 16
```

Esempio: visualizzare i chip TPU in un singolo nodo

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.

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

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).
Recupera i log del pod:
```
kubectl logs tpu-job-jax-v5
```
L'output è simile al seguente:
```
Total TPU chips: 8
```

Osservabilità e metriche

Dashboard

Nella pagina Cluster Kubernetes della Console Google Cloud, la scheda Osservabilità mostra l'osservabilità della TPU metriche di valutazione. Per ulteriori informazioni, consulta Metriche di osservabilità di GKE.

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

Metriche di runtime

In GKE versione 1.27.4-gke.900 o successive, i carichi di lavoro TPU che usano la versione JAX 0.4.14 o una versione successiva e specifica containerPort: 8431 per l'esportazione delle metriche di utilizzo TPU come GKE metriche di sistema. Le seguenti metriche sono disponibili in Cloud Monitoring 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 che i TensorCore elaboravano attivamente 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 in Kubernetes del container (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, VM in una sezione TPU esporta le metriche di utilizzo delle TPU come GKE metriche di sistema. Le seguenti metriche sono disponibili in Cloud Monitoring 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 che sono state eseguita nell'ultimo periodo campione (60 secondi) per il numero supportato di le operazioni di TensorCore nello stesso periodo. Un valore maggiore corrisponde a un utilizzo migliore.
Utilizzo larghezza di banda memoria: percentuale attuale dell'acceleratore per la larghezza di banda della memoria in uso. Viene calcolato dividendo la larghezza di banda della memoria utilizzata in un periodo campione (60 secondi) dalla larghezza di banda massima supportata su nello stesso periodo campione.

Queste metriche si trovano nel nodo Kubernetes (k8s_node) e in Kubernetes del container (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 le metriche di sistema di GKE.

Logging

Log emessi dai container in esecuzione su nodi GKE, tra cui TPU Le VM, vengono raccolte dell'agente Logging GKE, inviato a Logging visibile in Logging.

Suggerimenti per i carichi di lavoro TPU in Autopilot

I seguenti suggerimenti potrebbero migliorare l'efficienza dei carichi di lavoro TPU:

Utilizza le funzionalità di pod a tempo di esecuzione esteso per un periodo di tolleranza fino a sette giorni prima della terminazione di GKE per gli scale down o gli upgrade dei nodi. Puoi usare periodi di manutenzione ed esclusioni con pod a tempo di esecuzione esteso per ritardare ulteriormente il nodo automatico upgrade.
Utilizza le prenotazioni di capacità per assicurarti che i tuoi carichi di lavoro ricevano la richiesta TPU senza essere messe in coda per disponibilità.