Google macht dynamisches Slicing für TPU-Workloads in GKE allgemein verfügbar

TPU-Hardware und Workload-Topologie voneinander trennen

Dynamisches Slicing entkoppelt die Bildung logischer TPU-Slices von der Bereitstellung physischer Nodepools in Google Kubernetes Engine. Bisher mussten Teams, die GKE Standard nutzten, separate, feste Nodepools für TPU-Slice-Topologien verwalten. Änderungen an den Anforderungen von Workloads konnten das Löschen und erneute Erstellen dieser Nodepools erfordern, was die Startzeit und die betriebliche Komplexität erhöhte.

Google Cloud zufolge führte die bisherige Anordnung zudem zu größeren Fehlerdomänen. Ein einzelner Hardwarefehler konnte einen gesamten Slice außer Betrieb setzen, während die Infrastruktur neu bereitgestellt wurde. Dynamisches Slicing nutzt stattdessen optisches Schalten von TPU-Verbindungen, kurz OCS, um TPU-Cubes zu größeren Slices zu verbinden oder sie für mehrere Workloads in kleinere Slices aufzuteilen.

Super-Slicing und Sub-Slicing

Dynamisches Slicing in GKE ist in zwei Varianten verfügbar. Super-Slicing verbindet mehrere TPU-Cubes zu Slices, die größer als ein einzelner Cube sind. Jeder Cube besteht aus 16 virtuellen Maschinen, die in einer 4x4x4-Slice-Topologie konfiguriert sind. Wenn ein Workload seine benötigte Topologie in einer Kubernetes-Workload-YAML-Datei angibt, können der GKE-Scheduler oder ein benutzerdefinierter Scheduler den entsprechenden Slice zum Zeitpunkt der Planung anfordern.

Google nennt einen 4x4x16-Super-Slice als Beispiel. Er entsteht durch die Verbindung von vier Ironwood-Cubes und umfasst 64 Ironwood-VMs sowie insgesamt 256 Chips.

Sub-Slicing partitioniert einen vorab bereitgestellten TPU-Cube in kleinere, unabhängige Slices. Dadurch können mehrere Jobs mit unterschiedlichen Topologieanforderungen gleichzeitig innerhalb desselben physischen Cubes ausgeführt werden. Wenn ein Job abgeschlossen ist, zerlegt der Scheduler den Slice und gibt seine Partitionen an den gemeinsamen Pool zurück, ohne den GKE-Nodepool neu erstellen zu müssen.

Schnellerer Start, schnellere Wiederherstellung und bessere Kapazitätsnutzung

Nach Angaben von Google Cloud ermöglicht dynamisches Slicing einen bis zu 5-mal schnelleren Jobstart, weil logische Topologien aus vorab bereitgestellten TPU-Nodepools zusammengesetzt werden, anstatt auf die Bereitstellung eines neuen Nodepools zu warten. Zudem kann sich die Auslastung der Flotte verbessern, indem kleinere Workloads in gemeinsam genutzte Nodepools gepackt und funktionsfähige Hosts in teilweise funktionsfähigen Nodepools verwendet werden.

Nach Angaben des Unternehmens kann die Wiederherstellung bis zu 4,5-mal schneller erfolgen, da sich Fehler auf einen TPU-Cube begrenzen lassen, der als 16-VM-Slice mit einer 4x4x4-Topologie beschrieben wird. Fehlerhafte Cubes können innerhalb von ein bis zwei Minuten ausgetauscht werden, während gesunde Partitionen für Workloads verfügbar bleiben.

Google Cloud zufolge kann dynamisches Slicing Trainingskonfigurationen unterstützen, die von großen einzelnen Slices mit 8.000 Chips bis zu Multi-Slices mit mehreren Tausend Chips sowie Konfigurationen mit vier Chips auf einem einzelnen Host reichen. Sub-Slicing soll außerdem Inferenz-Workloads von kleinen bis hin zu groß angelegten Bereitstellungen unterstützen.

Was Teams für den Einstieg benötigen

Organisationen müssen zunächst TPU-Kapazität in Nodepools mit jeweils 16 VMs vorab bereitstellen. Diese Einheiten entsprechen einem TPU-Cube oder Sub-Block und bilden die Grundlage für die bedarfsgesteuerte Erstellung benutzerdefinierter Slice-Topologien.

Dynamisches Slicing führt inkrementelle Bereitstellungs-Nodepools ein. Google beschreibt dies als fehlertolerantes Modell, das verfügbare gesunde Hosts auch dann nutzt, wenn einige Hosts in einem 16-VM-Slice fehlerhaft sind. Das System gleicht den Nodepool kontinuierlich ab und fügt ausstehende Nodes hinzu, sobald sich fehlerhafte Hosts erholen.

Nach der Aktivierung des Slice-Controllers und der Konfiguration des GKE-Schedulers können Teams dynamische Slices über Workload-Annotationen anfordern. GKE stellt für dynamisches Slicing optimierte Scheduler bereit. Kunden können jedoch auch benutzerdefinierte Scheduler und Informationen zum Systemzustand verwenden, um die Platzierung von Workloads zu steuern. Damit erhalten Plattformteams eine Möglichkeit, vorab bereitgestellte TPU-Kapazität über heterogene KI-Workloads hinweg gemeinsam zu nutzen und zugleich den Bedarf an manuellen Änderungen an Nodepools zu verringern.