The Pulse

InferenceX apre il confronto tra TPU e Nvidia nell’inferenza

SemiAnalysis ha pubblicato i primi risultati di terze parti di InferenceX per la TPUv7 Ironwood di Google, a confronto con B200 e B300 di Nvidia. Il benchmark mostra che Ironwood raggiunge prestazioni per dollaro fino al 50% superiori in al

AI.info Team · 2026-09-12

Un nuovo benchmark pubblico mette l’ultima TPU di Google a confronto con i principali sistemi di inferenza di Nvidia, usando la metrica che determina sempre più spesso se un servizio di IA è redditizio: i token generati per ogni dollaro speso.

Il 7 settembre, SemiAnalysis ha pubblicato i primi risultati di terze parti sull’inferenza con la TPUv7 Ironwood di Google attraverso la piattaforma di confronto InferenceX. Nei test di serving del modello Qwen3.5 da 397 miliardi di parametri in FP8, Ironwood raggiunge prestazioni per dollaro fino al 50% superiori a quelle di Nvidia B200 e B300 nelle condizioni di serving selezionate dal benchmark.

La pubblicazione offre agli operatori esterni un punto di riferimento pubblico per un chip che Google ha storicamente usato soprattutto nei propri servizi. Chiarisce inoltre che il vantaggio di Ironwood dipende dalla forma del carico di lavoro, dalle ipotesi sui costi, dalla precisione, dalla topologia di serving e dal livello di maturità dello stack software.

Il primo confronto pubblico di Ironwood con Blackwell

SemiAnalysis afferma che i nuovi risultati sono le prime misurazioni di terze parti per TPUv7 Ironwood nel programma di anteprima ufficiale di InferenceX. Il confronto si basa su serving aggregato, precisione FP8 e predizione di un singolo token, con Qwen3.5 397B come primo modello per il percorso di serving nativo TorchTPU di Google.

Con un obiettivo di interattività di 100 token al secondo per utente, l’analisi stima un costo di circa 0,181 dollari per milione di token totali per Ironwood. Le stime corrispondenti sono di 0,222 dollari per Nvidia B200 e 0,276 dollari per Nvidia B300. In base a queste cifre, Ironwood costa circa il 19% in meno di B200 e il 34% in meno di B300, offrendo la stessa velocità di generazione dichiarata per utente.

Il confronto non sostiene che Ironwood raggiunga il throughput grezzo più elevato in tutto l’intervallo di test. SemiAnalysis afferma che i sistemi Nvidia restano in vantaggio su gran parte della curva delle prestazioni grezze. Il risultato di Ironwood deriva dalla combinazione di un throughput competitivo e di un costo orario stimato inferiore, che cambia la classifica quando il calcolo passa dai token al secondo ai token per dollaro.

A 20 token al secondo per utente, Ironwood raggiunge 9.364 token totali al secondo per chip nelle prove riportate. B200 raggiunge 8.903, mentre B300 arriva a 8.925. In base alle ipotesi sui costi totali esterni usate da SemiAnalysis, il vantaggio in termini di prestazioni per dollaro è del 50,4% rispetto a B200 e del 96,0% rispetto a B300.

L’economia del benchmark dipende da chi possiede l’hardware

SemiAnalysis presenta due prospettive sui costi, anziché una sola. Il confronto esterno modella i costi per un laboratorio hyperscaler che acquista sistemi TPU, mentre un calcolo separato usa un costo interno stimato per Google di 1,03 dollari per chip-ora.

Con una concorrenza di 256, lo scenario basato sui costi interni porta il vantaggio stimato di Ironwood in termini di prestazioni per dollaro al 76,7% rispetto a B200 e al 130,2% rispetto a B300. Il risultato comporta però una penalità in termini di latenza: il tempo medio di Ironwood al primo token è indicato in 5,41 secondi, contro i 3,75 secondi di B200 e i 2,40 secondi di B300 con la stessa concorrenza.

Questi numeri circoscrivono il significato del risultato principale per le implementazioni in produzione. Un servizio che vende risposte rapide a utenti che interagiscono con il sistema potrebbe attribuire più importanza alla latenza del primo token che al throughput aggregato massimo. Un servizio che elabora grandi lotti o opera con un budget infrastrutturale rigido potrebbe accettare risposte iniziali più lente in cambio di un costo per token inferiore.

