IBM делает ускоритель Spyre полноценным бэкендом PyTorch

В опубликованной 26 октября 2026 года публикации в блоге IBM Research IBM сообщила, что обновления программного обеспечения, выпущенные во второй половине 2026 года в экосистеме PyTorch, сделали её ускоритель потоковой обработки данных Spyre полноценным бэкендом PyTorch. Тем самым был реализован план, который IBM и PyTorch Foundation изложили в октябре 2025 года.

IBM описывает Spyre как свой ИИ-ускоритель потоковой обработки данных, оптимизированный для инференса и предназначенный для корпоративных команд, которые запускают ИИ наряду с приложениями и данными на системах IBM Z, LinuxONE и Power. Вычисления с пониженной точностью ориентированы на операции с матрицами, характерные для генерации текста и моделей векторных представлений. В отличие от обычного графического процессора, который выполняет ядра в виде потоков инструкций на запланированных группах потоков, Spyre запускает вычисления по мере поступления данных в вычислительные блоки.

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

Компилятор, заново построенный на базе Inductor

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

В публикации PyTorch Foundation от 13 октября 2026 года Dave Grove, Olivier Tardieu и команда 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 небольших ядер, соединённых кольцевой шиной. У каждого ядра есть собственная локальная память scratchpad объёмом 2 МБ вместо общей кэш-памяти; данные передаются блоками фиксированного размера — 128 байт, называемыми sticks. Как говорится в публикации, работа над компилятором была сосредоточена на перемещении данных с гранулярностью stick, планировании использования scratchpad и назначении ядер на этапе компиляции.

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

Интеграция с нативным устройством

Spyre становится нативным устройством PyTorch благодаря регистрации PrivateUse1, которая придаёт tensor.to(“spyre”) реальную идентичность устройства: аллокатор PyTorch выделяет память для тензоров, благодаря чему они остаются на устройстве; потоки обеспечивают упорядочение операций, а события среды выполнения связывают зависимые задачи в разных потоках. На карте установлено 32 ядра, соединённых высокоскоростной кольцевой шиной; у каждого ядра есть локальная память scratchpad объёмом 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, в котором агенты для написания кода создают черновые патчи времени выполнения, позволяющие запускать на Spyre стандартные модели Hugging Face Transformers. Как сообщается в публикации, с середины апреля до конца июня 2026 года 13 отдельных адаптеров обеспечили поддержку 7 960 из 10 000 наиболее загружаемых моделей эмбеддингов Hugging Face; 6 804 из них успешно прошли сквозное тестирование на Spyre. Например, в одном случае вызов torch.pow(x, 3.0) в функции активации gelu_new заменили на математически эквивалентное выражение 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.