IBM gör Spyre-acceleratorn till en förstklassig PyTorch-backend

I ett blogginlägg från IBM Research som publicerades den 26 oktober 2026 uppgav IBM att programvaruuppdateringar som lanserats i PyTorch-ekosystemet under andra halvåret 2026 har gjort företagets dataflödesaccelerator Spyre till en förstklassig PyTorch-backend. Därmed har en plan som IBM och PyTorch Foundation presenterade i oktober 2025 förverkligats.

IBM beskriver Spyre som sin dataflödesaccelerator för AI, optimerad för inferens och utformad för företagsteam som kör AI tillsammans med sina applikationer och data på IBM Z-, LinuxONE- och Power-system. Dess beräkningar med reducerad precision är inriktade på det matristunga arbete som språkmodellgenerering och inbäddningsmodeller kräver. Till skillnad från en konventionell GPU, som kör kärnor som instruktionsströmmar över schemalagda grupper av trådar, startar Spyre beräkningar när data når dess beräkningsenheter.

Under andra halvåret 2026 lanserade IBM, Red Hat och samarbetspartner inom PyTorch Foundation, däribland Meta och Hugging Face, uppdateringar för modellstöd från dag ett, hårdvaruoberoende modeller i vLLM, kontinuerlig regressionstestning och releasetestning samt inbyggd enhetsintegration, enligt inlägget. Vid PyTorch Conference 2025 uppgav IBM i ett inlägg från IBM Research daterat den 21 oktober 2025 att företaget planerade att utöka stödet för Spyre under 2026. Spyre skulle ingå som en förstklassig backend i arbetsflöden för inferens med öppen källkod, med fokus på enhetliga kompileringsvägar, optimerad generering av kärnor och transparent schemaläggning över flera acceleratorer. IBM hade då infört vLLM som sin inferenskörmiljö och torch.compile som frontendkompilator för integrering av acceleratorer som Spyre. Företaget hade också bidragit med en Spyre-insticksmodul för vLLM som möjliggör paged attention vid inferens med stora språkmodeller.

En kompilator ombyggd med Inductor

Kärnan i integreringen är torch-spyre, en PyTorch-backend som kompilerar vanlig PyTorch-kod till en körbar plan för Spyre. Det mesta av en modells logik passerar oförändrad genom PyTorch-kompilatorn. Om en operation ännu inte kan kompileras effektivt kan en adapter ersätta den med en matematiskt likvärdig form som kompilatorn kan hantera.

I ett inlägg från PyTorch Foundation som publicerades den 13 oktober 2026 beskrev Dave Grove, Olivier Tardieu och IBM Spyre Team hur de flyttade torch-spyres torch.compile-backend från sendnn, en kompileringsstack som byggts helt från grunden, till backend=inductor, en backend med öppen källkod som byggts genom att utöka PyTorchs egen Inductor. Mätningar med kodanalysatorn lizard visar att sendnn omfattar ungefär 273 000 rader C++- och Python-kod fördelade på 6 170 funktioner, medan Inductor-utökningen omfattar ungefär 38 600 rader Python-kod fördelade på 1 878 funktioner – omkring 7 gånger färre rader och lägre komplexitet per funktion, uppgav författarna.

Spyre är en accelerator på 75 watt som ansluts via PCIe. Den består av 32 små kärnor som är sammankopplade i en ring. Varje kärna har ett eget 2 MB-scratchpadminne i stället för en delad cache, och data flyttas i fasta segment på 128 byte som kallas sticks. Enligt inlägget fokuserade kompilatorarbetet på dataförflyttning på sticknivå, planering av scratchpadminnet och tilldelning av kärnor vid kompilering.

Bland de redovisade mätresultaten finns en minskning på 29–69 % av körtiden för matrisproduktkärnor genom val av blockindelning och minneslayout, en minskning av medianens körtid för softmax-kärnor från 32,51 mikrosekunder till 23,67 mikrosekunder – en minskning på 27 % – tack vare schemaläggning som tar hänsyn till scratchpadminnet, samt en sammanslagen MLP-liknande kärna som höjde kärnutnyttjandet från ungefär två tredjedelar till cirka 80 % och samtidigt minskade körtiden med omkring 17 %. I en syntetisk graf som konstruerats för att sätta dessa val på prov ersatte en ny omfördelning av data på chipet en tur-och-retur-överföring via enhetsminnet på 80 mikrosekunder med en förflyttning mellan kärnor på 1,1 mikrosekunder. Inlägget noterar också att torch-spyres behov av att registrera enhetsspecifika dekompositioner bidrog till förbättringar av stödet för Inductor-backendlösningar utanför huvudkodbasen. Förbättringarna införlivades sedan i PyTorch 2.12 genom två sammanslagna pull-förfrågningar.

Integrering som inbyggd enhet

Spyre blir en inbyggd PyTorch-enhet genom registrering med PrivateUse1, vilket ger tensor.to(“spyre”) en faktisk enhetsidentitet: PyTorchs allokerarlagring håller tensorerna kvar på enheten, strömmar ger semantik för ordningsföljd och körtidshändelser kopplar samman beroende arbete mellan strömmar. Kortet har 32 kärnor som är sammankopplade med en ring med hög bandbredd, var och en med 2 MB lokalt scratchpadminne, samt upp till 128 GB LPDDR5 för tensorer och program. I den nuvarande körtidsmiljön modifieras programmen vid start: symboliska tensoradresser ersätts med faktiska adresser i tre steg i bestämd ordning.

