Google kündigt TPU 8t Sunfish und TPU 8i Zebrafish an

Auf der Google Cloud Next kündigte Google seine KI-Beschleuniger der nächsten Generation an: die TPU 8t „Sunfish“ für das Training und die TPU 8i „Zebrafish“ für die Inferenz, zusammen mit seiner neuen Virgo-Rechenzentrumsarchitektur. Aus Googles Blogbeiträgen geht hervor, dass diese Chips für das „agentische Zeitalter“ optimiert sind: Sie trainieren hochmoderne Mixture-of-Experts-Modelle im Umfang von Hunderttausenden von Chips und stellen diese Modelle anschließend mit geringer Latenz und aggressiven Preiszielen pro Token bereit. Die 8t und 8i sind zwei architektonisch unterschiedliche Chips, die zwar dieselbe Host-Plattform und dieselbe Architektur nutzen, sich aber in Speicherkapazität, On-Chip-SRAM, Verbindungsarchitektur und On-Die-Spezialisierung unterscheiden. Die 8t ist für die dichte Matrixmultiplikation (matmul) im großen Maßstab ausgelegt, während die 8i auf KV-Cache auf Silizium und geringer kollektiver Latenz pro Token basiert.

Ein einzelner 8t-Superpod skaliert auf bis zu 9,600 Chips, verfügt über 2 PB HBM und liefert 121 EFLOPS FP4-Rechenleistung – fast das Dreifache der Rechenleistung eines Ironwood-Superpods pro Pod. 8i kombiniert 288 GB HBM mit 384 MB On-Chip-SRAM (dreimal so viel wie Ironwood) in einer Scale-Up-Domäne mit 1,152 Chips und bietet laut Herstellerangaben ein um 80 % besseres Preis-Leistungs-Verhältnis als Ironwood bei LLM-Inferenz. Virgo integriert beide Chipfamilien in ein einziges Rechenzentrumsnetzwerk, das mehr als 134,000 8t-Chips mit einer nicht-blockierenden Bisektionsbandbreite von 47 Pb/s verbindet. Dies ermöglicht bis zu viermal höhere Bandbreite pro Beschleuniger und eine um 40 % geringere Latenz im Leerlauf als bei der Vorgängergeneration.

Was ein TPU eigentlich ist

Bevor wir uns mit dem Silizium der 8er-Serie befassen, hier einige Hintergrundinformationen darüber, was eine TPU ist und wie sie sich von einer GPU unterscheidet, denn die Designentscheidungen der 8er-Serie sind nur in diesem Kontext sinnvoll.

Eine Tensor Processing Unit (TPU) ist ein kundenspezifischer ASIC, den Google seit 2015 weiterentwickelt. Jede Generation basiert auf demselben Kernprinzip: Anstatt wie eine GPU Tausende kleiner Kerne dynamisch zu planen, konzentriert sich eine TPU auf wenige sehr große MXUs (Matrixmultiplikationseinheiten). Diese werden von einem On-Chip-Scratchpad (softwareverwaltet) gespeist und von einem Ahead-of-Time-Compiler gesteuert. Jeder Chip enthält einige TensorCores, die jeweils um eine große MXU mit systolischem Array aufgebaut sind, sowie eine kleinere Anzahl von SparseCores, die für die unregelmäßigen Gather-Scatter-Lookups zuständig sind, welche die Empfehlungseinbettungen dominieren. Die Daten fließen vom HBM durch das Scratchpad, durch die MXU, zurück zum Scratchpad und wieder hinaus. Eine Vector Processing Unit (VPU) übernimmt dabei Aktivierungen, Normalisierungen und Reduktionen. Es gibt keinen Hardware-Warp-Scheduler, keine L1- oder L2-Cache-Hierarchie wie bei einer GPU und keine dynamische Dispatch-Verwaltung.

Der Vorteil dieses Designs liegt in der Effizienz bei komplexen linearen Algebraoperationen. Da ein Ahead-of-Time-Compiler festlegt, wo jeder Tensor gespeichert wird und wann jeder Kollektivalgorithmus ausgeführt wird, entstehen weder Cache-Miss-Jitter noch zusätzliche Kosten durch den Warp-Scheduler. Dies ist besonders wichtig, wenn Zehntausende von Chips während eines Kollektivalgorithmus synchronisiert bleiben müssen. Die FLOP-Auslastung realer Modelle ist auf TPUs für gut optimierte Trainingslasten tendenziell höher als auf herkömmlichen GPUs. Der Nachteil besteht darin, dass sich alles, was sich nicht direkt auf große, komplexe Matrixmultiplikationen abbilden lässt – insbesondere dynamische Formen, unregelmäßige Sparsity-Muster, MoE-Routing mit ungleichmäßiger Tokenverteilung oder Graph-Neuronale Netze –, schwieriger effizient darstellen lässt. TPUs verfügten zudem historisch gesehen über weniger HBM pro Chip als ihre GPU-Pendants und boten eine deutlich eingeschränktere Framework-Unterstützung. XLA und JAX sind erstklassig; PyTorch benötigte bis vor Kurzem eine Übersetzungsschicht; darüber hinaus sind Compiler, Laufzeitumgebung, Netzwerkbibliotheken und der Multi-Pod-Software-Stack weiterhin Closed Source bei Google.

