IBM macht den Spyre-Beschleuniger zu einem erstklassigen PyTorch-Backend

IBM erklärte in einem Blogbeitrag von IBM Research vom 26. Oktober 2026, dass Softwareaktualisierungen, die in der zweiten Hälfte des Jahres 2026 im gesamten PyTorch-Ökosystem bereitgestellt wurden, seinen Spyre-Datenflussbeschleuniger zu einem erstklassigen PyTorch-Backend gemacht hätten. Damit werde ein Plan umgesetzt, den IBM und die PyTorch Foundation im Oktober 2025 vorgestellt hatten.

IBM beschreibt Spyre als seinen Datenfluss-KI-Beschleuniger, der für Inferenz optimiert und für Unternehmensteams konzipiert wurde, die KI zusammen mit ihren Anwendungen und Daten auf IBM Z-, LinuxONE- und Power-Systemen betreiben. Seine Rechenleistung mit reduzierter Genauigkeit ist auf die matrixintensiven Aufgaben bei der Sprachgenerierung und in Einbettungsmodellen ausgelegt. Anders als eine herkömmliche GPU, die Kernel als Befehlsströme über eingeplante Thread-Gruppen hinweg ausführt, stößt Spyre Berechnungen an, sobald Daten an seinen Recheneinheiten eintreffen.

In der zweiten Hälfte des Jahres 2026 stellten IBM, Red Hat und weitere Beteiligte der PyTorch Foundation, darunter Meta und Hugging Face, Aktualisierungen bereit, die die sofortige Modellunterstützung, hardwareunabhängige Modelle in vLLM, kontinuierliche Regressionstests und Veröffentlichungstests sowie die Integration als natives Gerät abdeckten, heißt es in dem Beitrag. Auf der PyTorch Conference 2025 erklärte IBM in einem Beitrag von IBM Research vom 21. Oktober 2025, dass es für 2026 eine umfassendere Spyre-Unterstützung plane. Spyre sollte dabei als erstklassiges Backend in Open-Source-Inferenz-Workflows zum Einsatz kommen; im Mittelpunkt sollten einheitliche Compilerpfade, die optimierte Kernel-Generierung und eine transparente Planung für mehrere Beschleuniger stehen. IBM hatte vLLM zu diesem Zeitpunkt bereits als Inferenzlaufzeit und torch.compile als Frontend-Compiler für die Integration von Beschleunigern wie Spyre übernommen. Außerdem hatte das Unternehmen ein Spyre-Plug-in für vLLM beigesteuert, das paged attention für die Inferenz großer Sprachmodelle ermöglicht.

Ein mit Inductor neu aufgebauter Compiler

Kern der Integration ist torch-spyre, ein PyTorch-Backend, das gewöhnlichen PyTorch-Code in einen ausführbaren Plan für Spyre kompiliert. Der größte Teil der Modelllogik durchläuft den PyTorch-Compiler unverändert. Lässt sich eine Operation noch nicht wirksam absenken, kann ein Adapter sie durch eine mathematisch gleichwertige Form ersetzen, mit der der Compiler umgehen kann.

In einem Beitrag der PyTorch Foundation vom 13. Oktober 2026 beschrieben Dave Grove, Olivier Tardieu und das IBM Spyre Team, wie sie das torch.compile-Backend von torch-spyre von sendnn – einem vollständig von Grund auf neu entwickelten Compiler-Stack – auf backend=inductor umstellten, ein Open-Source-Backend, das durch die Erweiterung von PyTorchs eigenem Inductor entstanden ist. Eine Messung mit dem Code-Analyzer lizard ergab, dass sendnn insgesamt rund 273.000 Zeilen C++ und Python in 6.170 Funktionen umfasst, während die Inductor-Erweiterung rund 38.600 Zeilen Python in 1.878 Funktionen aufweist – etwa siebenmal weniger Zeilen und eine geringere Komplexität pro Funktion, berichteten die Autoren.

Spyre ist ein 75-Watt-Beschleuniger mit PCIe-Anschluss. Er besteht aus 32 kleinen, ringförmig miteinander verbundenen Kernen, von denen jeder über einen eigenen 2-MB-Scratchpad-Speicher statt über einen gemeinsamen Cache verfügt. Daten werden in festen 128-Byte-Blöcken übertragen, die Sticks genannt werden. Die Compilerarbeit konzentrierte sich auf den Datentransfer in Stick-Einheiten, die Planung des Scratchpad-Speichers und die Zuweisung der Kerne zur Kompilierzeit, heißt es in dem Beitrag.

