L'inferenza Google TPU ha appena sfidato il vantaggio di costo di Nvidia con Ironwood

L'inferenza Google TPU ha raggiunto una nuova fase: secondo quanto riportato, Ironwood offre fino al 50% di prestazioni per dollaro in più rispetto a Nvidia B200 in test selezionati. Il risultato proviene da un'anteprima ufficiale di InferenceX, un progetto di benchmarking di terze parti gestito da SemiAnalysis. Mette in discussione l'ipotesi che un'economia competitiva delle TPU esista soltanto all'interno di Google.

Questa precisazione è importante. SemiAnalysis ha testato uno stack TPU per il serving, recentemente reso disponibile all'esterno, contro acceleratori Nvidia in specifiche condizioni di modello, precisione, throughput e latenza. Ironwood non ha vinto ogni confronto e il suo software non dispone ancora di diverse ottimizzazioni disponibili nelle implementazioni GPU mature.

La sfida più profonda non riguarda quindi un benchmark contro un altro. È il tentativo di Google di rendere il suo sistema TPU verticalmente integrato utilizzabile dai clienti abituati all'ambiente software CUDA di Nvidia. Se Google riuscirà nell'intento, gli acquirenti otterranno un'alternativa credibile per l'inferenza su larga scala senza dover attendere che si riduca soltanto il divario hardware.

L'inferenza Google TPU esce dai confini di Google

Il cambiamento importante è che ora gli esterni possono valutare l'inferenza Google TPU attraverso un flusso di lavoro più familiare per il serving di modelli aperti.

Google utilizza TPU in produzione da oltre un decennio. I suoi servizi interni hanno dato all'azienda un controllo insolito sulla progettazione degli acceleratori, i compilatori, il networking, i modelli e il software di distribuzione. Quel controllo ha reso le TPU efficaci all'interno di Google, ma non ha creato automaticamente una piattaforma accessibile agli sviluppatori esterni.

Ironwood modifica una parte di questa equazione. Google ha presentato la TPU di settima generazione nell'aprile 2025 come la sua prima TPU progettata specificamente per l'inferenza. L'inferenza è il processo di esecuzione di un modello addestrato per produrre una risposta, un'immagine, una previsione o un'azione.

Google ha successivamente reso Ironwood generalmente disponibile attraverso Google Cloud. I suoi dettagli sul lancio di Ironwood descrivono configurazioni fino a 9.216 chip e 42,5 exaflops per pod. Google ha inoltre dichiarato un'efficienza energetica quasi 30 volte superiore rispetto alla sua prima Cloud TPU del 2018.

Queste specifiche hanno definito la scala dell'hardware. Non hanno però risposto alla domanda se un team esterno possa fornire modelli open-weight in modo efficiente senza dipendere dall'ambiente di produzione privato di Google.

I nuovi risultati di InferenceX affrontano questa domanda più difficile. SemiAnalysis afferma che l'anteprima usa TorchTPU, uno stack software esterno progettato per collegare i flussi di lavoro dei modelli orientati a PyTorch con le TPU di Google. Include inoltre lavoro su SGLang, un motore di serving open source utilizzato per l'inferenza dei modelli linguistici di grandi dimensioni.

Questa combinazione è importante perché la maggior parte degli sviluppatori AI non sceglie un acceleratore leggendo la sua specifica di calcolo di picco. Valuta quanto lavoro ingegneristico separi un checkpoint del modello da un servizio di produzione stabile.

L'anteprima del benchmark di terze parti riporta che Ironwood ha superato Nvidia B200 e B300 nelle prestazioni per dollaro in alcune parti dell'intervallo operativo testato. Con un obiettivo di 100 token generati al secondo per utente, SemiAnalysis ha calcolato un vantaggio di costo di circa il 19% rispetto a B200. Il vantaggio riportato ha raggiunto circa il 34% rispetto a B300.

Con un obiettivo più lento di 20 token al secondo, Ironwood ha prodotto 9.364 token totali al secondo per chip nel test riportato. B200 ha prodotto 8.903, mentre B300 ha prodotto 8.925. Ciò ha rappresentato un throughput grezzo superiore di circa il 5% per Ironwood in quella particolare esecuzione.

