Google mette la latenza di inferenza direttamente nel silicio con il TPU 8i, pensato per le interfacce guidate da agenti

Dividere il chip lungo la linea training/inferenza

La TPU di ottava generazione di Google non arriva come un pezzo unico ma come due: la TPU 8t, pensata per il training di modelli massivi, e la TPU 8i, pensata per l'inferenza. Google afferma che entrambi i chip possono gestire vari carichi di lavoro, ma è dalla specializzazione che arrivano i vantaggi reali.

L'azienda racconta di aver previsto questa separazione già alcuni anni fa, puntando sul fatto che, con i modelli frontier destinati alla produzione, la domanda di inferenza avrebbe giustificato un chip dedicato. I due chip hanno bilanciamenti di risorse diversi: l'8t punta su throughput di calcolo e banda di scale-up, mentre l'8i punta sulla banda di memoria per un serving sensibile alla latenza.

Questa divisione conta per chiunque costruisca il livello con cui gli utenti interagiscono davvero. Le economie del training e quelle del serving hanno sempre tirato l'hardware in direzioni opposte; ora Google rende esplicita questa tensione a livello di silicio, invece di chiedere a un solo chip di scendere a compromessi tra le due.

Perché l'8i sembra un budget di latenza fatto hardware

Google inquadra l'era agentica in termini fondamentalmente legati alla reattività:

In questa era degli agenti IA, i modelli devono ragionare sui problemi, eseguire workflow multi-step e imparare dalle proprie azioni in loop continui.Montana Labs

È in questi loop continui che la latenza si accumula. Google è chiaro sul fatto che "le interazioni tra agenti su larga scala amplificano anche le inefficienze più piccole" — uno sciame di agenti specializzati significa molti scambi di andata e ritorno, e ogni millisecondo si moltiplica. Il design dell'8i punta esattamente a questo: abbina 288 GB di memoria ad alta banda a 384 MB di SRAM on-chip (3 volte la generazione precedente) per mantenere il working set di un modello sul chip, e aggiunge un nuovo Collectives Acceleration Engine on-chip che, secondo Google, riduce la latenza on-chip fino a 5 volte.

Google definisce l'obiettivo come l'eliminazione dell'effetto "sala d'attesa" — processori inattivi mentre i dati si spostano. Per chi lavora sul frontend, quel tempo morto è esattamente ciò che si traduce in uno spinner. La scheda tecnica del chip è, di fatto, una risposta a livello hardware alla latenza che definisce l'esperienza utente degli agenti.

KV cache dimensionata direttamente nell'hardware

Il dettaglio più significativo è l'affermazione di co-design di Google: la capacità SRAM dell'8i è stata "dimensionata per l'impronta della KV cache dei modelli di reasoning a scala di produzione". Si tratta di un team hardware che progetta attorno a una struttura dati a runtime che determina quanto contesto conversazionale e di ragionamento un modello può mantenere senza dover ricorrere a memoria più lenta.

Google elenca anche il supporto per i framework che riguardano direttamente lo stack di serving — JAX nativo, MaxText, PyTorch e, in particolare, SGLang e vLLM, i motori di inferenza che i team già usano. Viene offerto anche l'accesso bare-metal per saltare l'overhead della virtualizzazione. Il filo conduttore è che Google sta ottimizzando per il percorso specifico tra un modello e una richiesta in tempo reale, non solo per il throughput puro.

La promessa economica collegata è un miglioramento dell'80% nel rapporto prestazioni/prezzo rispetto alla generazione precedente, che Google traduce come la possibilità di servire quasi il doppio del volume di clienti allo stesso costo. Per un'azienda che gestisce agenti rivolti agli utenti, quel rapporto fa la differenza tra una funzionalità che ha senso economicamente e una che non lo ha.

Cosa significa questo per i team che sviluppano frontend agentici

Entrambi i chip saranno disponibili al pubblico più avanti quest'anno tramite l'AI Hypercomputer di Google, quindi per ora non c'è nulla da costruire concretamente. Ma l'annuncio segnala dove si sta spostando il limite di latenza per gli agenti hosted, e vale la pena leggerlo prima di impegnarsi su un'architettura.

Se l'esperienza utente del tuo agente dipende da loop multi-step rapidi, le scelte di design dell'8i — working set on-chip, un motore di collectives focalizzato sulla latenza, banda di interconnessione raddoppiata per i modelli Mixture-of-Experts — descrivono i vincoli sotto cui Google si aspetta che questi loop funzionino. Il punto pratico per i team frontend e applied è che la latenza che puoi promettere agli utenti sarà sempre più determinata da decisioni hardware a livello di inferenza prese sotto il tuo stack, e gli obiettivi di design pubblicati qui da Google sono un'anticipazione di cosa significherà "abbastanza rapido" quando questi carichi di lavoro verranno serviti su larga scala.