AMD и Intel объединят оптимизации PyTorch в oneDNN

AMD и Intel договорились объединять оптимизации PyTorch для процессоров x86 в открытой библиотеке oneDNN. AMD планирует перенести в неё наработки ZenDNN, чтобы разработчикам было проще поддерживать ИИ-приложения на процессорах обеих компаний. Анонс опубликован 20 октября 2026 года; 21 октября о нём сообщили профильные издания.

Это сотрудничество вокруг программного слоя вычислений. Оно не означает появления общего процессора или немедленного ускорения любой нейросети после обновления Python-пакета. Главный смысл для разработчика — меньше разветвлений в поддержке CPU-инференса и более общий путь получения оптимизаций.

Что именно объявили AMD и Intel

Согласно сообщению AMD, компании выбрали oneDNN в качестве общей открытой библиотеки ускорения x86 в PyTorch. Решение связано с рекомендацией x86 Ecosystem Advisory Group — группы, в которой участники согласуют развитие экосистемы этой архитектуры.

AMD интегрирует оптимизации ZenDNN в oneDNN и присоединилась к Unified Acceleration Foundation, или UXL, как steering member. Именно UXL управляет проектом oneDNN. При этом AMD продолжит оптимизировать работу на собственных процессорах: общая библиотека не отменяет различия между поколениями и устройством чипов.

В анонсе также упомянуты AI Compute Extensions, сокращённо ACE. Это направление развития инструкций x86 для ускорения матричных вычислений; поддержку в PyTorch планируют проводить через будущие обновления oneDNN. Срок появления конкретных возможностей в используемой вами сборке из этого объявления определить нельзя.

Что такое oneDNN и где здесь PyTorch

PyTorch предоставляет разработчику операции над тензорами и инструменты работы с нейросетями. Но выражение в Python ещё нужно превратить в вычисления на конкретном оборудовании. Библиотеки нижнего уровня содержат реализации таких операций, рассчитанные на особенности процессора и доступные инструкции.

oneDNN — одна из таких библиотек. В ней есть оптимизированные операции глубокого обучения, включая умножение матриц и свёртки. Она используется в разных фреймворках и средах исполнения. В определённых конфигурациях библиотека определяет доступные инструкции во время работы и выбирает подходящий вычислительный код.

Полезно представить три уровня: модель описывает вычисление, PyTorch организует его выполнение, а выбранный backend реализует поддерживаемые операции на устройстве. Backend — это нижележащий механизм исполнения. От того, какие операции действительно попали в него, зависит и результат оптимизации.

В документации PyTorch по CPU можно встретить название MKLDNN и параметры torch.backends.mkldnn. Это не признак того, что для новой инициативы нужен отдельный фреймворк: соответствующий backend уже существует. Однако его наличие в конкретной установке и поддержка нужных операций требуют отдельной проверки.

Зачем объединять оптимизации двух производителей

Представим команду, которая разворачивает один сервис на нескольких площадках: часть серверов с процессорами AMD, часть — Intel. Чем больше отдельных веток настройки, зависимостей и инструкций установки, тем сложнее воспроизвести окружение, диагностировать сбой и перенести приложение на другую машину.

Общее место разработки оптимизаций может сократить такую сложность. Например, инженеру будет проще сопоставлять изменения библиотеки с поведением одной модели на двух стендах. Это наш практический разбор смысла инициативы; в анонсе нет обещания, что все варианты установки сразу станут одинаковыми.

Где это может пригодиться

CPU-инференс — выполнение уже обученной модели на центральном процессоре — интересен для задач, где важны доступность обычных серверов и отсутствие отдельного ускорителя. В зависимости от модели и нагрузки это могут быть классификация запросов, обработка признаков, небольшие модели или отдельные этапы поиска по документам.

Например, в системе RAG генерация ответа и обработка входных данных могут выполняться разными компонентами. Улучшение одной CPU-операции полезно только в той мере, в какой она влияет на весь путь запроса. Если основное время уходит на обращение к внешнему API или чтение документов, ускорение матричного умножения не устранит это ожидание.

Для локальных языковых моделей тоже нужно учитывать движок исполнения. Новость относится к сотрудничеству вокруг PyTorch и oneDNN. Нельзя автоматически переносить ожидаемый эффект на любую программу для запуска GGUF-моделей: формат весов, backend и способ сборки — отдельные части системы.

Почему это не обещание заменить GPU

Из заявления не следует, что центральные процессоры сравняются с ускорителями на любых задачах. Для выбора оборудования нужны требования конкретного приложения: размер модели, доступная память, задержка, число параллельных запросов и стоимость эксплуатации. Унификация программного слоя сама по себе не меняет эти ограничения.

Также нельзя считать, что весь код PyTorch работает через одну библиотеку. У разных операций и устройств свои пути выполнения. Совместимость приложения на уровне Python ещё не подтверждает одинаковую производительность на двух CPU, а успешный запуск не доказывает, что нужные оптимизации использованы.

В первичном анонсе нет универсального процента прироста для объединённых наработок. Поэтому цифры из старых тестов oneDNN или ZenDNN нельзя выдавать за измеренный результат этого сотрудничества. Для читателя важнее понимать статус изменений: объявлен общий курс разработки, а свойства конкретных релизов предстоит смотреть отдельно.

Что проверить разработчику перед обновлением

Переустанавливать рабочую среду только из-за заголовка новости не нужно. Подготовьте отдельное окружение и запишите исходные версии PyTorch, библиотек, ОС и модель CPU. Затем сверяйте примечания к релизам: попали ли туда изменения, которые относятся к вашей задаче.

1. Зафиксируйте нагрузку. Используйте одинаковую модель, входные данные, длину запросов и число одновременных обращений.
2. Сравнивайте весь запрос. Измеряйте задержку, пропускную способность и память после прогрева, а не только одну удобную операцию.
3. Следите за потоками. Несколько процессов с большим числом потоков могут конкурировать за те же ядра; условия сравнения должны быть явными.
4. Проверяйте качество. Изменение точности вычислений оценивайте вместе с допустимой ошибкой результата.
5. Сохраняйте возможность отката. Рабочие зависимости обновляйте после сравнения в отдельном окружении.

Это план проверки для своей инфраструктуры, а не результаты нашего бенчмарка. Для небольшого проекта достаточно начать с одного типичного сценария и двух сопоставимых запусков. Так будет видно, помогает ли обновление реальному сервису, а не только синтетическому примеру.

Что стоит запомнить

AMD и Intel собирают работу над CPU-оптимизациями PyTorch вокруг oneDNN. Для разработчиков это перспективное упрощение поддержки приложений на разных x86-серверах. Практическую пользу будут определять конкретные версии, поддерживаемые операции и измерения на собственной нагрузке; объявление о сотрудничестве пока не заменяет эти проверки.