Zu den berichteten Messwerten zählen eine Verringerung der Matmul-Kernelzeit um 29–69 % durch Kachelung und Layoutentscheidungen, eine Senkung der medianen Softmax-Kernelzeit von 32,51 auf 23,67 Mikrosekunden – eine Verringerung um 27 % – durch eine Scratchpad-bewusste Ablaufplanung sowie ein fusionierter Kernel im MLP-Stil, der die Kernauslastung von rund zwei Dritteln auf etwa 80 % steigerte und zugleich die Kernelzeit um rund 17 % senkte. In einem synthetischen Graphen, der diese Entscheidungen gezielt auf die Probe stellte, ersetzte ein neues On-Chip-Relayout einen 80 Mikrosekunden dauernden Umweg über den Gerätespeicher durch einen 1,1 Mikrosekunden schnellen Datenaustausch zwischen den Kernen. Dem Beitrag zufolge trug auch die Notwendigkeit, gerätespezifische Zerlegungen in torch-spyre zu registrieren, zu Verbesserungen bei der Unterstützung externer Inductor-Backends bei. Diese flossen in PyTorch 2.12 als zwei zusammengeführte Pull Requests ein.

Integration als natives Gerät

Spyre wird durch die Registrierung über PrivateUse1 zu einem nativen PyTorch-Gerät. Dadurch erhält tensor.to(“spyre”) eine echte Geräteidentität: Der Speicher des PyTorch-Allokators hält Tensoren auf dem Gerät vor, Streams sorgen für die Reihenfolge der Ausführung, und Laufzeitereignisse verknüpfen voneinander abhängige Aufgaben über mehrere Streams hinweg. Die Karte verfügt über 32 Kerne, die durch einen Ring mit hoher Bandbreite verbunden sind; jeder Kern besitzt 2 MB lokalen Scratchpad-Speicher. Hinzu kommen bis zu 128 GB LPDDR5 für Tensoren und Programme. Die aktuelle Laufzeitumgebung passt Programme beim Start an und ersetzt dabei symbolische Tensoradressen in drei aufeinander abgestimmten Schritten durch reale Adressen.

Bei einer Demonstration mit Granite 3.3 8B, einer Batchgröße von 1 und einer Sequenzlänge von 1024 verbesserte das Verlagern der Graphkonstruktion aus dem Datenübertragungspfad heraus das Prefill um 9,9 % und das Decode um 13,6 %, berichtete das Team. Wurde diese Arbeit auch aus der Rechenausführung entfernt, stieg die Gesamtleistung beim Prefill auf das 1,7-Fache und beim Decode auf das 2,4-Fache; rund drei Viertel des Leistungszuwachses entfielen auf den Rechenpfad.

„Der Vorteil besteht darin, dass weder Spyre noch PyTorch so tun müssen, als wären sie etwas anderes“, schrieben die Autoren in Spyre als natives PyTorch-Gerät entwickeln, veröffentlicht am 8. Oktober 2026. Spyre behalte sein Datenfluss-Ausführungsmodell bei, während die Nutzer ein natives PyTorch-Gerät mit vertrauter Tensorplatzierung, Streams und Kompilierung erhielten, fügten sie hinzu.

vLLM-Portabilität und die Verbindung zu Llm-D

Spyre ist ein Accelerator außerhalb des Hauptbaums und keine der von KI-Software am häufigsten unterstützten GPU-Plattformen. Dabei stützt es sich auf TorchDynamo, um den Modellgraphen nachzuverfolgen, und auf TorchInductor, um diesen Graphen für die Zielhardware zu kompilieren. In vLLM ermöglichen Erweiterungsmechanismen wie CustomOp und PluggableLayer einem Hardware-Plugin, das Verhalten anzupassen, ohne große Teile des Software-Stacks neu implementieren zu müssen.

