PyTorch na TPU: Hloubkový pohled na TorchTPU, XLA a Cloud TPU

Home » PYTHON » PyTorch na TPU: Hloubkový pohled na TorchTPU, XLA a Cloud TPU

Spouštění PyTorch na Google TPU již není specializovanou experimentální cestou vyhrazenou pro hrstku expertů.Mezi novými funkcemi od Googlu TorchTPU stack, osvědčený projekt PyTorch/XLA a rostoucí ekosystém nástrojů a frameworků, trénovacích a obslužných modelů na TPU se rychle stává stejně přirozeným jako práce na grafických procesorech NVIDIA. Velkým posunem je, že nyní můžete usilovat o vysoký výkon, obrovské škálování a zároveň mnohem plynulejší vývojářský zážitek.

Tento článek se podrobně zabývá tím, jak PyTorch dnes využívá TPU a kam tento stack směřuje.Rozebereme si architekturu TorchTPU, rozdíly oproti tradičnímu PyTorch/XLA, jak funguje distribuované trénování, kompilace a hardwarová specifika a co to v praxi znamená, pokud migrujete pracovní postupy PyTorch zaměřené na GPU. Pokud žijete ve světě LLM, difúze nebo rozsáhlých doporučovacích systémů, níže uvedené podrobnosti představují přesně ten druh nízkoúrovňové reality, která rozhodne, zda váš TPU poběží hladce nebo ne.

Proč je PyTorch na TPU právě teď důležitý

Moderní pracovní zátěže umělé inteligence přerostly jednoduchou éru „jeden stroj, málo GPU“.Nejmodernější modely se nyní rozprostírají napříč klastry obsahujícími desítky tisíc akcelerátorů a posouvají software tak, aby zvládal extrémní škálovatelnost, spolehlivé distribuované provádění a přenositelný výkon napříč různými čipy a od různých dodavatelů. Infrastruktura AI.

Tenzorové procesorové jednotky (TPU) od Googlu stojí v centru této hranice.Pohánějí interní systémy jako Gemini a Veo, a také velkou část tréninkových a inferenčních úloh zákazníků Google Cloudu. Historicky byly TPU úzce spárovány s JAX a TensorFlow, ale širší ekosystém se silně standardizoval na PyTorch, což vedlo k bolestivému rozdělení: GPU znamenaly „PyTorch + CUDA“, TPU znamenaly „JAX + XLA“.

Odpovědí Googlu je snaha naplno vyvolat dojem, že TPU jsou prvotřídním cílem PyTorchu.TorchTPU si klade za cíl poskytnout nativní a aktivní sémantiku PyTorch s nejvyšším výkonem, zatímco PyTorch/XLA zůstává výkonnou, líně kompilovanou cestou, která je již široce používána v produkčním prostředí. V rámci těchto stacků Cloud TPU, GKE, Vertex AI a komunitní frameworky jako easy-torch-tpu proměňují clustery TPU v přímočarou a skriptovatelnou infrastrukturu pro cokoli od 1B do 70B+ parametrických modelů.

Uvnitř hardwaru TPU: více než jen rychlejší čip

Systém TPU je v podstatě úzce integrovaná struktura čipů, hostitelů a propojení., ne jen jednu akcelerační kartu. Pochopení tohoto rozvržení je nezbytné pro pochopení designu TorchTPU a toho, proč se jeho kompilační možnosti liší od čistých GPU stacků.

Každý hostitelský TPU se připojuje k více čipům TPU prostřednictvím rozhraní Inter-Chip Interconnect (ICI).ICI vytváří 2D nebo 3D topologii torusu s vysokou šířkou pásma, která umožňuje rozsáhlým podům chovat se jako jeden logický akcelerátor. Místo přenášení gradientů přes tradiční síťové stacky se kolektivy pohybují přímo na tomto torusu, což značně zefektivňuje horizontální škálování, jakmile váš software ví, jak tyto kolektivy správně vyjádřit.

V rámci TPU čipu je výpočetní proces rozdělen mezi TensorCores a SparseCores.TensorCores jsou specializované jednovláknové enginy, které vynikají v matematice s hustými maticemi – přesně to, co pohání transformátory, CNN a většinu standardních vrstev hlubokého učení. SparseCores jsou navrženy pro úlohy s nepravidelnými vzory přístupu k paměti, jako jsou embeddingy, gathery/scattery a odlehčené kolektivní operace.

