Углубить module выполнения транскрипции для развития ONNX #56

Closed
opened 2026-09-21 21:58:26 +03:00 by ddmitry · 2 comments
Owner

Проблема и результат

CLI согласует model, backend, model_path, actual_device и переносит их между файлами после fallback. Для ONNX выбранные настройки живут отдельно от загруженной модели, а принятый cpu_threads не применяется. Это затрудняет развитие поддерживаемых моделей и вариантов исполнения.

Нужен deep module выполнения распознавания: один владелец согласованного состояния на запуск, один external interface для одиночного файла и батча. CLI получает результат и сведения о выполнении, без внутренних handles и ручного переноса состояния.

Согласованная спецификация — источник решений и полной матрицы поведения. Реализовывать после #2: CUDA и автоматический ONNX CPU уже должны иметь определённую политику.

Объём

  • Различить внутри module модель, движок распознавания и способ исполнения; сохранить действующие CLI/TOML значения. Конкретные имена типов выбираются при реализации.
  • Скрыть загрузку, переиспользование, фактические настройки и разрешённые переходы исполнения. Подготовка после prescan и проверка возможностей перед первым ASR сохраняются.
  • Перевести single/batch callers и публичный путь transcribe на один interface; сохранить прогресс, прерывание и семантику ошибок. Backend остаётся internal seam с существующими adapters.
  • Оставить каталог ONNX, VAD, квантизацию и нормализацию результата внутри ONNX adapter; применять бюджет CPU-потоков к ASR и VAD через поддерживаемые настройки библиотеки. Значение 0 сохраняет её настройки потоков.
  • Выдавать согласованные сведения о запрошенном и выбранном исполнении, модели, квантизации и потоках. В --verbose показывать нужные для удалённой диагностики версии runtime/providers. Наличие provider не называть доказательством выполнения графа на GPU/NPU.
  • Перенести основные сценарные тесты на external interface при работающей оркестрации и подменённых внешних движках; убрать ставшие лишними проверки передачи полей, сохранив проверки поведения adapters.
  • Обновить ADR-002/003 и пользовательское описание диагностики; не возвращать политику автоматической CUDA, устранённую в #2.

Критерии приёмки

  • CLI больше не читает и не переносит backend/model/path между файлами; одиночный файл и батч используют один module выполнения.
  • Пустой prescan не загружает модели; два файла переиспользуют одну загрузку. Подготовка включённой диаризации по-прежнему завершается до первого ASR.
  • Добавление каталожной ONNX-модели не требует правок CLI; фактическая квантизация соответствует явному/неявному выбору.
  • Настройки потоков получают и ASR, и VAD; параметр перестаёт быть молча игнорируемым.
  • Разрешённый fallback оставляет согласованное состояние для следующего файла; обычная ошибка файла не повреждает продолжение батча. Явный strict-выбор и политика #2 сохраняются.
  • Сведения об исполнении основаны на данных module, а не догадке CLI по строке device; не обещают аппаратное ускорение без доказательства.
  • Сохраняются CPU/OpenVINO-пути, публичный путь одного файла, временная шкала и порядок слов, форматирование, прогресс и прерывание. Ошибка диаризации сохраняет обычный транскрипт, а батч продолжает остальные файлы с прежним итоговым статусом.
  • Пройдены сценарные проверки через external interface, относящиеся тесты adapters и uv run pytest; реальные модели для автоматических проверок не загружаются.

Границы и коммиты

Одна задача, несколько связных коммитов: module выполнения; переход callers; настройки/диагностика ONNX; проверки и документация. Это ориентир группировки, не отдельные обязательные тикеты; каждый коммит должен оставлять рабочее состояние.

