TPUs in GKE planen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie die Nutzung von Tensor Processing Units (TPUs) in Google Kubernetes Engine (GKE) planen, um das Risiko von TPU-Fehlkonfigurationen, Fehlern aufgrund von Nichtverfügbarkeit oder Unterbrechungen aufgrund von Kontingentüberschreitungen zu verringern.

Bevor Sie TPUs in GKE verwenden, sollten Sie sich mit den TPU-Definitionen und der Terminologie in GKE vertraut machen.

TPU-Konfiguration planen

Wenn Sie TPUs in GKE-Clustern verwenden möchten, müssen Sie ihre Konfiguration planen. Wir empfehlen, so vorzugehen:

1. GKE-Betriebsmodus auswählen: Führen Sie Ihre Arbeitslasten auf TPUs in einem GKE Autopilot- oder Standard-Cluster aus.

   Best Practice:

   Verwenden Sie einen Autopilot-Cluster für eine vollständig verwaltete Kubernetes-Umgebung.

2. TPU-Version auswählen: Unterschiedliche TPU-Typen haben unterschiedliche Funktionen wie Preis-Leistungs-Verhältnis, Trainingsdurchsatz und Bereitstellungslatenz. Die TPU-Typen wirken sich auf die verfügbaren CPU- und Arbeitsspeicherkapazitäten aus.

3. TPU-Verfügbarkeit prüfen: TPUs sind in bestimmten Google CloudRegionen verfügbar. Wenn Sie einen TPU-Typ in Ihrer GKE-Arbeitslast verwenden möchten, muss sich Ihr Cluster in einer unterstützten Region für diesen Typ befinden.

4. TPU-Topologie auswählen: Die physische Anordnung der TPUs in einem TPU-Slice. Wählen Sie eine Topologie aus, die den Parallelitätsanforderungen Ihres Modells entspricht.

Anhand der Referenztabellen auf dieser Seite können Sie ermitteln, ob Ihre Knotenpools TPU-Slice-Knoten mit einem einzelnen Host oder mit mehreren Hosts sind.

GKE-Betriebsmodus auswählen

Sie können TPUs in den verfügbaren GKE-Betriebsmodi für Cluster verwenden:

• Standardmodus: Sie verwalten die zugrunde liegende Infrastruktur, einschließlich der Konfiguration der einzelnen Knoten.
• Autopilot-Modus (empfohlen): GKE verwaltet die zugrunde liegende Infrastruktur, z. B. Knotenkonfiguration, Autoscaling, automatische Upgrades, Referenzsicherheitskonfigurationen und Referenznetzwerkkonfiguration. In Autopilot wählen Sie einen TPU-Typ und eine Topologie aus und geben diese dann in Ihrem Kubernetes-Manifest an. GKE verwaltet die Bereitstellung von Knoten mit TPUs und die Planung Ihrer Arbeitslasten.

Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

Option für die TPU-Nutzung auswählen

Wenn Sie Ihre TPU-Konfiguration in GKE planen, wählen Sie eine Verbrauchsoption aus, die Ihren Arbeitslastanforderungen entspricht. Die von Ihnen gewählte Option für die Nutzung wirkt sich auf die verfügbaren TPU-Versionen und das Kontingent aus, das Sie konfigurieren müssen. GKE bietet die folgenden Optionen für den TPU-Verbrauch, mit denen Sie die Ressourcenzuweisung und die Kosten optimieren und gleichzeitig die Arbeitslastleistung aufrechterhalten können:

• Flex-Start:Flex-Start-VMs werden für bis zu sieben Tage bereitgestellt. GKE weist die Hardware automatisch auf Best-Effort-Basis entsprechend der Verfügbarkeit zu. Weitere Informationen finden Sie unter GPU-, TPU- und H4D-Nutzung mit dem Bereitstellungsmodus „Flex-Start“.
• Spot-VMs:Wenn Sie Spot-VMs bereitstellen, können Sie erhebliche Rabatte erhalten. Spot-VMs können jedoch jederzeit vorzeitig beendet werden. Sie erhalten 30 Sekunden vor dem Beenden eine Warnung. Weitere Informationen finden Sie unter Spot-VMs.
• Vorausschauende Reservierung für bis zu 90 Tage (im Kalendermodus): Damit können Sie TPU-Ressourcen für bis zu 90 Tage für einen bestimmten Zeitraum bereitstellen. Weitere Informationen finden Sie unter TPUs mit vorausschauender Reservierung im Kalendermodus anfordern.
• TPU-Reservierungen:Vorausschauende Reservierung für ein Jahr oder länger anfordern

