Google divide le sue TPU in due chip distinti per l'era dell'AI agentiva

Ogni volta che Google annuncia una nuova generazione di TPU, i propri chip personalizzati per l'intelligenza artificiale, la tentazione è concentrarsi sui numeri di picco e leggere la notizia come un altro round della competizione con Nvidia. Con le TPU 8t e TPU 8i, presentate il 22 aprile 2026 a Google Cloud Next, farlo sarebbe un errore. Questa volta Google non sta solo dichiarando chip più veloci: sta cercando di spostare l'asse della competizione dall'acceleratore in sé al comportamento dell'intero sistema quando viene spinto al limite. Migliaia di chip connessi, reti che devono restare stabili, guasti che capitano comunque, e carichi di lavoro sempre più complessi — non più il semplice ciclo «addestra il modello, poi usalo», ma una sequenza continua di richieste, azioni automatizzate, memorie temporanee e modelli che si parlano tra loro.

Una linea di chip che si biforca

Il segnale più importante è organizzativo prima ancora che tecnico: per la prima volta Google divide la linea TPU in due prodotti distinti con obiettivi separati. La TPU 8t nasce per il training, cioè per la fase in cui un modello viene addestrato elaborando enormi quantità di dati. La TPU 8i nasce invece per l'inference, cioè per erogare risposte in tempo reale quando il modello è già in produzione e deve rispondere agli utenti. La distinzione può sembrare ovvia, ma nel mercato degli acceleratori AI si è cercato a lungo un chip «abbastanza buono per tutto». Google sta dicendo che, nell'era dei sistemi agentivi, il chip tuttofaire ha un costo reale: in denaro, in energia e soprattutto in complessità operativa.

La TPU 8t è pensata per chi addestra modelli di grandi dimensioni, dove il tempo di calcolo è direttamente una variabile economica. Google descrive configurazioni che arrivano fino a 9.600 chip collegati in un unico cluster, con una memoria condivisa dell'ordine dei petabyte e una potenza dichiarata di 121 exaflop nella precisione numerica ridotta FP4 — un formato che permette calcoli più veloci sacrificando un po' di precisione, accettabile in molti scenari di addestramento. Rispetto a Ironwood, la generazione precedente presentata a Cloud Next 2025, Google parla di circa 2,8 volte le prestazioni per il training. Ma il dato su cui insiste di più è un altro: una goodput superiore al 97%.

Goodput, la metrica che conta davvero

Goodput è una parola che negli annunci hardware suona quasi burocratica, eppure è una delle poche metriche che descrive davvero il mondo reale. È la frazione del calcolo che finisce effettivamente a fare lavoro utile, invece di restare intrappolata in attese di rete, sincronizzazioni, colli di bottiglia nel trasferimento dati, o ricalcoli dovuti a errori e componenti che si guastano. Il paradosso dei grandi cluster è proprio questo: più chip si aggiungono, più cresce la potenza teorica, ma anche più tempo il sistema passa a «tenersi insieme» — coordinare migliaia di nodi, gestire i guasti, ribilanciare i carichi. Se Google riesce a rendere credibile quel 97% su larga scala, sta offrendo un argomento più forte dei semplici FLOP: la promessa che un cluster enorme non sia una macchina che devi accudire costantemente, ma un'infrastruttura su cui puoi pianificare.

Un chip più veloce non basta se il sistema passa metà del tempo a tenersi insieme

Sul fronte della TPU 8i, l'unità di misura cambia radicalmente: non è «quanti token al secondo riesci a produrre in totale», ma «quanto in fretta riesci a reagire» quando hai molte richieste simultanee, e soprattutto quando quelle richieste sono catene di azioni automatizzate — quello che Google chiama «sciami di agenti», più modelli o istanze dello stesso modello che lavorano in parallelo scambiandosi continuamente stato e risultati intermedi. In questo scenario, la latenza — il tempo che passa tra una richiesta e la risposta — diventa critica quanto la potenza di calcolo grezza.

Più memoria vicina al chip, meno tempi morti

Per rispondere a questa esigenza, Google ha fatto due scelte architetturali precise. La prima riguarda la memoria: la TPU 8i triplica la SRAM on-chip fino a 384 MB, una cache interna velocissima che permette di tenere «a portata di mano» porzioni di dati che altrimenti dovrebbero essere recuperate da memorie più lente. Nell'inference moderna, specialmente con contesti lunghi e richieste che richiedono più passaggi, il tempo si consuma spesso proprio nel recupero e nella gestione di dati intermedi, non solo nel calcolo vero e proprio. Più SRAM significa meno traffico interno e tempi di risposta più stabili anche sotto carico.

La seconda scelta riguarda la topologia di rete tra i chip. La TPU 8i adotta una nuova architettura di interconnessione chiamata Boardfly, distinta dal 3D torus usato storicamente — e mantenuto nella TPU 8t, dove la priorità è massimizzare la banda per spostare grandi quantità di dati. Come ha spiegato Amin Vahdat, Senior Vice President e Chief Technologist di Google Cloud per AI e infrastrutture, la topologia precedente era ottimizzata per il throughput, ma non per minimizzare la latenza da un capo all'altro della rete. Google dichiara un miglioramento fino al 50% nella latenza grazie a Boardfly: meno distanza logica tra chi calcola e chi aspetta il risultato.

La CPU torna centrale nel progetto

