TPU-Arbeitslasten in GKE Standard bereitstellen

Auf dieser Seite erfahren Sie, wie Sie umfangreiche Arbeitslasten für das Training, die Abstimmung und die Inferenz von KI- und ML-Modellen mit Cloud TPU-Beschleunigern (TPUs) in Google Kubernetes Engine (GKE)-Standardclustern anfordern und bereitstellen.

Bevor Sie TPU-Arbeitslasten in GKE konfigurieren und bereitstellen, sollten Sie mit den folgenden Konzepten vertraut sein:

1. Einführung in Cloud TPU
2. Cloud TPU-Systemarchitektur
3. TPUs in GKE

Hinweise

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

• Aktivieren Sie die Google Kubernetes Engine API.
Google Kubernetes Engine API aktivieren
• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

TPU-Verfügbarkeit in GKE

Verwenden Sie GKE zum Erstellen und Verwalten von Knotenpools mit TPUs. Mit diesen speziell entwickelten Beschleunigern können Sie umfangreiches Training, Abstimmung und Inferenz für KI-Modelle ausführen.

Liste der unterstützten TPU-Versionen in GKE

TPU-Konfiguration planen

Planen Sie Ihre TPU-Konfiguration basierend auf Ihrem ML-Modell und dem erforderlichen Arbeitsspeicher. Die folgenden Schritte sind für die Planung Ihrer TPU-Konfiguration relevant:

1. TPU-Version und Topologie auswählen
2. Zu verwendenden Knotenpooltyp auswählen

Ausreichendes Kontingent für On-Demand- oder Spot-VMs sicherstellen

Für das Erstellen eines TPU-Slice-Knotenpools, der eine TPU-Reservierung nutzt, ist kein TPU-Kontingent erforderlich.¹ Sie können diesen Abschnitt für reservierte TPUs überspringen.

Zum Erstellen eines On-Demand- oder Spot-TPU-Slice-Knotenpools in GKE ist ein Kontingent für die Compute Engine API erforderlich. Das Compute Engine API-Kontingent (compute.googleapis.com) ist nicht mit dem Cloud TPU API-Kontingent (tpu.googleapis.com) identisch, das beim Erstellen von TPUs mit der Cloud TPU API erforderlich ist.

Führen Sie die folgenden Schritte aus, um das Limit und die aktuelle Nutzung Ihres Compute Engine API-Kontingents für TPUs zu prüfen:

1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

   Kontingente aufrufen

2. Gehen Sie im Feld filter_listFilter folgendermaßen vor:

   1. Wählen Sie das Attribut Dienst aus, geben Sie Compute Engine API ein und drücken Sie die Eingabetaste.

   2. Wählen Sie das Attribut Typ und dann Kontingent aus.

   3. Wählen Sie das Attribut Name aus und geben Sie basierend auf der TPU-Version und dem Maschinentyp den Namen des Kontingents ein. Wenn Sie beispielsweise On-Demand-TPU v5e-Knoten erstellen möchten, deren Maschinentyp mit ct5lp- beginnt, geben Sie TPU v5 Lite PodSlice chips ein.

      TPU-Version	Maschinentyp beginnt mit	Name des Kontingents für On-Demand-Instanzen	Name des Kontingents für Spot2-Instanzen
      TPU v4	ct4p-	TPU v4 PodSlice chips	Preemptible TPU v4 PodSlice chips
      TPU v5e	ct5l-	TPU v5 Lite Device chips	Preemptible TPU v5 Lite Device chips
      TPU v5e	ct5lp-	TPU v5 Lite PodSlice chips	Preemptible TPU v5 Lite PodSlice chips
      TPU v5p	ct5p-	TPU v5p chips	Preemptible TPU v5p chips

   4. Wählen Sie das Attribut Dimensionen (z.B. Standorte) aus und geben Sie region: gefolgt vom Namen der Region ein, in der Sie TPUs in GKE erstellen möchten. Geben Sie beispielsweise region:us-west4 ein, wenn Sie TPU-Slice-Knoten in der Zone us-west4-a erstellen möchten. Das TPU-Kontingent ist regional, d. h. alle Zonen innerhalb derselben Region nutzen dasselbe TPU-Kontingent.

