Google TPU-Inferenz fordert Nvidias Kostenvorsprung mit Ironwood heraus

Google TPU inference hat eine neue Phase erreicht: Ironwood liefert Berichten zufolge in ausgewählten Tests bis zu 50 % bessere Leistung pro Dollar als Nvidia B200. Das Ergebnis stammt aus einer offiziellen Vorschau von InferenceX, einem Benchmarking-Projekt eines Drittanbieters unter Leitung von SemiAnalysis. Es stellt die Annahme infrage, dass wettbewerbsfähige TPU-Ökonomie nur innerhalb von Google existiert.

Diese Einschränkung ist wichtig. SemiAnalysis testete einen neu für externe Nutzer bereitgestellten TPU-Serving-Stack unter spezifischen Bedingungen bei Modell, Präzision, Durchsatz und Latenz gegen Nvidia-Beschleuniger. Ironwood gewann nicht jeden Vergleich, und seiner Software fehlen weiterhin mehrere Optimierungen, die in ausgereiften GPU-Deployments verfügbar sind.

Der tieferliegende Wettbewerb ist daher nicht ein Benchmark gegen den anderen. Es geht um Googles Versuch, sein vertikal integriertes TPU-System für Kunden nutzbar zu machen, die an Nvidias CUDA-Softwareumgebung gewöhnt sind. Gelingt Google dies, erhalten Käufer eine glaubwürdige Alternative für Inferenz im großen Maßstab, ohne darauf warten zu müssen, dass sich allein die Hardwarelücke schließt.

Google TPU-Inferenz verlässt Googles Mauern

Die entscheidende Veränderung besteht darin, dass Außenstehende Google TPU inference nun über einen vertrauteren Serving-Workflow für offene Modelle bewerten können.

Google betreibt TPUs seit mehr als einem Jahrzehnt in der Produktion. Die internen Dienste des Unternehmens verschafften ihm ungewöhnlich viel Kontrolle über Beschleunigerdesign, Compiler, Netzwerke, Modelle und Deployment-Software. Diese Kontrolle machte TPUs innerhalb von Google effektiv, schuf jedoch nicht automatisch eine zugängliche Plattform für externe Entwickler.

Ironwood verändert einen Teil dieser Gleichung. Google stellte die TPU der siebten Generation im April 2025 als erste speziell für Inferenz entwickelte TPU vor. Inferenz bezeichnet den Prozess, bei dem ein trainiertes Modell eine Antwort, ein Bild, eine Vorhersage oder eine Aktion erzeugt.

Später machte Google Ironwood über Google Cloud allgemein verfügbar. Die Details zur Einführung von Ironwood beschreiben Konfigurationen mit bis zu 9.216 Chips und 42,5 Exaflops pro Pod. Google behauptete zudem eine nahezu 30-mal bessere Energieeffizienz als bei seiner ersten Cloud TPU aus dem Jahr 2018.

Diese Spezifikationen belegten die Größenordnung der Hardware. Sie beantworteten jedoch nicht, ob ein externes Team Open-Weight-Modelle effizient bedienen kann, ohne sich auf Googles private Produktionsumgebung zu stützen.

Die neuen InferenceX-Ergebnisse befassen sich mit dieser schwierigeren Frage. SemiAnalysis zufolge verwendet die Vorschau TorchTPU, einen externen Software-Stack, der PyTorch-orientierte Modell-Workflows mit Google TPUs verbinden soll. Dazu gehört auch Arbeit rund um SGLang, eine Open-Source-Serving-Engine für die Inferenz großer Sprachmodelle.

Diese Kombination ist wichtig, weil die meisten KI-Entwickler einen Beschleuniger nicht anhand seiner Spitzenrechenleistung auswählen. Sie bewerten, wie viel Engineering-Aufwand zwischen einem Modell-Checkpoint und einem stabilen Produktionsservice liegt.

Die Vorschau des Drittanbieter-Benchmarks berichtet, dass Ironwood Nvidia B200 und B300 in Teilen des getesteten Betriebsbereichs bei der Leistung pro Dollar übertraf. Bei einem Zielwert von 100 generierten Tokens pro Sekunde und Nutzer berechnete SemiAnalysis einen Kostenvorteil von rund 19 % gegenüber B200. Gegenüber B300 soll der Vorteil bei etwa 34 % gelegen haben.

