Inferencja Google TPU właśnie podważyła przewagę kosztową Nvidia dzięki Ironwood

Inferencja Google TPU weszła w nową fazę: według doniesień Ironwood zapewnia w wybranych testach nawet o 50% lepszą wydajność w przeliczeniu na dolara niż Nvidia B200. Wynik pochodzi z oficjalnej zapowiedzi InferenceX, niezależnego projektu benchmarkingowego prowadzonego przez SemiAnalysis. Podważa on założenie, że konkurencyjna ekonomika TPU istnieje wyłącznie wewnątrz Google.

To zastrzeżenie ma znaczenie. SemiAnalysis testowało nowo udostępniony zewnętrznie stos obsługi TPU względem akceleratorów Nvidia w określonych warunkach dotyczących modeli, precyzji, przepustowości i opóźnień. Ironwood nie wygrał każdego porównania, a jego oprogramowaniu nadal brakuje kilku optymalizacji dostępnych w dojrzałych wdrożeniach GPU.

Głębsza rywalizacja nie dotyczy więc jednego benchmarku przeciwko drugiemu. Chodzi o próbę Google, by uczynić swój pionowo zintegrowany system TPU użytecznym dla klientów przyzwyczajonych do środowiska programowego CUDA od Nvidia. Jeśli Google odniesie sukces, kupujący zyskają wiarygodną alternatywę dla inferencji na dużą skalę, bez konieczności czekania wyłącznie na zamknięcie luki sprzętowej.

Inferencja Google TPU wychodzi poza mury Google

Najważniejsza zmiana polega na tym, że podmioty zewnętrzne mogą teraz oceniać inferencję Google TPU poprzez bardziej znajomy przepływ obsługi otwartych modeli.

Google wykorzystuje TPU produkcyjnie od ponad dekady. Wewnętrzne usługi firmy zapewniły jej wyjątkową kontrolę nad projektowaniem akceleratorów, kompilatorami, sieciami, modelami i oprogramowaniem wdrożeniowym. Ta kontrola sprawiła, że TPU były skuteczne wewnątrz Google, lecz nie stworzyła automatycznie dostępnej platformy dla zewnętrznych deweloperów.

Ironwood zmienia część tego równania. Google przedstawiło TPU siódmej generacji w kwietniu 2025 roku jako pierwsze TPU zaprojektowane specjalnie do inferencji. Inferencja to proces uruchamiania wytrenowanego modelu w celu wygenerowania odpowiedzi, obrazu, prognozy lub działania.

Google później udostępniło Ironwood powszechnie za pośrednictwem Google Cloud. Jego szczegóły premiery Ironwood opisują konfiguracje obejmujące 9 216 układów i 42,5 eksaflopsa na pod. Google twierdziło również, że efektywność energetyczna jest niemal 30 razy lepsza niż w przypadku pierwszego Cloud TPU z 2018 roku.

Te specyfikacje określały skalę sprzętu. Nie odpowiadały jednak na pytanie, czy zewnętrzny zespół może efektywnie obsługiwać modele o otwartych wagach bez polegania na prywatnym środowisku produkcyjnym Google.

Nowe wyniki InferenceX dotyczą właśnie tego trudniejszego pytania. SemiAnalysis informuje, że zapowiedź wykorzystuje TorchTPU — zewnętrzny stos programowy zaprojektowany, by połączyć przepływy pracy modeli zorientowane na PyTorch z Google TPU. Obejmuje także prace wokół SGLang, silnika obsługi open source wykorzystywanego do inferencji dużych modeli językowych.

To połączenie ma znaczenie, ponieważ większość twórców AI nie wybiera akceleratora po przeczytaniu jego specyfikacji szczytowej mocy obliczeniowej. Ocenią oni, ile pracy inżynieryjnej dzieli punkt kontrolny modelu od stabilnej usługi produkcyjnej.

Zapowiedź niezależnego benchmarku wskazuje, że Ironwood przewyższył Nvidia B200 i B300 pod względem wydajności na dolara w części badanego zakresu operacyjnego. Przy celu 100 generowanych tokenów na sekundę na użytkownika SemiAnalysis obliczyło przewagę kosztową wynoszącą około 19% względem B200. Raportowana przewaga sięgnęła około 34% względem B300.

