IBM Spyre abandonne le sendnn maison au profit d'Inductor pour torch.compile

L'IBM Spyre compte 32 cœurs d'accélération et jusqu'à 128 Go de mémoire LPDDR5 sur une seule carte PCIe, et il utilise désormais un autre compilateur dans PyTorch. La pile logicielle de Spyre est passée de sendnn, un système de compilation distinct écrit de zéro, à backend=inductor. Il s'agit du backend ouvert de torch.compile, utilisé par défaut dans PyTorch. L'information provient du PyTorch Blog. La partie accessible de l'annonce se limite à l'énoncé du changement de backend, sans benchmarks : il faut donc juger l'intérêt architectural de la décision.

Ce qui change concrètement

Jusqu'ici, le parcours d'un modèle sur Spyre se déroulait ainsi. L'utilisateur appelait torch.compile, le graphe partait vers sendnn, puis le compilateur d'IBM, sans lien avec le reste de l'écosystème PyTorch, décidait de tout. Désormais, le graphe passe par Inductor, qui prend en charge la capture du graphe, la décomposition des opérateurs, la planification et la fusion des noyaux. Seule une extension branchée sur Inductor s'occupe des spécificités de Spyre.

Pour Inductor, ce schéma est classique. Il génère du code Triton pour les GPU et du C++ pour les CPU, et ses points d'extension permettent de brancher des périphériques tiers sans forker tout le compilateur. Spyre devient un périphérique de plus de ce type.

Pourquoi pas un compilateur maison

Une pile propriétaire donne un contrôle total, mais elle coûte cher. Chaque nouveauté de PyTorch, des nouveaux opérateurs aux formes dynamiques en passant par les évolutions d'AOTAutograd, doit être rattrapée à la main. Les modèles récents font sauter la couverture des opérateurs, et l'équipe met à jour le compilateur architecture par architecture.

Avec Inductor, IBM obtient une partie de ce travail sans frais :

• les décompositions d'opérateurs maintenues par la communauté PyTorch ;
• les optimisations générales du graphe et la fusion d'opérations ;
• un parcours unique de débogage et de profilage, familier des développeurs qui ont déjà travaillé sur GPU ;
• moins de code qu'IBM doit maintenir par lui-même.

Il y a aussi un prix à payer. Inductor a été conçu autour des GPU et des CPU, avec leurs modèles de mémoire et de parallélisme. Spyre est construit différemment : c'est un accélérateur doté de sa propre organisation du calcul et des données. Une partie des optimisations que sendnn réalisait directement pour le matériel doit maintenant s'exprimer via les extensions d'Inductor, ce qui peut se révéler plus compliqué qu'il n'y paraît.

Ce que l'on sait de Spyre

Spyre est issu de la puce de recherche IBM AIU et vise l'inférence dans les systèmes d'entreprise, d'abord sur les mainframes IBM Z et les serveurs Power. Principales caractéristiques selon les données publiques d'IBM :

• 32 cœurs d'accélération ;
• environ 25,6 milliards de transistors, gravure en 5 nm ;
• jusqu'à 128 Go de mémoire LPDDR5 par carte ;
• format PCIe, de l'ordre de 75 W par carte ;
• cas d'usage visé : l'inférence de modèles génératifs et classiques au sein du périmètre de l'entreprise.

La logique de cet accélérateur est claire. Les banques et les assureurs veulent exécuter les modèles près des données, sans les envoyer dans le cloud, et cela suppose une pile familière aux développeurs. Le passage à Inductor pousse Spyre précisément dans cette direction.

En pratique

Tant qu'aucun tableau de vitesse ni de couverture des opérateurs n'est public, la transition s'évalue à l'aune de plusieurs critères.

1. Votre modèle fonctionne-t-il avec backend=inductor sur Spyre sans modification, et combien de coupures de graphe subsistent après compilation. 2. Comment le temps de compilation a évolué par rapport à sendnn, notamment pour les grands LLM à formes dynamiques. 3. Les performances sur vos modèles sont-elles comparables à celles de l'ancien backend. Si ce n'est pas le cas, il faut chercher où l'extension d'Inductor n'exploite pas les capacités du matériel. 4. À quelle vitesse les nouvelles versions de PyTorch arrivent dans la pile. C'est le principal gain pratique du changement d'architecture : moins il y a de code propriétaire, plus le retard se réduit.

Pour les équipes qui prévoient de faire de l'inférence sur IBM Z ou Power, il est judicieux de constituer d'emblée un jeu de tests avec leurs propres modèles et de l'exécuter sur les deux backends, tant que sendnn reste disponible pour la comparaison. Si Inductor s'en sort sans perte de vitesse, Spyre aura une raison de moins de se distinguer des autres accélérateurs dans PyTorch.