Bei einem langsameren Ziel von 20 Tokens pro Sekunde erzeugte Ironwood im berichteten Test 9.364 Tokens pro Sekunde und Chip. B200 erreichte 8.903, während B300 auf 8.925 kam. Das entsprach in diesem speziellen Durchlauf einem rund 5 % höheren Rohdurchsatz für Ironwood.

Niedrigere modellierte Hardwarekosten vergrößerten den berechneten Vorteil. SemiAnalysis berichtete an einem Punkt hoher Gleichzeitigkeit von 50,4 % mehr Tokens pro Dollar als bei B200. Gegenüber B300 meldete das Unternehmen am selben Punkt einen deutlich größeren Vorsprung.

Dies sind Benchmark-Ergebnisse, keine universellen Ranglisten. Sie repräsentieren ausgewählte Modelle und Konfigurationen, die auf einem noch in Entwicklung befindlichen Stack laufen. Dennoch verschieben sie die TPU-Diskussion von architektonischem Potenzial hin zu extern beobachtbarer Wirtschaftlichkeit.

Dieser Übergang schafft die zentrale Spannung. Google muss nicht länger nur zeigen, dass seine eigenen Teams Wert aus TPUs ziehen können. Es muss beweisen, dass Kunden genug dieses Werts mit vertretbarem Aufwand, akzeptabler Latenz, Zuverlässigkeit und Modellabdeckung reproduzieren können.

Das Kostenergebnis setzt Nvidias Standardposition unter Druck

Ein glaubwürdiger TPU-Kostenvorteil setzt Nvidia unter Druck, weil Käufer von Inferenzsystemen erledigte Arbeit kaufen, keine Spitzen-Chipspezifikationen.

Große KI-Dienste müssen enorme Mengen an Eingabe- und Ausgabe-Tokens verarbeiten. Kleine Unterschiede bei Auslastung, Latenz und Energieverbrauch summieren sich über dauerhafte Workloads hinweg. Daher ist Leistung pro Dollar beim Vergleich von Produktionssystemen nützlicher als reiner Durchsatz.

Die Kennzahl braucht dennoch Kontext. Ein System kann den Gesamtdurchsatz durch das Bündeln weiterer Anfragen erhöhen, doch größere Batches lassen einzelne Nutzer oft länger warten. Niedrigere Kosten pro Token bedeuten wenig, wenn der Dienst sein Ziel bei der Antwortzeit verfehlt.

SemiAnalysis legte diesen Zielkonflikt in seinen Messungen mit hoher Gleichzeitigkeit offen. Bei einer Gleichzeitigkeit von 256 verzeichnete Ironwood eine durchschnittliche Zeit bis zum ersten Token von 5,41 Sekunden. B200 erreichte 3,75 Sekunden, B300 2,40 Sekunden.

Die Zeit bis zum ersten Token misst, wie lange ein Nutzer wartet, bevor das Modell seine Antwort zu generieren beginnt. Sie ist besonders wichtig für Chat-Oberflächen, Coding-Assistenten, Sprachsysteme und interaktive Agenten.

Die Latenzlücke relativiert jede Behauptung, Ironwood schlage Blackwell schlichtweg. Ironwoods stärkstes Kostenergebnis zeigte sich an einem Betriebspunkt, an dem Nvidia das erste Token schneller lieferte. Unterschiedliche Kunden werden diesen Tausch unterschiedlich bewerten.

Ein Offline-Dienst zur Dokumentenverarbeitung kann längere Wartezeiten akzeptieren, wenn er dafür deutlich höheren Durchsatz gewinnt. Ein auf Reaktionsgeschwindigkeit konkurrierender Consumer-Chatbot könnte ein schnelleres erstes Token bevorzugen, selbst wenn jede abgeschlossene Anfrage mehr kostet.

Lang laufende Agenten erzeugen ein weiteres Workload-Muster. Sie lesen wiederholt Kontext, rufen Tools auf, aktualisieren ihren Zustand und generieren kurze Antworten. Ihre Infrastrukturbedürfnisse unterscheiden sich von einem einzelnen Prompt mit anschließender langer Antwort.

