TPUs in GKE

In diesem Dokument wird beschrieben, wie Cloud TPU mit Google Kubernetes Engine (GKE) funktioniert. Dazu gehören Terminologie, die Vorteile von Tensor Processing Units (TPUs) und Überlegungen zur Arbeitslastplanung. 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.

Dieses Dokument richtet sich an Plattformadministratoren und ‑operatoren sowie an Daten- und KI-Experten, die ML-Modelle (Machine Learning) ausführen, die Merkmale wie umfangreich, lange Laufzeit oder dominiert von Matrixberechnungen aufweisen. Weitere Informationen zu häufigen Rollen und Beispielaufgaben, auf die wir im Inhalt verweisen, finden Sie unter Häufige GKE-Nutzerrollen und ‑aufgaben. Google Cloud

Bevor Sie dieses Dokument lesen, sollten Sie mit der Funktionsweise von ML-Beschleunigern vertraut sein. Weitere Informationen finden Sie unter Einführung in Cloud TPU.

Vorteile von TPUs in GKE

GKE bietet vollständige Unterstützung für die Verwaltung des Lebenszyklus von TPU-Knoten und ‑Knotenpools, einschließlich des Erstellens, Konfigurierens und Löschens von TPU-VMs. GKE unterstützt auch Spot-VMs sowie die Verwendung von reservierten Cloud TPU. Weitere Informationen finden Sie unter Cloud TPU-Nutzungsoptionen.

TPUs in GKE bieten folgende Vorteile:

  • Einheitliche Betriebsumgebung:Sie können eine einzige Plattform für alle ML- und sonstigen Arbeitslasten verwenden.
  • 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.
  • Sandboxing-Optionen:GKE Sandbox schützt Ihre Arbeitslasten mit gVisor. Weitere Informationen finden Sie unter GKE Sandbox.

Erste Schritte mit Ironwood (TPU7x)

Ironwood (TPU7x) ist die TPU der siebten Generation von Google, die für umfangreiche KI-Arbeitslasten entwickelt wurde. Weitere Informationen zu den Vorteilen von Ironwood (TPU7x) finden Sie unter Informationen zu Ironwood (TPU7x) in GKE.

Terminologie in Bezug auf TPUs in GKE

In diesem Dokument wird die folgende Terminologie in Bezug auf TPUs verwendet:

  • Cloud TPU ICI-Ausfallsicherheit:Eine Funktion, die zur Verbesserung der Fehlertoleranz von optischen Verbindungen und optischen Schaltern (Optical Circuit Switches, OCS) beiträgt, die TPUs zwischen Cubes verbinden. Weitere Informationen finden Sie unter TPU-Architektur.
  • TPU-Cube:Eine 4x4x4-Topologie miteinander verbundener TPU-Chips. Dies gilt nur für Topologien in 3-Tupeln ({A}x{B}x{C}).
  • TPU-Typ:Der Cloud TPU-Typ, z. B. v5e.
  • TPU-Slice:Eine Gruppe von Chips, die sich innerhalb desselben TPU-Pod befinden und über Hochgeschwindigkeits-Verbindungen zwischen den Chips (ICI) miteinander verbunden sind. Slices werden je nach TPU-Version in Bezug auf Chips oder TensorCores beschrieben.
  • TPU-Slice-Knoten:Ein Kubernetes-Knoten, der durch eine einzelne VM dargestellt wird, die einen oder mehrere verbundene TPU-Chips enthält.
  • TPU-Slice-Knotenpool:Eine Gruppe von Kubernetes-Knoten in einem Cluster, die alle dieselbe TPU-Konfiguration haben.
  • TPU-Topologie:Die Anzahl und die physische Anordnung der TPU-Chips in einem TPU-Slice.
  • Atomar:GKE behandelt alle verbundenen Knoten als eine Einheit. Bei Skalierungsvorgängen skaliert GKE die gesamte Gruppe von Knoten auf 0 und erstellt neue Knoten. Wenn eine Maschine 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 verbundener Knoten nicht manuell neue Knoten hinzufügen. Sie können jedoch einen neuen Knotenpool mit der gewünschten TPU-Topologie erstellen und Arbeitslasten im neuen Knotenpool planen.

Typen von TPU-Slice-Knotenpools

GKE unterstützt zwei Arten von TPU-Knotenpools:

Der TPU-Typ und die TPU-Topologie bestimmen, ob Ihr TPU-Slice-Knoten mehrere Hosts oder einen einzelnen Host haben kann. Unsere Empfehlungen lauten daher:

  • Verwenden Sie für umfangreiche Modelle TPU-Slice-Knoten mit mehreren Hosts.
  • Verwenden Sie für kleine Modelle TPU-Slice-Knoten mit einem einzelnen Host.
  • Verwenden Sie für umfangreiches Training oder Inferenz Pathways. Pathways vereinfacht umfangreiche ML-Berechnungen, indem ein einzelner JAX Client Arbeitslasten über mehrere große TPU-Slices hinweg orchestrieren kann. Weitere Informationen finden Sie unter Pathways.

