IBM робить прискорювач Spyre повноцінним бекендом PyTorch

У дописі в блозі IBM Research, опублікованому 26 жовтня 2026 року, IBM повідомила, що оновлення програмного забезпечення, випущені в екосистемі PyTorch у другій половині 2026 року, перетворили її прискорювач обробки потоків даних Spyre на повноцінний бекенд PyTorch. Так було втілено план, який IBM і Фонд PyTorch окреслили в жовтні 2025 року.

IBM описує Spyre як свій прискорювач ШІ на основі потоків даних, оптимізований для інференсу й розроблений для корпоративних команд, які запускають ШІ поряд із застосунками та даними на системах IBM Z, LinuxONE і Power. Обчислення зі зниженою точністю призначені для матричних операцій, характерних для генерації тексту та моделей ембедингів. На відміну від звичайного графічного процесора, який виконує ядра як потоки інструкцій у запланованих групах потоків, Spyre запускає обчислення в міру надходження даних до обчислювальних блоків.

У другій половині 2026 року IBM, Red Hat і учасники Фонду PyTorch, зокрема Meta та Hugging Face, випустили оновлення для підтримки моделей із першого дня, апаратно-незалежних моделей у vLLM, безперервного регресійного тестування й тестування релізів, а також інтеграції як нативного пристрою, зазначається в дописі. На PyTorch Conference 2025, у дописі IBM Research від 21 жовтня 2025 року, IBM повідомила про плани поглибити підтримку Spyre у 2026 році: Spyre мав стати повноцінним бекендом у робочих процесах інференсу з відкритим кодом, а основну увагу планували приділити уніфікованим шляхам компіляції, оптимізованій генерації ядер і прозорому плануванню роботи кількох прискорювачів. На той час IBM уже використовувала vLLM як середовище виконання для інференсу, а torch.compile — як фронтенд-компілятор для інтеграції таких прискорювачів, як Spyre; крім того, компанія розробила плагін Spyre для vLLM, який забезпечує сторінковий механізм уваги для інференсу великих мовних моделей.

Компілятор, перебудований на основі Inductor

В основі інтеграції лежить torch-spyre — бекенд PyTorch, який компілює звичайний код PyTorch у план виконання для Spyre. Більшість логіки моделі проходить через компілятор PyTorch без змін; якщо певну операцію поки що не вдається ефективно знизити до цільового коду, адаптер може замінити її математично еквівалентною формою, яку компілятор здатен обробити.

У дописі Фонду PyTorch, опублікованому 13 жовтня 2026 року, Дейв Ґроув, Олів’є Тардьє та команда IBM Spyre описали перехід бекенду torch.compile для torch-spyre зі sendnn — стека компіляції, повністю створеного з нуля, — на backend=inductor, бекенд із відкритим кодом, побудований на основі розширення власного Inductor у PyTorch. За результатами вимірювання аналізатором коду lizard, sendnn налічує приблизно 273 000 рядків коду C++ і Python у 6 170 функціях, тоді як розширення Inductor — приблизно 38 600 рядків Python у 1 878 функціях: за словами авторів, рядків коду приблизно у 7 разів менше, а складність окремих функцій нижча.

Spyre — це прискорювач потужністю 75 Вт із підключенням через PCIe, побудований на 32 невеликих ядрах, з’єднаних кільцевою шиною. Кожне ядро має власну скретчпад-пам’ять обсягом 2 МБ замість спільного кешу, а дані передаються фіксованими блоками по 128 байтів, які називаються sticks. У роботі над компілятором зосередилися на переміщенні даних блоками розміром stick, плануванні використання скретчпад-пам’яті та призначенні ядер під час компіляції, зазначається в дописі.

Серед оприлюднених результатів вимірювань — скорочення часу роботи ядра matmul на 29–69% завдяки вибору тайлінгу й компонування даних; зменшення медіанного часу роботи ядра softmax із 32,51 до 23,67 мікросекунди, тобто на 27%, завдяки плануванню з урахуванням скретчпад-пам’яті; а також злиття ядра типу MLP, що підвищило завантаженість ядер приблизно з двох третин до близько 80% і скоротило час роботи ядра приблизно на 17%. На синтетичному графі, створеному для перевірки цих рішень, нове переставлення даних на кристалі замінило 80-мікросекундний обмін із пам’яттю пристрою на пересилання між ядрами тривалістю 1,1 мікросекунди. У дописі також зазначено, що потреба torch-spyre реєструвати специфічні для пристрою декомпозиції сприяла вдосконаленню підтримки зовнішніх бекендів Inductor; ці зміни увійшли до PyTorch 2.12 у вигляді двох злитих запитів на внесення змін.

Інтеграція як нативного пристрою

Spyre стає нативним пристроєм PyTorch завдяки реєстрації через PrivateUse1, що надає tensor.to(“spyre”) ідентичність справжнього пристрою: алокатор PyTorch виділяє пам’ять для тензорів, які залишаються на пристрої, потоки забезпечують упорядкування операцій, а події середовища виконання пов’язують залежні завдання між потоками. Плата має 32 ядра, з’єднані високошвидкісною кільцевою шиною, кожне з яких оснащене локальною скретчпад-пам’яттю обсягом 2 МБ, а також до 128 ГБ LPDDR5 для тензорів і програм. Поточне середовище виконання під час запуску вносить зміни в програми, замінюючи символічні адреси тензорів на фактичні у три послідовні етапи.

