PyTorch på TPU-er: Dypdykk i TorchTPU, XLA og Cloud TPU

Home » Python » PyTorch på TPU-er: Dypdykk i TorchTPU, XLA og Cloud TPU

Å kjøre PyTorch på Google TPU-er er ikke lenger en nisjebasert, eksperimentell vei forbeholdt en håndfull eksperterMellom Googles nye TorchTPU-stabel, det kamptestede PyTorch/XLA-prosjektet, og et voksende økosystem av verktøy og rammeverk, trenings- og serveringsmodeller på TPU-er, blir raskt like naturlig som å jobbe med NVIDIA GPU-er. Det store skiftet er at du nå kan sikte mot høy ytelse, stor skala og en mye smidigere utvikleropplevelse samtidig.

Denne artikkelen dykker dypt inn i hvordan PyTorch utnytter TPU-er i dag og hvor stacken er på vei.Vi skal pakke ut TorchTPU-arkitekturen, forskjellene mot tradisjonell PyTorch/XLA, hvordan distribuert trening, kompilering og maskinvarespesifikasjoner fungerer, og hva dette betyr i praksis hvis du migrerer GPU-sentriske PyTorch-arbeidsflyter. Hvis du lever i verdenen av LLM-er, diffusjon eller storskala anbefalingssystemer, er detaljene nedenfor akkurat den typen lavnivåvirkelighet som vil avgjøre om TPU-en din kjører uten problemer.

Hvorfor PyTorch på TPU-er er viktig akkurat nå

Moderne AI-arbeidsmengder har vokst ut av den enkle «én maskin, få GPU-er»-æraenToppmoderne modeller strekker seg nå over klynger som inneholder titusenvis av akseleratorer, og presser programvare til å håndtere ekstrem skala, pålitelig distribuert utførelse og bærbar ytelse på tvers av forskjellige brikker og leverandører i AI-infrastruktur.

Googles Tensor-prosessorenheter (TPU-er) ligger i hjertet av denne grensen.De driver interne systemer som Gemini og Veo, samt en stor andel av Google Cloud-kundenes opplærings- og inferensarbeidsmengder. Historisk sett var TPU-er tett parret med JAX og TensorFlow, men det bredere økosystemet har standardisert seg sterkt på PyTorch, noe som skapte en smertefull splittelse: GPU-er betydde «PyTorch + CUDA», TPU-er betydde «JAX + XLA».

Googles svar er en full gass-innsats for å få TPU-er til å føles som et førsteklasses PyTorch-målTorchTPU har som mål å gi deg innebygd, ivrig PyTorch-semantikk med førsteklasses ytelse, mens PyTorch/XLA fortsatt er en kraftig, lettkompilert metode som allerede er bredt tatt i bruk i produksjon. Rundt disse stakkene gjør Cloud TPU, GKE, Vertex AI og fellesskapsrammeverk som easy-torch-tpu TPU-klynger om til en enkel, skriptbar infrastruktur for alt fra 1B til 70B+ parametermodeller.

Inne i TPU-maskinvaren: mer enn bare en raskere brikke

Et TPU-system er i bunn og grunn et tett integrert stoff av brikker, verter og sammenkoblinger., ikke bare et enkelt akseleratorkort. Å forstå dette oppsettet er viktig for å forstå TorchTPUs design og hvorfor kompilatorvalgene skiller seg fra rene GPU-stabler.

Hver TPU-vert kobles til flere TPU-brikker via en Inter-Chip Interconnect (ICI)ICI danner en 2D- eller 3D-torustopologi med høy båndbredde, som lar store poder oppføre seg som en enkelt logisk akselerator. I stedet for å sende gradienter gjennom tradisjonelle nettverksstabler, kjører kollektiver direkte på denne torusen, noe som gjør utskalering mye mer effektiv når programvaren din vet hvordan den skal uttrykke disse kollektivene riktig.

Innenfor en TPU-brikke er databehandlingen delt mellom TensorCores og SparseCoresTensorCores er spesialiserte, enkelttrådede motorer som utmerker seg i tett matrisematematikk – akkurat det som driver transformere, CNN-er og de fleste standard dyp læringslag. SparseCores er designet for arbeidsbelastninger med uregelmessige minnetilgangsmønstre, for eksempel innebygging, samlinger/spredninger og avlastede kollektive operasjoner.

