Auf dieser Seite wird Cloud TPU vorgestellt. Außerdem erfahren Sie, wo Sie Informationen zur Verwendung von Cloud TPU mit Google Kubernetes Engine (GKE) finden. Tensor Processing Units (TPUs) sind von Google speziell entwickelte anwendungsspezifische integrierte Schaltungen (Application-Specific Integrated Circuits, ASICs), die verwendet werden, um die beim maschinellen Lernen entstehenden Arbeitslasten zu beschleunigen, die Frameworks wie TensorFlow, PyTorch und JAX nutzen.
Bevor Sie TPUs in GKE verwenden, sollten Sie den folgenden Lernpfad durcharbeiten:
- Lernen Sie mit der Einführung in Cloud TPU, wie ML-Beschleuniger funktionieren.
- Lernen Sie mehr über die aktuelle Verfügbarkeit von TPU-Versionen unter Cloud TPU-Systemarchitektur.
Informationen zum Einrichten von Cloud TPU in GKE finden Sie in den folgenden Ressourcen:
Vorteile von TPUs in GKE
GKE bietet vollständige Unterstützung für die Verwaltung des TPU-VM-Lebenszyklus, einschließlich Erstellen, Konfigurieren und Löschen von TPU-VMs. GKE unterstützt auch Spot-VMs sowie die Verwendung von reservierten Cloud TPUs. TPUs in GKE bieten folgende Vorteile:
- Einheitliche Betriebsumgebung: Eine einzige Plattform für alle ML- und sonstigen Arbeitslasten.
- Automatische Upgrades: GKE automatisiert Versionsupdates, wodurch der operative Aufwand reduziert wird.
- Load-Balancing: GKE verteilt die Last, um die Latenz zu reduzieren und die Zuverlässigkeit zu verbessern.
- Responsive Skalierung: GKE skaliert TPU-Ressourcen automatisch entsprechend den Anforderungen Ihrer Arbeitslasten.
- Ressourcenverwaltung: Mit Kueue, einem nativen Kubernetes-Jobwarteschlangensystem, können Sie Ressourcen über mehrere Mandanten innerhalb Ihrer Organisation verwalten, indem Sie Warteschlangen, vorzeitiges Beenden, Priorisierung und faire Freigabe nutzen.
Terminologie in Bezug auf TPU in GKE
In diesem Dokument wird die folgende Terminologie in Bezug auf TPUs verwendet:
- TPU-Typ: Der Cloud TPU-Typ, z. B. v5e.
- TPU-Slice: Eine Reihe miteinander verbundener TPU-Chips.
- TPU-Topologie: Die Anzahl und die physische Anordnung der TPU-Chips in einem TPU-Slice.
- TPU-Slice-Knoten mit einem einzelnen Host: Ein oder mehrere unabhängige TPU-Knoten. Die an die VMs angehängten TPUs sind nicht über Hochgeschwindigkeits-Interconnect-Verbindungen miteinander verbunden.
- Knoten eines TPU-Slices mit mehreren Hosts: Zwei oder mehr miteinander verbundene TPU-Knoten. Die an die VMs angehängten TPUs sind über Hochgeschwindigkeits-Interconnect-Verbindungen miteinander verbunden. TPU-Knoten mit mehreren Hosts haben folgende Eigenschaften:
- Atomar: GKE behandelt alle miteinander verbundenen Knoten als eine Einheit. Während der Skalierungsvorgänge skaliert GKE die gesamte Gruppe von Knoten auf null und erstellt neue Knoten. Wenn ein Computer in der Gruppe ausfällt oder beendet wird, erstellt GKE die gesamte Gruppe von Knoten als neue Einheit neu.
- Unveränderlich: Sie können der Gruppe der miteinander verbundenen Knoten keine neuen Knoten manuell hinzufügen.
Funktionsweise von TPUs in GKE
Die Kubernetes-Ressourcenverwaltung und -Priorität behandelt TPU-VMs so wie andere VM-Typen. Sie fordern TPU-Chips über den Ressourcennamen google.com/tpu an:
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
Wenn Sie TPUs in GKE verwenden, müssen Sie die folgenden TPU-Eigenschaften beachten:
- Eine TPU-VM kann auf bis zu 8 TPU-Chips zugreifen.
- Ein TPU-Slice enthält eine feste Anzahl von TPU-Chips, die vom ausgewählten TPU-Maschinentyp abhängen.
- Die Anzahl der angeforderten
google.com/tpumuss der Gesamtzahl der verfügbaren Chips auf dem TPU-Knoten entsprechen. Jeder Container in einem GKE-Pod, der TPUs anfordert, muss alle TPU-Chips im Knoten nutzen. Andernfalls schlägt das Deployment fehl, da GKE die TPU-Ressourcen nicht teilweise nutzen kann. Beispiele:- Der Maschinentyp
ct5l-hightpu-8that einen einzelnen TPU-Knoten mit 8 TPU-Chips. Ein GKE-Pod, für den acht TPU-Chips erforderlich sind, kann auf dem Knoten bereitgestellt werden. Zwei GKE-Pods, die jeweils vier TPU-Chips erfordern, können jedoch nicht auf einem Knoten bereitgestellt werden. - Der Maschinentyp
ct5lp-hightpu-4tmit einer2x4-Topologie enthält zwei TPU-Knoten mit jeweils vier Chips, also insgesamt acht TPU-Chips. Ein GKE-Pod, für den acht TPU-Chips erforderlich sind, kann auf keinem der Knoten in diesem Knotenpool bereitgestellt werden. Es können aber zwei Pods, die jeweils vier TPU-Chips erfordern, auf den beiden Knoten im Knotenpool bereitgestellt werden. - TPU v5e mit einer 4x4-Topologie hat 16 Chips in vier Knoten. Die GKE Autopilot-Arbeitslast, für die diese Konfiguration ausgewählt wird, muss für bis zu vier Repliken jeweils vier Chips anfordern.
- Der Maschinentyp
- In Standardclustern können mehrere Kubernetes-Pods auf einer TPU-VM geplant werden, aber in jedem Pod kann nur ein Container auf die TPU-Chips zugreifen.
- Jeder Standard-Cluster benötigt mindestens einen Nicht-TPU-Knotenpool, um kube-system-Pods wie kube-dns zu erstellen.
- Standardmäßig haben TPU-Knoten die
google.com/tpu-Markierung, wodurch verhindert wird, dass Nicht-TPU-Pods auf ihnen geplant werden. Die Markierung sorgt nicht automatisch dafür, dass TPU-Ressourcen vollständig genutzt werden. Sie können Arbeitslasten ausführen, die keine TPUs auf Nicht-TPU-Knoten verwenden, und so TPU-Knoten für Code freigeben, der TPUs verwendet. - GKE erfasst die Logs, die von Containern auf TPU-VMs ausgegeben werden. Weitere Informationen finden Sie unter Logging.
- TPU-Auslastungsmesswerte wie Laufzeitleistung sind in Cloud Monitoring verfügbar. Weitere Informationen finden Sie unter Beobachtbarkeit und Messwerte.
TPU-Konfiguration planen
Wenn Sie TPUs in GKE-Clustern verwenden möchten, müssen Sie die folgenden Parameter festlegen:
- TPU-Typ: Unterschiedliche TPU-Typen haben unterschiedliche Funktionen wie Preis-Leistungs-Verhältnis, Trainingsdurchsatz und Bereitstellungslatenz. Die VMs, an die die TPUs angeschlossen sind, haben unterschiedliche CPU- und Arbeitsspeicherkapazitäten.
- Topologie: Das Layout der Chips im TPU-Typ. Jeder TPU-Typ unterstützt ein 2D- oder 3D-Chiplayout und bestimmte Anordnungen. Wählen Sie eine Topologie aus, die den Parallelisierungsanforderungen Ihres Modells entspricht.
TPU-Interkonnektivität: Der TPU-Typ und die TPU-Topologie bestimmen, ob Sie TPUs in mehreren Knoten mit Hochgeschwindigkeits-Interconnect-Verbindungen erhalten. Damit wird festgelegt, ob TPU-Slice-Knoten mit einem oder mehreren Hosts verwendet werden sollen.
- Für umfangreiche Modelle TPU-Slice-Knoten mit mehreren Hosts verwenden
- Für kleine Modelle TPU-Slice-Knoten mit einem Host verwenden
Privilegierter Modus: Für Container, die in GKE-Knoten der Version 1.28 oder niedriger ausgeführt werden, muss der privilegierte Modus aktiviert sein. Bei Version 1.28 oder höher muss der privilegierte Modus für den Zugriff auf TPUs nicht aktiviert sein.
TPU-Konfiguration für den GKE Autopilot-Modus auswählen
In Autopilot wählen Sie einen TPU-Typ und eine Topologie aus und geben diese in Ihrem Kubernetes-Manifest an. GKE verwaltet die Bereitstellung von Knoten mit TPUs und die Planung Ihrer Arbeitslasten.
TPU-Verfügbarkeit in GKE Autopilot
TPUs sind in bestimmten Google Cloud-Regionen verfügbar. Wenn Sie einen TPU-Typ in Ihrer GKE-Arbeitslast verwenden möchten, muss sich Ihr Cluster in einer für diesen Typ unterstützten Region befinden. Weitere Informationen finden Sie in der Cloud TPU-Dokumentation unter TPU-Regionen und ‑Zonen.
TPU-Typ in Autopilot auswählen
| TPU-Typ | Anzahl der vCPUs | Speicher (GiB) | Anzahl der NUMA-Knoten | Maximale Anzahl von TPU-Chips in einem Slice |
|---|---|---|---|---|
TPU v5p (Vorabversion)tpu-v5p-slice |
208 | 448 | 2 | 6.144 |
TPU v5etpu-v5-lite-podslice |
24 bis 224 | 48 bis 384 | 1 | 256 |
TPU v5e (nur einzelner Host)tpu-v5-lite-device |
24 bis 224 | 48 bis 384 | 1 bis 2 | 8 |
TPU v4tpu-v4-podslice |
240 | 407 | 2 | 4.096 |
In der Cloud TPU-Dokumentation finden Sie die Chipspezifikationen und Preise, anhand derer Sie sich für eine Version entscheiden können.
Topologie für Autopilot auswählen
Die Topologie ist das physische Layout der Chips in einem TPU-Slice. Je nach TPU-Typ ist die Topologie zwei- oder dreidimensional. Nachdem Sie sich für einen TPU-Typ entschieden haben, wählen Sie eine Topologie aus, die von diesem TPU-Typ unterstützt wird. Die Parallelisierungsanforderungen Ihres Modells helfen Ihnen bei der Auswahl einer Topologie. Das Produkt der Topologie ist die Anzahl der Chips im Slice. Beispiel:
2x2x2ist ein TPU v4-Slice mit 8 Chips und mehreren Hosts2x2ist ein TPU v5e-Slice mit 4 Chips mit einem Host.
Die Topologie, die Sie für einen TPU-Typ auswählen, bestimmt, ob Sie TPU-Slice-Knoten mit einem oder mehreren Hosts erhalten. Wenn eine bestimmte Topologie sowohl Slices mit einem Host als auch mit mehreren Hosts unterstützt, bestimmt die Anzahl der TPU-Chips, die Ihre Arbeitslastanfragen erhalten, den erhaltenen Hosttyp. TPU v5e (tpu-v5-lite-podslice) unterstützt beispielsweise die 2x4-Topologie sowohl mit einem als auch mit mehreren Hosts. Wenn Sie in Ihrer Arbeitslast 4 Chips anfordern, erhalten Sie einen Knoten mit mehreren Hosts und 4 Chips. Wenn Sie in Ihrer Arbeitslast 8 Chips anfordern, erhalten Sie einen Knoten mit einem einzelnen Host und 8 Chips.
In der folgenden Tabelle werden die unterstützten Topologien für jeden TPU-Typ sowie die Anzahl der Chips, die Anzahl der Knoten und der Hosttyp beschrieben:
| TPU-Typ | Topologie | TPU-Chips in einem Slice | Anzahl von Knoten | Hosttyp | Hinweise |
|---|---|---|---|---|---|
TPU v5p (Vorabversion)tpu-v5p-slice |
2x2x1 | 4 | 1 | Einzelner Host | Benutzerdefinierte Topologien für mehr als 64 Chips werden unterstützt. Dabei gelten folgende Bedingungen:
|
| 2x2x2 | 8 | 2 | Mehrere Hosts | ||
| 2x2x4 | 16 | 4 | Mehrere Hosts | ||
| 2x4x4 | 32 | 8 | Mehrere Hosts | ||
| 4x4x4 | 64 | 16 | Mehrere Hosts | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Mehrere Hosts | ||
TPU v5etpu-v5-lite-podslice |
1x1 | 1 | 1 | Einzelner Host | Benutzerdefinierte Topologien werden nicht unterstützt. |
| 2x2 | 4 | 1 | |||
| 2x4 | 8 | 1 | |||
| 2x4 | 2 | 1 | Mehrere Hosts | ||
| 4x4 | 16 | 4 | |||
| 4x8 | 32 | 8 | |||
| 8x8 | 64 | 16 | |||
| 8x16 | 128 | 32 | |||
| 16x16 | 256 | 64 | |||
TPU v5e (nur einzelner Host)tpu-v5-lite-device |
1x1 | 1 | 1 | Einzelner Host | Benutzerdefinierte Topologien werden nicht unterstützt |
| 2x2 | 4 | 1 | |||
| 2x4 | 8 | 1 | |||
TPU v4tpu-v4-podslice |
2x2x1 | 4 | 1 | Einzelner Host | Benutzerdefinierte Topologien für mehr als 64 Chips werden unterstützt. Dabei gelten folgende Bedingungen:
|
| 2x2x2 | 8 | 2 | Mehrere Hosts | ||
| 2x2x4 | 16 | 4 | Mehrere Hosts | ||
| 2x4x4 | 32 | 8 | Mehrere Hosts | ||
| 4x4x4 | 64 | 16 | Mehrere Hosts | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Mehrere Hosts |
-
Berechnet sich aus dem Topologieprodukt geteilt durch vier. ↩
Nachdem Sie einen TPU-Typ und eine TPU-Topologie ausgewählt haben, geben Sie diese in Ihrem Arbeitslastmanifest an. Eine Anleitung finden Sie unter TPU-Arbeitslasten in GKE Autopilot bereitstellen.
TPU-Konfiguration für den GKE-Standardmodus auswählen
In den folgenden Abschnitten werden die TPU-Eigenschaften beschrieben, die Sie bei der Planung und Einrichtung Ihrer TPU-Arbeitslasten in GKE berücksichtigen. Weitere Informationen zu verfügbaren Versionen, zum Maschinentypen, zu gültigen Topologien und zur Anzahl der Chips finden Sie in diesem Dokument unter Zuordnung von TPU-Konfigurationen.
TPU-Verfügbarkeit im GKE-Standardmodus
In der folgenden Tabelle ist die TPU-Verfügbarkeit abhängig vom Maschinentyp und der Version aufgeführt:
| TPU-Version | Maschinentyp beginnt mit | Mindestversion für GKE | Verfügbarkeit | Zone |
|---|---|---|---|---|
| TPU v4 | ct4p- |
1.26.1-gke.1500 | Allgemein verfügbar | us-central2-b |
| TPU v5e | ct5l- |
1.27.2-gke.2100 | Allgemein verfügbar | europe-west4-b |
us-central1-a |
||||
| TPU v5e | ct5lp- |
1.27.2-gke.2100 | Allgemein verfügbar | europe-west4-a1 |
us-central1-a1 |
||||
us-east1-c |
||||
us-east5-b1 |
||||
us-west1-c |
||||
us-west4-a |
||||
us-west4-b1 |
||||
| TPU v5p | ct5p- |
1.28.3-gke.1024000 | Vorschau | us-east1-d |
us-east5-a |
||||
us-east5-c |
-
Beim Erstellen einer TPU v5e mit einem Maschinentyp, der mit
ct5lp-in einer der Zoneneurope-west4-a,us-central1-a,us-east5-boderus-west4-bbeginnt, werden TPU v5e-Knotenpools mit einzelnen Hosts nicht unterstützt. Wenn Sie also einen TPU v5e-Knotenpool in einer dieser Zonen erstellen, wird nur der Maschinentypct5lp-hightpu-4tmit einer Topologie von mindestens2x4unterstützt. Um eine TPU v5e mit einzelnem Host inus-central1odereurope-west4zu erstellen, wählen Sie die Zonen aus,us-central1-aodereurope-west4-b, und verwenden Maschinentypen, die mitct5l-beginnen, z. B.ct5l-hightpu-1t,ct5l-hightpu-4t, oderct5l-hightpu-8t“ Wenn Sie eine TPU v5e mit einem einzelnen Host in der Regionus-west4erstellen möchten, wählen Sie die Zoneus-west4-aaus und verwenden Sie Maschinentypen, die mitct5lp-beginnen, z. B.ct5lp-hightpu-1t. Hinweis: Für Maschinentypen, die mitct5l-beginnen, gilt ein anderes Kontingent als für Maschinentypen, die mitct5lp-beginnen. ↩
In den folgenden Abschnitten werden die TPU-Eigenschaften beschrieben, die Sie bei der Planung und Einrichtung Ihrer TPU-Arbeitslasten in GKE berücksichtigen. Weitere Informationen zu verfügbaren Versionen, zum Maschinentypen, zu gültigen Topologien und zur Anzahl der Chips finden Sie in diesem Dokument unter Zuordnung von TPU-Konfigurationen.
Maschinentyp
Maschinentypen, die TPU-Ressourcen unterstützen, folgen einer Namenskonvention, die die TPU-Version und die Anzahl der Chips pro Knoten wie ct<version>-hightpu-<node-chip-count>t enthält. Der Maschinentyp ct5lp-hightpu-1t unterstützt beispielsweise TPU v5e und enthält insgesamt einen TPU-Chip.
Topologie
Die Topologie definiert die physische Anordnung von TPUs in einem TPU-Slice. GKE stellt ein TPU-Slice in zwei- oder dreidimensionalen Topologien bereit, je nach TPU-Version. Sie geben eine Topologie als Anzahl der TPU-Chips in jeder Dimension an:
Für TPU v4 und v5p, das in TPU-Slice-Knotenpools mit mehreren Hosts geplant ist, definieren Sie die Topologie in 3-Tupeln (
{A}x{B}x{C}), z. B.4x4x4. Das Produkt von{A}x{B}x{C}definiert die Anzahl der Chips im Knotenpool. Beispielsweise können Sie kleine Topologien mit weniger als 64 Chips mit Topologieformen wie2x2x2,2x2x4oder2x4x4definieren. Wenn Sie Topologien mit mehr als 64 Chips verwenden, müssen die Werte, die Sie {A}, {B} und {C} zuweisen, die folgenden Bedingungen erfüllen:- {A}, {B} und {C} sind Vielfache von vier.
- Die größte für Version 4 unterstützte Topologie ist
12x16x16und für Version 5p16x16x24. - Die zugewiesenen Werte entsprechen dem Muster A ≤ B ≤ C. Beispiel:
4x4x8oder8x8x8.
Zuordnung der TPU-Konfiguration
Verwenden Sie die folgende Tabelle, um den TPU-Maschinentyp und die Topologie zu definieren, die basierend auf Ihrem Anwendungsfall verwendet werden sollen:
- Verwenden Sie für kleines Modelltraining oder Inferenz TPU v4 oder TPU v5e mit TPU-Slice-Knotenpools mit einem Host.
- Verwenden Sie für umfangreiches Modelltraining oder Inferenz TPU v4 oder TPU v5e mit TPU-Slice-Knotenpools mit mehreren Hosts.
| TPU-Version | Maschinentyp | Topologie | Anzahl der TPU-Chips | Anzahl der VMs | Knotenpooltyp |
|---|---|---|---|---|---|
| TPU v4 | ct4p-hightpu-4t |
2x2x1 | 4 | 1 | Einzelner Host |
| 2x2x2 | 8 | 2 | Mehrere Hosts | ||
| 2x2x4 | 16 | 4 | Mehrere Hosts | ||
| 2x4x4 | 32 | 8 | Mehrere Hosts | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Mehrere Hosts | ||
| TPU v5p | ct5p-hightpu-4t |
2x2x1 | 4 | 1 | Einzelner Host |
| 2x2x2 | 8 | 2 | Mehrere Hosts | ||
| 2x2x4 | 16 | 4 | Mehrere Hosts | ||
| 2x4x4 | 32 | 8 | Mehrere Hosts | ||
| {A}x{B}x{C} | A*B*C | (A*B*C/4)1 | Mehrere Hosts | ||
| TPU v5e | ct5l-hightpu-1t |
1x1 | 1 | 1 | Einzelner Host |
ct5l-hightpu-4t |
2x2 | 4 | 1 | Einzelner Host | |
ct5l-hightpu-8t |
2x4 | 8 | 1 | Einzelner Host | |
ct5lp-hightpu-1t |
1x1 | 1 | 1 | Einzelner Host | |
ct5lp-hightpu-4t |
2x2 | 4 | 1 | Einzelner Host | |
ct5lp-hightpu-8t |
2x4 | 8 | 1 | Einzelner Host | |
ct5lp-hightpu-4t |
2x4 | 8 | 2 | Mehrere Hosts | |
| 4x4 | 16 | 4 | Mehrere Hosts | ||
| 4x8 | 32 | 8 | Mehrere Hosts | ||
| 8x8 | 64 | 16 | Mehrere Hosts | ||
| 8x16 | 128 | 32 | Mehrere Hosts | ||
| 16x16 | 256 | 64 | Mehrere Hosts |
-
Berechnet sich aus dem Topologieprodukt geteilt durch vier. ↩
TPU v5e-Eigenschaften
TPU v5e-Maschinen haben die folgenden technischen Eigenschaften:
| Maschinentyp | Anzahl der vCPUs | Arbeitsspeicher (GB) | Anzahl der NUMA-Knoten | Wahrscheinlichkeit eines vorzeitigen Beendens |
|---|---|---|---|---|
ct5l-hightpu-1t |
24 | 48 | 1 | Höher |
ct5l-hightpu-4t |
112 | 192 | 1 | Mittel |
ct5l-hightpu-8t |
224 | 384 | 2 | Niedriger |
ct5lp-hightpu-1t |
24 | 48 | 1 | Höher |
ct5lp-hightpu-4t |
112 | 192 | 1 | Mittel |
ct5lp-hightpu-8t |
224 | 384 | 1 | Niedrig |
TPU v4- und v5p-Eigenschaften
TPU v4p- und v5p-Maschinen haben die folgenden technischen Eigenschaften:
| Maschinentyp | Anzahl der vCPUs | Arbeitsspeicher (GB) | Anzahl der NUMA-Knoten |
|---|---|---|---|
ct4p-hightpu-4t |
240 | 407 | 2 |
ct5p-hightpu-4t |
208 | 448 | 2 |
TPU-Reservierung
Beim Kauf einer Zusicherung sind TPU-Reservierungen verfügbar. Jede TPU-Reservierung kann mit GKE verwendet werden.
Verwenden Sie beim Erstellen eines TPU-Knotenpools die Flags --reservation und --reservation-affinity=specific, um eine reservierte TPU-Instanz aufzunehmen.
TPUs in GKE automatisch skalieren
GKE unterstützt Tensor Processing Units (TPUs), um ML-Arbeitslasten zu beschleunigen. Sowohl der TPU-Slice-Knotenpool mit einem einzelnen Host als auch der TPU-Slice-Knotenpool mit mehreren Hosts unterstützen Autoscaling und die automatische Bereitstellung.
Mit dem Flag --enable-autoprovisioning in einem GKE-Cluster erstellt oder löscht GKE TPU-Slice-Knotenpools mit einem oder mehreren Hosts mit einer TPU-Version und Topologie, die die Anforderungen ausstehender Arbeitslasten erfüllt.
Wenn Sie --enable-autoscaling verwenden, skaliert GKE den Knotenpool basierend auf seinem Typ so:
Einzelner Host TPU-Slice-Knotenpool: GKE fügt dem vorhandenen Knotenpool TPU-Knoten hinzu oder entfernt sie. Der Knotenpool kann eine beliebige Anzahl von TPU-Knoten zwischen null und der maximalen Größe des Knotenpools enthalten, wie durch --max-nodes und die --total-max-nodes-Flags bestimmt. Wenn der Knotenpool skaliert wird, haben alle TPU-Knoten im Knotenpool denselben Maschinentyp und dieselbe Topologie. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit einem Host finden Sie unter Knotenpool erstellen.
TPU-Slice-Knotenpool mit mehreren Hosts: GKE skaliert den Knotenpool in kleinstmöglichen Schritten von null auf die Anzahl der Knoten, die für die TPU-Topologie erforderlich sind. Bei einem TPU-Knotenpool mit dem Maschinentyp
ct5lp-hightpu-4tund der Topologie16x16enthält der Knotenpool beispielsweise 64 Knoten. GKE Autoscaling sorgt dafür, dass dieser Knotenpool genau 0 oder 64 Knoten hat. Beim Herunterskalieren entfernt GKE alle geplanten Pods und leert den gesamten Knotenpool auf null. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit mehreren Hosts finden Sie unter Knotenpool erstellen.
Beschränkungen
- Für Kapazitätsreservierungen müssen Sie eine spezifische Reservierung verwenden.
- Die GKE-Kostenzuordnung und -Nutzungsmessung enthält keine Daten zur Nutzung oder zu den Kosten der reservierten TPU v4.
- TPU v5p und v5e unterstützen kein Riptide-/Image-Streaming in us-east5.
- Das TPU v5p-Autoscaling wird auf GKE-Clustern mit Steuerungsebenen unterstützt, auf denen mindestens 1.29.2-gke.1035000 oder mindestens 1.28.7-gke.1020000 ausgeführt wird.
Überlegungen zur Arbeitslastplanung
TPUs haben besondere Merkmale, die eine spezielle Arbeitslastplanung und -verwaltung in Kubernetes erfordern. In den folgenden Abschnitten finden Sie Best Practices für die Planung.
CPU
Dieser Abschnitt gilt nicht für Autopilot-Cluster, da GKE jeden TPU-Pod auf einem eigenen Knoten platziert.
Sorgen Sie dafür, dass Ihr GKE-Pod die google.com/tpu-Markierung tolerieren kann, um eine Arbeitslast auf der Onboard-CPU auf einer TPU-VM zu planen. Wenn Sie die Arbeitslast für bestimmte Knoten bereitstellen möchten, verwenden Sie die Knotenauswahl.
Die Kubernetes-Ressourcenverwaltung und -Priorität behandelt TPU-VMs so wie andere VM-Typen. Damit Pods, die TPU-Planung erfordern, Vorrang vor anderen Pods auf denselben Knoten haben, fordern Sie die maximale CPU- oder Arbeitsspeichermenge für diese TPU-Pods an. Pods mit niedriger Priorität sollten folgende Voraussetzungen erfüllen:
- Legen Sie niedrige CPU- und Speicheranforderungen fest, damit der Knoten genügend zuweisbare Ressourcen für die TPU-Arbeitslasten hat. Weitere Informationen finden Sie unter So wendet Kubernetes Ressourcenanfragen und -limits an.
- Legen Sie kein CPU-Limit (unbegrenzt) fest, damit die Pods Bursts verwenden können, um alle nicht verwendeten Zyklen zu nutzen.
- Legen Sie ein hohes Arbeitsspeicherlimit fest, damit Pods den meisten nicht verwendeten Arbeitsspeicher verwenden können, ohne die Stabilität der Knoten zu beeinträchtigen.
Wenn ein Kubernetes-Pod keine CPUs und keinen Arbeitsspeicher anfordert (selbst wenn er TPUs anfordert), betrachtet Kubernetes ihn als Best-Effort-Pod und es gibt keine Garantie dafür, dass CPU und Arbeitsspeicher benötigt werden. Nur Pods, die explizit CPU und Arbeitsspeicher anfordern, haben solche Garantien. Weitere Informationen finden Sie unter Ressourcenverwaltung für Pods und Container.
Weitere Informationen finden Sie unter Best Practices für Kubernetes: Ressourcenanforderungen und -limits.
Unterbrechungen der Arbeitslast reduzieren
Wenn Sie TPUs zum Trainieren eines Modells für maschinelles Lernen verwenden und Ihre Arbeitslast unterbrochen wird, geht alle seit dem letzten Prüfpunkt ausgeführte Arbeit verloren. So verringern Sie die Wahrscheinlichkeit, dass Ihre Arbeitslast unterbrochen wird:
- Legen Sie eine höhere Priorität für diesen Job als für alle anderen Jobs fest: Wenn die Ressourcen knapp sind, vorzeitig beendet der GKE-Planer Jobs mit niedrigerer Priorität vorzeitig, um einen Job mit höherer Priorität zu planen. Darüber hinaus wird damit sichergestellt, dass Ihre Arbeitslast mit höherer Priorität alle erforderlichen Ressourcen erhält (bis zu den insgesamt im Cluster verfügbaren Ressourcen). Weitere Informationen finden Sie unter Pod-Priorität und vorzeitiges Beenden.
- Konfigurieren Sie einen Wartungsausschluss: Ein Wartungsausschluss ist ein sich nicht wiederholender Zeitraum, in dem keine automatische Wartung stattfinden darf. Weitere Informationen finden Sie unter Wartungsausschlüsse.
- Pods mit verlängerter Laufzeit in Autopilot verwenden: Verwenden Sie Pods mit verlängerter Laufzeit für einen Kulanzzeitraum von bis zu sieben Tagen, bevor GKE Ihre Pods für Herunterskalierungen oder Knotenupgrades beendet. “
Störungen aufgrund von Knotenwartungen verarbeiten
Alle GKE-Knoten, einschließlich derjenigen, auf denen TPU-VMs gehostet werden, unterliegen Wartungsereignissen oder anderen Störungen, die zum Herunterfahren des Knotens führen können. Sie können Unterbrechungen von Arbeitslasten reduzieren, die in GKE-Clustern ausgeführt werden, auf denen auf der Steuerungsebene Version 1.29.1-gke.1425000 und höher ausgeführt wird.
GKE benachrichtigt die Knoten über ein bevorstehendes Herunterfahren. Dazu wird bis zu fünf Minuten vor der Bereinigung ein SIGTERM-Signal an den Knoten gesendet. Wenn Ihre Arbeitslast ein ML-Framework wie MaxText, Pax oder JAX mit Orbax verwendet, können die Arbeitslasten das SIGTERM-Signal erfassen und einen Prüfpunktprozess initiieren.
Sie können GKE so konfigurieren, dass Ihre ML-Arbeitslasten mit der maximalen Benachrichtigungszeit ordnungsgemäß beendet werden. Legen Sie im Pod-Manifest das spec.terminationGracePeriodSeconds-Feld auf 300 Sekunden (fünf Minuten) fest.
GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden und die von Ihnen definierte Beendigungsaktion auszuführen, z. B. das Speichern eines Trainingsstatus. GKE berücksichtigt jede Konfiguration von bis zu fünf Minuten für die Einstellungen PodDisruptionBudget oder terminationGracePeriodSeconds.
Das spec.terminationGracePeriodSeconds-Feld verarbeitet ausschließlich Unterbrechungen aufgrund von Wartungs- und Defragmentierungsereignissen, die bei VMs nicht auf Abruf auftreten. GKE verarbeitet keine unfreiwilligen Unterbrechungen, z. B. Hardwarefehler.
Weitere Informationen finden Sie unter Ordnungsgemäße Beendigung von TPU-Knoten konfigurieren.
TPU-Auslastung maximieren
Um Ihre Investition in TPUs zu maximieren, planen Sie eine Mischung von Jobprioritäten und stellen Sie sie in eine Warteschlange, um die Betriebszeit Ihrer TPUs zu maximieren. Wenn Sie Planung und vorzeitiges Beenden auf Jobebene wünschen, müssen Sie ein Add-on zu Kubernetes verwenden, das Jobs in Warteschlangen orchestriert. Für diesen Anwendungsfall empfehlen wir die Verwendung von Kueue.
Nächste Schritte
- Folgen Sie der Anleitung unter TPU-Arbeitslasten in GKE bereitstellen, um Cloud TPU mit GKE einzurichten.
- Best Practices für die Verwendung von Cloud TPU für Ihre Machine Learning-Aufgaben
- Umfangreiches maschinelles Lernen auf Cloud TPUs mit GKE erstellen
- Large Language Models mit KubeRay auf TPUs bereitstellen