IBM fait de l’accélérateur Spyre un back-end PyTorch de premier ordre

Dans un article de blog d’IBM Research publié le 26 octobre 2026, IBM a indiqué que les mises à jour logicielles déployées dans l’écosystème PyTorch au cours du second semestre 2026 ont fait de son accélérateur de flot de données Spyre un back-end PyTorch de premier ordre, concrétisant ainsi un projet présenté par IBM et la PyTorch Foundation en octobre 2025.

IBM décrit Spyre comme son accélérateur d’IA à flot de données, optimisé pour l’inférence et conçu pour les équipes d’entreprise qui exécutent des applications d’IA aux côtés de leurs applications et de leurs données sur les systèmes IBM Z, LinuxONE et Power. Ses calculs en précision réduite ciblent les opérations matricielles intensives des modèles de génération de langage et d’incorporation. Contrairement à un processeur graphique classique, qui exécute des noyaux sous forme de flux d’instructions répartis entre des groupes de threads planifiés, Spyre déclenche les calculs à mesure que les données arrivent à ses moteurs de calcul.

Au cours du second semestre 2026, IBM, Red Hat et des collaborateurs de la PyTorch Foundation, dont Meta et Hugging Face, ont déployé des mises à jour portant sur la prise en charge des modèles dès le premier jour, les modèles indépendants du matériel dans vLLM, les tests continus de régression et de publication, ainsi que l’intégration en tant que périphérique natif, indique l’article. Lors de la PyTorch Conference 2025, dans un article d’IBM Research daté du 21 octobre 2025, IBM avait annoncé son intention d’approfondir la prise en charge de Spyre en 2026, afin que celui-ci soit intégré comme back-end de premier ordre aux flux d’inférence open source. L’entreprise mettait l’accent sur des voies de compilation unifiées, la génération de noyaux optimisés et la planification transparente de plusieurs accélérateurs. IBM avait alors adopté vLLM comme moteur d’inférence et torch.compile comme compilateur frontal pour intégrer des accélérateurs tels que Spyre, et avait contribué à un plug-in Spyre pour vLLM permettant l’attention paginée lors de l’inférence des grands modèles de langage.

Un compilateur reconstruit sur Inductor

Au cœur de cette intégration se trouve torch-spyre, un back-end PyTorch qui compile du code PyTorch ordinaire en un plan exécutable pour Spyre. La majeure partie de la logique d’un modèle traverse le compilateur PyTorch sans modification ; lorsqu’une opération ne peut pas encore être abaissée efficacement, un adaptateur peut la remplacer par une forme mathématiquement équivalente que le compilateur sait traiter.

Dans un article de la PyTorch Foundation publié le 13 octobre 2026, Dave Grove, Olivier Tardieu et l’équipe IBM Spyre ont décrit le passage du back-end torch.compile de torch-spyre de sendnn — une pile de compilation entièrement développée à partir de zéro — à backend=inductor, un back-end open source créé en étendant le propre compilateur Inductor de PyTorch. Selon les auteurs, l’analyseur de code lizard estime sendnn à environ 273 000 lignes de C++ et de Python réparties entre 6 170 fonctions, tandis que l’extension Inductor compte environ 38 600 lignes de Python réparties entre 1 878 fonctions, soit environ sept fois moins de lignes et une complexité moindre par fonction.

Spyre est un accélérateur de 75 watts connecté en PCIe, composé de 32 petits cœurs reliés en anneau. Chacun dispose de son propre bloc-notes mémoire de 2 Mo plutôt que d’un cache partagé, et les données sont transférées par blocs fixes de 128 octets appelés « sticks ». Selon l’article, les travaux sur le compilateur se sont concentrés sur les transferts de données à la granularité d’un stick, la planification du bloc-notes mémoire et l’affectation des cœurs au moment de la compilation.

Les mesures rapportées font état d’une réduction de 29 à 69 % du temps d’exécution des noyaux de multiplication matricielle grâce au choix du découpage en tuiles et de la disposition des données, d’une baisse du temps médian d’exécution des noyaux softmax, qui passe de 32,51 à 23,67 microsecondes — soit une réduction de 27 % — grâce à une planification tenant compte du bloc-notes mémoire, ainsi que d’un noyau fusionné de type MLP qui a fait passer l’utilisation des cœurs d’environ deux tiers à près de 80 %, tout en réduisant le temps d’exécution des noyaux d’environ 17 %. Sur un graphe synthétique conçu pour mettre ces choix à l’épreuve, une nouvelle réorganisation des données sur la puce a remplacé un aller-retour de 80 microsecondes vers la mémoire de l’appareil par un transfert entre cœurs de 1,1 microseconde. L’article indique également que la nécessité, pour torch-spyre, d’enregistrer des décompositions propres au périphérique a contribué à améliorer la prise en charge des back-ends Inductor externes à PyTorch ; ces améliorations ont été intégrées en amont dans PyTorch 2.12 sous la forme de deux demandes de fusion.

Intégration en tant que périphérique natif

Spyre devient un périphérique PyTorch natif grâce à son enregistrement via PrivateUse1, qui confère une véritable identité de périphérique à tensor.to(“spyre”) : le stockage alloué par PyTorch maintient les tenseurs sur le périphérique, les flux définissent l’ordre d’exécution et les événements d’exécution relient les opérations dépendantes entre les flux. La carte comporte 32 cœurs reliés par un anneau à large bande passante, chacun doté d’un bloc-notes mémoire local de 2 Mo, ainsi que jusqu’à 128 Go de mémoire LPDDR5 pour les tenseurs et les programmes. À l’heure actuelle, l’environnement d’exécution corrige les programmes au moment de leur lancement, en substituant les adresses symboliques des tenseurs par des adresses réelles en trois étapes ordonnées.

