ONNX простыми словами: как локальный ИИ работает на AMD, Intel и NVIDIA

Многие приложения для локального ИИ выглядят так, будто зависят от одного производителя GPU. На практике выполнение модели определяется не только самой моделью, но и тем, как она подключается к доступному оборудованию. Именно здесь появляются ONNX, ONNX Runtime и так называемые Execution Providers.

ONNX задаёт стандартизированную основу для моделей ИИ. ONNX Runtime загружает и выполняет эти модели. Execution Providers связывают Runtime с доступным CPU, GPU или NPU. Благодаря этому приложение локального ИИ может использовать разные пути выполнения на системах AMD, Intel и NVIDIA.

VANIV применяет эту архитектуру для локальной обработки аудио, речи и видео. В статье разберём, что такое ONNX, как работает аппаратное ускорение и почему гибкость по оборудованию не означает одинаковую скорость на каждом компьютере.

Что такое ONNX? Открытый формат моделей ИИ

Общий формат для обученных моделей

Упрощённо ONNX можно представить как общий формат файлов для обученных моделей ИИ. MP3 помогает воспроизводить аудиофайлы в разных программах, а JPEG выполняет похожую роль для изображений. ONNX переносит эту общую идею на модели ИИ, хотя технически устроен значительно сложнее.

ONNX означает Open Neural Network Exchange. Формат описывает вычислительный граф модели, операции, типы данных и сохранённые параметры. Например, модель можно разработать в PyTorch, экспортировать в ONNX и затем загрузить в совместимую Runtime.

Сравнение с MP3 и JPEG помогает понять принцип, но не является техническим тождеством. Модель ИИ — не просто медиафайл. Она содержит структуру вычислений, определённые входы и выходы, а также обученные веса.

Простой пример с распознаванием речи

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

После экспорта модель хранится в файле ONNX. ONNX Runtime может загрузить этот файл, принять подготовленные аудиоданные и вернуть распознанный текст либо промежуточный результат, который приложение обработает дальше.

Преимущество ONNX не в том, что он устраняет все технические ограничения. Его ценность — в более чётком разделении разработки модели и её последующего выполнения.

Кто развивает ONNX?

Microsoft и Facebook, сегодня Meta, совместно представили ONNX в 2017 году. Со временем формат превратился в проект с открытым управлением под эгидой LF AI & Data.

Это важно, потому что ONNX не является закрытым форматом одного производителя оборудования. Он формирует общую техническую основу для разных фреймворков, runtimes и аппаратных экосистем.

ONNX и нативные форматы фреймворков

PyTorch, TensorFlow и другие среды разработки используют собственные форматы и инструменты. Они важны для обучения, экспериментов и рабочих процессов внутри конкретного фреймворка.

ONNX создавался как формат обмена. Модель обучается в исходной среде, экспортируется в ONNX и затем выполняется в совместимой Runtime.

ONNX не заменяет исходный фреймворк полностью. Он добавляет к процессу разработки более переносимый слой выполнения.

Есть ли у ONNX ограничения?

Да. Не каждую модель можно экспортировать в ONNX без доработок. Динамический поток управления, пользовательские операторы и поведение, специфичное для конкретного фреймворка, могут усложнить экспорт и дальнейшее выполнение. Выбранный Execution Provider также должен поддерживать нужные операции, либо Runtime должна иметь альтернативный путь.

ONNX не ускоряет модель автоматически. Версия ONNX opset, версия Runtime и поддерживаемые операторы должны быть совместимы между собой. ONNX создаёт основу для переносимого выполнения, а реальная скорость зависит от оптимизации модели, Runtime, оборудования и Execution Provider.

Это не отменяет пользы ONNX. Общий формат просто не может самостоятельно решить все детали реализации.

Чем ONNX является — и чем не является

Сам по себе ONNX ещё не выполняет модель. Для этого нужна Runtime — следующий уровень архитектуры.

Что такое ONNX Runtime? Как модель выполняется на вашем оборудовании

Модель и Runtime — разные вещи

