PyTorch sulle TPU: un'analisi approfondita di TorchTPU, XLA e Cloud TPU.

Casa » Python » PyTorch sulle TPU: un'analisi approfondita di TorchTPU, XLA e Cloud TPU.

Eseguire PyTorch sulle TPU di Google non è più una pratica di nicchia e sperimentale riservata a pochi esperti.. Tra il nuovo di Google Stack TorchTPUGrazie al collaudato progetto PyTorch/XLA e a un ecosistema in continua espansione di strumenti e framework, l'addestramento e la distribuzione di modelli su TPU stanno diventando rapidamente naturali quanto lavorare su GPU NVIDIA. Il grande cambiamento consiste nella possibilità di puntare contemporaneamente a prestazioni elevate, scalabilità elevata e un'esperienza di sviluppo molto più fluida.

Questo articolo analizza in dettaglio come PyTorch sfrutta oggi le TPU e in quale direzione si sta evolvendo lo stack.Analizzeremo l'architettura di TorchTPU, le differenze rispetto al tradizionale PyTorch/XLA, il funzionamento dell'addestramento distribuito, della compilazione e delle specifiche hardware, e cosa ciò significhi in pratica se state migrando flussi di lavoro PyTorch incentrati sulla GPU. Se lavorate nel mondo dei modelli lineari di apprendimento (LLM), della diffusione o dei sistemi di raccomandazione su larga scala, i dettagli che seguono rappresentano esattamente il tipo di realtà di basso livello che determinerà se le vostre esecuzioni TPU saranno veloci o lente.

Perché PyTorch sulle TPU è importante proprio ora

I moderni carichi di lavoro di intelligenza artificiale hanno superato la semplice era "una macchina, poche GPU".. I modelli all'avanguardia si estendono ora su cluster che contengono decine di migliaia di acceleratori, spingendo il software a gestire una scala estrema, un'esecuzione distribuita affidabile e prestazioni portatili su diversi chip e fornitori in Infrastruttura AI.

Le unità di elaborazione tensoriale (TPU) di Google si trovano al centro di questa frontieraAlimentano sistemi interni come Gemini e Veo, nonché una grande parte dei carichi di lavoro di training e inferenza dei clienti di Google Cloud. Storicamente, le TPU erano strettamente associate a JAX e TensorFlow, ma l'ecosistema più ampio si è standardizzato in larga misura su PyTorch, il che ha creato una dolorosa divisione: le GPU significavano "PyTorch + CUDA", le TPU significavano "JAX + XLA".

La risposta di Google è un impegno a tutto campo per far sì che le TPU vengano percepite come un target PyTorch di prim'ordine.TorchTPU mira a fornire una semantica PyTorch nativa e immediata con prestazioni di alto livello, mentre PyTorch/XLA rimane una soluzione potente e a compilazione differita, già ampiamente adottata in produzione. Attorno a questi stack, Cloud TPU, GKE, Vertex AI e framework della community come easy-torch-tpu stanno trasformando i cluster TPU in un'infrastruttura semplice e programmabile per modelli con un numero di parametri che varia da 1 miliardo a oltre 70 miliardi.

All'interno dell'hardware TPU: molto più di un semplice chip più veloce

Un sistema TPU è fondamentalmente un tessuto strettamente integrato di chip, host e interconnessioniNon si tratta di una singola scheda acceleratrice. Comprendere questa configurazione è fondamentale per capire il design di TorchTPU e perché le sue scelte di compilazione differiscono da quelle delle architetture basate esclusivamente su GPU.

Ogni host TPU si connette a più chip TPU tramite un'interconnessione inter-chip (ICI)L'ICI forma una topologia toroidale 2D o 3D ad alta larghezza di banda, che consente ai pod di grandi dimensioni di comportarsi come un singolo acceleratore logico. Invece di trasferire i gradienti attraverso i tradizionali stack di rete, i collettivi viaggiano direttamente su questo toro, rendendo la scalabilità orizzontale molto più efficiente una volta che il software sa come esprimere correttamente tali collettivi.

All'interno di un chip TPU, l'elaborazione è suddivisa tra TensorCore e SparseCore.I TensorCore sono motori specializzati a singolo thread che eccellono nei calcoli con matrici dense, ovvero ciò che alimenta i transformer, le reti neurali convoluzionali (CNN) e la maggior parte dei layer standard di deep learning. Gli SparseCore sono progettati per carichi di lavoro con modelli di accesso alla memoria irregolari, come embedding, gather/scatter e operazioni collettive offloadate.