Con un obiettivo di tempo mediano di risposta di 20 secondi, SemiAnalysis stima per Ironwood un costo di circa 0,098 dollari per milione di token totali, contro 0,106 dollari per B200 e 0,132 dollari per B300. Ironwood può comunque risultare svantaggiata in un breve tratto della curva di confronto, incluso un punto intorno a un tempo mediano di risposta di 30 secondi, prima di tornare a un vantaggio di costo con tempi di risposta più lunghi.

TorchTPU nativo è la vera novità sul fronte dei prodotti

I dati sull’hardware arrivano insieme a una transizione software. Google e collaboratori esterni stanno spostando l’inferenza su TPU dal precedente percorso TorchAX a TorchTPU, un backend nativo per PyTorch pensato per vLLM e SGLang.

TorchAX permette al codice dei modelli PyTorch di essere eseguito tramite JAX. TorchTPU, invece, consente ai framework di serving di trattare le TPU come dispositivi PyTorch nativi, continuando però a usare i kernel specifici per TPU e i componenti del compilatore nei casi in cui sono utili. Questa differenza incide sulla facilità con cui gli sviluppatori possono portare su hardware Google il codice dei modelli e l’infrastruttura di serving già esistenti.

Le prestazioni di inferenza non emergono automaticamente quando un framework supporta un dispositivo. SemiAnalysis descrive centinaia di ore di lavoro ingegneristico e numerose modifiche al codice per la prima configurazione di un modello su Ironwood. Il lavoro comprende l’attenzione parallela sui dati, l’instradamento delle mixture-of-experts, kernel personalizzati, l’ottimizzazione delle comunicazioni e la riduzione del padding per le architetture con gating.

L’attenzione grouped-query di Qwen3.5 è un esempio del problema. Il modello ha 32 teste di query ma solo due teste key-value condivise, che non si ripartiscono equamente su otto dispositivi logici. Servono mappature specifiche per TPU e interventi sulle comunicazioni per mantenere occupati quei dispositivi, evitando che la distribuzione irregolare dell’attenzione diventi un collo di bottiglia.

«Un benchmarking neutrale rispetto ai fornitori e aggiornato continuamente è essenziale, man mano che modelli e stack di inferenza evolvono insieme», afferma Ryan Lee, responsabile delle relazioni con gli sviluppatori di MiniMax, nella pagina dei sostenitori di InferenceX. «InferenceX offre il tipo di dati trasparenti e riproducibili di cui l’ecosistema ha bisogno».

La citazione spiega perché un confronto pubblico è importante al di là della classifica tra due chip. I risultati dell’inferenza cambiano quando migliora un kernel, cambia uno scheduler, emerge una nuova topologia di serving o un modello adotta una diversa strategia di parallelismo. Una scheda tecnica statica non può cogliere questi cambiamenti.

FP8 offre a Ironwood un terreno favorevole, ma non rappresenta l’intero mercato

Ironwood supporta nativamente l’hardware FP8, il che consente di confrontarla con B200 e B300 usando la stessa precisione FP8 su entrambi i fronti. TPUv7, tuttavia, non supporta nativamente il calcolo FP4, e questo dà a Nvidia un chiaro vantaggio quando gli operatori usano il serving FP4.

SemiAnalysis afferma che Nvidia mantiene il vantaggio nei confronti in FP4, pur avvertendo che il serving di un modello in FP4 può ridurne la qualità rispetto all’FP8. La distinzione è importante perché i sistemi Blackwell di Nvidia possono usare percorsi a precisione inferiore che Ironwood non è attualmente in grado di eguagliare a livello hardware.

L’analisi indica TPUv8i, identificata come Boardfly, come la risposta di Google a questo divario. TPUv8i dovrebbe aggiungere il supporto nativo FP4 e, secondo SemiAnalysis, potrebbe competere con i sistemi Rubin NVL72 di Nvidia. Si tratta di una previsione, non di un risultato dell’attuale benchmark pubblico su Ironwood: non va quindi interpretata come prova che TPUv8i abbia già raggiunto le prestazioni dell’hardware Nvidia.

L’attuale vantaggio di Google non si estende inoltre allo stesso modo a ogni configurazione di serving. I risultati pubblici di Ironwood si concentrano sul serving aggregato, in cui prefill e decode avvengono insieme. In alcuni casi, i sistemi GB200 e GB300 NVL72 di Nvidia vengono confrontati usando il serving disaggregato, che separa prefill e decode in pool distinti e può migliorare la risposta del sistema a determinati carichi di lavoro.