TPU-Slice-Knotenpools mit mehreren Hosts

Ein TPU-Slice-Knotenpool mit mehreren Hosts ist ein Knotenpool, der zwei oder mehr verbundene TPU-VMs enthält. Jede VM hat ein TPU-Gerät, das mit ihr verbunden ist. Die TPUs in einem TPU-Slice mit mehreren Hosts sind über eine Hochgeschwindigkeitsverbindung (ICI) verbunden. Nachdem ein TPU-Slice-Knotenpool mit mehreren Hosts erstellt wurde, können Sie keine Knoten mehr hinzufügen. Sie können beispielsweise keinen v4-32 Knotenpool erstellen und später einen Kubernetes-Knoten (TPU-VM) zum Knotenpool hinzufügen. Wenn Sie einem GKE-Cluster ein TPU-Slice hinzufügen möchten, müssen Sie einen neuen Knotenpool erstellen.

Die VMs in einem TPU-Slice-Knotenpool mit mehreren Hosts werden als eine atomare Einheit behandelt. Wenn GKE einen Knoten im Slice nicht bereitstellen kann, werden keine Knoten im TPU-Slice-Knoten bereitgestellt.

Wenn ein Knoten in einem TPU-Slice mit mehreren Hosts repariert werden muss, beendet GKE alle VMs im TPU-Slice und erzwingt das Entfernen aller Kubernetes-Pods in der Arbeitslast. Nachdem alle VMs im TPU-Slice ausgeführt werden, können die Kubernetes-Pods auf den VMs im neuen TPU-Slice geplant werden.

Das folgende Diagramm zeigt ein v5litepod-16-TPU-Slice (v5e) mit mehreren Hosts. Dieses TPU-Slice hat vier VMs. Jede VM im TPU-Slice hat vier TPU v5e-Chips, die über Hochgeschwindigkeitsverbindungen (ICI) verbunden sind. Jeder TPU v5e-Chip hat einen TensorCore:

Diagramm eines TPU-Slice mit mehreren Hosts

Das folgende Diagramm zeigt einen GKE-Cluster mit einem TPU-Slice v5litepod-16 (v5e) (Topologie: 4x4) und einem TPU-Slice v5litepod-8 (v5e) (Topologie: 2x4):

TPU v5e-Pod-Diagramm

TPU-Slice-Knotenpools mit einem einzelnen Host

Ein Knotenpool mit einem einzelnen Host ist ein Knotenpool, der eine oder mehrere unabhängige TPU-VMs enthält. Jede VM hat ein TPU-Gerät, das mit ihr verbunden ist. Die VMs in einem Knotenpool mit einem einzelnen Host können zwar über das Rechenzentrumsnetzwerk (Data Center Network, DCN) kommunizieren, die an die VMs angehängten TPUs sind jedoch nicht miteinander verbunden.

Das folgende Diagramm zeigt ein Beispiel für ein TPU-Slice mit einem einzelnen Host, das sieben v4-8-Maschinen enthält:

Diagramm des Knotenpools für einen Slice mit einzelnem Host

Merkmale von TPUs in GKE

TPUs haben einzigartige Merkmale, die eine spezielle Planung und Konfiguration erfordern.

TPU-Nutzung

Um die Ressourcennutzung und die Kosten zu optimieren und gleichzeitig die Arbeitslastleistung auszugleichen, unterstützt GKE die folgenden TPU-Nutzungsoptionen:

  • Flex-Start:Sie können Flex-Start-VMs für bis zu sieben Tage bereitstellen. GKE weist die Hardware automatisch nach 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 mit einer 30-sekündigen Warnung vorzeitig beendet werden. Weitere Informationen finden Sie unter Spot-VMs.
  • Vorausschauende Reservierung für bis zu 90 Tage (im Kalendermodus) : Sie können 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:Sie können eine vorausschauende Reservierung für ein Jahr oder länger anfordern.
  • On-Demand:Sie können TPUs nutzen, ohne Kapazität im Voraus zu reservieren. Bevor Sie Ressourcen anfordern, müssen Sie genügend On-Demand-Kontingent für den jeweiligen Typ und die jeweilige Anzahl von TPU-VMs haben. On-Demand ist die flexibelste Nutzungsoption. Es gibt jedoch keine Garantie dafür, dass genügend On-Demand-Ressourcen verfügbar sind, um Ihre Anfrage zu erfüllen.

