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

Python 3.13, onnx-asr 0.12 и три модели GigaAM в каталоге #1

New Issue
Closed
opened 2026-08-11 11:19:08 +03:00 by ddmitry · 6 comments
ddmitry commented 2026-08-11 11:19:08 +03:00
Owner
Copy Link
Copy Source

Что строим

Onnx-путь получает три новые поддерживаемые модели — gigaam-multilingual-ctc
для смешанной русско-английской речи и gigaam-v3-e2e-ctc / gigaam-v3-e2e-rnnt
с пунктуацией и нормализацией текста. Заодно проект переезжает на Python 3.13 и
ONNX Runtime 1.28, а версии зависимостей получают верхние границы.

Решения и их обоснования — в спеке docs/specs/onnx-model-catalog.md. Здесь
только порядок работ и приёмка.

Модель по умолчанию не меняется, OpenVINO и CTranslate2 не обновляются.

Порядок работ

Одна ветка feature/…, в master вливается после всех проверок. Внутри ветки —
два шага с контрольной точкой между ними, чтобы при странном поведении было
видно, окружение виновато или новая библиотека.

Шаг 1 — окружение, модели не меняются:

  • requires-python = ">=3.13", добавить .python-version
  • убрать зависимость tomli и условный импорт в пользу tomllib
  • проставить верхние границы по мажорной версии всем прямым зависимостям;
    объявить onnxruntime прямой зависимостью с границей; зафиксировать
    openvino-genai на линии 2026.0; ограничить nvidia-cublas-cu12 мажором
  • переrезолвить lock

Шаг 2 — движок и модели:

  • снять ограничение <0.12.0, поднять onnx-asr до 0.12
  • описать три модели в каталоге бэкенда вместе с опубликованными для них
    квантизациями, passthrough сырых имён сохранить
  • разрешать compute_type с учётом модели: если запрошенной квантизации у
    модели нет, брать доступную и сообщать об этом; значение, заданное
    пользователем в CLI или .transcriber.toml, остаётся ошибкой
  • README и PRD

Приёмка

  • после шага 1 uv run pytest зелёный
  • после шага 1 по одному реальному прогону на onnx, openvino и cuda —
    результат такой же, как до переезда
  • uv.lock содержит onnxruntime 1.28.x; если нет — разобраться, что
    ставит верхнюю границу, а не продавливать пином
  • после шага 2 каждая из трёх моделей и gigaam-v3 как регрессия: модель
    грузится, текст осмысленный, таймкоды на месте, хвост записи не потерян
  • вывод E2E-модели не ломает разбивку на абзацы и не даёт ложных
    предупреждений о потере содержания
  • проверено, принимает ли multilingual-модель подсказку языка; правило
    описано в README
  • README дополнен тремя моделями, версия Python поправлена в PRD

Практика прогона

  • первый запуск качает модели в кэш HF, суммарно порядка гигабайта
  • начинать с короткого фрагмента, особенно для gigaam-v3-e2e-rnnt —
    декодер последовательный, на часовой записи ждать долго
  • скорость мерить на том, что есть, и записывать с указанием CPU; это
    наблюдение, а не приёмка для Intel Core i5
  • macOS остаётся непроверенным: колёса cp313 опубликованы, тестировщика нет

Blocked by

Нет, можно начинать.

