local-transcriber/docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md

Куда движутся ONNX Runtime и OpenVINO: сравнение жизненного цикла

Дата: 2026-08-12

Статус: исследование для карты диаризации. Не архитектурное решение и не основание для консолидации всех движков распознавания на ONNX Runtime.

Вопрос

Насколько устойчивы ONNX Runtime, его DirectML и OpenVINO Execution Provider, а также нативный стек OpenVINO/OpenVINO GenAI; какой из путей с большей вероятностью сохранит Intel-ускорение и поддержку Whisper/NPU; что из этого практически доступно проекту на CPython 3.13.

Исследование опирается только на первичные источники: официальную документацию, release notes, репозитории владельцев и метаданные PyPI.

Границы в контексте проекта

Терминология следует CONTEXT.md: ONNX Runtime, OpenVINO и OpenVINO GenAI здесь — движки распознавания, их обновление само по себе не меняет поддерживаемую модель или модель по умолчанию. Архитектурная точка отсчёта — отдельные pluggable backends из ADR-003 и принятый ONNX CPU-путь из ADR-006.

Исследование дополняет срез обновлений движков и отвечает на инфраструктурный вопрос, открытый разведкой диаризации и бэклогом. Оно не пересматривает качество моделей и не принимает решение о полной консолидации на ORT.

Краткий вывод

1. ONNX Runtime — активно развиваемый, production-стабильный движок, но не все его EP имеют одинаковый жизненный цикл. Версии 1.26, 1.27 и 1.28 вышли 8 мая, 19 июня и 25 июля 2026 года, то есть три minor-релиза примерно за одиннадцать недель; 1.28 продолжает развивать plugin EP API, ядро, безопасность и аппаратные EP (1.26.0, 1.27.0, 1.28.0).
2. DirectML EP поддерживается, но переведён в sustained engineering. Новая функциональность Windows-пути перенесена в WinML; Microsoft рекомендует WinML для новых Windows-развёртываний, а DirectML EP оставляет для legacy и специальных сценариев (официальная страница DirectML EP, Windows-путь ORT). Поэтому onnxruntime-directml нельзя считать перспективным кросс-вендорным GPU-дефолтом проекта, хотя пакет не заброшен.
3. OpenVINO и OpenVINO GenAI — основной активно развиваемый Intel-стек. В 2026 году регулярные релизы вышли 23 февраля, 7 апреля, 28 мая и 4 августа; OpenVINO публикует формальную release/LTS policy, где регулярная версия поддерживается до следующей, а последняя версия года становится LTS с двумя годами security updates (release notes, release policy).
4. Для Intel-ускорения более долгоживущая ставка — сам OpenVINO, а не конкретная обвязка ORT OpenVINO EP. EP остаётся активным мостом из ORT к OpenVINO, но зависит сразу от двух release train и его готовые wheel заметно отстают от обоих ядер. Нативный OpenVINO одновременно является runtime для CPU/GPU/NPU, имеет собственную LTS policy и служит основанием OpenVINO GenAI (OpenVINO EP, GenAI как расширение runtime). Это не означает, что проекту нужно переносить ONNX-путь на OpenVINO или консолидироваться на ORT: ONNX-модели сохраняют переносимость, а выбор движка распознавания остаётся отдельным решением по качеству и контракту.
5. CPython 3.13 не блокирует ни один из трёх исследованных PyPI-пакетов на целевой Windows x86-64, но матрицы платформ радикально различаются: onnxruntime кроссплатформенный, DirectML только Windows x86-64, OpenVINO EP только Windows/Linux x86-64 (onnxruntime 1.28.0 files, DirectML 1.24.4 files, OpenVINO EP 1.24.1 files).

Что именно является чем

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