Costi hardware modellati più bassi hanno ampliato il vantaggio calcolato. SemiAnalysis ha riportato il 50,4% di token per dollaro in più rispetto a B200 a un punto di alta concorrenza. Ha riportato un vantaggio molto maggiore rispetto a B300 nello stesso punto.

Si tratta di risultati di benchmark, non di classifiche universali. Rappresentano modelli e configurazioni selezionati in esecuzione tramite uno stack ancora in sviluppo. Anche così, spostano la conversazione sulle TPU dal potenziale architetturale verso un'economia osservabile dall'esterno.

Questa transizione crea la tensione centrale. Google non deve più dimostrare soltanto che i propri team possono estrarre valore dalle TPU. Deve dimostrare che i clienti possono riprodurre una quota sufficiente di quel valore con impegno, latenza, affidabilità e copertura dei modelli accettabili.

Il risultato sui costi mette sotto pressione la posizione predefinita di Nvidia

Un vantaggio di costo credibile delle TPU mette sotto pressione Nvidia perché gli acquirenti di inferenza acquistano lavoro completato, non specifiche di picco dei chip.

I grandi servizi AI devono elaborare enormi quantità di token in input e output. Piccole differenze nell'utilizzo, nella latenza e nel consumo energetico si moltiplicano su carichi di lavoro persistenti. Questo rende le prestazioni per dollaro più utili del throughput grezzo nel confronto tra sistemi di produzione.

La metrica richiede comunque contesto. Un sistema può aumentare il throughput totale raggruppando più richieste in batch, ma batch più grandi spesso fanno attendere più a lungo i singoli utenti. Un costo inferiore per token conta meno se il servizio non raggiunge il proprio obiettivo sui tempi di risposta.

SemiAnalysis ha illustrato questo compromesso nelle sue misurazioni ad alta concorrenza. Con concorrenza 256, Ironwood ha registrato un tempo medio al primo token di 5,41 secondi. B200 ha raggiunto 3,75 secondi, mentre B300 ha raggiunto 2,40 secondi.

Il tempo al primo token misura quanto attende un utente prima che il modello inizi a generare la risposta. È particolarmente importante per interfacce chat, assistenti di coding, sistemi vocali e agenti interattivi.

Il divario di latenza complica qualsiasi affermazione secondo cui Ironwood superi semplicemente Blackwell. Il risultato di costo più forte di Ironwood è apparso in un punto operativo in cui Nvidia forniva il primo token più rapidamente. Clienti diversi attribuiranno un valore differente a questo scambio.

Un servizio offline di elaborazione documentale può accettare attese più lunghe se ottiene un throughput sostanzialmente superiore. Un chatbot per consumatori che compete sulla reattività potrebbe preferire un primo token più rapido, anche quando ogni richiesta completata costa di più.

Gli agenti a esecuzione prolungata creano un altro schema di carico di lavoro. Leggono ripetutamente il contesto, richiamano strumenti, aggiornano lo stato e generano risposte brevi. Le loro esigenze infrastrutturali differiscono da quelle di un singolo prompt seguito da una risposta lunga.

Queste distinzioni spiegano perché InferenceX presenta una curva di Pareto anziché un unico punteggio principale. Una curva di Pareto mostra le migliori combinazioni disponibili di costo e latenza senza fingere che un singolo punto operativo sia adatto a ogni applicazione.

Secondo quanto riportato, Ironwood è rimasto competitivo lungo gran parte di quella curva. Con un tempo mediano di risposta end-to-end di 20 secondi, SemiAnalysis ha stimato un vantaggio di costo dell'8% rispetto a B200 e del 25% rispetto a B300.

Tuttavia, B200 è passato in testa in una porzione più piccola della curva sovrapposta. Nvidia ha inoltre mantenuto vantaggi importanti quando i modelli utilizzavano calcolo FP4 a precisione inferiore.

FP4 memorizza valori numerici usando rappresentazioni in virgola mobile a quattro bit. Può aumentare il throughput e ridurre l'uso della memoria, anche se una quantizzazione aggressiva può influire sulla qualità del modello. Secondo l'analisi del benchmark, Ironwood non dispone di calcolo FP4 nativo.

