Dynamisches Slicing in GKE

In diesem Dokument wird das dynamische Slicing in Google Kubernetes Engine (GKE) für Cloud TPU beschrieben. Dynamisches Slicing verbessert die TPU-Effizienz und -Flexibilität, indem die TPU-Bereitstellung von den TPU-Slice-Anforderungen der Arbeitslast entkoppelt wird. Dynamisches Slicing trägt dazu bei, die TPU-Ressourcenauslastung zu verbessern, indem die Startzeit von Arbeitslasten um das bis zu Fünffache und die Wiederherstellungszeit um das bis zu 4,5-Fache reduziert wird.

Dynamisches Slicing richtet sich an ML- und Plattform-Engineers, die die TPU-Auslastung optimieren, die Bereitstellungszeit verkürzen und die Fehlertoleranz für umfangreiche Trainings- und Inferenzarbeitslasten verbessern möchten.

Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:

Was ist dynamisches Slicing?

Dynamisches Slicing ist eine GKE-TPU-Optimierungsfunktion, die die physische und statische TPU-Hardwarebereitstellung von der TPU-Slice-Zuweisung zur Laufzeit entkoppelt, wenn Arbeitslasten geplant werden.

Wenn Sie statische TPU-Topologien verwenden, sind GKE-Knotenpools an die spezifische Topologie gebunden, die Sie bei der Erstellung konfiguriert haben. Aufgrund dieser Einschränkung ist der gesamte Knotenpool betroffen, wenn ein Knoten in einem statischen Pool ausfällt. Ihre Arbeitslasttopologie muss außerdem genau mit der TPU-Topologie des Knotenpools übereinstimmen, damit sie geplant werden kann. Dies kann häufiges erneutes Bereitstellen der TPU-Infrastruktur für verschiedene Arbeitslasten erfordern.

Mit dynamischem Slicing kann GKE TPU-Slices zur Laufzeit konfigurieren, wenn Arbeitslasten geplant werden. Anstatt für jede neue Arbeitslast manuell Knotenpools mit der genauen TPU-Topologie zu erstellen, stellen Sie Ihre gesamte TPU-Kapazität vorab in detaillierten Knotenpools mit fester Größe bereit. Bei Ironwood (TPU7x) besteht jeder Knotenpool aus einer 4x4x4-Topologie, die auch als Unterblock bezeichnet wird. Ein Unterblock stellt eine Gruppe von 16 TPU-VMs ohne aktive ICI-Topologie (Inter-Chip Interconnect) dar. Wenn Arbeitslasten zur Laufzeit geplant werden, konfiguriert das dynamische Slicing von GKE die TPU-Netzwerkverbindung neu, um entweder mehrere Knotenpools zu dem erforderlichen großen TPU-Slice zusammenzufügen oder Knotenpools in kleinere TPU-Slices zu unterteilen. Durch diese Neukonfiguration wird in Sekundenschnelle die genaue mehrdimensionale Topologie erstellt, die von einer Arbeitslast angefordert wird.

Vorteile des dynamischen Slicings

Die Implementierung einer dynamischen TPU-Architektur in GKE bietet folgende Vorteile:

  • Schnellere Wiederherstellung von Arbeitslasten: Bei einem physischen Hardwarefehler isoliert die GKE das Problem auf eine einzelne Partition. Der GKE-Slice-Controller formt den aktiven Slice automatisch um und konfiguriert das Netzwerk neu, um die fehlerhafte Partition durch eine fehlerfreie Ersatzpartition zu ersetzen. Dieser Prozess verbessert die Ausfallsicherheit oder die durchschnittliche Wiederherstellungszeit (Mean Time To Recovery, MTTR) um das bis zu 4,5-Fache im Vergleich zur Neuerstellung eines gesamten Knotenpools.
  • Beschleunigter Jobstart: Arbeitslast-Slices können dynamisch erstellt werden, was die Latenz beim Jobstart im Vergleich zum Erstellen statischer Knotenpools um das Fünffache verbessert.
  • Fehlerisolation: Hardwarefehler werden auf die spezifische Partition isoliert, in der der Fehler auftritt. Diese Isolation trägt dazu bei, andere gleichzeitige Jobs im Cluster vor kaskadierenden Fehlern zu schützen.
  • Optimierte Ressourcennutzung: Dynamisches Slicing hilft, ungenutzte oder nicht ausgelastete Kapazitäten zu vermeiden. Da Slices so konfiguriert sind, dass sie den Anforderungen der Arbeitslast entsprechen, trägt das dynamische Slicing dazu bei, die Flottenauslastung zu maximieren und die Hardware im Leerlauf zu minimieren.
  • Deklarative Orchestrierung: Beim dynamischen Slicing werden Kubernetes-native benutzerdefinierte Ressourcen und Annotationen wie JobSet und Kueue verwendet. Bei diesem Ansatz werden Low-Level-Netzwerke und die Hardware-Orchestrierung automatisch verwaltet.

Konfigurationen für dynamisches Slicing