Informationen zum Auswählen der Nutzungsoption, die Ihren Arbeitslastanforderungen entspricht, finden Sie unter Beschleuniger-Nutzungsoptionen für KI-/ML-Arbeitslasten in GKE.

TPU-Version auswählen

Die VMs in einem TPU-Slice haben die folgenden technischen Eigenschaften.

Ironwood (TPU7x) TPU Trillium TPU v5p TPU v5e TPU v4 TPU v3 Alle löschen

Standard

TPU-Version	Maschinentyp	Anzahl der vCPUs	Anzahl der Chips pro VM	Speicher (GiB)	Anzahl der NUMA-Knoten	Wahrscheinlichkeit eines vorzeitigen Beendens
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	224	4	960	2	Nicht zutreffend
TPU Trillium (v6e)	ct6e-standard-1t	44	1	448	2	Höher
TPU Trillium (v6e)	ct6e-standard-4t	180	4	720	1	Mittel
TPU Trillium (v6e)	ct6e-standard-8t	180	8	1440	2	Niedrigere
TPU v5p	ct5p-hightpu-4t	208	4	448	2	Nicht zutreffend
TPU v5e	ct5lp-hightpu-1t	24	1	48	1	Höher
TPU v5e	ct5lp-hightpu-4t	112	4	192	1	Mittel
TPU v5e	ct5lp-hightpu-8t	224	8	384	1	Niedrig
TPU v4	ct4p-hightpu-4t	240	4	407	2	Nicht zutreffend
TPU v3 (nur Einzelhost)	ct3-hightpu-4t	96	4	340	2	Nicht zutreffend
TPU v3	ct3p-hightpu-4t	48	4	340	1	Nicht zutreffend

ct5lp--Maschinentypen mit mehreren Hosts eignen sich besser für die Bereitstellung großer Modelle oder für das Training. ct5lp--Maschinen mit mehreren Hosts sind über Hochgeschwindigkeitsverbindungen miteinander verbunden.

Autopilot

TPU-Version	Maschinentyp	Anzahl der vCPUs	Speicher (GiB)	Anzahl der NUMA-Knoten	Maximale Anzahl von TPU-Chips in einem TPU-Slice-Knoten
Ironwood (TPU7x) (Vorschau)	tpu7x	224	960	2	2.048
TPU Trillium (v6e)	tpu-v6e-slice	44 bis 180	176 bis 1440	1 bis 2	256
TPU v5p	tpu-v5p-slice	208	448	2	6.144
TPU v5e	tpu-v5-lite-podslice	24 bis 224	48 bis 384	1	256
TPU v4	tpu-v4-podslice	240	407	2	4.096
TPU v3 (nur Single-Host)	tpu-v3-device	96	340	2	8
TPU v3	tpu-v3-slice	48	340	1	256

Sehen Sie sich die TPU-Spezifikationen und -Preise in der Cloud TPU-Preisdokumentation an, um zu entscheiden, welche TPU-Konfiguration Sie verwenden möchten.

Beschränkungen

Berücksichtigen Sie diese Einschränkungen bei der Auswahl der zu verwendenden TPU:

• Ironwood (TPU7x) (Vorabversion) ist als Vorabversion verfügbar und hat die folgenden Einschränkungen:

  • Standardcluster in Version 1.34.0-gke.2201000 und höher im RAPID-Channel.
  • Autopilot-Cluster in Version 1.34.1-gke.3084001 und höher im RAPID-Channel.
  • Nur Google Cloud Hyperdisk Balanced wird unterstützt.
  • Multislice wird für Flex-Start nicht unterstützt.
  • Mehrere Netzwerke für Managed Lustre werden nicht unterstützt.
  • Sekundäre Bootlaufwerke werden nicht unterstützt.
  Wichtig :Wenn Sie Ironwood (TPU7x) (Vorschau) verwenden möchten, müssen Sie den Cluster im Rapid Release Channel erstellen. Nachdem der Cluster erstellt wurde, können Sie zu „Kein Channel“ wechseln oder Wartungsausschlüsse verwenden, um Upgrades zu verwalten.

• TPU Trillium ist in den folgenden Versionen verfügbar:

  • Standardcluster in Version 1.31.1-gke.1846000 und höher.
  • Autopilot-Cluster in Version 1.31.2-gke.1115000 und höher.