C'è un altro aspetto che spesso sfugge negli articoli su questi annunci: il ruolo crescente della CPU come componente progettuale. Google dichiara che sia TPU 8t che 8i useranno esclusivamente host basati su Axion, il processore personalizzato basato su architettura Arm sviluppato internamente per Google Cloud. E sulla TPU 8i il rapporto diventa più generoso: un host CPU ogni due chip TPU, contro configurazioni precedenti più «tirate».

La ragione è concreta: in un data center AI il lavoro non si riduce all'esecuzione del modello. C'è pre-elaborazione dei dati, gestione dell'input/output, orchestrazione dei job, instradamento delle richieste, monitoraggio del sistema. Usando l'analogia di un circuito di Formula 1: la TPU può essere il motore, ma se la corsia dei box è stretta e il team non regge il ritmo, la macchina non gira mai alla velocità promessa. Spostare l'host su un processore Arm personalizzato è anche un modo per controllare costi ed efficienza energetica di quella parte del sistema, che cresce man mano che i modelli AI diventano servizi sempre accesi.

L'efficienza energetica non è più una nota a margine, è la condizione che decide chi può scalare

Ed è proprio sull'energia che Google insiste con più decisione, inquadrandola come condizione di possibilità — non come postilla di sostenibilità. Google dichiara fino al doppio della performance per watt rispetto a Ironwood, abbinando l'annuncio a un ulteriore sviluppo del raffreddamento a liquido nei suoi data center. Non è un tema isolato: anche Nvidia sta spingendo piattaforme rack-scale con raffreddamento a liquido come standard per le sue «AI factory», e sulla piattaforma Vera Rubin NVL72 parla di 3,6 exaflop di inference per rack con un'architettura pensata come sistema integrato. Il consumo energetico non è più un costo che si gestisce a valle: è la metrica che decide chi può scalare e chi no.

Hardware e strategia cloud sono la stessa cosa

Vale la pena chiarire dove finisce l'hardware e dove inizia la strategia commerciale. Per Google, sono inscindibili. TPU 8t e 8i non sono chip venduti sul mercato come componenti: sono capacità erogata come servizio, all'interno di un'offerta che Google chiama AI Hypercomputer, dove convergono storage, rete, software e strumenti di sviluppo. La promessa della goodput è esattamente questo: non ti vendo il picco teorico, ti vendo la costanza operativa.

Il rischio, però, è altrettanto sistemico. Metriche come goodput oltre il 97% o scalabilità fino a centinaia di migliaia di chip sono difficili da verificare dall'esterno, e possono dipendere da condizioni ideali: carichi di lavoro selezionati, uno stack software molto specifico, capacità di rete dedicata, margini operativi che pochi clienti ottengono in modo stabile. Più integrazione può significare più efficienza, ma anche più dipendenza da come Google decide di esporre quella capacità e da quanto il software dell'utente si adatta senza attriti.

Google prova ad attenuare questo punto insistendo sul supporto a framework diffusi come JAX, PyTorch e vLLM — un messaggio esplicito ai team che negli ultimi anni hanno costruito pipeline di MLOps attorno a PyTorch. L'idea è: non devi diventare «un'azienda JAX» per usare le TPU. Nella pratica, però, la compatibilità nominale è solo il primo ostacolo. Contano la maturità dei componenti critici, il supporto alle funzionalità diventate standard nel serving di LLM, gli strumenti di debug e analisi delle prestazioni, e la portabilità dei modelli senza dover riprogettare l'architettura del servizio.

L'inference è già la parte più difficile

C'è un tema che emerge indirettamente quando Google parla di «era degli agenti»: l'inference — cioè l'utilizzo in produzione del modello — non è più un'attività secondaria rispetto all'addestramento. Per molti operatori è già la voce dominante: è continua, richiede latenza prevedibile, deve reggere i picchi di traffico ed è direttamente legata ai ricavi, perché alimenta prodotti e funzioni che gli utenti usano ogni giorno. In questo senso, la TPU 8i non è «la versione economica» del chip: è una risposta alla parte più difficile da industrializzare, quella in cui la qualità percepita dall'utente dipende dai tempi di risposta, non dalla dimensione del modello.

La domanda più concreta, dopo l'annuncio, riguarda disponibilità e costi. Alcune fonti parlano di disponibilità «nei prossimi mesi» per i clienti Google Cloud, ma in assenza di listini e tipologie di istanza dettagliati è difficile tradurre la promessa in una decisione d'acquisto. Il punto di riferimento restano le generazioni precedenti, dove la logica è chiara: sconti per impegni pluriennali, prenotazioni per garantirsi capacità, opzioni più flessibili per chi può aspettare in coda. Perché la TPU 8 diventi davvero la piattaforma di riferimento per l'AI agentiva in cloud, dovrà dimostrare che quel modello di consumo funziona anche per carichi sempre attivi e imprevedibili, non solo per sessioni di addestramento pianificate con largo anticipo.

Il punto non è stabilire chi vince tra TPU e GPU, ma capire cosa sta diventando l'unità di innovazione nell'infrastruttura AI. Google sta dicendo che quell'unità non è il singolo chip, e nemmeno il cluster: è la combinazione di rete, memoria, host, affidabilità e strumenti software che decide quanta potenza teorica si trasforma in lavoro utile. In un mercato dove tutti dichiarano acceleratori più veloci, la variabile più rara rischia di essere quella meno misurabile dagli annunci: la prevedibilità del sistema quando cresce, quando si rompe e quando deve restare sempre acceso.