Wenn keine Kontingente vorhanden sind, die Sie eingegeben haben, wurde dem Projekt keines der angegebenen Kontingente für die gewünschte Region zugewiesen und Sie müssen eine TPU-Kontingenterhöhung anfordern.

Verfügbarkeit von Reservierungen sichern

Für das Erstellen eines reservierten TPU-Slice-Knotenpools, der eine Reservierung nutzt, ist kein TPU-Kontingent erforderlich. Die Reservierung muss jedoch genügend verfügbare oder ungenutzte TPU-Chips haben, wenn der Knotenpool erstellt wird.

Um herauszufinden, welche Reservierungen in einem Projekt bestehen, rufen Sie eine Liste Ihrer Reservierungen auf.

Wie viele TPU-Chips innerhalb einer TPU-Reservierung verfügbar sind, sehen Sie in den Details einer Reservierung.

Cluster erstellen

Erstellen Sie einen GKE-Cluster im Standard-Modus in einer Region mit verfügbaren TPUs. Es wird empfohlen, regionale Cluster zu verwenden, die eine hohe Verfügbarkeit der Kubernetes-Steuerungsebene bieten. Sie können dazu die Google Cloud CLI oder die Google Cloud Console verwenden.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des neuen Clusters.
• LOCATION: Die Region mit Ihrer verfügbaren TPU-Kapazität.
• VERSION: Die GKE-Version, die den gewünschten Maschinentyp unterstützen muss. Die Standard-GKE-Version ist möglicherweise nicht für Ihre Ziel-TPU verfügbar. Informationen zu den für die TPU-Maschinentypen verfügbaren Mindest-GKE-Versionen finden Sie unter TPU-Verfügbarkeit in GKE.

Knotenpool erstellen

TPU-Slice mit einzelnem Host

Sie können einen TPU-Slice-Knotenpool mit einem einzelnen Host mithilfe der Google Cloud CLI, mit Terraform oder mit der Google Cloud Console erstellen.

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE

resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
  }
}

TPU-Slice mit mehreren Hosts

Sie können ein TPU-Slice mit mehreren Hosts über die Google Cloud CLI, Terraform oder die Google Cloud Console erstellen.

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONE \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    [--spot \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME]

ProvisioningState

Wenn GKE den Knotenpool des TPU-Slices aufgrund unzureichender TPU-Kapazität nicht erstellen kann, gibt GKE eine Fehlermeldung zurück, die besagt, dass die Knoten des TPU-Slices aufgrund von Kapazitätsmangel nicht erstellt werden können.

Wenn Sie einen TPU-Slice-Knotenpool mit nur einem Host erstellen, sieht die Fehlermeldung in etwa so aus:

2 nodes cannot be created due to lack of capacity. The missing nodes will be
created asynchronously once capacity is available. You can either wait for the
nodes to be up, or delete the node pool and try re-creating it again later.

Wenn Sie einen TPU-Slice-Knotenpool mit mehreren Hosts erstellen, sieht die Fehlermeldung in etwa so aus:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
will be created asynchronously once capacity is available. You can either wait
for the nodes to be up, or delete the node pool and try re-creating it again
later.

Ihre TPU-Bereitstellungsanfrage kann über einen längeren Zeitraum in der Warteschlange verbleiben, wo sie den Status "Wird bereitgestellt" hat.

Sobald Kapazität verfügbar ist, erstellt GKE die Knoten, die noch nicht erstellt wurden.

Wenn Sie die Kapazität früher benötigen, können Sie Spot-VMs verwenden. Beachten Sie jedoch, dass Spot-VMs ein anderes Kontingent aufnehmen als On-Demand-Instanzen.

Sie können die anstehende TPU-Anfrage löschen, indem Sie den TPU-Slice-Knotenpool löschen.

Arbeitslast auf TPU-Slice-Knoten ausführen

Arbeitslastvorbereitung

Für TPU-Arbeitslasten gelten die folgenden Vorbereitungsanforderungen.