• TPU Trillium unterstützt nicht die Konfiguration von SMT auf 2 auf ct6e-standard-8t.

• TPU v5p-Autoscaling wird in GKE-Clustern mit Steuerungsebenen unterstützt, auf denen mindestens Version 1.29.2-gke.1035000 oder 1.28.7-gke.1020000 ausgeführt wird.

• Verwenden Sie für Kapazitätsreservierungen eine spezifische Reservierung.

• Sie können maximal 256 Pods auf einer einzelnen TPU-VM ausführen.

• Die GKE-Kostenzuordnung und -Nutzungsmessung enthalten keine Daten zur Nutzung oder zu den Kosten von TPUs.

• Cluster Autoscaler bricht das Hochskalieren von TPU-Knotenpools ab, die länger als 10 Stunden im Wartestatus verbleiben. Cluster Autoscaler wiederholt solche Hochskalierungsversuche, wenn Ressourcen verfügbar sind. Dieses Verhalten kann die TPU-Erreichbarkeit reduzieren, wenn Sie keine Reservierungen verwenden.

• Ubuntu-Knoten werden nicht unterstützt.

• Die TPU-Knotenarchitektur wird nicht mehr unterstützt. TPU v3 ist die einzige TPU-Version, die die TPU-Knotenarchitektur in GKE noch unterstützt.

TPU-Verfügbarkeit in GKE prüfen

TPUs sind in bestimmten Google Cloud Regionen verfügbar. Wenn Sie einen TPU-Typ in Ihrem GKE-Cluster verwenden möchten, muss sich Ihr Cluster in einer für diesen Typ unterstützten Region befinden.

Ironwood (TPU7x) TPU Trillium TPU v5p TPU v5e TPU v4 TPU v3 asia-northeast1-b europe-west4-a europe-west4-b us-central1-a us-central1-b us-central2-b us-east1-d us-east5-a us-east5-b us-east5-c us-south1-a us-west1-c us-west4-a southamerica-west1-a Alle löschen

Standard

TPU-Version	Maschinentyp beginnt mit	Mindestversion für GKE	Verfügbarkeit	Zone
TPU Ironwood (TPU7x)	tpu7x-standard-4t	1.34.0-gke.2201000	Öffentliche Vorschau	us-central1-c
TPU Trillium (v6e)	ct6e-	1.31.2-gke.1115000	GA	asia-northeast1-b europe-west4-a southamerica-west1-a us-central1-b us-east1-d us-east5-a us-east5-b
TPU v5e	ct5lp-	1.27.2-gke.2100	GA	europe-west4-b us-central1-a us-south1-a us-west1-c us-west4-a
TPU v5p	ct5p-	1.28.3-gke.1024000	GA	europe-west4-b us-central1-a us-east5-a
TPU v4	ct4p-	1.26.1-gke.1500	GA	us-central2-b
TPU v3	ct3p-	1.31.1-gke.1146000	GA	europe-west4-a us-central1-a us-central1-b
TPU v3	ct3-	1.31.0-gke.1500	GA	europe-west4-a us-central1-a us-central1-b

Autopilot

TPU-Version	cloud.google.com/gke-tpu-accelerator	Mindestversion für GKE	Verfügbarkeit	Zone
TPU Ironwood (TPU7x)	tpu7x	1.34.1-gke.3084001	Öffentliche Vorschau	us-central1-c
TPU Trillium (v6e)	tpu-v6e-slice	1.31.2-gke.1384000	GA	asia-northeast1-b europe-west4-a southamerica-west1-a us-central1-b us-east1-d us-east5-a us-east5-b
TPU v5e	tpu-v5-lite-podslice	1.27.2-gke.2100	GA	europe-west4-b us-central1-a us-south1-a us-west1-c us-west4-a
TPU v5p	tpu-v5p-slice	1.28.3-gke.1024000	GA	europe-west4-b us-central1-a us-east5-a
TPU v4	tpu-v4-podslice	1.26.1-gke.1500	GA	us-central2-b
TPU v3	tpu-v3-slice	1.31.1-gke.1146000	GA	europe-west4-a us-central1-a us-central1-b
TPU v3	tpu-v3-device	1.31.0-gke.1500	GA	europe-west4-a us-central1-a us-central1-b

Topologie auswählen