За даними команди, у демонстрації з Granite 3.3 8B, розміром пакета 1 і довжиною послідовності 1024 перенесення побудови графа з етапу передавання даних прискорило попереднє заповнення на 9,9%, а декодування — на 13,6%. Якщо прибрати цю роботу також із диспетчеризації обчислень, загальне прискорення становило 1,7 раза для попереднього заповнення і 2,4 раза для декодування; приблизно три чверті приросту забезпечив обчислювальний шлях.

«Перевага в тому, що ні Spyre, ні PyTorch не доводиться вдавати, ніби вони є чимось іншим», — написали автори в матеріалі «Створення Spyre як нативного пристрою PyTorch», опублікованому 8 жовтня 2026 року. Вони додали, що Spyre зберігає свою модель виконання на основі потоків даних, а користувачі отримують нативний пристрій PyTorch зі звичними засобами розміщення тензорів, потоками та компіляцією.

Переносність vLLM і зв’язок із Llm-D

Spyre — це прискорювач, який не входить до основного дерева коду, на відміну від платформ GPU, підтримуваних більшістю програмного забезпечення для ШІ. Він використовує TorchDynamo для побудови графа моделі та TorchInductor для його адаптації до цільового обладнання. У vLLM такі механізми розширення, як CustomOp і PluggableLayer, дають змогу апаратному плагіну змінювати поведінку системи, не переписуючи значної частини програмного стека.

У матеріалі Моделі в vLLM, не прив’язані до обладнання, опублікованому 22 вересня 2026 року авторами з IBM, Meta та Hugging Face, команда описала перехід vLLM до визначень моделей, прив’язаних до конкретного обладнання, у вигляді «плоских» структур і представила апаратно-незалежні шари, побудовані на чотирьох принципах: придатність до компіляції, розширюваність, ізоляція від шляхів, специфічних для певного обладнання, та переносність. Початкова підтримка вже з’явилася в основній гілці vLLM; її можна ввімкнути за допомогою USE_HW_AGNOSTIC=1 у бекенді transformers. Цей підхід перевірили за допомогою зовнішнього плагіна Spyre на моделях, зокрема Gemma 4, Qwen3 і Granite 4.2. Як повідомили автори, на графічних процесорах NVIDIA H100 апаратно-незалежні шари забезпечили загальну пропускну здатність обробки токенів, що відрізнялася від нативної реалізації не більш ніж на 3,4%; показник виміряли як геометричне середнє для трьох нещодавніх моделей.

Як пояснюється в дописі IBM, інтеграція Spyre з PyTorch також забезпечує його підключення до llm-d: llm-d виконує розподілений інференс на базі vLLM на різних типах прискорювачів, vLLM взаємодіє з кожним прискорювачем через PyTorch, а коли для пристрою є робочий бекенд PyTorch, апаратний плагін vLLM може відкрити до нього доступ, щоб llm-d міг призначати йому завдання.

Підтримка з першого дня та безперервне тестування

У дописі від 20 серпня 2026 року команда IBM Spyre розповідає про HF-adapters — проєкт, у якому агенти програмування створюють чернетки патчів для середовища виконання, щоб стандартні моделі Hugging Face Transformers могли працювати на Spyre. З середини квітня до кінця червня 2026 року з’явилося 13 різних адаптерів, які охопили 7 960 із 10 000 моделей вбудовувань Hugging Face із найбільшою кількістю завантажень; 6 804 із них пройшли наскрізне тестування на Spyre, повідомляється в дописі. Наприклад, активацію gelu_new замінено з torch.pow(x, 3.0) на математично тотожний вираз x x x, який стек torch-spyre може оптимізувати. Люди й надалі займаються діагностикою: визначають збої, що виникають лише на пристрої через об’єднані операції, та звіряють висновки кожного агента з результатами наскрізного тестування.

У дописі від 30 вересня 2026 року інженери IBM і Red Hat описали інтеграцію L2 у torch-spyre з Cross-Repository CI Relay для PyTorch. Цей механізм запускає подальше тестування у відповідь на зміни в основному репозиторії PyTorch і надсилає результати назад на інформаційну панель CI PyTorch. Інтеграція поєднує чотириетапний конвеєр вибору тестів на основі агентів із декларативною системою повторного використання тестів у YAML. За словами авторів, перехід із PyTorch 2.13 на 2.14 вимагав оцінити приблизно 4 000 змінених тестів замість десятків тисяч. Вони додали, що планують співпрацювати з командою PyTorch, щоб перенести багаторазово використовувані компоненти до основного репозиторію, взявши PyTorch OpenReg за орієнтир.

Як зазначається в дописі IBM, користувачі IBM Z, LinuxONE і Power11 мають отримувати моделі з таких екосистем, як Hugging Face, і користуватися майже тими самими робочими процесами на базі PyTorch, що й на графічних процесорах Nvidia; спільні точки розширення PyTorch приховуватимуть значну частину архітектурних відмінностей. Автори допису про vLLM повідомили, що планують почати включати апаратно-незалежні моделі до CI та поступово зробити цей підхід типовим для обслуговування моделей на Spyre.