1. Frameworks wie JAX, PyTorch und TensorFlow greifen auf TPU-VMs mit der freigegebenen Bibliothek libtpu zu. libtpu enthält den XLA-Compiler, die TPU-Laufzeitsoftware und den TPU-Treiber. Jede Version von PyTorch und JAX erfordert eine bestimmte Version von libtpu.so. Für die Verwendung von TPUs in GKE benötigen Sie die folgenden Versionen:

   TPU-Typ	libtpu.so-Version
   TPU v5e tpu-v5-lite-podslice tpu-v5-lite-device	Empfohlene jax[tpu]-Version: v0.4.9 oder höher. Empfohlene torchxla[tpuvm]-Version: v2.1.0 oder höher.
   TPU v5p tpu-v5p-slice	Empfohlene jax[tpu]-Version: 0.4.19 oder höher. Empfohlene torchxla[tpuvm]-Version: nächtliche Version verwenden, die am 23. Oktober 2023 erstellt wurde.
   TPU v4 tpu-v4-podslice	jax[tpu]: v0.4.4 oder höher torchxla[tpuvm]: v2.0.0 oder höher

2. Legen Sie die folgenden Umgebungsvariablen für den Container fest, der die TPU-Ressourcen anfordert:
   • TPU_WORKER_ID: Eine eindeutige Ganzzahl für jeden Pod. Diese ID bezeichnet eine eindeutige Worker-ID im TPU-Slice. Die unterstützten Werte für dieses Feld reichen von null bis zur Anzahl der Pods minus eins.
   • TPU_WORKER_HOSTNAMES: Eine durch Kommas getrennte Liste von TPU-VM-Hostnamen oder IP-Adressen, die innerhalb des Slices miteinander kommunizieren müssen. Für jede TPU-VM im Slice sollte ein Hostname oder eine IP-Adresse vorhanden sein. Die Liste der IP-Adressen oder Hostnamen ist geordnet und ab null nach der TPU_WORKER_ID indexiert.

   GKE fügt diese Umgebungsvariablen automatisch ein. Dazu wird ein mutierender Webhook verwendet, wenn ein Job mit completionMode: Indexed, subdomain, parallelism > 1 erstellt wird, und es werden google.com/tpu-Attribute angefordert. GKE fügt einen monitorlosen Service hinzu, sodass die DNS-Einträge für die Pods, die den Service unterstützen, hinzugefügt werden.

   Wenn Sie Ressourcen von TPU mit mehreren Hosts mit Kuberay bereitstellen, stellt GKE im Rahmen der Terraform-Vorlagen einen bereitstellbaren Webhook zum Ausführen von Ray in GKE bereit. Eine Anleitung zum Ausführen von Ray in GKE mit TPUs finden Sie im TPU-Benutzerhandbuch. Der mutierende Webhook schleust diese Umgebungsvariablen in Ray-Cluster ein, die google.com/tpu-Attribute und einen cloud.google.com/gke-tpu-topology-Knotenselektor für mehrere Hosts anfordern.

   • Fügen Sie in Ihrem Arbeitslastmanifest ein Kubernetes-Knotenselektor hinzu, um dafür zu sorgen, dass GKE Ihre TPU-Arbeitslast auf dem von Ihnen definierten TPU-Maschinentyp und der TPU-Topologie plant:

       nodeSelector:
         cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
         cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
       

     Ersetzen Sie Folgendes:

     • TPU_ACCELERATOR: Der Name des TPU-Beschleunigers
       • Verwenden Sie für TPU v4 tpu-v4-podslice.
       • Verwenden Sie für TPU v5e-Maschinentypen, die mit ct5l- beginnen, tpu-v5-lite-device.
       • Verwenden Sie für TPU v5e-Maschinentypen, die mit ct5lp- beginnen, tpu-v5-lite-podslice.
       • Verwenden Sie für TPU v5p tpu-v5p-slice.
     • TPU_TOPOLOGY: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt so von der TPU-Version ab:
       • TPU v4: Definieren Sie die Topologie in 3-Tupeln ({A}x{B}x{C}), z. B. 4x4x4.
       • TPU v5e: Definieren Sie die Topologie in 2-Tupeln ({A}x{B}), z. B. 2x2.
       • TPU v5p: Definieren Sie die Topologie in 3-Tupeln ({A}x{B}x{C}), z. B. 4x4x4.