## Что строим Onnx-путь получает три новые поддерживаемые модели — `gigaam-multilingual-ctc` для смешанной русско-английской речи и `gigaam-v3-e2e-ctc` / `gigaam-v3-e2e-rnnt` с пунктуацией и нормализацией текста. Заодно проект переезжает на Python 3.13 и ONNX Runtime 1.28, а версии зависимостей получают верхние границы. Решения и их обоснования — в спеке `docs/specs/onnx-model-catalog.md`. Здесь только порядок работ и приёмка. Модель по умолчанию не меняется, OpenVINO и CTranslate2 не обновляются. ## Порядок работ Одна ветка `feature/…`, в `master` вливается после всех проверок. Внутри ветки — два шага с контрольной точкой между ними, чтобы при странном поведении было видно, окружение виновато или новая библиотека. **Шаг 1 — окружение, модели не меняются:** - `requires-python = ">=3.13"`, добавить `.python-version` - убрать зависимость `tomli` и условный импорт в пользу `tomllib` - проставить верхние границы по мажорной версии всем прямым зависимостям; объявить `onnxruntime` прямой зависимостью с границей; зафиксировать `openvino-genai` на линии 2026.0; ограничить `nvidia-cublas-cu12` мажором - переrезолвить lock **Шаг 2 — движок и модели:** - снять ограничение `<0.12.0`, поднять `onnx-asr` до 0.12 - описать три модели в каталоге бэкенда вместе с опубликованными для них квантизациями, passthrough сырых имён сохранить - разрешать `compute_type` с учётом модели: если запрошенной квантизации у модели нет, брать доступную и сообщать об этом; значение, заданное пользователем в CLI или `.transcriber.toml`, остаётся ошибкой - README и PRD ## Приёмка - [ ] после шага 1 `uv run pytest` зелёный - [ ] после шага 1 по одному реальному прогону на onnx, openvino и cuda — результат такой же, как до переезда - [ ] `uv.lock` содержит `onnxruntime` 1.28.x; если нет — разобраться, что ставит верхнюю границу, а не продавливать пином - [ ] после шага 2 каждая из трёх моделей и `gigaam-v3` как регрессия: модель грузится, текст осмысленный, таймкоды на месте, хвост записи не потерян - [ ] вывод E2E-модели не ломает разбивку на абзацы и не даёт ложных предупреждений о потере содержания - [ ] проверено, принимает ли multilingual-модель подсказку языка; правило описано в README - [ ] README дополнен тремя моделями, версия Python поправлена в PRD ## Практика прогона - первый запуск качает модели в кэш HF, суммарно порядка гигабайта - начинать с короткого фрагмента, особенно для `gigaam-v3-e2e-rnnt` — декодер последовательный, на часовой записи ждать долго - скорость мерить на том, что есть, и записывать с указанием CPU; это наблюдение, а не приёмка для Intel Core i5 - macOS остаётся непроверенным: колёса cp313 опубликованы, тестировщика нет ## Blocked by Нет, можно начинать.
ddmitry added the ready-for-human label 2026-08-11 11:19:09 +03:00
ddmitry commented 2026-08-11 14:36:01 +03:00
Author
Owner
Copy Link
Copy Source

Реализация завершена и запушена в feature/onnx-model-catalog.

Коммиты:

  • 3c519c6 — Python 3.13.13, границы зависимостей, tomllib, ONNX Runtime 1.28;
  • 0af2dbd — onnx-asr 0.12, каталог моделей, model-aware compute_type, README/PRD;
  • 7392d72 — защита от некорректных VAD-сегментов и исправления по review.

Автоматическая проверка:

  • uv lock --check — успешно;
  • ограниченный Ruff по затронутым Python-файлам — успешно;
  • uv run pytest -q — 224 passed, 1 skipped.

Ручные прогоны на Windows, AMD Ryzen 7 8845H, запись 14:51:

  • базовые onnx / OpenVINO CPU / FasterWhisper CPU до обновления прошли без потери хвоста;
  • после обновления: gigaam-v3 — 72,6 с; multilingual — 84,8 с; E2E CTC — 72,6 с; E2E RNN-T — 76,1 с;
  • у всех четырёх ONNX-моделей 223 VAD-сегмента, последний таймкод 14:48.41, ложных quality-предупреждений нет;
  • результат gigaam-v3 до/после идентичен, кроме даты транскрипции;
  • E2E-пунктуация не ломает группировку абзацев;
  • multilingual с --language auto и --language ru даёт идентичный текст: языковая подсказка не влияет;
  • явный недоступный --compute-type fp16 корректно завершается ошибкой с вариантами float32, int8.

Проведён независимый review по стандартам и спеке; замечания, доступные на текущей машине, исправлены.

Не закрыто: Linux/CUDA ручная матрица. На текущей машине CUDA отсутствует; в WSL также нет nvidia-smi. До слияния нужен прогон на машине с CUDA либо явное принятие этого риска.