Denne arkitekturen er fantastisk for dyp læring, men den er kresen når det gjelder hvordan du mater den.For eksempel bruker mange transformatorimplementeringer hardkodede oppmerksomhetshodedimensjoner på 64. Nåværende TPU-generasjoner har en tendens til å nå sitt beste punkt ved 128–256, noe som betyr at det å doble hodedimensjonen kan forbedre matrisemultiplikasjonseffektiviteten og TensorCore-utnyttelsen dramatisk. Portabilitet sletter ikke disse maskinvarerealitetene; det gjør det bare enklere å nå dem.

Fra PyTorch/XLA til TorchTPU: to komplementære måter å kjøre PyTorch på TPU-er på

PyTorch kan allerede kjøre på TPU-er i dag via PyTorch/XLA (torch_xla), som presenterer TPU-er som standard PyTorch-enheter og kompilerer late XLA-grafer under panseret. Mange forskere har imidlertid funnet ut at selv om endringene i koden deres er små på papiret, kan forskjellen i oppførsel kontra GPU-ivrig utførelse føles rystende.

TorchTPU er Googles nye, innebygde PyTorch-backend designet for å føles som «ekte» PyTorch, ikke en innpakning.I stedet for å tvinge PyTorch inn i en JAX-lignende modell med Lazy Tensors overalt, lener TorchTPU seg på PyTorchs ivrige utførelse og moderne kompilerings-API-er som torch.compile. Den bruker Privatbruk1 enhetsmekanismen i PyTorch, så fra ditt perspektiv jobber du bare med vanlige fakkel.Tensor objekter som tilfeldigvis lever på en TPU.

Hovedforskjellen mellom de to tilnærmingene er utførelsesstilenPyTorch/XLA bruker som standard lat utførelse: operasjoner bygger opp en graf, som deretter utløser en XLA-kompilering når du treffer en synkroniseringsbarriere, for eksempel et trinn i treningsløkken din. TorchTPU er derimot utformet som «Eager First», med tilleggsmoduser som gradvis fusjonerer operasjoner og overfører optimaliserte delgrafer til XLA uten å be deg om å forlate den vanlige PyTorch-mentale modellen.

Cloud TPU, GKE og Vertex AI: infrastrukturryggraden

Under enhver PyTorch-on-TPU-stakk du velger, finner du Cloud TPU-plattformen., som eksponerer tilpassede ASIC-er som skalerbare skyressurser som er innstilt for både trening og inferens. Disse akseleratorene brukes til et bredt spekter av arbeidsbelastninger: samtaleagenter, kodegenerering, bilde- og mediemodeller, tale, anbefalingssystemer og personaliseringsmotorer.

Cloud TPU-er er tett integrert med Google Kubernetes Engine (GKE), slik at du kan planlegge PyTorch-jobber i stor skala ved hjelp av standard Kubernetes-primitiver. Den dynamiske arbeidsbelastningsplanleggeren lar deg be om hele flåten av akseleratorer du trenger på én gang, slik at tusenvis av TPU-brikker kommer online sammen for å trene eller betjene en modell uten manuell orkestrering.

For team som ønsker den enkleste påkjørselen, abstraherer Vertex AI bort mesteparten av klyngeadministrasjonen.Du kan målrette TPU-er fra administrerte opplærings- og serveringsbearbeidingsflyter, inkludert når du bruker PyTorch-baserte modellerGoogle Cloud posisjonerer denne fleksibiliteten – TPU-er eller GPU-er, administrerte eller DIY-Kubernetes – som et direkte svar på den eksploderende etterspørselen etter AI-infrastruktur fra både bedrifter og forskningslaboratorier.

TorchTPUs kjernefilosofi: «PyTorch-borgerskap»

Det sentrale designmålet til TorchTPU er enkelt: det skal føles som PyTorch, ikke som et fremmed rammeverk.Hvis du allerede vet hvordan du trener en modell på CUDA GPU-er, bør du kunne portere det samme treningsskriptet til TPU-er med minimale koderedigeringer og uten å omskrive den mentale modellen din.

I praksis ser den ideelle migrasjonen nesten komisk enkel utDer du vanligvis ville skrevet enhet = lommelykt.enhet('cuda'), får du i stedet en TPU-enhet fra TorchTPU-modulen – konseptuelt noe sånt som enhet = tpu.get_device()– og ring modell.til(enhet) akkurat som du ville gjort på GPU. Din fremoverpassering, optimaliseringslogikken og måten du kaller inn i Hugging Face-modeller kan forbli uendret.