Przy wolniejszym celu 20 tokenów na sekundę Ironwood osiągnął w raportowanym teście 9 364 tokeny łącznie na sekundę na układ. B200 osiągnął 8 903, a B300 8 925. Oznaczało to około 5% wyższą surową przepustowość Ironwood w tym konkretnym uruchomieniu.

Niższe modelowane koszty sprzętu zwiększyły obliczoną przewagę. SemiAnalysis podało, że w jednym punkcie wysokiej współbieżności Ironwood zapewnił o 50,4% więcej tokenów na dolara niż B200. W tym samym punkcie raportowano znacznie większą przewagę nad B300.

Są to wyniki benchmarków, a nie uniwersalne rankingi. Reprezentują wybrane modele i konfiguracje działające na stosie, który nadal jest rozwijany. Mimo to przesuwają rozmowę o TPU z potencjału architektonicznego w stronę zewnętrznie obserwowalnej ekonomiki.

Ta zmiana tworzy główne napięcie. Google nie musi już jedynie wykazywać, że jego własne zespoły potrafią czerpać wartość z TPU. Musi pokazać, że klienci mogą odtworzyć wystarczającą część tej wartości przy akceptowalnym nakładzie pracy, opóźnieniach, niezawodności i obsłudze modeli.

Wynik kosztowy wywiera presję na domyślną pozycję Nvidia

Wiarygodna przewaga kosztowa TPU wywiera presję na Nvidia, ponieważ nabywcy inferencji kupują wykonaną pracę, a nie szczytowe specyfikacje układów.

Duże usługi AI muszą przetwarzać ogromne liczby tokenów wejściowych i wyjściowych. Niewielkie różnice w wykorzystaniu zasobów, opóźnieniach i zużyciu energii kumulują się w przypadku stałych obciążeń. Dlatego wydajność w przeliczeniu na dolara jest bardziej użyteczna niż surowa przepustowość przy porównywaniu systemów produkcyjnych.

Ta metryka nadal wymaga kontekstu. System może zwiększyć całkowitą przepustowość, grupując więcej żądań w partie, lecz większe partie często wydłużają czas oczekiwania pojedynczych użytkowników. Niższy koszt na token ma mniejsze znaczenie, jeśli usługa nie realizuje celu dotyczącego czasu odpowiedzi.

SemiAnalysis ujawniło ten kompromis w pomiarach przy wysokiej współbieżności. Przy współbieżności 256 Ironwood odnotował średni czas do pierwszego tokenu wynoszący 5,41 sekundy. B200 osiągnął 3,75 sekundy, a B300 2,40 sekundy.

Czas do pierwszego tokenu mierzy, jak długo użytkownik czeka, zanim model zacznie generować odpowiedź. Jest szczególnie ważny dla interfejsów czatowych, asystentów programistycznych, systemów głosowych i interaktywnych agentów.

Różnica w opóźnieniach komplikuje wszelkie twierdzenia, że Ironwood po prostu pokonuje Blackwell. Najlepszy wynik kosztowy Ironwood pojawił się w punkcie pracy, w którym Nvidia szybciej dostarczała pierwszy token. Różni klienci będą inaczej oceniać tę wymianę.

Usługa przetwarzania dokumentów offline może zaakceptować dłuższe oczekiwanie, jeśli zyskuje znaczną przepustowość. Chatbot konsumencki rywalizujący responsywnością może preferować szybszy pierwszy token, nawet jeśli każde zrealizowane żądanie kosztuje więcej.

Długotrwale działający agenci tworzą kolejny wzorzec obciążenia. Wielokrotnie odczytują kontekst, wywołują narzędzia, aktualizują stan i generują krótkie odpowiedzi. Ich potrzeby infrastrukturalne różnią się od pojedynczego promptu, po którym następuje długa odpowiedź.

