TPUs in GKE planen


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 Überschreitungen des Kontingents zu reduzieren.

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 die Konfiguration planen. Wir empfehlen, so vorzugehen:

  1. GKE-Betriebsmodus auswählen: Führen Sie Ihre Arbeitslasten auf TPUs in einem GKE Autopilot- oder Standardcluster 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 Trusted Cloud by S3NSRegionen 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 oder mehreren Hosts sind.

GKE-Betriebsmodus auswählen

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

  • 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.
  • Standardmodus: Sie verwalten die zugrunde liegende Infrastruktur, einschließlich der Konfiguration der einzelnen Knoten.

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

TPU-Version auswählen

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

Autopilot

TPU-Version Maschinentyp Anzahl der vCPUs Speicher (GiB) Anzahl der NUMA-Knoten Maximale Anzahl von TPU-Chips in einem TPU-Slice-Knoten
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 mit einem Host)
tpu-v3-device 96 340 2 8
TPU v3
tpu-v3-slice 48 340 1 256

Standard

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

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.

In der Cloud TPU-Preisdokumentation finden Sie die TPU-Spezifikationen und -Preise, anhand derer Sie entscheiden können, welche TPU-Konfiguration Sie verwenden möchten.

Beschränkungen

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

  • 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, das auf 2 auf ct6e-standard-8t festgelegt ist.
  • Die GKE-Kostenzuordnung und -Nutzungsmessung enthält keine Daten zur Nutzung oder zu den Kosten der reservierten TPU v4.
  • Das Autoscaling von TPU v5p 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 ist eingestellt. 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 Trusted 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.

Autopilot

TPU-Version cloud.google.com/gke-tpu-accelerator Mindestversion für GKE Verfügbarkeit Zone
TPU Trillium (v6e) tpu-v6e-slice 1.31.2-gke.1384000 GA
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
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
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 tpu-v3-device 1.31.0-gke.1500 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a

Standard

TPU-Version Maschinentyp beginnt mit Mindestversion für GKE Verfügbarkeit Zone
TPU Trillium (v6e) ct6e- 1.31.2-gke.1115000 GA
  • asia-northeast1-b
  • europe-west4-a
  • us-central1-b
  • us-east1-d
  • us-east5-a
  • us-east5-b
  • southamerica-west1-a
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
  • us-central1-a
  • us-central1-b
  • europe-west4-a
TPU v3 ct3- 1.31.0-gke.1500 GA
  • us-central1-a
  • us-central1-b
  • europe-west4-a

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.

Verwenden Sie die folgende Tabelle, um den TPU-Maschinentyp und die Topologie für Ihren Anwendungsfall auszuwählen:

  • 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.
  • Verwenden Sie für umfangreiches Training oder Inferenz Pathways. Pathways vereinfacht umfangreiche ML-Berechnungen, da ein einzelner JAX-Client Arbeitslasten über mehrere große TPU-Slices hinweg orchestrieren kann. Weitere Informationen finden Sie unter Pathways.

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
TPU Trillium (v6e) tpu-v6e-slice Einzelner Host
  • Topologie: 1x1
  • Anzahl der TPU-Chips: 1
  • Anzahl der VMs: 1
TPU Trillium (v6e) tpu-v6e-slice Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 4
TPU Trillium (v6e) tpu-v6e-slice Einzelner Host
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 8
TPU Trillium (v6e) tpu-v6e-slice Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU Trillium (v6e) tpu-v6e-slice Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU Trillium (v6e) tpu-v6e-slice Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU Trillium (v6e) tpu-v6e-slice Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 32
TPU Trillium (v6e) tpu-v6e-slice Mehrere Hosts
  • Topologie: 16x16
  • Anzahl der TPU-Chips: 256
  • Anzahl der VMs: 64