Слой	Роль	Что фиксирует приложение
ONNX	Формат графа, операторов и типов данных; операторы исполняются внешней реализацией	Артефакт модели и его opset (ONNX About)
ONNX Runtime	Движок выполнения ONNX-графа, который разбивает его между EP и CPU fallback	API сессии, версия ORT и набор EP (архитектура ORT)
OpenVINO	Intel runtime, компилятор и device plugins для CPU/GPU/NPU; умеет принимать в том числе ONNX-графы	API OpenVINO и поддерживаемые устройства/форматы (поддержанные модели)
OpenVINO EP	Адаптер внутри ORT: получает поддержанные подграфы, переводит и компилирует их для OpenVINO	Одновременно контракты ORT, EP и совместимой версии OpenVINO (EP architecture, OpenVINO EP)
OpenVINO GenAI	Высокоуровневые генеративные pipelines поверх OpenVINO runtime, включая Whisper и общий ASR API	Формат моделей OpenVINO IR, pipeline API и согласованные версии OpenVINO/Tokenizers/GenAI (GenAI PyPI)

Следствие: модель в ONNX не означает ONNX Runtime, а OpenVINO EP не является форматом модели. Один ONNX-артефакт можно исполнять CPU EP в ORT, передавать поддержанные подграфы OpenVINO EP либо загружать в OpenVINO напрямую; однако покрытие операторов, квантование, fallback и производительность у этих путей различаются (ORT EP partitioning, OpenVINO EP support coverage, прямое чтение ONNX в OpenVINO).

ONNX Runtime и execution providers

Ядро ORT

Официальные страницы расходятся в обещанном cadence: servicing-документ всё ещё говорит о full releases «примерно ежеквартально», тогда как roadmap — о ежемесячных релизах и patch-релизах между ними. Формального LTS/EOL-окна в публичной support policy нет. Поэтому для планирования надёжнее опираться на фактические публикации и backward-compatibility policy, а не превращать текущий почти месячный темп в гарантию (releases and servicing, roadmap, support policy).

ORT 1.23 начал переход к независимо подключаемым plugin EP и прямо рекомендует новые EP реализовывать как plugins, а не добавлять внутрь ядра. В 1.24–1.28 plugin API последовательно получал prepacking, EP Context, zero-copy I/O, profiling и model packages (инструкция для нового EP, релиз 1.24.1, релиз 1.28.0). Это сильный сигнал продолжения ORT как общего движка, но одновременно сигнал, что жизненный цикл конкретного аппаратного backend всё больше принадлежит его поставщику, а не ядру ORT.

DirectML EP

Официальная формулировка однозначна: DirectML находится в sustained engineering, поддержка продолжается, но feature development перешёл в WinML. Документация также фиксирует DirectML 1.15.2 и покрытие только до ONNX opset 20; модели с более высоким требованием официально не поддерживаются (DirectML EP).

Это согласуется с поставкой: последний onnxruntime-directml на дату среза — 1.24.4 от 17 марта, тогда как ядро ORT уже 1.28.0. При этом ORT 1.28 всё ещё содержит исправление DML readback, то есть sustained engineering означает не «удалён», а «исправления без прежнего темпа новых возможностей» (DirectML на PyPI, ORT 1.28, DML fix).

Для проекта DirectML остаётся возможным Windows-only экспериментом на AMD, Intel и NVIDIA GPU, но его стратегический successor — WinML, который требует Windows-специфической интеграции. Это слабее текущего требования ADR-003 о плаггируемых бэкендах и кроссплатформенном ONNX CPU-пути.

OpenVINO EP

Официальная документация не объявляет OpenVINO EP deprecated или maintenance-only. Наоборот, Intel публикует готовые пакеты, принимает issues/PR, заявляет CPU, интегрированные и дискретные GPU и NPU, а ORT 1.26 и 1.28 содержат OpenVINO EP development updates (страница пакета, ORT 1.26, ORT 1.28).

Но готовая поставка имеет свой темп. Последний wheel onnxruntime-openvino 1.24.1 от 26 февраля 2026 года включает OpenVINO 2025.4.1 на Linux и требует отдельной установки OpenVINO на Windows. Официальная таблица совместимости покрывает только три версии OpenVINO: ORT-EP 1.22/2025.1, 1.23/2025.3 и 1.24.1/2025.4.1 (PyPI, матрица совместимости). На дату среза нативный OpenVINO уже 2026.3, а ядро ORT — 1.28. Значит, EP активен, но готовый Python-путь не является способом автоматически получить самые новые возможности OpenVINO/NPU.