Te rozróżnienia wyjaśniają, dlaczego InferenceX prezentuje krzywą Pareto zamiast jednego nagłówkowego wyniku. Krzywa Pareto pokazuje najlepsze dostępne kombinacje kosztu i opóźnienia, nie udając, że jeden punkt pracy odpowiada każdej aplikacji.

Według doniesień Ironwood pozostawał konkurencyjny na znacznej części tej krzywej. Przy medianie pełnego czasu odpowiedzi wynoszącej 20 sekund SemiAnalysis oszacowało przewagę kosztową 8% nad B200 i 25% nad B300.

Jednak B200 wysunął się na prowadzenie w mniejszej części nakładającej się krzywej. Nvidia zachowała również istotne przewagi, gdy modele wykorzystywały obliczenia FP4 o niższej precyzji.

FP4 przechowuje wartości liczbowe przy użyciu czterobitowych reprezentacji zmiennoprzecinkowych. Może zwiększać przepustowość i ograniczać zużycie pamięci, chociaż agresywna kwantyzacja może także wpływać na jakość modelu. Według analizy benchmarku Ironwood nie obsługuje natywnie obliczeń FP4.

SemiAnalysis porównało systemy przede wszystkim przy użyciu FP8 i predykcji pojedynczego tokenu w najbliżej dopasowanych testach. Zauważyło, że ścieżka FP4 Nvidia może prowadzić, gdy klienci akceptują związane z nią kompromisy jakościowe i implementacyjne.

To sprawia, że presja na Nvidia jest węższa niż historia o bezpośrednim zastąpieniu. Google kwestionuje ekonomiczną domyślną pozycję Nvidia dla części obciążeń inferencyjnych, zwłaszcza tam, gdzie stabilne kształty modeli sprzyjają wyspecjalizowanemu sprzętowi.

Nvidia nadal oferuje szerokie pokrycie obciążeń, powszechnie wdrożone biblioteki, doświadczonych operatorów i ugruntowane narzędzia do debugowania. Te atuty redukują ryzyko integracji w sposób niewidoczny na wykresach przepustowości tokenów.

Bezpośrednia presja dotyczy cen i segmentacji produktów Nvidia. Jeśli klienci będą mogli przenosić przewidywalne obciążenia inferencyjne do Ironwood, Nvidia będzie musiała bronić Blackwell lepszym wykorzystaniem zasobów, niższymi opóźnieniami, szerszym wyborem precyzji lub prostszym wdrożeniem.

Google również stoi pod presją. Musi przekształcić obiecującą zapowiedź w powtarzalne wyniki dla klientów. W przeciwnym razie kupujący uznają benchmark za zoptymalizowaną demonstrację, a nie alternatywę zakupową.

Dlaczego zewnętrzny stos TPU Google ma większe znaczenie niż jeden benchmark

Rzeczywistym mechanizmem jest uzewnętrznienie oprogramowania, ponieważ konkurencyjny sprzęt nie może zmniejszyć zależności od CUDA, gdy klienci mają trudności z wdrożeniem swoich modeli.

CUDA to platforma programistyczna Nvidia i zbiór przyspieszonych bibliotek do obliczeń GPU. Jej znaczenie wykracza poza język używany do pisania kerneli. CUDA łączy sterowniki, kompilatory, biblioteki komunikacyjne, profilery, silniki inferencyjne, optymalizatory modeli i lata wiedzy deweloperskiej.

Ten połączony system obniża ryzyko operacyjne. Zespół napotykający problem z wydajnością GPU może korzystać z obszernej dokumentacji, znajomych narzędzi, wsparcia dostawcy i dużej społeczności inżynieryjnej. Często może też ponownie wykorzystać wzorce wdrożeniowe między różnymi generacjami Nvidia.

Google historycznie optymalizowało TPU za pomocą wewnętrznych narzędzi i zespołów. JAX stał się najbardziej widoczną publiczną ścieżką programowania, podczas gdy wiele zewnętrznych projektów AI ustandaryzowało się wokół PyTorch i CUDA.