SemiAnalysis ha confrontato i sistemi principalmente con FP8 e previsione di un singolo token nei test più direttamente comparabili. Ha osservato che il percorso FP4 di Nvidia può primeggiare quando i clienti accettano i relativi compromessi in termini di qualità e implementazione.

Questo rende la pressione su Nvidia più circoscritta di una storia di sostituzione diretta. Google sta sfidando la scelta economica predefinita di Nvidia per alcuni carichi di lavoro di inferenza, soprattutto dove forme di modello stabili favoriscono hardware specializzato.

Nvidia continua a offrire ampia copertura dei carichi di lavoro, librerie ampiamente distribuite, operatori esperti e strumenti di debugging consolidati. Questi asset riducono il rischio di integrazione in modi che non compaiono nei grafici del throughput di token.

La pressione immediata ricade sui prezzi e sulla segmentazione dei prodotti di Nvidia. Se i clienti possono spostare carichi di lavoro di inferenza prevedibili su Ironwood, Nvidia deve difendere Blackwell con un utilizzo migliore, una latenza più bassa, opzioni di precisione più ampie o una distribuzione più semplice.

Anche Google affronta pressioni. Deve trasformare un'anteprima promettente in risultati ripetibili per i clienti. In caso contrario, gli acquirenti considereranno il benchmark una dimostrazione ottimizzata anziché un'alternativa per gli acquisti.

Perché lo stack TPU esterno di Google conta più di un singolo benchmark

Il meccanismo reale è l'esternalizzazione del software, perché hardware competitivo non può ridurre la dipendenza da CUDA quando i clienti faticano a distribuire i propri modelli.

CUDA è la piattaforma di programmazione di Nvidia e la sua raccolta di librerie accelerate per il calcolo GPU. La sua importanza va oltre il linguaggio utilizzato per scrivere i kernel. CUDA collega driver, compilatori, librerie di comunicazione, profiler, motori di inferenza, ottimizzatori di modelli e anni di conoscenza degli sviluppatori.

Questo sistema connesso riduce il rischio operativo. Un team che incontra un problema di prestazioni GPU può attingere a documentazione estesa, strumenti familiari, supporto del fornitore e una vasta comunità ingegneristica. Spesso può riutilizzare modelli di distribuzione tra diverse generazioni Nvidia.

Google ha storicamente ottimizzato le TPU tramite strumenti e team interni. JAX è diventato il percorso di programmazione pubblico più visibile, mentre molti progetti AI esterni si sono standardizzati su PyTorch e CUDA.

TorchTPU cerca di ridurre questa distanza. Offre agli sviluppatori orientati a PyTorch un percorso verso l'esecuzione su TPU, supportando al contempo livelli familiari di modelli e serving. Più questa esperienza si avvicina ai flussi di lavoro esistenti, più si riduce il costo di passaggio per Google.

SGLang offre un altro ponte. Gestisce attività di serving dei modelli come pianificazione delle richieste, uso della memoria, batching ed esecuzione distribuita. Supportare un motore di inferenza riconoscibile consente a Google di competere a un livello superiore rispetto al chip.

Questo non significa che il problema software sia stato risolto. SemiAnalysis ha identificato lavoro incompleto su speculative decoding, serving disaggregato, offloading della cache key-value e carichi di lavoro di agenti multi-turno.

Lo speculative decoding utilizza un modello più piccolo o più veloce per suggerire token che un modello più grande verifica. Se implementato bene, aumenta la velocità di generazione senza modificare la distribuzione prevista dell'output finale del modello.

Il serving disaggregato separa l'elaborazione del prompt dalla generazione dei token. Queste fasi impongono requisiti diversi a calcolo, memoria e networking, quindi pool di risorse specializzati possono migliorare l'utilizzo.

L'offloading della cache key-value sposta i dati di attenzione memorizzati lontano dalla memoria dell'acceleratore quando opportuno. Può espandere la capacità effettiva per contesti lunghi o molte sessioni simultanee, ma il trasferimento dei dati può introdurre latenza.