Nachdem Sie sich für eine TPU-Version entschieden haben, wählen Sie eine Topologie aus, die von diesem TPU-Typ unterstützt wird. Je nach TPU-Typ ist die Topologie zwei- oder dreidimensional. Die Parallelitätsanforderungen Ihres Modells helfen Ihnen bei der Entscheidung für eine Topologie. Sie können die Anzahl der TPU-Chips im Slice ermitteln, indem Sie das Produkt jeder Größe in der Topologie berechnen. Beispiel:

• 2x2x2 ist ein TPU v4-Slice mit 8 Chips und mehreren Hosts
• 2x2 ist ein TPU v5e-Slice mit 4 Chips mit einem Host.

Wenn eine bestimmte Topologie sowohl TPU-Slice-Knoten 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. Es stehen folgende Optionen zur Verfügung:

• Wenn Sie in Ihrer Arbeitslast 4 Chips anfordern, erhalten Sie einen Knoten mit mehreren Hosts und 4 TPU-Chips.
• Wenn Sie in Ihrer Arbeitslast 8 Chips anfordern, erhalten Sie einen Knoten mit einem einzelnen Host und 8 TPU-Chips.

Wir empfehlen TPUs für Inferenz- und Trainingsarbeitslasten. Verwenden Sie die folgende Tabelle, um den TPU-Maschinentyp und die Topologie für Ihren Anwendungsfall auszuwählen:

• Verwenden Sie für umfangreiches Training oder Inferenz Pathways. Pathways vereinfacht umfangreiche ML-Berechnungen, da ein einzelner JAX-Client Arbeitslasten auf mehreren großen TPU-Slices orchestrieren kann. Weitere Informationen finden Sie unter Pathways.

Die Definitionen der Begriffe in der folgenden Tabelle finden Sie unter TPUs in GKE.

Ironwood (TPU7x) TPU Trillium TPU v5p TPU v5e TPU v4 TPU v3 Einzelner Host Mehrere Hosts Alle löschen

Standard

Nachdem Sie einen TPU-Typ und eine Topologie ausgewählt haben, geben Sie diese in Ihrem Arbeitslastmanifest an. Eine Anleitung finden Sie unter TPU-Arbeitslasten in GKE Standard bereitstellen.

TPU-Version	Maschinentyp	Knotenpooltyp	Technische Spezifikationen
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der Hosts: 1 Anzahl der VMs: 1 Anzahl der Cubes: 1/16
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der Hosts: 2 Anzahl der VMs: 2 Anzahl der Cubes: 1/8
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 2x2x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der Hosts: 4 Anzahl der VMs: 4 Anzahl der Cubes: 1/4
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der Hosts: 8 Anzahl der VMs: 8 Anzahl der Cubes: 1/2
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 4x4x4 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der Hosts: 16 Anzahl der VMs: 16 Anzahl der Cubes: 1
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 4x4x8 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der Hosts: 32 Anzahl der VMs: 32 Anzahl der Cubes: 2
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 4x8x8 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der Hosts: 64 Anzahl der VMs: 64 Anzahl der Würfel: 4
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 8x8x8 Anzahl der TPU-Chips für die Topologie: 512 Anzahl der Hosts: 128 Anzahl der VMs: 128 Anzahl der Würfel: 8
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: 8 x 8 x 16 Anzahl der TPU-Chips für die Topologie: 1024 Anzahl der Hosts: 256 Anzahl der VMs: 256 Anzahl der Cubes: 16
Ironwood (TPU7x) (Vorschau)	tpu7x-standard-4t	Mehrere Hosts	Topologie: {A}x{B}x{C} (wobei A, B und C Vielfache von 2 sind) Anzahl der TPU-Chips für die Topologie: A*B*C Anzahl der Hosts: (A*B*C)/4 Anzahl der VMs: (A*B*C/4) Anzahl der Cubes: (A*B*C/64)
TPU Trillium (v6e)	ct6e-standard-1t	Einzelner Host	Topologie: 1x1 Anzahl der TPU-Chips für die Topologie: 1 Anzahl der VMs: 1
TPU Trillium (v6e)	ct6e-standard-8t	Einzelner Host	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 1
TPU Trillium (v6e)	ct6e-standard-4t	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 32
TPU Trillium (v6e)	ct6e-standard-4t	Mehrere Hosts	Topologie: 16 × 16 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der VMs: 64
TPU v5p	ct5p-hightpu-4t	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v5p	ct5p-hightpu-4t	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v5p	ct5p-hightpu-4t	Mehrere Hosts	Topologie: 2x2x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v5p	ct5p-hightpu-4t	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v5p	ct5p-hightpu-4t	Mehrere Hosts	Topologie: {A}x{B}x{C} (wobei A, B und C Vielfache von 2 sind) Anzahl der TPU-Chips für die Topologie: A*B*C Anzahl der VMs: (A*B*C/4)^1
TPU v5e	ct5lp-hightpu-1t	Einzelner Host	Topologie: 1x1 Anzahl der TPU-Chips für die Topologie: 1 Anzahl der VMs: 1
TPU v5e	ct5lp-hightpu-4t	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v5e	ct5lp-hightpu-8t	Einzelner Host	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 1
TPU v5e	ct5lp-hightpu-4t	Mehrere Hosts	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v5e	ct5lp-hightpu-4t	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v5e	ct5lp-hightpu-4t	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v5e	ct5lp-hightpu-4t	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU v5e	ct5lp-hightpu-4t	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 32
TPU v5e	ct5p-hightpu-4t	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v5e	ct5p-hightpu-4t	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v4	ct4p-hightpu-4t	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v4	ct4p-hightpu-4t	Mehrere Hosts	Topologie: 2x2x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v4	ct4p-hightpu-4t	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v4	ct4p-hightpu-4t	Mehrere Hosts	Topologie: {A}x{B}x{C} (wobei A, B und C Vielfache von 2 sind) Anzahl der TPU-Chips für die Topologie: A*B*C Anzahl der VMs: (A*B*C/4)^1
TPU v3	ct3-hightpu-4t	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 32
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 16 × 16 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der VMs: 64
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 16x32 Anzahl der TPU-Chips für die Topologie: 512 Anzahl der VMs: 128
TPU v3	ct3p-hightpu-4t	Mehrere Hosts	Topologie: 32x32 Anzahl der TPU-Chips für die Topologie: 1024 Anzahl der VMs: 256