TorchTPU próbuje zmniejszyć tę różnicę. Daje deweloperom zorientowanym na PyTorch drogę do wykonywania zadań na TPU, obsługując jednocześnie znajome warstwy modeli i obsługi. Im bardziej to doświadczenie zbliża się do istniejących przepływów pracy, tym niższy staje się koszt zmiany po stronie Google.

SGLang zapewnia kolejny pomost. Zarządza zadaniami obsługi modeli, takimi jak harmonogramowanie żądań, wykorzystanie pamięci, grupowanie w partie i wykonanie rozproszone. Obsługa rozpoznawalnego silnika inferencyjnego pozwala Google konkurować powyżej poziomu układu.

Nie oznacza to, że problem oprogramowania został rozwiązany. SemiAnalysis wskazało niedokończone prace dotyczące spekulacyjnego dekodowania, rozdzielonej obsługi, odciążania pamięci podręcznej klucz-wartość oraz obciążeń wieloturowych agentów.

Spekulacyjne dekodowanie wykorzystuje mniejszy lub szybszy model do proponowania tokenów, które następnie weryfikuje większy model. Przy dobrym wdrożeniu zwiększa szybkość generowania bez zmiany oczekiwanego rozkładu wyników końcowego modelu.

Rozdzielona obsługa oddziela przetwarzanie promptu od generowania tokenów. Fazy te stawiają odmienne wymagania wobec mocy obliczeniowej, pamięci i sieci, dlatego wyspecjalizowane pule zasobów mogą poprawić wykorzystanie.

Odciążanie pamięci podręcznej klucz-wartość przenosi zapisane dane uwagi poza pamięć akceleratora, gdy jest to właściwe. Może zwiększyć efektywną pojemność dla długich kontekstów lub wielu równoczesnych sesji, lecz przemieszczanie danych może wprowadzać opóźnienia.

Te możliwości stały się ważne w czołowych wdrożeniach GPU. Prywatna infrastruktura Google według doniesień wykorzystuje pewne porównywalne techniki, lecz jej zewnętrzny stos TPU nie udostępnia jeszcze każdej zoptymalizowanej ścieżki.

Ta luka wyjaśnia znaczące porównanie w raporcie benchmarkowym. SemiAnalysis stwierdziło, że system Nvidia GB300 NVL72 wykorzystujący rozdzieloną obsługę zachował około 30% przewagi w wydajności na dolara w części zakresu opóźnień. Porównanie TPU wykorzystywało obsługę zagregowaną, ponieważ jego zewnętrzna rozdzielona ścieżka nie była w pełni zoptymalizowana.

Nie było to czyste porównanie architektur. Pokazało jednak, jak bardzo oprogramowanie produkcyjne może wpływać na wynik. Przewaga sprzętowa zmienia się, gdy jeden system otrzymuje dojrzalszą strategię harmonogramowania i obsługi.

Nvidia rozszerza również swoją warstwę inferencyjną. W marcu 2026 roku firma udostępniła Dynamo 1.0 jako oprogramowanie open source do rozproszonego generatywnego i agentowego wnioskowania. Dynamo koordynuje operacje takie jak kierowanie żądań, zarządzanie pamięcią i rozdzielona obsługa modeli.

Nvidia przekazała również jądra CUDA TensorRT-LLM do projektu open source FlashInfer. Strategia ta umieszcza komponenty zoptymalizowane dla Nvidia we frameworkach, z których programiści już korzystają.

Google nie może zatem zmniejszyć przewagi CUDA przez dorównanie statycznemu celowi. Musi się rozwijać, podczas gdy Nvidia nadal otwiera część swojego stosu i optymalizuje systemy w skali szafy rackowej.

Obiecującym elementem dla Google jest zdolność do koordynowania rozwoju sprzętu i oprogramowania. Inżynierowie TPU mogą kształtować kompilatory, jądra, interkonekty i systemy obsługi modeli wokół tych samych założeń architektonicznych.

Ograniczeniem jest różnorodność modeli. Wyspecjalizowana macierz działa najlepiej, gdy wymiary i operacje modelu są zgodne z jej geometrią. Modele projektowane i dostrajane pod GPU mogą tworzyć nieefektywne struktury dla wykonywania na TPU.