Lors d’une démonstration avec Granite 3.3 8B, une taille de lot de 1 et une longueur de séquence de 1 024, le déplacement de la construction du graphe hors du chemin de transfert des données a amélioré le préremplissage de 9,9 % et le décodage de 13,6 %, a indiqué l’équipe. En retirant également cette opération du chemin de distribution des calculs, les gains totaux ont atteint un facteur d’accélération de 1,7 pour le préremplissage et de 2,4 pour le décodage, environ les trois quarts du gain provenant du chemin de calcul.

« L’avantage, c’est que ni Spyre ni PyTorch n’ont besoin de prétendre être autre chose », ont écrit les auteurs dans Construire Spyre comme périphérique PyTorch natif, publié le 8 octobre 2026. Ils ajoutaient que Spyre conserve son modèle d’exécution à flot de données, tandis que les utilisateurs disposent d’un périphérique PyTorch natif offrant les mécanismes familiers de placement des tenseurs, de gestion des flux et de compilation.

Portabilité de vLLM et lien avec Llm-D

Spyre est un accélérateur hors arborescence, et non l’une des plateformes GPU les plus couramment prises en charge par les logiciels d’IA. Il s’appuie sur TorchDynamo pour tracer le graphe d’un modèle et sur TorchInductor pour compiler ce graphe en vue de son exécution sur le matériel cible. Dans vLLM, des mécanismes d’extension tels que CustomOp et PluggableLayer permettent à un plug-in matériel de personnaliser le comportement sans avoir à réimplémenter une grande partie de la pile logicielle.

Dans Modèles indépendants du matériel dans vLLM, publié le 22 septembre 2026 par des auteurs d’IBM, de Meta et de Hugging Face, l’équipe a décrit l’évolution de vLLM vers des définitions de modèles « à plat » propres à chaque matériel et présenté des couches indépendantes du matériel fondées sur quatre principes de conception : être compilables, extensibles, isolées des chemins propres à un matériel donné et portables. Une première prise en charge est disponible dans la branche principale de vLLM et peut être activée avec USE_HW_AGNOSTIC=1 sur le backend Transformers. Cette approche a été validée avec le plug-in Spyre hors arborescence sur des modèles comme Gemma 4, Qwen3 et Granite 4.2. Sur les GPU NVIDIA H100, les couches indépendantes du matériel ont atteint un débit total de jetons à moins de 3,4 % de celui de l’implémentation native, selon la moyenne géométrique calculée sur trois modèles récents, ont indiqué les auteurs.

L’intégration de Spyre à PyTorch est également le moyen de le connecter à llm-d, explique l’article d’IBM : llm-d exécute des inférences distribuées au-dessus de vLLM sur plusieurs types d’accélérateurs, vLLM accède à chacun d’eux par l’intermédiaire de PyTorch et, dès qu’un appareil dispose d’un backend PyTorch fonctionnel, un plug-in matériel pour vLLM peut l’exposer afin que llm-d puisse y planifier des tâches.

Activation dès le premier jour et tests continus

Un article du 20 août 2026 de l’équipe IBM Spyre présente HF-adapters, un projet qui s’appuie sur des agents de programmation pour rédiger des correctifs d’exécution permettant aux modèles Hugging Face Transformers standard de fonctionner sur Spyre. De la mi-avril à la fin juin 2026, 13 adaptateurs distincts ont fini par couvrir 7 960 des 10 000 modèles d’embeddings Hugging Face les plus téléchargés ; parmi eux, 6 804 réussissent leur test de bout en bout sur Spyre, rapporte l’article. Un exemple consiste à remplacer torch.pow(x, 3.0), l’opération d’activation gelu_new, par l’expression mathématiquement équivalente x x, que la pile torch-spyre peut compiler. Les humains continuent de se charger du diagnostic : ils localisent les échecs qui ne se produisent que sur l’appareil et qui résultent d’opérations fusionnées, puis vérifient les conclusions de chaque agent au regard des résultats de bout en bout.

Dans un article du 30 septembre 2026, des ingénieurs d’IBM et de Red Hat ont décrit l’intégration L2 de torch-spyre au Cross-Repository CI Relay de PyTorch, qui déclenche des tests en aval à la suite de modifications apportées à PyTorch en amont et transmet les résultats au tableau de bord d’intégration continue de PyTorch. Cette intégration associe un processus de sélection des tests en quatre étapes reposant sur des agents à un cadre déclaratif de réutilisation des tests en YAML. Selon les auteurs, la mise à niveau de PyTorch 2.13 vers la version 2.14 a nécessité d’évaluer environ 4 000 tests modifiés au lieu de plusieurs dizaines de milliers. Ils ajoutent qu’ils comptent travailler avec l’équipe PyTorch pour intégrer en amont les éléments réutilisables, en prenant PyTorch OpenReg comme référence.

Pour les utilisateurs d’IBM Z, de LinuxONE et de Power11, l’objectif est de pouvoir obtenir des modèles auprès d’écosystèmes tels que Hugging Face et utiliser des flux de travail largement identiques à ceux qu’ils emploieraient avec des GPU Nvidia, les points d’extension communs de PyTorch masquant une grande partie des différences architecturales, indique l’article d’IBM. Les auteurs de l’article consacré à vLLM ont déclaré prévoir d’intégrer des modèles indépendants du matériel aux tests d’intégration continue, puis d’adopter progressivement cette approche comme méthode par défaut pour servir des modèles sur Spyre.