Sparsity ist das beste Beispiel für den philosophischen Unterschied zwischen GPUs und TPUs, und der Grund dafür ist struktureller Natur und nicht marketingbedingt. NVIDIA unterstützt 2:4-strukturierte Sparsity auf Tensor-Kernen seit Ampere, und theoretisch ist die Leistung bei spärlichen Arbeitslasten doppelt so hoch wie bei dichten. Ein Tensor-Kern ist im Grunde eine Dispatch-Einheit: Er benötigt explizite Operanden-Ladevorgänge pro MMA-Befehl. Daher ist das Hinzufügen einer spärlichen MMA-Variante, die einen komprimierten 2-aus-4-Block plus Index-Metadaten akzeptiert, eine einfache Erweiterung des bestehenden Befehlssatzes. In jedem Zyklus lädt die Hardware nur die Nicht-Null-Werte und ihre Indizes in das Multiplikator-Array und überspringt implizit die Nullen.

Ein systolisches Array funktioniert genau umgekehrt. Jedes Verarbeitungselement (PE) berechnet in jedem Zyklus die Operanden, die synchron über direkte Register-zu-Register-Pfade von einem PE zum nächsten durch das Array fließen. Dieser deterministische Datenfluss ist genau der Grund für den Energieeffizienzvorteil gegenüber SIMT: keine wiederholten SRAM-Lesezugriffe, kein Overhead bei der Befehlsausgabe, maximale Wiederverwendung von Operanden. Das bedeutet aber auch, dass die Hardware in jedem Zyklus kein Element mit dem Wert Null überspringen kann, ohne die Pipeline zu unterbrechen.

TPUs können weiterhin Sparsity auf Kachelebene ausnutzen; besteht eine gesamte Kachel der Größe einer MXU nur aus Nullen, plant der Compiler keine Verarbeitung dafür ein. Googles Entscheidung, keine Hardwarebeschleunigung für strukturierte Sparsity zu implementieren, ist jedoch bewusst. Das Hinzufügen von M:N-strukturierter Sparsity zu einem systolischen Array kann mit verschiedenen Techniken erreicht werden, die jeweils unterschiedliche Vor- und Nachteile mit sich bringen. Eine dieser Techniken erfordert eine Kompressionseinheit zwischen SRAM und den Eingangsports des Arrays. Ein systolisches Array ist jedoch eine Pipeline, kein Dispatcher. Seine Effizienzgarantie beruht darauf, dass die Operanden in einer deterministischen Reihenfolge eintreffen und jedes Verarbeitungselement in jedem Zyklus ausgelastet ist. Das Überspringen von Operanden führt zu einem von zwei Problemen: Entweder wird die Pipeline bei den Nullen blockiert, wodurch der Effizienzvorteil, der die Architektur ursprünglich motivierte, verloren geht. Oder es wird dedizierte Dekomprimierungshardware benötigt, um aus dem komprimierten Input einen Datenstrom voller Breite zu rekonstruieren, bevor dieser in das Array gelangt. Dies würde Chipfläche beanspruchen und die Latenz erhöhen.

Einige Beschleuniger kombinieren systolische Arrays mit Hardwareunterstützung für Sparsity. AWS hat dies mit NeuronCore-v3, der Engine von Trainium2 und Trainium3, umgesetzt. Die Implementierung zeigt, wie ein hardwareseitig spärliches systolisches Array aussieht. Die NeuronCore-v3 Tensor Engine ist ein 128×128 systolisches Array, das mit einer stationären Gewichtsmatrix und einer Streaming-Aktivierungsmatrix arbeitet. Die Kontraktionsdimension ist dabei an die Partitionsdimension des Arrays angepasst. Im Sparsity-Modus erweitert sich der Eingabedatenpfad von 2×128 Elementen pro Zyklus bei dichtem BF16 und FP16 auf 5×128 Elemente pro Zyklus. Die stationäre Seite verwendet eine komprimierte Darstellung der Gewichtsmatrix anstelle der ursprünglichen dichten Gewichte. Zur Kompilierzeit wird der Gewichtstensor in ein M:N-Format umgewandelt. Von jeweils N zusammenhängenden Elementen entlang der Kontraktionsdimension werden nur M beibehalten. Eine kompakte Bitmaske kodiert, welche Positionen ungleich null sind. Der komprimierte Puffer speichert nur die M Werte und verkleinert sich um den Faktor N/M. Bei der Ausführung des matmul-Befehls liest die Hardware die komprimierten Gewichte und verwendet die Bitmaske, um die entsprechenden Aktivierungen vom stationären Tile den richtigen Verarbeitungselementen zuzuweisen. Verarbeitungselemente, die mit Null multipliziert würden, erhalten für diesen Slot keine Arbeit. Da die Bitmaskensuche und das Routing im Dekompressor erfolgen, der das Array speist, und nicht im Array selbst, arbeitet die Pipeline bei Werten ungleich Null mit voller Durchsatzrate, anstatt bei Nullen anzuhalten.

Dichte Matrixmultiplikation ist nicht die einzige Aufgabe einer TPU. Seit mehreren Generationen verfügen TPUs neben den TensorCores über einen SparseCore. Der SparseCore ist eine domänenspezifische Engine, die für die unregelmäßigen Gather-Scatter-Zugriffsmuster von Empfehlungsmodellen entwickelt wurde. Ein YouTube-Ranking-Modell oder ein Suchanzeigen-Relevanzmodell ähnelt keinem Dense Transformer. Die meisten Parameter befinden sich in Einbettungstabellen, die Hunderte von Gigabyte bis hin zu Petabytes umfassen können. Der Großteil der Rechenzeit wird für kleine Abfragen in diesen Tabellen, die leichte Transformation der abgerufenen Werte und die Kombination der Ergebnisse aufgewendet. Dieses Zugriffsmuster stellt einen Worst-Case für eine MXU dar und ist für die Cache-Hierarchie einer GPU nur geringfügig besser. SparseCores sind genau darauf optimiert: Hochdurchsatz-Gather-Scatter-Operationen auf HBM-basierten Einbettungstabellen mit Hardwareunterstützung für die Deduplizierungs- und Kombinationsoperationen, von denen der Rest der Einbettungspipeline abhängt. Die gleiche Hardware hilft auch beim MoE-Experten-Routing, denn sobald die Top-k-Auswahl Expertenindizes erzeugt, folgt der Rest des Routing-Prozesses (Permutieren der Token nach Experten, Verteilen auf die Chips, Zurücksammeln der Expertenausgaben und Durchführen der gewichteten Reduktion) dem gleichen Gather/Scatter/Reduce-Muster wie die Embedding-Pipeline, wobei die Sortierunterstützung von SparseCore den Top-k-Schritt selbst abdeckt.

Vor diesem Hintergrund folgen nun die Ankündigungen.

TPU 8t „Sunfish“

Die erste Ankündigung betrifft den Trainingschip TPU 8t mit dem Codenamen Sunfish. Der Generationssprung gegenüber Ironwood folgt in den meisten Aspekten den Erwartungen: mehr Speicher, höhere Bandbreite und native Unterstützung für schmalere Datentypen. Jeder Chip verfügt über einen einzelnen TensorCore, der von sechs 12-Hi HBM3e-Stacks mit insgesamt 216 GB Speicherkapazität und einer Übertragungsrate von 6.5 TB/s gespeist wird – im Vergleich zu den 192 GB des Vorgängers Ironwood, verteilt auf acht Stacks. Der On-Chip-Vmem-SRAM bleibt bei 128 MB.

Der Großteil des Rechenleistungssprungs ist auf die native FP4-Architektur der MXU zurückzuführen. Die Ausführung von Matrixmultiplikationen mit 4 Bit statt 8 Bit verdoppelt den Durchsatz pro Taktzyklus für dasselbe physikalische Array. Dadurch erreicht Google mit der 8t-Architektur einen Leistungszuwachs von 12.6 PFLOPS (FP4) gegenüber 4.6 PFLOPS (FP8) bei Ironwood. Beim Training mit gemischter Präzision wird weiterhin eine FP32-Masterkopie der Gewichte für den Optimierungsschritt verwendet; FP4 verkleinert die Arbeitstensoren, die den Großteil der Rechenzeit beanspruchen.

Die Verbindungsarchitektur ist einfach. Die ICI-Bandbreite verdoppelt sich auf 19.2 Tb/s pro Chip, der Superpod mit 9,600 Chips aggregiert 2 PB HBM und 121 EFLOPS, und die 3D-Torus-Topologie bleibt erhalten. Der Torus ist für das Training sinnvoll, da die wichtigsten Rechenprozesse von ringfreundlichen Kollektiven dominiert werden: All-Reduces für Daten- und Tensorparallelität, All-Gathers und Reduce-Scatters für FSDP sowie pipeline-parallele Punkt-zu-Punkt-Sendungen. All diese Operationen lassen sich problemlos auf die Torusachsen abbilden.

Google verwendet weiterhin die SparseCores, die seit Version 4 auf jeder TPU verbaut sind. Ursprünglich waren sie für DLRM-basierte Empfehlungsmodelle gedacht, bei denen der Großteil der Rechenzeit für unregelmäßige Gather-Scatter-Operationen gegen massive Einbettungstabellen benötigt wird. Dieselbe Hardware übernimmt auch das MoE-Routing. JAX stellt Ragged All-to-All und das entsprechende Ragged Dot als Operationen erster Klasse bereit, bei denen jeder Chip einen unterschiedlich großen Datenblock an jeden Peer senden kann. Dies entspricht der tatsächlichen Struktur des MoE-Dispatches, da das Top-k-Routing datenabhängig ist und die Anzahl der Token, die an jeden Experten fließen, in jedem Schritt variiert. Der Compiler fasst die unregelmäßige Kommunikation und die unregelmäßige Matrixmultiplikation der Experten zu einer einzigen geplanten Operation zusammen, während SparseCore die umgebenden Sortier- und Permutationsoperationen übernimmt. Da Mixture-of-Experts mittlerweile die dominierende Architektur in modernen Modellen ist, beweist diese Hardware ihren Wert bei jeder modernen Trainingsaufgabe, nicht nur bei den Werbe- und Ranking-Workloads, für die sie ursprünglich entwickelt wurde.

Dies sind evolutionäre Schritte. Die größeren Veränderungen sind TPUDirect und der Wechsel zu Axion-basierten Hosts, die beide Engpässe beheben, die erst im fortgeschrittenen Maßstab sichtbar werden.

TPUDirect RDMA und TPUDirect Storage

Frühere TPU-Generationen nutzten einen hostvermittelten Pfad für Netzwerk- und Speicher-I/O: Pakete landeten zunächst im Host-DRAM, dann kopierte ein separater DMA-Prozess sie in den TPU-HBM. Das bedeutete zwei Speichertransaktionen mit der Host-CPU. TPUDirect RDMA eliminiert den Bounce-Puffer. Die Netzwerkkarte liest und schreibt den TPU-HBM direkt über PCIe Peer-to-Peer, wodurch der Host aus dem Datenpfad entfernt wird. NVIDIA bietet mit GPUDirect RDMA bereits seit Jahren eine vergleichbare Funktionalität und gibt eine etwa zehnfache Leistungssteigerung gegenüber dem hostvermittelten Pfad an. Google zieht nun auf der TPU-Seite nach.

TPUDirect Storage erweitert dieses Prinzip auf persistenten Speicher. Tensoren werden mit einer Gesamtrate von 10 TB/s direkt zwischen TPU HBM und Managed Lustre übertragen. Laut Google ermöglicht dies einen zehnmal schnelleren Speicherzugriff als der entsprechende Pfad auf Ironwood. Im Grenzbereich, wo Checkpoints Hunderte von Terabyte umfassen können, entscheidet sich, ob ein mehrwöchiger Trainingslauf Checkpoints und Datensätze mit Leitungsgeschwindigkeit streamt oder die MXU-Pipeline durch Wartezeiten auf Host-I/O blockiert.

Arm Axion Hosts

Alle vorherigen TPU-Generationen liefen auf x86-Hostsystemen von Drittanbietern. Die 8t ist die erste, die Googles eigenen Axion-Prozessor, eine auf Arm Neoverse V2 basierende CPU, als System-Header verwendet. Die Host-CPU hat auf einem TPU-Pod eine anspruchsvolle Aufgabe, die mit zunehmender Größe immer komplexer wird: Sie steuert die Eingabepipeline, dekodiert und verarbeitet Multi-Petabyte-Datensätze, verwaltet die JAX/XLA-Steuerungsebene, übernimmt die Checkpoint-Serialisierung und koordiniert die SPMD-Verteilung über Tausende von Chips. Wenn der Host ausfällt, steht die MXU still.

Google hebt die Axion-basierte NUMA-Isolation auf 8t als Mechanismus hervor, der verhindert, dass serverseitige Jitter in die synchronisierten kollektiven Trainingsphasen gelangen. Bei 9,600 Chips pro Pod summieren sich selbst kleine Schwankungen pro Host zu messbaren Leistungseinbußen. TPUDirect optimiert den Datenpfad, indem der Host von Massenübertragungen ausgeschlossen wird. Axion optimiert den Kontrollpfad, indem jeder TPU ausreichend dedizierte CPU-Bandbreite zugewiesen wird, sodass die Vorverarbeitung niemals zum Flaschenhals wird. Google hat zudem das Verhältnis physischer Axion-Hosts pro Server auf der Plattform der achten Generation erhöht. Dadurch steht dem Orchestrierungsaufwand, der mit der Chipanzahl skaliert, mehr Spielraum zur Verfügung als bei der Host-Konfiguration von Ironwood.

TPU 8i „Zebrafisch“

Der Inferenzchip nutzt dieselbe Axion-Hostplattform wie 8t, natives FP4 und HBM3e-Speicher, aber die darunterliegende Siliziumarchitektur zielt auf einen anderen Flaschenhals ab. Das Training ist rechenintensiv, die Inferenzdekodierung hingegen speicherbandbreitenbegrenzt. Die meisten architektonischen Unterschiede von 8i ergeben sich daraus.

Die größte Änderung betrifft den On-Chip-SRAM. Der 8i verfügt über 384 MB Vmem, dreimal so viel wie der Ironwood. Dies ist aufgrund des KV-Caches von Bedeutung. Bei der Dekodierung langer Kontexte muss für jedes generierte Token der akkumulierte Schlüssel-Wert-Zustand vorheriger Token gelesen werden. Bei den meisten Beschleunigern erfolgt dieser Lesevorgang aus dem HBM, wodurch der Dekodierungsdurchsatz eher durch die Speicherbandbreite als durch die Rechenleistung begrenzt wird. Der 8i ist so dimensioniert, dass ein sinnvoller KV-Cache vollständig auf dem Chip untergebracht werden kann. Die On-Chip-SRAM-Bandbreite ist etwa eine Größenordnung höher als die des HBM. Daher bedeutet jeder KV-Lesevorgang aus dem SRAM anstatt aus dem HBM eine geringere Latenz pro Token und eine höhere Token-Verarbeitungsrate pro Sekunde bei gleichem Stromverbrauch.

Die TensorCore-Konfiguration stellt die zweite wesentliche Neuerung dar. Während 8t einen einzelnen TensorCore mit 12.6 PFLOPS nutzt, verteilt 8i die Rechenleistung auf zwei TensorCores mit insgesamt 10.1 PFLOPS. Ein geringerer Spitzendurchsatz mag zunächst wie ein Rückschritt erscheinen, doch betrachtet man die tatsächliche Funktionsweise der Inferenz auf Chipebene, wird dies deutlich. Trainings-Workloads sind batchdominiert: Große Matrixmultiplikationen amortisieren den fixen Overhead, und eine einzelne große MXU kann nahezu maximale Auslastung gewährleisten. Bei der Inferenzdekodierung verhält es sich genau umgekehrt. Die Batchgrößen sind klein, die Rechenfenster pro Token kurz, und der Chip verbringt einen erheblichen Teil seiner Zeit mit Kollektivoperationen, Sampling und Routing anstatt mit reiner Matrixmultiplikation. Eine einzelne große Engine würde während dieser unregelmäßigen Pausen ins Stocken geraten. Die Aufteilung in zwei TensorCores ermöglicht es 8i, Rechenphasen effektiver zu überlappen. Jeder TensorCore wird von seinen vier direkt angeschlossenen HBM-Stacks versorgt, die insgesamt 288 GB mit 8.6 TB/s über das gesamte Paket bereitstellen. Das Ergebnis ist eine höhere, nachhaltige Auslastung bei den Chargengrößen, die im interaktiven Service tatsächlich zum Einsatz kommen.

Auf der Ebene der Scale-up-Domäne verfügen die 1,024 aktiven Chips eines Boardfly-Pods über insgesamt etwa 295 TB HBM, 384 GB On-Chip-SRAM und 10.3 EFLOPS FP4-Rechenleistung. Die SRAM-Größe ist für die Inferenz entscheidend: 384 GB On-Chip-Cache reichen aus, um umfangreiche KV-Zustände zu speichern, ohne auf HBM zurückzugreifen. Dies ermöglicht die Bereitstellung von Langzeitkontexten mit geringer Latenz.

Auf der Hostseite gilt dieselbe Logik. Google gibt an, die Anzahl der physischen Axion-Hosts pro Server auf 8i im Vergleich zu Ironwood erhöht zu haben. Inferenzserver verwenden einen erheblichen Teil der Token-Zeit für Tokenisierung, Sampling-Logik, Routing, Batching und die Orchestrierung der Agentenlaufzeit. Dieser Overhead skaliert mit der Parallelität und nicht mit der Modellgröße. Bei den Anfrageraten, die agentenbasierte Workloads erzeugen, kann der Host zum Flaschenhals werden. Mehr Host-CPU pro Beschleuniger ist die naheliegende Lösung.

Kollektive Beschleunigungsmotor

Die zweite wichtige Änderung auf dem Chip ist die Collectives Acceleration Engine, die die vier SparseCores des Ironwood ersetzt. SparseCores übernehmen das MoE-Routing und die Einbettungs-Lookups mit dedizierter Gather-Scatter-Hardware. Dadurch werden sie von den Inferenzchipsignalen entfernt, die 8i für einen anderen Flaschenhals optimiert.

Der Flaschenhals, den CAE adressiert, ist die kollektive Latenz. Jedes dekodierte Token erfordert die Synchronisierung der beteiligten Chips: Aufmerksamkeitsausgaben müssen vollständig reduziert, Experten-Routing-Metadaten müssen übertragen und abgetastete Tokens an den nächsten Schritt weitergeleitet werden. Auf GPUs erfolgt diese Koordination softwareseitig über NCCL, das kollektive Vorgänge als Sequenz von Kernel-Starts und Netzwerkoperationen plant. Auf 8i ist CAE ein dedizierter Siliziumchip, der sich auf einem eigenen Chiplet-Die neben den TensorCores befindet und diese Synchronisierungsprimitive in Hardware verarbeitet.

Google behauptet, die kollektive Latenz auf dem Chip sei im Vergleich zu Ironwood bis zu 5-mal geringer. Bei Batchgrößen im Trainingsmaßstab würde diese Verbesserung jedoch durch die Rechenzeit kompensiert; die kollektive Latenz macht nur einen Bruchteil des Fortschritts aus. Bei kleinen Batches und kurzen Zeitfenstern pro Token in der interaktiven Inferenz kann die kollektive Latenz die Zeit pro Token dominieren, sodass sich die 5-fache Reduzierung in Token pro Sekunde und Preis pro Token niederschlägt.

8i wechselt außerdem von der 3D-Torus-Topologie zu dem von Google so genannten Boardfly, einer von Dragonfly inspirierten hierarchischen Topologie, die Bandbreite für Ringkollektive gegen Latenz zwischen allen Geräten eintauscht. Wir werden Boardfly weiter unten detailliert untersuchen.

Boardfly-Topologie

8i verwendet eine andere Topologie als 8t, da Training und Inferenz unterschiedliche Kommunikationsmuster aufweisen.

Der 3D-Torus eignet sich ideal für Ringkollektive: Jeder Chip hat sechs Nachbarn, die Daten rotieren im Ring, und kein Chip leitet beliebigen Datenverkehr. Das Training wird von diesen ringfreundlichen Mustern dominiert, weshalb 8t den Torus beibehält. Ein Ring-All-Reduce-Algorithmus lässt sich perfekt auf eine einzelne Torusachse abbilden. Moderne Anwendungen platzieren typischerweise Datenparallelität auf einer Achse, Tensorparallelität auf einer anderen und Pipelineparallelität auf der dritten. Topologie und Arbeitslast sind optimal aufeinander abgestimmt.

Die Inferenz für ein großes MoE-Modell weist ein anderes Kommunikationsprofil auf. Experten sind auf viele Chips verteilt, und jedes dekodierte Token löst eine All-to-All-Kommunikation aus: Tokens müssen ihre zugewiesenen, über das gesamte Netzwerk verteilten Experten erreichen, und die Expertenausgaben müssen zurückgegeben werden. Dies ist kein Ring, sondern beliebiger Punkt-zu-Punkt-Verkehr. Auf einem 3D-Torus mit 1,024 Chips beträgt der ungünstigste Pfad zwischen zwei beliebigen Chips 16 Hops. Google erläutert dies mathematisch: „In einem 3D-Torus sind die Knoten in einem Gitter angeordnet, wobei jede Dimension wie ein Ring verläuft. Um den am weitesten entfernten Chip in einer 8 x 8 x 16 (1024-Chip-)Konfiguration zu erreichen, muss ein Paket die Hälfte der Entfernung jedes Rings zurücklegen.“

3D-Torus = 8/2(X) + 8/2(Y) + 16/2(Z) = 16 Sprünge

Während der Torus für die für dichtes Training typische Nachbar-zu-Nachbar-Kommunikation hocheffizient ist, führt er bei der Kommunikation zwischen allen Chips zu einer höheren Latenz. Im Zeitalter von Reasoning-Modellen und MoE, wo jeder Chip mit jedem anderen Chip kommunizieren muss, um ein Token weiterzuleiten, ist diese Anzahl an Hops von Bedeutung.

Bei latenzempfindlichen interaktiven Diensten führen diese zusätzlichen Zwischenschritte dazu, dass die Latenz pro Token außerhalb des SLO-Bereichs liegt.

Boardfly ist eine von der Libelle inspirierte Hierarchie, die den Durchmesser dieses Netzwerks reduziert. Die Struktur besteht aus drei Ebenen. Der Grundbaustein ist ein Ring aus vier Chips mit 16 externen Verbindungen. Acht dieser Bausteine ​​bilden eine Gruppe, die vollständig über Kupferkabel mit jeweils elf Verbindungen miteinander verbunden ist. 36 Gruppen verbinden sich über optische Schaltkreise zu einem Pod. Das Ergebnis ist eine skalierbare Domäne mit 1,152 Chips (davon 1,024 aktiv) und maximal sieben Hops zwischen je zwei Chips – eine Reduzierung um 56 % gegenüber dem Torus. Google gibt an, dass dies die Latenz bei kommunikationsintensiven Anwendungen wie MoE All-to-All um bis zu 50 % verbessert.

Die größere Skalierung ist auch für die Expertenreplikation relevant. Mehr Chips pro ICI-Fabric bedeuten, dass jeder Experte in einem großen MoE mehrfach repliziert werden kann. Dies gleicht Routing-Ungleichgewichte aus und hält die Dekodierungslatenz konstant, selbst bei ungleichmäßiger Tokenverteilung. Top-k-Routing ist datenabhängig; manche Experten erhalten in einem bestimmten Schritt mehr Token als andere. Die Replikation gleicht diese Varianz aus. Die ICI-Bandbreite wurde unter anderem zur Bewältigung des entstehenden Datenverkehrs auf 19.2 Tbit/s pro Chip verdoppelt.

Jungfrau-Netzwerk

Ein Superpod mit 9,600 Chips ist groß, doch für anspruchsvolle Trainingsläufe werden zunehmend mehr Chips benötigt. Virgo ist die Scale-Out-Fabric, die Superpods innerhalb eines Rechenzentrums verbindet und den Ost-West-RDMA-Datenverkehr zwischen den Pods abwickelt, wenn ein Job die Kapazität einer einzelnen Scale-Up-Domäne übersteigt.

Ein einzelnes Virgo-Fabric verbindet über 134,000 8t-Chips mit einer nicht-blockierenden, bisektionalen Bandbreite von 47 Pb/s. Dies entspricht der bis zu vierfachen Bandbreite pro Beschleuniger und einer um 40 % geringeren Latenz im Leerlauf im Vergleich zur Vorgängergeneration. Die Architektur basiert auf einer flachen, zweischichtigen, nicht-blockierenden Topologie mit High-Radix-Switches, einem multiplanaren Design und unabhängigen Steuerdomänen.

Herkömmliche Clos-Fabrics überbuchen höhere Ebenen, um die Portanzahl und die Kosten überschaubar zu halten. Das funktioniert gut, solange der Datenverkehr überwiegend in Nord-Süd-Richtung verläuft, wie es in allgemeinen Cloud-Umgebungen üblich ist: Clients greifen auf Load Balancer zu, Load Balancer auf Anwendungsserver, Anwendungsserver auf Speicher. KI-Trainings-Workloads verlaufen jedoch fast ausschließlich in Ost-West-Richtung, Chip für Chip innerhalb des Fabrics, und die Kollektive sind von der Bisektionsmethode dominiert. Jede Überbuchung auf einer beliebigen Ebene wirkt sich direkt auf die Trainingszeit aus. Virgos flaches Zwei-Schichten-Design mit High-Radix-Switches beseitigt den Flaschenhals der Spine-Ebene, indem Switches mit genügend Ports pro ASIC ausgestattet werden, um einen relevanten Teil des Fabrics in zwei Hops zu terminieren.

Die Zuverlässigkeitstechnik ist in diesem Maßstab entscheidend und basiert maßgeblich auf Googles MEMS-basierten optischen Schaltkreisschaltern (OCS). OCS ermöglicht es Google, die physische Topologie zwischen den Jobs ohne Neuverkabelung zu rekonfigurieren und – noch wichtiger – ausgefallene Chips oder Verbindungen während des Betriebs zu umgehen. Wird ein Fehler erkannt, kann OCS den betroffenen Bereich der Infrastruktur innerhalb von Millisekunden neu zuordnen und so manuelle Eingriffe überflüssig machen. Telemetriedaten im Submillisekundenbereich ermöglichen die automatische Erkennung von Ausfällen und Hängern. Die Kombination aus schneller Erkennung und OCS-basierter Umleitung optimiert die mittlere Zeit zwischen Unterbrechungen (MTBI) und die mittlere Wiederherstellungszeit (MTTR) bei über 100,000 Chips, wo die statistische Wahrscheinlichkeit eines Ausfalls während eines mehrwöchigen Betriebs nahezu 100 % beträgt. Das von Google für 8t-Pods angegebene Ziel von 97 % Goodput basiert auf dieser Infrastruktur. Dieselbe OCS-Technologie findet sich im gesamten TPU-Stack: Sie verbindet Cubes zu Superpods auf der ICI-Ebene, vernetzt Boardfly-Gruppen auf der 8i-Scale-Up-Ebene und verarbeitet den Inter-Pod-Verkehr auf der Virgo-Ebene.

Bei 134,000 Chips erreicht die Gesamtrechenleistung rund 1,690 EFLOPS FP4 bzw. etwa 1.7 ZFLOPS. Google gibt an, dass die Architektur eine nahezu lineare Skalierung für bis zu eine Million Chips in einem einzigen logischen Trainingscluster ermöglicht, wobei die aktuellen Implementierungen diese Grenze noch nicht erreicht haben.

Jupiter und Multi-Data-Center-Skala

Virgo verarbeitet den Ost-West-Beschleunigerverkehr innerhalb eines Rechenzentrums, ist aber nicht die oberste Ebene der Infrastruktur. Jupiter ist Googles bestehende Nord-Süd-Infrastruktur, mittlerweile in der fünften Generation, die den Frontend-Verkehr und den Zugriff auf verteilte Speicher- und Rechenressourcen abwickelt. Jupiter wurde nicht auf der Cloud Next angekündigt; es ist die bestehende Infrastruktur, auf der die achte Generation aufbaut.

Die neueste Jupiter-Generation bietet 13 Pb/s bilaterale Bandbreite pro Rechenzentrumsgebäude mit einer Verfügbarkeit von 99.999 %. Sie nutzt Apollo MEMS OCS-Switches mit einem Stromverbrauch von ca. 108 W pro OCS, im Vergleich zu ca. 3,000 W bei einem gleichwertigen elektrischen Paket-Switch. Dieses Netzwerk verbindet die Google-Rechenzentren mit der Außenwelt und untereinander.

Für Trainingsläufe, die die Kapazität und den Speicherplatz eines einzelnen Rechenzentrums übersteigen, ermöglicht Jupiter die Skalierung über mehrere Standorte hinweg. Die Kombination ist mehrschichtig: ICI innerhalb eines Pods, Virgo zwischen Pods innerhalb eines Standorts und Jupiter zwischen Standorten. Googles Pathways-Software-Stack kann Workloads über diese Multi-Rechenzentrum-Domänen hinweg als einen einzigen logischen Cluster verarbeiten.

Mit rund 1.7 ZFLOPS ist ein einzelner Virgo-Fabric der größte bisher angekündigte KI-Trainingscluster. Mehrere über Jupiter verbundene Virgo-Fabrics können über eine Million TPU-Chips ansteuern – genau die Größenordnung, die Google anstrebt, auch wenn die aktuellen Implementierungen diese noch nicht erreicht haben.

Durchsatz und Auslastung

Die reine FLOP-Zahl ist weniger wichtig als der Anteil der FLOPs, der tatsächlich nutzbare Arbeit leistet. Google gibt für 8-Tonnen-Superpods ein Ziel von 97 % Nutzlast an. Das bedeutet, dass 97 % der Laufzeit für produktive Berechnungen und nicht für Wiederherstellung, Wartezeiten oder Koordinierungsaufwand aufgewendet werden. Dieser Wert hängt von der oben beschriebenen OCS-basierten Fehlertoleranz und der Telemetrie im Submillisekundenbereich ab.

Die zweite Variable ist die Modell-FLOP-Auslastung (MFU). Die MFU misst, welchen Anteil der theoretischen Spitzen-FLOPs der Chip unter realer Arbeitslast tatsächlich erreicht. SemiAnalysis schätzt, dass bei einer TPU-MFU von 40 % die Kosten pro effektivem Trainings-FLOP im Vergleich zu GB300 NVL72 um etwa 62 % sinken, wobei die Gewinnschwelle bei etwa 15 % TPU-MFU liegt. Die von Anthropic veröffentlichten TPU-Wirtschaftlichkeitsdaten deuten darauf hin, dass sie deutlich über dieser Gewinnschwelle liegen. Die Kombination aus hohem Durchsatz (konstanter Chipbetrieb) und wettbewerbsfähiger MFU (ausgelastete Chips im Betrieb) ermöglicht die Skalierbarkeit der TPU-Gesamtbetriebskosten.

Wo die 8 sitzt

Beim Vergleich der TPU 8 mit aktuellen und zukünftigen Plattformen von NVIDIA ist die Beachtung der Einheiten entscheidend. NVIDIA gibt die NVLink-Bandbreite als bidirektionale Gesamtbandbreite an; eine B200 mit 1.8 TB/s (NVLink 5: 900 GB/s pro Richtung) ist vergleichbar. Die von NVIDIA angegebenen FLOPs beziehen sich üblicherweise auf eine 2:4-Auslastung (sparse); eine dichte Auslastung entspricht der Hälfte dieses Wertes. Googles TPU-Werte hingegen sind dicht und bidirektional. Prüfen Sie daher bei jedem Vergleich, ob die Bandbreite unidirektional oder bidirektional und die FLOPs dicht oder spärlich angegeben sind.

 

Die FP4-Leistung pro Chip, 8t mit 12.6 PFLOPS (dicht) liegt zwischen den Werten von GB200 (10 PFLOPS spärlich, 5 PFLOPS dicht) und GB300 (20 PFLOPS spärlich, 15 PFLOPS dicht). Der Vergleich der Leistung pro Chip ist also ähnlich. Der Vergleich der Skalierung hingegen nicht. Ein GB300 NVL72-Rack beherbergt 72 GPUs in einer NVLink-Domäne. Ein 8t-Superpod besteht aus 9,600 Chips in einem einzigen 3D-Torus. Das sind 133-mal so viele Chips in einer einzigen Domäne – genau diese Differenz trennt die Plattformen für Spitzenreproduktionsanwendungen.

NVIDIA ruht sich nicht auf seinen Lorbeeren aus. Vera Rubin kommt im zweiten Halbjahr 2026 auf den Markt und bietet 50 PFLOPS NVFP4-Inferenz pro Package (wobei SemiAnalysis die Annahme adaptiver Komprimierung infrage stellt), 288 GB HBM4 mit 22 TB/s und NVLink 6 mit 3.6 TB/s bidirektional. Rubin Ultra, das im zweiten Halbjahr 2027 erscheint, kombiniert vier Reticle-Dies für bis zu 100 PFLOPS FP4 und 1 TB HBM4e pro Package. Kyber NVL576 integriert 576 Rubin Ultra GPUs in einem einzigen Rack mit 15 EFLOPS FP4-Inferenz. Dies verringert Googles Skalierungsvorteil, obwohl 576 GPUs immer noch um eine Größenordnung kleiner sind als ein 8-Tonnen-Superpod.

Wo 8 führt: Skalierung der Domänengröße (9,600 Chips gegenüber 72 GPUs bzw. 576 nach Kyber), Single-Fabric-Skalierung (über 134,000 Chips bei 47 Pb/s), deterministische Latenz durch statische XLA-Planung und TCO für Workloads, die zum TPU-Modell passen.

Wo 8 Spuren: HBM-Kapazität pro Chip (216 GB gegenüber Rubins 288 GB HBM4), Sparsity (NVIDIA hat einen 2:4 Hardware-Pfad, Google nicht) und Ökosystembreite (CUDA, cuDNN, TensorRT-LLM und der PyTorch-First Serving Stack landen zuerst auf NVIDIA; natives PyTorch auf TPU ist noch in der Vorschau).

Beide Plattformen sind gefragt. Meta verhandelt angeblich über einen Milliarden-Dollar-Vertrag zur Implementierung von Google TPUs in seinen Rechenzentren ab 2027, wobei die Anmietung von Cloud TPUs bereits ab 2026 möglich sein könnte. Gleichzeitig kündigte Google Cloud A5X-Instanzen auf Basis der NVIDIA Vera Rubin NVL72 an, die auf bis zu 80,000 Rubin-GPUs an einem einzelnen Standort und 960,000 GPUs in Multi-Site-Bereitstellungen skalieren. Google baut beide Plattformen massiv aus.

Einpacken

Die TPU der achten Generation besteht aus zwei Chips statt einem und ist für die heutigen Anforderungen an umfangreiches Training und agentenbasierte Inferenz optimiert, anstatt für allgemeine KI-Workloads. 8t ermöglicht eine Skalierung auf 9,600 Chips pro Superpod und eine horizontale Skalierung auf über 134,000 Chips pro Virgo Fabric. 8i ersetzt SparseCores durch kollektive Beschleunigung und den 3D-Torus durch Boardfly, um die für MoE-basierte Anwendungen erforderlichen Latenzziele zu erreichen. NVIDIAs Roadmap mit Vera Rubin, Rubin Ultra und Kyber wird einige dieser Lücken in den Jahren 2026–2027 schließen, der Skalierungsvorteil bleibt jedoch vorerst bestehen. Für Spitzenforschungslabore, die Mixture-of-Experts-Modelle auf Hunderttausenden von Chips ausführen, ist die achte Generation eine ernstzunehmende Alternative zu Grace Blackwell, und die Diskussionen bei Meta deuten darauf hin, dass der Markt dies bereits einpreist.