Testy AgentX pokazują różne wyniki dla TPUv7

5 listopada 2026 r. SemiAnalysis opisał cztery zgłoszenia Google TPUv7, znanego jako Ironwood, w teście AgentX. Wyniki zależą od modelu, precyzji obliczeń, oprogramowania i mierzonego etapu obsługi. Raport nie wskazuje jednego układu, który wygrywałby w każdym z tych porównań.

Wynik inferencji mówi najwięcej wtedy, gdy wiadomo, jaki model, ustawienia i etap obsługi żądania zmierzono.

Co mierzy AgentX

AgentX sprawdza obsługę długich kontekstów i wieloetapowych, wieloturowych sesji. W opisywanym obciążeniu pojawiają się ponownie wykorzystywane fragmenty kontekstu oraz skokowe uruchamianie podagentów. To ważne dla zadań agentowych, ale samo w sobie nie opisuje wydajności w każdym zastosowaniu inferencji.

Wyniki kosztowe wyrażone jako liczba tokenów na dolara zestawiają przepustowość z kosztem obsługi. „Decode”, czyli dekodowanie, to etap generowania kolejnych tokenów odpowiedzi. Pomiar end-to-end obejmuje obsługę całego żądania, a nie tylko dekodowanie. Dlatego dwa testy tego samego modelu mogą dać różne porównania.

Cztery modele, różne wyniki TPUv7

W zgłoszeniu Muse Spark Open wykorzystano stos SGLang-TorchTPU i wagi NVFP4. Według SemiAnalysis TPUv7 osiągał konkurencyjną efektywność kosztową dekodowania przy założonym koszcie TPU po stronie Meta, ale opóźnienie end-to-end wymagało dalszej optymalizacji, między innymi jąder prefill. Raport wiązał też długokontekstową uwagę modelu z wykorzystaniem 64-elementowych głowic uwagi i wypełnianiem 25% macierzy systolicznej TPU.

Dla GLM-5.2 w formacie FP8 SemiAnalysis podał od 1,2 do 2,7 raza więcej tokenów na dolara na TPUv7 niż na B200, B300 i MI355X przy docelowej przepustowości od 60 do 300 tokenów na sekundę na użytkownika. Przy 150 tokenach na sekundę na użytkownika raportował wynik 4,4 raza wyższy niż dla H200. To porównanie dotyczy wskazanych ustawień GLM-5.2 FP8, a nie surowej szybkości układów w dowolnym zadaniu.

Osobny wynik dla GLM-5.3 dotyczył obliczeń FP4 przy 100 tokenach na sekundę na użytkownika: GB300 FP4 i GB200 FP4 osiągnęły odpowiednio 3,6 i 3,5 raza więcej tokenów na dolara niż TPUv7. SemiAnalysis wiązał tę przewagę między innymi z brakiem natywnej obsługi FP4 przez TPUv7. Format FP4 używa mniejszej precyzji niż FP8, więc takie zestawienie obejmuje również różnicę w formacie wag.

W pierwszym opisanym porównaniu Qwen3.5 397B konfiguracja TPUv7 FP8 z vLLM osiągnęła, według SemiAnalysis, 1,67 raza lepszy stosunek wydajności do kosztu niż GB300 NVL72 FP4. Późniejsze zgłoszenie NVIDIA wygrywało pod względem dekodowania, ale TPUv7 pozostawał z przodu w pomiarze end-to-end. W konfiguracji llm-d każdy wynik wykorzystywał od 24 do 32 układów TPUv7, po cztery na host. Przy najszybszym badanym punkcie 90. percentyl czasu do pierwszego tokenu wynosił 8,6 sekundy dla TPUv7 i 11,1 sekundy dla GB300 FP4.

Porównanie Kimi K3 pokazuje, jak zmiana zgłoszenia może zmienić rezultat. W zestawieniu z okresu premiery TPUv7 osiągał od 0,77 do 0,91 wyniku GB300 pod względem liczby tokenów na dolara przy przepustowości od 50 do 200 tokenów na sekundę na użytkownika. W teście jednego użytkownika raport podawał odpowiednio 391 i 251 tokenów na sekundę na użytkownika dla TPUv7 i GB300. Po czterech aktualizacjach NVIDIA GB300 FP4 prowadził, według SemiAnalysis, od 1,5 do 2,6 raza. W odrębnym późniejszym zestawieniu TPUv7 osiągał od 1,15 do 2,5 raza więcej tokenów na dolara niż GB200, B200 i B300.

Przykłady inferencji Ironwood w Google Cloud

Google Cloud wymienia przykłady wdrożenia inferencji na Ironwood: obsługę GPT OSS-120B z vLLM w klastrach GKE oraz Qwen3-Coder-480B z vLLM. Biblioteka zawiera też przykłady inferencji z PyTorch i TorchTPU. To ścieżki demonstracyjne do pracy z oprogramowaniem i modelami, nie wyniki pomiarów wydajności. Przykłady Google Cloud dla TPU pokazują, od jakich konfiguracji można zacząć własną ocenę wybranego obciążenia.