# Куда движутся 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`](../../CONTEXT.md): ONNX Runtime, OpenVINO и
OpenVINO GenAI здесь — **движки распознавания**, их обновление само по себе не
меняет поддерживаемую модель или модель по умолчанию. Архитектурная точка
отсчёта — отдельные pluggable backends из [ADR-003](../adr/003-pluggable-backends.md)
и принятый ONNX CPU-путь из [ADR-006](../adr/006-onnx-asr-backend.md).

Исследование дополняет [срез обновлений движков](2026-08-10-engine-model-updates.md)
и отвечает на инфраструктурный вопрос, открытый
[разведкой диаризации](../benchmarks/2026-08-12-diarization-feasibility.md) и
[бэклогом](../backlog.md#диаризация--разделение-говорящих). Оно не пересматривает
качество моделей и не принимает решение о полной консолидации на 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](https://github.com/microsoft/onnxruntime/releases/tag/v1.26.0),
   [1.27.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.27.0),
   [1.28.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).
2. **DirectML EP поддерживается, но переведён в sustained engineering.** Новая
   функциональность Windows-пути перенесена в WinML; Microsoft рекомендует
   WinML для новых Windows-развёртываний, а DirectML EP оставляет для legacy и
   специальных сценариев ([официальная страница DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html),
   [Windows-путь ORT](https://onnxruntime.ai/docs/get-started/with-windows.html)).
   Поэтому `onnxruntime-directml` нельзя считать перспективным
   кросс-вендорным GPU-дефолтом проекта, хотя пакет не заброшен.
3. **OpenVINO и OpenVINO GenAI — основной активно развиваемый Intel-стек.** В
   2026 году регулярные релизы вышли 23 февраля, 7 апреля, 28 мая и 4 августа;
   OpenVINO публикует формальную release/LTS policy, где регулярная версия
   поддерживается до следующей, а последняя версия года становится LTS с двумя
   годами security updates ([release notes](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html),
   [release policy](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/release-policy.html)).
4. **Для Intel-ускорения более долгоживущая ставка — сам OpenVINO, а не
   конкретная обвязка ORT OpenVINO EP.** EP остаётся активным мостом из ORT к
   OpenVINO, но зависит сразу от двух release train и его готовые wheel заметно
   отстают от обоих ядер. Нативный OpenVINO одновременно является runtime для
   CPU/GPU/NPU, имеет собственную LTS policy и служит основанием OpenVINO GenAI
   ([OpenVINO EP](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html),
   [GenAI как расширение runtime](https://docs.openvino.ai/2026/openvino-workflow-generative/inference-with-genai.html)).
   Это не означает, что проекту нужно переносить 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](https://pypi.org/project/onnxruntime/1.28.0/#files),
   [DirectML 1.24.4 files](https://pypi.org/project/onnxruntime-directml/1.24.4/#files),
   [OpenVINO EP 1.24.1 files](https://pypi.org/project/onnxruntime-openvino/1.24.1/#files)).

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

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

| Слой | Роль | Что фиксирует приложение |
|---|---|---|
| ONNX | Формат графа, операторов и типов данных; операторы исполняются внешней реализацией | Артефакт модели и его opset ([ONNX About](https://onnx.ai/about)) |
| ONNX Runtime | Движок выполнения ONNX-графа, который разбивает его между EP и CPU fallback | API сессии, версия ORT и набор EP ([архитектура ORT](https://onnxruntime.ai/docs/reference/high-level-design.html)) |
| OpenVINO | Intel runtime, компилятор и device plugins для CPU/GPU/NPU; умеет принимать в том числе ONNX-графы | API OpenVINO и поддерживаемые устройства/форматы ([поддержанные модели](https://docs.openvino.ai/2026/documentation/compatibility-and-support/supported-models.html)) |
| OpenVINO EP | Адаптер внутри ORT: получает поддержанные подграфы, переводит и компилирует их для OpenVINO | Одновременно контракты ORT, EP и совместимой версии OpenVINO ([EP architecture](https://onnxruntime.ai/docs/execution-providers/), [OpenVINO EP](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html)) |
| OpenVINO GenAI | Высокоуровневые генеративные pipelines поверх OpenVINO runtime, включая Whisper и общий ASR API | Формат моделей OpenVINO IR, pipeline API и согласованные версии OpenVINO/Tokenizers/GenAI ([GenAI PyPI](https://pypi.org/project/openvino-genai/2026.3.0.0/)) |

Следствие: **модель в ONNX не означает ONNX Runtime**, а **OpenVINO EP не
является форматом модели**. Один ONNX-артефакт можно исполнять CPU EP в ORT,
передавать поддержанные подграфы OpenVINO EP либо загружать в OpenVINO
напрямую; однако покрытие операторов, квантование, fallback и производительность
у этих путей различаются ([ORT EP partitioning](https://onnxruntime.ai/docs/execution-providers/),
[OpenVINO EP support coverage](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html),
[прямое чтение ONNX в OpenVINO](https://docs.openvino.ai/2026/openvino-workflow/model-preparation/convert-model-onnx.html)).

## ONNX Runtime и execution providers

### Ядро ORT

Официальные страницы расходятся в обещанном cadence: servicing-документ всё
ещё говорит о full releases «примерно ежеквартально», тогда как roadmap — о
ежемесячных релизах и patch-релизах между ними. Формального LTS/EOL-окна в
публичной support policy нет. Поэтому для планирования надёжнее опираться на
фактические публикации и backward-compatibility policy, а не превращать
текущий почти месячный темп в гарантию
([releases and servicing](https://onnxruntime.ai/docs/reference/releases-servicing.html),
[roadmap](https://onnxruntime.ai/roadmap),
[support policy](https://github.com/microsoft/onnxruntime/blob/main/SUPPORT.md)).

ORT 1.23 начал переход к независимо подключаемым plugin EP и прямо рекомендует
новые EP реализовывать как plugins, а не добавлять внутрь ядра. В 1.24–1.28
plugin API последовательно получал prepacking, EP Context, zero-copy I/O,
profiling и model packages ([инструкция для нового EP](https://onnxruntime.ai/docs/execution-providers/add-execution-provider.html),
[релиз 1.24.1](https://github.com/microsoft/onnxruntime/releases/tag/v1.24.1),
[релиз 1.28.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).
Это сильный сигнал продолжения ORT как общего движка, но одновременно сигнал,
что жизненный цикл конкретного аппаратного backend всё больше принадлежит его
поставщику, а не ядру ORT.

### DirectML EP

Официальная формулировка однозначна: DirectML находится в **sustained
engineering**, поддержка продолжается, но feature development перешёл в WinML.
Документация также фиксирует DirectML 1.15.2 и покрытие только до ONNX opset 20;
модели с более высоким требованием официально не поддерживаются
([DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html)).

Это согласуется с поставкой: последний `onnxruntime-directml` на дату среза —
1.24.4 от 17 марта, тогда как ядро ORT уже 1.28.0. При этом ORT 1.28 всё ещё
содержит исправление DML readback, то есть sustained engineering означает не
«удалён», а «исправления без прежнего темпа новых возможностей»
([DirectML на PyPI](https://pypi.org/project/onnxruntime-directml/),
[ORT 1.28, DML fix](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).

Для проекта 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 ([страница пакета](https://pypi.org/project/onnxruntime-openvino/),
[ORT 1.26](https://github.com/microsoft/onnxruntime/releases/tag/v1.26.0),
[ORT 1.28](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).

Но готовая поставка имеет свой темп. Последний 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](https://pypi.org/project/onnxruntime-openvino/1.24.1/),
[матрица совместимости](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html)).
На дату среза нативный 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](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html)).

## OpenVINO, OpenVINO GenAI, Whisper и Intel NPU

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

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

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](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-0-0),
  [2026.3 release notes](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-3-0));
- OpenVINO 2026.3 ввёл общий `ASRPipeline` и поддержку Qwen3-ASR, то есть
  speech API расширяется за пределы Whisper
  ([2026.3 release notes](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-3-0));
- удалён только ранее deprecated **stateless decoder** Whisper; рекомендуемый
  путь — stateful model, а не отказ от Whisper
  ([deprecation section](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#deprecation-and-support)).

NPU является первым классом устройств OpenVINO: NPU plugin доступен в
дистрибутивах, целевая аппаратная платформа начинается с Intel Core Ultra,
Compiler-In-Plugin появился preview в 2026.0 и стал предпочитаемым компилятором
в 2026.1. При этом NPU требует отдельный driver, поддерживает только static
shapes, а совместимость предкомпилированных blobs между версиями OpenVINO не
гарантируется ([NPU device](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html)).
WhisperPipeline официально работает на NPU с tiny/base/small/large без
специальных ограничений pipeline, но документация рекомендует актуальный NPU
driver и даёт workaround для memory failures
([Whisper on NPU](https://docs.openvino.ai/2026/openvino-workflow-generative/inference-with-genai/inference-with-genai-on-npu.html#whisper-inference-on-npu)).

Это не делает NPU актуальным для целевого Intel Core i5 11-го поколения: NPU
появился только в Core Ultra. Для текущей целевой машины долгоживущий
OpenVINO-путь означает прежде всего CPU/iGPU; NPU — будущий аппаратный профиль,
который нужно выбирать явно, тем более что OpenVINO AUTO пока исключает NPU из
дефолтного приоритета
([NPU hardware](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html),
[AUTO priority](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/auto-device-selection.html)).

## 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](https://pypi.org/project/onnxruntime/1.28.0/#files)) |
| `onnxruntime-directml` | 1.24.4 | 2026-03-17 | Да | Только Windows x86-64; нет Linux, macOS и Windows ARM64 wheel ([files](https://pypi.org/project/onnxruntime-directml/1.24.4/#files)) |
| `onnxruntime-openvino` | 1.24.1 | 2026-02-26 | Да | Windows x86-64 и Linux x86-64 с glibc 2.28+; нет ARM64 и macOS wheel ([files](https://pypi.org/project/onnxruntime-openvino/1.24.1/#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](https://pypi.org/project/onnxruntime-openvino/1.24.1/)).

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

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](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-0-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?