SemiAnalysis zwróciło uwagę na ten problem w kontekście wymiarów mechanizmu attention oraz routingu mixture-of-experts. Popularny model może nadal wymagać znacznej pracy nad jądrami, zanim będzie efektywnie wykorzystywać Ironwood.

Eksternalizacja zależy więc od rosnącej macierzy kompatybilności, a nie od jednego udanego portowania. Kupujący potrzebują pewności, że nowe rodziny modeli będą szybko optymalizowane bez konieczności bezpośredniego dostępu do inżynierów Google zajmujących się wydajnością.

Ironwood Wygrywa Wybrane Testy, Ale Luka Weryfikacyjna Pozostaje

Raportowana przewaga jest istotna, lecz jej zakres wciąż jest zbyt wąski, by potwierdzić ogólną przewagę Google TPU w inferencji.

InferenceX opisuje swoje wyniki jako pierwsze zewnętrzne pomiary inferencji dla Ironwood. Nadaje to pracy większą niezależność niż benchmark opublikowany wyłącznie przez Google. SemiAnalysis zaznacza jednak również, że inżynierowie Google i inne uczestniczące zespoły pomagali budować i optymalizować testowany stos.

Współpraca jest normalna przy benchmarkach wczesnego sprzętu. Może ujawnić osiągalną wydajność systemu dokładniej niż instalacja bez wsparcia. Sprawia też, że wynik jest bliższy dostrojonej implementacji referencyjnej niż przeciętnemu wdrożeniu klienta.

Podgląd koncentrował się początkowo na obciążeniu 8k1k. To oznaczenie zazwyczaj opisuje przetworzenie wejścia o długości 8 000 tokenów i wygenerowanie 1 000 tokenów wyjściowych. Reprezentuje znaczący prompt, po którym następuje istotna odpowiedź, ale nie obejmuje każdego współczesnego wzorca inferencji.

Agenci programistyczni mogą wielokrotnie wykorzystywać i rozbudowywać repozytoria w wielu turach. Agenci badawczy mogą przeplatać długie wejścia pobierane z wyszukiwania krótkimi wywołaniami narzędzi. Aplikacje głosowe priorytetowo traktują ciągłe niskie opóźnienia, podczas gdy podsumowywanie wsadowe stawia na całkowitą przepustowość.

Jedno obciążenie nie może odzwierciedlać tych różnic. Kupujący potrzebują wyników dla różnych długości promptów, długości odpowiedzi, poziomów współbieżności, architektur modeli, formatów kwantyzacji i celów SLA.

Jakość modelu również powinna być uwzględniona w porównaniu. FP4 może poprawiać przepustowość Nvidia, ale konfigurację o niższej precyzji należy oceniać pod kątem dokładności zadań i spójności wyników. Rezultat dotyczący szybkości jest niepełny, jeśli zmiany precyzji prowadzą do odmiennego zachowania modelu.

Metodologia kosztowa stanowi kolejną niewiadomą. SemiAnalysis wykorzystało modelowany całkowity koszt posiadania dla systemów kupowanych zewnętrznie, zamiast opierać się wyłącznie na publicznych stawkach wynajmu w chmurze. Takie modele zależą od założeń dotyczących zakupu, wykorzystania, energii, sieci, finansowania i okresu użytkowania.

Wewnętrzna ekonomika Google różni się od ekonomiki klientów. Raport oszacował większą przewagę TPU przy zastosowaniu wewnętrznych założeń kosztowych Google. Zewnętrzni nabywcy nie mogą zakładać, że otrzymają tę samą strukturę kosztów.

Dostępność może dodatkowo zmienić kalkulację. Technicznie wydajny akcelerator ma ograniczoną wartość, jeśli klienci nie mogą uzyskać wystarczającej mocy w regionach, z których korzystają. Nvidia również mierzy się z ograniczeniami podaży, ale jej systemy pozostają dostępne za pośrednictwem wielu dostawców chmurowych i partnerów serwerowych.

