Когда выходит очередной ИИ-чип, его поддержка в PyTorch решается не презентацией, а месяцами инженерной работы: регистрация устройства, диспатч операторов, тесты, профилировка. Эту работу почти не видно снаружи, но от неё зависит, появится ли поддержка нового железа за недели или за годы. Поддержка чипа складывается из десятков шагов, и чем стандартнее этот путь, тем быстрее железо доходит до пользователей.

В PyTorch этой работой занимается Accelerator Integration Working Group, рабочая группа по интеграции ускорителей. В первом полугодии 2026 года она довела до рабочего состояния несколько крупных проектов: механизм кросс-репозиторного CI, рефакторинг тестового набора из 600 000+ тестов и эталонные реализации интеграции для вендоров. Разбираем, как всё это устроено и почему это важно всем, кто запускает PyTorch на чём-то кроме NVIDIA.

Что такое рабочая группа по интеграции ускорителей

Accelerator Integration Working Group это сообщество контрибьюторов PyTorch, которое стандартизирует подключение новых аппаратных платформ к фреймворку. Группа создаёт вендор-нейтральные механизмы интеграции: единые пути для регистрации устройств, тестирования, профилировки и компиляции. Цель в том, чтобы вендору не приходилось поддерживать собственный набор патчей, а экосистема не расползалась на десятки несовместимых форков.

Проблема: у каждого вендора были свои патчи

PyTorch давно перестал быть фреймворком для одного типа железа. Кроме CUDA в нём есть бэкенды Intel XPU, AMD ROCm, Apple MPS и Qualcomm AI Engine, плюс десятки ускорителей, подключённых через механизм PrivateUse1. Вокруг этого слоя живут vLLM, SGLang и Transformers.

Цена этой схемы долгое время была высокой. Тесты PyTorch, а их больше 600 000, писались под конкретные ускорители: строки вида device="cuda", вызовы torch.cuda.synchronize() и декораторы @onlyCUDA встречались по всему коду. Вендору, который хотел прогнать тесты на своём чипе, приходилось поддерживать собственные патчи, а каждое обновление PyTorch требовало ручной адаптации. Чем быстрее выходили релизы, тем дороже обходилась эта работа. Каждый апгрейд требовал перенести патчи на новую версию, а дублированная работа росла с каждым релизом. Для небольших команд поддержка собственного форка становилась неподъёмной, и отставание от апстрима накапливалось.

Отдельная проблема касалась CI. У самого PyTorch зрелый и обширный пайплайн, но он живёт внутри репозитория pytorch/pytorch. Даунстрим-проекты не имели стандартного способа узнать, когда тестировать свои изменения против свежего апстрима, и как сообщать результаты обратно. Контрибьюторы PyTorch не могли понять до мержа, сломает ли их PR чужой бэкенд, а мейнтейнеры железа узнавали о поломках постфактум.

CRCR: CI-эстафета между репозиториями

Часть проблемы закрыл Cross-Repository CI Relay, сокращённо CRCR. Когда в pytorch/pytorch открывается PR или пушится коммит, вебхук запускает CI во всех зарегистрированных даунстрим-репозиториях параллельно, а результаты через аутентифицированные колбэки собираются в дашборд PyTorch CI HUD. Архитектуру и модель доверия мы подробно разбирали в отдельном посте про CRCR. Здесь важен итог: изменения ядра PyTorch теперь штатно тестируются против внешних бэкендов до мержа, а не после.

600 000 тестов перестают быть CUDA-тестами

Корректность нового бэкенда проще всего проверять, прогоняя на нём существующий тестовый набор PyTorch. Проблема в том, что этот набор исторически писался под конкретные бэкенды: device-строки, активности профилировщика, API памяти и skip-декораторы были захардкожены. В первом полугодии рабочая группа начала системную отвязку тестов от железа.

В основе миграция на device-agnostic конструкции: вместо жёстких device-строк и декораторов используется параметризация вида instantiate_device_type_tests(), которая автоматически создаёт варианты теста для каждого зарегистрированного бэкенда. Как из шаблонов рождаются конкретные имена тестов, разбирали в гайде по тестовой инфраструктуре. За первое полугодие мигрировали больше 276 файлов, среди них dynamo, profiler, nn-модули, linalg, оптимизаторы, свёртки, сериализация, мультипроцессинг и dataloader.