La disaggregazione e il lavoro sulla cache KV determineranno il prossimo confronto

SemiAnalysis afferma che Google usa internamente il serving disaggregato da anni, anche nei sistemi Gemini in produzione, ma che il percorso TPU esterno non è ancora del tutto ottimizzato. In un confronto disaggregato con GB300 NVL72, il sistema Nvidia può quindi apparire più competitivo di quanto non risulti nel confronto aggregato con Ironwood.

La fase successiva dell’apertura delle TPU agli operatori esterni prevede di trasferire queste tecniche interne nel software pubblico. Google sta lavorando al supporto TPU per llm-d e a TPU-Sync, una libreria per trasferire la cache key-value tra worker. La cache contiene lo stato intermedio dell’attenzione necessario per continuare a generare una risposta, quindi la sua efficienza di trasferimento può determinare se una configurazione con prefill e decode separati fa risparmiare tempo o aggiunge un costo in termini di comunicazione.

Lo scaricamento della cache KV diventa più importante quando i modelli gestiscono prompt lunghi, grandi lotti e sessioni multi-turno con agenti. Questi carichi di lavoro riutilizzano istruzioni di sistema, definizioni degli strumenti e cronologia delle conversazioni per molte richieste. Mantenere quello stato nella memoria ad alta larghezza di banda è costoso, mentre spostarlo nella memoria dell’host o nello spazio di archiviazione può ridurre i costi, ma introduce nuovi problemi di latenza e pianificazione.

SemiAnalysis afferma inoltre che Google prevede di ottimizzare il decoding speculativo, la predizione di più token, il prefill disaggregato e i carichi di lavoro agentici. Il benchmark iniziale si concentra deliberatamente su una configurazione con un input di 8.000 token e un output di 1.000 token, per rendere gestibile la prima configurazione. I risultati con contesti più lunghi, tracce multi-turno e sessioni che fanno ampio uso della cache potrebbero produrre classifiche diverse.

I dati pubblici riducono il divario di Google sul software per TPU

Per molto tempo è stato difficile per gli sviluppatori esterni valutare i chip di Google, perché le implementazioni TPU più avanzate dell’azienda si basano su sistemi e software sotto il controllo di Google. Ironwood cambia questo scenario commerciale: SemiAnalysis descrive TPUv7 come la prima generazione che Google offre per i carichi di inferenza di altre aziende, tramite acquisti diretti o noleggi su Google Cloud.

La pubblicazione del benchmark arriva inoltre mentre lo stack software esterno di Google comincia a integrarsi con progetti che già dominano il serving di modelli aperti. vLLM e SGLang offrono un ampio supporto a Nvidia e un supporto crescente ad AMD. SemiAnalysis prevede che TorchTPU uscirà dalla beta privata e diventerà open source intorno a ottobre, offrendo così ai manutentori dei framework una base pubblica per aggiungere il supporto TPU più vicino alla data di rilascio di un modello.

La tempistica è importante perché il supporto dei modelli spesso determina la scelta dell’hardware. Un chip può avere costi e consumi favorevoli, ma un operatore potrebbe comunque scegliere Nvidia se il modello più recente, il metodo di quantizzazione, lo scheduler o l’implementazione del decoding speculativo funzionano prima su quella piattaforma. Il successo di TorchTPU si misurerà non solo sul risultato di Qwen3.5, ma anche sulla rapidità con cui supporterà modelli come Kimi K3, GLM5.3 e i sistemi open-weight di Google.

La pubblicazione del 7 settembre non dimostra che Google abbia scalzato Nvidia nell’inferenza. Stabilisce una conclusione più circoscritta e utile: con un carico di lavoro pubblico in FP8 e ipotesi sui costi dell’hardware esterno, Ironwood può generare più token spendendo meno di B200 e B300, mentre Nvidia resta in vantaggio su alcuni tratti della curva delle prestazioni grezze, negli scenari sensibili alla latenza e nel serving FP4.

Per chi acquista infrastrutture, il cambiamento immediato è concreto. TPUv7 non viene più valutata solo sulla base delle dichiarazioni interne di Google o delle specifiche teoriche. Gli operatori possono ora confrontare un modello aperto identificato, un percorso di serving definito e stime esplicite del costo per token con i sistemi Nvidia, per poi decidere se il lavoro software ancora necessario è compatibile con le proprie esigenze di produzione.