Файл ONNX содержит модель. ONNX Runtime — это среда выполнения, которая загружает модель и проводит вычисления.

Простая аналогия:

Модель ONNX — это чертёж. ONNX Runtime — машина, которая читает чертёж и выполняет работу.

ONNX Runtime анализирует и оптимизирует граф модели. Затем она выполняет вычисления с помощью доступных Execution Providers. Приложение передаёт входные данные и обрабатывает полученный результат.

Модель распознавания речи по шагам

Как это выглядит на примере реального аудиофайла?

1. Загрузка модели: ONNX Runtime открывает ONNX-файл с обученной моделью распознавания речи.
2. Подготовка аудио: приложение читает файл и преобразует его в формат, который ожидает модель.
3. Инференс: ONNX Runtime вычисляет результат с помощью доступных Execution Providers.
4. Формирование текста: модель возвращает распознанный текст или промежуточный результат, из которого приложение собирает транскрипт.
5. Следующий этап: приложение использует текст для субтитров, перевода или дальнейшей обработки речи.

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

Почему разделение уровней важно

Модель, Runtime, интеграция с оборудованием и пользовательский интерфейс остаются отдельными уровнями. Это позволяет:

• обновлять модели независимо от интерфейса
• подключать разные Execution Providers
• использовать одну логику приложения на нескольких аппаратных платформах
• отдельно оптимизировать подготовку данных и обработку результата

ONNX Runtime умеет загрузить и выполнить модель. Но как вычисления попадают на подходящее оборудование? За это отвечают Execution Providers.

Что такое Execution Provider? Связь между ONNX и CPU, GPU или NPU

Что делает Execution Provider

Execution Provider соединяет ONNX Runtime с определённой аппаратной платформой или технологией ускорения.

ONNX Runtime анализирует граф модели. Зарегистрированные Execution Providers сообщают, какие узлы или подграфы они способны выполнить. Runtime распределяет между ними поддерживаемые части. Оставшиеся операции могут перейти другому Provider либо стандартному CPU Execution Provider.

Execution Provider — не просто название в конфигурационном файле. Он связывает Runtime с оптимизированными вычислительными ядрами, управлением памятью и целевым оборудованием.

Аналогия с универсальным адаптером

ONNX Runtime можно представить как универсальный адаптер. Модель в основе остаётся той же, но подключение к оборудованию меняется:

• CUDA или TensorRT для NVIDIA
• MIGraphX для AMD
• OpenVINO для Intel
• DirectML как межпроизводительный путь Windows
• выполнение на CPU как широкая базовая возможность

Аналогия объясняет принцип, но не означает, что все Providers обладают одинаковыми функциями и скоростью.

Что происходит с неподдерживаемой операцией?

Если Execution Provider не может выполнить определённую операцию, ONNX Runtime может передать поддерживаемые части другому Provider, а остаток выполнить на CPU.

Набор Providers и порядок их регистрации относятся к технической конфигурации приложения. Пользователь VANIV работает с готовым процессом, а распределение вычислений происходит в фоновом режиме.

CPU, GPU и NPU: сравнение

Execution Providers создают основу аппаратно-гибкого ИИ. Теперь рассмотрим NVIDIA, AMD и Intel отдельно.

ONNX на NVIDIA: CUDA и TensorRT для локального ИИ

CUDA как зрелый путь выполнения

CUDA Execution Provider связывает ONNX Runtime с GPU NVIDIA. CUDA широко распространена в экосистеме ИИ, поэтому многие модели и приложения сначала оптимизируют именно для этого пути.

Для владельцев NVIDIA это означает зрелую среду выполнения с большим количеством программных инструментов и документации.

TensorRT как дополнительная оптимизация

TensorRT Execution Provider использует движок инференса NVIDIA для ускорения совместимых ONNX-моделей на GPU NVIDIA. TensorRT — дополнительный слой выполнения, а не сам формат ONNX.

Польза TensorRT зависит от модели, поддерживаемых операторов, выбранной точности и необходимого объёма оптимизации.

Что это значит для пользователя