I en demonstration med Granite 3.3 8B, batchstorlek 1 och sekvenslängd 1024 förbättrades prefill med 9,9 % och avkodning med 13,6 % när grafkonstruktionen flyttades bort från dataöverföringsvägen, uppgav teamet. När arbetet även togs bort från beräkningsdispatchen blev den totala hastigheten 1,7 gånger högre för prefill och 2,4 gånger högre för avkodning. Ungefär tre fjärdedelar av förbättringen kom från beräkningsvägen.

”Fördelen är att varken Spyre eller PyTorch behöver låtsas vara något annat”, skrev författarna i Att bygga Spyre som en inbyggd PyTorch-enhet, som publicerades den 8 oktober 2026. De tillade att Spyre behåller sin dataflödesbaserade körmodell, samtidigt som användarna får en inbyggd PyTorch-enhet med välbekant placering av tensorer, strömmar och kompilering.

Portabilitet i vLLM och kopplingen till Llm-D

Spyre är en accelerator utanför huvudträdet, snarare än en av de GPU-plattformar som AI-programvara oftast stöder. Den förlitar sig på TorchDynamo för att spåra en modellgraf och på TorchInductor för att kompilera grafen för målhårdvaran. I vLLM gör utökningsmekanismer som CustomOp och PluggableLayer det möjligt för ett hårdvaruplugin att anpassa beteendet utan att behöva återskapa stora delar av programvarustacken.

I Hårdvaruoberoende modeller i vLLM, som publicerades den 22 september 2026 av författare från IBM, Meta och Hugging Face, beskrev teamet hur vLLM går mot hårdvaruspecifika, ”platta” modelldefinitioner och presenterade hårdvaruoberoende lager som bygger på fyra designprinciper: de ska kunna kompileras, vara utbyggbara, vara frikopplade från hårdvaruspecifika kodvägar och vara portabla. Stöd i ett tidigt skede har införts i vLLM:s huvudgren och kan aktiveras med USE_HW_AGNOSTIC=1 i transformers-backenden. Lösningen har validerats med Spyres plugin utanför huvudträdet på modeller som Gemma 4, Qwen3 och Granite 4.2. På NVIDIA H100-GPU:er uppnådde de hårdvaruoberoende lagren en total token-genomströmning som låg inom 3,4 procent från den ursprungliga implementationen, mätt som det geometriska medelvärdet för tre nya modeller, rapporterade författarna.

Spyres PyTorch-integration är också det som kopplar lösningen till llm-d, förklarar IBM i inlägget: llm-d kör distribuerad inferens ovanpå vLLM över flera typer av acceleratorer, vLLM når varje accelerator via PyTorch, och när en enhet väl har en fungerande PyTorch-backend kan ett vLLM-hårdvaruplugin exponera den så att llm-d kan schemalägga arbete på den.

Aktivering från dag ett och kontinuerlig testning

I ett inlägg från 20 augusti 2026 beskriver IBM Spyre-teamet HF-adapters, ett projekt som använder kodningsagenter för att ta fram körningspatchar som gör det möjligt att köra vanliga Hugging Face Transformers-modeller på Spyre. Från mitten av april till slutet av juni 2026 kom 13 olika adaptrar att täcka 7 960 av de 10 000 mest nedladdade inbäddningsmodellerna från Hugging Face. Av dessa klarar 6 804 sina heltäckande tester på Spyre, rapporterar inlägget. Ett exempel ersätter aktiveringsfunktionens torch.pow(x, 3.0) i gelu_new med det matematiskt identiska x x x, som torch-spyre-stacken kan kompilera. Människor står fortfarande för diagnostiken: de lokaliserar fel som bara uppstår på enheten och som orsakas av sammanslagna operationer, och kontrollerar varje agents slutsatser mot resultaten från heltäckande tester.

I ett inlägg från den 30 september 2026 beskrev ingenjörer från IBM och Red Hat torch-spyres L2-integration med PyTorchs Cross-Repository CI Relay. Den utlöser tester i nedströmsprojekt när ändringar görs i PyTorchs huvudprojekt och rapporterar resultaten tillbaka till PyTorchs CI-instrumentpanel. Integrationen kombinerar en agentbaserad pipeline i fyra steg för testurval med ett deklarativt YAML-ramverk för återanvändning av tester. När PyTorch uppgraderades från 2.13 till 2.14 behövde man därför utvärdera ungefär 4 000 ändrade tester i stället för tiotusentals, skrev författarna. De tillade att de avser att samarbeta med PyTorch-teamet för att föra över de återanvändbara delarna till PyTorchs huvudprojekt, med PyTorch OpenReg som utgångspunkt.

För användare av IBM Z, LinuxONE och Power11 är målet att de ska kunna hämta modeller från ekosystem som Hugging Face och använda i stort sett samma PyTorch-baserade arbetsflöden som med Nvidia-GPU:er. Gemensamma utökningspunkter i PyTorch döljer då en stor del av de arkitektoniska skillnaderna, enligt IBM:s inlägg. Författarna till vLLM-inlägget uppgav att de planerar att börja inkludera hårdvaruoberoende modeller i CI och gradvis göra den lösningen till standard för att köra modeller på Spyre.