Tidligere TPU-integrasjoner presset ofte PyTorch til å imitere JAXDe var sterkt avhengige av late tensorer og tvang deg til statisk graftenkning. Det ødela en av PyTorchs største styrker: du kunne ikke bare sette inn et trykk midt i fremoverpasseringen for å inspisere former eller verdier. TorchTPU avviser dette avveiningen. Den beholder ivrig atferd som grunnlinje og bygger ytelse rundt den, i stedet for å be deg om å forlate den.

Dette «PyTorch-borgerskapsprinsippet» gjelder også for feilhåndteringI stedet for kryptiske, 500-linjers C++-stakkspor begravd dypt i XLA-stakken, er målet å avdekke rene Python-sporinger som peker direkte til den problematiske linjen i treningsløkken eller modelldefinisjonen din. Når du sjonglerer modeller med flere milliarder parametere og tusenvis av TPU-er, er denne forbedringen av livskvaliteten forskjellen mellom en ettermiddagsreparasjon og dager med målløs feilsøking.

Ivrige moduser i TorchTPU: Feilsøking, Strict og Fused

Å levere en innebygd, ivrig opplevelse på maskinvare bygget for store, sammenslåtte grafer er ikke trivielt.TorchTPU løser dette ved å tilby flere ivrige moduser støttet av en delt kompilerings- og utførelsespipeline, slik at du kan gå smidig fra «få det til å fungere» til «få det til å fungere raskt».

Feilsøkingsivrig er den tregeste, men mest transparente modusen. Den sender én operasjon om gangen til TPU-en og synkroniserer med CPU-en etter hver operasjon. Ytelsen ofres bevisst, slik at du enkelt kan spore opp NaN-er, formavvik eller feil på grunn av tomt minne med umiddelbar tilbakemelding og tydelige stakkspor.

Streng ivrig beholder denne semantikken for enkeltoperasjonsforsendelse, men utfører asynkrontTPU-en og CPU-en kan kjøre parallelt inntil brukerkoden treffer et synkroniseringspunkt, noe som gir en opplevelse som er mye nærmere standard GPU-støttet PyTorch, men fortsatt uten tunge krav til grafkompilering.

Fused Eager er der ting blir virkelig interessante fra et ytelsesperspektivTorchTPU observerer strømmen av operasjoner du utfører og slår dem automatisk sammen til større, tettere beregningsbiter før de sendes til TPU-en via XLA. Dette dynamiske fusjonstrinnet øker TensorCore-utnyttelsen betydelig og reduserer minnebåndbreddeoverhead, noe som rutinemessig gir 50–100 %+ hastighetsøkninger i forhold til Strict Eager uten endringer i modellkoden.

Alle tre ivrige modusene deler en felles kompileringsbuffer som kan ligge på én enkelt vert eller gjøres persistent på tvers av flere verter i et distribuert oppsett. Over tid, etter hvert som treningsløkken stabiliserer seg og systemet ser de samme mønstrene, synker kompileringskostnadene, og du bruker mer tid på å knuse tensorer i stedet for å bygge kjørbare filer.

Statisk kompilering: torch.compile, XLA og StableHLO

Når du trenger absolutt topp ytelse på TPU-er, kobler TorchTPU seg direkte til den moderne PyTorch-kompileringsrørledningen.Du kan pakke inn modeller eller funksjoner med fakkel.kompilere(), som fanger opp en FX-graf ved hjelp av Torch Dynamo, og deretter omgår den vanlige TorchInductor-backend og overfører kontrollen til XLA i stedet.

Å velge XLA som primær backend er en bevisst avgjørelse forankret i TPU-virkelighetenXLA har blitt herdet over årevis med distribusjon på tvers av TPU-poder, og den forstår dypt skjæringspunktet mellom tett matematikk og kollektiv kommunikasjon over ICI-torusen. TorchTPU kartlegger PyTorch-operatorer direkte inn i StabilHLO, tensoren IR som forstås av OpenXLA, lar deretter XLAs senkingspass generere optimaliserte TPU-binærfiler, og gjenbruke de samme kjøretidsbanene som de ivrige modusene der det er mulig.