Diese Unterschiede erklären, warum InferenceX statt eines einzelnen Schlagzeilen-Scores eine Pareto-Kurve präsentiert. Eine Pareto-Kurve zeigt die besten verfügbaren Kombinationen aus Kosten und Latenz, ohne vorzutäuschen, dass ein Betriebspunkt für jede Anwendung geeignet ist.

Ironwood blieb Berichten zufolge über große Teile dieser Kurve konkurrenzfähig. Bei einer medianen End-to-End-Antwortzeit von 20 Sekunden schätzte SemiAnalysis einen Kostenvorteil von 8 % gegenüber B200 und von 25 % gegenüber B300.

Allerdings lag B200 in einem kleineren Abschnitt der überlappenden Kurve vorn. Nvidia behielt zudem wichtige Vorteile, wenn Modelle FP4-Berechnungen mit niedrigerer Präzision nutzten.

FP4 speichert numerische Werte als Gleitkommadarstellungen mit vier Bit. Dies kann den Durchsatz erhöhen und den Speicherverbrauch senken, obwohl aggressive Quantisierung auch die Modellqualität beeinträchtigen kann. Laut Benchmark-Analyse verfügt Ironwood über keine native FP4-Berechnung.

SemiAnalysis verglich die Systeme für seine am engsten abgestimmten Tests primär mit FP8 und Single-Token-Prediction. Es merkte an, dass Nvidias FP4-Pfad führen kann, wenn Kunden dessen Kompromisse bei Qualität und Implementierung akzeptieren.

Damit ist der Druck auf Nvidia enger gefasst als eine direkte Ersatzgeschichte. Google fordert Nvidias wirtschaftliche Standardposition für einige Inferenz-Workloads heraus, insbesondere dort, wo stabile Modellformen spezialisierte Hardware begünstigen.

Nvidia bietet weiterhin breite Workload-Abdeckung, weit verbreitete Bibliotheken, erfahrene Betreiber und etablierte Debugging-Tools. Diese Ressourcen verringern das Integrationsrisiko auf eine Weise, die in Token-Durchsatzdiagrammen nicht sichtbar wird.

Der unmittelbare Druck trifft Nvidias Preisgestaltung und Produktsegmentierung. Wenn Kunden vorhersehbare Inferenz-Workloads auf Ironwood verlagern können, muss Nvidia Blackwell durch bessere Auslastung, niedrigere Latenz, breitere Präzisionsoptionen oder einfacheres Deployment verteidigen.

Auch Google steht unter Druck. Das Unternehmen muss aus einer vielversprechenden Vorschau reproduzierbare Kundenergebnisse machen. Andernfalls werden Käufer den Benchmark als optimierte Demonstration und nicht als Beschaffungsalternative betrachten.

Warum Googles externer TPU-Stack wichtiger ist als ein einzelner Benchmark

Der eigentliche Mechanismus ist die Externalisierung der Software, denn wettbewerbsfähige Hardware kann die CUDA-Abhängigkeit nicht reduzieren, wenn Kunden Schwierigkeiten haben, ihre Modelle bereitzustellen.

CUDA ist Nvidias Programmierplattform und Sammlung beschleunigter Bibliotheken für GPU-Computing. Ihre Bedeutung reicht über die Sprache zum Schreiben von Kernels hinaus. CUDA verbindet Treiber, Compiler, Kommunikationsbibliotheken, Profiler, Inferenz-Engines, Modelloptimierer und jahrelanges Entwicklerwissen.

Dieses vernetzte System senkt das operative Risiko. Ein Team, das auf ein GPU-Performanceproblem stößt, kann auf umfangreiche Dokumentation, vertraute Tools, Herstellersupport und eine große Engineering-Community zurückgreifen. Es kann Deployment-Muster oft über verschiedene Nvidia-Generationen hinweg wiederverwenden.

Google optimierte TPUs historisch über interne Tools und Teams. JAX wurde zum sichtbarsten öffentlichen Programmierweg, während sich viele externe KI-Projekte um PyTorch und CUDA standardisierten.

