IBM gjør Spyre-akseleratoren til en førsteklasses PyTorch-bakende

IBM opplyste i et blogginnlegg fra IBM Research publisert 26. oktober 2026 at programvareoppdateringer som ble levert i PyTorch-økosystemet i andre halvdel av 2026, har gjort dataflyt-akseleratoren Spyre til en førsteklasses PyTorch-bakende. Dermed har IBM realisert planen som IBM og PyTorch Foundation la fram i oktober 2025.

IBM beskriver Spyre som sin dataflytbaserte AI-akselerator, optimalisert for inferens og utviklet for bedriftsteam som kjører AI sammen med applikasjonene og dataene sine på IBM Z-, LinuxONE- og Power-systemer. Beregninger med redusert presisjon er rettet mot det matriseintensive arbeidet i språkmodeller for generering og embedding, og i motsetning til en konvensjonell GPU, som utfører kjerner som instruksjonsstrømmer på tvers av planlagte trådgrupper, starter Spyre beregninger etter hvert som dataene når beregningsenhetene.

I andre halvdel av 2026 lanserte IBM, Red Hat og samarbeidspartnerne i PyTorch Foundation, blant dem Meta og Hugging Face, oppdateringer for å støtte modeller fra første dag, maskinvareuavhengige modeller i vLLM, kontinuerlig regresjons- og utgivelsestesting samt integrering som innebygd enhet, står det i innlegget. På PyTorch Conference 2025 opplyste IBM i et innlegg fra IBM Research datert 21. oktober 2025 at selskapet planla å utvide Spyre-støtten i 2026, slik at Spyre skulle delta som en førsteklasses bakende i arbeidsflyter for inferens med åpen kildekode, med vekt på enhetlige kompilatorløp, optimalisert generering av kjerner og transparent planlegging på tvers av flere akseleratorer. IBM hadde da tatt i bruk vLLM som inferensruntime og torch.compile som frontend-kompilator for integrering av akseleratorer som Spyre, og hadde bidratt med en Spyre-plugin for vLLM som muliggjør paged attention ved inferens med store språkmodeller.

En kompilator bygget opp på nytt med Inductor

Kjernen i integreringen er torch-spyre, en PyTorch-bakende som kompilerer vanlig PyTorch-kode til en kjørbar plan for Spyre. Mesteparten av logikken i en modell går uendret gjennom PyTorch-kompilatoren. Når en operasjon ennå ikke kan senkes effektivt, kan en adapter erstatte den med en matematisk ekvivalent form som kompilatoren kan håndtere.

I et innlegg fra PyTorch Foundation publisert 13. oktober 2026 beskrev Dave Grove, Olivier Tardieu og IBM Spyre Team hvordan de flyttet torch-spyres torch.compile-bakende fra sendnn, en kompileringsstakk bygget helt fra grunnen av, til backend=inductor, en åpen kildekode-bakende som er utviklet ved å bygge videre på PyTorchs egen Inductor. Målt med kodeanalysatoren lizard består sendnn av omtrent 273 000 linjer C++ og Python fordelt på 6 170 funksjoner, mens Inductor-utvidelsen består av omtrent 38 600 linjer Python fordelt på 1 878 funksjoner – rundt sju ganger færre linjer og lavere kompleksitet per funksjon, rapporterte forfatterne.

Spyre er en 75-watts akselerator tilkoblet via PCIe, bygget av 32 små kjerner koblet sammen i en ring. Hver kjerne har sin egen hurtigbuffer på 2 MB i stedet for en delt hurtigbuffer, og data flyttes i blokker på fast 128 byte, kalt «sticks». Ifølge innlegget var kompilatorarbeidet konsentrert om dataflytting på stick-nivå, planlegging av hurtigbufferen og tildeling av kjerner ved kompilering.

Rapporterte målinger omfatter en reduksjon på 29–69 % i kjøretiden for matmul-kjerner som følge av valg av blokkdeling og datalayout, en reduksjon i median kjøretid for softmax-kjerner fra 32,51 mikrosekunder til 23,67 mikrosekunder – en nedgang på 27 % – gjennom planlegging som tar hensyn til hurtigbufferen, og en sammenslått kjerne av MLP-typen som økte kjerneutnyttelsen fra omtrent to tredeler til rundt 80 %, samtidig som kjøretiden for kjernen ble redusert med rundt 17 %. I en syntetisk graf utformet for å sette disse valgene på prøve erstattet en ny omorganisering av data på brikken en tur-retur-overføring til enhetsminnet på 80 mikrosekunder med en overføring mellom kjerner på 1,1 mikrosekunder. Innlegget påpeker også at behovet torch-spyre hadde for å registrere enhetsspesifikke dekomponeringer, bidro til forbedringer av støtten for Inductor-bakender utenfor treet. Disse forbedringene ble tatt inn i PyTorch 2.12 gjennom to sammenslåtte pull requests.

Integrering som innebygd enhet

Spyre blir en innebygd PyTorch-enhet gjennom registrering med PrivateUse1, som gir tensor.to(“spyre”) en reell enhetsidentitet: lagring administrert av PyTorchs allokator holder tensorer på enheten, strømmer gir ordningssemantikk, og kjøretidshendelser kobler sammen avhengige oppgaver på tvers av strømmer. Kortet har 32 kjerner koblet sammen med en ring med høy båndbredde, hver med en lokal hurtigbuffer på 2 MB, og opptil 128 GB LPDDR5 for tensorer og programmer. Den nåværende kjøretidsløsningen oppdaterer programmer ved oppstart og erstatter symbolske tensoradresser med faktiske adresser i tre ordnede trinn.

