Einführung in TPUs in GKE

Google Kubernetes Engine (GKE)-Kunden können jetzt Kubernetes-Knotenpools mit TPU v4- und v5e-Scheiben erstellen. Weitere Informationen zu TPUs finden Sie unter Systemarchitektur.

Wenn Sie mit GKE arbeiten, müssen Sie zuerst einen GKE-Cluster erstellen. Anschließend fügen Sie dem Cluster Knotenpools hinzu. 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 zwei oder mehr verbundene TPU-VMs enthält. Jede VM ist mit einem TPU-Gerät verbunden. Die TPUs in einem Multi-Host-Slice sind über eine Hochgeschwindigkeits-Interconnect-Verbindung (ICI) verbunden. Nachdem ein Knotenpool mit mehreren Hosts erstellt wurde, können Sie ihm keine Knoten mehr hinzufügen. Sie können beispielsweise keinen v4-32-Knotenpool erstellen und dem Knotenpool dann später einen zusätzlichen Kubernetes-Knoten (TPU-VM) hinzufügen. 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 einzelne atomare Einheit behandelt. Wenn GKE keinen Knoten im Slice bereitstellen kann, werden keine Knoten im Slice bereitgestellt.

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 einsatzbereit sind, können die Kubernetes-Pods 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.

Diagramm für TPU-Slices mit mehreren Hosts

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):

TPU v5e-Pod-Diagramm

Ein Beispiel für die Ausführung einer Arbeitslast auf einem TPU-Segment 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. Jede VM ist mit einem TPU-Gerät verbunden. Die VMs in einem Slice-Knotenpool mit einem einzelnen Host können zwar über das Data Center Network (DCN) kommunizieren, die an die VMs angehängten TPUs sind jedoch nicht miteinander verbunden.

Das folgende Diagramm zeigt ein Beispiel für ein TPU-Speicher-Slice mit einem einzelnen Host und sieben v4-8-Maschinen:

Diagramm: Knotenpool für Slices mit einem Host

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 die Größe des TPU-Slices auswählen, die für Ihre Arbeitslast erforderlich sind. TPU v4 wird in der GKE-Standardversion 1.26.1-gke.1500 und höher, TPU v5e in der GKE-Standardversion 1.27.2-gke.2100 und höher und TPU v5p in der GKE-Standardversion 1.28.3-gke.1024000 und höher unterstützt.

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. Wählen Sie beim Erstellen eines TPU-Knotenpools eine TPU-Slice-Größe (eine TPU-Topologie) basierend auf der Größe Ihres Modells und dem erforderlichen Arbeitsspeicher aus. Der Maschinentyp, den Sie beim Erstellen Ihrer Knotenpools angeben, hängt von der Version und Größe Ihrer Slices ab.

v5e

Die folgenden TPU v5e-Maschinentypen und ‑Topologien werden für Anwendungsfälle für Training und Inferenz unterstützt:

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 mit einem einzelnen Host
ct5lp-hightpu-8t 2x4 8 1 Training, Inferenz mit einem einzelnen Host
ct5lp-hightpu-4t 2x4 8 2 Training, Multihost-Inferenz
ct5lp-hightpu-4t 4x4 16 4 Umfangreiches Training, Multihost-Inferenz
ct5lp-hightpu-4t 4x8 32 8 Umfangreiches Training, Multihost-Inferenz
ct5lp-hightpu-4t 8x8 64 16 Umfangreiches Training, Multihost-Inferenz
ct5lp-hightpu-4t 8x16 128 32 Umfangreiches Training, Multihost-Inferenz
ct5lp-hightpu-4t 16x16 256 64 Umfangreiches Training, Multihost-Inferenz

Cloud TPU v5e ist ein kombiniertes Produkt für Training und Inferenz. Trainingsjobs sind für Durchsatz und Verfügbarkeit optimiert, während Inferenzjobs für Latenz optimiert sind. Weitere Informationen finden Sie unter Beschleunigertypen für v5e Training und Beschleunigertypen für v5e-Inferenz.

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. Für GKE Autopilot muss die Steuerungsebene Version 1.29.2-gke.1521000 oder höher 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. Daher werden VMs mit 8 Chips mit höherer Wahrscheinlichkeit von VMs mit 1 und 4 Chips unterbrochen.

