IBM gør Spyre-acceleratoren til en førsteklasses PyTorch-backend

IBM oplyste i et blogindlæg fra IBM Research, udgivet den 26. oktober 2026, at softwareopdateringer, der blev leveret på tværs af PyTorch-økosystemet i anden halvdel af 2026, har gjort deres Spyre-dataflowaccelerator til en førsteklasses PyTorch-backend. Dermed har IBM indfriet en plan, som virksomheden og PyTorch Foundation fremlagde i oktober 2025.

IBM beskriver Spyre som virksomhedens dataflow-accelerator til AI, optimeret til inferens og udviklet til virksomhedsteams, der kører AI sammen med deres applikationer og data på IBM Z-, LinuxONE- og Power-systemer. Dens beregninger med reduceret præcision er målrettet det matrixintensive arbejde i sprogmodeller til tekstgenerering og embeddingmodeller. I modsætning til en traditionel GPU, der udfører kerner som instruktionsstrømme på tværs af grupper af tråde, der afvikles efter en plan, igangsætter Spyre beregninger, efterhånden som data når frem til beregningsenhederne.

I anden halvdel af 2026 udsendte IBM, Red Hat og samarbejdspartnere i PyTorch Foundation, herunder Meta og Hugging Face, opdateringer, der dækkede understøttelse af modeller fra dag ét, hardwareuafhængige modeller i vLLM, løbende regressionstest og test af udgivelser samt integration af enheden som indbygget, fremgår det af indlægget. På PyTorch Conference 2025 oplyste IBM i et indlæg fra IBM Research dateret den 21. oktober 2025, at virksomheden planlagde at udvide understøttelsen af Spyre i 2026, så Spyre kunne indgå som en førsteklasses backend i open source-arbejdsgange for inferens, med fokus på samlede compilerforløb, optimeret generering af kerner og gennemsigtig planlægning på tværs af flere acceleratorer. IBM havde på det tidspunkt taget vLLM i brug som inferenskøretidsmiljø og torch.compile som frontendcompiler til integration af acceleratorer som Spyre, og virksomheden havde bidraget med et Spyre-plugin til vLLM, der muliggør paged attention ved inferens med store sprogmodeller.

En compiler genopbygget på Inductor

Centralt i integrationen står torch-spyre, en PyTorch-backend, der kompilerer almindelig PyTorch-kode til en eksekverbar plan for Spyre. Det meste af modellens logik passerer uændret gennem PyTorch-compileren. Når en operation endnu ikke kan omsættes effektivt til lavere niveau, kan en adapter erstatte den med en matematisk ækvivalent form, som compileren kan håndtere.

I et indlæg fra PyTorch Foundation, udgivet den 13. oktober 2026, beskrev Dave Grove, Olivier Tardieu og IBM Spyre-teamet, hvordan de flyttede torch-spyres torch.compile-backend fra sendnn, en kompileringsstak bygget helt fra bunden, til backend=inductor, en open source-backend, der er bygget ved at udvide PyTorchs egen Inductor. Målt med kodeanalysatoren lizard består sendnn af cirka 273.000 linjer C++- og Python-kode fordelt på 6.170 funktioner, mens Inductor-udvidelsen består af cirka 38.600 linjer Python-kode fordelt på 1.878 funktioner – omkring syv gange færre linjer og lavere kompleksitet pr. funktion, oplyste forfatterne.

Spyre er en 75-watt-accelerator, der tilsluttes via PCIe, og som består af 32 små kerner, der er forbundet i en ring. Hver kerne har sin egen scratchpad på 2 MB i stedet for en delt cache, og data flyttes i faste blokke på 128 byte, kaldet sticks. Compilerarbejdet fokuserede på dataflytning i stick-størrelse, planlægning af scratchpad-hukommelse og tildeling af kerner på kompileringstidspunktet, fremgår det af indlægget.

De rapporterede målinger omfatter en reduktion på 29–69 % i matmul-kernetid som følge af valg af blokinddeling og datalayout, et fald i softmax-kernens medianbehandlingstid fra 32,51 mikrosekunder til 23,67 mikrosekunder – en reduktion på 27 % – takket være planlægning, der tager højde for scratchpad-hukommelse, samt en fusioneret MLP-lignende kerne, der øgede kerneudnyttelsen fra cirka to tredjedele til omkring 80 % og samtidig reducerede kernetiden med cirka 17 %. I en syntetisk graf, der var konstrueret til at belaste disse beslutninger, erstattede en ny relayout på chippen en tur-retur-overførsel til enhedens hukommelse på 80 mikrosekunder med en overførsel mellem kerner på 1,1 mikrosekunder. Indlægget bemærker også, at torch-spyres behov for at registrere enhedsspecifikke dekomponeringer var med til at fremme forbedringer af understøttelsen af Inductor-backends uden for PyTorch-kildekoden. Forbedringerne blev indarbejdet i PyTorch 2.12 via to sammenflettede pull requests.

Integration som indbygget enhed

Spyre bliver en indbygget PyTorch-enhed via PrivateUse1-registrering, som giver tensor.to(“spyre”) en reel enhedsidentitet: PyTorchs allokator sørger for, at tensorer forbliver i enhedens hukommelse, streams giver semantik for rækkefølgen af operationer, og runtimehændelser forbinder afhængige opgaver på tværs af streams. Kortet har 32 kerner, der er forbundet via en ring med høj båndbredde, hver med 2 MB lokal scratchpad-hukommelse, samt op til 128 GB LPDDR5 til tensorer og programmer. Den nuværende runtime tilpasser programmerne ved start ved at erstatte symbolske tensoradresser med faktiske adresser i tre trin i en fast rækkefølge.