In Hardwareunabhängige Modelle in vLLM, veröffentlicht am 22. September 2026 von Autoren von IBM, Meta und Hugging Face, beschrieb das Team den Wandel von vLLM hin zu hardwarebezogenen „flachen“ Modelldefinitionen und stellte hardwareunabhängige Ebenen vor, die auf vier Gestaltungsprinzipien beruhen: Kompilierbarkeit, Erweiterbarkeit, Trennung von hardwarespezifischen Pfaden und Portabilität. Erste Unterstützung ist im Hauptzweig von vLLM verfügbar und lässt sich im Transformers-Backend mit USE_HW_AGNOSTIC=1 aktivieren. Das Verfahren wurde mit dem Spyre-Plugin außerhalb des Hauptbaums anhand von Modellen wie Gemma 4, Qwen3 und Granite 4.2 validiert. Auf NVIDIA-H100-GPUs erreichten die hardwareunabhängigen Ebenen einen Gesamtdurchsatz bei der Tokenverarbeitung, der höchstens 3,4 % unter dem der nativen Implementierung lag. Gemessen wurde dabei das geometrische Mittel über drei aktuelle Modelle, wie die Autoren berichteten.

Die PyTorch-Integration von Spyre ist laut dem IBM-Beitrag auch die Grundlage für die Anbindung an llm-d: llm-d führt verteilte Inferenz auf Basis von vLLM über verschiedene Beschleunigertypen hinweg aus, vLLM greift über PyTorch auf die jeweiligen Beschleuniger zu, und sobald ein Gerät über ein funktionsfähiges PyTorch-Backend verfügt, kann ein vLLM-Hardware-Plugin es verfügbar machen, sodass llm-d Aufgaben darauf verteilen kann.

Befähigung vom ersten Tag an und kontinuierliche Tests

Ein Beitrag vom 20. August 2026 des IBM Spyre Teams beschreibt HF-adapters, ein Projekt, bei dem Programmieragenten Laufzeit-Patches entwerfen, mit denen sich unveränderte Hugging-Face-Transformers-Modelle auf Spyre ausführen lassen. Von Mitte April bis Ende Juni 2026 deckten 13 verschiedene Adapter 7.960 der 10.000 am häufigsten heruntergeladenen Hugging-Face-Einbettungsmodelle ab; 6.804 davon bestanden laut dem Beitrag ihren End-to-End-Test auf Spyre. Ein Beispiel ersetzt torch.pow(x, 3.0) in der Aktivierungsfunktion gelu_new durch das mathematisch identische x x x, das der torch-spyre-Stack kompilieren kann. Menschen übernehmen weiterhin die Diagnose: Sie lokalisieren ausschließlich auf dem Gerät auftretende Fehler, die durch fusionierte Operationen entstehen, und prüfen die Schlussfolgerungen jedes Agenten anhand der End-to-End-Ergebnisse.

In einem Beitrag vom 30. September 2026 beschrieben Ingenieure von IBM und Red Hat die L2-Integration von torch-spyre mit PyTorchs Cross-Repository-CI-Relay, das bei Änderungen am vorgelagerten PyTorch-Projekt nachgelagerte Tests auslöst und die Ergebnisse an das CI-Dashboard von PyTorch zurückmeldet. Die Integration kombiniert eine agentengestützte Pipeline zur Auswahl von Tests in vier Phasen mit einem deklarativen YAML-Framework zur Wiederverwendung von Tests. Beim Upgrade von PyTorch 2.13 auf 2.14 mussten dadurch rund 4.000 geänderte Tests statt Zehntausender Tests ausgewertet werden, schrieben die Autoren. Sie fügten hinzu, dass sie mit dem PyTorch-Team daran arbeiten wollen, die wiederverwendbaren Komponenten in das Hauptprojekt zu übernehmen, wobei PyTorch OpenReg als Referenz dienen soll.

Für Nutzer von IBM Z, LinuxONE und Power11 besteht das angestrebte Nutzungserlebnis darin, Modelle aus Ökosystemen wie Hugging Face zu beziehen und im Wesentlichen dieselben PyTorch-basierten Arbeitsabläufe zu verwenden wie mit Nvidia-GPUs. Gemeinsame PyTorch-Erweiterungspunkte verbergen dabei einen Großteil der Architekturunterschiede, heißt es im IBM-Beitrag. Die Autoren des vLLM-Beitrags erklärten, sie planten, hardwareunabhängige Modelle künftig in die CI aufzunehmen und schrittweise standardmäßig auf diesen Weg umzusteigen, wenn Modelle auf Spyre bereitgestellt werden.