TorchTPU versucht, diese Lücke zu verkleinern. Es bietet PyTorch-orientierten Entwicklern einen Weg zur TPU-Ausführung und unterstützt zugleich vertraute Modell- und Serving-Schichten. Je stärker sich diese Erfahrung bestehenden Workflows annähert, desto geringer werden Googles Wechselkosten.

SGLang bildet eine weitere Brücke. Es verwaltet Aufgaben des Model Serving wie Anfrageplanung, Speichernutzung, Batching und verteilte Ausführung. Die Unterstützung einer wiedererkennbaren Inferenz-Engine ermöglicht Google Wettbewerb oberhalb der Chip-Ebene.

Das bedeutet nicht, dass das Softwareproblem gelöst ist. SemiAnalysis identifizierte noch offene Arbeiten bei spekulativem Decoding, disaggregiertem Serving, Key-Value-Cache-Offloading und Multi-Turn-Agent-Workloads.

Spekulatives Decoding verwendet ein kleineres oder schnelleres Modell, um Tokens vorzuschlagen, die ein größeres Modell überprüft. Bei guter Umsetzung erhöht dies die Generierungsgeschwindigkeit, ohne die erwartete Ausgabeverteilung des finalen Modells zu verändern.

Disaggregiertes Serving trennt Prompt-Verarbeitung von der Token-Generierung. Diese Phasen stellen unterschiedliche Anforderungen an Rechenleistung, Speicher und Netzwerk, sodass spezialisierte Ressourcenpools die Auslastung verbessern können.

Key-Value-Cache-Offloading verschiebt gespeicherte Attention-Daten bei Bedarf aus dem Beschleunigerspeicher. Es kann die effektive Kapazität für lange Kontexte oder viele gleichzeitige Sessions erweitern, doch Datenbewegungen können Latenz verursachen.

Diese Fähigkeiten sind in führenden GPU-Deployments wichtig geworden. Googles private Infrastruktur nutzt Berichten zufolge einige vergleichbare Techniken, doch sein externer TPU-Stack stellt noch nicht jeden optimierten Pfad bereit.

Diese Lücke erklärt einen aufschlussreichen Vergleich im Benchmark-Bericht. SemiAnalysis stellte fest, dass ein Nvidia GB300 NVL72-System mit disaggregiertem Serving in einem Teil des Latenzbereichs einen Vorteil bei der Leistung pro Dollar von rund 30 % behielt. Der TPU-Vergleich nutzte aggregiertes Serving, weil dessen externer disaggregierter Pfad noch nicht vollständig optimiert war.

Dies war kein sauberer Architekturvergleich. Er zeigte jedoch, wie stark Produktionssoftware das Ergebnis beeinflussen kann. Die Hardwareführerschaft verschiebt sich, wenn ein System eine ausgereiftere Strategie für Planung und Serving erhält.

Nvidia baut auch seine Inferenzschicht weiter aus. Das Unternehmen veröffentlichte im März 2026 Dynamo 1.0 als Open-Source-Software für verteilte generative und agentische Inferenz. Dynamo koordiniert Vorgänge wie Request-Routing, Speicherverwaltung und disaggregiertes Serving.

Nvidia steuerte zudem TensorRT-LLM-CUDA-Kernels zum Open-Source-Projekt FlashInfer bei. Diese Strategie bringt Nvidia-optimierte Komponenten in Frameworks ein, die Entwickler bereits nutzen.

Google kann den CUDA-Burggraben daher nicht durch das Erreichen eines statischen Ziels verringern. Es muss sich weiterentwickeln, während Nvidia Teile seines Stacks weiterhin öffnet und seine Systeme im Rack-Maßstab optimiert.

Das vielversprechende Element für Google ist die Fähigkeit, Hardware- und Softwareentwicklung zu koordinieren. TPU-Ingenieure können Compiler, Kernels, Interconnects und Serving-Systeme auf dieselben architektonischen Annahmen ausrichten.

Die Einschränkung liegt in der Modellvielfalt. Ein spezialisiertes Array funktioniert am besten, wenn Modelldimensionen und Operationen zu seiner Geometrie passen. Modelle, die rund um GPUs entwickelt und abgestimmt wurden, können für die TPU-Ausführung ineffiziente Strukturen erzeugen.

