Googles Ironwood-TPU macht die Serving-Ebene zum eigentlichen Designzentrum

Ein TPU, der von der Serving-Seite aus angekündigt wird, nicht von der Trainingsseite

Ein Jahrzehnt lang hat Google seine TPUs vor allem im Kontext von Training positioniert. Ironwood wird anders beschrieben: Er ist, in Googles eigenen Worten, „der erste, der gezielt für Inferenz konzipiert wurde". Genau diese Einordnung ist die eigentliche Nachricht, nicht die Rechenleistung in FLOPs.

Es ist ein Wandel von reaktiven KI-Modellen, die Menschen Echtzeitinformationen zur Interpretation liefern, zu Modellen, die proaktiv Erkenntnisse generieren und interpretieren. Genau das meinen wir mit dem „Zeitalter der Inferenz", in dem KI-Agenten Daten proaktiv abrufen und erzeugen.Montana Labs

Die praktische Erkenntnis für alle, die an der Ebene bauen, mit der Nutzer tatsächlich interagieren: Google behandelt die laufenden Kosten des Servings – jede Anfrage, jeden Agentenschritt, jeden Retrieval-Vorgang – als die Workload, um die herum sich Chip-Design lohnt. Training ist eine einmalige Investition, Inferenz ist die Betriebskosten-Größe, die mit der Produktnutzung skaliert.

Wo 192 GB pro Chip im Produkt ankommen

Die Spezifikation, die Google für Serving betont, ist Speicher, nicht rohe Rechenleistung. Ironwood bietet 192 GB HBM-Speicher pro Chip – sechsmal so viel wie Trillium – und 7,37 TB/s Bandbreite, das 4,5-Fache des Vorgängers. Google verknüpft das direkt mit der „Verarbeitung größerer Modelle und Datensätze, wodurch häufige Datenübertragungen seltener nötig werden".

Das ist auf Anfrageebene relevant, weil die Inferenzlatenz großer Modelle oft durch das Verschieben von Gewichten und Key-Value-Caches begrenzt wird, nicht durch Arithmetik. Mehr On-Chip-Speicher und höhere Bandbreite verhindern, dass eine Anfrage mit langem Kontext oder komplexem Reasoning an der Datenbewegung ins Stocken gerät – ein Fehlerbild, das ein Produktteam als langsame erste Tokens und ruckeliges Streaming zu spüren bekommt.

Google gibt außerdem an, dass Ironwood „darauf ausgelegt ist, Datenbewegung und Latenz auf dem Chip bei der Durchführung massiver Tensor-Operationen zu minimieren". Auch hier liegt der Fokus auf Latenz – ein Serving-Thema, kein Durchsatz-Trainingsthema.

SparseCore zeigt: Es geht um Ranking, nicht nur um Chat

Ironwood verfügt über einen verbesserten SparseCore, den Google als „einen spezialisierten Beschleuniger für die Verarbeitung extrem großer Embeddings, wie sie bei fortgeschrittenen Ranking- und Empfehlungs-Workloads üblich sind" beschreibt. Das Unternehmen ergänzt, die erweiterte Unterstützung reiche „über den klassischen KI-Bereich hinaus bis in Finanz- und Wissenschaftsbereiche".

Das ist ein Signal dafür, was „Inferenz" für Google hier bedeutet. Es geht nicht nur um generatives Chatten hinter einem Textfeld, sondern um die embedding-intensive Empfehlungs- und Ranking-Maschinerie, die bereits hinter Search und Gmail in dieser Größenordnung steht. Derselbe Chip wird sowohl auf die LLM-Antwort als auch auf das dahinterliegende Retrieval ausgerichtet – genau das ist die Form der agentenbasierten Pipeline, die Google beschreibt.

Zwei Pod-Größen und Pathways bestimmen die eigentliche Wahl für Teams

Google bietet Ironwood in einer Konfiguration mit 256 Chips und einer mit 9.216 Chips an, wobei letztere 42,5 Exaflops erreicht. Diese Aufteilung in zwei Größen ist die konkrete Entscheidung, vor der Cloud-Kunden stehen: ein kleinerer Pod für begrenztes Serving oder ein vollständiger Pod für Frontier-Training und Serving dichter LLM- und MoE-Modelle.

Oberhalb eines einzelnen Pods verweist Google auf Pathways, seine von DeepMind entwickelte Laufzeitumgebung, um Hunderttausende Chips zu „orchestrieren". Die Distributed-Computing-Geschichte wird als Software-Abstraktion über der Hardware verkauft, Teil der breiteren AI-Hypercomputer-Architektur.

Der angegebene Effizienzgewinn – doppelte Leistung pro Watt gegenüber Trillium und „fast das 30-Fache" gegenüber der Cloud-TPU von 2018 – wird vor dem Hintergrund einer konkreten Einschränkung dargestellt, die Google direkt benennt: „verfügbare Energie ist einer der limitierenden Faktoren bei der Bereitstellung von KI-Fähigkeiten". Ein Pod mit fast 10 MW macht diese Einschränkung greifbar.

Die Implikation: Inferenz-Ökonomie, nicht Modellgröße, wird zur Frontend-Beschränkung

Ironwoods Positionierung zeigt Anwendungsteams, wohin sich der Druck verschiebt. Wenn Google seinen leistungsstärksten Beschleuniger um Inferenz, Speicherbandbreite und Leistung pro Watt herum baut, dann wird der limitierende Faktor beim Ausliefern von KI-Funktionen zunehmend die Kosten und Latenz des Servings in großem Maßstab – nicht die Frage, ob es ein größeres Modell gibt.

Ironwood ist noch nicht verfügbar; Google gibt an, dass er „später in diesem Jahr" kommt, und weist darauf hin, dass Gemini 2.5 und AlphaFold schon heute auf TPUs laufen. Die konkrete Handlungsempfehlung: das Serving-Budget – Tokens, Embeddings, Agentenschritte pro Nutzeraktion – als erstklassige Design-Variable zu behandeln, denn genau um diese Kennzahl herum wird die Hardware-Roadmap inzwischen gezeichnet.