Nachdem Sie die Arbeitslastvorbereitung abgeschlossen haben, können Sie einen Job ausführen, der TPUs verwendet.

Die folgenden Abschnitte zeigen Beispiele für die Ausführung eines Jobs, der eine einfache Berechnung mit TPUs ausführt.

Beispiel 1: Arbeitslast ausführen, die die Anzahl der verfügbaren TPU-Chips in einem TPU-Slice-Knotenpool anzeigt

Die folgende Arbeitslast gibt die Anzahl der TPU-Chips für alle Knoten in einem TPU-Slice mit mehreren Hosts zurück. Zum Erstellen eines Slices mit mehreren Hosts hat die Arbeitslast die folgenden Parameter:

• TPU-Version: TPU v4
• Topologie: 2x2x4

Diese Versions- und Topologieauswahl führt zu einem Slice mit mehreren Hosts.

1. Speichern Sie das folgende Manifest als available-chips-multihost.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: headless-svc
   spec:
     clusterIP: None
     selector:
       job-name: tpu-available-chips
   ---
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: tpu-available-chips
   spec:
     backoffLimit: 0
     completions: 4
     parallelism: 4
     completionMode: Indexed
     template:
       spec:
         subdomain: headless-svc
         restartPolicy: Never
         nodeSelector:
           cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
           cloud.google.com/gke-tpu-topology: 2x2x4
         containers:
         - name: tpu-job
           image: python:3.10
           ports:
           - containerPort: 8471 # Default port using which TPU VMs communicate
           - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
           securityContext:
             privileged: true
           command:
           - bash
           - -c
           - |
             pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
             python -c 'import jax; print("TPU cores:", jax.device_count())'
           resources:
             requests:
               cpu: 10
               memory: 500Gi
               google.com/tpu: 4
             limits:
               cpu: 10
               memory: 500Gi
               google.com/tpu: 4

2. Stellen Sie das Manifest bereit:

   kubectl create -f available-chips-multihost.yaml
   

   GKE führt ein TPU v4-Slice mit vier VMs aus (TPU-Slice mit mehreren Hosts). Das Slice hat 16 miteinander verbundene TPU-Chips.

3. Prüfen Sie, ob der Job vier Pods erstellt hat:

   kubectl get pods
   

   Die Ausgabe sieht in etwa so aus:

   NAME                       READY   STATUS      RESTARTS   AGE
   tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
   tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
   tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
   tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
   

4. Rufen Sie die Logs eines der Pods ab:

   kubectl logs POD_NAME
   

   Ersetzen Sie POD_NAME durch den Namen eines der erstellten Pods. Beispiel: tpu-job-podslice-0-5cd8r.

   Die Ausgabe sieht in etwa so aus:

   TPU cores: 16
   

Beispiel 2: Arbeitslast ausführen, die die Anzahl der verfügbaren TPU-Chips im TPU-Slice anzeigt

Die folgende Arbeitslast ist ein statischer Pod, der die Anzahl der TPU-Chips anzeigt, die mit einem bestimmten Knoten verbunden sind. Zum Erstellen eines Knotens mit einem einzelnen Host hat die Arbeitslast folgende Parameter:

• TPU-Version: TPU v5e
• Topologie: 2x4

Diese Versions- und Topologieauswahl führt zu einem Slice mit einem einzelnen Host.

1. Speichern Sie das folgende Manifest als available-chips-singlehost.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: tpu-job-jax-v5
   spec:
     restartPolicy: Never
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
       cloud.google.com/gke-tpu-topology: 2x4
     containers:
     - name: tpu-job
       image: python:3.10
       ports:
       - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
       securityContext:
         privileged: true
       command:
       - bash
       - -c
       - |
         pip install 'jax[tpu]' -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
         python -c 'import jax; print("Total TPU chips:", jax.device_count())'
       resources:
         requests:
           google.com/tpu: 8
         limits:
           google.com/tpu: 8

2. Stellen Sie das Manifest bereit:

   kubectl create -f available-chips-singlehost.yaml
   

   GKE stellt Knoten mit acht TPU-Slices mit einem einzelnen Host bereit, die TPU v5e verwenden. Jeder TPU-Knoten hat acht TPU-Chips (TPU-Slice mit einzelnem Host).

