Einführung in TPUs in GKE

Google Kubernetes Engine-Kunden (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, die dieselben Attribute. 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 ein Slice mit mehreren Hosts über eine Hochgeschwindigkeits-Interconnect-Verbindung (ICI) verbunden ist. Sobald ein Slice-Knotenpool mit mehreren Hosts erstellt wurde. Sie können ihm keine Knoten 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. Um ein zusätzliches TPU-Slice zu einem GKE-Cluster 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, alle TPU-VMs im Slice werden heruntergefahren, wodurch alle Kubernetes-Pods in der zu entfernende Arbeitslast. 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 v5litepod-16 (v5e)-TPU mit mehreren Hosts Segment. Dieses Slice hat vier TPU-VMs. Mit jeder TPU-VM sind vier TPU v5e-Chips verbunden mit Hochgeschwindigkeits-Interconnect-Verbindungen (ICI) und jeder TPU v5e-Chip hat einen TensorCore-Prozessor.

TPU-Slice-Diagramm mit mehreren Hosts

Das folgende Diagramm zeigt einen GKE-Cluster, der einen enthält TPU v5litepod-16 (v5e)-Slice (Topologie: 4x4) und ein TPU v5litepod-8 (v5e) Slice (Topologie: 2x4):

TPU v5e Pod-Diagramm

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 einzelnem Host

Ein Knotenpool mit einem einzelnen Host-Slice ist ein Knotenpool, der einen oder mehrere unabhängige TPU-VMs. 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 und sieben v4-8 Maschinen:

Diagramm eines Slice-Knotenpools mit einem einzelnen 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 -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 unterstützt Version 1.29.2-gke.1521000 und höher.

Weitere Informationen zu den Hardwarespezifikationen der verschiedenen TPUs 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. Den von Ihnen angegebenen Maschinentyp bei der Erstellung von Knotenpools abhängig von der Version und Größe der Segmente.

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 eines einzelnen Hosts
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 optimiert für Durchsatz und Verfügbarkeit, während Inferenzjobs für Latenz. 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. GKE-Standardcluster müssen die Steuerungsebene ausführen Version 1.27.2-gke.2100 oder höher. GKE Autopilot muss mindestens Version 1.29.2-gke.1521000 der Steuerungsebene ausführen. Weitere Informationen 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-Planer 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. Siehe v4-Topologien und die TPU-Systemarchitektur Informationen. TPU v4-Slice-Maschinentypen sind in us-central2-b verfügbar. Ihr GKE-Standardcluster müssen die Steuerungsebene ausführen Version 1.26.1-gke.1500 oder höher. 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-Slice-Maschinentypen sind verfügbar in us-west4-a und us-east5-a. GKE Standard Cluster müssen mindestens Version 1.28.3-gke.1024000 der Steuerungsebene ausführen. GKE Autopilot muss 1.29.2-gke.1521000 ausführen oder . 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 ausführen. Kubernetes-Pods in einer einzelnen TPU-VM.
  • Nur BESTIMMTE Reservierungen: Bei der Verwendung von TPUs in GKE: SPECIFIC ist der einzige unterstützte Wert für das Flag --reservation-affinity des Befehls gcloud 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.
  • Autoscaling kann die Kapazität berechnen: Cluster-Autoscaling kann Kapazität für neue Knoten mit TPU-VMs falsch eingestellt werden, bevor diese Knoten verfügbar. Cluster Autoscaler kann dann eine zusätzliche Skalierung vornehmen, mehr Knoten als nötig erzeugen. Cluster-Autoscaling wird herunterskaliert zusätzliche Knoten, wenn diese nicht benötigt werden, nach dem regulären Herunterskalieren.
  • 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 verringert die TPU-Verfügbarkeit für Kunden, die keine Reservierungen verwenden.
  • Markierung kann das Herunterskalieren verhindern: Nicht-TPU-Arbeitslasten, die eine Toleranz für Die TPU-Markierung kann das Herunterskalieren des Knotenpools verhindern, wenn dieser neu erstellt wird während des Ausgleichs des TPU-Knotenpools.

Ausreichende TPU- und GKE-Kontingente sicherstellen

Möglicherweise müssen Sie bestimmte GKE-bezogene Kontingente in Die Regionen, in denen Ihre Ressourcen erstellt werden.

Die folgenden Kontingente haben Standardwerte, die wahrscheinlich erhöht werden müssen:

  • Kontingent für nichtflüchtigen SSD-Speicher (GB): Das Bootlaufwerk jedes Kubernetes-Knotens. erfordert standardmäßig 100 GB. Daher sollte dieses Kontingent auf mindestens hoch (die maximale Anzahl von GKE-Knoten, die Sie erwarten erstellen) * 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 Erhöhung des Kontingents 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 mit Google Kubernetes Engine-Cluster erstellen fort.

Damit Sie reservierte TPUs mit GKE verwenden können, müssen Sie zuerst TPU-Reservierung zu einer neuen Compute Engine-basierten Reservierung migrieren System.

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, werden Sie 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 zum neuen Compute Engine-basierten Reservierungssystem.
  • 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 unter Cluster erstellen in der Google Kubernetes Engine-Dokumentation.

TPU-Knotenpool erstellen

Siehe Knotenpool erstellen in der Google Kubernetes Engine-Dokumentation.

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

Siehe GKE-Arbeitslasten auf TPUs ausführen in der Google Kubernetes Engine-Dokumentation.

Knotenselektoren

Damit Kubernetes Ihre Arbeitslast auf Knoten planen kann, die TPU-VMs enthalten, müssen Sie in Ihrem Google Kubernetes Engine-Manifest zwei Selektoren für jeden Knoten angeben:

  • Setzen Sie cloud.google.com/gke-accelerator-type auf tpu-v5-lite-podslice oder tpu-v4-podslice
  • Legen Sie cloud.google.com/gke-tpu-topology auf die TPU-Topologie des Knotens fest.

Die Trainingsarbeitslasten und Inferenzarbeitslasten -Abschnitte 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, der gesamte Knotenpool neu erstellt. Weitere Informationen finden Sie unter Automatische Knotenreparatur. in der GKE-Dokumentation.

Multislice - über ein einzelnes Segment hinaus

Sie können kleinere Segmente in einem Multislice zusammenfassen, um größere Segmente Trainingsarbeitslasten. Weitere Informationen finden Sie unter Cloud TPU Multislice.

Anleitungen für Trainingsarbeitslasten

In diesen Anleitungen geht es um das Trainieren von Arbeitslasten auf einem TPU-Slice mit mehreren Hosts (für Beispiel: 4 v5e-Maschinen). Sie decken die folgenden Modelle ab:

  • Hugging Face FLAX-Modelle: Trainiere die Streuung von Pokémon
  • PyTorch/XLA: GPT2 in WikiText

Anleitungsressourcen herunterladen

Python-Skripts und YAML-Spezifikationen für jedes vortrainierte Modell herunterladen mit dem folgenden Befehl:

git clone https://github.com/GoogleCloudPlatform/ai-on-gke.git

Erstellen und mit Cluster verbinden

Einen regionalen GKE-Cluster erstellen, damit das Kubernetes wird die Steuerungsebene in drei Zonen repliziert, was für eine höhere Verfügbarkeit sorgt. Erstellen Sie den Cluster in us-west4, us-east1 oder us-central2, je nachdem, TPU-Version, die Sie verwenden. Weitere Informationen zu TPUs und Zonen finden Sie unter Cloud TPU-Regionen und -Zonen.

Mit dem folgenden Befehl wird ein neuer regionaler GKE-Cluster erstellt haben den Kanal für schnelle Releases mit einem Knotenpool abonniert, der ursprünglich ein Knoten pro Zone. Der Befehl aktiviert auch Workload Identity 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 CSI-Treiberfeatures für Workload Identity und 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 verwendet tpu-topology=4x4 mit vier Knoten
  • Der Knotenpool verwendet machine-type ct5lp-hightpu-4t

Führen Sie den folgenden Befehl aus, um eine Verbindung zum 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, stellen Sie sicher, dass Ihr Konto über den richtigen Wert für Berechtigungen damit Docker in das Repository übertragen kann.

Erstellen Sie das Docker-Image und übertragen Sie es per Push:

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üllen Sie das Bildfeld mit dem Bild aus, das Sie gerade erstellt haben.

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 mit folgendem Befehl bereit:

kubectl apply -f tpu_job_diffusion.yaml

Bereinigen

Nachdem der Job ausgeführt wurde, können Sie ihn so löschen:

kubectl delete -f tpu_job_diffusion.yaml

PyTorch/XLA: GPT2 in 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, stellen Sie sicher, dass Ihr Konto über den richtigen Wert für Berechtigungen damit Docker in das Repository übertragen kann.

Erstellen Sie das Docker-Image und übertragen Sie es per Push:

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 bereit. Verwenden Sie dazu:

kubectl apply -f tpu_job_gpt.yaml

Bereinigen

Nachdem der Job ausgeführt wurde, können Sie ihn so löschen:

kubectl delete -f tpu_job_gpt.yaml

Anleitung: Arbeitslasten für Inferenz mit einem einzelnen Host

In dieser Anleitung wird gezeigt, wie Sie eine Inferenzarbeitslast eines einzelnen Hosts GKE v5e TPUs für vortrainierte Modelle mit JAX, TensorFlow, und PyTorch. Im Großen und Ganzen sind vier separate Schritte für die GKE-Cluster:

  1. Erstellen Sie einen Cloud Storage-Bucket und richten Sie den Zugriff auf den Bucket ein. Sie verwenden eine Cloud Storage-Bucket wird zum Speichern des vortrainierten Modells verwendet.

  2. Vortrainiertes Modell herunterladen und in ein TPU-kompatibles Modell konvertieren Wenden Sie Kubernetes-Pod, der das vortrainierte Modell herunterlädt, verwendet den 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 und führen Sie den Cloud TPU Converter im CPU-Knotenpool aus.

  3. Starten Sie den Server für das konvertierte Modell. Deployment anwenden das das Modell mithilfe eines Server-Frameworks bereitstellt, das auf dem in das nichtflüchtige ROX-Volume (ReadOnlyMany). 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.

  4. Stellen Sie einen Load-Balancer bereit, um den Modellserver zu testen. Der Server ist für externe Anfragen mithilfe des LoadBalancer-Dienstes. Es wurde ein Python-Skript mit einer Beispielanfrage bereitgestellt, um die Modellserver.

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

Ein Diagramm, das das Routing des Load-Balancers zeigt

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:
    • Topologie ist 1 x 1
    • 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 in Ihrem TPU-Knotenpool eine andere Anzahl von Knoten verwenden, ändern Sie den replicas auf 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 unter resources so fest, dass sie der Anzahl der Chips für den entsprechenden Maschinentyp zu erstellen.

Einrichtung

Laden Sie die Python-Skripts und YAML-Manifeste der Anleitung mit folgendem Befehl herunter: Befehl:

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, das requirements.txt für jede Anleitung zu installieren, bevor Sie den Python-Testskripts

Wenn Python in Ihrer lokalen Umgebung nicht richtig eingerichtet ist, können Sie laden Sie die Datei mit Cloud Shell herunter und führen Sie sie aus. Python-Skripts.

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

Bei den 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: Die 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 des Objekts Knoten in Ihrem Knotenpool zu erstellen.

Modellspeicher einrichten

Es gibt mehrere Möglichkeiten, Ihr Modell für die Bereitstellung zu speichern. In dieser Anleitung verwenden wir den folgenden Ansatz:

  • 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 Standort Ihres Cloud Storage-Bucket. Geben Sie zum Verbessern der Leistung den Standort an, an dem Ihr GKE-Cluster wird ausgeführt.

Führen Sie die folgenden Schritte aus, um Ihrem GKE-Cluster Zugriff auf aus dem Bucket. In den folgenden Beispielen wird die Standardeinstellung verwendet, um die Einrichtung zu vereinfachen. Namespace und das Kubernetes-Standarddienstkonto. Weitere Informationen finden Sie unter Zugriff auf Cloud Storage-Buckets mit GKE Workload Identity konfigurieren

  1. Erstellen Sie ein IAM-Dienstkonto für Ihre Anwendung oder verwenden Sie stattdessen ein vorhandenes IAM-Dienstkonto. Sie können beliebige IAM-Dienstkonto im Projekt Ihres Cloud Storage-Bucket.

    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. Das IAM-Dienstkonto muss sich im selben Projekt wie Ihr Cloud Storage-Bucket befinden.

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

  3. 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.
    • your-project-id: die ID des Projekts, in dem Sie Ihr GKE-Cluster. Ihre Cloud Storage-Buckets und Der GKE-Cluster kann 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-Dienstes. Konto.
    • your-bucket-project-id: die ID des Projekts, in dem Sie Ihr IAM-Dienstkonto.

  5. Führen Sie den folgenden Befehl aus, um den Bucket-Namen in die YAML-Dateien dieser Demo:

    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 nichtflüchtige Volumes mit Befehl:

    kubectl apply -f pvc-pv.yaml

Inferenz und Bereitstellung von JAX-Modellen

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 JAX BERT E2E-Bereitstellung ausführen:

Diese Demo verwendet ein vortrainiertes BERT-Modell von Hugging Face.

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

  1. Das Python-Skript export_bert_model.py aus dem Beispiel wird heruntergeladen und verwendet. Ressourcen zum Herunterladen des vortrainierten BERT-Modells in ein temporäres Verzeichnis.
  2. 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

Bei den 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, der Folgendes enthält: TPU-Chip

Wenn Sie eine andere Clusterkonfiguration als zuvor beschrieben verwenden, müssen Sie das Manifest für die Serverbereitstellung bearbeiten.

Bereitstellung anwenden
kubectl apply -f jax/bert/serve-bert.yaml

Überprüfen Sie mit folgendem Code, 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 mit den folgenden Schritten, 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 angezeigt wird.

Anfrage an den Modellserver senden

Rufen Sie die externe IP-Adresse vom Load-Balancer-Dienst ab:

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

Zum Bereinigen von Ressourcen führen Sie kubectl delete in umgekehrter Reihenfolge aus.

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 JAX Stable Diffusion E2E-Bereitstellung 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:

  1. Lädt das Python-Skript export_stable_diffusion_model.py von herunter und verwendet es Beispielressourcen, um das vortrainierte stabile Diffusion-Modell herunterzuladen, ein temporäres Verzeichnis.
  2. Verwendet das Cloud TPU Converter-Bild zum Konvertieren des vortrainierten Modells CPU zu TPU und speichert das Modell in dem von Ihnen erstellten Cloud Storage-Bucket während der Speichereinrichtung.

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.

Servercontainer des TF-Modells für das Modell starten

Die Beispielarbeitslasten wurden unter Berücksichtigung der folgenden Annahmen konfiguriert:

  • Der Cluster wird mit einem TPU v5-Knotenpool mit drei Knoten ausgeführt
  • Der Knotenpool verwendet den Maschinentyp ct5lp-hightpu-1t. Dabei gilt:
    • Topologie ist 1 x 1
    • Anzahl der TPU-Chips: 1

Wenn Sie eine andere Clusterkonfiguration als zuvor beschrieben 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.

Wenden Sie den Load-Balancer-Dienst an:

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 angezeigt 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}')

