Einführung in TPUs in GKE
Kunden der Google Kubernetes Engine (GKE) können jetzt Kubernetes-Knotenpools mit TPU v4- und v5e-Segmenten. Weitere Informationen Informationen zu TPUs finden Sie unter Systemarchitektur.
Wenn Sie mit GKE arbeiten, müssen Sie zuerst eine GKE-Cluster. Anschließend fügen Sie Knotenpools zu Ihrem Cluster. GKE-Knotenpools sind Sammlungen von VMs mit denselben Attributen. Bei TPU-Arbeitslasten bestehen Knotenpools aus TPU-VMs.
Knotenpooltypen
GKE unterstützt zwei Arten von TPU-Knotenpools:
TPU-Slice-Knotenpool mit mehreren Hosts
Ein TPU-Slice-Knotenpool mit mehreren Hosts ist ein Knotenpool, der mindestens zwei
vernetzte TPU-VMs. Mit jeder VM ist ein TPU-Gerät verbunden. Die TPUs in einem Multi-Host-Slice sind über eine Hochgeschwindigkeits-Interconnect-Verbindung (ICI) verbunden. Nachdem ein Slice-Knotenpool mit mehreren Hosts erstellt wurde, können Sie ihm keine Knoten mehr hinzufügen. Beispiel:
Sie können keinen v4-32
-Knotenpool erstellen und später ein zusätzliches Kubernetes hinzufügen
Knoten (TPU-VM) zum Knotenpool hinzu. Wenn Sie einem GKE-Cluster ein zusätzliches TPU-Speicherelement hinzufügen möchten, müssen Sie einen neuen Knotenpool erstellen.
Die Hosts in einem TPU-Slice-Knotenpool mit mehreren Hosts werden als eine einzelne atomare Einheit behandelt. Wenn GKE einen Knoten im Slice nicht bereitstellen kann, im Slice bereitgestellt werden.
Wenn ein Knoten in einem TPU-Slice mit mehreren Hosts repariert werden muss, schaltet GKE alle TPU-VMs im Slice aus, wodurch alle Kubernetes-Pods in der Arbeitslast entfernt werden. Sobald alle TPU-VMs im Slice ausgeführt werden, Kubernetes-Pods können auf den TPU-VMs im neuen Slice geplant werden.
Das folgende Diagramm zeigt ein Beispiel für eine TPU-SLICE mit mehreren Hosts vom Typ „v5litepod-16“ (v5e). Dieses Slice hat vier TPU-VMs. Jede TPU-VM hat vier TPU v5e-Chips, die über Hochgeschwindigkeits-Interconnects (ICI) verbunden sind. Jeder TPU v5e-Chip hat einen TensorCore.
Das folgende Diagramm zeigt einen GKE-Cluster mit einem TPU v5litepod-16
(v5e)-Speicherbereich (Topologie: 4x4) und einem TPU v5litepod-8
(v5e)-Speicherbereich (Topologie: 2x4):
Ein Beispiel für die Ausführung einer Arbeitslast auf einem TPU-Slice mit mehreren Hosts finden Sie unter Arbeitslast auf TPUs ausführen
TPU-Slice-Knotenpools mit einem Host
Ein Knotenpool mit einem einzelnen Slice ist ein Knotenpool, der eine oder mehrere unabhängige TPU-VMs enthält. Mit jeder VM ist ein TPU-Gerät verbunden. Während die VMs innerhalb eines Slice-Knotenpools mit einem einzelnen Host über das Rechenzentrum kommunizieren können. Netzwerk (DCN), sind die an die VMs angehängten TPUs nicht miteinander verbunden.
Das folgende Diagramm zeigt ein Beispiel für ein Slice eines TPU-Slice mit einem einzelnen Host mit sieben
v4-8
Maschinen:
Ein Beispiel für die Ausführung einer Arbeitslast auf einem TPU-Slice mit einem einzelnen Host finden Sie unter Arbeitslast auf TPUs ausführen.
TPU-Maschinentypen für GKE-Knotenpools
Bevor Sie Knotenpools erstellen, müssen Sie die TPU-Version und -Größe des
TPU-Slice, die Ihre Arbeitslast benötigt. TPU v4 wird in GKE unterstützt
Standardversion 1.26.1-gke.1500
und höher, v5e in GKE
Standardversion 1.27.2-gke.2100
und höher sowie v5p in
GKE-Standardversion 1.28.3-gke.1024000
und höher.
TPU v4, v5e und v5p werden in GKE Autopilot-Version 1.29.2-gke.1521000
und höher unterstützt.
Weitere Informationen zu den Hardwarespezifikationen der verschiedenen TPU-Versionen finden Sie unter Systemarchitektur. Wann? TPU-Knotenpool erstellen, wählen Sie eine TPU-Slice-Größe (eine TPU-Topologie) anhand der Größe Ihres Modells und den dafür benötigten Speicher. Der Maschinentyp, den Sie beim Erstellen Ihrer Knotenpools angeben, hängt von der Version und Größe Ihrer Slices ab.
Version 5e
Folgende TPU v5e-Maschinentypen und -Topologien werden unterstützt: für Trainings- und Inferenz-Anwendungsfälle:
Maschinentyp | Topologie | Anzahl der TPU-Chips | Anzahl der VMs | Empfohlener Anwendungsfall |
---|---|---|---|---|
ct5lp-hightpu-1t |
1x1 | 1 | 1 | Training, Inferenz mit einem einzelnen Host |
ct5lp-hightpu-4t |
2x2 | 4 | 1 | Training, Inferenz eines einzelnen Hosts |
ct5lp-hightpu-8t |
2x4 | 8 | 1 | Training, Inferenz eines einzelnen Hosts |
ct5lp-hightpu-4t |
2x4 | 8 | 2 | Training, Inferenz mit mehreren Hosts |
ct5lp-hightpu-4t |
4x4 | 16 | 4 | Umfangreiches Training, Inferenz mit mehreren Hosts |
ct5lp-hightpu-4t |
4x8 | 32 | 8 | Umfangreiches Training, Inferenz mit mehreren Hosts |
ct5lp-hightpu-4t |
8x8 | 64 | 16 | Umfangreiches Training, Inferenz mit mehreren Hosts |
ct5lp-hightpu-4t |
8x16 | 128 | 32 | Umfangreiches Training, Inferenz mit mehreren Hosts |
ct5lp-hightpu-4t |
16x16 | 256 | 64 | Umfangreiches Training, Inferenz mit mehreren Hosts |
Cloud TPU v5e ist ein kombiniertes Trainings- und Inferenzprodukt. Trainingsjobs sind für Durchsatz und Verfügbarkeit optimiert, während Inferenzjobs für Latenz optimiert sind. Weitere Informationen finden Sie unter v5e Training-Beschleunigertypen. und v5e-Inferenzbeschleunigertypen.
TPU v5e-Maschinen sind in us-west4-a
, us-east5-b
und us-east1-c
verfügbar.
Auf GKE-Standardclustern muss die Steuerungsebenen-Version 1.27.2-gke.2100 oder höher ausgeführt werden. GKE Autopilot
muss mindestens Version 1.29.2-gke.1521000 der Steuerungsebene ausführen. Weitere Informationen zu v5e finden Sie unter Cloud TPU v5e-Training.
Vergleich der Maschinentypen:
Maschinentyp | ct5lp-hightpu-1t | ct5lp-hightpu-4t | ct5lp-hightpu-8t |
---|---|---|---|
Anzahl der v5e-Chips | 1 | 4 | 8 |
Anzahl der vCPUs | 24 | 112 | 224 |
RAM (GB) | 48 | 192 | 384 |
Anzahl der NUMA-Knoten | 1 | 1 | 2 |
Wahrscheinlichkeit eines vorzeitigen Beendens | Hoch | Mittel | Niedrig |
Um Platz für VMs mit mehr Chips zu schaffen, kann der GKE-Scheduler VMs mit weniger Chips vorzeitig beenden und neu planen. Bei VMs mit 8 Chips ist die Wahrscheinlichkeit präemptive 1- und 4-Chip-VMs.
v4 und v5p
Dies sind die TPU v4- und v5p-Maschinentypen:
Maschinentyp | Anzahl der vCPUs | Arbeitsspeicher (GB) | Anzahl der NUMA-Knoten |
---|---|---|---|
ct4p-hightpu-4t |
240 | 407 | 2 |
ct5p-hightpu-4t |
208 | 448 | 2 |
Verwenden Sie beim Erstellen eines TPU v4-Slice den Maschinentyp ct4p-hightpu-4t
mit
einen Host und enthält 4 Chips. Weitere Informationen finden Sie unter v4-Topologien und TPU-Systemarchitektur. TPU v4-Slice-Maschinentypen sind in us-central2-b
verfügbar. Auf Ihren GKE-Standardclustern muss die Steuerungsebenen-Version 1.26.1-gke.1500
oder höher ausgeführt werden. GKE Autopilot
Cluster müssen mindestens Version 1.29.2-gke.1521000
der Steuerungsebene ausführen.
Verwenden Sie beim Erstellen eines TPU v5p-Slice den Maschinentyp ct5p-hightpu-4t
mit
einen Host und enthält 4 Chips. TPU v5p-Speicher-Maschinentypen sind in us-west4-a
und us-east5-a
verfügbar. Auf GKE Standard-Clustern muss die Steuerungsebenen-Version 1.28.3-gke.1024000
oder höher ausgeführt werden.
GKE Autopilot muss 1.29.2-gke.1521000
oder höher ausführen. Weitere Informationen zu v5p finden Sie in der Einführung zum v5p-Training.
Bekannte Probleme und Beschränkungen
- Maximale Anzahl von Kubernetes-Pods: Sie können maximal 256 Kubernetes-Pods auf einer einzelnen TPU-VM ausführen.
- Nur BESTIMMTE Reservierungen: Bei der Verwendung von TPUs in GKE:
SPECIFIC
ist der einzige unterstützte Wert für das Flag--reservation-affinity
des Befehlsgcloud container node-pools create
ein. - Nur die Spot-VMs-Variante von TPUs auf Abruf wird unterstützt: Spot-VMs ähneln VMs auf Abruf und unterliegen der gleichen Verfügbarkeit aber keine maximale Dauer von 24 Stunden.
- Keine Unterstützung für die Kostenzuweisung: GKE-Kostenzuweisung und Nutzungsmessung enthalten keine Daten über die Nutzung oder Kosten von TPUs.
- Autoscaler kann Kapazität berechnen: Der Cluster-Autoscaler kann die Kapazität für neue Knoten mit TPU-VMs falsch berechnen, bevor diese Knoten verfügbar sind. Cluster-Autoscaler kann dann zusätzliche Hochskalierungen ausführen und so mehr Knoten als erforderlich erstellen. Cluster-Autoscaler skaliert zusätzliche Knoten nach dem regulären Herunterskalieren herunter, wenn sie nicht benötigt werden.
- Autoscaling bricht das Hochskalieren ab: Cluster-Autoscaling bricht das Hochskalieren der TPU ab. Knotenpools, die länger als 10 Stunden im Wartestatus bleiben. Cluster Autoscaling wiederholt solche Vorgänge zum Hochskalieren später. Dieses Verhalten kann die TPU-Verfügbarkeit für Kunden, die keine Reservierungen verwenden, verringern.
- Markierung kann das Herunterskalieren verhindern: Nicht-TPU-Arbeitslasten mit einer Toleranz für die TPU-Markierung können das Herunterskalieren des Knotenpools verhindern, wenn sie während des Leerens des TPU-Knotenpools neu erstellt werden.
Ausreichende TPU- und GKE-Kontingente bereitstellen
Möglicherweise müssen Sie bestimmte GKE-bezogene Kontingente in den Regionen erhöhen, in denen Ihre Ressourcen erstellt werden.
Die folgenden Kontingente haben Standardwerte, die wahrscheinlich erhöht werden müssen:
- Kontingent für Peresistent Disk SSD (GB): Das Bootlaufwerk jedes Kubernetes-Knotens benötigt standardmäßig 100 GB. Daher sollte dieses Kontingent auf mindestens hoch (die maximale Anzahl von GKE-Knoten, die Sie erwarten erstellt) * 100 GB.
- Kontingent für verwendete IP-Adressen: Jeder Kubernetes-Knoten nutzt eine IP-Adresse. Daher sollte dieses Kontingent mindestens so hoch sein wie die maximale Anzahl GKE-Knoten, die erstellt werden sollen.
Unter Höheres Kontingent anfordern erfahren Sie, wie Sie eine Kontingenterhöhung anfordern. Weitere Informationen zu den Arten von TPU-Kontingenten finden Sie unter TPU-Kontingent.
Es kann einige Tage dauern, bis Ihre Anträge auf Kontingenterhöhung genehmigt werden. Wenn Sie Ihre Anfragen zur Kontingenterhöhung innerhalb eines wenden Sie sich bitte an Ihr Google Konten-Team.
TPU-Reservierung migrieren
Wenn Sie keine vorhandene TPU-Reservierung mit TPUs in GKE verwenden möchten, überspringen Sie diesen Abschnitt und fahren Sie mit Google Kubernetes Engine-Cluster erstellen fort.
Wenn Sie reservierte TPUs mit GKE verwenden möchten, müssen Sie zuerst Ihre TPU-Reservierung zu einem neuen Compute Engine-basierten Reservierungssystem migrieren.
Es gibt einige wichtige Dinge, die Sie über diese Migration wissen sollten:
- Zur neuen Compute Engine-basierten Reservierung migrierte TPU-Kapazität -System kann nicht mit der Cloud TPU Queued Resource API verwendet werden. Wenn Sie für Ihre Reservierung TPU-Ressourcen in der Warteschlange verwenden möchten, müssen einen Teil Ihrer TPU-Reservierung zur neuen Auf Compute Engine basierendes Reservierungssystem
- Es können keine Arbeitslasten aktiv auf TPUs ausgeführt werden, wenn sie in das neue Compute Engine-basierte Reservierungssystem migriert werden.
- Wählen Sie einen Zeitpunkt für die Migration aus und arbeiten Sie mit Ihrer Google Cloud Account-Management-Team, um die Migration zu planen. Das Zeitfenster für die Migration muss während der Geschäftszeiten (Montag bis Freitag, 9:00 bis 17:00 Uhr Pacific Time)
Google Kubernetes Engine-Cluster erstellen
Weitere Informationen finden Sie in der Google Kubernetes Engine-Dokumentation unter Cluster erstellen.
TPU-Knotenpool erstellen
Weitere Informationen finden Sie in der Google Kubernetes Engine-Dokumentation unter Nodepool erstellen.
Ohne privilegierten Modus ausführen
Wenn Sie den Berechtigungsbereich für Ihren Container einschränken möchten, lesen Sie TPU-Privilegmodus:
Arbeitslasten in TPU-Knotenpools ausführen
Weitere Informationen finden Sie in der Google Kubernetes Engine-Dokumentation unter GKE-Arbeitslasten auf TPUs ausführen.
Knotenselektoren
Damit Kubernetes Ihre Arbeitslast auf Knoten mit TPU-VMs planen kann, müssen Sie in Ihrem Google Kubernetes Engine-Manifest für jeden Knoten zwei Selektoren angeben:
- Legen Sie
cloud.google.com/gke-accelerator-type
auftpu-v5-lite-podslice
,tpu-v5p-slice
odertpu-v4-podslice
fest. - Legen Sie
cloud.google.com/gke-tpu-topology
auf die TPU-Topologie des Knotens fest.
Die Abschnitte Trainingsarbeitslasten und Inferenzarbeitslasten enthalten Beispielmanifeste, die die Verwendung dieser Knotenselektoren veranschaulichen.
Überlegungen zur Arbeitslastplanung
TPUs haben besondere Merkmale, die eine spezielle Arbeitslastplanung und -verwaltung in Kubernetes erfordern. Weitere Informationen finden Sie unter Überlegungen zur Arbeitslastplanung. in der GKE-Dokumentation.
Knotenreparatur
Wenn ein Knoten in einem TPU-Slice-Knotenpool mit mehreren Hosts fehlerhaft ist, erstellt GKE den gesamten Knotenpool neu. Weitere Informationen finden Sie in der GKE-Dokumentation unter Automatische Knotenreparatur.
Mehrslice – mehr als ein einzelnes Segment
Sie können kleinere Slices in einem Multi-Slice aggregieren, um größere Trainingsarbeitslasten zu verarbeiten. Weitere Informationen finden Sie unter Cloud TPU Multi-Slice.
Anleitungen zum Trainieren von Arbeitslasten
In diesen Anleitungen geht es um das Trainieren von Arbeitslasten auf einem TPU-Slice mit mehreren Hosts (für Beispiel: 4 v5e-Maschinen). Sie gelten für die folgenden Modelle:
- Hugging Face FLAX-Modelle: Diffusion mit Pokémon trainieren
- PyTorch/XLA: GPT2 in WikiText
Anleitungsressourcen herunterladen
Laden Sie die Python-Scripts und YAML-Spezifikationen für jedes vorab trainierte Modell mit dem folgenden Befehl herunter:
git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git
Cluster erstellen und eine Verbindung dazu herstellen
Erstellen Sie einen regionalen GKE-Cluster, damit die Kubernetes-Steuerungsebene in drei Zonen repliziert wird und so eine höhere Verfügbarkeit erreicht wird.
Erstellen Sie Ihren Cluster in us-west4
, us-east1
oder us-central2
, je nachdem, welche TPU-Version Sie verwenden. Weitere Informationen zu TPUs und Zonen finden Sie unter Cloud TPU-Regionen und ‑Zonen.
Mit dem folgenden Befehl wird ein neuer GKE-Regionalcluster erstellt, der für den Rapid-Release-Kanal registriert ist, mit einem Knotenpool, der anfangs einen Knoten pro Zone enthält. Der Befehl aktiviert auch die Identitätsföderation von Arbeitslasten für GKE und CSI-Treiberfeatures für Cloud Storage FUSE in Ihrem Cluster, da das Beispiel Bei Inferenzarbeitslasten in diesem Leitfaden werden Cloud Storage-Buckets verwendet, vortrainierten Modellen.
gcloud container clusters create cluster-name \ --region your-region \ --release-channel rapid \ --num-nodes=1 \ --workload-pool=project-id.svc.id.goog \ --addons GcsFuseCsiDriver
So aktivieren Sie die Workload Identity-Föderation für GKE und die CSI-Treiberfeatures von Cloud Storage FUSE für vorhandenen Clustern führen Sie den folgenden Befehl aus:
gcloud container clusters update cluster-name \ --region your-region \ --update-addons GcsFuseCsiDriver=ENABLED \ --workload-pool=project-id.svc.id.goog
Die Beispielarbeitslasten werden mit den folgenden Annahmen konfiguriert:
- der Knotenpool
tpu-topology=4x4
mit vier Knoten verwendet - der Knotenpool verwendet
machine-type
ct5lp-hightpu-4t
Führen Sie den folgenden Befehl aus, um eine Verbindung zu Ihrem neu erstellten Cluster herzustellen:
gcloud container clusters get-credentials cluster-name \ --location=cluster-region
Hugging Face FLAX-Modelle: Trainiere die Streuung von Pokémon
In diesem Beispiel wird das Stable Diffusion-Modell von HuggingFace mithilfe der Methode Pokémon Dataset.
Das Stable Diffusion-Modell ist ein latentes Text-zu-Bild-Modell, das fotorealistische Bilder aus jeder Texteingabe. Weitere Informationen zur stabilen Version Streuung, siehe:
Docker-Image erstellen
Das Dockerfile befindet sich im Ordner ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/
.
Bevor Sie den folgenden Befehl ausführen, prüfen Sie, ob Ihr Konto die richtigen Berechtigungen hat, damit Docker per Push in das Repository übertragen kann.
Erstellen und übertragen Sie das Docker-Image:
cd ai-on-gke/tutorials-and-examples/tpu-examples/training/diffusion/ docker build -t gcr.io/project-id/diffusion:latest . docker push gcr.io/project-id/diffusion:latest
Arbeitslast bereitstellen
Erstellen Sie eine Datei mit folgendem Inhalt und nennen Sie sie tpu_job_diffusion.yaml
.
Fügen Sie das gerade erstellte Bild in das Bildfeld ein.
apiVersion: v1
kind: Service
metadata:
name: headless-svc
spec:
clusterIP: None
selector:
job-name: tpu-job-diffusion
---
apiVersion: batch/v1
kind: Job
metadata:
name: tpu-job-diffusion
spec:
backoffLimit: 0
# Completions and parallelism should be the number of chips divided by 4.
# (e.g. 4 for a v5litepod-16)
completions: 4
parallelism: 4
completionMode: Indexed
template:
spec:
subdomain: headless-svc
restartPolicy: Never
nodeSelector:
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
cloud.google.com/gke-tpu-topology: 4x4
containers:
- name: tpu-job-diffusion
image: gcr.io/${project-id}/diffusion:latest
ports:
- containerPort: 8471 # Default port using which TPU VMs communicate
- containerPort: 8431 # Port to export TPU usage metrics, if supported
command:
- bash
- -c
- |
cd examples/text_to_image
python3 train_text_to_image_flax.py --pretrained_model_name_or_path=duongna/stable-diffusion-v1-4-flax --dataset_name=lambdalabs/pokemon-blip-captions --resolution=128 --center_crop --random_flip --train_batch_size=4 --mixed_precision=fp16 --max_train_steps=1500 --learning_rate=1e-05 --max_grad_norm=1 --output_dir=sd-pokemon-model
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Stellen Sie es dann mithilfe von Folgendem bereit:
kubectl apply -f tpu_job_diffusion.yaml
Bereinigen
Nachdem der Job beendet wurde, können Sie ihn so löschen:
kubectl delete -f tpu_job_diffusion.yaml
PyTorch/XLA: GPT2 auf WikiText
In dieser Anleitung wird gezeigt, wie GPT2 mit HuggingFace auf v5e-TPUs ausgeführt wird. zu PyTorch/XLA mit dem Wikitext-Dataset
Docker-Image erstellen
Das Dockerfile befindet sich im Ordner ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/
.
Bevor Sie den folgenden Befehl ausführen, prüfen Sie, ob Ihr Konto die richtigen Berechtigungen hat, damit Docker per Push in das Repository übertragen kann.
Erstellen und übertragen Sie das Docker-Image:
cd ai-on-gke/tutorials-and-examples/tpu-examples/training/gpt/ docker build -t gcr.io/project-id/gpt:latest . docker push gcr.io/project-id/gpt:latest
Arbeitslast bereitstellen
Kopieren Sie den folgenden YAML-Code und speichern Sie ihn in einer Datei namens tpu_job_gpt.yaml
. Ausfüllen
das Bildfeld mit dem Bild, das Sie gerade erstellt haben.
apiVersion: v1
kind: Service
metadata:
name: headless-svc
spec:
clusterIP: None
selector:
job-name: tpu-job-gpt
---
apiVersion: batch/v1
kind: Job
metadata:
name: tpu-job-gpt
spec:
backoffLimit: 0
# Completions and parallelism should be the number of chips divided by 4.
# (for example, 4 for a v5litepod-16)
completions: 4
parallelism: 4
completionMode: Indexed
template:
spec:
subdomain: headless-svc
restartPolicy: Never
volumes:
# Increase size of tmpfs /dev/shm to avoid OOM.
- name: shm
emptyDir:
medium: Memory
# consider adding `sizeLimit: XGi` depending on needs
nodeSelector:
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
cloud.google.com/gke-tpu-topology: 4x4
containers:
- name: tpu-job-gpt
image: gcr.io/$(project-id)/gpt:latest
ports:
- containerPort: 8479
- containerPort: 8478
- containerPort: 8477
- containerPort: 8476
- containerPort: 8431 # Port to export TPU usage metrics, if supported.
env:
- name: PJRT_DEVICE
value: 'TPU'
- name: XLA_USE_BF16
value: '1'
command:
- bash
- -c
- |
numactl --cpunodebind=0 python3 -u examples/pytorch/xla_spawn.py --num_cores 4 examples/pytorch/language-modeling/run_clm.py --num_train_epochs 3 --dataset_name wikitext --dataset_config_name wikitext-2-raw-v1 --per_device_train_batch_size 16 --per_device_eval_batch_size 16 --do_train --do_eval --output_dir /tmp/test-clm --overwrite_output_dir --config_name my_config_2.json --cache_dir /tmp --tokenizer_name gpt2 --block_size 1024 --optim adafactor --adafactor true --save_strategy no --logging_strategy no --fsdp "full_shard" --fsdp_config fsdp_config.json
volumeMounts:
- mountPath: /dev/shm
name: shm
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Stellen Sie den Workflow mit einer der folgenden Methoden bereit:
kubectl apply -f tpu_job_gpt.yaml
Bereinigen
Nachdem der Job beendet wurde, können Sie ihn so löschen:
kubectl delete -f tpu_job_gpt.yaml
Anleitung: Inferenzarbeitslasten mit einem einzelnen Host
In dieser Anleitung wird gezeigt, wie Sie eine Inferenzarbeitslast für einen einzelnen Host GKE v5e-TPUs für vortrainierte Modelle mit JAX, TensorFlow, und PyTorch. Im Wesentlichen sind vier separate Schritte für den GKE-Cluster erforderlich:
Erstellen Sie einen Cloud Storage-Bucket und richten Sie den Zugriff auf den Bucket ein. Sie verwenden einen Cloud Storage-Bucket, um das vortrainierte Modell zu speichern.
Vortrainiertes Modell herunterladen und in ein TPU-kompatibles Modell konvertieren Wenden Sie Kubernetes-Pod, der das vortrainierte Modell herunterlädt, verwendet die Cloud TPU Converter und speichert die konvertierten Modelle in einem Cloud Storage- Bucket mit dem CSI-Treiber für Cloud Storage FUSE verwenden. Cloud TPU Converter erfordert keine spezielle Hardware. In dieser Anleitung erfahren Sie, wie Sie das Modell herunterladen und den Cloud TPU-Konverter im CPU-Knotenpool ausführen.
Starten Sie den Server für das konvertierte Modell. Wenden Sie eine Bereitstellung an, die das Modell mit einem Server-Framework bereitstellt, das vom Volume unterstützt wird, das im nichtflüchtigen Volume „ReadOnlyMany“ (ROX) gespeichert ist. Die Bereitstellungsreplikate müssen ausgeführt werden in einem v5e-Slice-Knotenpool mit einem Kubernetes-Pod pro Knoten. in einem v5e-Slice-Knotenpool mit einem Kubernetes-Pod pro Knoten.
Stellen Sie einen Load-Balancer bereit, um den Modellserver zu testen. Der Server ist über den LoadBalancer-Dienst für externe Anfragen verfügbar. Es wurde ein Python-Skript mit einer Beispielanfrage bereitgestellt, um die Modellserver.
Das folgende Diagramm zeigt, wie Anfragen vom Load Balancer weitergeleitet werden.
Beispiele für die Serverbereitstellung
Diese Beispielarbeitslasten werden mit den folgenden Annahmen konfiguriert:
- Der Cluster wird mit einem TPU v5-Knotenpool mit 3 Knoten ausgeführt.
- Der Knotenpool verwendet den Maschinentyp
ct5lp-hightpu-1t
, wobei Folgendes gilt:- Die Topologie ist 1x1.
- Anzahl der TPU-Chips: 1
Das folgende GKE-Manifest definiert einen einzelnen Host Serverbereitstellung.
apiVersion: apps/v1
kind: Deployment
metadata:
name: bert-deployment
spec:
selector:
matchLabels:
app: tf-bert-server
replicas: 3 # number of nodes in node pool
template:
metadata:
annotations:
gke-gcsfuse/volumes: "true"
labels:
app: tf-bert-server
spec:
nodeSelector:
cloud.google.com/gke-tpu-topology: 1x1 # target topology
cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # target version
containers:
- name: serve-bert
image: us-docker.pkg.dev/cloud-tpu-images/inference/tf-serving-tpu:2.13.0
env:
- name: MODEL_NAME
value: "bert"
volumeMounts:
- mountPath: "/models/"
name: bert-external-storage
ports:
- containerPort: 8500
- containerPort: 8501
- containerPort: 8431 # Port to export TPU usage metrics, if supported.
resources:
requests:
google.com/tpu: 1 # TPU chip request
limits:
google.com/tpu: 1 # TPU chip request
volumes:
- name: bert-external-storage
persistentVolumeClaim:
claimName: external-storage-pvc
Wenn Sie eine andere Anzahl von Knoten in Ihrem TPU-Knotenpool verwenden, ändern Sie das Feld replicas
in die Anzahl der Knoten.
Wenn Ihr Standardcluster die GKE-Version 1.27 oder niedriger ausführt, Fügen Sie Ihrem Manifest das folgende Feld hinzu:
spec:
securityContext:
privileged: true
Sie müssen Kubernetes-Pods nicht im privilegierten Modus in GKE ausführen Version 1.28 oder höher. Weitere Informationen finden Sie unter Container ohne privilegierten Modus ausführen
Wenn Sie einen anderen Maschinentyp verwenden:
- Legen Sie
cloud.google.com/gke-tpu-topology
auf die Topologie für den Maschinentyp fest. die Sie verwenden. - Legen Sie die beiden
google.com/tpu
-Felder unterresources
so fest, dass sie der Anzahl der Chips für den entsprechenden Maschinentyp zu erstellen.
Einrichtung
Laden Sie die Python-Scripts und YAML-Manifeste der Anleitung mit dem folgenden Befehl herunter:
git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git
Wechseln Sie in das Verzeichnis single-host-inference
:
cd ai-on-gke/gke-tpu-examples/single-host-inference/
Python-Umgebung einrichten
Für die Python-Skripts, die Sie in dieser Anleitung verwenden, ist Python 3.9 oder höher erforderlich.
Denken Sie daran, die requirements.txt
für jede Anleitung zu installieren, bevor Sie die Python-Testscripts ausführen.
Wenn Sie in Ihrer lokalen Umgebung nicht die richtige Python-Einrichtung haben, können Sie die Python-Scripts in dieser Anleitung mit Cloud Shell herunterladen und ausführen.
Cluster einrichten
Erstellen Sie einen Cluster mit dem Maschinentyp
e2-standard-4
.gcloud container clusters create cluster-name \ --region your-region \ --release-channel rapid \ --num-nodes=1 \ --machine-type=e2-standard-4 \ --workload-pool=project-id.svc.id.goog \ --addons GcsFuseCsiDriver
Für die Beispielarbeitslasten wird Folgendes vorausgesetzt:
- Der Cluster wird mit einem TPU v5e-Knotenpool mit 3 Knoten ausgeführt.
- Der TPU-Knotenpool verwendet den Maschinentyp
ct5lp-hightpu-1t
.
Wenn Sie eine andere Clusterkonfiguration als zuvor beschrieben verwenden, müssen Sie das Manifest für die Serverbereitstellung bearbeiten.
Für die JAX Stable Diffusion-Demo benötigen Sie einen CPU-Knotenpool mit einer
Maschinentyp mit mehr als 16 GB verfügbarem Arbeitsspeicher (z. B. e2-standard-4
).
Dies wird im gcloud container clusters create
-Befehl oder durch
Sie fügen dem vorhandenen Cluster einen weiteren Knotenpool hinzu:
Befehl:
gcloud beta container node-pools create your-pool-name \ --zone=your-cluster-zone \ --cluster=your-cluster-name \ --machine-type=e2-standard-4 \ --num-nodes=1
Ersetzen Sie Folgendes:
your-pool-name
: Der Name des Knotenpools, der erstellt werden soll.your-cluster-zone
: Zone, in der der Cluster erstellt wurde.your-cluster-name
: Der Name des Clusters, dem der Knotenpool hinzugefügt werden soll.your-machine-type
: Der Maschinentyp der Knoten, die im Knotenpool erstellt werden sollen.
Modellspeicher einrichten
Es gibt mehrere Möglichkeiten, Ihr Modell für die Bereitstellung zu speichern. In dieser Anleitung gehen wir so vor:
- Zum Konvertieren des vortrainierten Modells für TPUs verwenden wir einen
Virtual Private Cloud mit Zugriff von
ReadWriteMany
(RWX) auf nichtflüchtigem Speicher unterstützt. - Für die Bereitstellung des Modells auf mehreren Einzelhost-TPUs verwenden wir dasselbe Vom Cloud Storage-Bucket unterstützte VPC.
Führen Sie den folgenden Befehl aus, um einen Cloud Storage-Bucket zu erstellen.
gcloud storage buckets create gs://your-bucket-name \ --project=your-bucket-project-id \ --location=your-bucket-location
Ersetzen Sie Folgendes:
your-bucket-name
: Der Name des Cloud Storage-Bucket.your-bucket-project-id
: Die ID des Projekts, in dem Sie den Cloud Storage erstellt haben. Bucket.your-bucket-location
: Der Speicherort Ihres Cloud Storage-Buckets. Um die Leistung zu verbessern, geben Sie den Standort an, an dem Ihr GKE-Cluster ausgeführt wird.
Führen Sie die folgenden Schritte aus, um Ihrem GKE-Cluster Zugriff auf den Bucket zu gewähren. In den folgenden Beispielen wird die Standardeinstellung verwendet, um die Einrichtung zu vereinfachen. Namespace und das Kubernetes-Standarddienstkonto. Weitere Informationen finden Sie unter Konfigurieren Sie den Zugriff auf Cloud Storage-Buckets mithilfe der GKE-Workload-Identitätsföderation für GKE.
Erstellen Sie ein IAM-Dienstkonto für Ihre Anwendung oder verwenden Sie stattdessen ein vorhandenes IAM-Dienstkonto. Sie können jedes IAM-Dienstkonto im Projekt Ihres Cloud Storage-Buckets verwenden.
gcloud iam service-accounts create your-iam-service-acct \ --project=your-bucket-project-id
Ersetzen Sie Folgendes:
your-iam-service-acct
: der Name des neuen IAM-Dienstes. Konto.your-bucket-project-id
: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto erstellt haben. Das IAM-Dienstkonto muss sich im selben Projekt wie Ihr Cloud Storage-Bucket befinden.
Achten Sie darauf, dass Ihr IAM-Dienstkonto die Speicherrollen hat, die Sie die Sie brauchen.
gcloud storage buckets add-iam-policy-binding gs://your-bucket-name \ --member "serviceAccount:your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com" \ --role "roles/storage.objectAdmin"
Ersetzen Sie Folgendes:
your-bucket-name
: Der Name Ihres Cloud Storage-Bucketsyour-iam-service-acct
: der Name des neuen IAM-Dienstkontos.your-bucket-project-id
: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto erstellt haben.
Kubernetes-Dienstkonto erlauben, die Identität der IAM zu übernehmen Dienstkonto, indem Sie eine IAM-Richtlinienbindung zwischen der zwei Dienstkonten. Durch diese Bindung kann das Kubernetes-Dienstkonto Sie fungieren als IAM-Dienstkonto.
gcloud iam service-accounts add-iam-policy-binding your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:your-project-id.svc.id.goog[default/default]"
Ersetzen Sie Folgendes:
your-iam-service-acct
: der Name des neuen IAM-Dienstes. Konto.your-bucket-project-id
: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto erstellt haben.your-project-id
: Die ID des Projekts, in dem Sie Ihren GKE-Cluster erstellt haben. Ihre Cloud Storage-Buckets und Der GKE-Cluster kann sich im selben oder in verschiedenen Projekten befinden.
Kennzeichnen Sie das Kubernetes-Dienstkonto mit der E-Mail-Adresse des IAM-Dienstkontos.
kubectl annotate serviceaccount default \ --namespace default \ iam.gke.io/gcp-service-account=your-iam-service-acct@your-bucket-project-id.iam.gserviceaccount.com
Ersetzen Sie Folgendes:
your-iam-service-acct
: der Name des neuen IAM-Dienstes. Konto.your-bucket-project-id
: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto erstellt haben.
Führen Sie den folgenden Befehl aus, um den Namen Ihres Buckets in die YAML-Dateien dieser Demo einzufügen:
find . -type f -name "*.yaml" | xargs sed -i "s/BUCKET_NAME/your-bucket-name/g"
Ersetzen Sie
your-bucket-name
durch den Namen Ihres Cloud Storage-Buckets.Erstellen Sie das Persistent Volume und den Persistent Volume Claim mit dem folgenden Befehl:
kubectl apply -f pvc-pv.yaml
JAX-Modellinferenz und -bereitstellung
Installieren Sie Python-Abhängigkeiten zum Ausführen von Python-Skripten in dieser Anleitung, die an den JAX-Modelldienst gesendet.
pip install -r jax/requirements.txt
Demo für die JAX BERT-E2E-Auslieferung ausführen:
In dieser Demo wird ein vortrainiertes BERT-Modell von Hugging Face verwendet.
Der Kubernetes-Pod führt die folgenden Schritte aus:
- Hier wird das Python-Script
export_bert_model.py
aus den Beispielressourcen heruntergeladen und verwendet, um das vortrainierte BERT-Modell in ein temporäres Verzeichnis herunterzuladen. - Verwendet das Cloud TPU Converter-Bild zum Konvertieren des vortrainierten Modells CPU zu TPU und speichert das Modell im Cloud Storage-Bucket, den Sie die während der Einrichtung erstellt wurden.
Dieser Kubernetes-Pod ist so konfiguriert, dass er auf der CPU des Standardknotenpools ausgeführt wird. Führen Sie den Pod mit dem folgenden Befehl:
kubectl apply -f jax/bert/install-bert.yaml
Prüfen Sie so, ob das Modell korrekt installiert wurde:
kubectl get pods install-bert
Es kann einige Minuten dauern, bis STATUS
Completed
liest.
TF-Modellserver für das Modell starten
Für die Beispielarbeitslasten in dieser Anleitung wird Folgendes vorausgesetzt:
- Der Cluster wird mit einem TPU v5-Knotenpool mit drei Knoten ausgeführt
- Der Knotenpool verwendet den Maschinentyp
ct5lp-hightpu-1t
mit einem TPU-Chip.
Wenn Sie eine andere Clusterkonfiguration als die zuvor beschriebene verwenden, müssen Sie das Manifest für die Serverbereitstellung bearbeiten.
Bereitstellung anwenden
kubectl apply -f jax/bert/serve-bert.yaml
Prüfen Sie, ob der Server ausgeführt wird:
kubectl get deployment bert-deployment
Es kann eine Minute dauern, bis AVAILABLE
3
liest.
Load-Balancer-Dienst anwenden
kubectl apply -f jax/bert/loadbalancer.yaml
Prüfen Sie, ob der Load Balancer für externen Traffic bereit ist:
kubectl get svc tf-bert-service
Es kann einige Minuten dauern, bis für EXTERNAL_IP
eine IP-Adresse aufgeführt wird.
Anfrage an den Modellserver senden
Externe IP-Adresse vom Load Balancer-Dienst abrufen:
EXTERNAL_IP=$(kubectl get services tf-bert-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Führen Sie ein Skript aus, um eine Anfrage an den Server zu senden:
python3 jax/bert/bert_request.py $EXTERNAL_IP
Erwartete Ausgabe:
For input "The capital of France is [MASK].", the result is ". the capital of france is paris.."
For input "Hello my name [MASK] Jhon, how can I [MASK] you?", the result is ". hello my name is jhon, how can i help you?."
Bereinigen
Führen Sie kubectl delete
in umgekehrter Reihenfolge aus, um die Ressourcen zu bereinigen.
kubectl delete -f jax/bert/loadbalancer.yaml kubectl delete -f jax/bert/serve-bert.yaml kubectl delete -f jax/bert/install-bert.yaml
JAX Stable Diffusion E2E-Bereitstellungsdemo ausführen
In dieser Demo wird das vortrainierte Stable Diffusion Model verwendet. von Hugging Face.
TPU-kompatibles TF2-Modell aus Flax Stable Diffusion-Modell exportieren
Zum Exportieren der stabilen Diffusionsmodelle muss der Cluster einen CPU-Knoten haben mit einem Maschinentyp mit mindestens 16 Gi verfügbarem Arbeitsspeicher, Cluster einrichten
Der Kubernetes-Pod führt die folgenden Schritte aus:
- Hier wird das Python-Script
export_stable_diffusion_model.py
aus den Beispielressourcen heruntergeladen und verwendet, um das vortrainierte Stable Diffusion-Modell in ein temporäres Verzeichnis herunterzuladen. - Das vortrainierte Modell wird mit dem Cloud TPU Converter-Image von der CPU auf die TPU konvertiert und im Cloud Storage-Bucket gespeichert, den Sie bei der Speichereinrichtung erstellt haben.
Dieser Kubernetes-Pod ist für die Ausführung im Standard-CPU-Knotenpool konfiguriert. Führen Sie den Pod mit dem folgenden Befehl:
kubectl apply -f jax/stable-diffusion/install-stable-diffusion.yaml
Prüfen Sie so, ob das Modell korrekt installiert wurde:
kubectl get pods install-stable-diffusion
Es kann einige Minuten dauern, bis STATUS
Completed
liest.
TF-Modellservercontainer für das Modell starten
Die Beispielarbeitslasten wurden mit den folgenden Annahmen konfiguriert:
- der Cluster mit einem TPU v5-Knotenpool mit drei Knoten ausgeführt wird
- der Knotenpool den Maschinentyp
ct5lp-hightpu-1t
verwendet, wobei Folgendes gilt:- Die Topologie ist 1x1.
- Anzahl der TPU-Chips: 1
Wenn Sie eine andere Clusterkonfiguration als die zuvor beschriebene verwenden, müssen Sie das Manifest für die Serverbereitstellung bearbeiten.
Wenden Sie die Bereitstellung an:
kubectl apply -f jax/stable-diffusion/serve-stable-diffusion.yaml
Prüfen Sie, ob der Server wie erwartet ausgeführt wird:
kubectl get deployment stable-diffusion-deployment
Es kann eine Minute dauern, bis AVAILABLE
3
liest.
Load Balancer-Dienst anwenden:
kubectl apply -f jax/stable-diffusion/loadbalancer.yaml
Prüfen Sie mit den folgenden Schritten, ob der Load-Balancer für externen Traffic bereit ist:
kubectl get svc tf-stable-diffusion-service
Es kann einige Minuten dauern, bis für EXTERNAL_IP
eine IP-Adresse aufgeführt wird.
Anfrage an den Modellserver senden
Rufen Sie eine externe IP-Adresse vom Load Balancer ab:
EXTERNAL_IP=$(kubectl get services tf-stable-diffusion-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Script zum Senden einer Anfrage an den Server ausführen
python3 jax/stable-diffusion/stable_diffusion_request.py $EXTERNAL_IP
Erwartete Ausgabe:
Der Prompt lautet Painting of a squirrel skating in New York
und das Ausgabebild
wird als stable_diffusion_images.jpg
im aktuellen Verzeichnis gespeichert.
Bereinigen
Führen Sie kubectl delete
in umgekehrter Reihenfolge aus, um die Ressourcen zu bereinigen.
kubectl delete -f jax/stable-diffusion/loadbalancer.yaml kubectl delete -f jax/stable-diffusion/serve-stable-diffusion.yaml kubectl delete -f jax/stable-diffusion/install-stable-diffusion.yaml
Demo für die End-to-End-Bereitstellung von TensorFlow ResNet-50 ausführen:
Installieren Sie Python-Abhängigkeiten, um die Python-Scripts aus der Anleitung auszuführen, die Anfragen an den TF-Modelldienst senden.
pip install -r tf/resnet50/requirements.txt
Schritt 1: Modell konvertieren
Modellkonvertierung anwenden:
kubectl apply -f tf/resnet50/model-conversion.yml
Prüfen Sie mit den folgenden Schritten, ob das Modell richtig installiert wurde:
kubectl get pods resnet-model-conversion
Es kann einige Minuten dauern, bis STATUS
Completed
liest.
Schritt 2: Modell mit TensorFlow-Bereitstellung bereitstellen
Bereitstellung des Modells einrichten:
kubectl apply -f tf/resnet50/deployment.yml
Prüfen Sie mit dem folgenden Befehl, ob der Server wie erwartet ausgeführt wird:
kubectl get deployment resnet-deployment
Es kann eine Minute dauern, bis AVAILABLE
3
liest.
Load Balancer-Dienst anwenden:
kubectl apply -f tf/resnet50/loadbalancer.yml
Prüfen Sie mit den folgenden Schritten, ob der Load-Balancer für externen Traffic bereit ist:
kubectl get svc resnet-service
Es kann einige Minuten dauern, bis für EXTERNAL_IP
eine IP-Adresse aufgeführt wird.
Schritt 3: Testanfrage an den Modellserver senden
Rufen Sie die externe IP-Adresse vom Load Balancer ab:
EXTERNAL_IP=$(kubectl get services resnet-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Führen Sie das Testanfrageskript (HTTP) aus, um die Anfrage an den Modellserver zu senden.
python3 tf/resnet50/request.py --host $EXTERNAL_IP
Die Antwort sollte in etwa so aussehen:
Predict result: ['ImageNet ID: n07753592, Label: banana, Confidence: 0.94921875', 'ImageNet ID: n03532672, Label: hook, Confidence: 0.0223388672', 'ImageNet ID: n07749582, Label: lemon, Confidence: 0.00512695312
Schritt 4: Bereinigen
Führen Sie die folgenden kubectl delete
-Befehle aus, um Ressourcen zu bereinigen:
kubectl delete -f tf/resnet50/loadbalancer.yml kubectl delete -f tf/resnet50/deployment.yml kubectl delete -f tf/resnet50/model-conversion.yml
Achten Sie darauf, dass Sie den GKE-Knotenpool löschen und Cluster wenn Sie mit ihnen fertig sind.
Inferenz und Bereitstellung von PyTorch-Modellen
Installieren Sie Python-Abhängigkeiten zum Ausführen von Python-Skripten in dieser Anleitung, die Anfragen an den PyTorch-Modelldienst gesendet:
pip install -r pt/densenet161/requirements.txt
Demo zum Ausführen von TorchServe Densenet161 E2E-Bereitstellung:
Modellarchiv generieren
- Modellarchiv anwenden:
kubectl apply -f pt/densenet161/model-archive.yml
- Prüfen Sie so, ob das Modell korrekt installiert wurde:
kubectl get pods densenet161-model-archive
Es kann einige Minuten dauern, bis
STATUS
Completed
liest.Das Modell mit TorchServe bereitstellen:
Modellbereitstellungs-Deployment anwenden:
kubectl apply -f pt/densenet161/deployment.yml
Überprüfen Sie mit dem folgenden Befehl, ob der Server wie erwartet ausgeführt wird:
kubectl get deployment densenet161-deployment
Es kann eine Minute dauern, bis
AVAILABLE
3
liest.Wenden Sie den Load-Balancer-Dienst an:
kubectl apply -f pt/densenet161/loadbalancer.yml
Prüfen Sie, ob der Load-Balancer für externen Traffic mit der folgenden Befehl:
kubectl get svc densenet161-service
Es kann einige Minuten dauern, bis für
EXTERNAL_IP
eine IP-Adresse angezeigt wird.
Testanfrage an den Modellserver senden:
Externe IP-Adresse vom Load Balancer abrufen:
EXTERNAL_IP=$(kubectl get services densenet161-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
Führen Sie das Testanfrageskript aus, um die Anfrage (HTTP) an den Modellserver zu senden:
python3 pt/densenet161/request.py --host $EXTERNAL_IP
Sie sollten eine Antwort wie die folgende sehen:
Request successful. Response: {'tabby': 0.47878125309944153, 'lynx': 0.20393909513950348, 'tiger_cat': 0.16572578251361847, 'tiger': 0.061157409101724625, 'Egyptian_cat': 0.04997897148132324
Bereinigen Sie die Ressourcen mit den folgenden
kubectl delete
-Befehlen:kubectl delete -f pt/densenet161/loadbalancer.yml kubectl delete -f pt/densenet161/deployment.yml kubectl delete -f pt/densenet161/model-archive.yml
Achten Sie darauf, dass Sie den GKE-Knotenpool löschen und gruppieren, wenn Sie damit erledigt sind.
Fehlerbehebung – allgemeine Probleme
Informationen zur GKE-Fehlerbehebung finden Sie unter Fehlerbehebung bei TPU in GKE
TPU-Initialisierung fehlgeschlagen
Wenn der folgende Fehler auftritt, prüfen Sie, ob Sie Ihre TPU ausführen
sich im privilegierten Modus befindet oder die Anzahl der ulimit
in Ihrem
Container. Weitere Informationen finden Sie unter Ausführen ohne privilegierten Modus.
TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance
Planungs-Deadlock
Angenommen, Sie haben zwei Jobs (Job A und Job B), die beide auf TPU-Slices mit einer bestimmten TPU-Topologie (z. B. v4-32
) geplant werden sollen. Angenommen, Sie haben zwei v4-32
-TPU-Slices im GKE-Cluster, die wir Slice X und Slice Y nennen. Da Ihr Cluster über genügend Kapazität verfügt, um beide Jobs zu planen, sollten beide Jobs theoretisch schnell geplant werden – ein Job auf jedem der beiden TPU v4-32
-Slices.
Ohne sorgfältige Planung kann es jedoch zu einer Planungsblockade kommen. Angenommen, der Kubernetes-Planer plant einen Kubernetes-Pod aus Job A in Slice X und dann einen Kubernetes-Pod aus Job B in Slice X. In In diesem Fall führt der Planer bei den Kubernetes-Pod-Affinitätsregeln für Job A versuchen, alle verbleibenden Kubernetes-Pods für Job A in Segment X zu planen. Das gilt auch für Job B. Daher können weder Job A noch Job B vollständig auf einem einzelnen Ausschnitt geplant werden. Das Ergebnis ist ein Planungsdeadlock.
Um das Risiko eines Planungs-Deadlocks zu vermeiden, können Sie den Kubernetes-Pod verwenden
Anti-Affinität mit cloud.google.com/gke-nodepool
als topologyKey
, wie gezeigt
im folgenden Beispiel:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
parallelism: 2
template:
metadata:
labels:
job: pi
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job
operator: In
values:
- pi
topologyKey: cloud.google.com/gke-nodepool
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: job
operator: NotIn
values:
- pi
topologyKey: cloud.google.com/gke-nodepool
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- kube-system
containers:
- name: pi
image: perl:5.34.0
command: ["sleep", "60"]
restartPolicy: Never
backoffLimit: 4
TPU-Knotenpoolressourcen mit Terraform erstellen
Sie können auch Terraform verwenden. um Ihre Cluster- und Knotenpoolressourcen zu verwalten.
TPU-Slice-Knotenpool mit mehreren Hosts in einem vorhandenen GKE-Cluster erstellen
Wenn Sie einen vorhandenen Cluster haben, in dem Sie eine TPU mit mehreren Hosts erstellen möchten Knotenpools können Sie das folgende Terraform-Snippet verwenden:
resource "google_container_cluster" "cluster_multi_host" {
…
release_channel {
channel = "RAPID"
}
workload_identity_config {
workload_pool = "my-gke-project.svc.id.goog"
}
addons_config {
gcs_fuse_csi_driver_config {
enabled = true
}
}
}
resource "google_container_node_pool" "multi_host_tpu" {
provider = google-beta
project = "${project-id}"
name = "${node-pool-name}"
location = "${location}"
node_locations = ["${node-locations}"]
cluster = google_container_cluster.cluster_multi_host.name
initial_node_count = 2
node_config {
machine_type = "ct4p-hightpu-4t"
reservation_affinity {
consume_reservation_type = "SPECIFIC_RESERVATION"
key = "compute.googleapis.com/reservation-name"
values = ["${reservation-name}"]
}
workload_metadata_config {
mode = "GKE_METADATA"
}
}
placement_policy {
type = "COMPACT"
tpu_topology = "2x2x2"
}
}
Ersetzen Sie die folgenden Werte:
your-project
: Ihr Google Cloud-Projekt, in dem Sie die Arbeitslast ausführen.your-node-pool
: Der Name des Knotenpools, den Sie erstellen.us-central2
: Die Region, in der Sie Ihre Arbeitslast ausführen.us-central2-b
: Die Zone, in der Sie Ihre Arbeitslast ausführen.your-reservation-name
: Der Name Ihrer Reservierung.
TPU-Slice-Knotenpool mit einem Host in einem vorhandenen GKE-Cluster erstellen
Verwenden Sie das folgende Terraform-Snippet:
resource "google_container_cluster" "cluster_single_host" {
…
cluster_autoscaling {
autoscaling_profile = "OPTIMIZE_UTILIZATION"
}
release_channel {
channel = "RAPID"
}
workload_identity_config {
workload_pool = "${project-id}.svc.id.goog"
}
addons_config {
gcs_fuse_csi_driver_config {
enabled = true
}
}
}
resource "google_container_node_pool" "single_host_tpu" {
provider = google-beta
project = "${project-id}"
name = "${node-pool-name}"
location = "${location}"
node_locations = ["${node-locations}"]
cluster = google_container_cluster.cluster_single_host.name
initial_node_count = 0
autoscaling {
total_min_node_count = 2
total_max_node_count = 22
location_policy = "ANY"
}
node_config {
machine_type = "ct4p-hightpu-4t"
workload_metadata_config {
mode = "GKE_METADATA"
}
}
}
Ersetzen Sie die folgenden Werte:
your-project
: Ihr Google Cloud-Projekt, in dem Sie die Arbeitslast ausführen.your-node-pool
: Der Name des Knotenpools, den Sie erstellen.us-central2
: Die Region, in der Sie Ihre Arbeitslast ausführen.us-central2-b
: Die Zone, in der Sie Ihre Arbeitslast ausführen.