Реализация завершена и запушена в `feature/onnx-model-catalog`. Коммиты: - `3c519c6` — Python 3.13.13, границы зависимостей, `tomllib`, ONNX Runtime 1.28; - `0af2dbd` — onnx-asr 0.12, каталог моделей, model-aware `compute_type`, README/PRD; - `7392d72` — защита от некорректных VAD-сегментов и исправления по review. Автоматическая проверка: - `uv lock --check` — успешно; - ограниченный Ruff по затронутым Python-файлам — успешно; - `uv run pytest -q` — 224 passed, 1 skipped. Ручные прогоны на Windows, AMD Ryzen 7 8845H, запись 14:51: - базовые onnx / OpenVINO CPU / FasterWhisper CPU до обновления прошли без потери хвоста; - после обновления: `gigaam-v3` — 72,6 с; multilingual — 84,8 с; E2E CTC — 72,6 с; E2E RNN-T — 76,1 с; - у всех четырёх ONNX-моделей 223 VAD-сегмента, последний таймкод 14:48.41, ложных quality-предупреждений нет; - результат `gigaam-v3` до/после идентичен, кроме даты транскрипции; - E2E-пунктуация не ломает группировку абзацев; - multilingual с `--language auto` и `--language ru` даёт идентичный текст: языковая подсказка не влияет; - явный недоступный `--compute-type fp16` корректно завершается ошибкой с вариантами `float32, int8`. Проведён независимый review по стандартам и спеке; замечания, доступные на текущей машине, исправлены. Не закрыто: Linux/CUDA ручная матрица. На текущей машине CUDA отсутствует; в WSL также нет `nvidia-smi`. До слияния нужен прогон на машине с CUDA либо явное принятие этого риска.
ddmitry commented 2026-08-11 14:40:48 +03:00
Author
Owner
Copy Link
Copy Source

Дополнение по качеству и скорости — прогоны использованы не только как smoke-проверка.

Внешний сервис взят как неточный ориентир, поэтому WER ниже — относительный сигнал, а не абсолютная истина. Перед сравнением удалены таймкоды/пунктуация, текст приведён к нижнему регистру, ё к е.

Модель Время RTFx WER к внешнему тексту
FasterWhisper medium CPU 1133,9 с* 0,79×* 20,8%
OpenVINO medium 190,6 с 4,67× 23,9%
GigaAM v3 72,6 с 12,27× 26,5%
GigaAM Multilingual CTC 84,8 с 10,51× 27,9%
GigaAM v3 E2E RNN-T 76,1 с 11,71× 29,0%
GigaAM v3 E2E CTC 72,6 с 12,27× 31,8%

* FasterWhisper включает около 263 с первой загрузки модели; оценка самого распознавания — около 871 с / 1,02× RTFx. Для точного cached-замера нужен повтор.

Независимое слепое чтение полных текстов подтвердило общее направление метрик:

  • FasterWhisper medium лучше сохраняет логику разговора и техническую лексику (Teradata, ClickHouse, ETL, legacy, MPP, SAP/BW/HANA, GUI, Apex), но на CPU идёт примерно в реальном времени.
  • OpenVINO medium близок по качеству и заметно быстрее, но иногда локально меняет смысл: около 00:59 «расчёт маржинальности называется» превращается в «расчёт маржинальности не бывает».
  • Обычный gigaam-v3 — лучший быстрый вариант для сырого русского текста: сохраняет почти весь смысл, числа и структуру, но отсутствие пунктуации и фонетические ошибки ухудшают чтение и поиск.
  • Среди быстрых вариантов с пунктуацией E2E RNN-T предпочтительнее E2E CTC: всего на 3,5 с медленнее, но текст устойчивее. Обе E2E-модели чрезмерно дробят живую речь; CTC даёт больше обрывков и ложных границ.
  • Multilingual на почти полностью русской записи медленнее и чуть хуже обычного GigaAM. Эта запись не доказывает её преимущество на mixed RU/EN; для такого вывода нужен материал с существенными английскими фрагментами.

Показательные места: 03:17–04:35 — Whisper-модели яснее передают обсуждение актуальности ТЗ, сайзинга и архитектуры; 06:42–07:39 — обычный GigaAM хорошо сохраняет перечень Teradata + ClickHouse, ETL, витрины SAP BW HANA; 07:52–09:49 — все модели сохраняют страницу 53 и 500 ГБ; 13:26–14:11 — FasterWhisper и OpenVINO буквально распознают Apex, multilingual — кириллическое «апекс».

Длинных автономных галлюцинаций не найдено. Есть локальные потенциально опасные искажения: Иришка, Lutriness, «расчёт маржинальности не бывает», «расчёты по губам», «понюхаю дело». Внешний сервис дополнительно даёт диаризацию двух говорящих; локальные бэкенды её не выполняют, и WER это преимущество не отражает.