v4 und v5p

Die folgenden Maschinentypen sind TPU v4- und TPU v5p:

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-Slabs den Maschinentyp ct4p-hightpu-4t mit einem Host und 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. Auf GKE Autopilot-Clustern muss die Steuerungsebenen-Version 1.29.2-gke.1521000 oder höher ausgeführt werden.

Verwenden Sie beim Erstellen eines TPU v5p-Slabs den Maschinentyp ct5p-hightpu-4t mit einem Host und 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 sein. Weitere Informationen zu v5p finden Sie unter Einführung in 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 BESONDERE Reservierungen: Wenn Sie TPUs in GKE verwenden, ist SPECIFIC der einzige unterstützte Wert für das Flag --reservation-affinity des Befehls gcloud container node-pools create.
  • Nur die Spot-VM-Variante von TPUs auf Abruf wird unterstützt: Spot-VMsähneln VMs auf Abruf und unterliegen denselben Verfügbarkeitsbeschränkungen, haben jedoch keine maximale Dauer von 24 Stunden.
  • Keine Unterstützung für die Kostenzuordnung: Die GKE-Kostenzuordnung und die Nutzungsmessung enthalten keine Daten zur Nutzung oder zu den Kosten von TPUs.
  • Autoscaler kann Kapazität berechnen: Die 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.
  • Autoscaler bricht Hochskalierung ab: Der Cluster-Autoscaler bricht das Hochskalieren von TPU-Knotenpools ab, die länger als 10 Stunden im Wartestatus verbleiben. Cluster Autoscaler wiederholt solche Hochskalierungsversuche später. Dieses Verhalten kann die TPU-Erreichbarkeit für Kunden reduzieren, die keine Reservierungen verwenden.
  • 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 mindestens so hoch wie das Produkt aus der maximalen Anzahl der GKE-Knoten, die Sie voraussichtlich erstellen werden, und 100 GB sein.
  • Kontingent für genutzte IP-Adressen: Jeder Kubernetes-Knoten verbraucht eine IP-Adresse. Daher sollte dieses Kontingent mindestens so hoch sein wie die maximale Anzahl von GKE-Knoten, die Sie voraussichtlich erstellen werden.

Wie Sie ein höheres Kontingent anfordern, erfahren Sie unter Höheres Kontingent anfordern. Weitere Informationen zu den Arten von TPU-Kontingenten finden Sie unter TPU-Kontingent.

Es kann einige Tage dauern, bis Ihre Anfragen zur Kontingenterhöhung genehmigt werden. Wenn Ihre Anfragen zur Kontingenterhöhung nicht innerhalb weniger Tage genehmigt werden, wenden Sie sich 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.