Queste capacità sono diventate importanti nelle principali implementazioni GPU. Secondo quanto riportato, l'infrastruttura privata di Google utilizza alcune tecniche comparabili, ma il suo stack TPU esterno non espone ancora ogni percorso ottimizzato.

Questo divario spiega un confronto rivelatore nel rapporto sul benchmark. SemiAnalysis ha rilevato che un sistema Nvidia GB300 NVL72 con serving disaggregato manteneva un vantaggio di circa il 30% nelle prestazioni per dollaro in una parte dell'intervallo di latenza. Il confronto TPU utilizzava serving aggregato perché il suo percorso disaggregato esterno non era completamente ottimizzato.

Non si è trattato di un confronto architetturale netto. Ha però mostrato quanto il software di produzione possa influire sul risultato. La leadership hardware cambia quando un sistema riceve una strategia di pianificazione e serving più matura.

Nvidia sta inoltre espandendo il proprio livello di inferenza. L'azienda ha rilasciato Dynamo 1.0 nel marzo 2026 come software open source per l'inferenza generativa e agentica distribuita. Dynamo coordina operazioni quali l'instradamento delle richieste, la gestione della memoria e il serving disaggregato.

Nvidia ha inoltre contribuito con kernel CUDA TensorRT-LLM al progetto open source FlashInfer. Questa strategia inserisce componenti ottimizzati per Nvidia nei framework che gli sviluppatori già utilizzano.

Google, pertanto, non può ridurre il vantaggio competitivo di CUDA limitandosi a eguagliare un obiettivo statico. Deve migliorare mentre Nvidia continua ad aprire parti del proprio stack e a ottimizzare i suoi sistemi su scala rack.

L'elemento promettente per Google è la sua capacità di coordinare lo sviluppo di hardware e software. Gli ingegneri TPU possono modellare compilatori, kernel, interconnessioni e sistemi di serving attorno alle stesse ipotesi architetturali.

Il vincolo è la diversità dei modelli. Un array specializzato funziona al meglio quando dimensioni e operazioni del modello si allineano alla sua geometria. I modelli progettati e ottimizzati attorno alle GPU possono creare configurazioni inefficienti per l'esecuzione su TPU.

SemiAnalysis ha evidenziato questo problema con le dimensioni dell'attenzione e il routing mixture-of-experts. Un modello diffuso potrebbe comunque richiedere un notevole lavoro sui kernel prima di utilizzare Ironwood in modo efficiente.

L'esternalizzazione dipende quindi da una matrice di compatibilità in crescita, non da un singolo porting riuscito. Gli acquirenti devono avere fiducia che le nuove famiglie di modelli riceveranno ottimizzazioni tempestive senza richiedere l'accesso diretto agli ingegneri delle prestazioni di Google.

Ironwood vince test selezionati, ma resta il divario nella verifica

Il vantaggio riportato è significativo, ma il suo ambito resta troppo ristretto per dimostrare una leadership generale di Google TPU nell'inferenza.

InferenceX descrive i suoi risultati come le prime misurazioni di inferenza di terze parti per Ironwood. Ciò conferisce al lavoro maggiore indipendenza rispetto a un benchmark pubblicato esclusivamente da Google. Tuttavia, SemiAnalysis attribuisce anche a ingegneri Google e ad altri team partecipanti il merito di aver contribuito a costruire e ottimizzare lo stack testato.

La collaborazione è normale nei primi benchmark hardware. Può rivelare le prestazioni raggiungibili di un sistema con maggiore accuratezza rispetto a un'installazione non supportata. Rende inoltre il risultato più simile a un'implementazione di riferimento ottimizzata che a un deployment medio di un cliente.

L'anteprima si è inizialmente concentrata su un carico di lavoro 8k1k. Questa notazione descrive generalmente l'elaborazione di un input di 8.000 token e la generazione di 1.000 token in output. Rappresenta un prompt sostanziale seguito da una risposta significativa, ma non copre ogni schema di inferenza moderno.

Gli agenti di coding possono riutilizzare ed espandere repository nel corso di molti turni. Gli agenti di ricerca possono alternare lunghi input di retrieval a brevi chiamate di strumenti. Le applicazioni vocali privilegiano una bassa latenza continua, mentre la sintesi batch privilegia il throughput complessivo.