Tato architektura je fantastická pro hluboké učení, ale je náročná na to, jak ji krmíte.Například mnoho implementací transformátorů napevno zadává rozměry hlavice s pozorností na 64. Současné generace TPU obvykle dosahují svého nejlepšího bodu v rozmezí 128–256, což znamená, že pouhé zdvojnásobení rozměru hlavice může dramaticky zlepšit efektivitu násobení matic a využití TensorCore. Přenositelnost tyto hardwarové skutečnosti nevymaže; pouze usnadňuje jejich dosažení.

Z PyTorch/XLA na TorchTPU: dva doplňkové způsoby, jak spustit PyTorch na TPU

PyTorch již dnes může běžet na TPU přes PyTorch/XLA (torch_xla)., který prezentuje TPU jako standardní zařízení PyTorch a pod kapotou kompiluje líné grafy XLA. Mnoho výzkumníků však zjistilo, že ačkoli jsou změny v jejich kódu na papíře drobné, rozdíl v chování oproti dychtivému provádění na GPU může být zarážející.

TorchTPU je nový, nativní backend PyTorch od Googlu, který je navržen tak, aby fungoval jako „skutečný“ PyTorch, nikoli jako obal.Místo nucení PyTorchu do modelu podobného JAXu s všudypřítomnými línými tenzory se TorchTPU opírá o rychlé provádění PyTorchu a moderní kompilační API, jako je torch.compile. Používá SoukroméUžití1 mechanismus zařízení v PyTorchu, takže z vašeho pohledu pracujete pouze s běžným pochodeň.Tensor objekty, které se náhodou nacházejí na TPU.

Klíčový rozdíl mezi těmito dvěma přístupy je styl provedeníPyTorch/XLA standardně používá líné provádění: operace vytvářejí graf, který poté spustí kompilaci XLA, když narazíte na synchronizační bariéru, například krok v trénovací smyčce. TorchTPU je naopak navržen jako „Eager First“ s dalšími režimy, které postupně slučují operace a předávají optimalizované podgrafy do XLA, aniž by vás žádaly o opuštění standardního mentálního modelu PyTorch.

Cloudové TPU, GKE a Vertex AI: páteř infrastruktury

Pod jakýmkoli stackem PyTorch-on-TPU, který si vyberete, se nachází platforma Cloud TPU., který zpřístupňuje vlastní ASIC jako škálovatelné cloudové zdroje vyladěné pro trénování i inferenci. Tyto akcelerátory se používají pro širokou škálu úloh: konverzační agenti, generování kódu, obrazové a mediální modely, řeč, doporučovací systémy a personalizační moduly.

Cloudové TPU jsou úzce integrovány s Google Kubernetes Engine (GKE)., takže můžete plánovat rozsáhlé úlohy PyTorch pomocí standardních primitiv Kubernetes. Dynamický plánovač úloh vám umožňuje najednou vyžádat si celou flotilu akcelerátorů, které potřebujete, a zajistit tak, aby se tisíce čipů TPU spojily a trénovaly nebo obsluhovaly model bez nutnosti ruční orchestrace.

Pro týmy, které chtějí nejjednodušší nájezd, Vertex AI abstrahuje většinu správy clusteru.Můžete cílit na TPU ze spravovaných trénovacích a obslužných pracovních postupů, a to i při použití. Modely založené na PyTorchGoogle Cloud pozicionuje tuto flexibilitu – TPU nebo GPU, spravované nebo DIY Kubernetes – jako přímou odpověď na explodující poptávku po infrastruktuře umělé inteligence ze strany podniků i výzkumných laboratoří.

Hlavní filozofie TorchTPU: „Občanství PyTorch“

Hlavní cíl návrhu TorchTPU je přímočarý: měl by působit jako PyTorch, ne jako cizí framework.Pokud již víte, jak trénovat model na GPU CUDA, měli byste být schopni portovat stejný trénovací skript na TPU s minimálními úpravami kódu a bez přepisování mentálního modelu.

V praxi vypadá ideální migrace téměř komicky jednoduše.Kam byste normálně psali zařízení = pochodeň.zařízení('cuda'), místo toho získáte zařízení TPU z modulu TorchTPU – koncepčně něco jako zařízení = tpu.get_device()—a zavolejte model.to(zařízení) stejně jako na GPU. Váš dopředný průchod, logika optimalizace a způsob, jakým voláte modely Hugging Face, mohou zůstat nezměněny.