1. Berechnet sich aus dem Topologieprodukt geteilt durch vier. ↩

Autopilot

Nachdem Sie einen TPU-Typ und eine Topologie ausgewählt haben, geben Sie diese in Ihrem Arbeitslastmanifest an. Eine Anleitung finden Sie unter TPU-Arbeitslasten in GKE Autopilot bereitstellen.

TPU-Version	Maschinentyp	Knotenpooltyp	Technische Spezifikationen
Ironwood (TPU7x) (Vorschau)	tpu7x	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der Hosts: 1 Anzahl der VMs: 1 Anzahl der Cubes: 1/16
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der Hosts: 2 Anzahl der VMs: 2 Anzahl der Cubes: 1/8
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der Hosts: 8 Anzahl der VMs: 8 Anzahl der Cubes: 1/2
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 4x4x4 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der Hosts: 16 Anzahl der VMs: 16 Anzahl der Cubes: 1
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 8x8x8 Anzahl der TPU-Chips für die Topologie: 512 Anzahl der Hosts: 128 Anzahl der VMs: 128 Anzahl der Würfel: 8
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 8 x 8 x 16 Anzahl der TPU-Chips für die Topologie: 1024 Anzahl der Hosts: 256 Anzahl der VMs: 256 Anzahl der Cubes: 16
Ironwood (TPU7x) (Vorschau)	tpu7x	Mehrere Hosts	Topologie: 8 x 16 x 16 Anzahl der TPU-Chips für die Topologie: 2.048 Anzahl der Hosts: 512 Anzahl der VMs: 512 Anzahl der Cubes: 32
TPU Trillium (v6e)	tpu-v6e-slice	Einzelner Host	Topologie: 1x1 Anzahl der TPU-Chips für die Topologie: 1 Anzahl der VMs: 1
TPU Trillium (v6e)	tpu-v6e-slice	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 4
TPU Trillium (v6e)	tpu-v6e-slice	Einzelner Host	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 8
TPU Trillium (v6e)	tpu-v6e-slice	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU Trillium (v6e)	tpu-v6e-slice	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU Trillium (v6e)	tpu-v6e-slice	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU Trillium (v6e)	tpu-v6e-slice	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 32
TPU Trillium (v6e)	tpu-v6e-slice	Mehrere Hosts	Topologie: 16 × 16 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der VMs: 64
TPU v5p	tpu-v5p-slice	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v5p	tpu-v5p-slice	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v5p	tpu-v5p-slice	Mehrere Hosts	Topologie: 2x2x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v5p	tpu-v5p-slice	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v5p	tpu-v5p-slice	Mehrere Hosts	Topologie: 4x4x4 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU v5p	tpu-v5p-slice	Mehrere Hosts	Topologie: {A}x{B}x{C} Anzahl der TPU-Chips für die Topologie: {A}*{B}*{C} Anzahl der VMs: (A*B*C/4)^1
TPU v5e	tpu-v5-lite-podslice	Einzelner Host	Topologie: 1x1 Anzahl der TPU-Chips für die Topologie: 1 Anzahl der VMs: 1
TPU v5e	tpu-v5-lite-podslice	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v5e	tpu-v5-lite-podslice	Einzelner Host	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 1
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 32
TPU v5e	tpu-v5-lite-podslice	Mehrere Hosts	Topologie: 16 × 16 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der VMs: 64
TPU v5e (nur mit einem Host)	tpu-v5-lite-device	Einzelner Host	Topologie: 1x1 Anzahl der TPU-Chips für die Topologie: 1 Anzahl der VMs: 1
TPU v5e (nur mit einem Host)	tpu-v5-lite-device	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v5e (nur mit einem Host)	tpu-v5-lite-device	Einzelner Host	Topologie: 2x4 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 1
TPU v4	tpu-v4-podslice	Einzelner Host	Topologie: 2x2x1 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1
TPU v4	tpu-v4-podslice	Mehrere Hosts	Topologie: 2x2x2 Anzahl der TPU-Chips für die Topologie: 8 Anzahl der VMs: 2
TPU v4	tpu-v4-podslice	Mehrere Hosts	Topologie: 2x2x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 4
TPU v4	tpu-v4-podslice	Mehrere Hosts	Topologie: 2x4x4 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 8
TPU v4	tpu-v4-podslice	Mehrere Hosts	Topologie: 4x4x4 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 16
TPU v4	tpu-v4-podslice	Mehrere Hosts	Topologie: {A}x{B}x{C} Anzahl der TPU-Chips für die Topologie: {A}*{B}*{C} Anzahl der VMs: (A*B*C/4)^1
TPU v3	tpu-v3-slice	Mehrere Hosts	Topologie: 4x4 Anzahl der TPU-Chips für die Topologie: 16 Anzahl der VMs: 2
TPU v3	tpu-v3-slice	Mehrere Hosts	Topologie: 4x8 Anzahl der TPU-Chips für die Topologie: 32 Anzahl der VMs: 4
TPU v3	tpu-v3-slice	Mehrere Hosts	Topologie: 8x8 Anzahl der TPU-Chips für die Topologie: 64 Anzahl der VMs: 8
TPU v3	tpu-v3-slice	Mehrere Hosts	Topologie: 8x16 Anzahl der TPU-Chips für die Topologie: 128 Anzahl der VMs: 16
TPU v3	tpu-v3-slice	Mehrere Hosts	Topologie: 16 × 16 Anzahl der TPU-Chips für die Topologie: 256 Anzahl der VMs: 32
TPU v3	tpu-v3-device	Einzelner Host	Topologie: 2x2 Anzahl der TPU-Chips für die Topologie: 4 Anzahl der VMs: 1