Questa architettura è fantastica per il deep learning, ma è selettiva su come le vengono forniti i dati.Ad esempio, molte implementazioni di transformer hanno dimensioni della testina di attenzione fisse a 64. Le attuali generazioni di TPU tendono a raggiungere il loro punto ottimale tra 128 e 256, il che significa che raddoppiare semplicemente la dimensione della testina può migliorare drasticamente l'efficienza della moltiplicazione di matrici e l'utilizzo di TensorCore. La portabilità non cancella queste realtà hardware; semplicemente ne facilita l'accesso.

Da PyTorch/XLA a TorchTPU: due modi complementari per eseguire PyTorch su TPU

PyTorch è già in grado di funzionare su TPU oggi tramite PyTorch/XLA (torch_xla)che presenta le TPU come dispositivi PyTorch standard e compila internamente i grafici XLA in modalità lazy. Tuttavia, molti ricercatori hanno scoperto che, sebbene le modifiche al loro codice siano minime sulla carta, la differenza di comportamento rispetto all'esecuzione eager su GPU può risultare fastidiosa.

TorchTPU è il nuovo backend nativo di PyTorch di Google, progettato per offrire un'esperienza simile al "vero" PyTorch, non un wrapper.Invece di forzare PyTorch in un modello simile a JAX con Lazy Tensors ovunque, TorchTPU sfrutta l'esecuzione immediata di PyTorch e le moderne API di compilazione come torch.compile. Utilizza l'estensione Uso privato1 meccanismo del dispositivo in PyTorch, quindi dal tuo punto di vista stai semplicemente lavorando con il normale Tensore torcia oggetti che risiedono su una TPU.

La differenza fondamentale tra i due approcci risiede nello stile di esecuzione.PyTorch/XLA utilizza di default l'esecuzione differita: le operazioni costruiscono un grafo, che poi attiva una compilazione XLA quando si incontra una barriera di sincronizzazione, come ad esempio un passaggio nel ciclo di addestramento. TorchTPU, al contrario, è progettato secondo il principio "Eager First", con modalità aggiuntive che fondono progressivamente le operazioni e trasferiscono i sottografi ottimizzati a XLA senza richiedere di abbandonare il modello mentale standard di PyTorch.

Cloud TPU, GKE e Vertex AI: la spina dorsale dell'infrastruttura

Alla base di qualsiasi stack PyTorch-on-TPU tu scelga c'è la piattaforma Cloud TPUche espone ASIC personalizzati come risorse cloud scalabili ottimizzate sia per l'addestramento che per l'inferenza. Questi acceleratori vengono utilizzati per un'ampia varietà di carichi di lavoro: agenti conversazionaligenerazione di codice, modelli di immagini e media, riconoscimento vocale, sistemi di raccomandazione e motori di personalizzazione.

Le Cloud TPU sono strettamente integrate con Google Kubernetes Engine (GKE).In questo modo è possibile pianificare processi PyTorch su larga scala utilizzando primitive Kubernetes standard. Il Dynamic Workload Scheduler consente di richiedere l'intera flotta di acceleratori necessari in un'unica soluzione, garantendo che migliaia di chip TPU si attivino contemporaneamente per addestrare o eseguire un modello senza necessità di orchestrazione manuale.

Per i team che desiderano un accesso più semplice possibile, Vertex AI semplifica notevolmente la gestione del cluster.È possibile indirizzare le TPU dai flussi di lavoro di training e di distribuzione gestiti, anche quando si utilizza modelli basati su PyTorchGoogle Cloud presenta questa flessibilità – con l'utilizzo di TPU o GPU, Kubernetes gestito o fai-da-te – come una risposta diretta alla crescente domanda di infrastrutture per l'intelligenza artificiale da parte di aziende e laboratori di ricerca.

La filosofia di base di TorchTPU: "Cittadinanza PyTorch"

L'obiettivo progettuale principale di TorchTPU è semplice: deve risultare simile a PyTorch, non un framework estraneo.Se sai già come addestrare un modello su GPU CUDA, dovresti essere in grado di adattare lo stesso script di addestramento alle TPU con modifiche minime al codice e senza dover riscrivere il tuo modello mentale.

In termini pratici, la migrazione ideale appare quasi comicamente semplice.. Dove normalmente scriveresti dispositivo = torcia.dispositivo('cuda'), invece si ottiene un dispositivo TPU dal modulo TorchTPU, concettualmente qualcosa come dispositivo = tpu.get_device()—e chiamare modello.a(dispositivo) Proprio come faresti su GPU. Il tuo passaggio in avanti, la logica dell'ottimizzatore e il modo in cui chiami i modelli di Hugging Face possono rimanere invariati.