Předchozí integrace TPU často nutily PyTorch napodobovat JAX.Silně se spoléhaly na líné tenzory a nutily vás k myšlení ve statických grafech. To narušilo jednu z největších silných stránek PyTorchu: nemohli jste jen tak vložit výtisk doprostřed průchodu dopředu, abyste si prohlédli tvary nebo hodnoty. TorchTPU tento kompromis odmítá. Ponechává si dychtivé chování jako základní linii a buduje výkon kolem něj, místo aby vás žádalo, abyste ho opustili.

Tento princip „občanství PyTorch“ se vztahuje i na ošetřování chyb.Místo kryptických, 500řádkových trasování zásobníku C++ zahrabaných hluboko v zásobníku XLA je cílem vyčistit zpětné vazby Pythonu, které odkazují přímo na problematický řádek ve vaší trénovací smyčce nebo definici modelu. Když žonglujete s modely s mnoha miliardami parametrů a tisíci TPU, toto zlepšení kvality života představuje rozdíl mezi odpolední opravou a dny bezcílného ladění.

Režimy Eager v TorchTPU: Debug, Strict a Fused

Poskytování nativního zážitku z Eager na hardwaru postaveném pro rozsáhlé fúzované grafy není triviální.TorchTPU to řeší tím, že nabízí několik režimů Eager podporovaných sdíleným kompilačním a spouštěcím kanálem, takže můžete plynule přejít od režimu „udělej to funkční“ k režimu „udělej to rychlé“.

Ladění Eager je nejpomalejší, ale nejtransparentnější režim. Odesílá jednu operaci po druhé k TPU a synchronizuje se s CPU po každé operaci. Výkon je záměrně obětován, abyste mohli snadno sledovat NaN, neshody tvarů nebo chyby nedostatku paměti s okamžitou zpětnou vazbou a jasnými trasy zásobníku.

Přísný dychtivý zachovává tuto sémantiku odesílání jedné operace, ale provádí asynchronněTPU a CPU mohou běžet paralelně, dokud uživatelský kód nedosáhne bodu synchronizace, což poskytuje zážitek mnohem bližší standardnímu PyTorchu s podporou GPU, ale stále bez náročných požadavků na kompilaci grafů.

Fused Eager je moment, kdy se věci z hlediska výkonu začnou opravdu zajímavě rozvíjet.TorchTPU sleduje proud operací, které provádíte, a automaticky je spojuje do větších a hustších výpočetních bloků, než je odešle do TPU prostřednictvím XLA. Tento krok dynamické fúze výrazně zvyšuje využití TensorCore a snižuje režijní zatížení paměti, což běžně vede k... Zrychlení o 50–100 % a více oproti Strict Eager bez jakýchkoli změn v kódu modelu.

Všechny tři režimy Eager sdílejí společnou kompilační mezipaměť. které mohou existovat na jednom hostiteli nebo být trvale uloženy na více hostitelích v distribuovaném prostředí. Postupem času, jak se vaše trénovací smyčka stabilizuje a systém vidí stejné vzorce, náklady na kompilaci klesají a vy trávíte více času zkoušením tenzorů místo vytváření spustitelných souborů.

Statická kompilace: torch.compile, XLA a StableHLO

Když potřebujete absolutně špičkový výkon na TPU, TorchTPU se připojí přímo k modernímu kompilačnímu kanálu PyTorch.Modely nebo funkce můžete zabalit pomocí torch.compile(), který zachycuje graf efektů pomocí Torch Dynamo, poté obchází obvyklý backend TorchInductor a předává ovládání XLA.

Volba XLA jako primárního backendu je záměrné rozhodnutí zakořeněné v realitě TPU.XLA byla v průběhu let nasazení napříč TPU pody vylepšována a hluboce chápe průnik husté matematiky a kolektivní komunikace přes ICI torus. TorchTPU mapuje operátory PyTorch přímo do StabilníHLO, tenzorový IR chápaný OpenXLA, pak umožňuje snižujícím průchodům XLA generovat optimalizované binární soubory TPU a znovu používat stejné běhové cesty jako režimy Eager, kdekoli je to možné.