I en demonstrasjon med Granite 3.3 8B, batchstørrelse 1 og sekvenslengde 1024 forbedret det å flytte grafbyggingen ut av dataoverføringsløpet prefill med 9,9 % og decode med 13,6 %, rapporterte teamet. Da dette arbeidet også ble fjernet fra utsendelsen av beregningsoppgaver, ble den samlede hastighetsøkningen 1,7 ganger for prefill og 2,4 ganger for decode, og omtrent tre fjerdedeler av gevinsten kom fra beregningsløpet.

«Gevinsten er at verken Spyre eller PyTorch trenger å utgi seg for å være noe annet», skrev forfatterne i Å bygge Spyre som en innebygd PyTorch-enhet, publisert 8. oktober 2026. De la til at Spyre beholder sin dataflytbaserte kjøremodell, samtidig som brukerne får en innebygd PyTorch-enhet med velkjent plassering av tensorer, strømmer og kompilering.

vLLM-portabilitet og forbindelsen til Llm-D

Spyre er en akselerator som ligger utenfor kildetreet, og ikke en av GPU-plattformene som oftest støttes av AI-programvare. Den bruker TorchDynamo til å spore en modellgraf og TorchInductor til å oversette grafen for målmaskinvaren. I vLLM gjør utvidelsesmekanismer som CustomOp og PluggableLayer det mulig for en maskinvaretillegg å tilpasse funksjonaliteten uten å måtte implementere store deler av programvarestakken på nytt.

I Maskinvareuavhengige modeller i vLLM, publisert 22. september 2026 av forfattere fra IBM, Meta og Hugging Face, beskrev teamet hvordan vLLM beveger seg bort fra maskinvarespesifikke, «flate» modelldefinisjoner, og presenterte maskinvareuavhengige lag bygget på fire designprinsipper: kompilerbare, utvidbare, isolert fra maskinvarespesifikke baner og portable. Tidlig støtte er nå tilgjengelig i hovedgrenen til vLLM og kan aktiveres med USE_HW_AGNOSTIC=1 på transformers-bakenden. Løsningen er validert med Spyre-tillegget utenfor kildetreet på modeller som Gemma 4, Qwen3 og Granite 4.2. På NVIDIA H100-GPU-er leverte de maskinvareuavhengige lagene en samlet token-gjennomstrømning som lå innenfor 3,4 % av den opprinnelige implementasjonen, målt som det geometriske gjennomsnittet på tvers av tre nyere modeller, opplyste forfatterne.

IBM-innlegget forklarer også at Spyres PyTorch-integrasjon er måten løsningen kobles til llm-d på: llm-d kjører distribuert inferens oppå vLLM på tvers av flere typer akseleratorer, vLLM kommuniserer med hver akselerator via PyTorch, og når en enhet har en fungerende PyTorch-bakende, kan et vLLM-maskinvaretillegg gjøre den tilgjengelig slik at llm-d kan planlegge arbeid på den.

Aktivering fra dag én og kontinuerlig testing

Et innlegg fra 20. august 2026 fra IBM Spyre Team beskriver HF-adapters, et prosjekt som bruker kodeagenter til å utarbeide kjøretidsoppdateringer som gjør det mulig å kjøre standardmodeller fra Hugging Face Transformers på Spyre. Fra midten av april til slutten av juni 2026 dekket 13 ulike adaptere 7 960 av de 10 000 mest nedlastede innebyggingsmodellene fra Hugging Face. Av disse besto 6 804 ende-til-ende-testen på Spyre, ifølge innlegget. Ett eksempel erstatter aktiveringsfunksjonens gelu_new-uttrykk torch.pow(x, 3.0) med det matematisk identiske x x x, som torch-spyre-stakken kan oversette. Mennesker står fortsatt for diagnostiseringen: De lokaliserer feil som bare oppstår på enheten, og som skyldes sammenslåtte operasjoner, og kontrollerer hver agents konklusjoner mot ende-til-ende-resultatene.

I et innlegg fra 30. september 2026 beskrev ingeniører fra IBM og Red Hat torch-spyres L2-integrasjon med PyTorchs Cross-Repository CI Relay, som utløser nedstrømstesting når det gjøres endringer i PyTorch oppstrøms, og rapporterer resultatene tilbake til PyTorchs CI-dashbord. Integrasjonen kombinerer en agentbasert testutvelgingsprosess i fire trinn med et deklarativt YAML-rammeverk for gjenbruk av tester. Da de oppgraderte fra PyTorch 2.13 til 2.14, måtte de evaluere rundt 4 000 endrede tester i stedet for titusenvis, skrev forfatterne. De la til at de har til hensikt å samarbeide med PyTorch-teamet om å bidra med de gjenbrukbare delene oppstrøms, med PyTorch OpenReg som referansepunkt.

For brukere av IBM Z, LinuxONE og Power11 er målet at de skal kunne hente modeller fra økosystemer som Hugging Face og bruke i hovedsak de samme PyTorch-baserte arbeidsflytene som med Nvidia-GPU-er. Delte utvidelsespunkter i PyTorch skjuler mye av forskjellen mellom arkitekturene, står det i IBM-innlegget. Forfatterne av vLLM-innlegget sa at de planlegger å begynne å inkludere maskinvareuavhengige modeller i CI og gradvis gjøre denne løsningen til standard for kjøring av modeller på Spyre.