Le precedenti integrazioni TPU spesso spingevano PyTorch a imitare JAXSi basavano pesantemente sui Lazy Tensor e ti costringevano a pensare come un grafico statico. Questo ha vanificato uno dei maggiori punti di forza di PyTorch: non potevi semplicemente inserire una stampa nel mezzo del tuo passaggio in avanti per ispezionare forme o valori. TorchTPU rifiuta questo compromesso. Mantiene il comportamento eager come base e costruisce le prestazioni attorno ad esso, invece di chiederti di abbandonarlo.

Questo principio di "cittadinanza PyTorch" si estende anche alla gestione degli errori.Invece di criptici stack trace C++ da 500 righe sepolti nelle profondità dello stack XLA, l'obiettivo è quello di rendere visibili traceback Python chiari che puntino direttamente alla riga incriminata nel ciclo di addestramento o nella definizione del modello. Quando si gestiscono modelli con miliardi di parametri e migliaia di TPU, questo miglioramento della qualità della vita fa la differenza tra una soluzione in un pomeriggio e giorni di debugging senza meta.

Modalità Eager in TorchTPU: Debug, Strict e Fused

Offrire un'esperienza nativa immediata su hardware progettato per grafici fusi di grandi dimensioni non è banaleTorchTPU risolve questo problema offrendo diverse modalità eager supportate da una pipeline di compilazione ed esecuzione condivisa, in modo da poter passare agevolmente da "far funzionare" a "far funzionare velocemente".

Debug Eager è la modalità più lenta ma più trasparente. Invia un'operazione alla volta Il programma invia i dati alla TPU e si sincronizza con la CPU dopo ogni operazione. Le prestazioni vengono intenzionalmente sacrificate per consentire di individuare facilmente NaN, discrepanze di forma o errori di memoria insufficiente, con un feedback immediato e stack trace chiari.

Severo e desideroso mantiene questa semantica di dispatch a singola operazione ma esegue in modo asincronoLa TPU e la CPU possono funzionare in parallelo fino a quando il codice utente non raggiunge un punto di sincronizzazione, offrendo un'esperienza molto più simile a quella di PyTorch eager standard supportato da GPU, ma senza i pesanti requisiti di compilazione del grafo.

Fused Eager è dove le cose si fanno davvero interessanti dal punto di vista delle prestazioni.. TorchTPU osserva il flusso di operazioni eseguite e le fonde automaticamente in blocchi di calcolo più grandi e densi prima di inviarli alla TPU tramite XLA. Questo passaggio di fusione dinamica aumenta significativamente l'utilizzo di TensorCore e riduce il sovraccarico della larghezza di banda della memoria, producendo regolarmente Accelerazione del 50-100%+ rispetto a Strict Eager senza alcuna modifica al codice del modello.

Tutte e tre le modalità eager condividono una cache di compilazione comune che può risiedere su un singolo host o essere reso persistente su più host in una configurazione distribuita. Nel tempo, man mano che il ciclo di addestramento si stabilizza e il sistema rileva gli stessi schemi, il costo di compilazione diminuisce e si impiega più tempo a elaborare i tensori anziché a creare eseguibili.

Compilazione statica: torch.compile, XLA e StableHLO

Quando hai bisogno delle massime prestazioni assolute sulle TPU, TorchTPU si integra direttamente nella moderna pipeline di compilazione di PyTorch.È possibile racchiudere modelli o funzioni con torch.compile()che acquisisce un grafico FX utilizzando Torch Dynamo, quindi bypassa il backend TorchInductor standard e passa il controllo a XLA.

La scelta di XLA come backend principale è una decisione ponderata radicata nella realtà delle TPU.XLA è stato consolidato nel corso di anni di implementazione su pod TPU e comprende a fondo l'intersezione tra matematica densa e comunicazione collettiva sul toro ICI. TorchTPU mappa gli operatori PyTorch direttamente in StableHLO, il tensore IR compreso da OpenXLA, consente quindi ai passaggi di abbassamento di XLA di generare binari TPU ottimizzati, riutilizzando gli stessi percorsi di runtime delle modalità eager ove possibile.