Rozšiřitelnost pro vlastní operátory není až tak důležitáTorchTPU podporuje vlastní jádra definovaná v Pallas a JAX: zdobením funkce JAX něčím jako @torch_tpu.pallas.custom_jax_kernel, můžete do kompilační cesty vložit nízkoúrovňový hardwarově vyladěný kód, aniž byste ztratili výhody globálního optimalizátoru. Pracuje se také na podpoře dalších DSL, jako je Helion, pro ještě flexibilnější tvorbu jádra.

Distribuovaný PyTorch na TPU: DDP, FSDP, DTensor a MPMD

Masivní modely netrénují na jednom akcelerátoru a TorchTPU je postaven s ohledem na tuto realitu.Integruje se přímo se standardními distribuovanými API PyTorch, včetně Distribuovaná data paralelně (DDP), FSDPv2, a DTensora byl ověřen pomocí knihoven třetích stran, které na těchto abstrakcích staví.

Jedním z velkých historických problémů PyTorch/XLA byla jeho striktní zkreslení SPMD (Single Program, Multiple Data - jeden program, více dat).Mnoho reálných trénovacích skriptů PyTorch má mezi ranky malé odchylky – rank 0 může zpracovávat logování, kontrolní body nebo metriky, zatímco ostatní ranky provádějí čistě výpočty. Pro globální grafové zobrazení XLA byl tento druh chování nepraktický a často nutil vývojáře přepisovat kód, aby se vyhnuli odchylkám.

TorchTPU explicitně podporuje scénáře MPMD (více programů, více dat)Pečlivě izoluje a vymezuje rozsah komunikačních primitiv, aby odlišné chování nenarušilo správnost ani nesnížilo výkon. Kdekoli je to možné, stále umožňuje XLA vidět globální obraz distribuovaných výpočtů, aby se překrývala komunikace s výpočetními operacemi, ale již vás nenutí do nerealisticky čistého stylu SPMD.

Způsob, jakým se to propojuje se stávajícími distribuovanými paradigmaty PyTorch, je obzvláště důležitý.Frameworky jako FSDP, DTensor a ekosystémové nástroje, jako je TorchTitan, se spoléhají na… Skupina procesů API pro kolektivy jako all-reduce, all-gather a broadcast. Na GPU se tato volání obvykle řeší jako NCCL. TorchTPU tyto kolektivy zachycuje na vrstvě ProcessGroup a převádí je do kolektivních operací StableHLO, které hardware TPU a ICI torus provádějí nativně. Z pohledu FSDP nebo DTensor se nic nezměnilo – jednoduše vidí jiný backend.

PyTorch/XLA: líné spuštění, synchronizační body a praktické tipy

Přestože TorchTPU je dlouhodobou, plně nativní cestou, PyTorch/XLA zůstává klíčovým nástrojem pro spuštění PyTorchu na TPU i dnes.Pokud jste zvyklí na rychlé provádění CUDA, největším koncepčním posunem u PyTorch/XLA je, že tenzory jsou... línýOperace zaznamenávají graf; skutečné spuštění a kompilace probíhají při explicitní nebo implicitní synchronizaci.

Synchronizační body jsou místa, kde PyTorch/XLA předává sestavený graf do XLA ke kompilaci a spuštění.Mezi typické překážky patří hovory jako torch_xla.sync() nebo nástroje vyšší úrovně, jako například xm.optimizer_step(optimalizátor), které v distribuovaném prostředí krokují optimalizátor a synchronizují přechody napříč zařízeními.

Tento líný model má zásadní dopad na výkonPři prvním spuštění daného grafu (nebo grafu s novými vstupními tvary) platíte náklady na kompilaci, ale následné iterace probíhají mnohem rychleji, pokud struktura zůstává stabilní. Proto je stabilita tvarů – pevné délky sekvencí, konzistentní velikosti dávek – pro úlohy PyTorch/XLA tak důležitá a proč... doplnění vstupů na pevné velikosti je takový běžný vzorec.

Víceprocesní školení na PyTorch/XLA využívá vlastní nástroje pro pohodlíObvykle zabalíte svou základní tréninkovou funkci (například _mp_mnist_fn) a spusťte jej napříč zařízeními pomocí torch_xla.launchNačítání dat je řízeno pomocí torch_xla.distributed.parallel_loader.MpDeviceLoader, který využívá standardní PyTorch DataLoader a zajišťuje, že každý proces vidí jedinečný segment dat při předběžném načítání dávek na příslušné zařízení TPU.