1. Berechnet sich aus dem Topologieprodukt geteilt durch vier. ↩

   Benutzerdefinierte Topologien für mehr als 64 Chips werden unterstützt. Dabei gelten folgende Bedingungen:

   • Bei mehr als 64 Chips müssen {A}, {B} und {C} ein Vielfaches von 4 sein
   • Die größte Topologie ist 16x16x24
   • Die Werte müssen {A}≤{B}≤{C} sein, z. B. 8x12x16.

2. Benutzerdefinierte Topologien werden nicht unterstützt.

Erweiterte Konfigurationen

In den folgenden Abschnitten werden Best Practices für die Planung für erweiterte TPU-Konfigurationen beschrieben.

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-4t und der Topologie 16x16 enthä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.

Zusätzlichen Speicher für einen TPU-Slice bereitstellen

Eine VM in einem TPU-Slice enthält ein 100 GiB großes Bootlaufwerk. Wenn für Ihren TPU-Slice zusätzlicher Speicherplatz für das Training oder die Vorverarbeitung erforderlich ist oder Sie Prüfpunkte speichern müssen, können Sie Google Cloud Hyperdisk- oder Balanced Persistent Disk-Speicher verwenden, sofern er für Ihre TPU verfügbar ist. Weitere Informationen zu den unterstützten Laufwerkstypen für die einzelnen TPU-Versionen finden Sie unter TPU-Unterstützung für Hyperdisk und Persistent Disk.