Начиная с ORT 1.23 часть старых provider options OpenVINO EP deprecated в пользу load_config с нативными OpenVINO properties. Это локальная миграция конфигурации, а не deprecation самого EP (deprecation notice).

OpenVINO, OpenVINO GenAI, Whisper и Intel NPU

OpenVINO имеет явно описанный цикл: несколько регулярных релизов в год, поддержка каждого до следующего и ежегодный LTS. LTS получает security updates два года либо до двух следующих LTS, а исправления новых bugs — один год; preview-компоненты этой гарантией не покрываются (release policy).

OpenVINO GenAI — не конкурирующий runtime, а библиотека pipelines поверх OpenVINO и OpenVINO Tokenizers. Их major.minor.patch должны совпадать: разъезд может привести к ABI/import errors; PyPI wheel нельзя смешивать с C++ archives другого ABI (официальные правила совместимости).

Whisper — активный, а не legacy use case OpenVINO GenAI:

• OpenVINO 2026.0 добавил word-level timestamps в WhisperPipeline на CPU, GPU и NPU; в 2026.3 результаты также содержат определённый/заданный язык, а NPU отдаёт word timestamps по умолчанию (2026.0 release notes, 2026.3 release notes);
• OpenVINO 2026.3 ввёл общий ASRPipeline и поддержку Qwen3-ASR, то есть speech API расширяется за пределы Whisper (2026.3 release notes);
• удалён только ранее deprecated stateless decoder Whisper; рекомендуемый путь — stateful model, а не отказ от Whisper (deprecation section).

NPU является первым классом устройств OpenVINO: NPU plugin доступен в дистрибутивах, целевая аппаратная платформа начинается с Intel Core Ultra, Compiler-In-Plugin появился preview в 2026.0 и стал предпочитаемым компилятором в 2026.1. При этом NPU требует отдельный driver, поддерживает только static shapes, а совместимость предкомпилированных blobs между версиями OpenVINO не гарантируется (NPU device). WhisperPipeline официально работает на NPU с tiny/base/small/large без специальных ограничений pipeline, но документация рекомендует актуальный NPU driver и даёт workaround для memory failures (Whisper on NPU).

Это не делает NPU актуальным для целевого Intel Core i5 11-го поколения: NPU появился только в Core Ultra. Для текущей целевой машины долгоживущий OpenVINO-путь означает прежде всего CPU/iGPU; NPU — будущий аппаратный профиль, который нужно выбирать явно, тем более что OpenVINO AUTO пока исключает NPU из дефолтного приоритета (NPU hardware, AUTO priority).

PyPI: версии, платформы и CPython 3.13

Срез сделан по фактически опубликованным wheel, а не по classifiers страницы. У всех трёх пакетов отсутствует source distribution, поэтому неподдержанная комбинация платформы и Python не сможет штатно собраться через обычный pip install без самостоятельной сборки из репозитория.

Пакет	Последняя версия на 2026-08-12	Последняя публикация	wheel для CPython 3.13	Платформы cp313
onnxruntime	1.28.0	2026-07-25	Да	Windows x86-64 и ARM64; Linux x86-64 и ARM64 (glibc 2.27/2.28+); macOS 14+ ARM64 (files)
onnxruntime-directml	1.24.4	2026-03-17	Да	Только Windows x86-64; нет Linux, macOS и Windows ARM64 wheel (files)
onnxruntime-openvino	1.24.1	2026-02-26	Да	Windows x86-64 и Linux x86-64 с glibc 2.28+; нет ARM64 и macOS wheel (files)