Исправление: первоначальная автоматическая проверка искала только кириллическое апекс и ошибочно не засчитала латинское Apex у FasterWhisper и OpenVINO. Вывод выше сверён по полным транскриптам.

Дополнение по качеству и скорости — прогоны использованы не только как smoke-проверка. Внешний сервис взят как неточный ориентир, поэтому WER ниже — относительный сигнал, а не абсолютная истина. Перед сравнением удалены таймкоды/пунктуация, текст приведён к нижнему регистру, `ё` к `е`. | Модель | Время | RTFx | WER к внешнему тексту | |---|---:|---:|---:| | FasterWhisper medium CPU | 1133,9 с* | 0,79×* | **20,8%** | | OpenVINO medium | 190,6 с | 4,67× | **23,9%** | | GigaAM v3 | **72,6 с** | **12,27×** | 26,5% | | GigaAM Multilingual CTC | 84,8 с | 10,51× | 27,9% | | GigaAM v3 E2E RNN-T | 76,1 с | 11,71× | 29,0% | | GigaAM v3 E2E CTC | **72,6 с** | **12,27×** | 31,8% | \* FasterWhisper включает около 263 с первой загрузки модели; оценка самого распознавания — около 871 с / 1,02× RTFx. Для точного cached-замера нужен повтор. Независимое слепое чтение полных текстов подтвердило общее направление метрик: - FasterWhisper medium лучше сохраняет логику разговора и техническую лексику (`Teradata`, `ClickHouse`, `ETL`, `legacy`, `MPP`, `SAP/BW/HANA`, `GUI`, `Apex`), но на CPU идёт примерно в реальном времени. - OpenVINO medium близок по качеству и заметно быстрее, но иногда локально меняет смысл: около 00:59 «расчёт маржинальности называется» превращается в «расчёт маржинальности не бывает». - Обычный `gigaam-v3` — лучший быстрый вариант для сырого русского текста: сохраняет почти весь смысл, числа и структуру, но отсутствие пунктуации и фонетические ошибки ухудшают чтение и поиск. - Среди быстрых вариантов с пунктуацией E2E RNN-T предпочтительнее E2E CTC: всего на 3,5 с медленнее, но текст устойчивее. Обе E2E-модели чрезмерно дробят живую речь; CTC даёт больше обрывков и ложных границ. - Multilingual на почти полностью русской записи медленнее и чуть хуже обычного GigaAM. Эта запись не доказывает её преимущество на mixed RU/EN; для такого вывода нужен материал с существенными английскими фрагментами. Показательные места: 03:17–04:35 — Whisper-модели яснее передают обсуждение актуальности ТЗ, сайзинга и архитектуры; 06:42–07:39 — обычный GigaAM хорошо сохраняет перечень `Teradata + ClickHouse`, `ETL`, витрины `SAP BW HANA`; 07:52–09:49 — все модели сохраняют страницу 53 и 500 ГБ; 13:26–14:11 — FasterWhisper и OpenVINO буквально распознают `Apex`, multilingual — кириллическое «апекс». Длинных автономных галлюцинаций не найдено. Есть локальные потенциально опасные искажения: `Иришка`, `Lutriness`, «расчёт маржинальности не бывает», «расчёты по губам», «понюхаю дело». Внешний сервис дополнительно даёт диаризацию двух говорящих; локальные бэкенды её не выполняют, и WER это преимущество не отражает. Исправление: первоначальная автоматическая проверка искала только кириллическое `апекс` и ошибочно не засчитала латинское `Apex` у FasterWhisper и OpenVINO. Вывод выше сверён по полным транскриптам.
ddmitry commented 2026-08-11 15:48:12 +03:00
Author
Owner
Copy Link
Copy Source

Расширенный benchmark завершён и зафиксирован в коммите f0d7d06.

К исходной BDMA-записи добавлены две разрешённые записи с полными внешними транскриптами:

  • RSQM, внутренний дейлик — 14:04, пять говорящих;
  • DataCat, обсуждение архитектуры — 14:42, три говорящих и плотная IT-лексика.

Итого: три записи, 43:37 аудио, десять новых cached-прогонов. Все модели дошли до конца без предупреждений о потере хвоста или повторах.