Un singolo carico di lavoro non può rappresentare queste differenze. Gli acquirenti necessitano di risultati su lunghezze dei prompt, lunghezze degli output, livelli di concorrenza, architetture dei modelli, formati di quantizzazione e obiettivi di livello di servizio diversi.

Anche la qualità del modello rientra nel confronto. FP4 può migliorare il throughput di Nvidia, ma una configurazione a precisione inferiore dovrebbe essere valutata rispetto all'accuratezza dei compiti e alla coerenza dell'output. Un risultato di velocità è incompleto se le modifiche alla precisione producono un comportamento diverso del modello.

La metodologia dei costi presenta un'altra incertezza. SemiAnalysis ha utilizzato un costo totale di proprietà modellato per sistemi acquistati esternamente, anziché limitarsi alle tariffe pubbliche di noleggio cloud. Tali modelli dipendono da ipotesi su acquisizione, utilizzo, energia, networking, finanziamento e vita utile.

L'economia interna di Google differisce da quella dei clienti. Il rapporto ha stimato un vantaggio TPU maggiore applicando le ipotesi di costo interne di Google. Gli acquirenti esterni non possono presumere di ricevere la stessa struttura di costi.

Anche la disponibilità può modificare ulteriormente il calcolo. Un acceleratore tecnicamente efficiente offre valore limitato se i clienti non riescono a ottenere capacità sufficiente nelle regioni in cui operano. Anche Nvidia affronta vincoli di fornitura, ma i suoi sistemi restano disponibili attraverso molti provider cloud e partner di server.

L'attuale catalogo TPU di Google elenca Ironwood come generalmente disponibile. Presenta inoltre TPU 8i come una generazione imminente focalizzata sull'inferenza. La capacità effettiva, le opzioni di acquisto, gli accordi di supporto e l'accesso geografico possono comunque variare da cliente a cliente.

La portabilità è un altro costo che i benchmark raramente catturano. Un'azienda che standardizza su ottimizzazioni specifiche per TPU può ottenere un'economia migliore, diventando però più dipendente da Google Cloud o da fornitori di sistemi selezionati.

CUDA crea lock-in, ma allontanarsi da CUDA non elimina automaticamente il lock-in. Può sostituire uno stack integrato con un altro. I framework aperti riducono questo rischio solo quando comportamento e prestazioni si trasferiscono in modo prevedibile tra backend.

Le prove operative conteranno quanto un'altra curva di benchmark. I clienti necessitano di ripristino dagli errori, osservabilità, autoscaling, controlli di sicurezza, gestione delle versioni e aggiornamenti prevedibili.

Hanno inoltre bisogno di ingegneri in grado di diagnosticare regressioni delle prestazioni. Una piattaforma con costi per token più bassi può diventare costosa se gli specialisti devono riscrivere ripetutamente i kernel o indagare il comportamento del compilatore.

Per questa ragione, il risultato di InferenceX dovrebbe essere interpretato come prova di competitività in condizioni selezionate. Non dimostra che Ironwood sia diventato il miglior acceleratore per ogni modello o organizzazione.

Questa distinzione non sminuisce la notizia. I precedenti dibattiti sulle TPU spesso si fermavano alla questione se i vantaggi privati di Google potessero uscire dal suo stesso ambiente. L'anteprima mostra che almeno una parte dello stack può ora supportare un'inferenza verificabile esternamente e competitiva dal punto di vista economico.

L'onere della prova si è spostato. Google deve ampliare la superficie testata, mentre Nvidia deve dimostrare che i suoi vantaggi in software e latenza giustificano la sua posizione nei carichi di lavoro in cui Ironwood riduce i costi.

TPU 8i estende la sfida oltre Ironwood

Ironwood stabilisce un percorso esterno credibile, mentre TPU 8i è progettato per affrontare diversi limiti emersi dall'attuale confronto.

Google ha annunciato l'ottava generazione di TPU nell'aprile 2026, con progetti separati per addestramento e inferenza. TPU 8t punta all'addestramento su larga scala, mentre TPU 8i si concentra su post-addestramento, reinforcement learning e inferenza.

