Questo documento descrive come accelerare i carichi di lavoro di machine learning (ML) Deployment tramite acceleratori Cloud TPU (TPU) nei cluster Autopilot di Google Kubernetes Engine (GKE). Prima di leggere questo documento, assicurati di acquisire familiarità con i seguenti argomenti di base:
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
.
- 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:
Nella casella Filtro di
, esegui le seguenti:Seleziona la proprietà Servizio, inserisci API Compute Engine e premi Invio.
Seleziona la proprietà Tipo e scegli Quota.
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.
- TPU v5p (
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, inserisciregion:us-west4
se prevedi di crea nodi della sezione TPU nella zonaus-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 il conducente. Ogni release di PyTorch e JAX richiede una determinata versione dilibtpu.so
. A per utilizzare le TPU in GKE, assicurati di utilizzare le seguenti versioni:Tipo di TPU libtpu.so
versioneTPU 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 valoreTPU_WORKER_ID
è indicizzato a zero.
GKE inserisce automaticamente queste variabili di ambiente utilizzando un modello webhook quando viene creato un job con
completionMode: Indexed
,subdomain
,parallelism > 1
e richiestagoogle.com/tpu
proprietà. GKE aggiunge un servizio headless vengono aggiunti i record DNS Pod che supportano il servizio.
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 ciascuno8
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 esempiotpu-v4-podslice
. Deve essere un valore supportato da GKE.TOPOLOGY
: la disposizione dei chip TPU nella sezione, come2x2x4
. 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 perlimits
erequests
.
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 seguente carico di lavoro restituisce il numero di chip TPU in tutti i nodi in un 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 degli utenti creati i 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à.