Aktualny katalog TPU Google wymienia Ironwood jako rozwiązanie ogólnie dostępne. Przedstawia również TPU 8i jako nadchodzącą generację skoncentrowaną na inferencji. Rzeczywista dostępność mocy, opcje zakupu, warunki wsparcia i dostęp geograficzny mogą jednak różnić się zależnie od klienta.

Przenośność to kolejny koszt, którego benchmarki rzadko uwzględniają. Firma standaryzująca optymalizacje specyficzne dla TPU może uzyskać lepszą ekonomikę, ale jednocześnie stać się bardziej zależna od Google Cloud lub wybranych dostawców systemów.

CUDA tworzy uzależnienie od dostawcy, lecz odejście od CUDA nie eliminuje go automatycznie. Może jedynie zamienić jeden zintegrowany stos na inny. Otwarte frameworki zmniejszają to ryzyko tylko wtedy, gdy zachowanie i wydajność można przewidywalnie przenosić między backendami.

Dowody operacyjne będą miały równie duże znaczenie jak kolejna krzywa benchmarkowa. Klienci potrzebują mechanizmów odzyskiwania po awarii, obserwowalności, automatycznego skalowania, kontroli bezpieczeństwa, zarządzania wersjami i przewidywalnych aktualizacji.

Potrzebują także inżynierów zdolnych diagnozować regresje wydajności. Platforma o niższym koszcie tokenów może stać się kosztowna, jeśli specjaliści muszą wielokrotnie przepisywać jądra lub analizować zachowanie kompilatora.

Z tego powodu wynik InferenceX należy odczytywać jako dowód konkurencyjności w wybranych warunkach. Nie jest to dowód, że Ironwood stał się najlepszym akceleratorem dla każdego modelu lub organizacji.

To rozróżnienie nie umniejsza znaczenia wiadomości. Wcześniejsze dyskusje o TPU często kończyły się na pytaniu, czy prywatne przewagi Google mogą wyjść poza jego własne środowisko. Podgląd pokazuje, że przynajmniej część stosu może teraz wspierać zewnętrznie testowalną, ekonomicznie konkurencyjną inferencję.

Ciężar dowodu się przesunął. Google musi rozszerzać zakres testów, podczas gdy Nvidia musi pokazać, że jej przewagi w oprogramowaniu i opóźnieniach uzasadniają jej pozycję w obciążeniach, w których Ironwood obniża koszty.

TPU 8i Rozszerza Wyzwanie Poza Ironwood

Ironwood ustanawia wiarygodną ścieżkę zewnętrzną, podczas gdy TPU 8i zaprojektowano z myślą o rozwiązaniu kilku ograniczeń ujawnionych przez obecne porównanie.

Google ogłosiło ósmą generację TPU w kwietniu 2026 roku, z oddzielnymi projektami dla trenowania i inferencji. TPU 8t jest przeznaczony do trenowania na dużą skalę, a TPU 8i koncentruje się na etapie po trenowaniu, uczeniu ze wzmocnieniem i inferencji.

Ten podział odzwierciedla zmianę popytu na infrastrukturę AI. Trenowanie wymaga intensywnych obliczeń w ogromnych klastrach. Inferencja musi równoważyć pojemność pamięci, opóźnienia, przepustowość, zużycie energii i szybko zmieniające się wzorce żądań.

Google twierdzi, że TPU 8i zapewni o 80% lepszy stosunek wydajności do ceny niż Ironwood w inferencji niskoopóźnieniowej dla dużych modeli mixture-of-experts. Modele mixture-of-experts aktywują dla każdego tokenu tylko wybrane grupy parametrów, zmniejszając zapotrzebowanie obliczeniowe, ale tworząc wymagania dotyczące routingu i komunikacji.

Firma twierdzi również, że TPU 8i obsługuje natywne obliczenia FP4. Bezpośrednio odnosi się to do obszaru, w którym Nvidia zachowała przewagę w porównaniach Ironwood.

Mapa drogowa ósmej generacji Google stwierdza, że TPU 8i i TPU 8t zapewniają do dwukrotnie wyższą wydajność na wat niż Ironwood. Oba rozwiązania zapowiedziano na późniejszą część 2026 roku.