SemiAnalysis hob dieses Problem anhand von Attention-Dimensionen und Mixture-of-Experts-Routing hervor. Ein populäres Modell kann weiterhin erhebliche Kernel-Arbeit erfordern, bevor es Ironwood effizient nutzt.

Die Externalisierung hängt daher von einer wachsenden Kompatibilitätsmatrix ab, nicht von einem einzigen erfolgreichen Port. Käufer benötigen die Gewissheit, dass neue Modellfamilien zeitnah optimiert werden, ohne direkten Zugang zu Googles Performance-Ingenieuren zu benötigen.

Ironwood gewinnt ausgewählte Tests, doch die Verifikationslücke bleibt

Der berichtete Vorteil ist bedeutsam, doch sein Umfang bleibt zu eng, um eine allgemeine Führungsposition von Google TPU bei der Inferenz zu belegen.

InferenceX beschreibt seine Ergebnisse als die ersten Inferenzmessungen Dritter für Ironwood. Das verleiht der Arbeit mehr Unabhängigkeit als ein Benchmark, der ausschließlich von Google veröffentlicht wurde. SemiAnalysis schreibt jedoch auch Google-Ingenieuren und anderen beteiligten Teams zu, beim Aufbau und der Optimierung des getesteten Stacks geholfen zu haben.

Zusammenarbeit ist bei frühem Hardware-Benchmarking normal. Sie kann die erreichbare Leistung eines Systems genauer offenlegen als eine nicht unterstützte Installation. Sie macht das Ergebnis zugleich eher zu einer abgestimmten Referenzimplementierung als zu einer durchschnittlichen Kundenbereitstellung.

Die Vorschau konzentrierte sich zunächst auf einen 8k1k-Workload. Diese Notation beschreibt üblicherweise die Verarbeitung einer Eingabe mit 8.000 Tokens und die Generierung von 1.000 Output-Tokens. Sie steht für einen umfangreichen Prompt gefolgt von einer aussagekräftigen Antwort, deckt jedoch nicht jedes moderne Inferenzmuster ab.

Coding Agents können Repositories über viele Durchläufe hinweg wiederverwenden und erweitern. Research Agents können lange Retrieval-Eingaben mit kurzen Tool-Aufrufen abwechseln. Sprach-Anwendungen priorisieren kontinuierlich niedrige Latenz, während Batch-Zusammenfassungen den Gesamtdurchsatz priorisieren.

Ein einzelner Workload kann diese Unterschiede nicht abbilden. Käufer benötigen Ergebnisse über Prompt-Längen, Output-Längen, Parallelitätsstufen, Modellarchitekturen, Quantisierungsformate und Service-Level-Ziele hinweg.

Auch die Modellqualität gehört in den Vergleich. FP4 kann den Nvidia-Durchsatz verbessern, doch eine Konfiguration mit geringerer Präzision sollte anhand von Aufgabenpräzision und Ausgabekonsistenz bewertet werden. Ein Geschwindigkeitsergebnis ist unvollständig, wenn Präzisionsänderungen ein anderes Modellverhalten erzeugen.

Die Kostenmethodik stellt eine weitere Unsicherheit dar. SemiAnalysis verwendete modellierte Gesamtbetriebskosten für extern erworbene Systeme statt ausschließlich öffentlicher Cloud-Mietpreise. Solche Modelle hängen von Annahmen zu Anschaffung, Auslastung, Strom, Networking, Finanzierung und Nutzungsdauer ab.

Googles interne Kostenstruktur unterscheidet sich von der Kostenstruktur seiner Kunden. Der Bericht schätzte einen größeren TPU-Vorteil bei Anwendung von Googles internen Kostenannahmen. Externe Käufer können nicht davon ausgehen, dieselbe Kostenstruktur zu erhalten.

Auch die Verfügbarkeit kann die Rechnung erheblich verändern. Ein technisch effizienter Beschleuniger bietet nur begrenzten Nutzen, wenn Kunden in den von ihnen genutzten Regionen nicht genügend Kapazität erhalten können. Nvidia steht ebenfalls vor Lieferengpässen, doch seine Systeme bleiben über viele Cloud-Anbieter und Serverpartner verfügbar.