TPU v5p tpu-v5p-slice Einzelner Host
  • Topologie: 2x2x1
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v5p tpu-v5p-slice Mehrere Hosts
  • Topologie: 2x2x2
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v5p tpu-v5p-slice Mehrere Hosts
  • Topologie: 2x2x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v5p tpu-v5p-slice Mehrere Hosts
  • Topologie: 2x4x4
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v5p tpu-v5p-slice Mehrere Hosts
  • Topologie: 4x4x4
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU v5p tpu-v5p-slice Mehrere Hosts
  • Topologie: {A}x{B}x{C}
  • Anzahl der TPU-Chips: {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: 1
  • Anzahl der VMs: 1
TPU v5e tpu-v5-lite-podslice Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v5e tpu-v5-lite-podslice Einzelner Host
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 1
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 32
TPU v5e tpu-v5-lite-podslice Mehrere Hosts
  • Topologie: 16x16
  • Anzahl der TPU-Chips: 256
  • Anzahl der VMs: 64
TPU v5e (nur einzelner Host) tpu-v5-lite-device Einzelner Host
  • Topologie: 1x1
  • Anzahl der TPU-Chips: 1
  • Anzahl der VMs: 1
TPU v5e (nur einzelner Host) tpu-v5-lite-device Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v5e (nur einzelner Host) tpu-v5-lite-device Einzelner Host
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 1
TPU v4 tpu-v4-podslice Einzelner Host
  • Topologie: 2x2x1
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v4 tpu-v4-podslice Mehrere Hosts
  • Topologie: 2x2x2
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v4 tpu-v4-podslice Mehrere Hosts
  • Topologie: 2x2x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v4 tpu-v4-podslice Mehrere Hosts
  • Topologie: 2x4x4
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v4 tpu-v4-podslice Mehrere Hosts
  • Topologie: 4x4x4
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU v4 tpu-v4-podslice Mehrere Hosts
  • Topologie: {A}x{B}x{C}
  • Anzahl der TPU-Chips: {A}*{B}*{C}
  • Anzahl der VMs: (A*B*C/4)1
TPU v3 tpu-v3-slice Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 2
TPU v3 tpu-v3-slice Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 4
TPU v3 tpu-v3-slice Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 8
TPU v3 tpu-v3-slice Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 16
TPU v3 tpu-v3-slice Mehrere Hosts
  • Topologie: 16x16
  • Anzahl der TPU-Chips: 256
  • Anzahl der VMs: 32
TPU v3 tpu-v3-device Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 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.

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
TPU Trillium (v6e) ct6e-standard-1t Einzelner Host
  • Topologie: 1x1
  • Anzahl der TPU-Chips: 1
  • Anzahl der VMs: 1
TPU Trillium (v6e) ct6e-standard-8t Einzelner Host
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 1
TPU Trillium (v6e) ct6e-standard-4t Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 32
TPU Trillium (v6e) ct6e-standard-4t Mehrere Hosts
  • Topologie: 16x16
  • Anzahl der TPU-Chips: 256
  • Anzahl der VMs: 64
TPU v5p ct5p-hightpu-4t Einzelner Host
  • Topologie: 2x2x1
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v5p ct5p-hightpu-4t Mehrere Hosts
  • Topologie: 2x2x2
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v5p ct5p-hightpu-4t Mehrere Hosts
  • Topologie: 2x2x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v5p ct5p-hightpu-4t Mehrere Hosts
  • Topologie: 2x4x4
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v5p ct5p-hightpu-4t Mehrere Hosts
  • Topologie: {A}x{B}x{C}
  • Anzahl der TPU-Chips: A*B*C
  • Anzahl der VMs: (A*B*C/4)1
TPU v5e ct5lp-hightpu-1t Einzelner Host
  • Topologie: 1x1
  • Anzahl der TPU-Chips: 1
  • Anzahl der VMs: 1
TPU v5e ct5lp-hightpu-4t Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v5e ct5lp-hightpu-8t Einzelner Host
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 1
TPU v5e ct5lp-hightpu-4t Mehrere Hosts
  • Topologie: 2x4
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v5e ct5lp-hightpu-4t Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v5e ct5lp-hightpu-4t Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v5e ct5lp-hightpu-4t Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU v5e ct5lp-hightpu-4t Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 32
TPU v5e ct5p-hightpu-4t Mehrere Hosts
  • Topologie: 2x4x4
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v5e ct5p-hightpu-4t Einzelner Host
  • Topologie: 2x2x1
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v4 ct4p-hightpu-4t Mehrere Hosts
  • Topologie: 2x2x2
  • Anzahl der TPU-Chips: 8
  • Anzahl der VMs: 2
TPU v4 ct4p-hightpu-4t Mehrere Hosts
  • Topologie: 2x2x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v4 ct4p-hightpu-4t Mehrere Hosts
  • Topologie: 2x4x4
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v4 ct4p-hightpu-4t Mehrere Hosts
  • Topologie: {A}x{B}x{C}
  • Anzahl der TPU-Chips: A*B*C
  • Anzahl der VMs: (A*B*C/4)1
TPU v3 ct3-hightpu-4t Einzelner Host
  • Topologie: 2x2
  • Anzahl der TPU-Chips: 4
  • Anzahl der VMs: 1
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 4x4
  • Anzahl der TPU-Chips: 16
  • Anzahl der VMs: 4
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 4x8
  • Anzahl der TPU-Chips: 32
  • Anzahl der VMs: 8
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 8x8
  • Anzahl der TPU-Chips: 64
  • Anzahl der VMs: 16
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 8x16
  • Anzahl der TPU-Chips: 128
  • Anzahl der VMs: 32
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 16x16
  • Anzahl der TPU-Chips: 256
  • Anzahl der VMs: 64
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 16x32
  • Anzahl der TPU-Chips: 512
  • Anzahl der VMs: 128
TPU v3 ct3p-hightpu-4t Mehrere Hosts
  • Topologie: 32x32
  • Anzahl der TPU-Chips: 1024
  • Anzahl der VMs: 256
  1. Berechnet sich aus dem Topologieprodukt geteilt durch vier.

Erweiterte Konfigurationen

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

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-Slice-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-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-Bootlaufwerk. Wenn für Ihren TPU-Slice zusätzlicher Speicherplatz für das Training oder die Vorverarbeitung erforderlich ist oder wenn 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. Trusted Cloud begrenzt und optimiert Unterbrechungen der Vorgänge von Inferenzarbeitslasten. 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