Načítání dat, distribuované provádění a AMP na TPU

Efektivní vstupní kanály jsou u TPU stejně důležité jako u GPU.Na PyTorch/XLA, Zavaděč MpDevice Překrývá načítání dat na straně hostitele a provádění na straně zařízení, přičemž dávky podává přímo do TPU a pomáhá vám vyhnout se dlouhým nečinnostem, zatímco akcelerátor čeká na nová data.

Pro distribuované trénování dělá xm.optimizer_step(optimizer) více než jen krok vanilkového optimalizátoru.Provádí redukce gradientů napříč zařízeními, průměruje je, aplikuje aktualizace vah a zpracovává nezbytnou synchronizaci, takže obvykle nepotřebujete samostatné explicitní volání synchronizace v každé iteraci. Pomocníky pro protokolování, jako například xm.is_master_ordinal(local=False) Zajistěte, aby metriky a kontrolní body zpracovával pouze jeden proces, aby se zabránilo duplicitě.

Automatická smíšená přesnost (AMP) vypadá na TPU trochu jinak než na GPUTPU nativně podporují bfloat16 (BF16), který nabízí mnohem větší rozsah exponentů než float16 a obvykle nevyžaduje explicitní škálování ztrát pro stabilitu. PyTorch/XLA rozšiřuje PyTorch AMP tak, aby automaticky mapoval mezi BF16 a FP32 v případě potřeby, což usnadňuje a zároveň usnadňuje trénování se smíšenou přesností na TPU.

Ukládání modelů má také osvědčený postup specifický pro TPU.I když můžete volat pochodeň.uložit z tenzorů zařízení se obecně doporučuje přesunout stavové slovníky do CPU před serializací při použití PyTorch/XLA, což usnadňuje jejich opětovné načítání na hardwaru bez TPU, jako jsou standardní počítače s GPU.

Tréninkové frameworky Easy-torch-tpu a reálného TPU

Kromě oficiálních stacků komunita vytváří frameworky vyšší úrovně, které usnadňují zavádění TPU.. Jedním příkladem je aklein4/easy-torch-tpu, což je odlehčený trénovací framework vytvořený speciálně pro zjednodušení pracovních postupů PyTorch/XLA v clusterech Google Cloud TPU.

Easy-torch-tpu se prezentuje jako jednodušší a flexibilnější alternativa k rozsáhlým a rigidním kódovým základnám, jako je Hypercomputer/torchprime.Jeho designové priority jsou jasné: snadné nastavení, přímočará přizpůsobitelnost a hladká integrace s gCloud SSH-řízené pracovní postupy v clusterech. Záměrně se zaměřuje na experimenty v „akademickém měřítku“ – modely v rozsahu parametrů 1–10B na čipech s přibližně 32–64 TPU.

Rozšiřitelnost je řešena pomocí podtříd a konfiguračních souborůPřidáním nových podtříd můžete začlenit vlastní architektury, trénovací smyčky, optimalizátory, zavaděče dat a dokonce i vlastní strategie shardingu a rematerializace. To vám umožňuje volně experimentovat a zároveň znovu využívat distribuované a logovací scaffoldingové struktury frameworku.

Rámec se úzce integruje s klíčovými nástroji ekosystémuPodpora vah a zkreslení zjednodušuje sledování experimentů, zatímco integrace Hugging Face zjednodušuje načítání datových sad, stahování předtrénovaných kontrolních bodů a ukládání modelů, které lze později spustit na standardním PyTorch s grafickým procesorem. Repozitář obsahuje instalační dokumentaci, úvodní příklady a aktivně se vyvíjí na základě zpětné vazby od komunity.

Omezení, ladění a úskalí výkonu

I přes všechna tato vylepšení není běh PyTorchu na TPU zcela bezproblémový.Pochopení toho, kde se mohou věci pokazit, vám ušetří spoustu času při práci s rozsáhlými modely nebo dynamickými úlohami.

Rekompilace grafů zůstávají jedním z největších skrytých zabijáků výkonu.Kdykoli se váš výpočetní graf nebo tvary vstupů změní mezi synchronizačními body, XLA může potřebovat překompilaci, což způsobuje znatelné pauzy. To je obzvláště běžné u sekvencí s proměnnou délkou nebo adaptivních velikostí dávek, které jsou běžné v úlohách modelování a generování jazyků.