CPU für Standardcluster

Dieser Abschnitt gilt nicht für Autopilot-Cluster, da GKE jedes TPU-Slice auf einem eigenen Knoten platziert. Weitere Informationen finden Sie unter Funktionsweise von TPUs im Autopilot-Modus.

Für Standardcluster gelten die folgenden Best Practices für die Planung.

Sorgen Sie dafür, dass Ihr GKE-Pod die google.com/tpu-Markierung tolerieren kann, um eine Nicht-TPU-Arbeitslast auf einer VM in einem TPU-Slice-Knoten zu planen. Wenn Sie die Arbeitslast für bestimmte Knoten bereitstellen möchten, verwenden Sie die Knotenauswahl.

Die Kubernetes-Ressourcenverwaltung und -Priorität behandelt VMs in TPUs so wie andere VM-Typen. Damit Pods, die TPU erfordern, planungs-Vorrang vor anderen Pods auf denselben Knoten haben, fordern Sie die maximale CPU- oder Arbeitsspeichermenge für diese TPU-Slices an. TPU-Slices mit niedriger Priorität sollten folgende Voraussetzungen erfüllen:

1. 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.
2. Legen Sie kein CPU-Limit (unbegrenzt) fest, damit die Pods Bursts verwenden können, um alle nicht verwendeten Zyklen zu nutzen.
3. Legen Sie geeignete Arbeitsspeicherlimits fest, damit Pods ordnungsgemäß funktionieren, ohne dass ein Risiko von Beendigung des Knotendrucks besteht.

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. Für eine spezifische Kubernetes-Planung konfigurieren Sie die Pod-Anforderungen mit einer expliziten CPU- und Arbeits-Speicher-anforderung. Weitere Informationen finden Sie unter Ressourcenverwaltung für Pods und Container.

Weitere Informationen zu Best Practices finden Sie unter Best Practices für Kubernetes: Ressourcenanforderungen und -limits.

Unterbrechungen von Arbeitslasten 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. “
• Sammlungsplanung in TPU Trillium verwenden: Verwenden Sie Sammlungen, um anzugeben, dass ein TPU-Slice-Knotenpool Teil einer Serving-Arbeitslast ist. Google Cloud Dadurch werden Unterbrechungen der Vorgänge von Inferenz-Arbeitslasten begrenzt und optimiert. Weitere Informationen zur Planung von Sammlungen

Diese Empfehlungen helfen dabei, Unterbrechungen zu minimieren, verhindern sie aber nicht. Beispielsweise ist das vorzeitige Beenden aufgrund eines Hardwarefehlers oder für die Defragmentierung möglich. Ebenso wird durch das Festlegen eines GKE-Wartungsausschlusses keine Compute Engine-Wartungsereignisse verhindert.

Best Practice:

Speichern Sie Prüfpunkte häufig und fügen Sie Ihrem Trainings-Script Code hinzu, damit bei der Fortsetzung beim letzten Prüfpunkt begonnen wird.

Störungen aufgrund von Knotenwartungen verarbeiten

Die GKE-Knoten, auf denen die TPUs gehostet werden, unterliegen Wartungsereignissen oder anderen Störungen, die zum Herunterfahren des Knotens führen können. In GKE-Clustern auf deren Steuerungsebene, die Version 1.29.1-gke.1425000 oder höher ausgeführt wird, können Sie die Unterbrechung von Arbeitslasten reduzieren. Konfigurieren Sie dazu GKE so, dass Ihre Arbeitslasten ordnungsgemäß beendet werden.

Informationen zum Verstehen, Konfigurieren und Überwachen von Störungsereignissen, die auf GKE-Knoten mit KI-/ML-Arbeitslasten auftreten können, finden Sie unter GKE-Knotenunterbrechungen für GPUs und TPUs verwalten.

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. Für die Planung und vorzeitiges Beenden auf Jobebene müssen Sie ein Add-on zu Kubernetes verwenden, das Jobs in Warteschlangen orchestriert.

Best Practice:

Verwenden Sie Kueue, um Jobs in Warteschlangen zu orchestrieren.

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