# Куда движутся ONNX Runtime и OpenVINO: жизненный цикл и переносимость моделей **Дата:** 2026-08-12 **Статус:** исследование для карты диаризации. Не архитектурное решение и не основание для консолидации всех движков распознавания на ONNX Runtime. ## Вопрос и границы Исследование отвечает на два связанных вопроса: 1. Насколько устойчивы ONNX Runtime (ORT), его аппаратные Execution Provider (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 — **движки распознавания**. Обновление движка само по себе не меняет поддерживаемую модель или модель по умолчанию. Архитектурная точка отсчёта — независимые бэкенды из [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). Оно основано на первичных источниках: официальной документации, release notes, репозиториях владельцев и фактических метаданных PyPI на 2026-08-12. Вне границ документа: - решение о консолидации проекта на одном runtime; - выбор нового устройства или модели по умолчанию; - обещание производительности без model-specific benchmark; - разработка браузерной версии `local-transcriber`. ## Краткий ответ - **Переносимый фундамент проекта — ONNX-артефакт плюс ORT CPU EP.** ORT core активно развивается и имеет наиболее широкую поставку для CPython 3.13: Windows и Linux x86-64/ARM64, macOS ARM64. - **Жизненный цикл ядра ORT не переносится автоматически на каждый EP.** DirectML уже в sustained engineering, OpenVINO EP активен, но отстаёт от ORT и OpenVINO, CoreML остаётся Preview, а удалённый ROCm EP сменяется MIGraphX. - **Долгосрочный Intel-путь — нативный OpenVINO/OpenVINO GenAI.** Он имеет собственную release/LTS policy, развивает Whisper и NPU и уже предоставляет word-level timestamps. OpenVINO EP полезен как мост для ONNX-моделей, но не даёт автоматически последние возможности нативного стека. - **Новый Windows-слой — Windows ML, а не DirectML.** Windows ML остаётся ORT, но добавляет обнаружение устройств и управляемый каталог vendor EP. Для AMD там доступен MIGraphX; Python-приложению всё равно нужны bootstrap, загрузка и явная регистрация EP. - **На AMD и Apple готовый пакет ещё не означает ускорение конкретной модели.** Linux AMD имеет wheel MIGraphX для CPython 3.13, Apple Silicon — CoreML EP в обычном ORT wheel; полный offload GigaAM и моделей диаризации не подтверждён ни для одного из этих путей. - **Браузеры используют ту же архитектурную идею:** ORT Web даёт единый API, WASM — переносимый CPU baseline, WebGPU/WebNN — опциональные ускорители с ограниченным набором операторов и fallback. Сам ONNX-файл не устраняет различия preprocessing, decoding и доступных kernels. - **Главная находка для карты диаризации:** OpenVINO GenAI уже умеет возвращать пословные таймкоды. Их отсутствие в результате `local-transcriber` — пробел проектного `Backend`/`TranscribeResult`, а не ограничение OpenVINO. Общий принцип: поддержка пути доказана только тогда, когда подтверждены поставка, создание сессии, фактическое размещение графа, сохранение выходного контракта и end-to-end стоимость. Наличие wheel или имени EP закрывает только первый из этих пунктов. ## Как устроены исследуемые слои Сравниваемые названия относятся к разным уровням и не являются взаимозаменяемыми пакетами. | Слой | Роль | Что фиксирует приложение | |---|---|---| | ONNX | Формат графа, операторов и типов данных | Артефакт модели и opset ([ONNX About](https://onnx.ai/about)) | | ONNX Runtime | Движок, который загружает ONNX-граф и распределяет узлы между EP | API сессии, версия ORT и порядок EP ([архитектура ORT](https://onnxruntime.ai/docs/reference/high-level-design.html)) | | Execution Provider | Адаптер ORT к CPU, GPU или NPU; получает только поддержанные узлы/подграфы | Аппаратный runtime, provider options и CPU fallback ([архитектура EP](https://onnxruntime.ai/docs/execution-providers/)) | | 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 | 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-артефакт можно исполнять обычным ORT CPU EP, передавать его поддержанные подграфы OpenVINO EP или загружать напрямую в OpenVINO. Результат различается по покрытию операторов, квантованию, fallback и производительности ([ORT partitioning](https://onnxruntime.ai/docs/execution-providers/), [OpenVINO EP 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)). ### Лестница доказательства Для каждой пары «модель × устройство × движок» используются пять уровней: 1. **Поставка:** существует совместимый wheel/runtime. 2. **Загрузка:** все модельные сессии создаются без ошибки. 3. **Размещение:** profiler показывает, какие узлы действительно исполняет EP, а какие ушли в CPU fallback. 4. **Контракт:** текст, таймкоды, сегменты и эмбеддинги остаются допустимыми. 5. **Пригодность:** end-to-end скорость, память и качество проходят проектную приёмку. Ниже «подтверждено» означает прямое 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), [support policy](https://github.com/microsoft/onnxruntime/blob/main/SUPPORT.md)). С ORT 1.23 новые EP рекомендуется делать отдельными plugins. В 1.24–1.28 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 как общий движок, но одновременно отделяет lifecycle конкретного ускорителя от lifecycle ядра. ### Нативный OpenVINO и OpenVINO GenAI OpenVINO публикует несколько регулярных релизов в год. Каждый поддерживается до следующего, а последняя версия года становится LTS: security updates выходят два года либо до двух следующих LTS, исправления новых bugs — один год. Preview-компоненты этой гарантией не покрываются ([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)). OpenVINO GenAI — pipeline-библиотека поверх OpenVINO и OpenVINO Tokenizers. Их `major.minor.patch` должны совпадать; разъезд версий может привести к ABI/import errors. PyPI wheel нельзя смешивать с C++ archive другого ABI ([правила совместимости](https://pypi.org/project/openvino-genai/2026.3.0.0/)). Whisper остаётся активным направлением: - 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)). NPU — полноценное устройство OpenVINO, но требует отдельного driver, работает со static shapes, а совместимость compiled blobs между версиями не гарантируется. `WhisperPipeline` поддерживает NPU, однако целевой Core i5 11-го поколения 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.28](https://github.com/microsoft/onnxruntime/releases/tag/v1.28.0)). Следствие: EP остаётся рабочим мостом для ONNX-моделей, но не является способом автоматически получить последние Whisper/NPU-возможности OpenVINO. Deprecated provider options, заменённые `load_config`, не означают deprecation самого EP. ## Практическая поставка по платформам Срез сделан по фактическим wheel, а не только по classifiers. | Платформа и устройство | Готовый runtime/EP | Статус | `cp313` | Текущий CLI без новой интеграции | |---|---|---|---|---| | Intel x86 CPU | ORT CPU; OpenVINO CPU | Production | Да | Оба пути уже есть | | Intel GPU/NPU | Нативный OpenVINO | Production; часть NPU-функций Preview | Да, Windows/Linux x86-64 | OpenVINO GPU есть; NPU потребует нового device profile | | 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 | Обычный `onnxruntime` 1.28.0 поставляет `cp313` wheels для Windows x86-64 и ARM64, Linux x86-64 и ARM64, macOS 14 ARM64 ([files](https://pypi.org/project/onnxruntime/1.28.0/#files)). Для сравнения, `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)). ### AMD На AMD x86 CPU поддерживаемая опора — ORT CPU EP. OpenVINO 2026.3 официально перечисляет Intel и ARM/Apple CPU, но не AMD x86; наличие x86 wheel само по себе не является обещанием поддержки AMD ([OpenVINO requirements](https://docs.openvino.ai/2026/about-openvino/release-notes-openvino/system-requirements.html)). Под Windows DirectML поддерживает AMD GCN первого поколения и новее, но его ограниченный lifecycle делает Windows ML + MIGraphX более перспективным путём. Текущий Windows ML MIGraphX требует совместимый GPU/driver и не поддерживает GenAI scenarios; применимость этой формулировки к GigaAM RNN-T не определена и должна проверяться экспериментом ([Windows ML EP](https://learn.microsoft.com/en-us/windows/ai/new-windows-ml/supported-execution-providers)). Под Linux прежний ROCm EP удалён из ORT 1.23. Пакет `onnxruntime-rocm` 1.22.2.post3 всё ещё имеет `cp313`, но закреплён на ветке до удаления EP. Активный `onnxruntime-migraphx` 1.27.1 публикует `cp313-manylinux_2_34_x86_64`; реальные ограничения теперь лежат в ROCm/GPU/OS и покрытии графа ([ROCm PyPI JSON](https://pypi.org/pypi/onnxruntime-rocm/json), [MIGraphX PyPI JSON](https://pypi.org/pypi/onnxruntime-migraphx/json), [MIGraphX EP](https://onnxruntime.ai/docs/execution-providers/MIGraphX-ExecutionProvider.html)). ### Apple Silicon 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)). 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/)). ## Возможности текущих моделей Таблица применяет одну и ту же лестницу доказательства к трем модельным путям. | Модель и требуемый контракт | Переносимый baseline | Intel accelerator | AMD accelerator | Apple accelerator | Browser | |---|---|---|---|---|---| | 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 | Нативный OpenVINO CPU на поддержанных платформах | **Подтверждено:** OpenVINO CPU/GPU/NPU | AMD GPU не поддержан; AMD CPU не входит в official hardware | **Подтверждено:** только OpenVINO CPU | Это другой runtime/model artifact; не подтверждено | | PyAnnote segmentation + WeSpeaker embeddings: интервалы + кластеры | **Подтверждено локально:** sherpa-onnx + ORT CPU на одной записи | OpenVINO EP/native — **эксперимент** | DML/MIGraphX — **эксперимент**, для sherpa может потребоваться rebuild | CoreML — **эксперимент** | sherpa имеет WASM demo, но выбранная пара моделей не подтверждена | ### GigaAM E2E RNN-T `onnx-asr` работает на x86/ARM CPU и перечисляет CoreML, DirectML, ROCm и WebGPU. GigaAM создаёт обычные ORT-сессии encoder/decoder/joint, поэтому смена EP архитектурно возможна ([onnx-asr](https://istupakov.github.io/onnx-asr/), [installation](https://istupakov.github.io/onnx-asr/installation/), [model card](https://huggingface.co/istupakov/gigaam-v3-onnx)). Но это не доказывает operator coverage или полный offload конкретного E2E RNN-T. Таймкоды формирует `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)). ### OpenVINO Whisper 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 не работает. Проектный OpenVINO backend уже запрашивает timestamps, но сводит результат к chunk-сегментам. Поэтому для диаризации нужно сначала определить и протянуть word-level контракт через `Backend`/`TranscribeResult`. ### PyAnnote + WeSpeaker для диаризации Локальная разведка доказала, что связка PyAnnote segmentation + WeSpeaker embeddings создаёт интервалы на CPU ORT для одной записи. Это закрывает базовую совместимость, но не upstream-гарантию пары и не переносимость на другие EP ([разведка](../benchmarks/2026-08-12-diarization-feasibility.md)). Официальный 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)). Итоговые сегменты создаёт sherpa после двух ONNX-моделей и clustering. Ускорение одной сессии не означает ускорение pipeline; численные изменения эмбеддингов могут изменить кластеры даже при совпадающем текстовом контракте ([C API](https://k2-fsa.github.io/sherpa/onnx/c-api/html/speaker_diarization.html)). ## Почему ONNX Runtime Web работает между браузерами Браузерная переносимость появляется не из ONNX-файла отдельно, а из сочетания трёх решений: 1. ONNX задаёт общий сериализованный граф. 2. ORT Web даёт один JavaScript `InferenceSession` API. 3. WASM служит широким CPU baseline, а WebGPU/WebNN подключаются как ускорители с fallback на WASM. На 2026-08-12 официальный browser matrix выглядит так ([матрица](https://onnxruntime.ai/docs/get-started/with-javascript/web.html)): - WASM работает в Chrome/Edge, Safari и Firefox на основных desktop/mobile платформах и имеет наиболее полное покрытие операторов; - WebGPU поддерживается Chromium на Windows/macOS/Android, остаётся experimental в ORT Web и имеет собственный operator subset; - WebNN experimental и в официальной матрице требует feature flag в Chrome/Edge Windows; неподдержанные узлы могут уйти в WASM ([WebNN guide](https://onnxruntime.ai/docs/tutorials/web/ep-webnn.html)); - WebGL находится в maintenance mode. Один 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)). `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)). 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)). Полезный для CLI вывод из браузерной архитектуры — не новый продукт, а строгая политика capabilities: - всегда сохранять переносимый CPU baseline; - обнаруживать ускоритель во время запуска; - различать наличие API, успешную сессию, размещение графа и сохранение контракта; - измерять end-to-end pipeline, а не отдельное имя provider. ## Что это меняет для `local-transcriber` 1. **CPU ORT остаётся переносимым baseline.** Он не зависит от затухающего EP и обеспечивает самый широкий CPython/platform coverage для GigaAM и диаризации. 2. **Нативный OpenVINO остаётся отдельным долгосрочным Intel ASR-путём.** Его не следует заменять OpenVINO EP только ради единого ORT API: EP отстаёт и не даёт автоматически 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-путь. Для текущей карты это даёт два входа: - [«Выбрать единицу привязки спикера к тексту»](https://git.dementev.space/ddmitry/local-transcriber/issues/14) должен назвать timestamp-aware изменение `Backend`/`TranscribeResult`; - [«UX диаризации: флаг, число участников, зависимость и поведение на OpenVINO»](https://git.dementev.space/ddmitry/local-transcriber/issues/16) должен определить поведение там, где конкретный backend/model не отдаёт нужных таймкодов. Реализация и приёмка WinML, MIGraphX, CoreML и browser-путей остаются за пунктом назначения карты. ## Минимальная экспериментальная матрица Будущий 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 и опциональных ускорителей?