Questa separazione riflette il cambiamento della domanda di infrastrutture AI. L'addestramento richiede calcolo denso su cluster enormi. L'inferenza deve bilanciare capacità di memoria, latenza, throughput, energia e schemi di richiesta in rapido cambiamento.

Google afferma che TPU 8i offrirà un miglioramento dell'80% nelle prestazioni per dollaro rispetto a Ironwood per l'inferenza a bassa latenza su grandi modelli mixture-of-experts. I modelli mixture-of-experts attivano solo gruppi selezionati di parametri per ciascun token, riducendo il calcolo ma creando esigenze di routing e comunicazione.

L'azienda afferma inoltre che TPU 8i supporta il calcolo FP4 nativo. Ciò affronta direttamente un'area in cui Nvidia manteneva un vantaggio nei confronti con Ironwood.

La roadmap dell'ottava generazione di Google afferma che TPU 8i e TPU 8t offrono fino al doppio delle prestazioni per watt rispetto a Ironwood. Entrambe sono state annunciate per un arrivo successivo nel 2026.

Restano affermazioni dell'azienda finché test indipendenti non le confermeranno. Il punto rilevante è la direzione dell'architettura. Google non considera più l'inferenza come un utilizzo secondario di hardware progettato principalmente attorno all'addestramento.

TPU 8i aumenta inoltre l'importanza del lavoro sul software esterno in corso. Un nuovo acceleratore senza uno stack di serving utilizzabile riavvierebbe il problema dell'adozione. Un ambiente TorchTPU in maturazione può trasferire supporto per i modelli e conoscenze operative nella generazione successiva.

SemiAnalysis prevede che TPU 8i competerà più direttamente con la piattaforma Rubin NVL72 di Nvidia. Quel confronto dipenderà da più del supporto FP4 nativo.

I sistemi Rubin di Nvidia combinano GPU, CPU, networking, memoria e software di inferenza su scala rack. Nvidia ha inoltre ottimizzato la propria roadmap attorno ai modelli di ragionamento e ai carichi di lavoro agentici, nei quali l'inferenza ripetuta aumenta la domanda totale di token.

Google propone un argomento simile a livello di sistema. Progetta congiuntamente calcolo TPU, comunicazione tra chip, networking ottico, compilatori e orchestrazione cloud.

La competizione è sempre più un sistema contro un sistema. Nessuno dei due fornitori può conquistare carichi di lavoro produttivi durevoli attraverso la specifica di un acceleratore isolato.

Amazon, AMD e altri programmi di silicio personalizzato aggiungono ulteriore pressione. La loro esistenza offre ai grandi acquirenti maggiore leva negoziale, anche quando tali acquirenti continuano a utilizzare Nvidia per molti carichi di lavoro.

Ciononostante, Google occupa una posizione distinta. Ha anni di esperienza nella produzione di TPU, importanti carichi di lavoro interni, un cloud pubblico, sviluppo di modelli di frontiera e una roadmap chiara per gli acceleratori.

Questa combinazione consente a Google di testare ottimizzazioni su servizi interni sostanziali prima di esporli ai clienti. Può inoltre modellare i modelli Gemini attorno alle caratteristiche delle TPU.

L'adozione esterna richiede il movimento opposto. Google deve ottimizzare modelli popolari che non ha progettato, comprese architetture le cui dimensioni riflettono anni di ricerca orientata alle GPU.

È qui che il vantaggio competitivo di CUDA diventa meno assoluto, ma rimane sostanziale. I framework di alto livello possono nascondere le differenze hardware durante l'esecuzione di base. Non possono eliminare automaticamente ogni differenza di kernel, networking, pianificazione e gestione della memoria.

La generazione di codice assistita dall'AI può accelerare parte del lavoro di porting. Non può sostituire la convalida in termini di accuratezza, stabilità e modalità di errore in produzione.

TPU 8i rafforzerà la sfida di Google se arriverà con un ampio supporto dei modelli e un serving disaggregato maturo. Indebolirà la narrazione se la sua migliore economia dipenderà da assistenza ingegneristica privilegiata o da configurazioni di benchmark ristrette.

Tre segnali determineranno se l'esternalizzazione delle TPU funziona