Модель Суммарное время RTFx WER к внешним текстам
FasterWhisper medium CPU 2511,6 с* 1,04× 20,9%
GigaAM v3 222,5 с 11,76× 26,0%
GigaAM v3 E2E RNN-T 226,9 с 11,54× 26,9%
GigaAM Multilingual CTC 261,7 с 10,00× 26,9%
GigaAM v3 E2E CTC 219,7 с 11,91× 29,3%

* Для первого файла FasterWhisper использована оценка чистого inference без первичной загрузки; два новых файла измерены на прогретом кеше.

Итоговая рекомендация:

  • gigaam-v3-e2e-rnnt — лучший профиль цена/качество для готового читаемого текста: всего на 2% медленнее обычного GigaAM, но с пунктуацией;
  • gigaam-v3 — для наиболее точного сырого текста и последующего постпроцессинга;
  • FasterWhisper medium — для важных терминологически плотных записей, если допустима обработка около realtime;
  • multilingual и E2E CTC преимуществ на этом наборе не показали. E2E CTC также создаёт смешанные артефакты вроде иnженter, мetднные, оrкl.

WER остаётся относительным сигналом: внешние транскрипты сами содержат ошибки и редактируют разговорную речь. Вывод дополнительно проверен чтением одинаковых технических и action-item фрагментов.

Полная методика, per-file таблицы и качественные примеры: benchmark GigaAM и Whisper.

