Ironwood, il nuovo TPU di Google, sposta il centro del progetto sull'inferenza

Un TPU annunciato dal lato del serving, non da quello del training

Per un decennio Google ha presentato i suoi TPU soprattutto in funzione del training. Ironwood viene descritto in modo diverso: è, nelle parole di Google, "il primo progettato specificamente per l'inferenza". È questo il punto centrale, non il numero di flop.

È un passaggio da modelli IA reattivi che forniscono informazioni in tempo reale da interpretare, a modelli che generano in modo proattivo insight e interpretazioni. Questo è ciò che chiamiamo "l'età dell'inferenza", in cui gli agenti IA recuperano e generano dati in modo proattivo.Montana Labs

La lettura pratica per chi costruisce lo strato che gli utenti toccano davvero: Google tratta il costo ricorrente del servire le richieste — ogni query, ogni passo di un agente, ogni recupero di dati — come il carico di lavoro attorno al quale vale la pena progettare il silicio. Il training è una spesa di capitale una tantum; l'inferenza è il costo operativo che cresce con l'uso del prodotto.

Dove si colloca in un prodotto la memoria di 192 GB per chip

La specifica che Google enfatizza per il serving è la memoria, non la potenza di calcolo grezza. Ironwood offre 192 GB di HBM per chip — sei volte Trillium — e una banda di 7,37 TB/s, 4,5 volte il predecessore. Google collega questo dato direttamente all'"elaborazione di modelli e dataset più grandi, riducendo la necessità di trasferimenti di dati frequenti".

Questo conta a livello di singola richiesta perché la latenza dell'inferenza nei modelli grandi è spesso limitata dallo spostamento di pesi e cache key-value, non dal calcolo aritmetico. Più memoria on-chip e più banda sono ciò che evita che una richiesta a contesto lungo o di reasoning si blocchi sullo spostamento dei dati — il tipo di guasto che un team di prodotto percepisce come primi token lenti e streaming a scatti.

Google afferma anche che Ironwood è "progettato per minimizzare lo spostamento di dati e la latenza on-chip durante manipolazioni tensoriali massive". L'accento sulla latenza, di nuovo, è una preoccupazione da serving, non da training orientato al throughput.

SparseCore dice che si tratta di ranking, non solo di chat

Ironwood integra un SparseCore migliorato, che Google descrive come "un accelerator specializzato per l'elaborazione di embedding ultra-grandi, comuni nei carichi di lavoro avanzati di ranking e raccomandazione". L'azienda aggiunge che il supporto ampliato va "oltre il tradizionale dominio dell'IA, arrivando ai settori finanziario e scientifico".

Questo è un segnale su cosa significhi "inferenza" per Google in questo contesto. Non si tratta solo della chat generativa dietro una casella di testo; è anche il meccanismo di raccomandazione e ranking basato su embedding che già sta dietro a prodotti come Search e Gmail su larga scala. Lo stesso chip viene puntato sia sulla risposta dell'LLM sia sul recupero dati che la alimenta — che è la forma della pipeline agentica descritta da Google.

Due formati di pod e Pathways definiscono la scelta reale per i team

Google offre Ironwood in una configurazione da 256 chip e una da 9.216 chip, quest'ultima capace di raggiungere 42,5 Exaflops. La divisione in due formati è la decisione concreta che un cliente Cloud deve affrontare: un pod più piccolo per serving limitato, oppure un pod completo per training e serving all'avanguardia di modelli LLM densi e MoE.

Oltre il singolo pod, Google indica Pathways, il suo runtime costruito da DeepMind, per "orchestrare" centinaia di migliaia di chip. La narrazione sul calcolo distribuito viene proposta come un'astrazione software sopra l'hardware, parte della più ampia architettura AI Hypercomputer.

Il guadagno di efficienza dichiarato — 2 volte le performance per watt rispetto a Trillium, e "quasi 30 volte" rispetto al Cloud TPU del 2018 — viene inquadrato rispetto a un vincolo specifico che Google nomina direttamente: "la disponibilità di energia è uno dei vincoli per fornire capacità di IA". Un pod che arriva a quasi 10 MW rende quel vincolo concreto.

L'implicazione: l'economia dell'inferenza, non la dimensione del modello, diventa il vincolo lato frontend

Il posizionamento di Ironwood indica ai team applicativi dove si sta spostando la pressione. Se Google costruisce il suo accelerator più potente attorno a inferenza, banda di memoria ed efficienza per watt, allora il fattore limitante per lanciare funzionalità IA è sempre più il costo e la latenza del servire richieste su larga scala — non se esista un modello più grande.

Ironwood non è ancora disponibile; Google dichiara che arriverà "più avanti quest'anno", e ricorda che Gemini 2.5 e AlphaFold già oggi girano su TPU. La conclusione concreta è trattare il budget di serving — token, embedding, passi degli agenti per ogni azione dell'utente — come una variabile di design di prima classe, perché la roadmap hardware viene ora disegnata esattamente attorno a quel numero.