Utvidbarhet for tilpassede operatorer er ikke en ettertankeTorchTPU støtter tilpassede kjerner definert i Pallas og JAX: ved å dekorere en JAX-funksjon med noe sånt som @torch_tpu.pallas.custom_jax_kernel, kan du injisere maskinvarejustert kode på lavt nivå i kompileringsbanen uten å miste fordelene med den globale optimaliseringen. Det arbeides også med å støtte flere DSL-er som Helion for enda mer fleksibel kjerneredigering.

Distribuert PyTorch på TPU-er: DDP, FSDP, DTensor og MPMD

Massive modeller trener ikke på en enkelt akselerator, og TorchTPU er bygget med den virkeligheten i sentrumDen integreres direkte med PyTorchs standard distribuerte API-er, inkludert Distribuerte dataparallelle (DDP), FSDPv2og DTensor, og har blitt validert med tredjepartsbiblioteker som bygger på disse abstraksjonene.

Et av de store historiske smertepunktene med PyTorch/XLA var den strenge SPMD-bias (Single Program, Multiple Data)Mange PyTorch-opplæringsskript i den virkelige verden har små avvik mellom ranger – rang 0 håndterer kanskje logging, kontrollpunkter eller beregninger, mens andre ranger utfører ren beregning. For XLAs globale grafvisning var denne typen oppførsel vanskelig og tvang ofte utviklere til å omskrive kode for å unngå avvik.

TorchTPU omfavner eksplisitt MPMD-scenarier (Multiple Program, Multiple Data)Den isolerer og måler kommunikasjonsprimitiver nøye, slik at divergerende oppførsel ikke forstyrrer korrektheten eller dreper ytelsen. Der det er mulig, lar den fortsatt XLA se et globalt bilde av den distribuerte beregningen for å overlappe kommunikasjon med beregning, men den tvinger deg ikke lenger inn i en urealistisk ren SPMD-stil.

Måten dette passer inn i eksisterende PyTorch-distribuerte paradigmer er spesielt viktig.Rammeverk som FSDP, DTensor og økosystemverktøy som TorchTitan er avhengige av Prosessgruppe API for kollektiver som all-reduce, all-gather og broadcast. På GPU-er løses disse kallene vanligvis til NCCL. TorchTPU fanger opp disse kollektivene på ProcessGroup-laget og senker dem ned i StableHLO-kollektive operasjoner, som TPU-maskinvaren og ICI-torusen kjører naturlig. Fra FSDP- eller DTensors perspektiv har ingenting endret seg – de ser bare en annen backend.

PyTorch/XLA: lat utførelse, synkroniseringspunkter og praktiske tips

Selv om TorchTPU er den langsiktige, fullstendig native banen, er PyTorch/XLA fortsatt et viktig verktøy for å kjøre PyTorch på TPU-er i dag.Hvis du er vant til CUDAs ivrige utførelse, er det største konseptuelle skiftet med PyTorch/XLA at tensorer er latOperasjoner registrerer en graf; faktisk utførelse og kompilering skjer når du eksplisitt eller implisitt synkroniserer.

Synkroniseringspunkter er der PyTorch/XLA overleverer den oppbygde grafen til XLA for kompilering og utførelse.Typiske barrierer inkluderer anrop som torch_xla.sync() eller verktøy på høyere nivå som f.eks. xm.optimizer_step(optimizer), som både trinnvis justerer optimaliseringen din og synkroniserer gradienter på tvers av enheter når du er i et distribuert oppsett.

Denne late modellen har store ytelsesmessige implikasjonerFørste gang en gitt graf (eller en graf med nye inputformer) kjøres, betaler du en kompileringskostnad, men påfølgende iterasjoner kjører mye raskere så lenge strukturen forblir stabil. Det er derfor formstabilitet – faste sekvenslengder, konsistente batchstørrelser – er så viktig for PyTorch/XLA-arbeidsbelastninger, og hvorfor utfylling av innganger til faste størrelser er et så vanlig mønster.

Flerprosessopplæring på PyTorch/XLA bruker sine egne praktiske verktøyDu pakker vanligvis inn kjernetreningsfunksjonen din (for eksempel _mp_mnist_fn) og lanser den på tvers av enheter med torch_xla.launchDatainnlasting håndteres via torch_xla.distribuert.parallel_loader.MpDeviceLoader, som tar en standard PyTorch DataLoader og sørger for at hver prosess ser et unikt dataskjær samtidig som den forhåndshenter batcher til riktig TPU-enhet.