Если у вас видеокарта NVIDIA, вам доступен широко поддерживаемый путь ONNX. При этом ONNX Runtime не ограничена CUDA. Именно эта открытость позволяет создавать приложения для разных производителей.

ONNX на AMD: DirectML, ROCm и MIGraphX

DirectML в Windows

DirectML — путь выполнения Windows для оборудования с поддержкой DirectX 12 независимо от производителя. Поэтому он актуален для графики AMD, Intel и NVIDIA.

DirectML продолжает поддерживаться, но находится в режиме sustained engineering. Новые функции для развёртывания ONNX Runtime в Windows Microsoft развивает через Windows ML. Windows ML также основан на ONNX Runtime и может управлять подходящими Execution Providers для CPU, GPU и NPU.

ROCm и MIGraphX

ROCm — платформа AMD для вычислений на GPU, особенно актуальная в Linux и продвинутых конфигурациях AMD. MIGraphX применяет оптимизацию графов AMD для ускорения ONNX-моделей на GPU AMD.

Прежний ROCm Execution Provider был удалён начиная с ONNX Runtime 1.23. Официальная документация рекомендует переносить подходящие нагрузки на MIGraphX.

Подходящая комбинация зависит от операционной системы, GPU, драйверов, пакета Runtime и модели.

Что это значит для пользователя

Оборудование AMD не исключается из локального ИИ только потому, что многие проекты сначала предлагают CUDA. ONNX и подходящие Execution Providers создают дополнительные пути, которые VANIV использует в гибкой архитектуре.

ONNX на Intel: CPU, графика, NPU и OpenVINO

CPU и графика Intel

Процессоры Intel могут выполнять ONNX-модели через CPU-пути. Встроенная графика Intel и дискретные GPU Intel Arc могут обеспечить дополнительное ускорение в зависимости от системы.

Поэтому компьютер Intel не обязательно ограничен инференсом только на CPU.

NPU в современных системах Intel

NPU предназначены для энергоэффективного инференса. Они особенно интересны в ноутбуках и компактных системах. Практическая применимость зависит от модели и доступного пути выполнения.

NPU не заменяет мощную GPU автоматически. Его задача другая: эффективный локальный инференс при меньшем энергопотреблении.

OpenVINO

OpenVINO — оптимизированный для Intel toolkit, который может подключаться к ONNX Runtime как Execution Provider. Актуальный OpenVINO Execution Provider поддерживает ускорение на CPU Intel, GPU Intel и NPU Intel.

Что это значит для пользователя

VANIV может включать доступные пути Intel в тот же локальный рабочий процесс. Интерфейс остаётся единым, а выполнение адаптируется к конкретной системе.

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

Старый ноутбук не превращается в мощную рабочую станцию. Это не проблема совместимости, а естественное следствие разницы в оборудовании.

Что это означает для вашего компьютера?

Производительность в основном определяется тремя факторами:

Совместимость и скорость — разные вопросы

Система может поддерживать рабочий процесс, но выполнять его заметно дольше.

Например:

• встроенная графика обычно имеет меньше вычислительных ресурсов
• дискретная GPU быстрее справляется с параллельными операциями
• крупным моделям требуется больше RAM или VRAM
• неподдерживаемые части могут выполняться на CPU, но медленнее

Почему здесь нет упрощённых «дуэлей видеокарт»

Утверждение «GPU A всегда быстрее GPU B» было бы ненадёжным без контролируемых условий. Корректное сравнение требует одинакового процесса, модели, версий драйверов, Execution Provider, настроек и исходных файлов.

Подробные сравнения видеокарт лучше выносить в отдельные тесты и руководства по выбору оборудования.

Почему ONNX важен для локального ИИ

Полностью локальное выполнение

Модели ONNX и ONNX Runtime можно полностью развернуть на локальном компьютере. Поэтому инференс не обязан выполняться в облаке.

Это особенно полезно для аудио и видео. Большие исходные файлы не нужно отправлять внешнему сервису на каждом этапе.

Контроль над файлами и процессом

Локальная обработка даёт больше контроля над исходниками, промежуточными результатами и экспортом. Она также уменьшает зависимость от скорости загрузки и доступности внешних сервисов.

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

