IBM maakt Spyre-accelerator tot volwaardige PyTorch-backend

IBM meldde in een blogbericht van IBM Research dat op 26 oktober 2026 is gepubliceerd, dat software-updates die in de tweede helft van 2026 in het PyTorch-ecosysteem zijn doorgevoerd, zijn Spyre-dataflowaccelerator tot een volwaardige PyTorch-backend hebben gemaakt. Daarmee is uitvoering gegeven aan een plan dat IBM en de PyTorch Foundation in oktober 2025 uiteenzetten.

IBM omschrijft Spyre als zijn dataflow-accelerator voor AI, geoptimaliseerd voor inferentie en ontworpen voor bedrijfsteams die AI naast hun applicaties en gegevens op IBM Z-, LinuxONE- en Power-systemen draaien. De berekeningen met lagere precisie zijn gericht op het matrixintensieve werk in taalmodellen voor tekstgeneratie en embeddingmodellen. In tegenstelling tot een conventionele GPU, die kernels uitvoert als instructiestromen over geplande groepen threads, activeert Spyre berekeningen zodra gegevens de rekeneenheden bereiken.

In de tweede helft van 2026 brachten IBM, Red Hat en samenwerkingspartners binnen de PyTorch Foundation, waaronder Meta en Hugging Face, updates uit voor modelondersteuning vanaf dag één, hardware-onafhankelijke modellen in vLLM, doorlopende regressie- en releasetests en integratie als native apparaat, aldus het bericht. Tijdens PyTorch Conference 2025 zei IBM in een bericht van IBM Research van 21 oktober 2025 dat het voor 2026 een diepgaandere ondersteuning van Spyre plande, waarbij Spyre als volwaardige backend zou deelnemen aan opensource-inferentieworkflows. De aandacht zou daarbij uitgaan naar uniforme compilertrajecten, geoptimaliseerde kernelgeneratie en transparante planning over meerdere accelerators. IBM had vLLM toen al gekozen als inferentieruntime en torch.compile als frontendcompiler voor de integratie van accelerators zoals Spyre. Ook had het een Spyre-plug-in voor vLLM bijgedragen die paged attention mogelijk maakt voor inferentie met grote taalmodellen.

Een compiler opnieuw opgebouwd op Inductor

De integratie draait om torch-spyre, een PyTorch-backend die gewone PyTorch-code compileert tot een uitvoerbaar plan voor Spyre. Het grootste deel van de logica van een model doorloopt de PyTorch-compiler ongewijzigd. Als een bewerking nog niet effectief kan worden omgezet naar uitvoerbare code, kan een adapter die vervangen door een wiskundig gelijkwaardige vorm die de compiler wel aankan.

In een bericht van de PyTorch Foundation van 13 oktober 2026 beschreven Dave Grove, Olivier Tardieu en het IBM Spyre Team hoe ze de torch.compile-backend van torch-spyre verplaatsten van sendnn, een compilatiestack die volledig vanaf nul was opgebouwd, naar backend=inductor, een opensourcebackend die is ontwikkeld door PyTorchs eigen Inductor uit te breiden. Volgens de auteurs omvat sendnn, gemeten met de code-analysator lizard, in totaal ongeveer 273.000 regels C++ en Python, verdeeld over 6.170 functies. De Inductor-uitbreiding telt ongeveer 38.600 regels Python, verdeeld over 1.878 functies: zo’n zeven keer minder regels en een lagere complexiteit per functie.

Spyre is een accelerator van 75 watt die via PCIe wordt aangesloten en bestaat uit 32 kleine kernen die via een ring met elkaar zijn verbonden. Elke kern heeft een eigen scratchpad van 2 MB in plaats van een gedeelde cache. Gegevens worden verplaatst in vaste blokken van 128 bytes, die sticks worden genoemd. Volgens het bericht richtte het compilerwerk zich op gegevensverplaatsing in eenheden van sticks, de planning van scratchpadgeheugen en de toewijzing van kernen tijdens het compileren.

De gerapporteerde metingen omvatten een afname van 29–69% in de rekentijd van matmul-kernels dankzij keuzes voor tiling en indeling, en een daling van de mediane rekentijd van softmax-kernels van 32,51 naar 23,67 microseconden — een afname van 27% — dankzij planning die rekening houdt met scratchpadgeheugen. Daarnaast verhoogde een gefuseerde kernel in MLP-stijl de benutting van de kernen van ongeveer twee derde naar circa 80% en verkortte die de rekentijd van kernels met ongeveer 17%. In een synthetische graaf die was ontworpen om deze keuzes op de proef te stellen, verving een nieuwe herindeling op de chip een retour naar het apparaatgeheugen van 80 microseconden door een shuffle tussen kernen van 1,1 microseconde. Het bericht vermeldt ook dat de noodzaak voor torch-spyre om apparaatspecifieke decomposities te registreren, heeft bijgedragen aan verbeteringen in de ondersteuning van Inductor-backends buiten de PyTorch-codeboom. Die verbeteringen zijn opgenomen in PyTorch 2.12 via twee samengevoegde pull requests.

Integratie als native apparaat

Spyre wordt een native PyTorch-apparaat via PrivateUse1-registratie, waardoor tensor.to(“spyre”) een echte apparaatidentiteit krijgt: opslag via de PyTorch-allocator houdt tensors op het apparaat, streams zorgen voor de juiste volgorde en runtime-events verbinden afhankelijk werk tussen streams. De kaart bevat 32 kernen die via een ring met hoge bandbreedte zijn verbonden, elk met 2 MB lokaal scratchpadgeheugen, en maximaal 128 GB LPDDR5 voor tensors en programma’s. De huidige runtime past programma’s bij het starten aan en vervangt symbolische tensoradressen in drie opeenvolgende stappen door echte adressen.

