Google rilascia TorchTPU open source: PyTorch nativo sulle TPU

Google ha reso open source TorchTPU, il suo stack nativo per far girare PyTorch sulle TPU, e lo ha fatto durante la PyTorch Conference 2026. Il progetto, sviluppato insieme al team PyTorch di Meta, è ora disponibile su GitHub e promette di cambiare un equilibrio che per anni ha pesato sul mercato dell’hardware per l’AI: chi voleva usare le TPU doveva quasi sempre passare da un ecosistema diverso da quello in cui lavora la maggior parte dei ricercatori.

In questo articolo ti spiego che cosa è TorchTPU, come funziona, quali strumenti già lo supportano e perché la mossa è importante per chi sviluppa, addestra o serve modelli di intelligenza artificiale.

Che cosa è TorchTPU e perché Google lo ha rilasciato ora

TorchTPU è lo stack software con cui Google porta PyTorch in modo nativo sulle proprie Tensor Processing Unit. L’annuncio ufficiale è stato pubblicato sul blog di Google Cloud il 20 ottobre 2026 da Mark Lohmeyer e Bill Jia, due dirigenti dell’area infrastrutture AI e ingegneria. Il codice si trova nel repository google-pytorch/torch_tpu.

L’idea di fondo è semplice: le TPU devono diventare un’opzione hardware nativa di PyTorch, esattamente come le GPU e le CPU. Google parla di un modello software e operativo coerente e aperto su tutto il portafoglio di acceleratori.

Il problema che risolve

PyTorch è il framework più usato per la ricerca e, sempre più spesso, anche per la produzione. Le TPU, però, sono nate attorno a un altro percorso software, e portare un progetto PyTorch esistente su questi chip ha richiesto a lungo lavoro extra, adattamenti e competenze specifiche. Il risultato era una barriera pratica: molti team sceglievano le GPU non perché fossero migliori sul caso specifico, ma perché il codice era già scritto per quelle.

TorchTPU punta a togliere questa frizione. Secondo Google, i carichi di lavoro PyTorch esistenti possono girare sulle TPU con modifiche minime al codice e con le API che gli sviluppatori già conoscono.

Eager mode e torch.compile

Dal punto di vista tecnico, lo stack supporta sia la modalità eager, utile per il debug e per la sperimentazione, sia torch.compile, pensato per ottenere prestazioni da produzione, un migliore utilizzo delle TPU e un minore consumo di memoria. Includono il pacchetto le API PyTorch standard, strumenti di diagnostica avanzata e primitive native per il calcolo distribuito.

In pratica, puoi partire da un modello che già funziona, validarlo in eager e poi passare alla compilazione quando ti serve efficienza.

Un ecosistema già pronto: Hugging Face, vLLM, SGLang e Ray

Un nuovo stack vale quanto gli strumenti che lo adottano. Per questo Google insiste sul fatto che TorchTPU arriva già integrato con una lista ampia di progetti: vLLM, SGLang, llm-d, TorchTitan, Ray, TorchRec, Hugging Face e LiteRT.

Hugging Face Transformers v5

Nel caso di Hugging Face, i modelli open weight più diffusi sull’Hub girano in modo nativo su TorchTPU. Con Transformers v5, il passaggio alle TPU si riduce a indicare device_map=”tpu” al momento del caricamento del modello. Anche Diffusers funziona in modo nativo, con eager mode, torch.compile e parallelismo tensoriale per i modelli generativi più grandi distribuiti su più acceleratori. Google precisa inoltre che la suite di test di Transformers viene eseguita ogni notte su infrastruttura TPU, un dettaglio che conta per l’affidabilità nel tempo.

Jeff Boudier di Hugging Face ha spiegato che il supporto nativo nelle librerie principali mette in pratica l’impegno sulla libertà di scelta dell’hardware.

vLLM e SGLang per l’inferenza

Sul fronte dell’inferenza, Google sottolinea che costi e latenza sono ormai i colli di bottiglia principali in produzione. Per questo TorchTPU è integrato nei motori di serving open source più usati.

