Google TPUv7: AgentX-Ergebnisse hängen von Modell und Messgröße ab

Am 5. November 2026 veröffentlichte SemiAnalysis einen Bericht über vier TPUv7-Einreichungen für den AgentX-Inferenzbenchmark. Die Resultate für Muse Spark Open, GLM-5.2 und GLM-5.3, Qwen3.5 397B sowie Kimi K3 hängen vom Modell, der numerischen Präzision, der Serving-Software und der gemessenen Leistungsgröße ab. Eine allgemeine Rangfolge für alle Inferenzaufgaben ergibt sich daraus nicht.

Ein Benchmarkwert wird erst aussagekräftig, wenn Modell, Präzision, Serving-Setup und Messpunkt dazustehen.

Was AgentX bei den TPUv7-Tests abbildet

AgentX bildet laut SemiAnalysis lange, mehrstufige Gespräche mit wiederverwendeten Kontextteilen und Aktivität mehrerer Unteragenten ab. Das unterscheidet den Benchmark von einer einzelnen Frage an einen Chatbot: Er bewertet eine bestimmte Art von agentischer Inferenz, nicht jede Aufgabe, die ein Sprachmodell erledigen kann.

Die Kennzahl Tokens pro Dollar setzt die erzeugte Tokenmenge ins Verhältnis zu den angesetzten Kosten. Sie ist weder eine reine Geschwindigkeitsangabe noch eine Aussage über einen Endkundenpreis. Auch die Zahl der Tokens pro Sekunde und Nutzer beschreibt zunächst den Durchsatz unter den jeweils angegebenen Testbedingungen.

Vier Modelle, unterschiedliche Ergebnisse

Muse Spark Open

RadixArk reichte Muse Spark Open mit SGLang-TorchTPU und NVFP4-Gewichten ein. SemiAnalysis beschreibt die TPUv7-Ergebnisse beim Decode, also beim schrittweisen Erzeugen der Antwort, als wettbewerbsfähig pro Dollar, gerechnet mit Metas angegebenem TPU-Kostenansatz. Für die End-to-End-Latenz, die auch die Verarbeitung der Eingabe vor der Antwort umfasst, sah der Bericht weiteren Optimierungsbedarf, insbesondere bei den Prefill-Kernels.

GLM-5.2 und GLM-5.3

Für GLM-5.2 mit FP8-Gewichten berichtet SemiAnalysis bei 60 bis 300 Tokens pro Sekunde und Nutzer 1,2- bis 2,7-mal so viele Tokens pro Dollar wie bei B200, B300 und MI355X. Bei 150 Tokens pro Sekunde und Nutzer lag der berichtete TPUv7-Wert beim 4,4-Fachen des H200-Werts.

Beim GLM-5.3-Vergleich mit FP4 lagen GB300 und GB200 am Betriebspunkt von 100 Tokens pro Sekunde und Nutzer laut Bericht beim Verhältnis Tokens pro Dollar um den Faktor 3,6 beziehungsweise 3,5 vor TPUv7. SemiAnalysis führt den Unterschied unter anderem darauf zurück, dass TPUv7 FP4 nicht nativ unterstützt; zudem ist ein FP4-Vergleich mit einem Qualitätskompromiss verbunden. FP8 und FP4 bezeichnen unterschiedliche Formate für die Genauigkeit der Modellgewichte.

Qwen3.5 397B

Für Qwen3.5 397B meldet SemiAnalysis zunächst bei TPUv7 mit vLLM und FP8 einen Vorteil von 1,67 zu 1 bei der Leistung pro Dollar gegenüber GB300 NVL72 mit FP4. In einer späteren NVIDIA-Einreichung lag der Decode-Durchsatz dem Bericht zufolge vorn, während TPUv7 bei der End-to-End-Leistung im beschriebenen Setup besser abschnitt. Das sind verschiedene Messpunkte: Der schnellere Antwortaufbau allein legt nicht fest, welches System die gesamte Anfrage schneller verarbeitet.

Für den llm-d-Aufbau nennt der Bericht 24 bis 32 TPUv7-Chips je Ergebnis, vier Chips pro Host. Am jeweils schnellsten getesteten Punkt betrug die p90-Zeit bis zum ersten Token 8,6 Sekunden bei TPUv7 und 11,1 Sekunden bei GB300 FP4. p90 bedeutet, dass 90 Prozent der gemessenen Anfragen diesen Wert nicht überschritten. Mit cache-bewusstem Routing stieg die berichtete Trefferquote für wiederverwendbare Inhalte von 56 auf 76 Prozent.

Kimi K3

Beim Startvergleich mit GB300 lag TPUv7 laut SemiAnalysis zwischen 0,77 und 0,91 bei Tokens pro Dollar, über den Bereich von 50 bis 200 Tokens pro Sekunde und Nutzer. Im Einzelbenutzertest war der berichtete Durchsatz dagegen höher: 391 Tokens pro Sekunde und Nutzer auf TPUv7 gegenüber 251 auf GB300. Geschwindigkeit und Kostenverhältnis können also unterschiedliche Rangfolgen ergeben.

Nach vier Aktualisierungen der NVIDIA-Einreichung lag GB300 mit FP4 in einer späteren Auswertung beim Verhältnis Tokens pro Dollar um den Faktor 1,5 bis 2,6 vor TPUv7. Eine separate spätere Vergleichsreihe setzte TPUv7 bei dieser Kennzahl um den Faktor 1,15 bis 2,5 vor GB200, B200 und B300. Die Werte beziehen sich auf unterschiedliche Systeme und Einreichungsstände.

Welche Ironwood-Beispiele Google Cloud dokumentiert

Google Cloud listet in seiner Sammlung von Cloud-TPU-Beispielen vLLM-Serving-Beispiele für GPT OSS-120B auf Ironwood-GKE-Clustern und für Qwen3-Coder-480B auf Ironwood. Daneben führt Google Cloud Inferenzbeispiele mit PyTorch und TorchTPU auf. Die Beispiele benennen konkrete Software- und Modellpfade für Ironwood; die Benchmarkzahlen oben stammen aus den jeweils beschriebenen AgentX-Konfigurationen.