Расширенный benchmark завершён и зафиксирован в коммите `f0d7d06`. К исходной BDMA-записи добавлены две разрешённые записи с полными внешними транскриптами: - RSQM, внутренний дейлик — 14:04, пять говорящих; - DataCat, обсуждение архитектуры — 14:42, три говорящих и плотная IT-лексика. Итого: три записи, 43:37 аудио, десять новых cached-прогонов. Все модели дошли до конца без предупреждений о потере хвоста или повторах. | Модель | Суммарное время | RTFx | WER к внешним текстам | |---|---:|---:|---:| | FasterWhisper medium CPU | 2511,6 с* | 1,04× | **20,9%** | | GigaAM v3 | 222,5 с | 11,76× | **26,0%** | | GigaAM v3 E2E RNN-T | 226,9 с | 11,54× | 26,9% | | GigaAM Multilingual CTC | 261,7 с | 10,00× | 26,9% | | GigaAM v3 E2E CTC | **219,7 с** | **11,91×** | 29,3% | \* Для первого файла FasterWhisper использована оценка чистого inference без первичной загрузки; два новых файла измерены на прогретом кеше. Итоговая рекомендация: - `gigaam-v3-e2e-rnnt` — лучший профиль цена/качество для готового читаемого текста: всего на 2% медленнее обычного GigaAM, но с пунктуацией; - `gigaam-v3` — для наиболее точного сырого текста и последующего постпроцессинга; - FasterWhisper medium — для важных терминологически плотных записей, если допустима обработка около realtime; - multilingual и E2E CTC преимуществ на этом наборе не показали. E2E CTC также создаёт смешанные артефакты вроде `иnженter`, `мetднные`, `оrкl`. WER остаётся относительным сигналом: внешние транскрипты сами содержат ошибки и редактируют разговорную речь. Вывод дополнительно проверен чтением одинаковых технических и action-item фрагментов. Полная методика, per-file таблицы и качественные примеры: [benchmark GigaAM и Whisper](https://git.dementev.space/ddmitry/local-transcriber/src/branch/feature/onnx-model-catalog/docs/benchmarks/2026-08-11-gigaam-model-comparison.md).
ddmitry commented 2026-08-11 16:48:19 +03:00
Author
Owner
Copy Link
Copy Source

Дополнение: GigaAM Multilingual Large и Parakeet v3

На том же наборе из трёх записей (43:37) выполнены cached-прогоны
gigaam-multilingual-large-ctc и parakeet-v3, CPU/int8, язык ru.

Модель Время RTFx WER Удаления Пунктуация / 1000 слов
GigaAM Multilingual Large CTC 545,0 с 4,80× 26,2% 103 0
Parakeet v3 345,6 с 7,57× 28,3% 264 301

Large точнее на всех трёх записях. Parakeet в 1,58 раза быстрее и ставит
пунктуацию, но при ручном чтении часто переключает русские реплики в ложный
английский (Just die, What foo, Skid of all) и заметно чаще теряет слова.
Для этого массива Large предпочтительнее по качеству; Parakeet требует ручной
проверки и не рекомендуется как основной профиль русских встреч.

Large добавлена в каталог алиасов. Точные имена трёх видео и эталонов, размеры
и SHA-256 сохранены в benchmark-документе, чтобы повторять тест на тех же
файлах ноутбука.

По итогам обсуждения потребителей транскрипта
gigaam-v3-e2e-rnnt выбрана моделью по умолчанию для явного
--device onnx: она всего на 2% медленнее сырого gigaam-v3, но содержит
пунктуацию для тех, кто читает результат напрямую. gigaam-v3 сохранена как
явный профиль для LLM-пайплайнов с приоритетом дословной точности. Auto-detect
не менялся.

Коммиты:

  • 8f85930 feat(onnx): добавлена модель GigaAM Multilingual Large
  • a06dbe6 docs(benchmark): сравнены GigaAM Large и Parakeet
  • 7f58a56 feat(onnx): изменена модель по умолчанию на GigaAM RNN-T

Проверка: 226 passed, 1 skipped; независимые Standards и Spec review — без
оставшихся находок.

## Дополнение: GigaAM Multilingual Large и Parakeet v3 На том же наборе из трёх записей (43:37) выполнены cached-прогоны `gigaam-multilingual-large-ctc` и `parakeet-v3`, CPU/int8, язык `ru`. | Модель | Время | RTFx | WER | Удаления | Пунктуация / 1000 слов | |---|---:|---:|---:|---:|---:| | GigaAM Multilingual Large CTC | 545,0 с | 4,80× | **26,2%** | **103** | 0 | | Parakeet v3 | **345,6 с** | **7,57×** | 28,3% | 264 | 301 | Large точнее на всех трёх записях. Parakeet в 1,58 раза быстрее и ставит пунктуацию, но при ручном чтении часто переключает русские реплики в ложный английский (`Just die`, `What foo`, `Skid of all`) и заметно чаще теряет слова. Для этого массива Large предпочтительнее по качеству; Parakeet требует ручной проверки и не рекомендуется как основной профиль русских встреч. Large добавлена в каталог алиасов. Точные имена трёх видео и эталонов, размеры и SHA-256 сохранены в benchmark-документе, чтобы повторять тест на тех же файлах ноутбука. По итогам обсуждения потребителей транскрипта `gigaam-v3-e2e-rnnt` выбрана моделью по умолчанию для явного `--device onnx`: она всего на 2% медленнее сырого `gigaam-v3`, но содержит пунктуацию для тех, кто читает результат напрямую. `gigaam-v3` сохранена как явный профиль для LLM-пайплайнов с приоритетом дословной точности. Auto-detect не менялся. Коммиты: - `8f85930 feat(onnx): добавлена модель GigaAM Multilingual Large` - `a06dbe6 docs(benchmark): сравнены GigaAM Large и Parakeet` - `7f58a56 feat(onnx): изменена модель по умолчанию на GigaAM RNN-T` Проверка: `226 passed, 1 skipped`; независимые Standards и Spec review — без оставшихся находок.
ddmitry commented 2026-08-11 17:08:28 +03:00
Author
Owner
Copy Link
Copy Source

Оставшаяся приёмка на ноутбуке с RTX 3060

Кодовая часть задачи завершена и находится в ветке
feature/onnx-model-catalog. До слияния остаётся проверить стабильность на
реальной NVIDIA GPU и закрыть Linux/WSL-часть матрицы.

Windows

  • Выполнить uv sync и полный uv run pytest -q.
  • Сделать холодный и повторный CUDA-прогон записи BDMA.
  • Сделать пакетный CUDA-прогон трёх записей из benchmark-манифеста.
  • Проверить фактическое использование GPU, расход VRAM, отсутствие
    CUDA/OOM-предупреждений, повторов и потери хвоста.
  • Сверить последние таймкоды и сопоставимость результатов холодного и
    прогретого запусков.

WSL2

  • Убедиться, что nvidia-smi видит RTX 3060.
  • Выполнить uv sync и полный uv run pytest -q.
  • Повторить холодный и прогретый CUDA-прогон BDMA, проверив Linux CUDA
    bootstrap.
  • На одной полной записи проверить ONNX с моделью по умолчанию
    gigaam-v3-e2e-rnnt и OpenVINO, чтобы закрыть Linux-часть матрицы.

Что записать в результат

  • модель GPU и объём VRAM;
  • версии драйвера, WSL, Python и ключевых runtime-зависимостей;
  • время холодного и прогретого запусков;
  • фактическое устройство, предупреждения и последний таймкод каждого прогона;
  • любые расхождения Windows и WSL.

Если матрица зелёная, результаты фиксируются в документации, ветка сливается в
master, задача закрывается. Если какой-либо путь нестабилен, исправление
делается в текущей ветке с повтором только провалившегося участка.

Точные имена, размеры и SHA-256 трёх разрешённых записей уже сохранены в
docs/benchmarks/2026-08-11-gigaam-model-comparison.md.

Отдельная задача #2 про необязательную установку CUDA runtime остаётся в
needs-triage и не блокирует эту приёмку.

## Оставшаяся приёмка на ноутбуке с RTX 3060 Кодовая часть задачи завершена и находится в ветке `feature/onnx-model-catalog`. До слияния остаётся проверить стабильность на реальной NVIDIA GPU и закрыть Linux/WSL-часть матрицы. ### Windows - [ ] Выполнить `uv sync` и полный `uv run pytest -q`. - [ ] Сделать холодный и повторный CUDA-прогон записи BDMA. - [ ] Сделать пакетный CUDA-прогон трёх записей из benchmark-манифеста. - [ ] Проверить фактическое использование GPU, расход VRAM, отсутствие CUDA/OOM-предупреждений, повторов и потери хвоста. - [ ] Сверить последние таймкоды и сопоставимость результатов холодного и прогретого запусков. ### WSL2 - [ ] Убедиться, что `nvidia-smi` видит RTX 3060. - [ ] Выполнить `uv sync` и полный `uv run pytest -q`. - [ ] Повторить холодный и прогретый CUDA-прогон BDMA, проверив Linux CUDA bootstrap. - [ ] На одной полной записи проверить ONNX с моделью по умолчанию `gigaam-v3-e2e-rnnt` и OpenVINO, чтобы закрыть Linux-часть матрицы. ### Что записать в результат - модель GPU и объём VRAM; - версии драйвера, WSL, Python и ключевых runtime-зависимостей; - время холодного и прогретого запусков; - фактическое устройство, предупреждения и последний таймкод каждого прогона; - любые расхождения Windows и WSL. Если матрица зелёная, результаты фиксируются в документации, ветка сливается в `master`, задача закрывается. Если какой-либо путь нестабилен, исправление делается в текущей ветке с повтором только провалившегося участка. Точные имена, размеры и SHA-256 трёх разрешённых записей уже сохранены в `docs/benchmarks/2026-08-11-gigaam-model-comparison.md`. Отдельная задача #2 про необязательную установку CUDA runtime остаётся в `needs-triage` и не блокирует эту приёмку.
ddmitry commented 2026-08-11 21:51:20 +03:00
Author
Owner
Copy Link
Copy Source

Финальная приёмка Windows и WSL2 завершена

Проверка выполнена на NVIDIA GeForce RTX 3060 Laptop GPU 6 ГиБ, драйвере 610.88 и CUDA Toolkit 12.9. Для финальной матрицы взяты три другие доступные записи из C:\Users\ddmitry\Videos\OBS длительностью 15:52, 22:27 и 24:04: файлов BDMA, RSQM и DataCat из benchmark-манифеста в каталоге не было.

Найденное и исправленное

На CTranslate2 4.7.1 длинный Windows/CUDA-пакет полностью обрабатывал три записи, но при освобождении ресурсов процесс стабильно завершался кодом 0xC0000409. Сбой воспроизведён три раза, в том числе после обновления драйвера с 610.47 до 610.88.

A/B-проверка с единственным изменением зависимости показала:

  • CTranslate2 4.7.1 — 0xC0000409;
  • CTranslate2 4.8.1 — код 0 на том же наборе.

Версия обновлена в uv.lock, коммит 6f2dbf8.

Автоматическая проверка

  • uv lock --check — успешно;
  • Windows — 226 passed, 1 skipped;
  • WSL2 — 226 passed, 1 skipped.

Ручная матрица

Windows:

  • одиночные CUDA-прогоны записи 15:52: 51,7 с и 47,7 с, результаты совпали кроме даты;
  • пиковая загрузка GPU 100%, расход до 4,3 ГиБ;
  • пакет из трёх записей после обновления CTranslate2: 212,9 с, код 0, 0 ошибок.

WSL2:

  • RTX 3060 и драйвер 610.88 доступны через nvidia-smi;
  • Linux CUDA bootstrap успешно загрузил nvidia-cublas-cu12 12.9.1.4;
  • CUDA/medium/float16: 62,6 с, код 0;
  • ONNX/gigaam-v3-e2e-rnnt/int8: 81,8 с, код 0;
  • OpenVINO CPU/medium/int8: 210,9 с, код 0.

Предупреждений CUDA/OOM, повторов и потери хвоста нет. В WSL/CUDA воспроизводится дополнительная короткая фраза на шумном хвосте 15:47–15:51, которой нет в Windows/CUDA, ONNX и OpenVINO; это зафиксировано как межплатформенное качественное расхождение, на стабильность обработки не влияет.

Pull request: #3

## Финальная приёмка Windows и WSL2 завершена Проверка выполнена на NVIDIA GeForce RTX 3060 Laptop GPU 6 ГиБ, драйвере 610.88 и CUDA Toolkit 12.9. Для финальной матрицы взяты три другие доступные записи из `C:\Users\ddmitry\Videos\OBS` длительностью 15:52, 22:27 и 24:04: файлов BDMA, RSQM и DataCat из benchmark-манифеста в каталоге не было. ### Найденное и исправленное На CTranslate2 4.7.1 длинный Windows/CUDA-пакет полностью обрабатывал три записи, но при освобождении ресурсов процесс стабильно завершался кодом `0xC0000409`. Сбой воспроизведён три раза, в том числе после обновления драйвера с 610.47 до 610.88. A/B-проверка с единственным изменением зависимости показала: - CTranslate2 4.7.1 — `0xC0000409`; - CTranslate2 4.8.1 — код `0` на том же наборе. Версия обновлена в `uv.lock`, коммит `6f2dbf8`. ### Автоматическая проверка - `uv lock --check` — успешно; - Windows — `226 passed, 1 skipped`; - WSL2 — `226 passed, 1 skipped`. ### Ручная матрица Windows: - одиночные CUDA-прогоны записи 15:52: 51,7 с и 47,7 с, результаты совпали кроме даты; - пиковая загрузка GPU 100%, расход до 4,3 ГиБ; - пакет из трёх записей после обновления CTranslate2: 212,9 с, код `0`, 0 ошибок. WSL2: - RTX 3060 и драйвер 610.88 доступны через `nvidia-smi`; - Linux CUDA bootstrap успешно загрузил `nvidia-cublas-cu12` 12.9.1.4; - CUDA/medium/float16: 62,6 с, код `0`; - ONNX/gigaam-v3-e2e-rnnt/int8: 81,8 с, код `0`; - OpenVINO CPU/medium/int8: 210,9 с, код `0`. Предупреждений CUDA/OOM, повторов и потери хвоста нет. В WSL/CUDA воспроизводится дополнительная короткая фраза на шумном хвосте 15:47–15:51, которой нет в Windows/CUDA, ONNX и OpenVINO; это зафиксировано как межплатформенное качественное расхождение, на стабильность обработки не влияет. Pull request: https://git.dementev.space/ddmitry/local-transcriber/pulls/3
ddmitry added ready-for-agent and removed ready-for-human labels 2026-08-12 12:54:08 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
needs-info
Ожидает дополнительной информации от автора
 needs-triage
Требует оценки сопровождающим
 ready-for-agent
Полностью описана и готова для автономного агента
 ready-for-human
Требует реализации человеком
 wayfinder:grilling
Тикет карты: решение через разговор по одному вопросу (HITL)
 wayfinder:map
Карта wayfinder: индекс решений и точка входа
 wayfinder:prototype
Тикет карты: дешёвый черновик, чтобы было на что реагировать (HITL)
 wayfinder:research
Тикет карты: чтение источников, итог — markdown-сводка (AFK)
 wayfinder:task
Тикет карты: ручная работа, разблокирующая решение
 wontfix
Выполняться не будет
No labels ready-for-agent
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ddmitry/local-transcriber#1