Con vLLM, realizzato insieme a Inferact tramite il backend vllm-torchtpu, i modelli open weight girano sulle TPU con kernel Pallas personalizzati, continuous batching, quantizzazione e parallelismo multi-chip, senza toccare worker, scheduler e API server già in uso. Con SGLang, sviluppato con RadixArk attraverso il backend sglang-torchtpu, entra in gioco RadixAttention, che riutilizza la KV cache tra richieste diverse così che i prefissi ripetuti nei prompt non vengano ricalcolati.

Il messaggio per chi gestisce servizi di inferenza è chiaro: lo stack che hai oggi può restare, cambia soltanto l’hardware sotto.

llm-d 1.0 e il routing su Kubernetes

Un capitolo a parte riguarda llm-d 1.0, rilasciato con Red Hat e IBM e sostenuto da una comunità di oltre 500 contributori di 25 organizzazioni. È un progetto CNCF Sandbox che collega PyTorch, dove vLLM e SGLang servono i modelli, a Kubernetes. Il router usa un instradamento sensibile alla cache dei prefissi, per mandare ogni richiesta alla replica che già conserva il suo contesto, separa il prefill, che richiede molto calcolo, dal decode, che richiede molta memoria, e aggiunge controllo del flusso multi-tenant, alta affidabilità del router, API v1 stabili e routing basato sulla sessione, utile per gli agenti.

Su Google Kubernetes Engine puoi far girare gli stessi carichi su GPU o su TPU dietro un unico endpoint llm-d.

Il dato di Zenteiq

Google porta anche un risultato di un cliente. Zenteiq, usando GKE Inference Gateway basato su llm-d, riferisce un throughput aggregato di inferenza oltre quattro volte superiore e una capacità giornaliera di token generati passata da 1,47 a 5,97 miliardi ogni 1.000 acceleratori TPU v6e. Si tratta di un dato dichiarato dall’azienda e riportato da Google, non di un benchmark indipendente, e va letto come tale.

Addestramento su larga scala: TorchTitan, VeRL e Ray

TorchTPU non riguarda soltanto l’inferenza. Google lo ha integrato nei framework centrali di PyTorch per addestramento, reinforcement learning e orchestrazione.

TorchTitan sulle TPU Ironwood

TorchTitan, l’implementazione di riferimento nativa PyTorch per l’addestramento distribuito scalabile, ha ora un’integrazione di livello produttivo con TorchTPU. Sfrutta torch.compile, SimpleFSDP compatibile con la compilazione, kernel Pallas specializzati e ottimizzazioni a livello di grafo. Le ricette disponibili coprono modelli densi come Llama 3 70B e 405B, Qwen 3 8B e 32B, modelli Mixture-of-Experts come Qwen 3 235B e transformer di diffusione come FLUX.1 12B.

I numeri più rilevanti sono questi: validazione fino a circa 8.000 TPU Ironwood (TPU v7x) e un utilizzo dei FLOPs del modello fino al 52% su Qwen 3 8B, con scalabilità quasi lineare e stabilità fino a 8.192 chip.

VeRL e il post-training

Per il post-training e l’apprendimento per rinforzo, Google ha contribuito a VeRL con un backend TPU e una ricetta di riferimento end to end, ancora in anteprima. L’architettura separa trainer e sampler, e la ricetta GRPO su dataset di ragionamento matematico mostra come eseguire VeRL sulle TPU senza modificare il codice indipendente dall’hardware di modelli e algoritmi.

Ray per le pipeline miste

Ray ha aggiunto il supporto nativo a TorchTPU. Questo permette di orchestrare elaborazione dei dati, addestramento, RL e serving su CPU, GPU e TPU in un solo flusso di lavoro, assegnando a ogni fase l’acceleratore più adatto con poche righe di configurazione delle risorse.

Dal cloud al dispositivo: LiteRT e l’agente per le TPU

L’annuncio guarda anche oltre il data center. LiteRT, il runtime di Google per l’inferenza on device che un tempo si chiamava TensorFlow Lite, entra nell’ecosistema PyTorch. Con LiteRT-Torch puoi convertire un modello PyTorch con una sola chiamata, sfruttando torch.export() e gli operatori Core ATen, quindi senza riscrivere il codice. Per i modelli linguistici, l’esportazione dei modelli Transformers di Hugging Face avviene verso LiteRT-LM.

