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?