Skript 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

Zum Bereinigen von Ressourcen führen Sie kubectl delete in umgekehrter Reihenfolge aus.

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

Demonstration der TensorFlow ResNet-50 E2E-Bereitstellung ausführen:

Installieren Sie Python-Abhängigkeiten zum Ausführen von Python-Skripten in dieser Anleitung, die an den TF-Modelldienst gesendet.

pip install -r tf/resnet50/requirements.txt
Schritt 1: Modell konvertieren

Modellkonvertierung anwenden:

kubectl apply -f tf/resnet50/model-conversion.yml

Prüfen Sie so, ob das Modell korrekt installiert wurde:

kubectl get pods resnet-model-conversion

Es kann einige Minuten dauern, bis STATUS Completed liest.

Schritt 2: Modell mit TensorFlow-Bereitstellung bereitstellen

Modellbereitstellungsbereitstellung anwenden:

kubectl apply -f tf/resnet50/deployment.yml

Überprü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.

Wenden Sie den Load-Balancer-Dienst an:

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

Schritt 3: Testanfrage an 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:

  1. Modellarchiv generieren.

    1. Modellarchiv anwenden:
    kubectl apply -f pt/densenet161/model-archive.yml
    1. 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.

  2. Bereitstellen des Modells mit TorchServe:

    1. Modellbereitstellungs-Deployment anwenden:

      kubectl apply -f pt/densenet161/deployment.yml

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

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

  3. Testanfrage an Modellserver senden:

    1. Rufen Sie die externe IP-Adresse vom Load-Balancer ab:

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

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

  4. Bereinigen Sie 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 Ohne privilegierten Modus ausführen.

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) und beide sollen auf TPU geplant werden Slices mit einer bestimmten TPU-Topologie (z. B. v4-32). Nehmen wir außerdem an, Sie haben zwei v4-32-TPU-Slices im GKE-Cluster; wir Segment X und Segment Y nennen. Da Ihr Cluster genügend Kapazität hat, Beide Jobs sollten in der Regel schnell eingeplant werden – für jedes der beiden TPU-v4-32-Slices.

Ohne sorgfältige Planung ist es jedoch möglich, Deadlock. Angenommen, der Kubernetes-Planer plant einen Kubernetes-Pod aus dem Job A in Slice X und plant 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. Gleicher Wert für Job B. Somit können weder Job A noch Job B vollständig auf einem einzelnen Slice. Das Ergebnis ist ein Planungs-Deadlock.

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 die 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 einzelnem 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 die Arbeitslast ausführen.
  • us-central2-b: Die Zone, in der Sie Ihre Arbeitslast ausführen.