I en demonstration med Granite 3.3 8B, batchstørrelse 1 og sekvenslængde 1024 forbedrede det prefill med 9,9 % og decode med 13,6 % at flytte grafkonstruktionen væk fra dataoverførselsstien, oplyste teamet. Da arbejdet også blev fjernet fra afsendelsen af beregningsopgaver, blev den samlede hastighed 1,7 gange højere for prefill og 2,4 gange højere for decode, og cirka tre fjerdedele af forbedringen kom fra beregningsstien.

»Fordelen er, at hverken Spyre eller PyTorch behøver at udgive sig for at være noget andet,« skrev forfatterne i Sådan bygges Spyre som en indbygget PyTorch-enhed, udgivet den 8. oktober 2026. De tilføjede, at Spyre bevarer sin dataflowbaserede afviklingsmodel, mens brugerne får en indbygget PyTorch-enhed med velkendt placering af tensorer, streams og kompilering.

vLLM-portabilitet og forbindelsen til Llm-D

Spyre er en accelerator uden for hovedtræet snarere end en af de GPU-platforme, som AI-software oftest understøtter. Den bruger TorchDynamo til at spore en modelgraf og TorchInductor til at oversætte grafen til målhardwaren. I vLLM gør udvidelsesmekanismer som CustomOp og PluggableLayer det muligt for et hardwareplugin at tilpasse funktionaliteten uden at genimplementere store dele af softwarestakken.

I Hardwareuafhængige modeller i vLLM, der blev offentliggjort den 22. september 2026 af forfattere fra IBM, Meta og Hugging Face, beskrev teamet vLLM’s bevægelse mod hardwaretilpassede, “flade” modeldefinitioner og introducerede hardwareuafhængige lag baseret på fire designprincipper: De skal kunne kompileres, kunne udvides, være adskilt fra hardwaretilpassede kodeveje og være portable. Den første understøttelse er kommet med i vLLM’s hovedgren og kan aktiveres med USE_HW_AGNOSTIC=1 i Transformers-backenden. Løsningen er blevet valideret med Spyre-pluginet uden for hovedtræet på modeller som Gemma 4, Qwen3 og Granite 4.2, og på NVIDIA H100-GPU’er leverede de hardwareuafhængige lag en samlet token-gennemstrømning, der lå inden for 3,4 % af den oprindelige implementerings, målt som det geometriske gennemsnit på tværs af tre nyere modeller, oplyste forfatterne.

Spyres PyTorch-integration er også forbindelsen til llm-d, forklarer IBM’s opslag: llm-d udfører distribueret inferens oven på vLLM på tværs af flere typer acceleratorer, vLLM kommunikerer med hver accelerator via PyTorch, og når en enhed har en fungerende PyTorch-backend, kan et vLLM-hardwareplugin gøre den tilgængelig, så llm-d kan planlægge opgaver på den.

Klargøring fra dag ét og løbende testning

Et opslag af 20. august 2026 fra IBM Spyre Team beskriver HF-adapters, et projekt, der bruger kodeagenter til at udarbejde programrettelser under kørsel, så standardmodeller fra Hugging Face Transformers kan køre på Spyre. Fra midten af april til slutningen af juni 2026 kom 13 forskellige adaptere til at dække 7.960 af de 10.000 mest downloadede indlejringsmodeller fra Hugging Face, og 6.804 af dem består deres ende-til-ende-test på Spyre, fremgår det af opslaget. I et eksempel erstattes aktiveringsfunktionens gelu_new-udtryk torch.pow(x, 3.0) med det matematisk identiske x x x, som torch-spyre-stakken kan oversætte; mennesker står fortsat for diagnosticeringen, lokaliserer fejl, der kun opstår på enheden som følge af fusionerede operationer, og kontrollerer hver agents konklusioner i forhold til ende-til-ende-resultaterne.

I et opslag af 30. september 2026 beskrev ingeniører fra IBM og Red Hat torch-spyres L2-integration med PyTorchs Cross-Repository CI Relay, som udløser nedstrømstest af ændringer i PyTorch og rapporterer resultaterne tilbage til PyTorchs CI-dashboard. Integrationen kombinerer en agentbaseret pipeline i fire faser til valg af test med et deklarativt YAML-rammeværk til genbrug af test, og opgraderingen fra PyTorch 2.13 til 2.14 betød, at man skulle evaluere omkring 4.000 ændrede tests i stedet for titusinder, skrev forfatterne. De tilføjede, at de har til hensigt at samarbejde med PyTorch-teamet om at bidrage med de genanvendelige dele til PyTorch med PyTorch OpenReg som referencepunkt.

For brugere af IBM Z, LinuxONE og Power11 er målet, at de kan hente modeller fra økosystemer som Hugging Face og bruge stort set de samme PyTorch-baserede arbejdsgange, som de ville bruge med Nvidia-GPU’er. Fælles udvidelsespunkter i PyTorch skjuler en stor del af de arkitektoniske forskelle, fremgår det af IBM’s opslag. Forfatterne til opslaget om vLLM sagde, at de planlægger at begynde at inkludere hardwareuafhængige modeller i CI og gradvist gøre denne løsning til standarden for servering af modeller på Spyre.