Дальше тесты получают классификацию. Атрибут hw_classification делит их на категории GENERIC, DEVICE_GENERIC, CUDA, XPU и MPS, а CI-раннеры автоматически выбирают подходящее подмножество под своё железо. Линтер HW_CLASSIFICATION следит, чтобы каждый новый тестовый класс объявлял категорию. Неклассифицированные файлы, а их на старте было 1 191, пока живут в аллоулисте и постепенно сокращаются. Всего в проекте рефакторинга отслеживается 259 пунктов.

Для вендора это меняет всю процедуру онбординга. Вместо патчинга сотен тестовых файлов под свой чип достаточно параметризации: тесты, которые раньше были невидимы для не-CUDA бэкендов, теперь запускаются на любом зарегистрированном ускорителе. Один device-agnostic тест валидирует конфигурации сразу на CUDA, MPS, XPU, ROCm и PrivateUse1. В планах на второе полугодие расширение покрытия на distributed, JIT и autograd, привязка классификации к планировщику CI и реестр возможностей операторов, где ускоритель сам декларирует поддерживаемые типы данных и точности.

OpenReg: эталонный бэкенд, который никого не ускоряет

Подключение нового ускорителя требует реализовать регистрацию устройства, диспатч операторов, работу со стримами и событиями, интеграцию с autograd. Раньше вендоры реверсили продакшн-бэкенды и смешивали особенности конкретного железа с самими паттернами интеграции. OpenReg закрывает эту дыру: это встроенный эталонный бэкенд для интеграции через PrivateUse1.

Важная деталь: OpenReg не продакшн-бэкенд. Это минимальная реализация на CPU, которая изолирует механику интеграции от сложности железа. В первом полугодии группа расширила покрытие базовых паттернов, включая регистрацию устройства, диспатч, стримы и события, синхронизировала реализацию с документацией и укрепила OpenReg как валидационный каркас. Он прогоняется в CI и ловит поломки механизмов PrivateUse1 раньше, чем они дойдут до вендоров. По сути это живая документация в виде кода, и CI не даёт ей устареть. Логика простая: если что-то работает в OpenReg, оно заработает и в вашем бэкенде.

Отдельный эффект касается расхождений между вендорами. Раньше каждая команда собирала картину интеграции по кускам: документация, код продакшн-бэкендов, обсуждения в трекерах. OpenReg даёт единый ориентир, а тесты на его основе работают как защитный контур: если механизм PrivateUse1 сломается в очередном релизе, поломку поймают до того, как она дойдёт до железа. Документации тоже можно доверять: сценарий, который работает в OpenReg, заработает и у вендора.

Профилировка, распределёнка и компилятор

Три продвинутых участка интеграции получили свои эталонные реализации. Для профилировки появился API REGISTER_PRIVATEUSE1_PROFILER: он позволяет внешнему бэкенду подключить собственный IActivityProfiler в Kineto без правок в PyTorch и Kineto. OpenReg обзавёлся stub-стеком с трейсером, управлением жизненным циклом сессий, типами активностей и correlation ID, всё покрыто end-to-end тестами через torch.profiler. Раньше у вендоров было два плохих варианта: грубый тайминг операторов через легаси-путь ProfilerStubs или реверс внутренних плагинов вроде CUPTI и XPUPTI, где вендорский тулинг смешан с паттернами интеграции. Для пользователей результат практический: трейсы нестандартного железа в Chrome и Perfetto становятся полнее, а узкие места видно на уровне отдельных ядер.