3. Rufen Sie die Logs des Pods ab:

   kubectl logs tpu-job-jax-v5
   

   Die Ausgabe sieht in etwa so aus:

   Total TPU chips: 8
   

Knotenpools mit Beschleunigern (GPUs und TPUs) aktualisieren

GKE aktualisiert automatisch Standardcluster, einschließlich Knotenpools. Sie können Knotenpools auch manuell aktualisieren, wenn Sie die Knoten früher auf eine neuere Version aktualisieren möchten. Um die Funktionsweise von Upgrades für Ihren Cluster zu steuern, verwenden Sie Release-Versionen, Wartungsfenster und -ausschlüsse und Roll-out-Sequenzierung.

Sie können auch eine Strategie für Knotenupgrades für Ihren Knotenpool konfigurieren, z. B. Surge-Upgrades oder Blau/Grün-Upgrades. Durch die Konfiguration dieser Strategien können Sie dafür sorgen, dass die Knotenpools so aktualisiert werden, dass das optimale Gleichgewicht zwischen Geschwindigkeit und Unterbrechung für Ihre Umgebung erreicht wird. Bei TPU-Slice-Knotenpools mit mehreren Hosts erstellt GKE den gesamten Knotenpool atomar in einem einzigen Schritt neu anstelle die konfigurierten Strategie für Knotenupgrades zu verwenden. Weitere Informationen finden Sie in der Definition der Atomarität unter Terminologie in Bezug auf TPU in GKE.

Wenn Sie eine Knotenupgrade-Strategie verwenden, muss GKE je nach Konfiguration vorübergehend zusätzliche Ressourcen bereitstellen. Wenn Google Cloud die Kapazität für die Ressourcen Ihres Knotenpools begrenzt hat, z. B. wenn beim Versuch, mehr Knoten mit GPUs oder TPUs zu erstellen, Fehler zur Ressourcenverfügbarkeit angezeigt werden, finden Sie weitere Informationen unter Upgrade in einer ressourcenbeschränkten Umgebung durchführen.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, sollten Sie die TPU-Slice-Knotenpools löschen, die keine geplanten Arbeitslasten mehr haben. Wenn die ausgeführten Arbeitslasten ordnungsgemäß beendet werden müssen, verwenden Sie kubectl drain, um die Arbeitslasten zu bereinigen, bevor Sie den Knoten löschen.

1. So löschen Sie einen TPU-Slice-Knotenpool:

   gcloud container node-pools delete POOL_NAME \
       --location=LOCATION \
       --cluster=CLUSTER_NAME
   

   Ersetzen Sie Folgendes:

   • POOL_NAME: Der Name des Knotenpools.
   • CLUSTER_NAME: Der Name des Clusters.
   • LOCATION: Der Compute-Standort des Clusters.

Zusätzliche Konfigurationen

In den folgenden Abschnitten werden die zusätzlichen Konfigurationen beschrieben, die Sie auf Ihre TPU-Arbeitslasten anwenden können.

Multi-Slice

Sie können kleinere Slices in einem Multi-Slice aggregieren, um größere Trainingsarbeitslasten zu verarbeiten. Weitere Informationen finden Sie unter Multi-Slice-TPUs in GKE.

TPU-Reservierung migrieren

Wenn Sie bereits TPU-Reservierungen haben, müssen Sie zuerst Ihre TPU-Reservierung zu einem neuen Compute Engine-basierten Reservierungssystem migrieren. Sie können auch ein Compute Engine-basiertes Reservierungssystem erstellen, bei dem keine Migration erforderlich ist. Informationen zum Migrieren Ihrer TPU-Reservierungen finden Sie unter TPU-Reservierung.

Logging

Logs, die von Containern ausgegeben werden, die auf GKE-Knoten ausgeführt werden, einschließlich TPU-VMs, werden vom GKE-Logging-Agent erfasst und an Logging gesendet und sind in Logging sichtbar.

Automatische Bereitstellung von GKE-Knoten verwenden