L'estensibilità per operatori personalizzati non è un ripensamento. TorchTPU supporta kernel personalizzati definiti in Pallas e JAX: decorando una funzione JAX con qualcosa come @torch_tpu.pallas.custom_jax_kernelÈ possibile iniettare codice di basso livello ottimizzato per l'hardware nel percorso di compilazione senza perdere i vantaggi dell'ottimizzatore globale. Sono inoltre in corso lavori per supportare ulteriori DSL come Helion per una creazione del kernel ancora più flessibile.

PyTorch distribuito su TPU: DDP, FSDP, DTensor e MPMD

I modelli di grandi dimensioni non vengono addestrati su un singolo acceleratore, e TorchTPU è stato progettato tenendo ben presente questa realtà.Si integra direttamente con le API distribuite standard di PyTorch, tra cui DistributedDataParallel (DDP), FSDPv2e DTensore la sua validità è stata confermata con librerie di terze parti che si basano su tali astrazioni.

Uno dei principali punti dolenti storici di PyTorch/XLA era la sua rigida impostazione SPMD (Single Program, Multiple Data).Molti script di training PyTorch reali presentano piccole divergenze tra i vari rank: il rank 0 potrebbe gestire la registrazione dei log, i checkpoint o le metriche, mentre gli altri rank si occupano esclusivamente di calcoli. Per la vista global-graph di XLA, questo tipo di comportamento risultava scomodo e spesso costringeva gli sviluppatori a riscrivere il codice per evitare divergenze.

TorchTPU supporta esplicitamente gli scenari MPMD (Multiple Program, Multiple Data).Isola e definisce con cura l'ambito delle primitive di comunicazione in modo che un comportamento divergente non comprometta la correttezza o le prestazioni. Ove possibile, consente comunque a XLA di avere una visione globale del calcolo distribuito per sovrapporre la comunicazione al calcolo, ma non impone più uno stile SPMD irrealisticamente puro.

Il modo in cui questo si integra con i paradigmi distribuiti PyTorch esistenti è particolarmente importante. Framework come FSDP, DTensor e strumenti dell'ecosistema come TorchTitan si basano su Gruppo di elaborazione API per operazioni collettive come all-reduce, all-gather e broadcast. Sulle GPU, queste chiamate si risolvono tipicamente in NCCL. TorchTPU intercetta queste operazioni collettive al livello ProcessGroup e le trasforma in operazioni collettive StableHLO, che l'hardware TPU e il toro ICI eseguono in modo nativo. Dal punto di vista di FSDP o DTensor, non è cambiato nulla: semplicemente vedono un backend diverso.

PyTorch/XLA: esecuzione differita, punti di sincronizzazione e consigli pratici

Sebbene TorchTPU rappresenti la soluzione nativa a lungo termine, PyTorch/XLA rimane oggi uno strumento fondamentale per eseguire PyTorch su TPU.. Se sei abituato all'esecuzione eager di CUDA, il più grande cambiamento concettuale con PyTorch/XLA è che i tensori sono pigroLe operazioni registrano un grafico; l'esecuzione effettiva e la compilazione avvengono quando si sincronizza in modo esplicito o implicito.

I punti di sincronizzazione sono i punti in cui PyTorch/XLA consegna il grafo costruito a XLA per la compilazione e l'esecuzione.Le barriere tipiche includono chiamate come torcia_xla.sync() o servizi di livello superiore come xm.optimizer_step(optimizer)che consentono sia di incrementare l'ottimizzatore che di sincronizzare i gradienti tra i dispositivi quando si utilizza una configurazione distribuita.

Questo modello pigro ha importanti implicazioni sulle prestazioni.La prima volta che un dato grafo (o un grafo con nuove forme di input) viene eseguito, si paga un costo di compilazione, ma le iterazioni successive vengono eseguite molto più velocemente finché la struttura rimane stabile. Ecco perché la stabilità della forma, ovvero lunghezze di sequenza fisse e dimensioni di batch costanti, è così importante per i carichi di lavoro PyTorch/XLA e perché riempimento degli input a dimensioni fisse è uno schema così comune.

L'addestramento multi-processo su PyTorch/XLA utilizza i suoi strumenti di convenienza. In genere si avvolge la funzione di allenamento principale (ad esempio, _mp_mnist_fn) e lanciarlo su tutti i dispositivi con torcia_xla.launchIl caricamento dei dati viene gestito tramite torch_xla.distributed.parallel_loader.MpDeviceLoader, che prende un DataLoader PyTorch standard e garantisce che ogni processo veda un frammento di dati univoco, precaricando i batch sul dispositivo TPU appropriato.