Googles aktueller TPU-Katalog führt Ironwood als allgemein verfügbar auf. Er präsentiert zudem TPU 8i als kommende, auf Inferenz ausgerichtete Generation. Tatsächliche Kapazität, Kaufoptionen, Support-Vereinbarungen und geografischer Zugang können weiterhin je nach Kunde variieren.

Portabilität ist ein weiterer Kostenfaktor, den Benchmarks selten erfassen. Ein Unternehmen, das sich auf TPU-spezifische Optimierungen standardisiert, kann bessere Wirtschaftlichkeit erzielen und zugleich stärker von Google Cloud oder ausgewählten Systemlieferanten abhängig werden.

CUDA schafft Lock-in, doch der Wechsel weg von CUDA beseitigt Lock-in nicht automatisch. Er kann einen integrierten Stack gegen einen anderen austauschen. Offene Frameworks verringern dieses Risiko nur, wenn sich Verhalten und Leistung vorhersehbar zwischen Backends übertragen lassen.

Betriebliche Nachweise werden ebenso wichtig sein wie eine weitere Benchmark-Kurve. Kunden benötigen Fehlerwiederherstellung, Observability, Autoscaling, Sicherheitskontrollen, Versionsmanagement und vorhersehbare Upgrades.

Sie benötigen zudem Ingenieure, die Performance-Regressionen diagnostizieren können. Eine Plattform mit niedrigeren Token-Kosten kann teuer werden, wenn Spezialisten wiederholt Kernels umschreiben oder Compiler-Verhalten untersuchen müssen.

Aus diesem Grund sollte das InferenceX-Ergebnis als Beleg für Wettbewerbsfähigkeit unter ausgewählten Bedingungen gelesen werden. Es ist kein Beweis dafür, dass Ironwood zum besten Beschleuniger für jedes Modell oder jede Organisation geworden ist.

Diese Unterscheidung schmälert die Bedeutung der Nachricht nicht. Frühere TPU-Debatten endeten oft bei der Frage, ob Googles private Vorteile die eigene Umgebung verlassen könnten. Die Vorschau zeigt, dass zumindest ein Teil des Stacks nun extern testbare, wirtschaftlich wettbewerbsfähige Inferenz unterstützen kann.

Die Beweislast hat sich verschoben. Google muss die getestete Fläche erweitern, während Nvidia zeigen muss, dass seine Software- und Latenzvorteile seine Position über Workloads hinweg rechtfertigen, bei denen Ironwood die Kosten senkt.

TPU 8i erweitert die Herausforderung über Ironwood hinaus

Ironwood schafft einen glaubwürdigen externen Weg, während TPU 8i mehrere durch den aktuellen Vergleich offengelegte Grenzen angehen soll.

Google kündigte seine achte TPU-Generation im April 2026 mit separaten Designs für Training und Inferenz an. TPU 8t richtet sich an Training im großen Maßstab, während TPU 8i auf Post-Training, Reinforcement Learning und Inferenz fokussiert.

Diese Aufteilung spiegelt wider, wie sich die Nachfrage nach KI-Infrastruktur verändert hat. Training benötigt dichte Rechenleistung über enorme Cluster hinweg. Inferenz muss Speicherkapazität, Latenz, Durchsatz, Energie und sich schnell verändernde Request-Muster ausbalancieren.

Google zufolge wird TPU 8i bei Inferenz mit niedriger Latenz auf großen Mixture-of-Experts-Modellen eine um 80 % bessere Performance pro Dollar als Ironwood bieten. Mixture-of-Experts-Modelle aktivieren für jedes Token nur ausgewählte Parametergruppen, was den Rechenaufwand reduziert, aber Routing- und Kommunikationsanforderungen schafft.

Das Unternehmen sagt zudem, TPU 8i unterstütze native FP4-Berechnungen. Das adressiert direkt einen Bereich, in dem Nvidia in den Ironwood-Vergleichen einen Vorteil behielt.

Googles Roadmap der achten Generation erklärt, dass TPU 8i und TPU 8t bis zu doppelte Performance pro Watt gegenüber Ironwood liefern. Beide wurden für einen späteren Zeitpunkt im Jahr 2026 angekündigt.