Nepodporované nebo částečně podporované operátory mohou tiše snižovat výkon.Zatímco PyTorch/XLA a TorchTPU se zaměřují na široké pokrytí operátorů, některé operace ATen zatím nemusí mít nativní snížení XLA. V takových případech se provádění může vrátit zpět na CPU, což je technicky správné, ale může být o řády pomalejší. Vestavěné ladicí nástroje a metriky (jako například torch_xla.debug.metrics) vám pomohou odhalit, kde dochází k výpadkům CPU nebo neočekávaným rekompilacím.

Klasické nástroje pro profilování GPU, jako jsou Nsight a nvprof, nevidí dovnitř jader TPU.Místo toho se k pochopení úzkých míst spoléháte na profilovací hooky specifické pro XLA, běhové metriky TPU a protokolování na vyšší úrovni. Mnoho týmů zjišťuje, že jakmile si osvojí osvědčené postupy (statické tvary, pečlivé načítání dat, monitorování rekompilací), rychle dosáhnou předvídatelného výkonu.

Plán kompilátorů od Googlu se explicitně zaměřuje na tato problematická místa.Práce na pokročilém ohraničeném dynamismu v XLA má umožnit modelům zpracovávat různé délky sekvencí a velikosti dávek bez nutnosti spouštět nové kompilace. Rostoucí knihovna předkompilovaných jader TPU si klade za cíl snížit latenci studeného startu při první iteraci nových grafů.

Plán a ekosystém: směrem k bezproblémovému PyTorch na TPU

Plán vývoje TorchTPU od Googlu je ambiciózní a úzce sladěný s širším ekosystémem PyTorch.Je plánováno veřejné repozitář GitHub s rozsáhlou dokumentací, tutoriály o architektuře a reprodukovatelnými příklady, které zahrnují jak školicí, tak i servisní scénáře.

Integrace s Helion DSL od PyTorch je na obzoru, což by mělo rozšířit možnosti vývojářů pro psaní vlastních TPU jader bez nutnosti ponořovat se do nejhlubších vrstev XLA nebo hardwarově specifického kódu. Nativní, prvotřídní podpora dynamických tvarů prostřednictvím torch.compile je také prioritou, která odráží realitu moderních modelů založených na sekvencích.

Podpora více front je další klíčovou oblastí zájmuMnoho produkčních kódových základen PyTorch se silně spoléhá na asynchronní vzorce provádění a oddělené paměťové/výpočetní toky. Čisté mapování těchto idiomů na TPU bez větších refaktorů výrazně sníží migrační tření u velkých a vyspělých projektů.

Hluboké integrace ekosystémů jsou již v pohybuProbíhá úsilí o ověření silné škálovatelnosti na plnou velikost TPU Podu a o propojení s hlavními systémy založenými na PyTorch, jako jsou vLLM a TorchTitan. Zároveň Google úzce spolupracuje se společností Meta a komunitou PyTorch a zkoumá open-source klíčové části TorchTPU s cílem urychlit jeho přijetí a transparentnost.

To vše se odehrává na pozadí širšího podnikání, kde se kapacita TPU dramaticky zvyšuje.Google Cloud podepisuje další multimiliardové smlouvy na infrastrukturu umělé inteligence, Anthropic plánuje přístup až k milionu TPU (řádově s kapacitou gigawattů) a Google dokonce prodává TPU přímo pro on-premise datová centra. Doby, kdy byly TPU specializovaným, interním zdrojem pouze pro Google, jsou dávno pryč.

Když to všechno sečteme, příběh PyTorch-on-TPU se pozoruhodně rychle posouvá z „bizarní vedlejší cesty“ do „standardní možnosti“.Díky nativnímu eager experience v TorchTPU, osvědčenému línému spouštění PyTorch/XLA, frameworkům jako easy-torch-tpu a bohaté infrastruktuře cloudového TPU kolem nich nyní můžete vzít běžné modely PyTorch – často s pouhou změnou řetězce zařízení – a efektivně je spouštět na některých z největších dostupných superpočítačů s umělou inteligencí. Čím více se stack sbližuje se známými idiomy PyTorch namísto vynucování nových mentálních modelů, tím realističtější je považovat výběr hardwaru spíše za implementační detail než za základní konstrukční omezení.