Pozostają to deklaracje firmy, dopóki niezależne testy ich nie potwierdzą. Istotny jest kierunek architektury. Google nie traktuje już inferencji jako drugorzędnego zastosowania sprzętu projektowanego głównie do trenowania.

TPU 8i zwiększa również znaczenie zewnętrznych prac nad oprogramowaniem, które toczą się obecnie. Nowy akcelerator bez użytecznego stosu obsługi modeli ponownie rozpocząłby problem adopcji. Dojrzewające środowisko TorchTPU może przenieść obsługę modeli i wiedzę operacyjną do następnej generacji.

SemiAnalysis oczekuje, że TPU 8i będzie konkurować bardziej bezpośrednio z platformą Rubin NVL72 firmy Nvidia. To porównanie będzie zależeć od czegoś więcej niż natywnej obsługi FP4.

Systemy Rubin firmy Nvidia łączą GPU, CPU, sieć, pamięć i oprogramowanie inferencyjne w skali szafy rackowej. Nvidia zoptymalizowała także swoją mapę drogową pod modele rozumowania i obciążenia agentowe, w których powtarzana inferencja zwiększa całkowity popyt na tokeny.

Google przedstawia podobny argument na poziomie całego systemu. Współprojektuje obliczenia TPU, komunikację między układami, sieci optyczne, kompilatory i orkiestrację chmurową.

Rywalizacja coraz bardziej staje się starciem systemu z systemem. Żaden dostawca nie może zdobyć trwałych obciążeń produkcyjnych wyłącznie dzięki specyfikacji samodzielnego akceleratora.

Amazon, AMD i inne programy własnego krzemu wywierają dodatkową presję. Ich istnienie daje dużym nabywcom większą siłę negocjacyjną, nawet jeśli nadal używają Nvidia do wielu obciążeń.

Google zajmuje jednak odrębną pozycję. Ma lata doświadczenia w produkcyjnym wykorzystaniu TPU, znaczące obciążenia wewnętrzne, publiczną chmurę, rozwój modeli frontierowych oraz jasną mapę drogową akceleratorów.

To połączenie pozwala Google testować optymalizacje w znaczących usługach wewnętrznych przed udostępnieniem ich klientom. Może też kształtować modele Gemini wokół charakterystyki TPU.

Adopcja zewnętrzna wymaga ruchu w przeciwnym kierunku. Google musi optymalizować popularne modele, których nie projektowało, w tym architektury, których wymiary odzwierciedlają lata badań zorientowanych na GPU.

W tym miejscu fosa CUDA staje się mniej absolutna, ale nadal pozostaje znacząca. Frameworki wysokiego poziomu mogą ukrywać różnice sprzętowe podczas podstawowego wykonywania. Nie potrafią automatycznie wyeliminować każdej różnicy w jądrach, sieci, harmonogramowaniu i zarządzaniu pamięcią.

Generowanie kodu wspomagane przez AI może przyspieszyć część prac nad portowaniem. Nie zastąpi jednak walidacji pod kątem dokładności, stabilności i produkcyjnych trybów awarii.

TPU 8i wzmocni wyzwanie Google, jeśli trafi na rynek z szeroką obsługą modeli i dojrzałą rozdzieloną obsługą modeli. Osłabi tę narrację, jeśli jego najlepsza ekonomika będzie zależeć od uprzywilejowanej pomocy inżynierskiej lub wąskich konfiguracji benchmarkowych.

Trzy Sygnały Zadecydują, Czy Eksternalizacja TPU Zadziała

Kolejne dowody muszą pokazać powtarzalność, szeroki zakres obciążeń i adopcję przez klientów, a nie kolejny odizolowany wynik szczytowy.

Pierwszym sygnałem jest dopasowany benchmark rozdzielonej obsługi modeli. SemiAnalysis twierdzi, że obecna zewnętrzna ścieżka TPU nadal wymaga optymalizacji w tym obszarze, mimo że Google wykorzystuje pokrewne techniki wewnętrznie.