On-Demand ist das Standardnutzungsmodell für TPUs in GKE, wenn Sie keine andere Option angeben. Informationen zum Auswählen der Nutzungsoption, die Ihren Arbeitslastanforderungen entspricht, finden Sie unter Optionen für die Nutzung von Beschleunigern für KI-/ML-Arbeitslasten in GKE.

Bevor Sie TPUs in GKE verwenden, wählen Sie die Nutzungsoption aus, die am besten zu Ihren Arbeitslastanforderungen passt.

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, v5p und Ironwood (TPU7x), die in TPU-Slice-Knotenpools mit mehreren Hosts geplant sind, 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 TPU-Chips im Knotenpool. Sie können beispielsweise kleine Topologien mit weniger als 64 TPU-Chips mit Topologieformen wie 2x2x2, 2x2x4 oder 2x4x4 definieren. Wenn Sie größere Topologien mit mehr als 64 TPU-Chips verwenden, müssen die Werte, die Sie {A}, {B} und {C} zuweisen, die folgenden Bedingungen erfüllen:

  • {A}, {B} und {C} müssen Vielfache von vier sein.
  • Die größte unterstützte Topologie für v4 ist 12x16x16 und für v5p 16x16x24.
  • Die zugewiesenen Werte müssen dem Muster A ≤ B ≤ C entsprechen. Beispiel: 4x4x8 oder 8x8x8.

Benennung von Maschinentypen

Die Benennung von Maschinentypen für TPUs in GKE variiert je nach Clustermodus und TPU-Version:

  • GKE Standard:Sie wählen einen bestimmten Compute Engine-Maschinentyp aus, z. B. ct6e-standard-1t für TPU Trillium (v6e).

  • GKE Autopilot:Sie wählen keine Maschinentypen direkt aus. Stattdessen fordern Sie TPUs an, indem Sie in Ihrem Arbeitslastmanifest einen Beschleunigertyp verwenden. Verwenden Sie beispielsweise tpu-v6e-slice für TPU Trillium (v6e) oder tpu-v5-lite-podslice für TPU v5e. GKE Autopilot stellt dann die zugrunde liegenden Knoten mit den entsprechenden Maschinentypen bereit, um die Anfrage zu erfüllen.

Die genauen Maschinentypen, die für jede TPU-Version verfügbar sind, finden Sie in den Tabellen unter TPUs in GKE planen.

Privilegierter Modus

Wenn Sie GKE-Versionen vor 1.28 verwenden, müssen Sie Ihre Container mit speziellen Funktionen konfigurieren, um auf TPUs zuzugreifen. In Clustern im Standardmodus können Sie den privilegierten Modus verwenden, um diesen Zugriff zu gewähren. Im privilegierten Modus werden viele der anderen Sicherheitseinstellungen im securityContext überschrieben. Weitere Informationen finden Sie unter Container ohne privilegierten Modus ausführen.

Für Version 1.28 und höher ist kein privilegierter Modus oder keine spezielle Funktion erforderlich.

Funktionsweise von TPUs in GKE

Die Kubernetes-Ressourcenverwaltung und ‑Priorisierung behandelt VMs auf TPUs so wie andere VM-Typen. Verwenden Sie den Ressourcennamen google.com/tpu, um TPU-Chips anzufordern:

resources:
  requests:
    google.com/tpu: 4
  limits:
    google.com/tpu: 4

Wenn Sie TPUs in GKE verwenden, beachten Sie die folgenden TPU-Merkmale:

  • Eine VM kann auf bis zu 8 TPU-Chips zugreifen.
  • Ein TPU-Slice enthält eine feste Anzahl von TPU-Chips. Die Anzahl hängt vom ausgewählten TPU-Maschinentyp ab.
  • Die Anzahl der angeforderten google.com/tpu muss der Gesamtzahl der verfügbaren TPU-Chips auf dem TPU-Slice-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. Beachten Sie die folgenden Szenarien:
    • Der Maschinentyp ct5lp-hightpu-4t mit einer 2x4-Topologie enthält zwei TPU-Slice-Knoten mit jeweils vier TPU-Chips, also insgesamt acht TPU-Chips. Mit diesem Maschinentyp können Sie Folgendes tun:
    • Sie können keinen GKE-Pod bereitstellen, für den acht TPU-Chips erforderlich sind, auf den Knoten in diesem Knotenpool.
    • Sie können zwei Pods bereitstellen, die jeweils vier TPU-Chips erfordern, wobei jeder Pod auf einem der beiden Knoten in diesem Knotenpool bereitgestellt wird.
    • TPU v5e mit der Topologie 4x4 hat 16 TPU-Chips in vier Knoten. Die GKE Autopilot-Arbeitslast, die diese Konfiguration auswählt, muss vier TPU-Chips in jeder Replik anfordern, für ein bis vier Replikate.
  • In Standardclustern können mehrere Kubernetes-Pods auf einer VM geplant werden, aber in jedem Pod kann nur ein Container auf die TPU-Chips zugreifen.
  • Um kube-system-Pods wie kube-dns zu erstellen, muss jeder Standardcluster mindestens einen Nicht-TPU-Slice-Knotenpool haben.
  • Standardmäßig haben TPU-Slice-Knoten die google.com/tpu Markierung wodurch verhindert wird, dass Nicht-TPU-Arbeitslasten auf den TPU-Slice-Knoten geplant werden. Arbeitslasten, die keine TPUs verwenden, werden auf Nicht-TPU-Knoten ausgeführt, wodurch Rechenleistung auf TPU-Slice-Knoten für Code freigegeben wird, der TPUs verwendet. Die Markierung sorgt jedoch nicht automatisch dafür, dass TPU-Ressourcen vollständig genutzt werden.
  • GKE erfasst die Logs, die von Containern auf TPU-Slice-Knoten 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.
  • Sie können Ihre TPU-Arbeitslasten mit GKE Sandbox in einer Sandbox ausführen. GKE Sandbox funktioniert mit TPU-Modellen ab Version 4. Weitere Informationen finden Sie unter GKE Sandbox.