Le prossime evidenze dovranno dimostrare ripetibilità, ampiezza dei carichi di lavoro e adozione da parte dei clienti, anziché un altro risultato di picco isolato.

Il primo segnale è un benchmark comparabile di serving disaggregato. SemiAnalysis afferma che l'attuale percorso TPU esterno necessita ancora di ottimizzazione in quest'area, sebbene Google utilizzi tecniche correlate internamente.

Un utile seguito confronterebbe Ironwood e sistemi Nvidia con la disaggregazione abilitata da entrambe le parti. Dovrebbe utilizzare lo stesso modello, precisione, obiettivo di qualità, vincolo di latenza e metodologia dei costi.

Se Ironwood riduce il divario riportato rispetto a GB300 NVL72, l'argomento di Google a livello di sistema diventa più forte. Se il divario persiste, il software di serving maturo di Nvidia resta un vantaggio decisivo.

Il secondo segnale è la prestazione nei carichi di lavoro agentici multi-turno. Questi sistemi elaborano ripetutamente contesto crescente, chiamano strumenti e producono output brevi. Sollecitano la gestione della cache e la latenza in modo diverso da un benchmark 8k1k.

SemiAnalysis afferma di prevedere la pubblicazione di risultati per carichi di lavoro agentici più avanti nel 2026. Tali test dovrebbero riportare il tempo al primo token, la latenza inter-token, il throughput, l'uso della memoria e il costo per attività completata.

Risultati solidi dimostrerebbero che l'inferenza Google TPU può gestire il modello di domanda che guida l'attuale pianificazione delle infrastrutture. Risultati deboli suggerirebbero che il vantaggio di Ironwood si concentri in lavori di serving più prevedibili.

Il terzo segnale è l'evidenza da clienti esterni. La disponibilità generale è importante, ma i deployment ripetuti rivelano se gli sviluppatori possono riprodurre l'economia dei benchmark senza un supporto insolitamente intensivo.

Le prove più solide includerebbero carichi di lavoro di produzione nominati, modelli aperti supportati, espansione della capacità e affidabilità misurata. Gli acquirenti dovrebbero inoltre osservare quanto rapidamente i nuovi modelli ricevono kernel TPU ottimizzati.

Google elenca già esempi di clienti relativi a Ironwood, tra cui workload più rapidi presso Citadel Securities. Un'adozione più ampia dell'inferenza mostrerebbe che l'esternalizzazione delle TPU va oltre i team specializzati e i principali partner strategici.

La risposta di Nvidia rientra nella stessa finestra di osservazione. I miglioramenti a Dynamo, TensorRT-LLM, Blackwell e Rubin possono modificare il confronto prima che il software TPU raggiunga la piena maturità.

Un vantaggio di costo non è permanente quando entrambe le piattaforme aggiornano rapidamente hardware e software di serving. Gli acquirenti dovrebbero valutare configurazioni operative riproducibili, invece di trattare un singolo benchmark come una classifica immutabile.

La lezione pratica è separare l'adeguatezza al carico di lavoro dall'identità del fornitore. Un'inferenza stabile e ad alto volume può giustificare già ora una valutazione delle TPU. I servizi sensibili alla latenza, i modelli in rapida evoluzione o i team fortemente investiti in CUDA potrebbero continuare a preferire Nvidia.

I team infrastrutturali dovrebbero conservare le proprie ipotesi di benchmark e i risultati delle implementazioni come documenti in continua evoluzione. Una base di conoscenza tecnica ricercabile può aiutare i team a confrontare i risultati man mano che cambiano modelli, compilatori e generazioni di acceleratori.

Google ha superato una soglia importante rendendo verificabile dall'esterno l'economia delle proprie TPU. Non ha però eliminato il vantaggio software di Nvidia né stabilito una leadership universale.

La prossima domanda è concreta: i clienti comuni riusciranno a riprodurre i miglioramenti nell'inferenza TPU di Google su applicazioni reali prima che il prossimo sistema di Nvidia riduca questo divario? La risposta determinerà se InferenceX rappresenterà un cambiamento duraturo del mercato o un impressionante traguardo iniziale.