Гибкость оборудования

Приложение и процесс не должны навсегда зависеть от одного производителя GPU. Модель, Runtime и аппаратный путь остаются отдельными компонентами.

Одна и та же программа может работать с разными системами без полностью отдельного интерфейса для каждой марки.

Поддерживаемая архитектура настольного приложения

Новые Execution Providers, поколения оборудования и версии моделей можно подключать к общей архитектуре. Это упрощает развитие локального программного обеспечения и снижает ненужную зависимость от одной платформы.

Как VANIV использует ONNX для локальной обработки аудио и видео

Один процесс для трёх аппаратных экосистем

Представьте три рабочих места:

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

Несколько этапов ИИ в одном локальном проекте

VANIV объединяет:

• локальное распознавание речи
• определение и распределение говорящих
• перевод видео с помощью ИИ
• Text-to-Speech и офлайн-голоса
• локальный Voice Cloning
• озвучивание видео
• многоголосое озвучивание
• коррекцию тайминга
• сведение аудио и экспорт

Не каждый этап обязательно использует одну и ту же модель или один Execution Provider. Ценность для пользователя в том, что все этапы образуют единый локальный проект, а не набор разрозненных инструментов.

Без обязательной загрузки в облако

• исходные файлы и экспорт остаются на вашем компьютере
• большие видео не нужно загружать повторно на каждом этапе
• локальные вычисления не требуют оплаты облака за каждую операцию
• конфиденциальные материалы не нужно отправлять внешнему сервису инференса

Для кого создан VANIV

VANIV предназначен для людей и команд, которые работают с аудио, речью или видео и хотят использовать локальный ИИ на оборудовании AMD, Intel или NVIDIA.

Это могут быть:

• авторы контента и видеопродюсеры
• компании с обучающими, маркетинговыми и поддерживающими видео
• агентства и команды локализации
• разработчики и энтузиасты ИИ
• пользователи, которым важна свобода выбора оборудования
• команды, предпочитающие локальную обработку постоянной зависимости от облака

Используйте локальный ИИ на своём оборудовании
VANIV объединяет распознавание речи, перевод, Voice Cloning и озвучивание видео в локальном процессе на AMD, Intel или NVIDIA.
Протестировать локальный ИИ на своём компьютере →

Какое оборудование подходит для локального ИИ?

Правильное оборудование зависит от задачи

Этот материал даёт общую ориентацию. Подробности доступны в разделе оборудования VANIV:

• Оборудование для локального ИИ: какие компоненты нужны
• Видеокарта для локального ИИ: GPU и VRAM
• Сколько RAM нужно локальному ИИ
• CPU и система для локального ИИ
• SSD для локального ИИ и больших медиапроектов

Общий раздел оборудования ведёт к отдельным материалам о RAM, CPU и SSD.

Частые вопросы об ONNX

Итоги: ONNX делает локальный ИИ гибким по оборудованию

Кратко:

• ONNX упрощает обмен обученными моделями ИИ.
• ONNX Runtime загружает, оптимизирует и выполняет их.
• Execution Providers связывают Runtime с CPU, GPU или NPU.

В результате архитектура может использовать разные пути выполнения на AMD, Intel и NVIDIA. Скорость по-прежнему зависит от конкретной системы, но основную логику процесса не нужно создавать заново для каждого производителя.

VANIV строится именно на этом подходе. Распознавание речи, перевод, Text-to-Speech, Voice Cloning и озвучивание видео объединяются в локальном процессе, который использует доступное оборудование AMD, Intel или NVIDIA. Вы выбираете компьютер — VANIV организует рабочий процесс.

Используйте локальный ИИ на своём оборудовании
VANIV объединяет обработку аудио, речи и видео в одном локальном процессе на AMD, Intel или NVIDIA.
Протестировать локальный ИИ на своём компьютере →

AMD, Intel, NVIDIA и соответствующие товарные знаки принадлежат их владельцам. VANIV является независимым продуктом и не связан с этими компаниями.