Dies bleiben Unternehmensangaben, bis unabhängige Tests sie bestätigen. Der entscheidende Punkt ist die Richtung der Architektur. Google behandelt Inferenz nicht länger als sekundären Einsatzzweck für Hardware, die hauptsächlich auf Training ausgelegt ist.

TPU 8i erhöht zudem die Bedeutung der derzeit stattfindenden externen Softwarearbeit. Ein neuer Beschleuniger ohne nutzbaren Serving-Stack würde das Adoptionsproblem neu beginnen lassen. Eine reifende TorchTPU-Umgebung kann Modellunterstützung und betriebliches Wissen in die nächste Generation übertragen.

SemiAnalysis erwartet, dass TPU 8i direkter mit Nvidias Rubin-NVL72-Plattform konkurriert. Dieser Vergleich wird von mehr als nur nativer FP4-Unterstützung abhängen.

Nvidias Rubin-Systeme kombinieren GPUs, CPUs, Networking, Speicher und Inferenzsoftware im Rack-Maßstab. Nvidia hat seine Roadmap zudem auf Reasoning-Modelle und agentische Workloads ausgerichtet, bei denen wiederholte Inferenz den gesamten Token-Bedarf steigert.

Google führt ein ähnliches Argument auf Systemebene an. Es entwickelt TPU-Rechenleistung, Chip-übergreifende Kommunikation, optisches Networking, Compiler und Cloud-Orchestrierung gemeinsam.

Der Wettbewerb wird zunehmend zu System gegen System. Kein Anbieter kann dauerhafte Produktions-Workloads allein durch die Spezifikation eines einzelnen Beschleunigers gewinnen.

Amazon, AMD und weitere Custom-Silicon-Programme erhöhen den Druck zusätzlich. Ihre Existenz verschafft großen Käufern mehr Verhandlungsmacht, selbst wenn diese Käufer Nvidia weiterhin für viele Workloads nutzen.

Google nimmt dennoch eine besondere Position ein. Das Unternehmen verfügt über jahrelange Erfahrung mit TPU-Produktion, bedeutende interne Workloads, eine öffentliche Cloud, Entwicklung von Frontier-Modellen und eine klare Beschleuniger-Roadmap.

Diese Kombination erlaubt Google, Optimierungen auf umfangreichen internen Diensten zu testen, bevor sie Kunden zugänglich gemacht werden. Es kann zudem Gemini-Modelle rund um TPU-Eigenschaften gestalten.

Externe Akzeptanz erfordert die entgegengesetzte Bewegung. Google muss populäre Modelle optimieren, die es nicht selbst entwickelt hat, einschließlich Architekturen, deren Dimensionen Jahre GPU-orientierter Forschung widerspiegeln.

Hier wird der CUDA-Burggraben weniger absolut, bleibt jedoch erheblich. High-Level-Frameworks können Hardwareunterschiede bei der grundlegenden Ausführung verbergen. Sie können nicht automatisch jeden Unterschied bei Kernels, Networking, Scheduling und Speicherverwaltung beseitigen.

KI-gestützte Codegenerierung kann einige Portierungsarbeiten beschleunigen. Sie kann die Validierung hinsichtlich Präzision, Stabilität und Produktionsfehlermodi nicht ersetzen.

TPU 8i wird Googles Herausforderung stärken, wenn es mit breiter Modellunterstützung und ausgereiftem disaggregiertem Serving erscheint. Die Erzählung wird geschwächt, wenn seine beste Wirtschaftlichkeit von privilegierter Engineering-Unterstützung oder engen Benchmark-Konfigurationen abhängt.

Drei Signale werden entscheiden, ob die TPU-Externalisierung funktioniert

Die nächsten Nachweise müssen Wiederholbarkeit, Workload-Breite und Kundenakzeptanz zeigen, statt eines weiteren isolierten Spitzenergebnisses.

Das erste Signal ist ein abgestimmter Benchmark für disaggregiertes Serving. SemiAnalysis sagt, der aktuelle externe TPU-Pfad benötige in diesem Bereich noch Optimierung, obwohl Google intern verwandte Techniken einsetzt.