Caricamento dati, esecuzione distribuita e AMP su TPU

Pipeline di input efficienti sono altrettanto cruciali per le TPU quanto lo sono per le GPU. Su PyTorch/XLA, MpDeviceLoader Sovrappone il caricamento dei dati lato host e l'esecuzione lato dispositivo, alimentando i batch direttamente alla TPU e contribuendo a evitare lunghi periodi di inattività mentre l'acceleratore attende nuovi dati.

Per l'addestramento distribuito, xm.optimizer_step(optimizer) fa più di un semplice passaggio di ottimizzazione.Esegue riduzioni di gradiente su tutti i dispositivi, ne calcola la media, applica gli aggiornamenti dei pesi e gestisce la sincronizzazione necessaria, quindi in genere non è necessaria una chiamata di sincronizzazione esplicita separata in ogni iterazione. Funzioni di supporto per la registrazione come xm.is_master_ordinal(local=False) Assicurarsi che un solo processo gestisca le metriche e i checkpoint per evitare duplicazioni.

La precisione mista automatica (AMP) appare leggermente diversa sulle TPU rispetto alle GPU.Le TPU supportano nativamente bfloat16 (BF16)che offre un intervallo di esponenti molto più ampio rispetto a float16 e di solito non richiede una scalatura esplicita della perdita per la stabilità. PyTorch/XLA estende PyTorch AMP per mappare automaticamente tra BF16 e FP32 quando necessario, rendendo l'addestramento a precisione mista su TPU semplice e robusto.

Anche il salvataggio dei modelli prevede una best practice specifica per le TPU.. Mentre puoi chiamare torcia.salva dai tensori del dispositivo, si raccomanda generalmente di Spostare i dizionari di stato sulla CPU prima della serializzazione quando si utilizza PyTorch/XLA, ciò semplifica il ricaricamento su hardware non-TPU come le macchine GPU standard.

Easy-torch-tpu e framework di training TPU per il mondo reale

Oltre agli stack ufficiali, la community sta sviluppando framework di livello superiore per rendere le TPU più facili da adottare.. Un esempio è aklein4/easy-torch-tpu, un framework di training leggero creato specificamente per semplificare i flussi di lavoro PyTorch/XLA sui cluster TPU di Google Cloud.

Easy-torch-tpu si propone come un'alternativa più semplice e flessibile a codebase ampie e rigide come Hypercomputer/torchprime.Le sue priorità di progettazione sono chiare: configurazione semplice, personalizzazione diretta e integrazione fluida con gcloud ssh-flussi di lavoro cluster guidati. Si rivolge intenzionalmente a esperimenti su "scala accademica", ovvero modelli con un numero di parametri compreso tra 1 e 10 miliardi, distribuiti su circa 32-64 chip TPU.

L'estensibilità viene gestita tramite sottoclassi e file di configurazione.Aggiungendo nuove sottoclassi, è possibile integrare architetture personalizzate, cicli di addestramento, ottimizzatori, caricatori di dati e persino strategie di sharding e rimaterializzazione su misura. Questo permette di sperimentare liberamente riutilizzando l'impalcatura distribuita e di logging del framework.

Il framework si integra strettamente con i principali strumenti dell'ecosistema.Il supporto per Weights & Biases semplifica il monitoraggio degli esperimenti, mentre l'integrazione con Hugging Face facilita il caricamento dei dataset, il recupero dei checkpoint pre-addestrati e il salvataggio dei modelli, che possono essere successivamente eseguiti su PyTorch standard basato su GPU. Il repository include la documentazione di installazione, esempi di avvio ed è in continua evoluzione grazie al feedback della community.

Limitazioni, debug e insidie ​​prestazionali

Nonostante tutti questi miglioramenti, l'esecuzione di PyTorch su TPU non è ancora completamente priva di intoppi.Capire dove possono sorgere problemi ti farà risparmiare molto tempo quando gestisci modelli complessi o carichi di lavoro dinamici.

La ricompilazione dei grafici rimane uno dei maggiori fattori nascosti che compromettono le prestazioni.Ogni volta che il grafico di calcolo o le forme di input cambiano tra i punti di sincronizzazione, XLA potrebbe dover ricompilare, il che introduce pause evidenti. Questo accade soprattutto con sequenze a lunghezza variabile o dimensioni di batch adattive, comuni nei carichi di lavoro di modellazione e generazione del linguaggio.

