In breve
Il codice PyTorch ora può puntare in modo nativo alle TPU di Google, senza un livello di porting separato. Google ha rilasciato TorchTPU come open source il 20 ottobre 2026 alla PyTorch Conference, sviluppato insieme al team PyTorch di Meta. Il codice PyTorch esistente di training e serving passa sulle Cloud TPU con modifiche minime, così i team possono confrontare TPU, GPU e Trainium su costi e qualità prima di impegnare il budget.
Che cosa ha rilasciato Google?
TorchTPU registra la TPU come dispositivo PyTorch a tutti gli effetti: il codice che oggi chiama .to("cuda") può chiamare .to("tpu") mantenendo intatto il ciclo di training. Finora PyTorch sulle TPU passava dal livello separato PyTorch/XLA, che molti team trovavano più difficile da debuggare rispetto al percorso GPU. Nell’annuncio di Google, firmato da Mark Lohmeyer e Bill Jia, si legge che le TPU ora «si affiancano a GPU e CPU come opzione nativa per PyTorch».
Il backend supporta l’esecuzione eager per lo sviluppo e torch.compile per le prestazioni in produzione. In parallelo Google ha pubblicato un’anteprima della TPU Agent Suite, un agente IA di sviluppo che aiuta nell’onboarding, nella diagnosi degli errori e nel tuning dell’inferenza, e ha portato LiteRT (ex TensorFlow Lite) nell’ecosistema PyTorch per esportare i modelli su smartphone, laptop e dispositivi embedded.
Quali strumenti funzionano già con TorchTPU?
La vera notizia è l’ecosistema. Secondo TechCrunch, prima del lancio Google ha lavorato direttamente con Meta, Hugging Face, Inferact (l’azienda dietro vLLM) e RadixArk (lo sviluppatore di SGLang). Secondo Google, lo stack supportato al rilascio è questo:
- Training: ricette TorchTitan per Llama 3, Qwen 3 e FLUX.1; VeRL per il post-training con reinforcement learning (anteprima); Ray per job misti CPU, GPU e TPU.
- Serving: backend TorchTPU per vLLM e SGLang, oltre a llm-d 1.0, il progetto CNCF Sandbox per l’inferenza distribuita sostenuto da Red Hat e IBM.
- Modelli: Hugging Face Transformers v5 si distribuisce sulle TPU con
device_map="tpu"; sono coperti anche Diffusers e TorchRec.
Google cita il risultato di un cliente: Zenteiq ha registrato un throughput di inferenza aggregato quattro volte superiore con llm-d, portando la capacità giornaliera da 1,47 a 5,97 miliardi di token ogni 1.000 chip TPU v6e.
Perché conta un secondo porting di PyTorch?
Il vantaggio di Nvidia poggia in buona parte sul fatto che CUDA sia il target predefinito di PyTorch. Amazon ha attaccato questo standard il 19 ottobre con TorchNeuron per Trainium; Google ha seguito il giorno dopo. Con due hyperscaler che rilasciano backend nativi e riportano il lavoro upstream in PyTorch, un PyTorch indipendente dall’hardware diventa la base attesa e non più un esperimento di un singolo fornitore.
Per chi acquista, l’effetto è potere negoziale. Quando lo stesso codice di modello gira su tre famiglie di acceleratori, prenotazioni GPU, impegni TPU e capacità Trainium diventano voci confrontabili in trattativa.
Che cosa resta da dimostrare?
I dati di utilizzo e throughput provengono da Google e dai suoi partner, non da benchmark indipendenti. Nell’anteprima tecnica di aprile Google stessa ammetteva che lunghezze di sequenza e dimensioni di batch variabili provocano una ricompilazione, e che le prestazioni massime sulle TPU possono ancora richiedere un refactoring del modello. I kernel CUDA personalizzati non si spostano con un flag di dispositivo e le TPU sono disponibili solo in Google Cloud: la portabilità vale tra chip, non tra cloud.
Cosa significa per i team software negli Stati Uniti e nell’UE
I team che addestrano, fanno fine-tuning o servono modelli in PyTorch standard hanno ora una terza opzione realistica per carichi stabili e ad alto volume come inferenza batch, embedding e cicli di fine-tuning. I fattori decisivi saranno il costo per token o per training sui vostri modelli, il profilo di latenza del serving tramite vLLM o SGLang e la capacità disponibile nelle region che siete autorizzati a usare.
Vale la stessa disciplina che ha reso testabile Trainium: scelta del dispositivo in configurazione, nessuna chiamata CUDA hard-coded nel percorso principale e un set di valutazione riproducibile.
Cosa cambia per i team IA in Italia?
Per molte PMI innovative e scale-up italiane il costo del calcolo GPU è la voce più pesante dei progetti di IA generativa, e il tema della sovranità digitale rende delicata ogni nuova dipendenza da un hyperscaler statunitense. TorchTPU abbassa il costo del passaggio tra chip, ma lega i carichi TPU interamente a Google Cloud. Con TorchNeuron per AWS e TorchTPU per Google, la mossa sensata è rendere fin da ora le pipeline PyTorch indipendenti dall’hardware, così da poter scegliere tra fornitori, cloud GPU europei o infrastruttura interna in base al prezzo e ai vincoli.
Sul piano della conformità, cambiare chip non cambia gli obblighi, ma cambia la documentazione. Google Cloud ha region in Italia, a Milano e Torino: prima di un pilota verificate in quali region europee TPU v6e e Ironwood sono effettivamente disponibili per il vostro account, e aggiornate il registro delle attività di trattamento previsto dal GDPR se cambia l’ambiente di elaborazione. Per i progetti della Pubblica Amministrazione, controllate inoltre che il servizio cloud scelto rientri tra quelli qualificati dall’Agenzia per la Cybersicurezza Nazionale (ACN).
Cosa dovrebbero fare i team ML in questo trimestre
- Mappare la dipendenza da CUDA. Elencate kernel personalizzati, librerie solo CUDA e chiamate al dispositivo hard-coded nel codice di training e di serving.
- Rendere il dispositivo un parametro. Gestite la scelta dell’acceleratore di ogni pipeline tramite configurazione, così che le esecuzioni su GPU, TPU e Trainium usino lo stesso codice.
- Partire dal serving. Confrontate un modello di produzione servito via vLLM o SGLang su TPU con il vostro setup GPU attuale, misurando latenza, throughput e costo per milione di token.
- Testare le shape dinamiche. Riproducete traffico reale con prompt di lunghezze diverse per capire se la ricompilazione incide sulla latenza.
- Verificare region e impegni. Confermate la capacità TPU nelle region autorizzate e l’effetto di un passaggio sugli impegni GPU o AWS esistenti e sulla documentazione GDPR.
Domande frequenti
Che cos’è Google TorchTPU?
TorchTPU è un backend PyTorch open source che esegue in modo nativo i modelli PyTorch sulle Cloud TPU di Google. Google lo ha reso pubblico il 20 ottobre 2026, dopo averlo sviluppato insieme al team PyTorch di Meta.
Quanto codice devo modificare per eseguire PyTorch sulle TPU?
Secondo Google, pochissimo: il codice che punta al dispositivo GPU può puntare invece al dispositivo TPU, e Hugging Face Transformers v5 usa device_map="tpu". I kernel CUDA personalizzati e le librerie solo CUDA vanno comunque portati.
In cosa TorchTPU differisce da Amazon TorchNeuron?
Entrambi fanno girare PyTorch in modo nativo su un chip non Nvidia. TorchTPU è pensato per le Cloud TPU di Google e include un agente IA per il porting e LiteRT per l’export verso l’edge; TorchNeuron, annunciato il giorno prima, punta ad AWS Trainium. Ciascuno funziona solo nel proprio cloud.
TorchTPU è pronto per la produzione?
Google e Meta descrivono un uso in produzione e llm-d 1.0 è indicato come pronto per la produzione, ma i dati di prestazione sono dichiarazioni dei fornitori. Avviate un pilota sui vostri modelli e sul traffico reale prima di spostare carichi di produzione. In Italia verificate anche la region di elaborazione e l’aggiornamento del registro dei trattamenti GDPR.
Fonti
Google Cloud — TorchTPU is now open source: run native PyTorch on TPUs (October 20, 2026)
TechCrunch — Google has joined Amazon in attacking Nvidia’s stronghold with AI app developers (October 20, 2026)
Google Developers Blog — TorchTPU: Running PyTorch natively on TPUs at Google scale (April 7, 2026)
Techzine — Google and Meta are making AI chips more accessible with TorchTPU (October 21, 2026)