Ein sinnvoller Folgetest würde Ironwood- und Nvidia-Systeme mit auf beiden Seiten aktivierter Disaggregation vergleichen. Er sollte dasselbe Modell, dieselbe Präzision, dasselbe Qualitätsziel, dieselbe Latenzvorgabe und dieselbe Kostenmethodik verwenden.

Wenn Ironwood die berichtete Lücke zu GB300 NVL72 schließt, wird Googles Argument auf Systemebene stärker. Bleibt die Lücke bestehen, bleibt Nvidias ausgereifte Serving-Software ein entscheidender Vorteil.

Das zweite Signal ist die Leistung über mehrturnige agentische Workloads hinweg. Diese Systeme verarbeiten wiederholt wachsenden Kontext, rufen Tools auf und erzeugen kurze Ausgaben. Sie belasten Cache-Verwaltung und Latenz anders als ein 8k1k-Benchmark.

SemiAnalysis erklärt, dass es später im Jahr 2026 Ergebnisse für agentische Workloads veröffentlichen will. Diese Tests sollten Zeit bis zum ersten Token, Inter-Token-Latenz, Durchsatz, Speichernutzung und Kosten pro abgeschlossener Aufgabe ausweisen.

Starke Ergebnisse würden zeigen, dass Google-TPU-Inferenz das Nachfragemuster bewältigen kann, das die aktuelle Infrastrukturplanung antreibt. Schwache Ergebnisse würden darauf hindeuten, dass sich Ironwoods Vorteil auf besser vorhersehbare Serving-Jobs konzentriert.

Das dritte Signal sind externe Kundennachweise. Allgemeine Verfügbarkeit ist wichtig, doch wiederholte Bereitstellungen zeigen, ob Entwickler Benchmark-Wirtschaftlichkeit ohne ungewöhnlich intensive Unterstützung reproduzieren können.

Die stärksten Nachweise würden namentlich genannte Produktions-Workloads, unterstützte offene Modelle, Kapazitätserweiterungen und gemessene Zuverlässigkeit umfassen. Käufer sollten zudem beobachten, wie schnell neue Modelle optimierte TPU-Kernels erhalten.

Google führt bereits Kundenbeispiele rund um Ironwood an, darunter schnellere Workloads bei Citadel Securities. Eine breitere Akzeptanz im Inference-Bereich würde zeigen, dass die Externalisierung von TPUs über Spezialistenteams und große strategische Partner hinausgeht.

Nvidias Reaktion gehört in dasselbe Beobachtungsfenster. Verbesserungen bei Dynamo, TensorRT-LLM, Blackwell und Rubin können den Vergleich verändern, bevor die TPU-Software ausgereift ist.

Ein Kostenvorteil ist nicht dauerhaft, wenn beide Plattformen Hardware und Serving-Software schnell weiterentwickeln. Käufer sollten reproduzierbare Betriebspunkte bewerten, statt einen einzelnen Benchmark als feste Rangfolge zu behandeln.

Die praktische Lehre lautet, die Eignung für den jeweiligen Workload von der Anbieteridentität zu trennen. Stabile Inference-Workloads mit hohem Volumen können jetzt eine TPU-Evaluierung rechtfertigen. Latenzkritische Dienste, sich schnell verändernde Modelle oder Teams mit tiefen CUDA-Investitionen könnten weiterhin Nvidia bevorzugen.

Infrastrukturteams sollten ihre Benchmark-Annahmen und Deployment-Erkenntnisse als lebendige Aufzeichnungen bewahren. Eine durchsuchbare technische Wissensdatenbank kann Teams dabei helfen, Ergebnisse zu vergleichen, während sich Modelle, Compiler und Accelerator-Generationen verändern.

Google hat eine wichtige Schwelle überschritten, indem es seine TPU-Ökonomie extern überprüfbar gemacht hat. Damit hat das Unternehmen weder Nvidias Softwarevorteil beseitigt noch eine universelle Führungsposition etabliert.

Die nächste Frage ist konkret: Können gewöhnliche Kunden die Google-TPU-Inference-Gewinne in realen Anwendungen reproduzieren, bevor Nvidias nächstes System sie verringert? Die Antwort wird darüber entscheiden, ob InferenceX einen dauerhaften Marktumschwung oder einen beeindruckenden frühen Meilenstein markiert.