Практический вывод для ADR-003 сохраняется: обычный onnxruntime остаётся широким zero-config CPU-путём. DirectML и OpenVINO EP нельзя подставить как одну безусловную зависимость на всех платформах; они требуют platform markers и отдельных проверок доступного provider. На Windows OpenVINO EP дополнительно требует совместимый openvino, а на Linux wheel уже включает конкретный OpenVINO 2025.4.1 (OpenVINO EP installation).

Что это меняет для карты диаризации

1. Разведка sherpa-onnx на обычном CPU ORT не опирается на затухающий компонент: ядро ORT активно и имеет самый широкий CPython/platform coverage. Это поддерживает текущий вариант диаризации как optional post-processing, но ничего не говорит о качестве DirectML/OpenVINO EP на конкретных двух моделях.
2. Формулировка разведочного замера «у OpenVINO GenAI потокенных таймкодов нет» требует уточнения. Upstream с 2026.0 предоставляет word-level timestamps; сейчас их не экспортирует проектный OpenVINO backend. Следовательно, невозможность пословной привязки на --device openvino-* — интеграционный пробел local-transcriber, а не долгосрочное ограничение движка (OpenVINO 2026.0).
3. Не следует связывать UX диаризации с немедленным выбором EP. Сначала можно определить пользовательский контракт — флаг, num_speakers, зависимость, формат и честное поведение при отсутствии word timestamps. Ускорение диаризации через OpenVINO EP или DirectML должно пройти отдельную совместимость и benchmark на обеих моделях sherpa-onnx.
4. Не следует принимать решение о полной консолидации проекта на ORT. Нативный OpenVINO GenAI развивается как ASR-платформа, в том числе по таймкодам и NPU, а FasterWhisper сохраняет отдельные достоинства CUDA и языкового покрытия, уже зафиксированные ADR-003/006.

Рекомендация по жизненному циклу

Ниже — интерпретация источников для local-transcriber, а не опубликованный roadmap Microsoft или Intel. Она исходит из фактов о lifecycle, wheel-матрицах и текущем контракте проекта; реальную пригодность каждого ускорителя должен подтвердить проектный benchmark.

• Сохранять ONNX-модели диаризации + обычный CPU ORT как базовый переносимый путь: это наименее связанный с одним вендором слой и единственная из трёх поставок с wheel на Windows/Linux ARM64 и macOS ARM64.
• Рассматривать OpenVINO EP как опциональное ускорение этих же ONNX-моделей на Intel, но не обещать его до проверки operator coverage, фактического provider assignment, качества и скорости. Его wheel активен, однако отстаёт от текущих ORT/OpenVINO и требует собственной матрицы версий.
• Рассматривать нативный OpenVINO/OpenVINO GenAI как основной долгосрочный Intel ASR-путь, особенно для Whisper и будущего NPU. Для пословной диаризации сначала проверить и протянуть уже существующие upstream word timestamps через проектный Backend contract.
• Не закладывать новый DirectML backend проекта: текущий EP поддерживается, но feature development официально ушёл в WinML. Если кросс-вендорное Windows GPU ускорение станет отдельной целью, исследовать WinML как новый Windows-специфический backend, а не считать onnxruntime-directml долгоживущим default.

Новые вопросы карты

• Какой точный контракт word timestamps возвращают WhisperPipeline и новый ASRPipeline 2026.3, и как без потери совместимости добавить их в проектный Backend/TranscribeResult?
• Дают ли sherpa-onnx segmentation и embedding models полный offload в OpenVINO EP, или часть графа уходит в CPU EP; меняются ли границы и эмбеддинги численно?
• Есть ли выигрыш OpenVINO EP на целевом Intel Core i5 11-го поколения после учёта второго runtime, загрузки модели и памяти, или CPU ORT уже оптимальнее?
• Нужен ли UX явного отказа/огрубления диаризации на backend без word timestamps, либо backend contract должен сначала стать timestamp-aware?
• Следует ли разделить extra диаризации на переносимый CPU-вариант и Intel-ускорение с platform marker, чтобы не ухудшить zero-config установку на ARM/macOS?