ddmitry/local-transcriber
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(research): переработана структура исследования

Browse Source 
- Зачем:
  - выводы о жизненном цикле и возможностях моделей должны читаться как единое исследование.
- Что:
  - материал перестроен вокруг слоёв, платформ и уровней доказательства.
  - объединены выводы по Intel, AMD, Apple и браузерным путям.
  - подтверждённые возможности отделены от выводов и необходимых экспериментов.
- Проверка:
  - относительные ссылки и структура Markdown проверены.
  - git diff --cached --check выполнен успешно.
This commit is contained in:
Dmitriy Dementiev
2026-08-12 16:25:54 +03:00
parent 4c7f2920c1
commit 388de09c42
1 changed files with 415 additions and 334 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md
+415 -334
View File
@@ -1,410 +1,491 @@
# Куда движутся ONNX Runtime и OpenVINO: сравнение жизненного цикла # Куда движутся ONNX Runtime и OpenVINO: жизненный цикл и переносимость моделей
**Дата:** 2026-08-12 **Дата:** 2026-08-12
**Статус:** исследование для карты диаризации. Не архитектурное решение и не **Статус:** исследование для карты диаризации. Не архитектурное решение и не
основание для консолидации всех движков распознавания на ONNX Runtime. основание для консолидации всех движков распознавания на ONNX Runtime.
## Вопрос ## Вопрос и границы
Насколько устойчивы ONNX Runtime, его DirectML и OpenVINO Execution Provider, Исследование отвечает на два связанных вопроса:
а также нативный стек OpenVINO/OpenVINO GenAI; какой из путей с большей
вероятностью сохранит Intel-ускорение и поддержку Whisper/NPU; что из этого
практически доступно проекту на CPython 3.13.
Исследование опирается только на первичные источники: официальную документацию, 1. Насколько устойчивы ONNX Runtime (ORT), его аппаратные Execution Provider
release notes, репозитории владельцев и метаданные PyPI. (EP), Windows ML и нативный стек OpenVINO/OpenVINO GenAI?
2. Что эти пути практически дают текущим моделям проекта — GigaAM E2E RNN-T,
OpenVINO Whisper и связке диаризации PyAnnote + WeSpeaker — на Intel, AMD,
Apple Silicon и в браузере?
## Границы в контексте проекта Терминология следует [`CONTEXT.md`](../../CONTEXT.md): ORT, OpenVINO и OpenVINO
GenAI — **движки распознавания**. Обновление движка само по себе не меняет
Терминология следует [`CONTEXT.md`](../../CONTEXT.md): ONNX Runtime, OpenVINO и поддерживаемую модель или модель по умолчанию. Архитектурная точка отсчёта —
OpenVINO GenAI здесь — **движки распознавания**, их обновление само по себе не независимые бэкенды из [ADR-003](../adr/003-pluggable-backends.md) и принятый
меняет поддерживаемую модель или модель по умолчанию. Архитектурная точка ONNX CPU-путь из [ADR-006](../adr/006-onnx-asr-backend.md).
отсчёта — отдельные 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) Исследование дополняет [срез обновлений движков](2026-08-10-engine-model-updates.md)
и отвечает на инфраструктурный вопрос, открытый и [разведку диаризации](../benchmarks/2026-08-12-diarization-feasibility.md).
[разведкой диаризации](../benchmarks/2026-08-12-diarization-feasibility.md) и Оно основано на первичных источниках: официальной документации, release notes,
[бэклогом](../backlog.md#диаризация--разделение-говорящих). Оно не пересматривает репозиториях владельцев и фактических метаданных PyPI на 2026-08-12.
качество моделей и не принимает решение о полной консолидации на ORT.
## Краткий вывод Вне границ документа:
Расширенный portability-срез не меняет исходный lifecycle-вывод, но уточняет его: ORT CPU остаётся наиболее ровным baseline на AMD Windows/Linux и Apple Silicon; Windows ML — уже production-поставка ORT для Windows с cp313, хотя vendor EP требуют bootstrap/registration; DirectML остаётся legacy; Linux AMD движется к MIGraphX; Apple accelerator-путь — CoreML Preview с обязательной проверкой partitioning. Наличие wheel/provider не подтверждает совместимость GigaAM или двух diarization graphs и тем более полный offload. - решение о консолидации проекта на одном runtime;
- выбор нового устройства или модели по умолчанию;
- обещание производительности без model-specific benchmark;
- разработка браузерной версии `local-transcriber`.
Браузер показывает тот же устойчивый pattern: ONNX — artifact, ORT Web — отдельный runtime, WASM — portable baseline, WebGPU/WebNN — optional accelerators с operator subset и fallback. Это portability evidence, а не предложение browser product или консолидации всего проекта на ORT. ## Краткий ответ
1. **ONNX Runtime — активно развиваемый, production-стабильный движок, но не - **Переносимый фундамент проекта — ONNX-артефакт плюс ORT CPU EP.** ORT core
все его EP имеют одинаковый жизненный цикл.** Версии 1.26, 1.27 и 1.28 активно развивается и имеет наиболее широкую поставку для CPython 3.13:
вышли 8 мая, 19 июня и 25 июля 2026 года, то есть три minor-релиза примерно Windows и Linux x86-64/ARM64, macOS ARM64.
за одиннадцать недель; 1.28 продолжает развивать plugin EP API, ядро, - **Жизненный цикл ядра ORT не переносится автоматически на каждый EP.**
безопасность и аппаратные EP ([1.26.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.26.0), DirectML уже в sustained engineering, OpenVINO EP активен, но отстаёт от
[1.27.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.27.0), ORT и OpenVINO, CoreML остаётся Preview, а удалённый ROCm EP сменяется
[1.28.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)). MIGraphX.
2. **DirectML EP поддерживается, но переведён в sustained engineering.** Новая - **Долгосрочный Intel-путь — нативный OpenVINO/OpenVINO GenAI.** Он имеет
функциональность Windows-пути перенесена в WinML; Microsoft рекомендует собственную release/LTS policy, развивает Whisper и NPU и уже предоставляет
WinML для новых Windows-развёртываний, а DirectML EP оставляет для legacy и word-level timestamps. OpenVINO EP полезен как мост для ONNX-моделей, но не
специальных сценариев ([официальная страница DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html), даёт автоматически последние возможности нативного стека.
[Windows-путь ORT](https://onnxruntime.ai/docs/get-started/with-windows.html)). - **Новый Windows-слой — Windows ML, а не DirectML.** Windows ML остаётся ORT,
Поэтому `onnxruntime-directml` нельзя считать перспективным но добавляет обнаружение устройств и управляемый каталог vendor EP. Для AMD
кросс-вендорным GPU-дефолтом проекта, хотя пакет не заброшен. там доступен MIGraphX; Python-приложению всё равно нужны bootstrap, загрузка
3. **OpenVINO и OpenVINO GenAI — основной активно развиваемый Intel-стек.** В и явная регистрация EP.
2026 году регулярные релизы вышли 23 февраля, 7 апреля, 28 мая и 4 августа; - **На AMD и Apple готовый пакет ещё не означает ускорение конкретной модели.**
OpenVINO публикует формальную release/LTS policy, где регулярная версия Linux AMD имеет wheel MIGraphX для CPython 3.13, Apple Silicon — CoreML EP в
поддерживается до следующей, а последняя версия года становится LTS с двумя обычном ORT wheel; полный offload GigaAM и моделей диаризации не подтверждён
годами 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)). - **Браузеры используют ту же архитектурную идею:** ORT Web даёт единый API,
4. **Для Intel-ускорения более долгоживущая ставка — сам OpenVINO, а не WASM — переносимый CPU baseline, WebGPU/WebNN — опциональные ускорители с
конкретная обвязка ORT OpenVINO EP.** EP остаётся активным мостом из ORT к ограниченным набором операторов и fallback. Сам ONNX-файл не устраняет
OpenVINO, но зависит сразу от двух release train и его готовые wheel заметно различия preprocessing, decoding и доступных kernels.
отстают от обоих ядер. Нативный OpenVINO одновременно является runtime для - **Главная находка для карты диаризации:** OpenVINO GenAI уже умеет возвращать
CPU/GPU/NPU, имеет собственную LTS policy и служит основанием OpenVINO GenAI пословные таймкоды. Их отсутствие в результате `local-transcriber` — пробел
([OpenVINO EP](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html), проектного `Backend`/`TranscribeResult`, а не ограничение OpenVINO.
[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)).
## Что именно является чем Общий принцип: поддержка пути доказана только тогда, когда подтверждены
поставка, создание сессии, фактическое размещение графа, сохранение выходного
контракта и end-to-end стоимость. Наличие wheel или имени EP закрывает только
первый из этих пунктов.
Слои нельзя сравнивать как взаимозаменяемые пакеты: ## Как устроены исследуемые слои
Сравниваемые названия относятся к разным уровням и не являются
взаимозаменяемыми пакетами.
| Слой | Роль | Что фиксирует приложение | | Слой | Роль | Что фиксирует приложение |
|---|---|---| |---|---|---|
| ONNX | Формат графа, операторов и типов данных; операторы исполняются внешней реализацией | Артефакт модели и его opset ([ONNX About](https://onnx.ai/about)) | | 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)) | | ONNX Runtime | Движок, который загружает ONNX-граф и распределяет узлы между EP | 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)) | | Execution Provider | Адаптер ORT к CPU, GPU или NPU; получает только поддержанные узлы/подграфы | Аппаратный runtime, provider options и CPU fallback ([архитектура EP](https://onnxruntime.ai/docs/execution-providers/)) |
| 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)) | | Windows ML | Windows-поставка ORT с каталогом, установкой и обновлением vendor EP | Windows App SDK, deployment mode и политика выбора EP ([обзор](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/overview)) |
| 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/)) | | OpenVINO | Runtime, компилятор и device plugins для CPU/GPU/NPU; читает в том числе ONNX | API OpenVINO, устройство и поддержанные форматы ([поддержанные модели](https://docs.openvino.ai/2026/documentation/compatibility-and-support/supported-models.html)) |
| OpenVINO GenAI | Высокоуровневые pipelines поверх OpenVINO, включая Whisper и общий ASR API | OpenVINO IR, pipeline API и согласованные версии компонентов ([GenAI PyPI](https://pypi.org/project/openvino-genai/2026.3.0.0/)) |
| ORT Web | Отдельная JavaScript/WebAssembly-поставка ORT для браузера | JS API, WASM runtime и browser EP ([обзор ORT Web](https://onnxruntime.ai/docs/tutorials/web/)) |
Следствие: **модель в ONNX не означает ONNX Runtime**, а **OpenVINO EP не Один ONNX-артефакт можно исполнять обычным ORT CPU EP, передавать его
является форматом модели**. Один ONNX-артефакт можно исполнять CPU EP в ORT, поддержанные подграфы OpenVINO EP или загружать напрямую в OpenVINO. Результат
передавать поддержанные подграфы OpenVINO EP либо загружать в OpenVINO различается по покрытию операторов, квантованию, fallback и производительности
напрямую; однако покрытие операторов, квантование, fallback и производительность ([ORT partitioning](https://onnxruntime.ai/docs/execution-providers/),
у этих путей различаются ([ORT EP partitioning](https://onnxruntime.ai/docs/execution-providers/), [OpenVINO EP coverage](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html),
[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 в OpenVINO](https://docs.openvino.ai/2026/openvino-workflow/model-preparation/convert-model-onnx.html)).
## ONNX Runtime и execution providers ### Лестница доказательства
### Ядро ORT Для каждой пары «модель × устройство × движок» используются пять уровней:
Официальные страницы расходятся в обещанном cadence: servicing-документ всё 1. **Поставка:** существует совместимый wheel/runtime.
ещё говорит о full releases «примерно ежеквартально», тогда как roadmap — о 2. **Загрузка:** все модельные сессии создаются без ошибки.
ежемесячных релизах и patch-релизах между ними. Формального LTS/EOL-окна в 3. **Размещение:** profiler показывает, какие узлы действительно исполняет EP,
публичной support policy нет. Поэтому для планирования надёжнее опираться на а какие ушли в CPU fallback.
фактические публикации и backward-compatibility policy, а не превращать 4. **Контракт:** текст, таймкоды, сегменты и эмбеддинги остаются допустимыми.
текущий почти месячный темп в гарантию 5. **Пригодность:** end-to-end скорость, память и качество проходят проектную
([releases and servicing](https://onnxruntime.ai/docs/reference/releases-servicing.html), приёмку.
Ниже «подтверждено» означает прямое upstream-обещание или локальный результат;
«вывод» следует из архитектуры, но не проверен на конкретной модели;
«эксперимент» означает, что неизвестен хотя бы один уровень после поставки.
## Жизненный цикл движков и аппаратных путей
### ONNX Runtime core
ORT core активно развивается. Версии 1.26, 1.27 и 1.28 вышли 8 мая, 19 июня и
25 июля 2026 года; в них продолжалось развитие plugin EP API, ядра,
безопасности и аппаратных провайдеров
([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)).
Официальные страницы расходятся в обещанном cadence: servicing-документ говорит
о full releases примерно раз в квартал, roadmap — о ежемесячных релизах и
промежуточных patch-релизах. Публичной LTS/EOL policy нет, поэтому текущий
почти месячный темп нельзя считать гарантией
([servicing](https://onnxruntime.ai/docs/reference/releases-servicing.html),
[roadmap](https://onnxruntime.ai/roadmap), [roadmap](https://onnxruntime.ai/roadmap),
[support policy](https://github.com/microsoft/onnxruntime/blob/main/SUPPORT.md)). [support policy](https://github.com/microsoft/onnxruntime/blob/main/SUPPORT.md)).
ORT 1.23 начал переход к независимо подключаемым plugin EP и прямо рекомендует С ORT 1.23 новые EP рекомендуется делать отдельными plugins. В 1.24–1.28 API
новые EP реализовывать как plugins, а не добавлять внутрь ядра. В 1.24–1.28 получил prepacking, EP Context, zero-copy I/O, profiling и model packages
plugin API последовательно получал prepacking, EP Context, zero-copy I/O, ([инструкция для нового EP](https://onnxruntime.ai/docs/execution-providers/add-execution-provider.html),
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.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)). Это
[релиз 1.28.0](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)). укрепляет ORT как общий движок, но одновременно отделяет lifecycle конкретного
Это сильный сигнал продолжения ORT как общего движка, но одновременно сигнал, ускорителя от lifecycle ядра.
что жизненный цикл конкретного аппаратного backend всё больше принадлежит его
поставщику, а не ядру ORT.
### DirectML EP ### Нативный OpenVINO и OpenVINO GenAI
Официальная формулировка однозначна: DirectML находится в **sustained OpenVINO публикует несколько регулярных релизов в год. Каждый поддерживается до
engineering**, поддержка продолжается, но feature development перешёл в WinML. следующего, а последняя версия года становится LTS: security updates выходят
Документация также фиксирует DirectML 1.15.2 и покрытие только до ONNX opset 20; два года либо до двух следующих LTS, исправления новых bugs — один год.
модели с более высоким требованием официально не поддерживаются Preview-компоненты этой гарантией не покрываются
([DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html)). ([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)).
Это согласуется с поставкой: последний `onnxruntime-directml` на дату среза — OpenVINO GenAI — pipeline-библиотека поверх OpenVINO и OpenVINO Tokenizers.
1.24.4 от 17 марта, тогда как ядро ORT уже 1.28.0. При этом ORT 1.28 всё ещё Их `major.minor.patch` должны совпадать; разъезд версий может привести к
содержит исправление DML readback, то есть sustained engineering означает не ABI/import errors. PyPI wheel нельзя смешивать с C++ archive другого ABI
«удалён», а «исправления без прежнего темпа новых возможностей» ([правила совместимости](https://pypi.org/project/openvino-genai/2026.3.0.0/)).
([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, Whisper остаётся активным направлением:
Intel и NVIDIA GPU, но его стратегический successor — WinML, который требует
Windows-специфической интеграции. Это слабее текущего требования ADR-003 о
плаггируемых бэкендах и кроссплатформенном ONNX CPU-пути.
### OpenVINO EP - OpenVINO 2026.0 добавил word-level timestamps в `WhisperPipeline` на CPU,
GPU и NPU; 2026.3 добавил язык в результат
([2026.0](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-0-0),
[2026.3](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](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-3-0));
- удалён только ранее deprecated stateless Whisper decoder; рекомендуемый путь
использует stateful model
([deprecations](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#deprecation-and-support)).
Официальная документация не объявляет OpenVINO EP deprecated или maintenance-only. NPU — полноценное устройство OpenVINO, но требует отдельного driver, работает
Наоборот, Intel публикует готовые пакеты, принимает issues/PR, заявляет CPU, со static shapes, а совместимость compiled blobs между версиями не
интегрированные и дискретные GPU и NPU, а ORT 1.26 и 1.28 содержат OpenVINO EP гарантируется. `WhisperPipeline` поддерживает NPU, однако целевой Core i5 11-го
development updates ([страница пакета](https://pypi.org/project/onnxruntime-openvino/), поколения NPU не имеет: для него OpenVINO означает CPU/iGPU
([NPU device](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html),
[Whisper on NPU](https://docs.openvino.ai/2026/openvino-workflow-generative/inference-with-genai/inference-with-genai-on-npu.html#whisper-inference-on-npu),
[AUTO priority](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/auto-device-selection.html)).
### Аппаратные пути ORT
| Путь | Состояние на 2026-08-12 | Практическое следствие |
|---|---|---|
| CPU EP | Часть ORT core, production baseline | Самая широкая поставка; аппаратного ускорителя не обещает |
| DirectML EP | Sustained engineering; feature development перешёл в Windows ML | Поддерживается, но не подходит как новый долгосрочный GPU default ([DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html)) |
| Windows ML | Production-поставка ORT для Windows с управляемым каталогом EP | Стратегический Windows-слой, но требует platform-specific bootstrap ([deployment](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/distributing-your-app)) |
| OpenVINO EP | Активен; deprecated только часть старых provider options | Мост к Intel-ускорению, но готовый wheel отстаёт от ORT/OpenVINO ([OpenVINO EP](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html)) |
| MIGraphX EP | Активный AMD-путь; прежний ROCm EP удалён из ORT 1.23 | Долгосрочнее ROCm EP, но зависит от ROCm/GPU/OS ([ORT 1.23](https://github.com/microsoft/onnxruntime/releases/tag/v1.23.0)) |
| CoreML EP | Preview | Доступен в macOS ORT wheel, но требует проверки partitioning ([CoreML EP](https://onnxruntime.ai/docs/execution-providers/CoreML-ExecutionProvider.html)) |
| Native WebGPU EP | Новый plugin поверх Dawn/D3D12/Vulkan/Metal | Кросс-вендорный кандидат; browser WebGPU использует другой runtime path ([WebGPU EP](https://onnxruntime.ai/docs/execution-providers/WebGPU-ExecutionProvider.html)) |
#### DirectML и Windows ML
DirectML EP использует DirectML 1.15.2, поддерживает ONNX только до opset 20 и
не допускает parallel execution одной session. Последний
`onnxruntime-directml` на дату среза — 1.24.4, тогда как ORT core уже 1.28.0.
Исправления DML всё ещё входят в ORT, то есть sustained engineering означает
поддержку без прежнего feature cadence, а не удаление
([DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html),
[PyPI](https://pypi.org/project/onnxruntime-directml/),
[ORT 1.28](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).
Windows ML не меняет формат модели и не заменяет ORT: runtime содержит
`onnxruntime.dll`, DirectML и Windows ML API. Новый слой добавляет обнаружение
устройств, каталог vendor EP, их установку, регистрацию и обновление. DirectML
остаётся встроенным legacy EP; MIGraphX, VitisAI, OpenVINO, QNN и
NvTensorRtRtx поставляются через каталог или вместе с приложением
([обзор](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/overview),
[состав runtime](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/distributing-your-app),
[каталог EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/supported-execution-providers)).
Python-пакет называется `onnxruntime-windowsml`. Версия
`1.27.1.202607110137` имеет статус `Production/Stable`, требует Python 3.11+ и
публикует `cp313` wheels для Windows x86-64 и ARM64
([PyPI](https://pypi.org/project/onnxruntime-windowsml/)). Отдельная ONNX
Runtime GenAI Windows ML library 0.x остаётся Preview; её статус не относится
к обычному ONNX-инференсу
([GenAI Preview](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/run-genai-onnx-models)).
Для Python поддержан только framework-dependent unpackaged deployment: нужны
Windows App SDK Runtime и bootstrap packages. Динамический каталог аппаратных
EP требует Windows 11 24H2 build 26100+
([get started](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/get-started),
[deployment](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/distributing-your-app)).
Приложение должно скачать выбранный EP через `ensure_ready_async()` и
зарегистрировать библиотеку в ORT; `EnsureAndRegisterCertifiedAsync()` не
регистрирует EP в Python environment
([инициализация EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/initialize-execution-providers)).
#### OpenVINO EP
OpenVINO EP не объявлен deprecated или maintenance-only. Intel продолжает
публиковать пакет, а ORT 1.26 и 1.28 содержат его изменения. Но последний
готовый `onnxruntime-openvino` 1.24.1 включает OpenVINO 2025.4.1 на Linux и
требует отдельный OpenVINO на Windows. Нативный OpenVINO уже достиг 2026.3, ORT
core — 1.28
([PyPI](https://pypi.org/project/onnxruntime-openvino/1.24.1/),
[матрица совместимости](https://onnxruntime.ai/docs/execution-providers/OpenVINO-ExecutionProvider.html),
[ORT 1.26](https://github.com/microsoft/onnxruntime/releases/tag/v1.26.0), [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)). [ORT 1.28](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)).
Но готовая поставка имеет свой темп. Последний wheel `onnxruntime-openvino` Следствие: EP остаётся рабочим мостом для ONNX-моделей, но не является способом
1.24.1 от 26 февраля 2026 года включает OpenVINO 2025.4.1 на Linux и требует автоматически получить последние Whisper/NPU-возможности OpenVINO. Deprecated
отдельной установки OpenVINO на Windows. Официальная таблица совместимости provider options, заменённые `load_config`, не означают deprecation самого EP.
покрывает только три версии 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 Срез сделан по фактическим wheel, а не только по classifiers.
OpenVINO имеет явно описанный цикл: несколько регулярных релизов в год, | Платформа и устройство | Готовый runtime/EP | Статус | `cp313` | Текущий CLI без новой интеграции |
поддержка каждого до следующего и ежегодный LTS. LTS получает security updates |---|---|---|---|---|
два года либо до двух следующих LTS, а исправления новых bugs — один год; | Intel x86 CPU | ORT CPU; OpenVINO CPU | Production | Да | Оба пути уже есть |
preview-компоненты этой гарантией не покрываются | Intel GPU/NPU | Нативный OpenVINO | Production; часть NPU-функций Preview | Да, Windows/Linux x86-64 | OpenVINO GPU есть; NPU потребует нового device profile |
([release policy](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/release-policy.html)). | Windows, AMD CPU | ORT CPU | Production baseline | Да, `win_amd64` | Да |
| Windows, AMD GPU | DirectML | Sustained engineering | Да, `onnxruntime-directml` | Нужен новый provider/device UX |
| Windows 11 24H2+, AMD GPU | Windows ML + MIGraphX | Windows ML production; EP зависит от driver/device | Да, `onnxruntime-windowsml` | Нужны bootstrap и регистрация EP |
| Linux, AMD CPU | ORT CPU | Production baseline | Да, manylinux x86-64 | Да |
| Linux, AMD GPU | MIGraphX | Активная замена удалённого ROCm EP | Да, `onnxruntime-migraphx 1.27.1` | Нужны ROCm stack и provider integration |
| Apple Silicon, CPU | ORT CPU | Production baseline | Да, macOS 14 ARM64 | Да |
| Apple Silicon, GPU/ANE | CoreML EP | Preview | Да, в обычном ORT wheel | Нужны provider integration и profiling |
| Apple Silicon, CPU | OpenVINO GenAI Whisper | Production package; CPU-only на macOS | Да | Текущий dependency marker исключает macOS |
OpenVINO GenAI — не конкурирующий runtime, а библиотека pipelines поверх Обычный `onnxruntime` 1.28.0 поставляет `cp313` wheels для Windows x86-64 и
OpenVINO и OpenVINO Tokenizers. Их `major.minor.patch` должны совпадать: ARM64, Linux x86-64 и ARM64, macOS 14 ARM64
разъезд может привести к ABI/import errors; PyPI wheel нельзя смешивать с C++ ([files](https://pypi.org/project/onnxruntime/1.28.0/#files)). Для сравнения,
archives другого ABI ([официальные правила совместимости](https://pypi.org/project/openvino-genai/2026.3.0.0/)). `onnxruntime-directml` 1.24.4 ограничен Windows x86-64, а
`onnxruntime-openvino` 1.24.1 — Windows/Linux x86-64
([DirectML files](https://pypi.org/project/onnxruntime-directml/1.24.4/#files),
[OpenVINO EP files](https://pypi.org/project/onnxruntime-openvino/1.24.1/#files)).
Whisper — активный, а не legacy use case OpenVINO GenAI: ### AMD
- OpenVINO 2026.0 добавил word-level timestamps в WhisperPipeline на CPU, GPU На AMD x86 CPU поддерживаемая опора — ORT CPU EP. OpenVINO 2026.3 официально
и NPU; в 2026.3 результаты также содержат определённый/заданный язык, а NPU перечисляет Intel и ARM/Apple CPU, но не AMD x86; наличие x86 wheel само по себе
отдаёт word timestamps по умолчанию не является обещанием поддержки AMD
([2026.0 release notes](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino.html#openvino-2026-0-0), ([OpenVINO requirements](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/system-requirements.html)).
[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 доступен в Под Windows DirectML поддерживает AMD GCN первого поколения и новее, но его
дистрибутивах, целевая аппаратная платформа начинается с Intel Core Ultra, ограниченный lifecycle делает Windows ML + MIGraphX более перспективным путём.
Compiler-In-Plugin появился preview в 2026.0 и стал предпочитаемым компилятором Текущий Windows ML MIGraphX требует совместимый GPU/driver и не поддерживает
в 2026.1. При этом NPU требует отдельный driver, поддерживает только static GenAI scenarios; применимость этой формулировки к GigaAM RNN-T не определена и
shapes, а совместимость предкомпилированных blobs между версиями OpenVINO не должна проверяться экспериментом
гарантируется ([NPU device](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html)). ([Windows ML EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/supported-execution-providers)).
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 Под Linux прежний ROCm EP удалён из ORT 1.23. Пакет `onnxruntime-rocm`
появился только в Core Ultra. Для текущей целевой машины долгоживущий 1.22.2.post3 всё ещё имеет `cp313`, но закреплён на ветке до удаления EP.
OpenVINO-путь означает прежде всего CPU/iGPU; NPU — будущий аппаратный профиль, Активный `onnxruntime-migraphx` 1.27.1 публикует
который нужно выбирать явно, тем более что OpenVINO AUTO пока исключает NPU из `cp313-manylinux_2_34_x86_64`; реальные ограничения теперь лежат в ROCm/GPU/OS
дефолтного приоритета и покрытии графа
([NPU hardware](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html), ([ROCm PyPI JSON](https://pypi.org/pypi/onnxruntime-rocm/json),
[AUTO priority](https://docs.openvino.ai/2026/openvino-workflow/running-inference/inference-devices-and-modes/auto-device-selection.html)). [MIGraphX PyPI JSON](https://pypi.org/pypi/onnxruntime-migraphx/json),
[MIGraphX EP](https://onnxruntime.ai/docs/execution-providers/MIGraphX-ExecutionProvider.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/)).
## Windows ML: следующий Windows-слой над ORT
### Что доступно сейчас, а что пока preview
> Artifact caveat: Microsoft Learn ещё указывает Python 3.10–3.13, тогда как текущий `onnxruntime-windowsml` требует Python 3.11+ и уже имеет cp314. Для установки источником истины служит фактическая wheel matrix PyPI; cp313 подтверждён для x64 и ARM64 ([PyPI JSON](https://pypi.org/pypi/onnxruntime-windowsml/json)).
**Подтверждено.** Windows ML — не новый формат модели и не замена ONNX Runtime: Microsoft описывает его как Windows-фреймворк локального инференса, **powered by ONNX Runtime**. Runtime содержит `onnxruntime.dll`, DirectML и Windows ML API; обычный инференс по-прежнему создаёт ORT `InferenceSession`. Windows ML добавляет обнаружение устройств, каталог совместимых vendor EP, их установку, регистрацию и обновление. DirectML остаётся встроенным legacy GPU EP; MIGraphX/VitisAI/OpenVINO/QNN/NvTensorRtRtx поставляются через каталог или вместе с приложением ([обзор](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/overview), [состав и deployment](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/distributing-your-app), [API](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/api-reference)).
Для Python реальная поставка называется `onnxruntime-windowsml`, а не анонсированная ранее `onnxruntime-winml`. На 2026-08-12 последняя версия — `1.27.1.202607110137`, статус PyPI `Production/Stable`, `Requires-Python >=3.11`; есть `cp313` wheels для `win_amd64` и `win_arm64` ([PyPI](https://pypi.org/project/onnxruntime-windowsml/)). Это уже доступный продуктовый путь. Отдельная **ONNX Runtime GenAI Windows ML library 0.x** прямо обозначена как Preview; её нельзя переносить на статус обычного ONNX-инференса ([GenAI Preview](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/run-genai-onnx-models)).
Python поддержан на 3.10–3.13, x64/ARM64, но только как framework-dependent unpackaged app: нужны Python с python.org/winget, Windows App SDK Runtime и bootstrap-пакеты. Self-contained deployment для Python не предусмотрен. Базовый runtime может работать на поддерживаемых Windows 10, но динамический каталог аппаратных EP требует Windows 11 24H2, build 26100+ ([getting started](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/get-started), [deployment](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/distributing-your-app), [поддерживаемые EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/supported-execution-providers)).
**Существенный caveat для CLI.** Каталог скачивает и обновляет EP, однако Python-приложение должно перечислить подходящие EP, вызвать `ensure_ready_async()` и зарегистрировать библиотеку через `onnxruntime.register_execution_provider_library`. Microsoft отдельно предупреждает, что `EnsureAndRegisterCertifiedAsync()` не регистрирует EP в Python ORT environment ([инициализация EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/initialize-execution-providers), [выбор EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/select-execution-providers)). Поэтому:
- `onnxruntime-windowsml` + встроенный DirectML — практически применимая замена ORT-дистрибутива для `onnx-asr`; upstream 0.12 документирует именно эту установку и тот же providers API ([installation](https://istupakov.github.io/onnx-asr/installation/));
- vendor EP из каталога (например, MIGraphX) не появится в существующем `local-transcriber` без Windows App SDK bootstrap/registration glue;
- device policy (`MAX_PERFORMANCE`, `PREFER_NPU` и другие) — пожелание к выбору, а не доказательство полного offload конкретной модели. Нужны capability discovery, session profiling и проверка fallback.
## AMD и Apple: практические пути без кастомной сборки
### AMD CPU и GPU
На AMD x86 CPU обычный `onnxruntime` использует portable CPU EP: это готовый baseline на Windows и Linux. OpenVINO 2026.3 официально перечисляет Intel и ARM/Apple CPU, но **не перечисляет AMD x86 в supported hardware**; наличие x86 wheel ещё не является обещанием поддержки AMD CPU ([OpenVINO system requirements](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/system-requirements.html)). Поэтому OpenVINO на AMD x86 — только экспериментальный путь, не поддерживаемая опора проекта.
На AMD GPU под Windows есть два готовых пути:
1. `onnxruntime-directml` 1.24.4 (`cp313-win_amd64`): DirectML официально поддерживает AMD GCN первого поколения и новее, но находится в sustained engineering, ограничен ONNX opset 20 и не гарантирует полный offload ([DirectML EP](https://onnxruntime.ai/docs/execution-providers/DirectML-ExecutionProvider.html)).
2. Windows ML 2.x: встроенный DirectML или загружаемый MIGraphX. Каталог MIGraphX доступен только на Windows 11 24H2+ и при совместимых GPU/driver; Microsoft отдельно отмечает, что текущий MIGraphX EP не поддерживает GenAI scenarios ([Windows ML EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/supported-execution-providers)). Для GigaAM RNN-T граница понятия GenAI в этой таблице не определена — нужен локальный тест, а не перенос ограничения по аналогии.
На AMD GPU под Linux прежний ROCm EP удалён из source tree начиная с ORT 1.23; Microsoft рекомендует MIGraphX или VitisAI ([ORT 1.23](https://github.com/microsoft/onnxruntime/releases/tag/v1.23.0)). Старый `onnxruntime-rocm` всё ещё публикуется на PyPI (последний `1.22.2.post3`, включая `cp313`), но остаётся на ветке до удаления EP и потому не является долгоживущим направлением ([PyPI JSON](https://pypi.org/pypi/onnxruntime-rocm/json)). Активный `onnxruntime-migraphx` уже имеет версию `1.27.1` и `cp313-manylinux_2_34_x86_64`; это готовый wheel, хотя он требует совместимых ROCm/GPU/OS и отличается от core ORT 1.28 ([PyPI JSON](https://pypi.org/pypi/onnxruntime-migraphx/json), [MIGraphX EP](https://onnxruntime.ai/docs/execution-providers/MIGraphX-ExecutionProvider.html)). Следовательно, Python 3.13 больше не блокирует установку; реальными неизвестными остаются системный ROCm stack и совместимость конкретных графов.
### Apple Silicon ### Apple Silicon
`onnxruntime` 1.28.0 публикует `cp313` wheel для macOS 14 ARM64; это готовый CPU baseline. Тот же macOS build доступен `onnx-asr`, который документирует `CPUExecutionProvider` и `CoreMLExecutionProvider` в обычном пакете ([ORT Python install](https://onnxruntime.ai/docs/get-started/with-python.html), [onnx-asr installation](https://istupakov.github.io/onnx-asr/installation/)). ORT CPU — готовый baseline. `onnx-asr` документирует CoreML в обычном
`onnxruntime` package. CoreML EP может использовать CPU, GPU и Apple Neural
Engine через `MLComputeUnits`, но забирает только поддержанные подграфы.
Dynamic shapes могут быть дорогими; offload внутри `Loop`/`Scan`/`If` по
умолчанию выключен. `ProfileComputePlan` позволяет увидеть размещение
([onnx-asr installation](https://istupakov.github.io/onnx-asr/installation/),
[CoreML EP](https://onnxruntime.ai/docs/execution-providers/CoreML-ExecutionProvider.html)).
CoreML EP может задействовать CPU, GPU и Apple Neural Engine через `MLComputeUnits`. Он забирает поддерживаемые subgraphs, допускает динамические shapes, но предупреждает об их возможной цене; для `Loop`/`Scan`/`If` offload внутри тела по умолчанию выключен. Параметры `RequireStaticInputShapes`, `EnableOnSubgraphs` и `ProfileComputePlan` позволяют проверить фактическое размещение. Сам EP в общей таблице ORT всё ещё помечен Preview ([CoreML EP](https://onnxruntime.ai/docs/execution-providers/CoreML-ExecutionProvider.html), [таблица EP](https://onnxruntime.ai/docs/execution-providers/)). Следовательно, «CoreML доступен» не означает «GigaAM целиком работает на ANE». OpenVINO/OpenVINO GenAI имеют `cp313-macosx_11_0_arm64` wheels и поддерживают
Apple Silicon, но на macOS исполняются только на CPU. GPU plugin рассчитан на
Intel GPU, NPU plugin — на Intel NPU
([OpenVINO requirements](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/system-requirements.html),
[OpenVINO GenAI files](https://pypi.org/project/openvino-genai/2026.3.0.0/)).
OpenVINO 2026.3 и OpenVINO GenAI 2026.3 имеют `cp313-macosx_11_0_arm64` wheels и официально поддерживают Apple silicon, но на macOS OpenVINO выполняет inference только на CPU; GPU plugin поддерживает только Intel GPU, NPU plugin — Intel NPU ([system requirements](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/system-requirements.html), [openvino-genai PyPI](https://pypi.org/project/openvino-genai/2026.3.0.0/)). Значит OpenVINO Whisper на Apple Silicon технически поставляется без сборки, но не использует GPU/ANE. Текущий marker проекта, исключающий OpenVINO extra на macOS, остаётся отдельным integration constraint. ## Возможности текущих моделей
### Сводная матрица runtime/device Таблица применяет одну и ту же лестницу доказательства к трем модельным путям.
| Платформа и устройство | Готовый runtime/EP | Статус на 2026-08-12 | `cp313` | Без кастомной сборки в текущем CLI | | Модель и требуемый контракт | Переносимый baseline | Intel accelerator | AMD accelerator | Apple accelerator | Browser |
|---|---|---|---|---|
| Windows, AMD CPU | ORT CPU EP | production baseline | да, `win_amd64` | да |
| Windows, AMD GPU | ORT DirectML | sustained engineering | да, `onnxruntime-directml` | пакет есть; нужен новый provider/device UX |
| Windows 11 24H2+, AMD GPU | Windows ML + DirectML/MIGraphX | Windows ML production; catalog EP зависит от driver/device | да, `onnxruntime-windowsml` | DirectML близко к готовому; MIGraphX требует bootstrap/registration |
| Linux, AMD CPU | ORT CPU EP | production baseline | да, `manylinux x86_64` | да |
| Linux, AMD GPU | ORT MIGraphX | active replacement for removed ROCm EP | да, `onnxruntime-migraphx 1.27.1` | wheel есть; нужны ROCm compatibility и model smoke-test |
| Apple Silicon, CPU | ORT CPU EP | production baseline | да, macOS 14 ARM64 | да |
| Apple Silicon, GPU/ANE | CoreML EP | preview; partial partitioning possible | да, в обычном ORT wheel | пакет есть; требуется provider integration и profiling |
| Apple Silicon, CPU | OpenVINO GenAI Whisper | production package; CPU-only на macOS | да | upstream да; текущий project extra/marker — нет |
## Матрица моделей: что действительно переносится
Легенда: **подтверждено** — есть прямое upstream-обещание/поставка; **вывод** — следует из одинакового ONNX/ORT контракта, но нет проверки данной модели; **эксперимент** — session/model compatibility и offload неизвестны.
| Модель/контракт | ORT CPU (AMD Win/Linux, Apple) | AMD GPU Windows (DML/WinML) | AMD GPU Linux (MIGraphX) | Apple GPU/ANE (CoreML) | OpenVINO native |
|---|---|---|---|---|---| |---|---|---|---|---|---|
| GigaAM v3 E2E RNN-T ONNX + token timestamps | **Подтверждено** upstream `onnx-asr` на x86/Arm CPU и готовыми cp313 wheels. `with_timestamps()` — API `onnx-asr` ([usage](https://istupakov.github.io/onnx-asr/usage/), [model card](https://huggingface.co/istupakov/gigaam-v3-onnx)) | `onnx-asr` заявляет DirectML/WebGPU support и документирует Windows ML package; **эксперимент** для конкретного E2E RNN-T: session creation, доля DML/MIGraphX, точность/timestamps | cp313 MIGraphX wheel есть; provider допустим как произвольная строка, но не first-class/tested; **эксперимент** для graph coverage и output | CoreML заявлен `onnx-asr`; **эксперимент** для dynamic encoder/decoder, control flow и доли ANE | OpenVINO EP package lagging; native IR не является тем же artifact; **эксперимент/конверсия** | | GigaAM v3 E2E RNN-T: текст + token timestamps | **Подтверждено:** `onnx-asr` + ORT CPU на x86/ARM | OpenVINO EP или конверсия в IR — **эксперимент** | DirectML/WinML MIGraphX/Linux MIGraphX — **эксперимент** | CoreML — **эксперимент** | Нужен порт Python preprocessing/decoder и проверка kernels |
| OpenVINO GenAI Whisper + word timestamps | не тот runtime/model artifact | OpenVINO GPU не работает на AMD GPU; CPU path возможен лишь там, где CPU официально поддержан | то же | OpenVINO CPU на Apple silicon **подтверждён**; GPU/ANE нет | **Подтверждено** для Whisper tiny/base/small/medium/large-v3 и Distil-Whisper; word timestamps доступны CPU/GPU/NPU, stateful model обязателен ([ASR guide](https://openvinotoolkit.github.io/openvino.genai/docs/use-cases/speech-recognition/), [supported models](https://openvinotoolkit.github.io/openvino.genai/docs/supported-models/)) | | OpenVINO GenAI Whisper: текст + word timestamps | Нативный OpenVINO CPU на поддержанных платформах | **Подтверждено:** OpenVINO CPU/GPU/NPU | AMD GPU не поддержан; AMD CPU не входит в official hardware | **Подтверждено:** только OpenVINO CPU | Это другой runtime/model artifact; не подтверждено |
| sherpa-onnx pyannote segmentation + WeSpeaker embeddings | **Подтверждено локальной разведкой** на CPU ORT для одной записи; cp313 wheels есть на Windows/Linux/macOS ARM64 ([разведка](../benchmarks/2026-08-12-diarization-feasibility.md), [PyPI 1.13.5](https://pypi.org/project/sherpa-onnx/1.13.5/)) | sherpa имеет DirectML build option, но готовый Python wheel/provider и именно эти две модели на DML не подтверждены: **эксперимент/возможно rebuild** | готовая sherpa Python поставка с MIGraphX не подтверждена; **не готово** | upstream Python provider vocabulary обычно ограничивает `cpu,cuda,coreml`; наличие CoreML в wheel не доказывает поддержку diarization graphs: **эксперимент** | модели ONNX теоретически читаются OpenVINO, но полное/частичное покрытие и численная стабильность clustering inputs не подтверждены: **эксперимент** | | PyAnnote segmentation + WeSpeaker embeddings: интервалы + кластеры | **Подтверждено локально:** sherpa-onnx + ORT CPU на одной записи | OpenVINO EP/native — **эксперимент** | DML/MIGraphX — **эксперимент**, для sherpa может потребоваться rebuild | CoreML — **эксперимент** | sherpa имеет WASM demo, но выбранная пара моделей не подтверждена |
Почему timestamps должны пережить смену EP — это **вывод**, а не готовая совместимость: `onnx-asr` сохраняет в Python preprocessing и greedy decoding, а EP исполняет ONNX encoder/decoder; одинаковые тензорные выходы должны дать тот же `TimestampedResult` ([описание архитектуры](https://github.com/istupakov/onnx-asr/tree/v0.12.0), [timestamps API](https://istupakov.github.io/onnx-asr/usage/)). Но mixed precision, unsupported ops/fallback и provider-specific graph transforms требуют golden-output проверки. Для diarization выходной контракт сегментов создаётся sherpa pipeline после двух ONNX-моделей и clustering ([C API](https://k2-fsa.github.io/sherpa/onnx/c-api/html/speaker_diarization.html)); ускорение одной модели не должно считаться ускорением всего pipeline. ### GigaAM E2E RNN-T
Отдельный support gap: официальный recipe sherpa подтверждает PyAnnote `onnx-asr` работает на x86/ARM CPU и перечисляет CoreML, DirectML, ROCm и
segmentation с 3D-Speaker или NeMo embeddings, но не с выбранным в разведке WebGPU. GigaAM создаёт обычные ORT-сессии encoder/decoder/joint, поэтому смена
WeSpeaker. Локальный CPU-прогон уже доказал, что эта пара создаёт интервалы на EP архитектурно возможна
одной записи; неизвестны upstream-гарантия контракта и переносимость на другие ([onnx-asr](https://istupakov.github.io/onnx-asr/),
EP, а не базовая совместимость CPU-пути [installation](https://istupakov.github.io/onnx-asr/installation/),
([разведка](../benchmarks/2026-08-12-diarization-feasibility.md), [model card](https://huggingface.co/istupakov/gigaam-v3-onnx)). Но это не
[sherpa models](https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/models.html), доказывает operator coverage или полный offload конкретного E2E RNN-T.
[WeSpeaker pretrained models](https://github.com/wenet-e2e/wespeaker/blob/master/docs/pretrained.md)).
GigaAM timestamp caveat: upstream GigaAM `transcribe(..., word_timestamps=True)` возвращает слова со start/end, но его официальный ONNX helper экспортирует encoder/decoder/joint и проверяет только text parity; helper возвращает `List[str]` и теряет emission frames ([GigaAM repository](https://github.com/salute-developers/GigaAM), [ONNX parity test](https://github.com/salute-developers/GigaAM/blob/main/tests/test_onnx.py), [ONNX helper](https://github.com/salute-developers/GigaAM/blob/main/gigaam/onnx_utils.py)). Timestamped contract текущего проекта даёт именно `onnx-asr.with_timestamps()`, а не произвольный GigaAM ONNX export. Поэтому golden test должен сравнивать project/onnx-asr contract, не только распознанный текст. Таймкоды формирует `onnx-asr.with_timestamps()` из тензорных выходов модели.
Если EP сохраняет эти выходы, `TimestampedResult` должен сохраниться — это
**вывод**, который требует golden test. Mixed precision, graph transforms и
CPU fallback могут менять численные результаты
([timestamps API](https://istupakov.github.io/onnx-asr/usage/),
[архитектура пакета](https://github.com/istupakov/onnx-asr/tree/v0.12.0)).
Минимальная будущая экспериментальная матрица без заявления производительности: Официальный ONNX helper исходного GigaAM проверяет только text parity и теряет
emission frames. Поэтому проверять нужно именно контракт `onnx-asr`, а не
произвольный GigaAM ONNX export
([GigaAM](https://github.com/salute-developers/GigaAM),
[ONNX parity test](https://github.com/salute-developers/GigaAM/blob/main/tests/test_onnx.py),
[ONNX helper](https://github.com/salute-developers/GigaAM/blob/main/gigaam/onnx_utils.py)).
1. Один фиксированный 5–10-минутный fixture с overlap и эталоном текущего CPU output. ### OpenVINO Whisper
2. Для GigaAM E2E RNN-T: ORT CPU против DML, WinML MIGraphX, CoreML и MIGraphX Linux; фиксировать session creation, provider assignment/profile, CPU fallback, transcript/token timestamps и численное расхождение.
3. Для diarization: отдельно pyannote segmentation и WeSpeaker embeddings, затем полный pipeline; фиксировать provider assignment каждой сессии, сегменты/число спикеров и стабильность embeddings/clustering.
4. Для OpenVINO Whisper: CPU на Apple и поддерживаемом Intel, GPU/NPU только на Intel; проверять word timestamps и project adapter отдельно.
## Почему ONNX Runtime Web стал общим браузерным слоем OpenVINO GenAI подтверждает Whisper tiny/base/small/medium/large-v3 и
Distil-Whisper. Word timestamps доступны на CPU/GPU/NPU, stateful model
обязателен
([ASR guide](https://openvinotoolkit.github.io/openvino.genai/docs/use-cases/speech-recognition/),
[supported models](https://openvinotoolkit.github.io/openvino.genai/docs/supported-models/)).
Это наиболее доказанный accelerator-путь из рассматриваемых, но только для
поддержанного OpenVINO hardware. На Apple Silicon он остаётся CPU-путём; на AMD
GPU не работает.
ONNX остаётся переносимым serialized graph/IR, а `onnxruntime-web` — отдельным JavaScript/WebAssembly runtime. Общность браузеров даёт не ONNX-файл сам по себе, а единый ORT JS API поверх разных EP: `wasm` как default CPU baseline, `webgpu`, `webnn` и legacy `webgl`. ORT распределяет поддерживаемые nodes/subgraphs на accelerator, а неподдерживаемые может оставить WASM, если он указан вторым provider ([web overview](https://onnxruntime.ai/docs/tutorials/web/), [session options](https://onnxruntime.ai/docs/tutorials/web/env-flags-and-session-options.html)). Это та же архитектурная идея, что native ORT, но runtime binaries и provider kernels другие. Проектный OpenVINO backend уже запрашивает timestamps, но сводит результат к
chunk-сегментам. Поэтому для диаризации нужно сначала определить и протянуть
word-level контракт через `Backend`/`TranscribeResult`.
На 2026-08-12 официальный browser matrix таков ([matrix](https://onnxruntime.ai/docs/get-started/with-javascript/web.html)): ### PyAnnote + WeSpeaker для диаризации
- WASM: Chrome/Edge, Safari, Firefox на основных desktop/mobile платформах; полный набор ONNX operators, CPU baseline; Локальная разведка доказала, что связка PyAnnote segmentation + WeSpeaker
- WebGPU: Chromium 113+ на Windows, Chromium на macOS/Android; в ORT Web всё ещё обозначен experimental, operator subset; embeddings создаёт интервалы на CPU ORT для одной записи. Это закрывает базовую
- WebNN: experimental и не включён по умолчанию; официальный matrix требует feature flag в Chrome/Edge Windows; unsupported ops fall back to WASM ([WebNN guide](https://onnxruntime.ai/docs/tutorials/web/ep-webnn.html)); совместимость, но не upstream-гарантию пары и не переносимость на другие EP
- WebGL: maintenance mode, operator subset. ([разведка](../benchmarks/2026-08-12-diarization-feasibility.md)).
Один ONNX artifact и близкий `InferenceSession` contract можно использовать native и web, но «один artifact» не означает одинаковую работоспособность. Для WebGPU опубликована отдельная operator table ([WebGPU operators](https://github.com/microsoft/onnxruntime/blob/main/js/web/docs/webgpu-operators.md)); accelerator EP поддерживают лишь subset, а WASM — все операторы. Большие модели ограничены браузером: около 2 GB для ArrayBuffer/Protobuf, 4 GB WebAssembly memory; external data нужно передавать URL/Blob явно ([large models](https://onnxruntime.ai/docs/tutorials/web/large-models.html)). WASM threading включается только при `crossOriginIsolated`; proxy worker не совместим с WebGPU и CSP-restricted environment ([env flags](https://onnxruntime.ai/docs/tutorials/web/env-flags-and-session-options.html)). Dynamic shapes и CPU fallback также исключают некоторые оптимизации WebGPU graph capture ([WebGPU guide](https://onnxruntime.ai/docs/tutorials/web/ep-webgpu.html)). Официальный sherpa recipe перечисляет PyAnnote с 3D-Speaker или NeMo
embeddings, а WeSpeaker публикует собственные ONNX-модели. Поэтому на новом EP
нужно отдельно проверять обе сессии и полный pipeline
([sherpa models](https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/models.html),
[WeSpeaker models](https://github.com/wenet-e2e/wespeaker/blob/master/docs/pretrained.md)).
`onnx-asr` 0.12 заявляет WebGPU support для **native Python package** и называет `onnxruntime-webgpu` beta; это не browser JavaScript port `onnx-asr` ([installation](https://istupakov.github.io/onnx-asr/installation/)). Для GigaAM E2E RNN-T browser compatibility не подтверждена: нужны JS preprocessing/decoder либо порт Python-логики, загрузка нескольких model artifacts, проверка WebGPU operator coverage и WASM fallback. У sherpa-onnx есть отдельная WebAssembly speaker-diarization сборка и JS example, но она однопоточная и не доказывает, что выбранные проектом pyannote + WeSpeaker models работают через ORT Web WebGPU ([sherpa JS diarization](https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/javascript.html), [build option](https://github.com/k2-fsa/sherpa-onnx/blob/master/CMakeLists.txt)). Итоговые сегменты создаёт sherpa после двух ONNX-моделей и clustering. Ускорение
одной сессии не означает ускорение pipeline; численные изменения эмбеддингов
могут изменить кластеры даже при совпадающем текстовом контракте
([C API](https://k2-fsa.github.io/sherpa/onnx/c-api/html/speaker_diarization.html)).
Native WebGPU и browser WebGPU нельзя смешивать: native Python EP использует Dawn поверх D3D12/Vulkan/Metal и теперь поставляется plugin-пакетом `onnxruntime-ep-webgpu` (0.2.1, universal wheels), тогда как ORT Web использует browser JSEP/WASM path ([native WebGPU EP](https://onnxruntime.ai/docs/execution-providers/WebGPU-ExecutionProvider.html), [plugin PyPI JSON](https://pypi.org/pypi/onnxruntime-ep-webgpu/json)). ## Почему ONNX Runtime Web работает между браузерами
Практический урок для CLI — не новый browser product, а более строгая portability-модель: Браузерная переносимость появляется не из ONNX-файла отдельно, а из сочетания
трёх решений:
- сохранять portable CPU baseline; 1. ONNX задаёт общий сериализованный граф.
- считать accelerator опциональной capability, обнаруживаемой при запуске; 2. ORT Web даёт один JavaScript `InferenceSession` API.
- различать «API/EP существует», «model session создалась», «graph offloaded» и «контракт/качество сохранены»; 3. WASM служит широким CPU baseline, а WebGPU/WebNN подключаются как
- измерять долю fallback и end-to-end pipeline, а не обещать устройство по имени provider. ускорители с fallback на WASM.
## Что это меняет для карты диаризации На 2026-08-12 официальный browser matrix выглядит так
([матрица](https://onnxruntime.ai/docs/get-started/with-javascript/web.html)):
1. Разведка `sherpa-onnx` на обычном CPU ORT не опирается на затухающий - WASM работает в Chrome/Edge, Safari и Firefox на основных desktop/mobile
компонент: ядро ORT активно и имеет самый широкий CPython/platform coverage. платформах и имеет наиболее полное покрытие операторов;
Это поддерживает текущий вариант диаризации как optional post-processing, - WebGPU поддерживается Chromium на Windows/macOS/Android, остаётся experimental
но ничего не говорит о качестве DirectML/OpenVINO EP на конкретных двух в ORT Web и имеет собственный operator subset;
моделях. - WebNN experimental и в официальной матрице требует feature flag в
2. Формулировка разведочного замера «у OpenVINO GenAI потокенных таймкодов нет» Chrome/Edge Windows; неподдержанные узлы могут уйти в WASM
требует уточнения. Upstream с 2026.0 предоставляет word-level timestamps; ([WebNN guide](https://onnxruntime.ai/docs/tutorials/web/ep-webnn.html));
сейчас их не экспортирует проектный OpenVINO backend. Следовательно, - WebGL находится в maintenance mode.
невозможность пословной привязки на `--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.
## Рекомендация по жизненному циклу Один model artifact не означает одинаковую работоспособность. WebGPU имеет
отдельную [таблицу операторов](https://github.com/microsoft/onnxruntime/blob/main/js/web/docs/webgpu-operators.md),
а preprocessing и decoding остаются кодом приложения. Большие модели упираются
примерно в 2 GB для ArrayBuffer/Protobuf и 4 GB WebAssembly memory; external
data нужно загружать отдельно
([large models](https://onnxruntime.ai/docs/tutorials/web/large-models.html)).
WASM threading требует `crossOriginIsolated`; proxy worker несовместим с
WebGPU, а dynamic shapes и CPU fallback ограничивают graph capture
([environment flags](https://onnxruntime.ai/docs/tutorials/web/env-flags-and-session-options.html),
[WebGPU guide](https://onnxruntime.ai/docs/tutorials/web/ep-webgpu.html)).
Для portability evidence приоритеты такие: CPU baseline должен оставаться обязательным; accelerator — opt-in capability с явной диагностикой provider/device/fallback; platform wheel и provider name считаются только предпосылкой, пока model-specific smoke/golden test не подтвердил session creation, placement и выходной контракт. Windows ML, MIGraphX, CoreML и native WebGPU следует оценивать отдельными экспериментами, а не добавлять в UX как обещанные устройства заранее. `onnx-asr` заявляет WebGPU для **native Python package**. Это не browser port:
GigaAM потребует JavaScript preprocessing/decoder, загрузки нескольких
артефактов и проверки kernels. У sherpa-onnx есть отдельная однопоточная WASM
speaker-diarization demo, но она не доказывает работу проектной пары PyAnnote +
WeSpeaker через ORT Web WebGPU
([onnx-asr installation](https://istupakov.github.io/onnx-asr/installation/),
[sherpa JS diarization](https://k2-fsa.github.io/sherpa/onnx/speaker-diarization/javascript.html)).
Это не решение о консолидации backend-ов на ORT и не предложение browser-направления. Native WebGPU EP также не равен browser WebGPU: Python plugin использует Dawn
поверх D3D12/Vulkan/Metal, ORT Web — browser JSEP/WASM path
([native WebGPU EP](https://onnxruntime.ai/docs/execution-providers/WebGPU-ExecutionProvider.html),
[plugin PyPI JSON](https://pypi.org/pypi/onnxruntime-ep-webgpu/json)).
Ниже — **интерпретация источников для local-transcriber**, а не опубликованный Полезный для CLI вывод из браузерной архитектуры — не новый продукт, а строгая
roadmap Microsoft или Intel. Она исходит из фактов о lifecycle, wheel-матрицах политика capabilities:
и текущем контракте проекта; реальную пригодность каждого ускорителя должен
подтвердить проектный benchmark.
- Сохранять **ONNX-модели диаризации + обычный CPU ORT** как базовый переносимый - всегда сохранять переносимый CPU baseline;
путь: это наименее связанный с одним вендором слой и единственная из трёх - обнаруживать ускоритель во время запуска;
поставок с wheel на Windows/Linux ARM64 и macOS ARM64. - различать наличие API, успешную сессию, размещение графа и сохранение
- Рассматривать **OpenVINO EP как опциональное ускорение этих же ONNX-моделей на контракта;
Intel**, но не обещать его до проверки operator coverage, фактического - измерять end-to-end pipeline, а не отдельное имя provider.
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.
## Новые вопросы карты ## Что это меняет для `local-transcriber`
- Нужен ли отдельный portability experiment: GigaAM E2E RNN-T и обе diarization-модели на DirectML, WinML MIGraphX, Linux MIGraphX и CoreML с node placement/profile и golden outputs? 1. **CPU ORT остаётся переносимым baseline.** Он не зависит от затухающего EP и
- Насколько устойчива локально работающая пара PyAnnote + WeSpeaker между обеспечивает самый широкий CPython/platform coverage для GigaAM и
платформами и EP, если upstream recipe её не фиксирует? диаризации.
- Должен ли Windows UX показывать не только выбранный provider, но и фактический accelerator/fallback после capability discovery? 2. **Нативный OpenVINO остаётся отдельным долгосрочным Intel ASR-путём.** Его
- Стоит ли поддерживать Windows ML bootstrap/catalog как отдельный integration layer или оставить низкофрикционный DirectML до появления подтверждённого выигрыша? не следует заменять OpenVINO EP только ради единого ORT API: EP отстаёт и не
- Какой минимальный browser experiment проверит GigaAM preprocessing/decoder/timestamps и pyannote+embedding WASM/WebGPU, не превращая карту в browser roadmap? даёт автоматически pipeline-возможности OpenVINO GenAI.
3. **Пословная диаризация на `openvino-*` технически достижима.** Upstream уже
возвращает word timestamps; карта должна решить контракт и fallback, а не
считать отсутствие таймкодов свойством движка.
4. **AMD/Apple acceleration нельзя добавлять по факту наличия wheel.** Сначала
нужны model-specific smoke/profile/golden tests; только затем device UX и
dependency markers.
5. **Диаризацию не нужно связывать с немедленным выбором аппаратного EP.**
Переносимый CPU-вариант может быть специфицирован независимо; ускорение двух
моделей — отдельная работа.
6. **Консолидация на ORT из исследования не следует.** FasterWhisper сохраняет
CUDA и языковое покрытие, нативный OpenVINO — актуальный Intel ASR API, ORT —
переносимый ONNX-путь.
- Какой точный контракт word timestamps возвращают `WhisperPipeline` и новый Для текущей карты это даёт два входа:
`ASRPipeline` 2026.3, и как без потери совместимости добавить их в проектный
`Backend`/`TranscribeResult`? - [«Выбрать единицу привязки спикера к тексту»](https://git.dementev.space/ddmitry/local-transcriber/issues/14)
- Дают ли `sherpa-onnx` segmentation и embedding models полный offload в должен назвать timestamp-aware изменение `Backend`/`TranscribeResult`;
OpenVINO EP, или часть графа уходит в CPU EP; меняются ли границы и - [«UX диаризации: флаг, число участников, зависимость и поведение на OpenVINO»](https://git.dementev.space/ddmitry/local-transcriber/issues/16)
эмбеддинги численно? должен определить поведение там, где конкретный backend/model не отдаёт
- Есть ли выигрыш OpenVINO EP на целевом Intel Core i5 11-го поколения после нужных таймкодов.
учёта второго runtime, загрузки модели и памяти, или CPU ORT уже оптимальнее?
- Нужен ли UX явного отказа/огрубления диаризации на backend без word Реализация и приёмка WinML, MIGraphX, CoreML и browser-путей остаются за
timestamps, либо backend contract должен сначала стать timestamp-aware? пунктом назначения карты.
- Следует ли разделить extra диаризации на переносимый CPU-вариант и
Intel-ускорение с platform marker, чтобы не ухудшить zero-config установку на ## Минимальная экспериментальная матрица
ARM/macOS?
Будущий platform experiment должен использовать один 5–10-минутный fixture с
перекрывающейся речью и зафиксированным CPU output.
| Объект | Сравнение | Что фиксировать |
|---|---|---|
| GigaAM E2E RNN-T | ORT CPU против DirectML, WinML MIGraphX, Linux MIGraphX, CoreML | Создание всех сессий, node placement, CPU fallback, текст, token timestamps, численное расхождение |
| PyAnnote segmentation | Те же EP отдельно от остального pipeline | Placement, интервалы и расхождение выходных тензоров |
| WeSpeaker embeddings | Те же EP отдельно | Placement, cosine drift и влияние на clustering |
| Полная диаризация | CPU baseline против каждого прошедшего EP | Число спикеров, границы, стабильность кластеров, время и память |
| OpenVINO Whisper | Intel CPU/GPU/NPU и Apple CPU | Word timestamps, проектный adapter, время и память |
| Browser, только если станет целью | WASM baseline против WebGPU/WebNN | Размер артефактов, kernels/fallback, preprocessing/decoder и память |
Путь можно предлагать пользователю только после прохождения всех пяти уровней
доказательства; выигрыш отдельной ONNX-сессии не считается выигрышем
end-to-end транскрипции или диаризации.
## Открытые вопросы после исследования
### Внутри карты диаризации
- Какой точный word/token timestamp contract нужен formatter и объединению с
интервалами спикеров?
- Как представить capability backend/model и какое fallback-поведение выбрать,
если пословных таймкодов нет?
### Отдельные будущие работы
- Проходят ли GigaAM E2E RNN-T, PyAnnote и WeSpeaker все пять уровней на
DirectML, Windows ML MIGraphX, Linux MIGraphX и CoreML?
- Насколько устойчива локально работающая пара PyAnnote + WeSpeaker между EP,
если upstream recipe её не фиксирует?
- Окупает ли Windows ML bootstrap/catalog преимущество над низкофрикционным,
но legacy DirectML?
- Даёт ли OpenVINO EP выигрыш моделям диаризации на целевом Intel Core i5 после
учёта fallback, загрузки и памяти?
- Нужен ли отдельный browser experiment, или браузерная ветка остаётся только
архитектурным примером переносимого baseline и опциональных ускорителей?