Вне задачи: исправление качества диаризации (см. #54/#55), возобновление обработки, новый универсальный каталог возможностей, иерархия providers, внедрение CoreML/Windows ML. Сведения о совместимости на Mac не выводить из mock-тестов.

## Проблема и результат CLI согласует `model`, `backend`, `model_path`, `actual_device` и переносит их между файлами после fallback. Для ONNX выбранные настройки живут отдельно от загруженной модели, а принятый `cpu_threads` не применяется. Это затрудняет развитие поддерживаемых моделей и вариантов исполнения. Нужен deep module выполнения распознавания: один владелец согласованного состояния на запуск, один external interface для одиночного файла и батча. CLI получает результат и сведения о выполнении, без внутренних handles и ручного переноса состояния. [Согласованная спецификация](https://git.dementev.space/ddmitry/local-transcriber/src/commit/2b54f5bc9ea71ea5056cb32534330e0295c51f9b/docs/specs/2026-09-21-transcription-execution.md) — источник решений и полной матрицы поведения. Реализовывать после #2: CUDA и автоматический ONNX CPU уже должны иметь определённую политику. ## Объём - Различить внутри module модель, движок распознавания и способ исполнения; сохранить действующие CLI/TOML значения. Конкретные имена типов выбираются при реализации. - Скрыть загрузку, переиспользование, фактические настройки и разрешённые переходы исполнения. Подготовка после prescan и проверка возможностей перед первым ASR сохраняются. - Перевести single/batch callers и публичный путь `transcribe` на один interface; сохранить прогресс, прерывание и семантику ошибок. Backend остаётся internal seam с существующими adapters. - Оставить каталог ONNX, VAD, квантизацию и нормализацию результата внутри ONNX adapter; применять бюджет CPU-потоков к ASR и VAD через поддерживаемые настройки библиотеки. Значение 0 сохраняет её настройки потоков. - Выдавать согласованные сведения о запрошенном и выбранном исполнении, модели, квантизации и потоках. В `--verbose` показывать нужные для удалённой диагностики версии runtime/providers. Наличие provider не называть доказательством выполнения графа на GPU/NPU. - Перенести основные сценарные тесты на external interface при работающей оркестрации и подменённых внешних движках; убрать ставшие лишними проверки передачи полей, сохранив проверки поведения adapters. - Обновить ADR-002/003 и пользовательское описание диагностики; не возвращать политику автоматической CUDA, устранённую в #2. ## Критерии приёмки - [x] CLI больше не читает и не переносит backend/model/path между файлами; одиночный файл и батч используют один module выполнения. - [x] Пустой prescan не загружает модели; два файла переиспользуют одну загрузку. Подготовка включённой диаризации по-прежнему завершается до первого ASR. - [x] Добавление каталожной ONNX-модели не требует правок CLI; фактическая квантизация соответствует явному/неявному выбору. - [x] Настройки потоков получают и ASR, и VAD; параметр перестаёт быть молча игнорируемым. - [x] Разрешённый fallback оставляет согласованное состояние для следующего файла; обычная ошибка файла не повреждает продолжение батча. Явный strict-выбор и политика #2 сохраняются. - [x] Сведения об исполнении основаны на данных module, а не догадке CLI по строке device; не обещают аппаратное ускорение без доказательства. - [x] Сохраняются CPU/OpenVINO-пути, публичный путь одного файла, временная шкала и порядок слов, форматирование, прогресс и прерывание. Ошибка диаризации сохраняет обычный транскрипт, а батч продолжает остальные файлы с прежним итоговым статусом. - [x] Пройдены сценарные проверки через external interface, относящиеся тесты adapters и `uv run pytest`; реальные модели для автоматических проверок не загружаются. ## Границы и коммиты Одна задача, несколько связных коммитов: module выполнения; переход callers; настройки/диагностика ONNX; проверки и документация. Это ориентир группировки, не отдельные обязательные тикеты; каждый коммит должен оставлять рабочее состояние. Вне задачи: исправление качества диаризации (см. #54/#55), возобновление обработки, новый универсальный каталог возможностей, иерархия providers, внедрение CoreML/Windows ML. Сведения о совместимости на Mac не выводить из mock-тестов.
ddmitry added the ready-for-agent label 2026-09-21 21:58:26 +03:00
Author
Owner

Реализация в PR #58: Transcriber как единственный владелец выполнения, бюджет потоков ONNX для ASR и VAD, диагностика в --verbose. Критерии приёмки отмечены; заметка с находками двух слепых ревью и решениями по ним — в описании PR.

Реализация в PR #58: `Transcriber` как единственный владелец выполнения, бюджет потоков ONNX для ASR и VAD, диагностика в `--verbose`. Критерии приёмки отмечены; заметка с находками двух слепых ревью и решениями по ним — в описании PR.
Author
Owner

Живой прогон финального HEAD 63307fe перед merge (ONNX CPU, --verbose --threads 4, батч из двух записей по ~15 мин из tmp/transcriber-model-comparison):

Файл Сегментов Время
RSQM дейлик (14:05) 231 125 с
BDMA уточнение (14:50) 223 ~143 с
  • Итого 268 с на 29.6 мин звука, RTF ≈ 0.15; user 18m28s при real 4m31s — четыре ядра загружены, как запрошено.
  • Модель инициализирована один раз на батч; второй файл переиспользовал загрузку.
  • --verbose печатает Потоки (запрошено): 4, onnxruntime 1.28.0 / onnx_asr 0.12.0, providers ASR и VAD раздельно, intra_op_threads: 4.
  • Шапка транскрипта: «Устройство: ONNX (CPU)» из данных module. Exit 0, Итого: 2 обработано, 0 ошибок.
  • uv run pytest -q — 535 passed, 2 skipped. ruff: 28 находок против 34 на master, новых нет.

Не проверялись вживую (только тесты с подменёнными движками): --diarize, OpenVINO, CUDA.

Справка по потокам: при --threads 0 onnxruntime сам создаёт потоки по числу физических ядер с привязкой к ним; явное значение фиксирует число и отключает привязку (threading).

Живой прогон финального HEAD `63307fe` перед merge (ONNX CPU, `--verbose --threads 4`, батч из двух записей по ~15 мин из `tmp/transcriber-model-comparison`): | Файл | Сегментов | Время | |---|---|---| | RSQM дейлик (14:05) | 231 | 125 с | | BDMA уточнение (14:50) | 223 | ~143 с | - Итого 268 с на 29.6 мин звука, RTF ≈ 0.15; `user 18m28s` при `real 4m31s` — четыре ядра загружены, как запрошено. - Модель инициализирована один раз на батч; второй файл переиспользовал загрузку. - `--verbose` печатает `Потоки (запрошено): 4`, onnxruntime 1.28.0 / onnx_asr 0.12.0, providers ASR и VAD раздельно, `intra_op_threads: 4`. - Шапка транскрипта: «Устройство: ONNX (CPU)» из данных module. Exit 0, `Итого: 2 обработано, 0 ошибок`. - `uv run pytest -q` — 535 passed, 2 skipped. ruff: 28 находок против 34 на master, новых нет. Не проверялись вживую (только тесты с подменёнными движками): `--diarize`, OpenVINO, CUDA. Справка по потокам: при `--threads 0` onnxruntime сам создаёт потоки по числу физических ядер с привязкой к ним; явное значение фиксирует число и отключает привязку ([threading](https://onnxruntime.ai/docs/performance/tune-performance/threading.html)).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: ddmitry/local-transcriber#56