Bij een demonstratie met Granite 3.3 8B, een batchgrootte van 1 en een sequentielengte van 1024 verbeterde het verplaatsen van de graafconstructie buiten het pad voor gegevensoverdracht de prefill met 9,9% en de decode met 13,6%, meldde het team. Toen die bewerking ook uit de dispatch van berekeningen werd verwijderd, kwam de totale verbetering uit op een 1,7x snellere prefill en een 2,4x snellere decode. Ongeveer driekwart van de winst was afkomstig van het berekeningspad.

“De winst is dat Spyre noch PyTorch hoeft te doen alsof het iets anders is”, schreven de auteurs in Spyre bouwen als native PyTorch-apparaat, gepubliceerd op 8 oktober 2026. Ze voegden eraan toe dat Spyre zijn dataflow-uitvoeringsmodel behoudt, terwijl gebruikers een native PyTorch-apparaat krijgen met de vertrouwde plaatsing van tensors, streams en compilatie.

vLLM-portabiliteit en de koppeling met Llm-D

Spyre is een externe accelerator, geen van de GPU-platforms die AI-software doorgaans ondersteunt. Het gebruikt TorchDynamo om een modelgrafiek te traceren en TorchInductor om die grafiek te vertalen voor de doelhardware. Met uitbreidingsmechanismen zoals CustomOp en PluggableLayer kan een hardwareplug-in binnen vLLM het gedrag aanpassen zonder grote delen van de softwarestack opnieuw te implementeren.

In Hardware-onafhankelijke modellen in vLLM, gepubliceerd op 22 september 2026 door auteurs van IBM, Meta en Hugging Face, beschreef het team hoe vLLM overstapt op hardware-specifieke ‘platte’ modeldefinities. Ook introduceerde het hardware-onafhankelijke lagen die zijn gebaseerd op vier ontwerpprincipes: ze moeten compileerbaar en uitbreidbaar zijn, losstaan van hardware-specifieke paden en overdraagbaar zijn. De eerste ondersteuning is opgenomen in de hoofdbranch van vLLM en kan worden ingeschakeld met USE_HW_AGNOSTIC=1 in de Transformers-backend. Deze aanpak is gevalideerd met de externe Spyre-plug-in voor onder meer Gemma 4, Qwen3 en Granite 4.2. Op NVIDIA H100-GPU’s leverden de hardware-onafhankelijke lagen een totale tokenverwerkingscapaciteit op die binnen 3,4% bleef van die van de native implementatie. Volgens de auteurs is dit gemeten als het geometrisch gemiddelde over drie recente modellen.

De PyTorch-integratie van Spyre zorgt er ook voor dat het kan worden aangesloten op llm-d, legt het IBM-bericht uit: llm-d voert gedistribueerde inferentie uit boven op vLLM, op meerdere typen accelerators. vLLM bereikt elke accelerator via PyTorch. Zodra een apparaat een werkende PyTorch-backend heeft, kan een vLLM-hardwareplug-in die beschikbaar maken, zodat llm-d er werk naartoe kan plannen.

Inschakeling vanaf dag één en doorlopende tests

In een bericht van 20 augustus 2026 beschrijft het IBM Spyre Team HF-adapters, een project dat programmeeragenten inzet om runtimepatches op te stellen waarmee standaardmodellen van Hugging Face Transformers op Spyre kunnen draaien. Van half april tot eind juni 2026 dekten 13 verschillende adapters 7.960 van de 10.000 meest gedownloade embeddingmodellen van Hugging Face. Daarvan slaagden er volgens het bericht 6.804 voor hun end-to-endtest op Spyre. Een voorbeeld vervangt de aanroep torch.pow(x, 3.0) in de gelu_new-activeringsfunctie door de wiskundig identieke uitdrukking x × x × x, die de torch-spyre-stack kan vertalen. Mensen blijven verantwoordelijk voor het diagnosticeren van problemen: zij lokaliseren fouten die uitsluitend op het apparaat optreden door gefuseerde bewerkingen en controleren de conclusies van elke agent aan de hand van end-to-endresultaten.

In een bericht van 30 september 2026 beschreven ingenieurs van IBM en Red Hat de L2-integratie van torch-spyre met PyTorch Cross-Repository CI Relay. Die start tests downstream op basis van wijzigingen upstream in PyTorch en stuurt de resultaten terug naar het CI-dashboard van PyTorch. De integratie combineert een door agenten aangestuurde testselectiepijplijn in vier fasen met een declaratief YAML-framework voor hergebruik van tests. Bij de upgrade van PyTorch 2.13 naar 2.14 moesten ongeveer 4.000 gewijzigde tests worden geëvalueerd in plaats van tienduizenden, schreven de auteurs. Ze voegden eraan toe dat ze met het PyTorch-team willen samenwerken om de herbruikbare onderdelen upstream op te nemen, met PyTorch OpenReg als uitgangspunt.

Voor gebruikers van IBM Z, LinuxONE en Power11 is het de bedoeling dat ze modellen uit ecosystemen zoals Hugging Face kunnen halen en grotendeels dezelfde op PyTorch gebaseerde workflows kunnen gebruiken als met Nvidia-GPU’s. Gedeelde uitbreidingspunten in PyTorch verhullen daarbij een groot deel van de verschillen in architectuur, aldus het IBM-bericht. De auteurs van het vLLM-bericht zeiden dat ze hardware-onafhankelijke modellen geleidelijk willen opnemen in CI en die aanpak stapsgewijs als standaard willen invoeren voor het aanbieden van modellen op Spyre.