Sie können GKE so konfigurieren, dass Knotenpools automatisch erstellt und gelöscht werden, um die Ressourcenanforderungen Ihrer TPU-Arbeitslasten zu erfüllen. Weitere Informationen finden Sie unter Cloud TPUs konfigurieren.

Automatische Reparatur von TPU-Slice-Knoten

Wenn ein TPU-Slice-Knoten in einem TPU-Slice-Knotenpool mit mehreren Hosts fehlerhaft ist, wird der gesamte Knotenpool neu erstellt. In einem TPU-Slice-Knotenpool mit einem einzelnen Host wird dagegen nur der fehlerhafte TPU-Knoten automatisch repariert.

Zu den Elementen, die zu fehlerhaften TPU-Slice-Knoten führen, gehören:

• TPU-Slice-Knoten mit gängigen Knotenbedingungen.
• TPU-Slice-Knoten mit einer nicht zuweisbaren TPU-Anzahl größer als null.
• VM-Instanz in einem TPU-Slice, die aufgrund eines vorzeitigen Beendens angehalten oder anderweitig beendet wurde.
• Knotenwartung: Wenn ein TPU-Slice-Knoten in einem TPU-Slice-Knotenpool mit mehreren Hosts für die Hostwartung beendet wird, erstellt GKE den gesamten TPU-Slice-Knotenpool neu.

Der Reparaturstatus (einschließlich des Fehlergrundes) wird im Vorgangsverlauf angezeigt. Wenn der Fehler durch ein unzureichendes Kontingent verursacht wird, wenden Sie sich an Ihren Google Cloud-Kundenbetreuer, um das entsprechende Kontingent zu erhöhen.

Ordnungsgemäße Beendigung von TPU-Slice-Knoten konfigurieren

In GKE-Clustern mit der Steuerungsebene, auf der 1.29.1-gke.1425000 oder höher ausgeführt wird, unterstützen TPU-Slice-Knoten SIGTERM-Signale, die den Knoten über ein bevorstehendes Herunterfahren informieren. Die Benachrichtigung über das bevorstehende Herunterfahren kann in TPU-Knoten auf bis zu fünf Minuten konfiguriert werden.

Wenn Sie GKE so konfigurieren möchten, dass Ihre Arbeitslasten innerhalb dieses Benachrichtigungszeitraums ordnungsgemäß beendet werden, folgen Sie der Anleitung unter GKE-Knotenunterbrechungen für GPUs und TPUs verwalten.

Container ohne privilegierten Modus ausführen

Wenn auf Ihrem TPU-Slice-Knoten Versionen vor 1.28 ausgeführt werden, lesen Sie den folgenden Abschnitt:

Ein Container, der auf einer VM in einem TPU-Slice ausgeführt wird, benötigt Zugriff auf höhere Limits für gesperrten Arbeitsspeicher, damit der Treiber mit den TPU-Chips über DMA (Direct Memory Access) kommunizieren kann. Damit dies möglich ist, müssen Sie ein höheres ulimit konfigurieren. Führen Sie die folgenden Schritte aus, um den Berechtigungsbereich für Ihren Container zu reduzieren:

1. Bearbeiten Sie securityContext so, dass die folgenden Felder enthalten sind:

   securityContext:
     capabilities:
       add: ["SYS_RESOURCE"]
   

2. Erhöhen Sie ulimit, indem Sie den folgenden Befehl im Container ausführen, bevor Sie die Arbeitslasten für die Verwendung von TPU-Ressourcen einrichten:

   ulimit -l 68719476736
   

Hinweis: Bei TPU v5e ist die Ausführung von Containern ohne privilegierten Modus in Clustern in Version 1.27.4-gke.900 und höher verfügbar.

Beobachtbarkeit und Messwerte

Dashboard

Auf der Seite Kubernetes-Cluster in der Google Cloud Console werden auf dem Tab Beobachtbarkeit die TPU-Beobachtbarkeitsmesswerte angezeigt. Weitere Informationen finden Sie unter GKE-Beobachtbarkeitsmesswerte.

Das TPU-Dashboard wird nur ausgefüllt, wenn in Ihrem GKE-Cluster Systemmesswerte aktiviert sind.

Laufzeitmesswerte