Datalasting, distribuert utførelse og AMP på TPU-er

Effektive input-pipelines er like kritiske på TPU-er som på GPU-erPå PyTorch/XLA, MpDeviceLoader overlapper datainnlasting på vertssiden og utførelse på enhetssiden, mater batcher direkte til TPU-en og hjelper deg med å unngå lange inaktive perioder mens akseleratoren venter på nye data.

For distribuert trening gjør xm.optimizer_step(optimizer) mer enn et vanlig optimaliseringstrinnDen utfører gradient all-reduces på tvers av enheter, beregner gjennomsnittet, bruker vektoppdateringene og håndterer nødvendig synkronisering, slik at du vanligvis ikke trenger et separat eksplisitt synkroniseringskall i hver iterasjon. Loggingshjelpere som xm.is_master_ordinal(local=Usann) Sørg for at bare én prosess håndterer målinger og kontrollpunkter for å unngå duplisering.

Automatisk blandet presisjon (AMP) ser litt annerledes ut på TPU-er enn på GPU-erTPU-er har innebygd støtte bfloat16 (BF16), som tilbyr et mye større eksponentområde enn float16 og vanligvis ikke krever eksplisitt tapskalering for stabilitet. PyTorch/XLA utvider PyTorch AMP til å automatisk kartlegge mellom BF16 og FP32 der det er nødvendig, noe som gjør blandet presisjonstrening på TPU-er både enkel og robust.

Lagring av modeller har også en TPU-spesifikk beste praksisSelv om du kan ringe fakkel.save fra enhetstensorer, anbefales det generelt å flytt tilstandsdiktater til CPU før serialisering når du bruker PyTorch/XLA, noe som gjør dem enklere å laste inn på maskinvare uten TPU, for eksempel standard GPU-maskiner.

Enkle TPU-opplæringsrammeverk og TPU-opplæringsrammeverk for virkelige formål

I tillegg til de offisielle plattformene bygger fellesskapet rammeverk på høyere nivå for å gjøre det enklere å ta i bruk TPU-er.. Et eksempel er aklein4/easy-torch-tpu, et lettvekts opplæringsrammeverk laget spesielt for å forenkle PyTorch/XLA-arbeidsflyter på Google Cloud TPU-klynger.

Easy-torch-tpu posisjonerer seg som et enklere og mer fleksibelt alternativ til store, rigide kodebaser som Hypercomputer/torchprime.Designprioriteringene er klare: enkelt oppsett, enkel tilpasning og problemfri integrering med gcloud ssh-drevne klyngearbeidsflyter. Den retter seg bevisst mot eksperimenter i «akademisk skala» – modeller i parameterområdet 1–10B over omtrent 32–64 TPU-brikker.

Utvidbarhet håndteres via underklassing og konfigurasjonsfilerVed å legge til nye underklasser kan du legge til dine egne arkitekturer, treningsløkker, optimaliseringsverktøy, datalastere og til og med tilpassede strategier for sharding og rematerialisering. Dette lar deg eksperimentere fritt mens du gjenbruker rammeverkets distribuerte og logging-stillas.

Rammeverket integreres tett med viktige økosystemverktøyStøtte for vekter og skjevheter gjør eksperimentsporing enkelt, mens integrering med Hugging Face forenkler lasting av datasett, henting av forhåndstrente kontrollpunkter og lagring av modeller som senere kan kjøres på standard GPU-basert PyTorch. Repositoriet inneholder installasjonsdokumentasjon, eksempler på oppstart og er i aktiv utvikling med tilbakemeldinger fra fellesskapet.

Begrensninger, feilsøking og ytelsesfallgruver

Selv med alle disse forbedringene er det ikke helt problemfritt å kjøre PyTorch på TPU-er ennå.Å forstå hvor ting kan gå galt vil spare deg for mye tid når du jobber med store modeller eller dynamiske arbeidsbelastninger.

Grafrekompileringer er fortsatt en av de største skjulte ytelsesdreperneHver gang beregningsgrafen eller input-figurene endres mellom synkroniseringspunkter, kan det hende at XLA må kompileres på nytt, noe som introduserer merkbare pauser. Dette er spesielt vanlig med sekvenser med variabel lengde eller adaptive batchstørrelser, som er vanlige i språkmodellering og genereringsarbeidsbelastninger.