Для распределённого обучения построили OCCL, OpenReg Collective Communications Library. Это минимальная эталонная реализация кастомного c10d-бэкенда (RFC #176877): она показывает, как зарегистрировать ProcessGroup, диспатчить коллективные операции и управлять семантикой завершения Work. Продакшн-перформанс не цель. Цель в том, чтобы вендору не приходилось выводить контракт интеграции из исходников NCCL, которые жёстко связаны с аппаратными библиотеками коммуникаций.

Для torch.compile сделали интеграцию с Dynamo и Inductor: OpenReg демонстрирует захват графа, планирование, генерацию кода и переопределение операций устройства без модификации апстрим-кода. В документацию по интеграции ускорителей добавили пошаговый гайд по обоим слоям компилятора. Раньше вендорам приходилось изучать кодовые пути CUDA и Triton, где механика регистрации перемешана с аппаратной спецификой планирования и кодогенерации.

Путь интеграции выглядит так: Dynamo захватывает граф и управляет устройством, Inductor планирует вычисления, генерирует обёртки и fused-ядра, а бэкенд может переопределять операции под своё железо. Подключиться можно на любом уровне: минимально достаточно захвата графа, а команды, которым нужны оптимизации, идут глубже, в проходы и кодогенерацию.

Официальная страница платформ

На pytorch.org появилась страница Additional Platforms, официальный список вычислительных платформ с поддержкой PyTorch. Она связана с главной страницей установки, а попадание на неё проходит через формальный процесс: вендор открывает issue с заявкой и подтверждает требования ссылками, документацией, CI-дашбордами и политикой безопасности. У пользователей впервые есть foundation-управляемый источник информации о том, какие платформы поддерживаются официально, а какие нет. Формальный процесс здесь ценен не бюрократией, а проверяемостью: статус платформы теперь можно подтвердить, а не принимать на веру.

Что это значит на практике

Вычислительные платформы продолжают расходиться: облака, край, специализированные чипы. Каждый новый ускоритель без стандартного пути интеграции означает лишние форки и месяцы работы на патчи. От этого слоя зависит, станет ли поддержка следующего NPU вопросом месяцев или застрянет в форке на годы. Механизмы рабочей группы снижают эту цену для всех сторон сразу.

Вендоры получают внятный контракт: эталонные реализации, единый тестовый набор, понятный процесс попадания на официальную страницу. Пользователи получают более предсказуемую поддержку нового железа и меньше шансов, что обновление PyTorch сломает нестандартный бэкенд: апстрим-PR теперь тестируются против даунстрим-проектов до мержа. Если вы работаете на Apple MPS, AMD ROCm или редком NPU, это ваш случай. А сам PyTorch всё меньше похож на зоопарк из десятка несовместимых сборок. Экономика здесь простая: работа по интеграции делается один раз в апстриме и переиспользуется всеми вместо дублирования в каждом форке.

Часто задаваемые вопросы

Что такое PrivateUse1?

Это механизм PyTorch для внешних бэкендов ускорителей. Вендор регистрирует собственный тип устройства через PrivateUse1 и реализует для него диспатч операторов, работу с памятью и стримами. Так подключаются ускорители, которым не нужен отдельный встроенный бэкенд вроде CUDA или MPS, и именно эту схему стандартизирует рабочая группа через эталонные реализации OpenReg.

Значит ли это, что PyTorch теперь работает на любом железе?

Нет. Эталонные реализации намеренно минимальны: OpenReg работает на CPU, а OCCL не гонится за перформансом. Они показывают вендору контракт интеграции, но реальный бэкенд с ядрами и оптимизациями чипу всё ещё придётся писать самому. Группа стандартизирует путь и валидирует механизмы, но не подменяет работу вендора.

Что это даёт мне как пользователю PyTorch?

Новые ускорители получают поддержку быстрее, потому что вендору не нужно с нуля выводить паттерны интеграции. Обновления PyTorch реже ломают нестандартные бэкенды: апстрим-PR тестируются против даунстрим-проектов до мержа. И тесты, которые раньше запускались только на CUDA, теперь валидируются на любом зарегистрированном ускорителе, включая тот, на котором работаете вы.

Итог

Работа группы по интеграции ускорителей это история про инфраструктуру, которая делает разнообразие железа управляемым. CI-эстафета CRCR показывает кросс-репозиторные поломки до мержа, рефакторинг отвязывает 600 000 тестов от CUDA, OpenReg и OCCL дают вендорам эталонный путь интеграции, а гайд по компилятору закрывает последний крупный участок. Если вы поддерживаете бэкенд ускорителя, следующий шаг очевиден: изучить репозиторий рабочей группы на github.com/pytorch-fdn/accelerator-integration-wg и заявку на Additional Platforms. Если вы просто запускаете PyTorch на необычном железе, теперь есть куда смотреть, когда что-то ломается.