Gli operatori non supportati o supportati solo parzialmente possono compromettere silenziosamente le prestazioni.. Mentre PyTorch/XLA e TorchTPU mirano a una copertura ampia degli operatori, alcune operazioni ATen potrebbero non avere ancora riduzioni XLA native. In questi casi, l'esecuzione potrebbe ripiegare sulla CPU, il che è tecnicamente corretto ma può essere di ordini di grandezza più lento. Utilità di debug integrate e metriche (come torch_xla.debug.metricsti aiutano a individuare dove si verificano fallback della CPU o ricompilazioni impreviste.

I classici strumenti di profilazione GPU come Nsight e nvprof non vedono all'interno dei kernel TPUInvece, ci si affida a strumenti di profilazione specifici per XLA, metriche di runtime delle TPU e logging di livello superiore per individuare i colli di bottiglia. Molti team scoprono che, una volta adottate le best practice (forme pressoché statiche, caricamento accurato dei dati, monitoraggio delle ricompilazioni), si raggiunge rapidamente una performance prevedibile.

La roadmap dei compilatori di Google si concentra esplicitamente su questi punti critici.Il lavoro sul dinamismo limitato avanzato all'interno di XLA mira a consentire ai modelli di gestire lunghezze di sequenza e dimensioni di batch variabili senza innescare nuove compilazioni. Una libreria in continua espansione di kernel TPU precompilati punta a ridurre drasticamente la latenza di avvio a freddo alla prima iterazione di nuovi grafi.

Roadmap ed ecosistema: verso un PyTorch senza attriti sulle TPU

Guardando al futuro, la roadmap di Google per TorchTPU è ambiziosa e strettamente allineata con il più ampio ecosistema PyTorch.È prevista la creazione di un repository pubblico su GitHub, completo di documentazione esaustiva, tutorial sull'architettura ed esempi riproducibili che coprono sia scenari di addestramento che di erogazione del servizio.

L'integrazione con Helion DSL di PyTorch è all'orizzonte., che dovrebbe ampliare le opzioni di sviluppo per la scrittura di kernel TPU personalizzati senza addentrarsi nei livelli più profondi di XLA o nel codice specifico dell'hardware. Supporto nativo di prima classe per forme dinamiche tramite torch.compile è inoltre una priorità, a testimonianza delle realtà dei moderni modelli basati sulle sequenze.

Il supporto multi-coda è un altro ambito di interesse fondamentale.Molti codebase PyTorch in produzione si basano fortemente su modelli di esecuzione asincrona e flussi di memoria/calcolo disaccoppiati. Rendere questi paradigmi facilmente mappabili alle TPU senza importanti refactoring ridurrà significativamente le difficoltà di migrazione per progetti grandi e maturi.

Le profonde integrazioni dell'ecosistema sono già in corsoSono in corso sforzi per convalidare la scalabilità completa fino alle dimensioni massime del Pod TPU e per integrarsi con i principali sistemi basati su PyTorch come vLLM e TorchTitan. Allo stesso tempo, Google sta collaborando strettamente con Meta e la comunità PyTorch e sta valutando la possibilità di rendere open source parti chiave di TorchTPU per accelerare l'adozione e la trasparenza.

Tutto ciò si inserisce in un contesto aziendale più ampio in cui la capacità delle TPU sta crescendo in modo esponenziale.Google Cloud sta firmando sempre più accordi multimiliardari per infrastrutture di intelligenza artificiale, Anthropic prevede di accedere a un massimo di un milione di TPU (dell'ordine di un gigawatt di capacità) e Google sta persino vendendo TPU direttamente per i data center on-premise. I tempi in cui le TPU erano una risorsa di nicchia, riservata esclusivamente a Google, sono ormai lontani.

Tirando le somme, la storia di PyTorch su TPU si sta trasformando da "percorso alternativo bizzarro" a "opzione standard" con una rapidità sorprendente.Grazie all'esperienza eager nativa di TorchTPU, all'esecuzione lazy collaudata di PyTorch/XLA, a framework come easy-torch-tpu e alla ricca infrastruttura Cloud TPU che li circonda, ora è possibile utilizzare modelli PyTorch di uso comune, spesso con poco più di una modifica alla stringa del dispositivo, ed eseguirli in modo efficiente su alcuni dei più grandi supercomputer per l'IA disponibili. Quanto più lo stack converge verso i paradigmi familiari di PyTorch anziché imporre nuovi modelli mentali, tanto più diventa realistico considerare la scelta dell'hardware come un dettaglio di implementazione piuttosto che un vincolo di progettazione fondamentale.