Użyteczne kolejne porównanie zestawiłoby systemy Ironwood i Nvidia z włączoną dezagregacją po obu stronach. Powinno wykorzystywać ten sam model, precyzję, cel jakościowy, ograniczenie opóźnień i metodologię kosztową.

Jeśli Ironwood zmniejszy raportowaną lukę wobec GB300 NVL72, argument Google na poziomie systemowym stanie się silniejszy. Jeśli luka się utrzyma, dojrzałe oprogramowanie Nvidia do obsługi modeli pozostanie decydującą przewagą.

Drugim sygnałem jest wydajność w wieloturowych obciążeniach agentowych. Systemy te wielokrotnie przetwarzają rosnący kontekst, wywołują narzędzia i generują krótkie odpowiedzi. Inaczej niż benchmark 8k1k obciążają one zarządzanie pamięcią podręczną i opóźnienia.

SemiAnalysis twierdzi, że planuje opublikować wyniki dla obciążeń agentowych później w 2026 roku. Testy te powinny raportować czas do pierwszego tokenu, opóźnienie między tokenami, przepustowość, wykorzystanie pamięci i koszt ukończonego zadania.

Silne wyniki pokazałyby, że inferencja Google TPU może obsłużyć wzorzec popytu napędzający obecne planowanie infrastruktury. Słabe wyniki sugerowałyby, że przewaga Ironwood koncentruje się w bardziej przewidywalnych zadaniach obsługi modeli.

Trzecim sygnałem są dowody od zewnętrznych klientów. Ogólna dostępność ma znaczenie, lecz powtarzalne wdrożenia pokazują, czy programiści mogą odtworzyć ekonomikę benchmarków bez nietypowo intensywnego wsparcia.

Najmocniejsze dowody obejmowałyby nazwane obciążenia produkcyjne, wspierane otwarte modele, rozszerzanie dostępnej mocy oraz mierzoną niezawodność. Kupujący powinni również obserwować, jak szybko nowe modele otrzymują zoptymalizowane jądra TPU.

Google już prezentuje przykłady klientów korzystających z Ironwood, w tym szybsze obciążenia w Citadel Securities. Szersze wdrożenie wnioskowania pokazałoby, że udostępnienie TPU na zewnątrz wykracza poza wyspecjalizowane zespoły i najważniejszych partnerów strategicznych.

Reakcję Nvidia należy obserwować w tym samym okresie. Usprawnienia w Dynamo, TensorRT-LLM, Blackwell i Rubin mogą zmienić porównanie, zanim oprogramowanie TPU osiągnie dojrzałość.

Przewaga kosztowa nie jest trwała, gdy obie platformy szybko aktualizują sprzęt i oprogramowanie obsługujące. Nabywcy powinni oceniać powtarzalne warunki operacyjne, zamiast traktować jeden benchmark jako niezmienny ranking.

Praktyczny wniosek jest taki, by oddzielić dopasowanie do obciążenia od tożsamości dostawcy. Stabilne wnioskowanie o dużym wolumenie może już uzasadniać ocenę TPU. Usługi wrażliwe na opóźnienia, szybko zmieniające się modele lub zespoły mocno zainwestowane w CUDA mogą nadal preferować Nvidia.

Zespoły infrastruktury powinny zachowywać założenia benchmarków i wnioski z wdrożeń jako żywe dokumenty. Przeszukiwalna techniczna baza wiedzy może pomóc zespołom porównywać wyniki wraz ze zmianami modeli, kompilatorów i generacji akceleratorów.

Google przekroczył ważny próg, udostępniając zewnętrznym odbiorcom możliwość testowania ekonomiki swoich TPU. Nie zniwelował jednak przewagi Nvidia w zakresie oprogramowania ani nie ustanowił uniwersalnego przywództwa.

Kolejne pytanie jest konkretne: czy zwykli klienci potrafią odtworzyć korzyści Google TPU w zakresie wnioskowania w rzeczywistych zastosowaniach, zanim kolejny system Nvidia je ograniczy? Odpowiedź zdecyduje, czy InferenceX oznacza trwałą zmianę na rynku, czy jedynie imponujący wczesny etap.