В октябре 2025 года IBM и PyTorch Foundation намекнули на планы по более глубокой интеграции Spyre в 2026 году: рассмотрение ускорителя как бэкенда PyTorch первого уровня и поддержка многоускорительного планирования. Последние обновления программной экосистемы воплощают это обещание в жизнь. Совместные усилия над torch-spyre, плагином vLLM для Spyre, улучшениями компилятора и непрерывной интеграцией упрощают перенос привычных моделей и рабочих процессов на другой класс аппаратного обеспечения для ИИ.
ИИ все глубже внедряется в системы, которые обрабатывают транзакции, обнаруживают мошенничество, анализируют претензии и помогают сотрудникам. Вместе с этим растущим использованием расширяется и экосистема аппаратного обеспечения для ИИ. Графические процессоры остаются центральным элементом современного ИИ, но к ним все чаще добавляются ускорители с другой архитектурой, моделями выполнения и характеристиками производительности. Предоставление разработчикам большего выбора требует нечто большего, чем просто создание новых чипов. Программная экосистема должна сделать новые ускорители пригодными для использования, не заставляя разработчиков отказываться от привычных моделей, инструментов и рабочих процессов.
Spyre — это датафлоу-ускоритель ИИ от IBM, оптимизированный для инференса. Он разработан для корпоративных команд, запускающих ИИ вместе со своими приложениями и данными на системах IBM Z, LinuxONE и Power. Его вычисления с пониженной точностью отлично подходят для задач генерации текста и моделей вложений, требующих интенсивных матричных вычислений. В отличие от обычного графического процессора, который выполняет ядра в виде потоков инструкций по расписанию для групп потоков, Spyre инициирует вычисления по мере поступления данных в свои вычислительные ядра. PyTorch обеспечивает общий слой, который позволяет этой принципиально иной архитектуре участвовать в экосистеме, построенной главным образом вокруг графических процессоров.
Расширение PyTorch за пределы графических процессоров
В центре этих усилий находится бэкенд PyTorch, который компилирует обычный код PyTorch в исполняемый план для Spyre. Большая часть логики модели проходит через компилятор PyTorch без изменений. Когда модель содержит операцию, которую нижележащий стек еще не может эффективно транслировать, адаптер может заменить ее математически эквивалентной формой, с которой компилятор может справиться. Вычисления модели остаются прежними, в то время как ее реализация становится совместимой с ускорителем.
Переход на бэкенд Inductor от PyTorch также сократил объем пользовательского кода компилятора, который команда должна поддерживать. Полученный компилятор примерно в семь раз меньше замененной системы и заметно менее сложен в расчете на одну функцию. Такая меньшая площадь поверхности упрощает перенос улучшений из вышестоящего PyTorch в torch-spyre и позволяет сосредоточить работу, специфичную для Spyre, там, где это действительно важно.
Тот же принцип применим и на границе устройств. В недавней демонстрации перенос построения графа с пути передачи данных повысил производительность модели Granite 3.3 8B при размере батча 1 и длине последовательности 1024 на 9,9% для префилла и на 13,6% для декодирования. Устранение этой работы также и из распределения вычислений привело к общему увеличению скорости: префилл ускорился в 1,7 раза, а декодирование — в 2,4 раза, причем примерно три четверти прироста были получены за счет вычислительного пути.
Сохранение переносимости vLLM
Spyre является ускорителем вне дерева исходного кода (out-of-tree), а не одной из платформ графических процессоров, наиболее часто поддерживаемых программным обеспечением для ИИ. Spyre опирается на TorchDynamo для трассировки графа модели и TorchInductor для его транслирования в представления, оптимизированные под целевое железо. Внутри vLLM механизмы расширения, такие как CustomOp и PluggableLayer, позволяют аппаратному плагину настраивать поведение без переписывания больших частей программного стека.
Сохранение этих точек расширения имеет решающее значение по мере развития vLLM. Некоторые новые реализации моделей становятся все более специализированными для конкретных моделей и передового оборудования на базе GPU. Для сохранения переносимости наряду с этой работой по оптимизации сообщество vLLM разрабатывает аппаратно-независимые слои, изолированные от аппаратно-специфичных путей и спроектированные так, чтобы их можно было компилировать, расширять и переносить между различными платформами ускорителей. Ранняя поддержка уже появилась в vLLM, и этот путь был проверен с помощью плагина Spyre на таких моделях, как Gemma 4, Qwen3 и Granite 4.2. На графических процессорах NVIDIA H100 эти аппаратно-независимые слои обеспечили общую пропускную способность токенов в пределах 3,4% от нативной реализации, измеренную как среднегеометрическое значение по трем последним моделям.
Один рабочий процесс, больше аппаратных возможностей
Для пользователей IBM Z, LinuxONE и Power11 предполагаемый опыт использования прост: получать модели из таких экосистем, как Hugging Face, и использовать практически те же рабочие процессы на базе PyTorch, которые они использовали бы с графическими процессорами Nvidia. Общие точки расширения PyTorch скрывают большую часть архитектурных различий под фреймворком, уменьшая препятствия для внедрения и избавляя от необходимости ограничиваться небольшим каталогом специально упакованных весов моделей.
Рассмотрим рабочий процесс обработки страховых претензий, который объединяет модели XGBoost для обнаружения мошенничества с моделью Gemma 26B на Spyre для криминалистического анализа. Программный стек позволяет разработчикам собирать рабочий процесс, используя привычные экосистемы моделей и интерфейсы фреймворков, в то время как аппаратное обеспечение выбирается под конкретные задачи.
Интеграция Spyre с PyTorch — это также способ подключения к llm-d. llm-d запускает распределенный инференс поверх vLLM и создан для поддержки нескольких типов ускорителей, а не какого-то одного аппаратного пути. vLLM взаимодействует с каждым ускорителем через PyTorch: как только у устройства появляется рабочий бэкенд PyTorch, аппаратный плагин vLLM может задействовать его, после чего llm-d может планировать на нем работу. Spyre следует именно этим путем. torch-spyre предоставляет бэкенд PyTorch, а плагин Spyre для vLLM надстраивается поверх него. В результате работа, которая делает Spyre устройством PyTorch, является той же работой, которая делает его пригодным для использования в развертываниях llm-d.
Делаем совместимость измеримой
Широкая совместимость полезна только тогда, когда у пользователей есть четкие доказательства того, что модели стабильно работают на разных платформах. Инженеры IBM Research собирают такие доказательства с помощью сквозного тестирования моделей и непрерывной интеграции. Эта работа помогает команде обнаруживать, когда изменения в вышестоящих фреймворках влияют на поддержку оборудования на уровне ниже.
Сквозное тестирование моделей имеет решающее значение, поскольку сбои могут возникать из-за комбинаций операций, форм, макетов, диапазонов чисел и поведения слияния компилятора, которые изолированные модульные тесты не выявляют. Запуск реальных моделей по сравнению с доверенными эталонами CPU или GPU превращает каждую модель одновременно в тест на совместимость и зонд для укрепления платформы. Это также дает разработчикам более четкие сигналы о том, какие модели и конфигурации ускорителей тестировались вместе.
Во втором полугодии 2026 года IBM, Red Hat и их партнеры по фонду PyTorch Foundation, включая Meta и Hugging Face, выпустили новые обновления программной экосистемы, охватывающие поддержку моделей с первого дня, аппаратно-независимые модели в vLLM, непрерывное тестирование на регрессию и релизы, а также интеграцию с нативными устройствами. Новая демонстрация фронтенд- и бэкенд-компилятора подробно описывает стек. В совокупности эта работа показывает, как адаптеры моделей, пути компилятора, интеграция среды выполнения, расширения vLLM и CI/CD объединяются для поддержки Spyre в качестве полноправного участника экосистемы PyTorch.
Объединяя привычные рабочие процессы, переносимые пути компилятора, широкую поддержку моделей и прозрачную валидацию, IBM помогает сделать выбор оборудования практическим решением, а не бременем интеграции программного обеспечения.
