local-transcriber/docs/research/2026-08-12-onnx-runtime-openvino-lifecycle.md

Куда движутся 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: ORT, OpenVINO и OpenVINO GenAI — движки распознавания. Обновление движка само по себе не меняет поддерживаемую модель или модель по умолчанию. Архитектурная точка отсчёта — независимые бэкенды из ADR-003 и принятый ONNX CPU-путь из ADR-006.

Исследование дополняет срез обновлений движков и разведку диаризации. Оно основано на первичных источниках: официальной документации, 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)
ONNX Runtime	Движок, который загружает ONNX-граф и распределяет узлы между EP	API сессии, версия ORT и порядок EP (архитектура ORT)
Execution Provider	Адаптер ORT к CPU, GPU или NPU; получает только поддержанные узлы/подграфы	Аппаратный runtime, provider options и CPU fallback (архитектура EP)
Windows ML	Windows-поставка ORT с каталогом, установкой и обновлением vendor EP	Windows App SDK, deployment mode и политика выбора EP (обзор)
OpenVINO	Runtime, компилятор и device plugins для CPU/GPU/NPU; читает в том числе ONNX	API OpenVINO, устройство и поддержанные форматы (поддержанные модели)
OpenVINO GenAI	Высокоуровневые pipelines поверх OpenVINO, включая Whisper и общий ASR API	OpenVINO IR, pipeline API и согласованные версии компонентов (GenAI PyPI)
ORT Web	Отдельная JavaScript/WebAssembly-поставка ORT для браузера	JS API, WASM runtime и browser EP (обзор ORT Web)

Один ONNX-артефакт можно исполнять обычным ORT CPU EP, передавать его поддержанные подграфы OpenVINO EP или загружать напрямую в OpenVINO. Результат различается по покрытию операторов, квантованию, fallback и производительности (ORT partitioning, OpenVINO EP coverage, чтение ONNX в OpenVINO).

Лестница доказательства

Для каждой пары «модель × устройство × движок» используются пять уровней:

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, 1.27.0, 1.28.0).

Официальные страницы расходятся в обещанном cadence: servicing-документ говорит о full releases примерно раз в квартал, roadmap — о ежемесячных релизах и промежуточных patch-релизах. Публичной LTS/EOL policy нет, поэтому текущий почти месячный темп нельзя считать гарантией (servicing, roadmap, support policy).

С ORT 1.23 новые EP рекомендуется делать отдельными plugins. В 1.24–1.28 API получил prepacking, EP Context, zero-copy I/O, profiling и model packages (инструкция для нового EP, 1.24.1, 1.28.0). Это укрепляет ORT как общий движок, но одновременно отделяет lifecycle конкретного ускорителя от lifecycle ядра.

Нативный OpenVINO и OpenVINO GenAI

OpenVINO публикует несколько регулярных релизов в год. Каждый поддерживается до следующего, а последняя версия года становится LTS: security updates выходят два года либо до двух следующих LTS, исправления новых bugs — один год. Preview-компоненты этой гарантией не покрываются (release notes, release policy).

OpenVINO GenAI — pipeline-библиотека поверх OpenVINO и OpenVINO Tokenizers. Их major.minor.patch должны совпадать; разъезд версий может привести к ABI/import errors. PyPI wheel нельзя смешивать с C++ archive другого ABI (правила совместимости).

Whisper остаётся активным направлением:

• OpenVINO 2026.0 добавил word-level timestamps в WhisperPipeline на CPU, GPU и NPU; 2026.3 добавил язык в результат (2026.0, 2026.3);
• OpenVINO 2026.3 ввёл общий ASRPipeline и Qwen3-ASR, расширив speech API за пределы Whisper (2026.3);
• удалён только ранее deprecated stateless Whisper decoder; рекомендуемый путь использует stateful model (deprecations).

NPU — полноценное устройство OpenVINO, но требует отдельного driver, работает со static shapes, а совместимость compiled blobs между версиями не гарантируется. WhisperPipeline поддерживает NPU, однако целевой Core i5 11-го поколения NPU не имеет: для него OpenVINO означает CPU/iGPU (NPU device, Whisper on NPU, AUTO priority).

Аппаратные пути ORT

Путь	Состояние на 2026-08-12	Практическое следствие
CPU EP	Часть ORT core, production baseline	Самая широкая поставка; аппаратного ускорителя не обещает
DirectML EP	Sustained engineering; feature development перешёл в Windows ML	Поддерживается, но не подходит как новый долгосрочный GPU default (DirectML EP)
Windows ML	Production-поставка ORT для Windows с управляемым каталогом EP	Стратегический Windows-слой, но требует platform-specific bootstrap (deployment)
OpenVINO EP	Активен; deprecated только часть старых provider options	Мост к Intel-ускорению, но готовый wheel отстаёт от ORT/OpenVINO (OpenVINO EP)
MIGraphX EP	Активный AMD-путь; прежний ROCm EP удалён из ORT 1.23	Долгосрочнее ROCm EP, но зависит от ROCm/GPU/OS (ORT 1.23)
CoreML EP	Preview	Доступен в macOS ORT wheel, но требует проверки partitioning (CoreML EP)
Native WebGPU EP	Новый plugin поверх Dawn/D3D12/Vulkan/Metal	Кросс-вендорный кандидат; browser WebGPU использует другой runtime path (WebGPU EP)

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, PyPI, ORT 1.28).

