docs(research): исследован жизненный цикл ORT и OpenVINO

- Зачем: - нужна фактическая опора для решений карты о диаризации на Intel-пути. - Что: - исследованы жизненные циклы ONNX Runtime, DirectML и OpenVINO. - зафиксированы платформы CPython 3.13 и поддержка таймкодов Whisper. - Проверка: - git diff --cached --check.
2026-08-12 15:55:06 +03:00
1 changed files with 289 additions and 0 deletions
@@ -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?