In GKE Version 1.27.4-gke.900 oder höher exportieren TPU-Arbeitslasten, die JAX Version 0.4.14 oder höher verwenden und containerPort: 8431 angeben, TPU-Auslastungsmesswerte als GKE-Systemmesswerte. Die folgenden Messwerte sind in Cloud Monitoring verfügbar, um die Laufzeitleistung Ihrer TPU-Arbeitslast zu überwachen:

• Arbeitszyklus: Prozentsatz der Zeit im vergangenen Stichprobenzeitraum (60 Sekunden), während der TensorCores auf einem TPU-Chip aktiv mit Verarbeitung beschäftigt waren. Ein höherer Prozentsatz bedeutet eine bessere TPU-Auslastung.
• Arbeitsspeichernutzung: Menge des dem Beschleuniger zugeteilten Arbeitsspeichers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.
• Speicherkapazität: Gesamter Arbeitsspeicher des Beschleunigers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.

Diese Messwerte befinden sich im Kubernetes-Knotenschema (k8s_node) und im Kubernetes-Containerschema (k8s_container).

Kubernetes-Container:

• kubernetes.io/container/accelerator/duty_cycle
• kubernetes.io/container/accelerator/memory_used
• kubernetes.io/container/accelerator/memory_total

Kubernetes-Knoten:

• kubernetes.io/node/accelerator/duty_cycle
• kubernetes.io/node/accelerator/memory_used
• kubernetes.io/node/accelerator/memory_total

Hostmesswerte

In GKE-Version 1.28.1-gke.1066000 oder höher exportieren VMs in einem TPU-Slice TPU-Auslastungsmesswerte als GKE-Systemmesswerte. Die folgenden Messwerte sind in Cloud Monitoring verfügbar, um die Leistung Ihres TPU-Hosts zu überwachen:

• TensorCore-Auslastung: Aktueller Prozentsatz des verwendeten TensorCore. Der TensorCore-Wert entspricht der Summe der Matrixmultiplikationseinheiten (MXUs) plus der Vektoreinheit. Der TensorCore-Auslastungswert ist der Quotient aus den TensorCore-Vorgängen, die im letzten Stichprobenzeitraum (60 Sekunden) ausgeführt wurden, und der unterstützten Anzahl von TensorCore-Vorgängen im selben Zeitraum. Ein größerer Wert bedeutet eine bessere Auslastung.
• Auslastung der Arbeitsspeicherbandbreite: Aktueller Prozentsatz der verwendeten Arbeitsspeicherbandbreite des Beschleunigers. Wird berechnet, indem die in einem Stichprobenzeitraum (60 s) verwendete Arbeitsspeicherbandbreite durch die maximal unterstützte Bandbreite im selben Stichprobenzeitraum geteilt wird.

Diese Messwerte befinden sich im Kubernetes-Knotenschema (k8s_node) und im Kubernetes-Containerschema (k8s_container).

Kubernetes-Container:

• kubernetes.io/container/accelerator/tensorcore_utilization
• kubernetes.io/container/accelerator/memory_bandwidth_utilization

Kubernetes-Knoten:

• kubernetes.io/container/node/tensorcore_utilization
• kubernetes.io/container/node/memory_bandwidth_utilization

Weitere Informationen finden Sie unter Kubernetes-Messwerte und GKE-Systemmesswerte.

Bekannte Probleme

• Cluster Autoscaler kann die Kapazität für neue TPU-Slice-Knoten falsch berechnen, bevor diese Knoten die verfügbaren TPUs melden. 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.
• Cluster Autoscaler bricht das Hochskalieren von TPU-Slice-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.
• 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-Slice-Knotenpools neu erstellt werden.
• Der Messwert „Speicherbandbreitenauslastung“ ist für TPUs der Version 5e nicht verfügbar.

Nächste Schritte

• Large Language Models mit Saxml auf TPUs bereitstellen
• Weitere Informationen zum Einrichten von Ray on GKE mit TPUs
• Umfangreiches maschinelles Lernen auf Cloud TPUs mit GKE erstellen
• Large Language Models mit KubeRay auf TPUs bereitstellen
• Fehlerbehebung bei TPUs in GKE