Operatorer som ikke støttes eller delvis støttes kan stille redusere ytelsenSelv om PyTorch/XLA og TorchTPU sikter mot bred operatørdekning, har kanskje ikke noen ATen-operasjoner innebygde XLA-senkninger ennå. I slike tilfeller kan utførelsen falle tilbake til CPU, noe som er teknisk korrekt, men kan være betydelig tregere. Innebygde feilsøkingsverktøy og målinger (som torch_xla.debug.metrics) hjelper deg med å oppdage hvor CPU-fallbacks eller uventede rekompileringer skjer.

Klassiske GPU-profileringsverktøy som Nsight og nvprof ser ikke innsiden av TPU-kjernerI stedet stoler du på XLA-spesifikke profileringskroker, TPU-kjøretidsmålinger og logging på høyere nivå for å forstå flaskehalser. Mange team opplever at når de først tar i bruk beste praksis (statiske former, nøye datalasting, overvåking av rekompileringer), konvergerer de raskt mot forutsigbar ytelse.

Googles kompilatorveikart retter seg eksplisitt mot disse smertepunkteneArbeid med avansert begrenset dynamikk i XLA er ment å la modeller håndtere varierende sekvenslengder og batchstørrelser uten å utløse nye kompileringer. Et voksende bibliotek med forhåndskompilerte TPU-kjerner har som mål å redusere kaldstartforsinkelsen på den første iterasjonen av nye grafer.

Veikart og økosystem: mot friksjonsfri PyTorch på TPU-er

Googles TorchTPU-veikart er ambisiøs og tett i tråd med det bredere PyTorch-økosystemet fremover.Et offentlig GitHub-arkiv er planlagt, komplett med omfattende dokumentasjon, arkitekturveiledninger og reproduserbare eksempler som spenner over både opplærings- og serveringscenarioer.

Integrasjon med PyTorchs Helion DSL er på horisonten, som skal utvide utvikleralternativene for å skrive tilpassede TPU-kjerner uten å dykke ned i de dypeste lagene av XLA eller maskinvarespesifikk kode. Innebygd, førsteklasses støtte for dynamiske former via torch.compile er også en prioritet, som gjenspeiler realitetene til moderne sekvensbaserte modeller.

Støtte for flere køer er et annet viktig fokusområdeMange PyTorch-produksjonskodebaser er i stor grad avhengige av asynkrone utførelsesmønstre og frakoblede minne-/beregningsstrømmer. Å gjøre disse idiomene tydelig kartlagt til TPU-er uten større refaktorering vil redusere migreringsfriksjonen betydelig for store, modne prosjekter.

Dype økosystemintegrasjoner er allerede i gangDet pågår arbeid med å validere sterk skalering til full TPU Pod-størrelse, og å koble til store PyTorch-baserte systemer som vLLM og TorchTitan. Samtidig samarbeider Google tett med Meta og PyTorch-fellesskapet, og utforsker åpen kildekode for viktige deler av TorchTPU for å akselerere adopsjon og åpenhet.

Alt dette skjer mot et større forretningsbakgrunn der TPU-kapasiteten skaleres dramatisk.Google Cloud signerer flere milliardavtaler for AI-infrastruktur, Anthropic planlegger tilgang til opptil en million TPU-er (i størrelsesorden en gigawatt med kapasitet), og Google selger til og med TPU-er direkte for lokale datasentre. Dagene da TPU-er var en nisjebasert, intern ressurs kun for Google er for lengst forbi.

Alt i alt beveger PyTorch-on-TPU-historien seg bemerkelsesverdig raskt fra en «sære sidevei» til et «standardalternativ»Med TorchTPUs innebygde brukervennlighet, PyTorch/XLAs kamptestede, late utførelse, rammeverk som easy-torch-tpu og den rike Cloud TPU-infrastrukturen rundt dem, kan du nå ta vanlige PyTorch-modeller – ofte med lite mer enn endring av enhetsstrengen – og kjøre dem effektivt på noen av de største AI-superdatamaskinene som er tilgjengelige. Jo mer stakken konvergerer mot kjente PyTorch-idiomer i stedet for å tvinge frem nye mentale modeller, desto mer realistisk blir det å behandle maskinvarevalg som en implementeringsdetalj snarere enn en grunnleggende designbegrensning.