Das dynamische Slicing bietet die folgenden Konfigurationen:

  • Dynamisches Super-Slicing: Kombiniert mehrere physisch separate, vorab bereitgestellte TPU-Knotenpools, um bei der Planung von Arbeitslasten ein einzelnes virtuelles Slice zu bilden. Sie können beispielsweise zwei 4x4x4-Knotenpools zu einer 4x4x8-Topologie kombinieren. Mit dieser Funktion können Sie Slices erstellen, die einer 4x4x4-Topologie entsprechen oder größer sind. Diese Konfiguration erfordert die Version 1.35.2-gke.1842000 oder höher. Mit dynamischem Super-Slicing können Sie große Foundation Models trainieren, die die Kapazität eines einzelnen physischen Hardwareblocks überschreiten.

    Der Slice-Controller orchestriert physische Neukonfigurationen innerhalb der OCS-Netzwerk-Fabric (Optical Circuit Switch). Durch die dynamische Neukonfiguration des OCS erweitert die GKE das ICI-Netzwerk (Inter-Chip Interconnect) auf unabhängige Hardwareracks. Aus Sicht der Arbeitslasten funktionieren die kombinierten Unterblöcke als ein einziges toroidales Mesh-Netzwerk. In einem toroidalen Mesh-Netzwerk sind die Verbindungen umlaufend. Die Chips am rechten Rand sind direkt mit den Chips am linken Rand verbunden und die Chips oben mit denen unten. Wenn Sie sich diese Anordnung vorstellen, würde sie die Form eines Torus (Ringform) haben.

  • Dynamisches Sub-Slicing: Partitioniert einen einzelnen, vorab bereitgestellten TPU-Knotenpool auf Arbeitslastebene in mehrere kleinere, unabhängige Einheiten. Mit dynamischem Sub-Slicing können Sie kleinere Topologien innerhalb eines einzelnen Sub-Blocks erstellen, insbesondere 2x2x1, 2x2x2, 2x2x4 und 2x4x4. Sie können beispielsweise einen 4x4x4-Unterblock in einen 2x2x4-Unterslice und zwei 2x2x2-Unterslices partitionieren. Für diese Konfiguration ist die Version 1.36.0-gke.3712000 oder höher im Rapid Channel erforderlich.

    Mit dynamischem Sub-Slicing können Sie mehrere Arbeitslasten in einem einzelnen physischen Knotenpool ausführen. Sie können beispielsweise gleichzeitig Feinabstimmung, Tests und Online-Inferenz ausführen. Die Aufteilung in Sub-Slices bietet eine elektrische und Netzwerkisolierung zwischen diesen Sub-Slices, was dazu beiträgt, Fehler oder Leistungseinbußen zwischen Arbeitslasten zu isolieren.

Wichtige Merkmale von Konfigurationen für dynamisches Slicing

Konfigurationen für dynamisches Slicing haben die folgenden Merkmale:

  • Inkrementelle Bereitstellung von Knotenpools: Beim dynamischen Slicing wird die inkrementelle Bereitstellung verwendet, ein fehlertolerantes Bereitstellungsmodell für Knotenpools. Bei diesem Modell wird Ihre gesamte TPU-Kapazität in Knotenpools umgewandelt, die aus 16-Knoten-Gruppen von Ironwood-VMs (TPU7x) bestehen. So können Sie auch teilweise fehlerhafte Cubes weiterhin bereitstellen und nutzen.
  • Slice-Controller: Ein benutzerdefinierter Kubernetes-Ressourcen-Controller, der in der GKE-Steuerungsebene ausgeführt wird und das dynamische Slicing verwaltet. Der Slice-Controller verwaltet den Lebenszyklus einer benutzerdefinierten Slice-Ressource, die einen dynamischen Slice darstellt (Erstellung, kontinuierliches Monitoring und Löschen). Außerdem werden Daten zum Zustand der Infrastruktur (Host, ICI, OCS) an Knotenlabels weitergegeben, um fehlerfreie Kandidatenknoten zu identifizieren.
  • Benutzerdefinierte Slice-Ressource: Stellt das logische Slice dar und initiiert die dynamische Konfiguration von Verbindungen zwischen Knoten (ICI und OCS), um die angeforderte TPU-Topologie zu bilden. Bei diesem Prozess werden entweder mehrere Unterblöcke zusammengefügt (Super-Slicing) oder eine kleinere Topologie innerhalb eines einzelnen Unterblocks isoliert (Sub-Slicing). Sie können den Fortschritt oder Zustand der dynamischen Slice-Erstellung prüfen, indem Sie die Statusfelder der benutzerdefinierten Slice-Ressource prüfen.

Voraussetzungen

Für die Verwendung von dynamischem Slicing in GKE müssen die folgenden Anforderungen erfüllt sein:

  • Verwenden Sie einen Standardcluster im Rapid Channel in einer der folgenden Versionen:
    • Verwenden Sie für die dynamische Super-Slicing-Konfiguration (Topologien gleich oder größer als 4x4x4) die Version 1.35.2-gke.1842000 oder höher.
    • Verwenden Sie für die dynamische Sub-Slicing-Konfiguration (Topologien kleiner als 4x4x4) die Version 1.36.0-gke.3712000 oder höher.
  • Verwenden Sie die Ironwood-Version (TPU7x).
  • Verwenden Sie das Container-Optimized OS-Image für Ihre Knoten.
  • Wenn Sie die inkrementelle Bereitstellung verwenden möchten, müssen Sie Reservierungen im Modus „Gesamte Kapazität“ verwenden. Der Modus „Alle Kapazitäten“ ist eine Funktion, die von TPU Cluster Director aktiviert wird.
  • Für dynamisches Sub-Slicing müssen Ihre Knoten ausstehende Wartungsereignisse haben. Instanzen auf ausstehende Wartungsereignisse überwachen Wenn für einen Ihrer Knoten ein ausstehendes Wartungsereignis mit einer Endzeit zwischen dem 18. September 2026 und dem 30. September 2026 geplant ist, müssen Sie das Hostwartungsereignis auf diesen Knoten manuell auslösen, bevor Sie Sub-Slicing verwenden können.

Planer für dynamisches Slicing verwenden

Für das dynamische Slicing haben Sie folgende Möglichkeiten:

Nächste Schritte