Auf dieser Seite finden Sie die Grundlagen, um zu erfahren, wie Sie Arbeitslasten für maschinelles Lernen (ML) mit TPUs in Google Kubernetes Engine (GKE) beschleunigen können. TPUs sind für die Verarbeitung von Matrixmultiplikationen konzipiert, z. B. für das Training von Deep-Learning-Modellen im großen Maßstab. TPUs sind für die Verarbeitung der enormen Datasets und komplexen Modelle von ML optimiert und daher aufgrund ihrer überlegenen Leistung kostengünstiger und energieeffizienter für ML-Arbeitslasten. In diesem Leitfaden erfahren Sie, wie Sie ML-Arbeitslasten mit Cloud TPU-Beschleunigern bereitstellen, Kontingente für TPUs konfigurieren, Upgrades für Knotenpools konfigurieren, auf denen TPUs ausgeführt werden, und TPU-Arbeitslastmesswerte überwachen.
Diese Anleitung richtet sich an Entwickler von maschinellem Lernen (ML) sowie an Plattformadministratoren und ‑operatoren, die daran interessiert sind, die Kubernetes-Containerorchestrierung zum Verwalten von Arbeitslasten für das Training, die Optimierung und die Inferenz von Modellen in großem Umfang mit TPUs zu verwenden. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die in Google Cloud -Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.
Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:
Hinweise
Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:
- Aktivieren Sie die Google Kubernetes Engine API. Google Kubernetes Engine API aktivieren
- Wenn Sie die Google Cloud CLI für diesen Task 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 dem Befehl
gcloud components update
ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
TPU-Konfiguration planen
Planen Sie Ihre TPU-Konfiguration basierend auf Ihrem Modell und dem erforderlichen Arbeitsspeicher. Bevor Sie diese Anleitung zum Bereitstellen Ihrer Arbeitslasten auf TPUs verwenden, führen Sie die Planungsschritte unter TPU-Konfiguration planen aus.
TPU-Kontingent prüfen
In den folgenden Abschnitten erfahren Sie, wie Sie sicherstellen können, dass Sie bei der Verwendung von TPUs in GKE über ausreichendes Kontingent verfügen.Kontingent für On-Demand- oder Spot-VMs
Wenn Sie einen TPU-Slice-Knotenpool mit On-Demand- oder Spot-VMs erstellen, müssen Sie in der gewünschten Region über ein ausreichendes TPU-Kontingent verfügen.
Für das Erstellen eines TPU-Slice-Knotenpools, der eine TPU-Reservierung nutzt, ist kein TPU-Kontingent erforderlich.1 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:
Rufen Sie in der Google Cloud Console die Seite Kontingente auf:
Gehen Sie im Feld
Filter folgendermaßen vor:Verwenden Sie die folgende Tabelle, um das Attribut des Kontingents basierend auf der TPU-Version und dem Maschinentyp auszuwählen und zu kopieren. Wenn Sie beispielsweise On-Demand-TPU v5e-Knoten erstellen möchten, deren Maschinentyp mit
ct5lp-
beginnt, geben SieName: TPU v5 Lite PodSlice chips
ein.TPU-Version, Maschinentyp beginnt mit Property und Name des Kontingents für On-Demand-Instanzen Property und Name des Kontingents für Spot2-Instanzen TPU v3,
ct3-
Dimensions (e.g. location):
tpu_family:CT3Nicht zutreffend TPU v3,
ct3p-
Dimensions (e.g. location):
tpu_family:CT3PNicht zutreffend TPU v4,
ct4p-
Name:
TPU v4 PodSlice chipsName:
Preemptible TPU v4 PodSlice chipsTPU v5e,
ct5lp-
Name:
TPU v5 Lite PodSlice chipsName:
Preemptible TPU v5 Lite Podslice
chipsTPU v5p,
ct5p-
Name:
TPU v5p chipsName:
Preemptible TPU v5p chipsTPU Trillium,
ct6e-
Dimensions (e.g. location):
tpu_family:CT6EName:
Preemptible TPU slices v6eWä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 beispielsweiseregion:us-west4
ein, wenn Sie TPU-Slice-Knoten in der Zoneus-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-Kontingentanpassung anfordern.
Wenn eine TPU-Reservierung erstellt wird, erhöhen sich sowohl der Limitwert als auch der Wert der aktuellen Nutzung für das entsprechende Kontingent um die Anzahl der Chips in der TPU-Reservierung. Wenn beispielsweise eine Reservierung für 16 TPU v5e-Chips erstellt wird, deren Maschinentyp mit ct5lp-
beginnt, werden sowohl die Begrenzung als auch die aktuelle Nutzung für das Kontingent TPU v5 Lite PodSlice chips
in der entsprechenden Region um 16 erhöht.
-
Verwenden Sie beim Erstellen eines TPU-Slice-Knotenpools die Flags
--reservation
und--reservation-affinity=specific
, um eine reservierte Instanz zu erstellen. Beim Kauf einer Zusicherung sind TPU-Reservierungen verfügbar. ↩ -
Verwenden Sie beim Erstellen eines TPU-Slice-Knotenpools das Flag
--spot
, um eine Spot-Instanz zu erstellen. ↩
Kontingente für zusätzliche GKE-Ressourcen
Möglicherweise müssen Sie die folgenden GKE-bezogenen Kontingente in den Regionen erhöhen, in denen GKE Ihre Ressourcen erstellt.
- Kontingent für Persistent 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 (Knoten × 100 GB) sein.
- Kontingent für verwendete 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.
- Achten Sie darauf, dass
max-pods-per-node
mit dem Subnetzbereich übereinstimmt: Jeder Kubernetes-Knoten verwendet sekundäre IP-Bereiche für Pods. Fürmax-pods-per-node
von 32 sind beispielsweise 64 IP-Adressen erforderlich, was einem /26-Subnetz pro Knoten entspricht. Dieser Bereich darf nicht für andere Cluster freigegeben werden. Verwenden Sie das Flag--max-pods-per-node
, um die Anzahl der Pods zu begrenzen, die auf einem Knoten geplant werden dürfen, damit der IP-Adressbereich nicht ausgeschöpft wird. Das Kontingent fürmax-pods-per-node
sollte mindestens so hoch sein wie die maximale Anzahl von GKE-Knoten, die Sie voraussichtlich erstellen werden.
Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter Kontingentanpassung anfordern.
Verfügbarkeit von Reservierungen sichern
Wenn Sie einen TPU-Slice-Knotenpool mit einer Reservierung erstellen möchten, muss die Reservierung zum Zeitpunkt der Erstellung des Knotenpools über genügend verfügbare TPU-Chips verfügen.
Um herauszufinden, welche Reservierungen in einem Projekt bestehen und wie viele TPU-Chips in einer TPU-Reservierung verfügbar sind, rufen Sie eine Liste Ihrer Reservierungen auf.
Optionen für die Bereitstellung von TPUs in GKE
Mit GKE können Sie TPUs direkt in einzelnen Arbeitslasten verwenden. Dazu verwenden Sie Kubernetes-nodeSelectors in Ihrem Arbeitslastmanifest oder erstellen Knotenpools im Standardmodus mit TPUs.
Alternativ können Sie TPUs mit benutzerdefinierten Compute-Klassen anfordern. Mit benutzerdefinierten Compute-Klassen können Plattformadministratoren eine Hierarchie von Knotenkonfigurationen für GKE definieren, die bei Entscheidungen zur Knotenskalierung priorisiert werden sollen, damit Arbeitslasten auf der ausgewählten Hardware ausgeführt werden.
Eine Anleitung finden Sie im Abschnitt TPUs mit benutzerdefinierten Compute-Klassen bereitstellen.
Cluster erstellen
Erstellen Sie einen GKE-Cluster im Standard-Modus in einer Region mit verfügbaren TPUs.
Verwenden Sie regionale Cluster, die eine hohe Verfügbarkeit der Kubernetes-Steuerungsebene bieten.
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 GKE-Standardversion ist für Ihre Ziel-TPU möglicherweise nicht 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
Sie können einen TPU-Slice-Knotenpool mit einem oder mehreren Hosts erstellen.
TPU-Slice-Knotenpool mit einem Host erstellen
Sie können einen TPU-Slice-Knotenpool mit einem einzelnen Host mithilfe der Google Cloud CLI, mit Terraform oder mit der Google Cloud erstellen.
gcloud
gcloud container node-pools create NODE_POOL_NAME \
--location=LOCATION \
--cluster=CLUSTER_NAME \
--node-locations=NODE_ZONES \
--machine-type=MACHINE_TYPE \
[--sandbox=type=gvisor]
Ersetzen Sie Folgendes:
NODE_POOL_NAME
: Der Name des neuen Knotenpools.LOCATION
: Der Name der Zone basierend auf der zu verwendenden TPU-Version. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.CLUSTER_NAME
ist der Name des Clusters.NODE_ZONES
: Die kommagetrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.MACHINE_TYPE
: Der Maschinentyp für Knoten. Weitere Informationen zu TPU-kompatiblen Maschinentypen finden Sie in der Tabelle unter TPU-Version auswählen.
Optional können Sie auch die folgenden Flags verwenden:
--num-nodes=NUM_NODES
: Die anfängliche Anzahl von Knoten im Knotenpool in jeder Zone. Wenn Sie dieses Flag weglassen, weist GKE den Standardwert3
zu.Best Practice: Wenn Sie das Flag
enable-autoscaling
für den Knotenpool verwenden, legen Sienum-nodes
auf0
fest, damit der Autoscaler zusätzliche Knoten bereitstellt, sobald Ihre Arbeitslasten diese benötigen.--reservation=RESERVATION_NAME
: Der Name der Reservierung, die GKE beim Erstellen des Knotenpools verwendet. Wenn Sie dieses Flag weglassen, verwendet GKE die verfügbaren TPUs. Weitere Informationen zu TPU-Reservierungen finden Sie unter Cloud TPU-Reservierungen.--node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY
: Gibt GKE, dass der Knotenpool für das TPU-Slice mit einem einzelnen Host Teil einer Sammlung ist. Verwenden Sie dieses Flag, wenn die folgenden Bedingungen erfüllt sind:- Der Knotenpool führt die Inferenzarbeitslast im neuen Knotenpool aus.
- Der Knotenpool verwendet TPU Trillium.
- Der Knotenpool verwendet keine Spot-VMs.
Weitere Informationen zur Verwaltung der Erfassungsplanung finden Sie unter Erfassungsplanung in TPU-Slices mit einem Host verwalten.
--enable-autoscaling
: Knotenpool mit aktiviertem Autoscaling erstellen. Erfordert die folgenden zusätzlichen Flags:--total-min-nodes=TOTAL_MIN_NODES
: Mindestanzahl aller Knoten im Knotenpool.--total-max-nodes=TOTAL_MAX_NODES
: Maximale Anzahl aller Knoten im Knotenpool.--location-policy=ANY
: Die Nutzung nicht verwendeter Reservierungen priorisieren und das Risiko des Vorzeitigen Beendens von Spot-VMs verringern.
--spot
: Legt fest, dass der Knotenpool Spot-VMs für die Knoten im Knotenpool verwendet. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden.--flex-start
: Legt den Knotenpool so fest, dass Flex-Start-VMs verwendet werden. Flex-Start-VMs werden mit der Verbrauchsoption flex-start erstellt, die in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt wird.--sandbox=type=gvisor
: Stellt einen Knoten mit aktivierter GKE Sandbox bereit. Erfordert TPU v4 und höher. Weitere Informationen finden Sie unter GKE Sandbox.
Eine vollständige Liste aller Flags, die Sie angeben können, finden Sie in der Referenz zu gcloud container clusters create
.
Terraform
- Prüfen Sie, ob Sie Version 4.84.0 oder höher des Anbieters
google
verwenden. - Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu:
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
flex_start = false
}
}
Ersetzen Sie Folgendes:
NODE_POOL_RESOURCE_NAME
: Der Name der Knotenpoolressource in der Terraform-Vorlage.PROJECT_ID
: Ihre Projekt-ID.CLUSTER_NAME
: Der Name des vorhandenen Clusters.POOL_NAME
: Der Name des Knotenpools, der erstellt werden soll.CLUSTER_LOCATION
: Die Compute-Zonen des Clusters. Geben Sie die Region an, in der die TPU-Version verfügbar ist. Weitere Informationen finden Sie unter TPU-Version und Topologie auswählen.NODE_ZONES
: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.MACHINE_TYPE
: Der zu verwendende TPU-Maschinentyp. Die TPU-kompatiblen Maschinentypen finden Sie in der Tabelle unter TPU-Version auswählen.
Optional können Sie auch die folgenden Variablen verwenden:
autoscaling
: Knotenpool mit aktiviertem Autoscaling erstellen. Bei einem TPU-Slice mit einem einzelnen Host skaliert GKE zwischen den WertenTOTAL_MIN_NODES
undTOTAL_MAX_NODES
.TOTAL_MIN_NODES
: Mindestanzahl aller Knoten im Knotenpool. Dieses Feld ist optional, es sei denn, Autoscaling ist ebenfalls angegeben.TOTAL_MAX_NODES
: Maximale Anzahl aller Knoten im Knotenpool. Dieses Feld ist optional, es sei denn, Autoscaling ist ebenfalls angegeben.
RESERVATION_NAME
: Wenn Sie die Cloud TPU-Reservierung verwenden, ist dies die Liste der Labels der Reservierungsressourcen, die beim Erstellen des Knotenpools verwendet werden sollen. Weitere Informationen zum Ausfüllen derRESERVATION_LABEL_VALUES
im Feldreservation_affinity
finden Sie unter Terraform-Anbieter.spot
: Legt den Knotenpool so fest, dass Spot-VMs für die TPU-Knoten verwendet werden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.flex_start
: Legt fest, dass der Knotenpool die Verbrauchsoption flex-start verwendet. Kann nicht auftrue
gesetzt werden, wennspot
aktiviert ist. Flex-Start wird in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt.
Console
So erstellen Sie einen Knotenpool mit TPUs:
Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie auf Knotenpool hinzufügen add_box.
Klicken Sie im Abschnitt Knotenpooldetails das Kästchen Knotenstandorte angeben an.
Wählen Sie die Zone anhand der TPU-Version aus, die Sie verwenden möchten. Informationen dazu, wie Sie eine verfügbare Zone ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.
Klicken Sie im Navigationsbereich auf Knoten.
Wählen Sie im Abschnitt Maschinenkonfiguration die Option TPUs aus.
Wählen Sie im Drop-down-Menü Serie eine der folgenden Optionen aus:
- CT3: TPU v3, einzelnes Host-Gerät
- CT3P: TPU v3, Pod-Slice mit mehreren Hosts
- CT4P: TPU v4
- CT5LP: TPU v5e
- CT5P: TPU v5p
- CT6E: TPU Trillium (v6e)
Wählen Sie im Drop-down-Menü Maschinentyp den Namen des Computers aus, der für Knoten verwendet werden soll. In der Tabelle TPU-Version auswählen erfahren Sie, wie Sie den Maschinentyp und die TPU-Topologie definieren, mit denen ein TPU-Slice-Knotenpool mit einem einzelnen Host erstellt wird.
Wählen Sie im Drop-down-Menü TPU-Topologie die physische Topologie für das TPU-Slice aus.
Klicken Sie im Dialogfeld Änderungen erforderlich auf Änderungen vornehmen.
Achten Sie darauf, dass als Bootlaufwerktyp entweder Nichtflüchtiger Standardspeicher oder Nichtflüchtiger SSD-Speicher angegeben ist.
Klicken Sie optional das Kästchen Knoten auf Spot-VMs aktivieren an, um Spot-VMs für die Knoten im Knotenpool zu verwenden.
Klicken Sie auf Erstellen.
TPU-Slice-Knotenpool mit mehreren Hosts erstellen
Sie können ein TPU-Slice mit mehreren Hosts über die Google Cloud CLI, Terraform oder die Google Cloud Console erstellen.
gcloud
gcloud container node-pools create POOL_NAME \
--location=LOCATION \
--cluster=CLUSTER_NAME \
--node-locations=NODE_ZONES \
--machine-type=MACHINE_TYPE \
--tpu-topology=TPU_TOPOLOGY \
[--num-nodes=NUM_NODES] \
[--spot \]
[--flex-start \]
[--enable-autoscaling \
--max-nodes MAX_NODES]
[--reservation-affinity=specific \
--reservation=RESERVATION_NAME] \
[--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
[--placement-type=COMPACT]
Ersetzen Sie Folgendes:
POOL_NAME
: Der Name des neuen Knotenpools.LOCATION
: Der Name der Zone basierend auf der zu verwendenden TPU-Version. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.CLUSTER_NAME
ist der Name des Clusters.NODE_ZONES
: Die kommagetrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.MACHINE_TYPE
: Der Maschinentyp für Knoten. Weitere Informationen zu den verfügbaren Maschinentypen finden Sie unter TPU-Version auswählen.TPU_TOPOLOGY
: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt von der TPU-Version ab. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter Topologie auswählen.Weitere Informationen finden Sie unter Topologie.
Optional können Sie auch die folgenden Flags verwenden:
NUM_NODES
: Die maximale Anzahl von Knoten im Knotenpool. Sie muss null oder das Produkt der inTPU_TOPOLOGY
definierten Werte ({A}x{B}x{C}
) geteilt durch die Anzahl der Chips in jeder VM sein. Für die Multi-Host-Version von TPU v4 und TPU v5e beträgt die Anzahl der Chips in jeder VM vier. Wenn IhreTPU_TOPOLOGY
also2x4x4
ist (TPU v4 mit vier Chips in jeder VM), beträgtNUM_NODES
32/4, was 8 entspricht. Wenn Sie dieses Flag weglassen, wird die Anzahl der Knoten anhand der Topologie und des Maschinentyps berechnet und standardmäßig festgelegt.RESERVATION_NAME
: Der Name der Reservierung, die GKE beim Erstellen des Knotenpools verwendet. Wenn Sie dieses Flag weglassen, verwendet GKE die verfügbaren TPU-Slice-Knotenpools. Weitere Informationen zu TPU-Reservierungen finden Sie unter TPU-Reservierung.--spot
: Legt den Knotenpool so fest, dass Spot-VMs für die TPU-Slice-Knoten verwendet werden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.--flex-start
: Legt den Knotenpool so fest, dass Flex-Start-VMs verwendet werden. Flex-Start-VMs werden mit der Verbrauchsoption flex-start erstellt, die in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt wird.--enable-autoscaling
: Knotenpool mit aktiviertem Autoscaling erstellen. Wenn GKE einen TPU-Slice-Knotenpool mit mehreren Hosts skaliert, wird der Knotenpool atomar von null auf die maximale Größe hochskaliert.MAX_NODES
: Maximale Größe des Knotenpools. Das Flag--max-nodes
ist erforderlich, wenn--enable-autoscaling
angegeben ist und dem Produkt aus den inTPU_TOPOLOGY
definierten Werten ({A}x{B}x{C}
) geteilt durch die Anzahl der Chips in jeder VM entsprechen muss.
--node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY
: Gibt GKE, dass der Knotenpool für TPU-Slices mit mehreren Hosts eine Sammlung ist. Verwenden Sie dieses Flag, wenn die folgenden Bedingungen erfüllt sind:- Der Knotenpool führt Inferenzarbeitslasten im neuen Knotenpool aus.
- Der Knotenpool verwendet TPU Trillium.
- Spot-VMs unterstützen keine Zeitplanung für die Erfassung.
Weitere Informationen zur Verwaltung der Planung von Sammlungen finden Sie unter Planung von Sammlungen in TPU-Slices mit mehreren Hosts verwalten.
--placement-type=COMPACT
: Knotenpool mit aktivierter kompakter Platzierung erstellen. Diese Option muss mit dem Flag--tpu-topology
verwendet werden. Weitere Informationen finden Sie unter Richtlinie für kompakte Platzierung erstellen und TPU-Topologie.
Terraform
- Prüfen Sie, ob Sie Version 4.84.0 oder höher des Anbieters
google
verwenden. Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu:
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] initial_node_count = NUM_NODES autoscaling { max_node_count = MAX_NODES location_policy = "ANY" } 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 flex_start = false } placement_policy { type = "COMPACT" tpu_topology = TPU_TOPOLOGY } }
Ersetzen Sie Folgendes:
NODE_POOL_RESOURCE_NAME
: Der Name der Knotenpoolressource in der Terraform-Vorlage.PROJECT_ID
: Ihre Projekt-ID.CLUSTER_NAME
: Der Name des vorhandenen Clusters, dem der Knotenpool hinzugefügt werden soll.POOL_NAME
: Der Name des Knotenpools, der erstellt werden soll.CLUSTER_LOCATION
: Der Compute-Standort des Clusters. Wir empfehlen einen regionalen Cluster für eine höhere Zuverlässigkeit der Kubernetes-Steuerungsebene. Sie können auch einen zonalen Cluster verwenden. Weitere Informationen finden Sie unter TPU-Version und Topologie auswählen.NODE_ZONES
: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.NUM_NODES
: Die maximale Anzahl von Knoten im Knotenpool. Sie muss null oder das Produkt der Anzahl der TPU-Chips geteilt durch vier sein, da in TPU-Slices mit mehreren Hosts jeder TPU-Slice-Knoten vier Chips hat. WennTPU_TOPOLOGY
beispielsweise4x8
ist, gibt es 32 Chips, d. h.,NUM_NODES
muss 8 sein. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter TPU-Version auswählen.TPU_TOPOLOGY
: Dies gibt die gewünschte physische Topologie für das TPU-Slice an. Das Format der Topologie hängt von der verwendeten TPU-Version ab. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter Topologie auswählen.
Optional können Sie auch die folgenden Variablen verwenden:
RESERVATION_NAME
: Wenn Sie die TPU-Reservierung verwenden, ist dies die Liste der Labels der Reservierungsressourcen, die beim Erstellen des Knotenpools verwendet werden sollen. Weitere Informationen zum Ausfüllen derRESERVATION_LABEL_VALUES
im Feldreservation_affinity
finden Sie unter Terraform-Anbieter.autoscaling
: Knotenpool mit aktiviertem Autoscaling erstellen. Wenn GKE einen TPU-Slice-Knotenpool mit mehreren Hosts skaliert, wird der Knotenpool atomar von null auf die maximale Größe hochskaliert.MAX_NODES
: Die maximale Größe des Knotenpools. Sie muss gleich dem Produkt aus den Werten inTPU_TOPOLOGY
definierten Werte ({A}x{B}x{C}
) geteilt durch die Anzahl der Chips in jeder VM sein.
spot
: Ermöglicht dem Knotenpool, Spot-VMs für die TPU-Slice-Knoten zu verwenden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.flex_start
: Legt fest, dass der Knotenpool die Verbrauchsoption flex-start verwendet. Kann nicht auftrue
gesetzt werden, wennspot
aktiviert ist.
Console
So erstellen Sie einen Knotenpool mit TPUs:
Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie auf Knotenpool hinzufügen add_box.
Klicken Sie im Abschnitt Knotenpooldetails das Kästchen Knotenstandorte angeben an.
Wählen Sie den Namen der Zone basierend auf der TPU-Version aus, die Sie verwenden möchten. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.
Klicken Sie im Navigationsbereich auf Knoten.
Wählen Sie im Abschnitt Maschinenkonfiguration die Option TPUs aus.
Wählen Sie im Drop-down-Menü Serie eine der folgenden Optionen aus:
- CT3P: Für TPU v3.
- CT4P: Für TPU v4.
- CT5LP: Für TPU v5e.
Wählen Sie im Drop-down-Menü Maschinentyp den Namen des Computers aus, der für Knoten verwendet werden soll. In der Tabelle TPU-Version auswählen erfahren Sie, wie Sie den Maschinentyp und die TPU-Topologie definieren, mit denen ein TPU-Slice-Knotenpool mit mehreren Hosts erstellt wird.
Wählen Sie im Drop-down-Menü TPU-Topologie die physische Topologie für das TPU-Slice aus.
Klicken Sie im Dialogfeld Änderungen erforderlich auf Änderungen vornehmen.
Achten Sie darauf, dass als Bootlaufwerktyp entweder Nichtflüchtiger Standardspeicher oder Nichtflüchtiger SSD-Speicher angegeben ist.
Klicken Sie optional das Kästchen Knoten auf Spot-VMs aktivieren an, um Spot-VMs für die Knoten im Knotenpool zu verwenden.
Klicken Sie auf Erstellen.
Umgang von GKE mit Kapazitätsproblemen
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 in die Warteschlange gestellte TPU-Anfrage löschen, indem Sie den TPU-Slice-Knotenpool löschen.
Arbeitslast auf TPU-Slice-Knoten ausführen
In diesem Abschnitt wird beschrieben, wie Sie Ihre Arbeitslasten vorbereiten und wie Sie sie ausführen können.
Arbeitslasten vorbereiten
Für TPU-Arbeitslasten gelten die folgenden Vorbereitungsanforderungen.
- 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 vonlibtpu.so
. Um Konflikte bei Paketversionen zu vermeiden, empfehlen wir die Verwendung eines JAX AI-Images. Für die Verwendung von TPUs in GKE benötigen Sie die folgenden Versionen:TPU-Typ libtpu.so
-VersionTPU Trillium (v6e)
tpu-v6e-slice
- Empfohlenes JAX AI-Image: jax0.4.35-rev1 oder höher
- Empfohlene jax[tpu]-Version: v0.4.9 oder höher.
- Empfohlene torchxla[tpuvm]-Version: v2.1.0 oder höher.
TPU v5e
tpu-v5-lite-podslice
- Empfohlenes JAX AI-Image: jax0.4.35-rev1 oder höher
- 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
- Empfohlenes JAX AI-Image: jax0.4.35-rev1 oder höher
- 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
- Empfohlenes JAX AI-Image: jax0.4.35-rev1 oder höher
- Empfohlene jax[tpu]-Version: v0.4.4 oder höher
- Empfohlene torchxla[tpuvm]-Version: v2.0.0 oder höher
TPU v3
tpu-v3-slice
tpu-v3-device
- Empfohlenes JAX AI-Image: jax0.4.35-rev1 oder höher
- Empfohlene jax[tpu]-Version: v0.4.4 oder höher
- Empfohlene torchxla[tpuvm]-Version: v2.0.0 oder höher
- 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 derTPU_WORKER_ID
indexiert.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.TPU_TOPOLOGY
: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt von der TPU-Version ab. Weitere Informationen finden Sie unter TPUs in GKE planen.
GKE fügt diese Umgebungsvariablen automatisch ein. Dazu wird ein mutierender Webhook verwendet, wenn ein Job mit
Wenn Sie Ressourcen von TPU mit mehreren Hosts mit Kuberay bereitstellen, stellt GKE im Rahmen der experimentellen 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 experimentellen TPU-Nutzerhandbuch. Der mutierende Webhook schleust diese Umgebungsvariablen in Ray-Cluster ein, diecompletionMode: Indexed
,subdomain
,parallelism > 1
erstellt wird, und es werdengoogle.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.google.com/tpu
-Attribute und einencloud.google.com/gke-tpu-topology
-Knotenselektor für mehrere Hosts anfordern.
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.
- 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 # Node selector to target TPU v4 slice nodes. cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice. containers: - name: tpu-job image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest ports: - containerPort: 8471 # Default port using which TPU VMs communicate - containerPort: 8431 # Port to export TPU runtime metrics, if supported. securityContext: privileged: true # Required for GKE versions earlier than 1.28 to access TPUs. command: - bash - -c - | python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips. resources: requests: cpu: 10 memory: 407Gi google.com/tpu: 4 # Request 4 TPU chips for this workload. limits: cpu: 10 memory: 407Gi google.com/tpu: 4 # Limit to 4 TPU chips for this workload.
- 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.
- 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
- 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 etwa so aus:
TPU cores: 16
- Optional: Arbeitslast entfernen:
kubectl delete -f available-chips-multihost.yaml
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.
- 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 # Node selector to target TPU v5e slice nodes. cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice. containers: - name: tpu-job image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest ports: - containerPort: 8431 # Port to export TPU runtime metrics, if supported. securityContext: privileged: true # Required for GKE versions earlier than 1.28 to access TPUs. command: - bash - -c - | python -c 'import jax; print("Total TPU chips:", jax.device_count())' resources: requests: google.com/tpu: 8 # Request 8 TPU chips for this container. limits: google.com/tpu: 8 # Limit to 8 TPU chips for this container.
- 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).
- Rufen Sie die Logs des Pods ab:
kubectl logs tpu-job-jax-v5
Die Ausgabe sieht etwa so aus:
Total TPU chips: 8
- Optional: Arbeitslast entfernen:
kubectl delete -f available-chips-singlehost.yaml
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, Blau/Grün-Upgrades oder Upgrades mit kurzer Lebensdauer. 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 Clouddie 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.
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 Einstellungen konfigurieren
In den folgenden Abschnitten werden die zusätzlichen Konfigurationen beschrieben, die Sie auf Ihre TPU-Arbeitslasten anwenden können.
Planung von Sammlungen verwalten
In TPU Trillium können Sie die Planung von Sammlungen verwenden, um TPU-Slice-Knoten zu gruppieren. Durch das Gruppieren dieser TPU-Slice-Knoten lässt sich die Anzahl der Replikate leichter an die Arbeitslastanforderungen anpassen. Google Cloud steuert Softwareupdates, um dafür zu sorgen, dass immer genügend Slices in der Sammlung verfügbar sind, um Traffic zu verarbeiten.
TPU Trillium unterstützt die Planung von Sammlungen für Knotenpools mit einem einzelnen Host und mehreren Hosts, auf denen Inferenz-Arbeitslasten ausgeführt werden. Im Folgenden wird beschrieben, wie sich die Planung von Sammlungen je nach verwendetem TPU-Slice-Typ verhält:
- TPU-Slice mit mehreren Hosts:GKE gruppiert TPU-Slices mit mehreren Hosts zu einer Sammlung. Jeder GKE-Knotenpool ist ein Replikat in dieser Sammlung. Wenn Sie eine Sammlung definieren möchten, erstellen Sie einen TPU-Slice mit mehreren Hosts und weisen Sie der Sammlung einen eindeutigen Namen zu. Wenn Sie der Sammlung weitere TPU-Slices hinzufügen möchten, erstellen Sie einen weiteren TPU-Slice-Knotenpool mit mehreren Hosts mit demselben Sammlungsnamen und Arbeitslasttyp.
- TPU-Slice mit einem Host:GKE betrachtet den gesamten TPU-Slice-Knotenpool mit einem Host als Sammlung. Wenn Sie der Sammlung weitere TPU-Slices hinzufügen möchten, können Sie die Größe des TPU-Slice-Knotenpools mit einem Host ändern.
Wenn Sie eine Sammlung verwalten möchten, führen Sie je nach verwendetem Knotentyp eine der folgenden Aktionen aus.
Sammlungsscheduling in TPU-Slice-Knotenpools mit mehreren Hosts verwalten
Verwenden Sie die folgenden Aufgaben, um TPU-Slice-Knotenpools mit mehreren Hosts zu verwalten.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein TPU-Slice-Pool mit mehreren Hosts Teil einer Sammlung ist:
gcloud container node-pools describe NODE_POOL_NAME \ --location LOCATION \ --cluster CLUSTER_NAME \ --format="json" | jq -r \ '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'
Die Ausgabe sieht etwa so aus:
nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code> gke-workload-type: HIGH_AVAILABILITY
Wenn der Pool mit TPU-Slices mit mehreren Hosts Teil einer Sammlung ist, enthält die Ausgabe die folgenden Labels:
cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>
Führen Sie den folgenden Befehl aus, um die Liste der Sammlungen im Cluster abzurufen:
#!/bin/bash # Replace with your cluster name, project, and location CLUSTER_NAME=CLUSTER_NAME PROJECT=PROJECT_ID LOCATION=LOCATION declare -A collection_names node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)") # Iterate over each node pool for pool in $node_pools; do # Describe the node pool and extract labels using jq collection_name=$(gcloud container node-pools describe "$pool" \ --cluster "$CLUSTER_NAME" \ --project "$PROJECT" \ --location "$LOCATION" \ --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]') # Add the collection name to the associative array if it's not empty if [[ -n "$collection_name" ]]; then collection_names["$collection_name"]=1 fi done # Print the unique node pool collection names echo "Unique cloud.google.com/gke-nodepool-group-name values:" for name in "${!collection_names[@]}"; do echo "$name" done
Die Ausgabe sieht etwa so aus:
Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}
Führen Sie den folgenden Befehl aus, um eine Liste der Knotenpools abzurufen, die zu einer Sammlung gehören:
#!/bin/bash TARGET_COLLECTION_NAME=COLLECTION_NAME CLUSTER_NAME=CLUSTER_NAME PROJECT=PROJECT_ID LOCATION=LOCATION matching_node_pools=() # Get the list of all node pools in the cluster node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)") # Iterate over each node pool for pool in $node_pools; do # Get the value of the cloud.google.com/gke-nodepool-group-name label collection_name=$(gcloud container node-pools describe "$pool" \ --cluster "$CLUSTER_NAME" \ --project "$PROJECT" \ --location "$LOCATION" \ --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]') # Check if the group name matches the target value if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then matching_node_pools+=("$pool") fi done # Print the list of matching node pools echo "Node pools with collection name '$TARGET_COLLECTION_NAME':" for pool in "${matching_node_pools[@]}"; do echo "$pool" done
Die Ausgabe sieht etwa so aus:
Node pools with collection name 'COLLECTION_NAME': {NODE_POOL_NAME_1} {NODE_POOL_NAME_2} {NODE_POOL_NAME_3}
Wenn Sie die Erfassung skalieren möchten, erstellen Sie einen weiteren TPU-Slice-Knotenpool mit mehreren Hosts und fügen Sie
cloud.google.com/gke-workload-type
undcloud.google.com/gke-nodepool-group-name
hinzu. Verwenden Sie denselben Sammlungsnamen incloud.google.com/gke-nodepool-group-name
und führen Sie denselben Workload-Typ aus. Wenn die automatische Knotenbereitstellung für den Cluster aktiviert ist, erstellt GKE automatisch Pools basierend auf den Anforderungen der Arbeitslast.Wenn Sie die Sammlung herunterskalieren möchten, löschen Sie den Knotenpool.
Entfernen Sie alle angehängten Knotenpools, um die Sammlung zu löschen. Sie können den Knotenpool löschen oder den Cluster löschen. Wenn Sie den Cluster löschen, werden alle Sammlungen darin entfernt.
Sammlungsplanung in TPU-Slice-Knotenpools mit einem Host verwalten
Verwenden Sie die folgenden Aufgaben, um TPU-Slice-Knotenpools mit einem Host zu verwalten.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob für einen TPU-Slice-Pool mit einem einzelnen Host die Sammlung geplant ist:
gcloud container node-pools describe NODE_POOL_NAME \ --cluster CLUSTER_NAME \ --project PROJECT_NAME \ --location LOCATION \ --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
Die Ausgabe sieht etwa so aus:
gke-workload-type: HIGH_AVAILABILITY
Wenn der TPU-Slice-Pool mit einem einzelnen Host Teil einer Sammlung ist, enthält die Ausgabe das Label
cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
.Wenn Sie die Erfassung skalieren möchten, passen Sie die Größe des Knotenpools manuell oder automatisch mit der automatischen Knotenbereitstellung an.
Wenn Sie die Sammlung herunterskalieren möchten, löschen Sie den Knotenpool.
Entfernen Sie alle angehängten Knotenpools, um die Sammlung zu löschen. Sie können den Knotenpool löschen oder den Cluster löschen. Wenn Sie den Cluster löschen, werden alle Sammlungen darin entfernt.
Multislice verwenden
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 aktivieren
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.
TPUs mit benutzerdefinierten Compute-Klassen bereitstellen
Sie können GKE auch so konfigurieren, dass TPUs bei Skalierungsvorgängen angefordert werden, bei denen neue Knoten erstellt werden. Verwenden Sie dazu benutzerdefinierte Compute-Klassen.
Sie können TPU-Konfigurationsoptionen in der Spezifikation Ihrer benutzerdefinierten Compute-Klasse angeben. Wenn eine GKE-Arbeitslast diese benutzerdefinierte Compute-Klasse verwendet, versucht GKE, beim Hochskalieren TPUs mit der von Ihnen angegebenen Konfiguration bereitzustellen.
So stellen Sie TPUs mit einer benutzerdefinierten Compute-Klasse bereit, die den TPU-Regeln entspricht, und stellen die Arbeitslast bereit:
Speichern Sie das folgende Manifest als
tpu-compute-class.yaml
:apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: tpu-class spec: priorities: - tpu: type: tpu-v5-lite-podslice count: 4 topology: 2x4 - spot: true tpu: type: tpu-v5-lite-podslice count: 4 topology: 2x4 - flexStart: enabled: true tpu: type: tpu-v6e-slice count: 4 topology: 2x4 nodePoolAutoCreation: enabled: true
Stellen Sie die Compute-Klasse bereit:
kubectl apply -f tpu-compute-class.yaml
Weitere Informationen zu benutzerdefinierten Compute-Klassen und TPUs finden Sie unter TPU-Konfiguration.
Speichern Sie das folgende Manifest als
tpu-job.yaml
:apiVersion: v1 kind: Service metadata: name: headless-svc spec: clusterIP: None selector: job-name: tpu-job --- apiVersion: batch/v1 kind: Job metadata: name: tpu-job spec: backoffLimit: 0 completions: 4 parallelism: 4 completionMode: Indexed template: spec: subdomain: headless-svc restartPolicy: Never nodeSelector: cloud.google.com/compute-class: tpu-class containers: - name: tpu-job image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest ports: - containerPort: 8471 # Default port using which TPU VMs communicate - containerPort: 8431 # Port to export TPU runtime metrics, if supported. command: - bash - -c - | python -c 'import jax; print("TPU cores:", jax.device_count())' resources: requests: cpu: 10 memory: MEMORY_SIZE google.com/tpu: NUMBER_OF_CHIPS limits: cpu: 10 memory: MEMORY_SIZE google.com/tpu: NUMBER_OF_CHIPS
Ersetzen Sie Folgendes:
NUMBER_OF_CHIPS
: Die Anzahl der TPU-Chips, die für den Container verwendet werden sollen. Muss fürlimits
undrequests
derselbe Wert sein, der dem Wert im Feldtpu.count
in der ausgewählten benutzerdefinierten Compute-Klasse entspricht.MEMORY_SIZE
: Die maximale Menge an Speicher, die von der TPU verwendet wird. Die Arbeitsspeicherlimits hängen von der verwendeten TPU-Version und ‑Topologie ab. Weitere Informationen finden Sie unter Mindest- und Höchstwerte für Beschleuniger.NUMBER_OF_CHIPS
: Die Anzahl der TPU-Chips, die für den Container verwendet werden sollen. Muss fürlimits
undrequests
derselbe Wert sein.
Stellen Sie den Job bereit:
kubectl create -f tpu-job.yaml
Wenn Sie diesen Job erstellen, führt GKE automatisch die folgenden Schritte aus:
- Stellt Knoten bereit, auf denen die Pods ausgeführt werden. Je nach TPU-Typ, Topologie und Ressourcenanforderungen, die Sie angegeben haben, sind diese Knoten entweder Slices mit einem Host oder Slices mit mehreren Hosts. Je nach Verfügbarkeit von TPU-Ressourcen mit der höchsten Priorität kann GKE auf niedrigere Prioritäten zurückgreifen, um die Verfügbarkeit zu maximieren.
- Fügt den Pods Markierungen und den Knoten Toleranzen hinzu, um zu verhindern, dass andere Arbeitslasten auf denselben Knoten wie TPU-Arbeitslasten ausgeführt werden.
Weitere Informationen zu benutzerdefinierten Compute-Klassen
Nach Abschluss dieses Abschnitts können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen:
kubectl delete -f tpu-job.yaml
Automatische Reparatur für TPU-Slice-Knoten konfigurieren
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 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 IhrenGoogle Cloud -Kundenbetreuer, um das entsprechende Kontingent zu erhöhen.
Ordnungsgemäße Beendigung für 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
Für Container, die in Knoten in GKE-Version 1.28 oder höher ausgeführt werden, muss der privilegierte Modus für den Zugriff auf TPUs nicht aktiviert sein. Für Knoten in GKE-Version 1.28 und früher ist der privilegierte Modus erforderlich.
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:
Bearbeiten Sie
securityContext
so, dass die folgenden Felder enthalten sind:securityContext: capabilities: add: ["SYS_RESOURCE"]
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
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
Die Beobachtbarkeit von Knotenpools in der Google Cloud Console ist allgemein verfügbar. Wenn Sie den Status Ihrer TPU-Knotenpools mit mehreren Hosts in GKE aufrufen möchten, rufen Sie das von Cloud Monitoring bereitgestellte Dashboard GKE TPU Node Pool Status auf:
Dieses Dashboard bietet umfassende Informationen zum Zustand Ihrer TPU-Knotenpools mit mehreren Hosts. Weitere Informationen finden Sie unter Zustandsmesswerte für TPU-Knoten und ‑Knotenpools überwachen.
Auf der Seite Kubernetes-Cluster in derGoogle Cloud Console werden auf dem Tab Beobachtbarkeit auch TPU-Beobachtbarkeitsmesswerte wie die TPU-Nutzung unter der Überschrift Beschleuniger > TPU angezeigt. Weitere Informationen finden Sie unter Beobachtbarkeitsmesswerte aufrufen.
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 sowohl JAX-Version 0.4.14 oder höher verwenden als auch 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
Messwerte zum Zustand von TPU-Knoten und ‑Knotenpools überwachen
Wenn bei einem Trainingsjob ein Fehler auftritt oder er fehlschlägt, können Sie die Messwerte der zugrunde liegenden Infrastruktur prüfen, um festzustellen, ob die Unterbrechung durch ein Problem mit dem zugrunde liegenden Knoten oder Knotenpool verursacht wurde.
Knotenstatus
In GKE-Version 1.32.1-gke.1357001 oder höher wird der Zustand eines GKE-Knotens durch den folgenden GKE-Systemmesswert dargestellt:
kubernetes.io/node/status_condition
Im Feld condition
werden Bedingungen für den Knoten gemeldet, z. B. Ready
, DiskPressure
und MemoryPressure
. Im Feld status
wird der gemeldete Status der Bedingung angezeigt, der True
, False
oder Unknown
sein kann. Dies ist ein Messwert mit dem überwachten Ressourcentyp k8s_node
.
Diese PromQL-Abfrage zeigt, ob ein bestimmter Knoten Ready
ist:
kubernetes_io:node_status_condition{
monitored_resource="k8s_node",
cluster_name="CLUSTER_NAME",
node_name="NODE_NAME",
condition="Ready",
status="True"}
Um Probleme in einem Cluster zu beheben, können Sie sich Knoten ansehen, die andere Bedingungen aufweisen:
kubernetes_io:node_status_condition{
monitored_resource="k8s_node",
cluster_name="CLUSTER_NAME",
condition!="Ready",
status="True"}
Möglicherweise möchten Sie sich speziell Knoten ansehen, die nicht Ready
sind:
kubernetes_io:node_status_condition{
monitored_resource="k8s_node",
cluster_name="CLUSTER_NAME",
condition="Ready",
status="False"}
Wenn keine Daten vorhanden sind, sind die Knoten bereit. Der Status wird alle 60 Sekunden erfasst.
Mit der folgenden Abfrage können Sie den Knotenstatus in der gesamten Flotte ermitteln:
avg by (condition,status)(
avg_over_time(
kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))
Knotenpoolstatus
Der folgende GKE-Systemmesswert für die überwachte Ressource k8s_node_pool
gibt den Status eines GKE-Knotenpools an:
kubernetes.io/node_pool/status
Dieser Messwert wird nur für Multi-Host-TPU-Knotenpools angegeben.
Im Feld status
wird der Status des Knotenpools angegeben, z. B. Provisioning
, Running
, Error
, Reconciling
oder Stopping
. Statusaktualisierungen erfolgen nach Abschluss der GKE API-Vorgänge.
Mit der folgenden PromQL-Abfrage können Sie prüfen, ob ein bestimmter Knotenpool den Status Running
hat:
kubernetes_io:node_pool_status{
monitored_resource="k8s_node_pool",
cluster_name="CLUSTER_NAME",
node_pool_name="NODE_POOL_NAME",
status="Running"}
Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Knotenpools in Ihrem Projekt nach Status gruppiert zu überwachen:
count by (status)(
count_over_time(
kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))
Knotenpoolverfügbarkeit
Der folgende GKE-Systemmesswert gibt an, ob ein TPU-Knotenpool mit mehreren Hosts verfügbar ist:
kubernetes.io/node_pool/multi_host/available
Der Messwert hat den Wert True
, wenn alle Knoten im Knotenpool verfügbar sind, andernfalls False
. Der Messwert wird alle 60 Sekunden abgerufen.
Verwenden Sie die folgende PromQL-Abfrage, um die Verfügbarkeit von TPU-Knotenpools mit mehreren Hosts in Ihrem Projekt zu prüfen:
avg by (node_pool_name)(
avg_over_time(
kubernetes_io:node_pool_multi_host_available{
monitored_resource="k8s_node_pool",
cluster_name="CLUSTER_NAME"}[${__interval}]))
Anzahl der Knotenunterbrechungen
Der folgende GKE-Systemmesswert gibt die Anzahl der Unterbrechungen für einen GKE-Knoten seit der letzten Stichprobe an (der Messwert wird alle 60 Sekunden abgerufen):
kubernetes.io/node/interruption_count
Die Felder interruption_type
(z. B. TerminationEvent
, MaintenanceEvent
oder PreemptionEvent
) und interruption_reason
(z. B. HostError
, Eviction
oder AutoRepair
) können Aufschluss darüber geben, warum ein Knoten unterbrochen wurde.
Wenn Sie eine Aufschlüsselung der Unterbrechungen und ihrer Ursachen in TPU-Knoten in den Clustern in Ihrem Projekt erhalten möchten, verwenden Sie die folgende PromQL-Abfrage:
sum by (interruption_type,interruption_reason)(
sum_over_time(
kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))
Wenn Sie nur die Hostwartungsereignisse sehen möchten, aktualisieren Sie die Abfrage, um den HW/SW Maintenance
-Wert für interruption_reason
zu filtern. Verwenden Sie die folgende PromQL-Abfrage:
sum by (interruption_type,interruption_reason)(
sum_over_time(
kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))
Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Unterbrechungen nach Knotenpool zusammenzufassen:
sum by (node_pool_name,interruption_type,interruption_reason)(
sum_over_time(
kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))
Wiederherstellungszeiten (Time To Recover, TTR) des Knotenpools
Der folgende GKE-Systemmesswert gibt die Verteilung der Dauer des Wiederherstellungszeitraums für GKE-TPU-Knotenpools mit mehreren Hosts an:
kubernetes.io/node_pool/accelerator/times_to_recover
Jede in diesem Messwert aufgezeichnete Stichprobe gibt ein einzelnes Wiederherstellungsereignis für den Knotenpool nach einer Ausfallzeit an.
Dieser Messwert ist nützlich, um die Wiederherstellungszeit und die Zeit zwischen Unterbrechungen von Multi-Host-TPU-Knotenpools zu verfolgen.
Mit der folgenden PromQL-Abfrage können Sie die mittlere Zeit bis zur Wiederherstellung (Mean Time to Recovery, MTTR) für die letzten 7 Tage in Ihrem Cluster berechnen:
sum(sum_over_time(
kubernetes_io:node_pool_accelerator_times_to_recover_sum{
monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
kubernetes_io:node_pool_accelerator_times_to_recover_count{
monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))
Zeiten zwischen Unterbrechungen (Times Between Interruptions, TBI) des Knotenpools
Die Zeit zwischen Unterbrechungen des Knotenpools gibt an, wie lange Ihre Infrastruktur läuft, bevor es zu einer Unterbrechung kommt. Er wird als Durchschnitt über einen bestimmten Zeitraum berechnet. Der Zähler gibt die Gesamtzeit an, in der Ihre Infrastruktur verfügbar war, und der Nenner die Gesamtzahl der Unterbrechungen Ihrer Infrastruktur.
Das folgende PromQL-Beispiel zeigt die durchschnittliche Zeit zwischen Unterbrechungen (Mean Time Between Interruptions, MTBI) für den angegebenen Cluster über einen Zeitraum von sieben Tagen:
sum(count_over_time(
kubernetes_io:node_memory_total_bytes{
monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
kubernetes_io:node_interruption_count{
monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
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/node/accelerator/tensorcore_utilization
kubernetes.io/node/accelerator/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 „Auslastung der Arbeitsspeicherbandbreite“ ist für v5e-TPUs nicht verfügbar.
Nächste Schritte
- 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
- Informationen zum Sandboxing von TPU-Arbeitslasten mit GKE Sandbox