IBM Spyre перевёл torch.compile с самописного sendnn на открытый Inductor

У IBM Spyre 32 ускорительных ядра и до 128 ГБ памяти LPDDR5 на одной PCIe-карте, а теперь у него другой компилятор в PyTorch. Программный стек Spyre перешёл с sendnn, отдельной системы компиляции, написанной с нуля, на backend=inductor. Это открытый бэкенд torch.compile, который в PyTorch используется по умолчанию. Об этом сообщил PyTorch Blog. В доступной части анонса есть только тезис о смене бэкенда, без бенчмарков, так что оценивать приходится архитектурный смысл шага.

Что именно поменялось

До сих пор путь модели на Spyre выглядел так. Пользователь вызывал torch.compile, граф уходил в sendnn, и дальше всё решал компилятор IBM, не связанный с остальной экосистемой PyTorch. Теперь граф проходит через Inductor, который берёт на себя захват графа, декомпозицию операторов, планирование и слияние ядер. Спецификой Spyre занимается только расширение, подключённое к Inductor.

Для Inductor такая схема штатная. Он генерирует код Triton для GPU и C++ для CPU, а точки расширения позволяют подключать сторонние устройства, не форкая весь компилятор. Spyre становится ещё одним таким устройством.

Почему не свой компилятор

Собственный стек даёт полный контроль, но дорого обходится. Каждое нововведение PyTorch, от новых операторов до динамических форм и изменений в AOTAutograd, приходится догонять вручную. Свежие модели ломают покрытие операторов, и команда обновляет компилятор под каждую архитектуру отдельно.

Используя Inductor, IBM получает часть этой работы бесплатно:

• декомпозиции операторов, которые поддерживает сообщество PyTorch;
• общие оптимизации графа и слияние операций;
• единый путь отладки и профилирования, знакомый разработчикам, которые уже работали с GPU;
• меньший объём кода, который IBM нужно поддерживать самостоятельно.

Цена тоже есть. Inductor проектировался вокруг GPU и CPU с их моделями памяти и параллелизма. Spyre устроен иначе: это ускоритель с собственной организацией вычислений и данных. Часть оптимизаций, которые sendnn делал под железо напрямую, теперь надо выразить через расширения Inductor, и это может оказаться сложнее, чем звучит.

Что известно о Spyre

Spyre вырос из исследовательского чипа IBM AIU и ориентирован на инференс в корпоративных системах, в первую очередь на мейнфреймах IBM Z и серверах Power. Ключевые параметры по публичным данным IBM:

• 32 ускорительных ядра;
• около 25,6 млрд транзисторов, техпроцесс 5 нм;
• до 128 ГБ памяти LPDDR5 на карте;
• форм-фактор PCIe, порядка 75 Вт на карту;
• целевой сценарий: инференс генеративных и классических моделей внутри корпоративного периметра.

За ускорителем стоит понятная логика. Банки и страховщики хотят запускать модели рядом с данными, не вынося их в облако, а для этого нужен привычный для разработчиков стек. Переход на Inductor двигает Spyre именно в эту сторону.

Практика

Пока в открытом доступе нет таблиц скорости и покрытия операторов, переход стоит оценивать по нескольким признакам.

1. Работает ли ваша модель с backend=inductor на Spyre без правок, и сколько графовых разрывов остаётся после компиляции. 2. Как изменилось время компиляции по сравнению с sendnn, особенно для больших LLM с динамическими формами. 3. Сравнима ли производительность на ваших моделях с прежним бэкендом. Если нет, надо смотреть, где расширение Inductor не использует возможности железа. 4. Как быстро в стеке появляются новые версии PyTorch. Это главный практический выигрыш от смены архитектуры: чем меньше собственного кода, тем короче отставание.

Командам, которые планируют инференс на IBM Z или Power, разумно сразу собрать тестовый набор своих моделей и прогнать его на обоих бэкендах, пока sendnn ещё доступен для сравнения. Если Inductor справится без потери скорости, у Spyre станет на одну причину меньше отличаться от остальных ускорителей в PyTorch.