I bersagli dichiarati sono Android, iOS, macOS, Windows, Linux, web e dispositivi IoT, con accelerazione su CPU, GPU e NPU dei principali produttori tramite un’unica API.

Google presenta infine una suite di agenti per le TPU, in anteprima iniziale su GitHub. Usa plug-in compatibili con diverse combinazioni di strumenti di coding e modelli per automatizzare onboarding, diagnostica, risposte alle domande degli utenti e ottimizzazione delle prestazioni di inferenza su molti modelli PyTorch.

Perché conta: la guerra del software attorno ai chip AI

Il punto più interessante, per chi segue il settore, non è il singolo componente ma la direzione. Negli ultimi mesi la competizione sull’hardware AI si è spostata sempre più sul software: vince chi rende facile usare i propri chip senza riscrivere tutto. Lo abbiamo visto con Amazon TorchNeuron, che porta PyTorch sui chip Trainium per sfidare il dominio di CUDA, e con Microsoft Maia 300, il nuovo chip per l’inferenza su Azure.

TorchTPU si inserisce nello stesso filone. Il fatto che sia co-sviluppato con Meta, che di PyTorch è il principale custode, dà al progetto una credibilità che un semplice strato di compatibilità non avrebbe. Jana van Greunen, a capo dell’ingegneria PyTorch in Meta, lo ha definito un passo avanti enorme per distribuire i carichi PyTorch sulle TPU.

Che cosa cambia per sviluppatori e aziende

Per un team di ricerca o di prodotto, i vantaggi pratici possibili sono tre. Il primo è la riduzione del costo di migrazione: provare le TPU non richiede più un progetto dedicato. Il secondo è il potere negoziale, perché poter spostare lo stesso codice tra GPU e TPU rende meno vincolante la dipendenza da un singolo fornitore. Il terzo è la flessibilità sull’inferenza, dove il rapporto tra throughput e costo è spesso decisivo.

Restano però alcune cautele. Molte componenti sono ancora in anteprima, come la ricetta VeRL e la suite di agenti, e i dati prestazionali citati provengono da Google e dai suoi partner. Prima di spostare un carico critico conviene misurare sul tuo caso d’uso.

Il collegamento con la strategia TPU di Google

Google sta investendo molto sulle proprie TPU, fino a progetti sperimentali come Project Suncatcher, che porta le prime TPU in orbita. Rendere questi chip accessibili a chi scrive PyTorch è il tassello che mancava per allargare la platea di utenti oltre i team già abituati all’ecosistema di Google.

Come iniziare con TorchTPU

Se vuoi provarlo, il punto di partenza è il repository GitHub del progetto, insieme alla documentazione di Google Cloud dedicata a PyTorch su TPU. Un percorso ragionevole è scegliere un modello open weight che già usi, caricarlo con Transformers v5 impostando il dispositivo TPU, verificare il comportamento in eager mode e solo dopo attivare torch.compile per misurare i guadagni.

Per l’inferenza, valuta di partire da vLLM o SGLang con i nuovi backend, tenendo invariata la tua infrastruttura di serving. Per l’addestramento, le ricette di TorchTitan sono il riferimento più concreto per capire che cosa aspettarti in termini di scalabilità.

Conclusioni

TorchTPU è una mossa tecnica, ma ha un significato strategico chiaro: Google vuole che scegliere le TPU diventi una decisione di costo e prestazioni, non di compatibilità software. Se il progetto manterrà le promesse, l’effetto sarà più concorrenza sull’hardware e più libertà per chi costruisce prodotti basati su modelli open source.

Il mio consiglio è di non aspettare di avere un problema di costi per provarlo: ritaglia mezza giornata, porta un tuo modello su TPU e confronta tempi e spesa con la tua configurazione attuale. Poi raccontaci come è andata e continua a seguirci per gli aggiornamenti sul fronte dei chip e del software per l’AI.

Newsletter gratuita · ogni venerdì

Tutta l'AI della settimana, in 5 minuti, nella tua email

• Le guide e le notizie della settimana, divise per rubrica
• Solo ciò che conta, verificato e spiegato in italiano
• Niente spam, ti cancelli con un clic

La tua email Iscriviti gratis

Ho letto l'informativa privacy e voglio ricevere la newsletter.

Preferisci i social? Seguici:

Seguici su Facebook X LinkedIn