Automatische Erstellung von Knotenpools mit TPUs

Die automatische Erstellung von Knotenpools unterstützt die folgenden Cloud TPUs nur in bestimmten GKE-Versionen:

  • TPU v3: 1.31.0 und höher.
  • TPU v5 und TPU v4: 1.29.0 und höher.
  • TPU Trillium: 1.32.0 und höher.
  • Ironwood (TPU7x): 1.34.1-gke.2541000 oder höher.

Andere Cloud TPU-Typen werden in allen GKE-Versionen unterstützt. Weitere Informationen zu den verfügbaren GKE-Versionen für TPUs finden Sie unter TPU-Verfügbarkeit in GKE prüfen.

Autoscaling von Cloud TPU-Knotenpools

GKE skaliert automatisch erstellte oder manuell erstellte Cloud TPU-Knotenpools, die den Cluster Autoscaler verwenden, auf eine der folgenden Arten:

  • TPU-Slice-Knotenpool mit einem einzelnen Host: 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 die --max-nodes und die --total-max-nodes Autoscaling-Flags bestimmt. Alle TPU-Knoten im Knotenpool haben denselben Maschinentyp und dieselbe Topologie. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit einem einzelnen Host finden Sie unter TPU-Slice-Knotenpool mit einem einzelnen Host 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 hat der Knotenpool beispielsweise immer entweder 64 oder null Knoten. GKE skaliert den Knotenpool herunter, wenn keine TPU-Arbeitslasten im Knotenpool vorhanden sind. Um den Knotenpool herunterzuskalieren, entfernt GKE alle geplanten Pods und alle Knoten im Knotenpool. Weitere Informationen zum Erstellen eines TPU Slice-Knotenpools mit mehreren Hosts finden Sie unter TPU-Slice-Knotenpool mit mehreren Hosts erstellen.

Planung von Sammlungen

Die Planung von Sammlungen wird nur für TPU Trillium unterstützt.

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.steuert Softwareupdates, um sicherzustellen, dass immer genügend Slices in der Sammlung verfügbar sind, um Traffic zu verarbeiten. Google Cloud

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 das Verhalten bei der Planung von Sammlungen je nach verwendetem TPU-Slice-Typ unterscheidet:

  • TPU-Slice mit mehreren Hosts:GKE gruppiert TPU-Slices mit mehreren Hosts zu einer Sammlung. Jeder GKE-Knotenpool ist ein Replikat in dieser Sammlung. Um eine Sammlung zu definieren, erstellen Sie ein 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 einzelnem Host:GKE betrachtet den gesamten TPU-Slice-Knotenpool mit einem einzelnen 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 einzelnen Host ändern.

Für die Planung von Sammlungen gelten die folgenden Einschränkungen:

  • Sie können Sammlungen nur für TPU Trillium planen.
  • Sie können Sammlungen nur beim Erstellen von Knotenpools definieren.
  • Spot-VMs werden nicht unterstützt.
  • Für Sammlungen, die TPU-Slice-Knotenpools mit mehreren Hosts enthalten, müssen für alle Knotenpools in der Sammlung derselbe Maschinentyp, dieselbe Topologie und dieselbe Version verwendet werden.

Sie können die Planung von Sammlungen in den folgenden Szenarien konfigurieren:

Nächste Schritte

Informationen zum Einrichten von Cloud TPU in GKE finden Sie auf den folgenden Seiten: