Googles Tensor Processing Unit verstehen

(considerthebulldog.com)

26 Punkte von GN⁺ 2025-12-15 | Noch keine Kommentare. | Auf WhatsApp teilen

Die TPU ist Googles domänenspezifischer Beschleuniger, der nur die für Deep Learning unbedingt nötigen Berechnungen beibehält und den Rest konsequent weglässt
Ausgelöst durch die Grenzen der Rechenzentrums-Skalierung im Jahr 2013 und in 12 Jahren bis zur 7. Generation „Ironwood“ weiterentwickelt
Da die Zeit vorbei ist, in der Halbleiter automatisch leistungsfähiger wurden, wurde die Strategie nicht zu warten, sondern selbst zu entwerfen zu einer zentralen Option
Eine TPU ist nicht nur ein Chip, sondern ein Co-Design-System aus Hardware, Compiler, Netzwerk und Betriebssoftware
Mit jeder Generation verschiebt sich der Schwerpunkt vom Leistungswettbewerb hin zu Stromverbrauch, Deployment und Betriebskosten (TCO)
Die Wettbewerbsfähigkeit der TPU beruht nicht auf einer einzelnen Technologie, sondern auf der Summe von mehr als zehn Jahren angesammelter Design- und Betriebserfahrung

Something New

Die TPU ist keine Geheimwaffe, sondern das Ergebnis langer öffentlicher Forschung und interner Iteration
Google entschied sich statt für den weiteren Ausbau von Rechenzentren für den Weg, die Art des Rechnens grundlegend zu verändern
Um 2013 führte der Druck, die Rechenzentrumskapazität zu verdoppeln, zusammen mit engen Zeitvorgaben zur Geburt der TPU in nur 15 Monaten
Im April 2025 stellte Google auf der Google Cloud Next die TPU Ironwood der 7. Generation vor und nannte Werte von 9.216 Chips pro Pod, 42,5 Exaflops und 10 MW
GPUs waren keine Geräte, die für Deep Learning entwickelt wurden, und die TPU wurde von Anfang an für neuronale Netzberechnungen entworfen
Diese Entscheidung brachte nicht nur bei der Rechenleistung, sondern auch bei Energieeffizienz und Betriebsstabilität strukturelle Vorteile
Das Ergebnis ist nicht „Zufall“, sondern die Akkumulation aus wiederholten Einschränkungen, Trade-offs und Co-Design

Durch die Abschwächung von Moore’s Law und Dennard Scaling reichte es früher, einfach auf eine neue CPU zu warten, damit Programme schneller wurden, aber diese Voraussetzung ist weggefallen
Die Zahl der Transistoren steigt weiter, doch Grenzen bei Stromverbrauch und Abwärme blockieren Leistungssteigerungen
Gleichzeitig verlangen neuronale Netze nach größeren Datenmengen und größeren Modellen, wodurch die Rechennachfrage explosionsartig steigt
Deshalb wurden statt „Chips, die alles ein bisschen gut können“ „Chips, die eine Sache extrem gut können“ nötig
Dass der Kern neuronaler Netzberechnungen in wiederholten matrixmultiplikationszentrierten Operationen liegt, machte ein spezialisiertes Design möglich

Die erste TPU konzentrierte sich nicht auf Training, sondern auf Inference, also die Ausführung bereits trainierter Modelle
TPUv1 entfernte Cache, Branch Prediction und Multithreading, um die Kontrollkosten zu minimieren
Stattdessen wurden alle Ressourcen auf ein Systolic Array (MXU) konzentriert, das große Matrixmultiplikationen ohne Unterbrechung verarbeitet
Statt während der Ausführung Entscheidungen zu treffen, folgt sie einfach der zur Compile-Zeit festgelegten Ausführungsreihenfolge
Dadurch konnte sie bei gleicher Leistungsaufnahme deutlich mehr Inference-Workloads als GPU oder CPU verarbeiten

Training erfordert weit mehr Rechenleistung und einen größeren Bereich numerischer Darstellung als Inference
Ab TPUv2 wurde über eine reine Inference-Struktur hinaus Flexibilität für das Training ergänzt
Die zentrale Änderung war die Aufgabentrennung zwischen Matrix (MXU), Vektor (VPU) und Steuerung (Scalar Unit)
Der Ausführungsfluss wird vom XLA-Compiler im Voraus berechnet und festgelegt, und der Chip führt ihn unverändert aus
Damit mehrere TPUs wie ein einziges Gerät arbeiten können, wurde auch ein dedizierter Hochgeschwindigkeits-Interconnect (ICI) mitentwickelt

Mit wachsender Systemgröße verlagerte sich die Frage von „Wie schnell ist es?“ zu „Wie lange und wie günstig lässt es sich betreiben?“
Dafür wurde in der Nähe der Recheneinheiten ein großer On-Chip-Speicher (CMEM) platziert, um langsame DRAM-Zugriffe zu reduzieren
Für Workloads mit vielen spärlichen Daten wie Empfehlungssysteme wurden auch dedizierte Einheiten wie SparseCore eingeführt
Durch die Trennung von Kommunikation innerhalb des Chips und zwischen Chips wurden Leitungskomplexität und Bottlenecks strukturell entschärft
Nicht Leistungskennzahlen, sondern die Betriebseffizienz bestimmt das gesamte Design

In Umgebungen mit Tausenden TPUs ist Ausfall nicht die Ausnahme, sondern die Annahme
Das Ziel ist ein System, das nicht stillsteht, also eine Struktur, die partielle Ausfälle absorbiert
Jobs werden auf mehrere TPUs verteilt ausgeführt, aber so verwaltet, dass sie wie ein einziges Programm erscheinen
Tritt ein Problem auf, wird nicht alles angehalten, sondern schnelles Re-Placement und Neustart gewählt
Dieser komplexe Prozess wird größtenteils automatisch von der Betriebssoftware verarbeitet

Wenn ein einzelner TPU-Verbund nicht mehr ausreicht, müssen mehrere Verbünde verbunden werden
Da normale Netzwerke an Grenzen stoßen, wurde optisches Switching (OCS) eingeführt
Dadurch lässt sich das gesamte Rechenzentrum wie eine einzige riesige Rechenressource aufbauen
Eine Erweiterung des bestehenden Ausführungsmodells und ein völlig neues asynchrones Ausführungsmodell (Pathways) existieren nebeneinander
So können größere Modelle und komplexere Kommunikationsmuster bewältigt werden

Aktuelle TPUs wirken nach den Kennzahlen überwältigend, doch die Kernprinzipien sind dieselben wie am Anfang
Der Fokus auf notwendige Berechnungen und das Entfernen unnötiger Komplexität bleibt bestehen
Dieses System lässt sich nicht allein durch Hardware-Spezifikationen reproduzieren
Compiler (XLA), dedizierter Interconnect (ICI), optisches Switching (OCS) und Betriebs-Scheduler müssen zusammenarbeiten
Die TPU ist keine einzelne Erfindung, sondern das Ergebnis von Hunderten gewöhnlichen Entscheidungen, die sich angesammelt haben

Systolic Array (MXU): das Herz der TPU für hocheffiziente Matrixmultiplikation
XLA-Compiler: berechnet die Ausführungsreihenfolge im Voraus und eliminiert Kontrollkosten
BF16: ein Zahlenformat, das den fürs Training nötigen Bereich beibehält und zugleich die Hardwarekosten senkt
ICI / OCS: eine dedizierte Kommunikationsstruktur, die Chip, Rack und Rechenzentrum zu einem Ganzen verbindet
TCO-zentriertes Design: eine Denkweise, die statt Spitzenleistung die langfristigen Betriebskosten optimiert