diff --git a/docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md b/docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md new file mode 100644 index 0000000..e9e086b --- /dev/null +++ b/docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md @@ -0,0 +1,289 @@ +# Куда движутся 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?