Windows ML не меняет формат модели и не заменяет ORT: runtime содержит onnxruntime.dll, DirectML и Windows ML API. Новый слой добавляет обнаружение устройств, каталог vendor EP, их установку, регистрацию и обновление. DirectML остаётся встроенным legacy EP; MIGraphX, VitisAI, OpenVINO, QNN и NvTensorRtRtx поставляются через каталог или вместе с приложением (обзор, состав runtime, каталог EP).

Python-пакет называется onnxruntime-windowsml. Версия 1.27.1.202607110137 имеет статус Production/Stable, требует Python 3.11+ и публикует cp313 wheels для Windows x86-64 и ARM64 (PyPI). Отдельная ONNX Runtime GenAI Windows ML library 0.x остаётся Preview; её статус не относится к обычному ONNX-инференсу (GenAI Preview).

Для Python поддержан только framework-dependent unpackaged deployment: нужны Windows App SDK Runtime и bootstrap packages. Динамический каталог аппаратных EP требует Windows 11 24H2 build 26100+ (get started, deployment). Приложение должно скачать выбранный EP через ensure_ready_async() и зарегистрировать библиотеку в ORT; EnsureAndRegisterCertifiedAsync() не регистрирует EP в Python environment (инициализация EP).

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, матрица совместимости, ORT 1.26, ORT 1.28).

Следствие: 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). Для сравнения, onnxruntime-directml 1.24.4 ограничен Windows x86-64, а onnxruntime-openvino 1.24.1 — Windows/Linux x86-64 (DirectML files, OpenVINO EP files).

AMD

На AMD x86 CPU поддерживаемая опора — ORT CPU EP. OpenVINO 2026.3 официально перечисляет Intel и ARM/Apple CPU, но не AMD x86; наличие x86 wheel само по себе не является обещанием поддержки AMD (OpenVINO requirements).

Под Windows DirectML поддерживает AMD GCN первого поколения и новее, но его ограниченный lifecycle делает Windows ML + MIGraphX более перспективным путём. Текущий Windows ML MIGraphX требует совместимый GPU/driver и не поддерживает GenAI scenarios; применимость этой формулировки к GigaAM RNN-T не определена и должна проверяться экспериментом (Windows ML EP).

Под 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, MIGraphX PyPI JSON, MIGraphX EP).

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, CoreML EP).

OpenVINO/OpenVINO GenAI имеют cp313-macosx_11_0_arm64 wheels и поддерживают Apple Silicon, но на macOS исполняются только на CPU. GPU plugin рассчитан на Intel GPU, NPU plugin — на Intel NPU (OpenVINO requirements, OpenVINO GenAI files).

Возможности текущих моделей

Таблица применяет одну и ту же лестницу доказательства к трем модельным путям.

Модель и требуемый контракт	Переносимый 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, installation, model card). Но это не доказывает operator coverage или полный offload конкретного E2E RNN-T.

Таймкоды формирует onnx-asr.with_timestamps() из тензорных выходов модели. Если EP сохраняет эти выходы, TimestampedResult должен сохраниться — это вывод, который требует golden test. Mixed precision, graph transforms и CPU fallback могут менять численные результаты (timestamps API, архитектура пакета).

Официальный ONNX helper исходного GigaAM проверяет только text parity и теряет emission frames. Поэтому проверять нужно именно контракт onnx-asr, а не произвольный GigaAM ONNX export (GigaAM, ONNX parity test, ONNX helper).

OpenVINO Whisper

OpenVINO GenAI подтверждает Whisper tiny/base/small/medium/large-v3 и Distil-Whisper. Word timestamps доступны на CPU/GPU/NPU, stateful model обязателен (ASR guide, 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 (разведка).

Официальный sherpa recipe перечисляет PyAnnote с 3D-Speaker или NeMo embeddings, а WeSpeaker публикует собственные ONNX-модели. Поэтому на новом EP нужно отдельно проверять обе сессии и полный pipeline (sherpa models, WeSpeaker models).

Итоговые сегменты создаёт sherpa после двух ONNX-моделей и clustering. Ускорение одной сессии не означает ускорение pipeline; численные изменения эмбеддингов могут изменить кластеры даже при совпадающем текстовом контракте (C API).

Почему 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 выглядит так (матрица):

• 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);
• WebGL находится в maintenance mode.

Один model artifact не означает одинаковую работоспособность. WebGPU имеет отдельную таблицу операторов, а preprocessing и decoding остаются кодом приложения. Большие модели упираются примерно в 2 GB для ArrayBuffer/Protobuf и 4 GB WebAssembly memory; external data нужно загружать отдельно (large models). WASM threading требует crossOriginIsolated; proxy worker несовместим с WebGPU, а dynamic shapes и CPU fallback ограничивают graph capture (environment flags, WebGPU guide).

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, sherpa JS diarization).

Native WebGPU EP также не равен browser WebGPU: Python plugin использует Dawn поверх D3D12/Vulkan/Metal, ORT Web — browser JSEP/WASM path (native WebGPU EP, plugin PyPI 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-путь.

Для текущей карты это даёт два входа:

• «Выбрать единицу привязки спикера к тексту» должен назвать timestamp-aware изменение Backend/TranscribeResult;
• «UX диаризации: флаг, число участников, зависимость и поведение на OpenVINO» должен определить поведение там, где конкретный 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 и опциональных ускорителей?