Bei dieser Migration gibt es einige wichtige Dinge zu beachten:

  • TPU-Kapazität, die zum neuen Compute Engine-basierten Reservierungssystem migriert wurde, kann nicht mit der Queued Resource API von Cloud TPU verwendet werden. Wenn Sie TPU-Warteschlangenressourcen mit Ihrer Reservierung verwenden möchten, müssen Sie einen Teil Ihrer TPU-Reservierung zum neuen Compute Engine-basierten Reservierungssystem migrieren.
  • 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 planen Sie sie gemeinsam mit Ihrem Google Cloud-Kontoteam. Die Migration muss während der Geschäftszeiten erfolgen (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 reduzieren möchten, lesen Sie den Hilfeartikel Berechtigungsmodus für TPU.

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 jede Arbeitslast zwei Selektoren angeben:

  • Legen Sie cloud.google.com/gke-accelerator-type auf tpu-v5-lite-podslice, tpu-v5p-slice oder tpu-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 in der GKE-Dokumentation unter Überlegungen zur Arbeitslastplanung.

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.

Mehrere Segmente – mehr als nur 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 für die Arbeitslast des Trainings

In diesen Anleitungen liegt der Schwerpunkt auf Trainingslasten auf einem TPU-Slice mit mehreren Hosts (z. B. 4 v5e-Maschinen). Sie gelten für die folgenden Modelle:

  • Hugging Face FLAX-Modelle: Diffusion mit Pokémon trainieren
  • PyTorch/XLA: GPT2 auf 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. Außerdem werden durch den Befehl die Funktionen „Workload Identity Federation for GKE“ und „Cloud Storage FUSE CSI-Treiber“ in Ihrem Cluster aktiviert, da in den Beispielinferenzarbeitslasten in diesem Leitfaden vorab trainierte Modelle in Cloud Storage-Buckets gespeichert werden.

gcloud container clusters create cluster-name \
  --region your-region \
  --release-channel rapid \
  --num-nodes=1 \
  --workload-pool=project-id.svc.id.goog \
  --addons GcsFuseCsiDriver

Führen Sie den folgenden Befehl aus, um die Identitätsföderation von Arbeitslasten für GKE und die Funktionen des CSI-Treibers für Cloud Storage FUSE für vorhandene Cluster zu aktivieren:

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: Diffusion mit Pokémon trainieren

In diesem Beispiel wird das Stable Diffusion-Modell von Hugging Face mit dem Pokémon-Dataset trainiert.

Das Stable Diffusion-Modell ist ein latentes Text-zu-Bild-Modell, das fotorealistische Bilder aus beliebigen Texteingaben generiert. Weitere Informationen zu Stable Diffusion finden Sie unter:

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 dem folgenden 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 Sie GPT2 auf v5e-TPUs mit HuggingFace auf PyTorch/XLA mit dem Wikitext-Dataset ausführen.

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 das folgende YAML-Manifest und speichern Sie es in einer Datei mit dem Namen tpu_job_gpt.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-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 erfahren Sie, wie Sie eine Inferenzarbeitslast mit einem einzelnen Host auf GKE v5e-TPUs für vorab trainierte Modelle mit JAX, TensorFlow und PyTorch ausführen. Im Wesentlichen sind vier separate Schritte für den GKE-Cluster erforderlich:

  1. Erstellen Sie einen Cloud Storage-Bucket und richten Sie den Zugriff darauf ein. Sie verwenden einen Cloud Storage-Bucket, um das vortrainierte Modell zu speichern.

  2. Laden Sie ein vortrainiertes Modell herunter und konvertieren Sie es in ein TPU-kompatibles Modell. Wenden Sie einen Kubernetes-Pod an, der das vortrainierte Modell herunterlädt, den Cloud TPU-Konverter verwendet und die konvertierten Modelle mit dem Cloud Storage FUSE CSI-Treiber in einem Cloud Storage-Bucket speichert. Für den Cloud TPU Converter ist keine spezielle Hardware erforderlich. In dieser Anleitung erfahren Sie, wie Sie das Modell herunterladen und den Cloud TPU-Konverter im CPU-Knotenpool ausführen.

  3. 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 im nichtflüchtigen Volume ReadOnlyMany (ROX) unterstützt wird. Die Deployment-Replikate müssen in einem v5e-Slice-Knotenpool mit einem Kubernetes-Pod pro Knoten ausgeführt werden.

  4. 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-Script mit einer Beispielanfrage zum Testen des Modellservers bereitgestellt.

Das folgende Diagramm zeigt, wie Anfragen vom Load Balancer weitergeleitet werden.

Diagramm mit Load Balancer-Routing

Beispiele für die Serverbereitstellung

Bei diesen Beispielarbeitslasten werden die folgenden Annahmen getroffen:

  • 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 ist 1

Das folgende GKE-Manifest definiert eine Bereitstellung mit einem einzelnen Hostserver.

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 in Ihrem Standardcluster GKE 1.27 oder niedriger ausgeführt wird, fügen Sie Ihrem Manifest das folgende Feld hinzu:

spec:
  securityContext:
    privileged: true

In GKE-Version 1.28 oder höher müssen Sie Kubernetes-Pods nicht im privilegierten Modus ausführen. 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 verwendeten Maschinentyp fest.
  • Legen Sie die beiden google.com/tpu-Felder unter resources so fest, dass sie der Anzahl der Chips für den entsprechenden Maschinentyp entsprechen.

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 in dieser Anleitung verwendeten Python-Scripts ist Python Version 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

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

  2. Erstellen Sie den TPU-Knotenpool mit einem Host.

Für die Beispielarbeitslasten wird Folgendes vorausgesetzt:

  • Ihr Cluster wird mit einem TPU v5e-Knotenpool mit drei Knoten ausgeführt.
  • Der TPU-Knotenpool verwendet den Maschinentyp ct5lp-hightpu-1t.

Wenn Sie eine andere Clusterkonfiguration als die zuvor beschriebene 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 einem Maschinentyp mit mindestens 16 GiB Arbeitsspeicher (z. B. e2-standard-4). Dies wird mit dem Befehl gcloud container clusters create konfiguriert oder indem Sie dem vorhandenen Cluster mit dem folgenden Befehl einen zusätzlichen Knotenpool hinzufügen:

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.

Speicher für Modelle einrichten

Es gibt mehrere Möglichkeiten, Ihr Modell für die Bereitstellung zu speichern. In dieser Anleitung gehen wir so vor:

  • Für die Umwandlung des vorab trainierten Modells für die Verwendung auf TPUs verwenden wir eine Virtual Private Cloud, die von einem Persistent Disk mit ReadWriteMany-Zugriff (Lesen/Schreiben/Ausführen) unterstützt wird.
  • Für das Bereitstellen des Modells auf mehreren TPUs mit einem einzelnen Host verwenden wir dieselbe VPC, die vom Cloud Storage-Bucket unterstützt wird.

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 Projekt-ID, unter der Sie den Cloud Storage-Bucket erstellt haben.
  • your-bucket-location: Der Speicherort Ihres Cloud Storage-Bucket. Geben Sie den Standort an, an dem Ihr GKE-Cluster ausgeführt wird, um die Leistung zu verbessern.

Führen Sie die folgenden Schritte aus, um Ihrem GKE-Cluster Zugriff auf den Bucket zu gewähren. Zur Vereinfachung der Einrichtung werden in den folgenden Beispielen der Standard-Namespace und das Standard-Kubernetes-Dienstkonto verwendet. Weitere Informationen finden Sie unter Zugriff auf Cloud Storage-Buckets mit der GKE-Workload Identity-Föderation für GKE konfigurieren.

  1. 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-Bucket 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-Dienstkontos.
    • 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.

  2. Achten Sie darauf, dass Ihr IAM-Dienstkonto die erforderlichen Speicherrollen hat.

    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-Buckets
    • your-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.

  3. Erlauben Sie dem Kubernetes-Dienstkonto, die Identität des IAM-Dienstkontos zu übernehmen. Fügen Sie dazu eine IAM-Richtlinienbindung zwischen den beiden Dienstkonten hinzu. Durch diese Bindung kann das Kubernetes-Dienstkonto als IAM-Dienstkonto verwendet werden.

    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-Dienstkontos.
    • 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 können sich im selben oder in verschiedenen Projekten befinden.

  4. 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-Dienstkontos.
    • your-bucket-project-id: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto erstellt haben.

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

  6. Erstellen Sie das nichtflüchtige Volume und den Anspruch auf ein nichtflüchtiges Volume mit dem folgenden Befehl:

    kubectl apply -f pvc-pv.yaml

JAX-Modellinferenz und ‑bereitstellung

Installieren Sie Python-Abhängigkeiten, um die Python-Scripts aus dem Tutorial auszuführen, die Anfragen an den JAX-Modelldienst senden.

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:

  1. 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.
  2. Das Cloud TPU Converter-Image wird verwendet, um das vorab trainierte Modell von der CPU auf die TPU zu konvertieren. Das Modell wird dann im Cloud Storage-Bucket gespeichert, den Sie bei der Einrichtung erstellt haben.

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 aus:

kubectl apply -f jax/bert/install-bert.yaml

Prüfen Sie mit den folgenden Schritten, ob das Modell richtig 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 Script 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

Demo für die E2E-Bereitstellung von JAX Stable Diffusion ausführen

In dieser Demo wird das vortrainierte Stable Diffusion-Modell von Hugging Face verwendet.

TPU-kompatibles TF2-SavedModel aus Flax Stable Diffusion-Modell exportieren

Zum Exportieren der stabilen Diffusionsmodelle muss der Cluster einen CPU-Knotenpool mit einem Maschinentyp haben, der mindestens 16 GiB Arbeitsspeicher hat, wie unter Cluster einrichten beschrieben.

Der Kubernetes-Pod führt die folgenden Schritte aus:

  1. 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.
  2. 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 aus:

kubectl apply -f jax/stable-diffusion/install-stable-diffusion.yaml

Prüfen Sie mit den folgenden Schritten, ob das Modell richtig 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 ist 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, 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 ist 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 Serving 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, 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 Testanfrage-Script (HTTP) aus, um eine 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

Löschen Sie den GKE-Knotenpool und den Cluster, wenn Sie sie nicht mehr benötigen.

PyTorch-Modellinferenz und -bereitstellung

Installieren Sie Python-Abhängigkeiten, um die Python-Scripts aus der Anleitung auszuführen, die Anfragen an den PyTorch-Modelldienst senden:

pip install -r pt/densenet161/requirements.txt

Demo für den E2E-Bereitstellungsdienst von TorchServe Densenet161 ausführen:

  1. Modellarchiv generieren

    1. Modellarchiv anwenden:
    kubectl apply -f pt/densenet161/model-archive.yml
    1. Prüfen Sie mit den folgenden Schritten, ob das Modell richtig installiert wurde:
    kubectl get pods densenet161-model-archive

    Es kann einige Minuten dauern, bis STATUS Completed liest.

  2. Modell mit TorchServe bereitstellen:

    1. Bereitstellung des Modell-Einsatzes anwenden:

      kubectl apply -f pt/densenet161/deployment.yml

    2. Prü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.

    3. Load Balancer-Dienst anwenden:

      kubectl apply -f pt/densenet161/loadbalancer.yml

      Prüfen Sie mit dem folgenden Befehl, ob der Load Balancer für externen Traffic bereit ist:

      kubectl get svc densenet161-service

      Es kann einige Minuten dauern, bis für EXTERNAL_IP eine IP-Adresse aufgeführt wird.

  3. Testanfrage an den Modellserver senden:

    1. Externe IP-Adresse vom Load Balancer abrufen:

      EXTERNAL_IP=$(kubectl get services densenet161-service --output jsonpath='{.status.loadBalancer.ingress[0].ip}')

    2. Führen Sie das Testanfrage-Script aus, um eine Anfrage (HTTP) an den Modellserver zu senden:

      python3 pt/densenet161/request.py --host $EXTERNAL_IP

      Sie sollten eine Antwort in folgender Form zurückerhalten:

      Request successful. Response: {'tabby': 0.47878125309944153, 'lynx': 0.20393909513950348, 'tiger_cat': 0.16572578251361847, 'tiger': 0.061157409101724625, 'Egyptian_cat': 0.04997897148132324

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

    Löschen Sie den GKE-Knotenpool und den Cluster, wenn Sie sie nicht mehr benötigen.

Fehlerbehebung – allgemeine Probleme

Informationen zur Fehlerbehebung in GKE finden Sie unter Fehlerbehebung bei TPUs in GKE.

TPU-Initialisierung fehlgeschlagen

Wenn der folgende Fehler auftritt, prüfen Sie, ob Sie Ihren TPU-Container entweder im privilegierten Modus ausführen oder ulimit im Container erhöht haben. 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. Außerdem haben Sie 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 diesem Fall versucht der Planer unter Berücksichtigung der Kubernetes-Pod-Affinitätsregeln für Job A, alle verbleibenden Kubernetes-Pods für Job A in Slice 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 Planungsdeadlocks zu vermeiden, können Sie die Kubernetes-Pod-Anti-Affinität mit cloud.google.com/gke-nodepool als topologyKey verwenden, wie im folgenden Beispiel gezeigt:

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 Ihre Cluster- und Knotenpoolressourcen auch mit Terraform verwalten.

TPU-Slice-Knotenpool mit mehreren Hosts in einem vorhandenen GKE-Cluster erstellen

Wenn Sie einen vorhandenen Cluster haben, in dem Sie einen TPU-Knotenpool mit mehreren Hosts erstellen möchten, 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 Ihre 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 Ihre 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.