Я ошибался: бенчмарк 23 ASR-нейросетей для русской айтишной диктовки
23 модели в 60+ конфигурациях, больше 100 000 прогонов на русско-английском IT-корпусе — пять суток (120+ часов) чистого инференса на одной RTX 5070 Ti. В марте я рекомендовал Whisper Large v3, а потом случайно нашёл модель не хуже — и понял, что выбор держался на инерции. Пересобрал всё по-научному, и мартовская рекомендация устарела. Кто её сместил — дальше.
В марте я написал статью про voice-to-text и пришёл к рекомендации: Whisper Large v3 + кастомный промпт на пунктуацию через свой форк Handy на Vulkan-ускорении (которое, к моему удивлению, оказалось быстрее CUDA — про это я тоже писал).
В Handy в списке поддерживаемых моделей я заметил странную опцию — breeze-asr с пометкой «Optimized for Taiwanese Mandarin. Code-switching support». Зачем нишевый мандарин-английский fine-tune вообще положили в набор моделей по умолчанию — непонятно. Из любопытства переключился. Поработал день в обычном режиме (я диктую LLM больше часа в день для общения и заметок). И обнаружил: качество не хуже Whisper Large v3. Может, даже лучше.
Об этом я написал короткий пост в Telegram — что вот, странная находка, надо разбираться. И начал разбираться.
Несколько недель и один Frankenstein-fork в три уровня глубиной. Дальше — что я нашёл и почему мартовская рекомендация теперь устарела.
(5 суток)
Один тест-набор, одна видеокарта RTX 5070 Ti — все модели в одинаковых условиях.
Так нельзя сравнивать модели
Тут важная оговорка: мартовская статья вообще не задумывалась как бенчмарк. Я искал лучший инструмент под себя, нашёл — и просто поделился находками. Метод был честным по факту, но не по науке: переключал модель в Handy, диктовал день в обычном рабочем режиме, через неделю говорил «эта получше» или «эта хуже». Это нормальный способ выбрать инструмент для себя — но не бенчмарк. Сравнения «по ощущениям» от ежедневной диктовки разваливаются сразу на трёх вещах:
- Эффект памяти. Я помню последние странные ошибки модели X лучше, чем такие же ошибки модели Y две недели назад.
- Эффект адаптации. За неделю я подстраиваю темп речи и формулировки под текущую модель. Реальные различия между моделями смазываются — я просто притираюсь к каждой.
- Разное аудио. Каждую модель я гонял на своих свежих надиктовках — то есть сравнивал разные модели на разном материале. Общего эталона, на котором их можно поставить рядом, не было вообще.
И когда случайный эксперимент с Breeze показал, что есть как минимум одна модель, не уступающая Whisper Large, — стало ясно: моя мартовская рекомендация держалась на инерции, а не на реальном сравнении.
Что из мартовской статьи остаётся актуальным:
- Обзор приложений (OpenWhispr, Handy, WisprFlow, SuperWhisper) — UX, фичи, проблемы.
- Цены на подписки и приложения.
- Концепт кастомного промпта на пунктуацию — работает. Более того, в этот раз я реально измерил его эффект и сильно углубил эту часть: протестировал несколько версий пунктуационного промпта (разбор — ниже).
Что меняется:
- Рекомендация по модели. Полностью. В мартовской статье поставлю ссылку на эту — выводы по модели читайте здесь.
Что мы вообще хотим от STT
Перед сравнением — договоримся, чего мы вообще ждём от модели. (И сразу про термины: ASR, STT, voice-to-text — это одно и то же, распознавание речи. Дальше я использую их как синонимы.)
Первое — чтобы модель понимала слова. Это самое очевидное, и тут классическая метрика WER (word error rate) работает: считаем долю слов, которые отличаются от эталона.
Второе — чтобы модель ставила знаки препинания. Особенно это важно на длинной диктовке. Попробуйте продиктовать что-то длинное во встроенную диктовку iPhone на русском — получите простыню одной строкой: без точек, без запятых, всё со строчной буквы. Пользоваться таким текстом потом неудобно: тяжело читать, тяжело редактировать. И тяжело скормить LLM — без знаков препинания она хуже понимает, где кончается одна мысль и начинается другая, путает границы предложений и смысловые группы. Чем длиннее простыня — тем сильнее LLM на ней плывёт. Встроенная диктовка iPhone вообще-то умеет расставлять знаки препинания — но только для горстки языков (английский, испанский, китайский и ещё несколько), а русского среди них нет. Так что на русском вы и получаете эту простыню. Часть моделей в моём бенчмарке тоже не ставит — их транскрипция приходит в точно таком же виде, одной слитной строкой, и при беглом сравнении с эталоном это заметно с первого взгляда.
Третье — сохранять английские термины латиницей (для нашего конкретного use case). Тут потребуется чуть больше объяснений.
Почему важна латиница в английских терминах
Сначала — откуда вообще в речи берётся латиница. Я диктую ровно так, как айтишники говорят между собой: русская фраза с английскими словами внутри — «задеплой feature в production», «смёржи branch», «прокинь параметр в config». На лингвистическом жаргоне это и называется code-switching — переключение между языками внутри одной фразы; дальше термин встретится часто. Иногда вообще хочется сказать «смотря какой fabric, смотря сколько details» — и хочется модель, которая понимает тебя в такие моменты. То есть: услышала английский термин — пишет его латиницей, а не угадывает кириллицей.
Транскрипция в нашем сценарии — это не самоцель. Это корм для LLM в виде промптов и заметок.
Современные LLM знают, что русское «гитхаб» и английское github — одно и то же. В большинстве случаев они справятся. Но есть нюанс: токенизация в LLM работает на уровне сабсловов, не понятий. У большинства актуальных токенизаторов (cl100k_base в GPT-4, токенизаторы Claude) английское GitHub кодируется одним-двумя токенами, русское «гитхаб» — четырьмя-пятью. На новых tokenizer’ах OpenAI (o200k_base в GPT-4o) русский кодируется чуть плотнее (~2–3 токена на «гитхаб»), но дисбаланс с английским всё равно остаётся. Латинская форма для модели экономнее по контексту, точнее по соответствию официальным названиям и техническим ссылкам, надёжнее в долгих промптах.
Это не критично — никакой катастрофы не случится, если в вашем промпте будут «гитхаб» и «клод» вместо GitHub и Claude. Но если транскрипция сохраняет латиницу там, где спикер сказал английское слово — это желаемое поведение для рассматриваемого кейса. Мы это поведение в бенчмарке вознаграждаем.
Метрику для этого я назвал EPI (English Preservation Index). Идея простая: для каждого английского термина в эталоне модель может выдать одну из нескольких форм, и они стоят по-разному.
- Каноническая английская форма (
GitHub) — 1.0, максимум. - Частично удержанный многословный термин: латиница цела, но одно слово услышано как другое (
future branchвместоfeature branch— реальная ошибка моделей из моих прогонов) — 0.75. - Латинская форма с опечаткой в одну букву (
GithabилиWhisprвместоWhisper) — 0.5. Столько же получает фраза, наполовину ушедшая в транслит (feature бранч): латиница удержана лишь в одном слове из двух. - Латинский огрызок — узнаваемый фрагмент термина, всё ещё латиницей — 0.25.
- Транслитерация (
гитхаб) и полный промах (что-то совсем не то или пропуск слова) — 0. Транслит, даже грамотный, — это потерянная латиница; почему он не получает частичный балл — чуть ниже.
Единственное исключение — устоявшиеся заимствования: для слов типа «баг» или «коммит» кириллица — это и есть каноническое русское написание, и EPI за неё не штрафует.
Метрика EPI
Как считается EPI — сохранение английских терминов
За каждый английский термин модель получает балл по тому, насколько сохранила латиницу. Сквозной пример — слово GitHub; на ступени 0.75 — многословный термин, где одно слово услышано неверно.
EPI = English Preservation Index. Баллы вычисляются по каждому термину бенчмарк-словаря, итог усредняется.
Полный словарь допустимых форм для каждого термина я собирал и расширял вручную по ходу — это было одной из самых рутинных частей всей работы.
Важно: EPI не заменяет WER — они считаются параллельно, один и тот же выход проходит через обе сразу. Грубо: WER считает попадание в слово, EPI — удержание латиницы. И тут есть тонкость, которая часто удивляет: на гитхаб вместо GitHub WER не штрафует — я в своей нормализации намеренно приравнял эти две формы (зачем — разбираю в приложении), — а вот EPI ставит 0: латиница потеряна, а за корректность самого транслита модель уже получила прощение на оси WER — награждать его ещё и в EPI значило бы заплатить за одну заслугу дважды. На каноническом GitHub совпадают обе оси: WER — попадание, EPI — 1.0.
Итого, композитная метрика Q — взвешенная сумма трёх измерений:
Композитная метрика
Из чего складывается балл Q
Взвешенная сумма трёх измерений. Веса подобраны под сценарий IT-диктовки.
Веса можно подвигать под свой сценарий на интерактивной странице с калькулятором.
Q ∈ [0, 1]. Меньший WER = лучше, поэтому в формуле он перевёрнут: (1 − WER). EPI и пунктуация уже в [0, 1].
Веса 0.65 / 0.10 / 0.25 подобраны под мой основной сценарий диктовки — вот логика по каждому слагаемому:
- 0.65 на WER — самая воспроизводимая и точная метрика, большая доля. (WER у меня тоже доработанный — не штрафует за то, что отдельно меряет EPI, и ещё за пару вещей; детали в приложении.)
- 0.10 на punct — у моделей в топе пунктуация упёрлась в потолок: почти у всех — около 99, различия исчезающе малы. Больше веса дать некорректно — это лишь усилит случайный шум вместо различительной способности. Но совсем выкинуть метрику нельзя: она нужна, чтобы штрафовать модели, которые знаки препинания пропускают часто или вообще их не ставят, — а такие в бенчмарке есть.
- 0.25 на EPI — заметный вес нашего главного отличия от чисто-русского распознавания: удержания латиницы. Не доминирует над WER, но и не теряется.
Если ваш сценарий диктовки отличается от моего, на интерактивной странице можно подвигать ползунки весов и пересобрать рейтинг под себя. Например, обнулить EPI, если диктуете на чистом русском без терминов.
Про числа в таблицах ниже. Все Q / WER / EPI / punct — это баллы по шкале 0–100, а не доли. Q=91 — композитный балл 91 из 100 (не «91% точности слов»). WER=8 — примерно 8 ошибок на 100 слов. Так читать удобнее, чем 0.910 и 0.078 в каждой ячейке.
На чём тестировал: два голоса и три типа записи
Сразу оговорка: это не огромное академическое исследование. Я не привлекал 100 спикеров и не обрабатывал тысячи часов аудио. У меня нет команды и гранта. Это работа одного человека в свободное время. Но я постарался сделать корпус максимально честным относительно реальных сценариев использования.
В финальной версии — три среза, два спикера. Speaker 1 (sp1) — это я, Speaker 2 (sp2) — моя жена, женский голос.
Корпус бенчмарка
На чём тестировал: 2 голоса × 3 типа записи
5 срезов корпуса, каждую модель прогонял по всем пяти.
У sp2 нет среза Medium — именно поэтому страт 5, а не 6. Medium записывался отдельно (фрагмент обучающего видео), sp2 в съёмках не участвовала.
Long-form (длинные блоки). Специально составленный benchmark-текст из 6 блоков по ~365 слов: разные темы IT-домена, разная плотность английских терминов. Sp1 и sp2 этот текст читают вслух. То есть это в некотором смысле синтетика — не живая речь, а контролируемый эталон, где мы заранее знаем правильный текст до запятой. Длительность блока — около 2.5–3.5 минут чтения, всего на спикера ~14–17 минут зачётного аудио. 23–47 IT-терминов в блоке. Первый блок — контрольный, без IT-терминов: в зачёт не идёт, так что по каждому спикеру считаются 5 блоков.
Вот он целиком. Long-form читается по бумажке, так что этот текст — дословный эталон, с которым сравнивали выводы моделей. Заодно видно, как плотность английских терминов растёт от контрольного первого блока к насыщенному пятому:
📄 Полный текст long-form корпуса — 6 блоков, ~2100 слов
Блок 1 · контрольный (чистый русский, без IT-терминов)
Интересное наблюдение из разговоров с людьми, которые приходят в хобби взрослыми: прогресс идёт медленнее, чем у подростков, но оказывается надёжнее. Подросток выучит гитарное соло за выходные, забудет через месяц и никогда к нему не вернётся. Взрослый тратит на то же самое два-три месяца, зато потом это остаётся с ним навсегда. То же самое с лыжами, с языками, с кулинарией.
Почему так — понятно при ближайшем рассмотрении. У подростка огромный ресурс времени и пластичности, но нет дисциплины и привычки возвращаться. У взрослого наоборот: времени мало, пластичности меньше, но есть понимание, что регулярность побеждает рывки. Двадцать минут каждый день дают больше, чем три часа раз в неделю — это известная истина, которую взрослый чувствует на собственном опыте, а молодой просто ещё не успел проверить.
Горные лыжи — хороший пример. Человек, вставший на лыжи в тридцать, проходит ту же самую кривую обучения, что и шестилетний ребёнок, но с одной ключевой разницей: он осознаёт каждое движение. Куда ставит лыжу, как переносит вес, где начинает поворот. Ребёнок делает это интуитивно, взрослый — сознательно. В итоге взрослый может научиться кататься не хуже ребёнка, просто путь будет другим: больше мыслей, меньше инстинкта.
С гитарой та же история. Ежедневные короткие занятия дают чистый линейный прогресс, который многолетние героические запои не способны воспроизвести. Пальцы запоминают аппликатуры, слух начинает выделять интервалы, в какой-то момент — обычно месяцев через шесть-восемь — простые песни начинают играться без раздумий. Это не волшебство и не талант, это просто следствие того, что каждый день повторялось одно и то же движение.
Сила регулярности — наверное, самое полезное, что взрослый может принести в хобби. Маленькое усилие, повторяемое без перерывов, побеждает большие спорадические попытки. Этот закон срабатывает везде, от музыки до спорта, и осознание его приходит только с возрастом.
Блок 2 · Hardware и OS
Про железо у меня сетап, в котором я уверен, но есть пара мест, где постоянно что-то отваливается.
Материнская плата ASUS, процессор Intel i5-13600, шестьдесят четыре гигабайта оперативной памяти, видеокарта GeForce RTX 5070 Ti на шестнадцать гигабайт. На основном накопителе стоит Samsung 990 Pro объёмом два терабайта — туда установлены Windows 11 и все активные рабочие проекты. Отдельно подключён SATA SSD на терабайт для архивов, и медленный HDD на четыре терабайта под видеоисходники и бэкапы. Недавно пытался включить вторичный накопитель как system drive и получил ожидаемое сообщение: можно использовать только один. На 990 Pro такой проблемы вообще нет, он подхватывается сразу.
Драйверы — отдельная история. В прошлую субботу обновил драйвер видеокарты NVIDIA до последней стабильной версии, заодно подтянул Intel Graphics Driver для встроенного видео, и мышь Logitech MX Master 3S наконец перестала отваливаться от USB. Проблема была плавающая, недели три не мог понять, где причина: устройство пропадало на несколько секунд, потом появлялось снова. Физически кабель в порядке, порт я менял, на другом компьютере та же мышь работает идеально. В итоге помог Logitech G Hub, обновлённый до последней версии.
Из периферии — Logitech MX Console как мини-консоль под Adobe и DaVinci, и Dialpad для видеосозвонов. Оба устройства висят на USB-хабе с отдельным питанием, потому что без питания хаб начинал просаживать напряжение при двух активных устройствах. Из мониторов — три штуки: центральный 4K на двадцать семь дюймов, два боковых Full HD. Клавиатура Logitech MX Keys, раскладка US International.
Весь сетап стоит на столе с регулировкой высоты, под ним ходовая дорожка Walking Pad — на видеоконференциях включаю её на три километра в час, и после рабочего дня набегает семь-восемь километров.
Блок 3 · Dev-workflow и Claude Code
Про работу с Claude Code — это мой основной инструмент последние месяцы. Утро начинается с того, что я открываю терминал, захожу в активный проект и запускаю сессию командой claude. Агент подгружает devlog, читает последний handoff от предыдущего сеанса, и обычно я сразу говорю: «Продолжай с того места, где остановились».
В хорошие дни он сразу ориентируется в контексте, в плохие — лезет перечитывать половину репозитория, и тогда приходится одёргивать. Типичная проблема — compaction: когда контекст забивается, система сжимает историю, и после сжатия агент теряет часть состояния. Я заметил, что после compaction надёжнее показывать итоговый план действий до исполнения.
В последние недели ввёл для себя правило: после каждой сессии prompt на commit и handoff, независимо от того, закончена задача или нет. Агент делает git add, пишет commit message в моём формате — короткая первая строка, перечисление изменений списком, в конце ссылка на issue, если есть, — а потом обновляет devlog и пишет handoff-файл со своим взглядом на текущее состояние. Следующая сессия стартует с чтения этого handoff, и потеря контекста между агентами минимизируется.
Отдельная боль — pop-ups на permission. При каждом обращении к bash, file edit или web fetch вылезает окно с запросом подтверждения. Это правильно с точки зрения безопасности, но мешает, когда делаешь рутинную правку из сорока последовательных команд. Помогает флаг auto-accept для тех инструментов, которым ты полностью доверяешь, но конфигурировать его нужно аккуратно: один раз согласился на шаблонные bash-команды, и агент пять минут чистил tmp-директорию, которую чистить было не надо.
Ещё момент — slash resume. Когда переключаешься между сессиями через slash resume, он всегда выкидывает pop-up подтверждения, и, похоже, это by design, а не баг.
Отдельный сценарий — работа с Pull Requests на GitHub. Раньше я сам писал описания для каждого PR: выдержку из коммитов, summary изменений, чек-лист для ревьюера. Сейчас эту часть делегирую агенту — он видит diff между feature branch и upstream, генерирует описание и отмечает потенциальные риски. Пару раз приходилось поправлять формулировки, но в среднем экономит минут пятнадцать на PR. Rebases перед merge тоже делаю через агента, но с визуальным подтверждением каждого шага: здесь слишком легко сломать историю необратимо. Опыт говорит, что для rebase и force-push нужна паранойя большая, чем обычно. Для GitLab и Merge request — тот же pipeline, только команды другие.
Блок 4 · Video production
С видеопродакшеном у меня сложились простые правила, до которых дошёл не сразу. Исходники лежат на HDD — там четыре терабайта, и для видео этого достаточно. Каждый проект в DaVinci Resolve я создаю на внутреннем SSD, cache и proxy тоже на SSD, потому что при 4K-потоке HDD физически не тянет одновременное чтение и запись. С 1080p я часто работаю вообще без proxy: карта вытягивает, и лишний шаг в пайплайне не нужен.
Сейчас на рабочем диске свободно сто восемьдесят восемь гигабайт, и один 4K-проект средней длительности может сожрать эту ёмкость полностью, особенно если включён рендер с промежуточными кэшами. Капасити — вечная тема: хочется купить ещё один SSD, но переносить активные проекты туда-сюда сложнее, чем просто чистить. Я давно подумывал ввести workflow, при котором активный проект автоматически едет на SSD, а при завершении уезжает на HDD, но так и не сделал — это работа на час, а в моменте всегда кажется, что задачи важнее.
Монтажный инструмент — DaVinci Resolve, платная версия Studio. Fairlight для звука, Fusion для титров и простой графики, color — встроенный, для моих нужд хватает. Экспорт на YouTube обычно в H.264 на десять мегабит, для архивов — ProRes 422 HQ. Микрофон RODE NT-USB Plus, лёгкий pop-filter, акустическая панель за спиной. Недавно поставил Autotune в fx-цепочке при записи закадровых голосов — не для пения, а для выравнивания интонации, и качество стало заметно ровнее.
Блок 5 · ASR и fine-tuning (hard-dense)
Теперь про речь. Из свежих интересных моделей — Breeze ASR 25. Это fine-tune Whisper-large-v2 от MediaTek Research, натренированный на паре Mandarin-English и задаче code-switching. Любопытный эффект: навык code-switching переносится на языковые пары, которых модель в обучении не видела, — на смеси русского с английским она показывает себя неожиданно хорошо.
Для сравнения — Whisper Large V3 на CUDA, с аккуратно подобранным initial_prompt на русском, в котором явно заданы все нужные знаки препинания: запятые, точки, вопросительные, двоеточия, кавычки-ёлочки, длинные тире, восклицательные. Autoregressive природа Whisper работает против пользователя: если первый сегмент вышел без пунктуации, все последующие наследуют этот стиль через condition_on_previous_text. Правильный initial_prompt ломает этот паттерн на старте. Запуск через faster-whisper с движком CTranslate2, compute type float16, VAD — silero.
WER на русском для типичных диктовок держится в районе семи-девяти процентов, на чисто англоязычных фрагментах сильно лучше, около четырёх. Главная метрика для bilingual-сценария — не WER, а сохранение английских терминов на латинице в русском контексте. Стандартный Whisper Large V3 с этой задачей справляется посредственно: примерно половину терминов оставляет на латинице, вторую половину транслитерирует, причём один и тот же термин в одной сессии может быть передан двумя-тремя разными способами. Это, мягко говоря, не добавляет детерминизма.
GigaAM-v3 от Сбера — модель сильная по WER на чистом русском, но в bilingual-сценарии сваливается в непредсказуемый транслит, без стабильности от прогона к прогону. На бенчмарке CSZS-zh-en Breeze ASR 25 даёт WER около тринадцати процентов против двадцати шести у базового Whisper Large V3 — то есть падение ошибки почти вдвое, и это на code-switching, а не на чистом языке. На чистом Mandarin он тоже улучшился, что подтверждает базовый тезис: специализация под code-switching не деградирует language-skill.
Интересный следующий шаг — LoRA fine-tuning Whisper Large V3 под специфический словарь русского IT-сленга: деплой, коммит, вайб-кодинг, мёрж-реквест. Для LoRA достаточно пяти-десяти часов размеченных аудиопар, что делает такой проект вполне реалистичным. Главное узкое место — сбор датасета: без аккуратно сохранённых пар «аудио плюс транскрипт» работать не с чем, и это отдельная инженерная задача.
RTFx Whisper Large V3 через CTranslate2 на RTX 5070 Ti выходит в районе четырёхсот-шестисот, Breeze ASR 25 — примерно втрое медленнее за счёт более тяжёлого decoder’а. На практике это означает, что обе модели обрабатывают речь быстрее реального времени с огромным запасом.
Блок 6 · Productivity-стек
Из инструментов у меня сложился довольно стабильный стек последние год-два. Заметки — сейчас постепенно переношу из Notion в Obsidian, потому что локальные markdown-файлы лучше дружат с LLM, и Claude Code умеет работать с ними напрямую. Это вообще важный аргумент: если ты регулярно используешь языковые модели как второй мозг, формат твоих заметок должен быть машино-читаемым. У Notion с этим хуже — свой проприетарный формат, экспорт кривоватый, и доступ из CLI требует обходных путей.
Задачи — Todoist. Простой, надёжный, работает между всеми устройствами. Пробовал всякие альтернативы: Things, OmniFocus, TickTick — возвращался. Синхронизация без тормозов, natural-language-ввод, дата-теги, фильтры по проектам. Ничего революционного, но и ломаться там нечему.
Почта — Gmail на стороне сервера, десктопный клиент MailSpring. Веб-интерфейс Gmail хорош, но MailSpring даёт быстрый поиск, snooze и read-receipts бесплатно, и после привычки к десктопу возвращаться в браузер не хочется. Календарь — Apple Calendar через стороннее приложение, потому что родной Google Calendar на Windows работает хуже, чем хотелось бы.
Коммуникации — Telegram доминирует: переписка по работе, чаты с коллегами, каналы, которые читаю. WhatsApp остался для бытовых вещей. Slack — только в рамках активных проектов, сам по себе его не открываю. Discord для нескольких специализированных сообществ, но там скорее lurking, чем активное участие.
Информационный ввод — в основном Хабр и VC.ru для русскоязычного IT-контента, англоязычная часть через RSS в Feedly плюс подборки от людей, которым доверяю. YouTube как замена телевизору: лекции, интервью, technical deep-dives. Spotify — фон для работы и отдельно для подкастов. Из подкастов слушаю в основном English-language, на темы инженерных практик, AI research, и пара общих про общество и технологии.
Всё вместе это не выглядит как цельная философия, скорее как эволюционно сложившийся набор. Каждый инструмент заменялся один-два раза, пока не встал на своё место. И, пожалуй, главное наблюдение за несколько лет: чем меньше ты меняешь инструменты, тем больше ценности успеваешь из них извлечь.
Live (спонтанная диктовка). Тут уже не чтение. У sp1 это реальные кусочки моей voice-to-text-диктовки: куски промптов к LLM, рабочие заметки, надиктованные на ходу мысли. Каждый фрагмент я вручную расшифровал в эталон — потом проверяю, насколько модель в эту расшифровку попадает. У sp2 — микс реальных спонтанных диктовок и коротких прочитанных. Всего 37 сегментов (25 у меня, 12 у sp2), из них 24 несут английские термины — именно на них считается EPI. Каждый сегмент от ~10 секунд до пары минут, общая продолжительность на двух спикеров — около получаса.
Чтобы было понятно, на чём именно считается EPI, — вот шесть таких сегментов вживую. Это настоящие куски голосовой диктовки, мои и моей жены; английские термины, которые идут в EPI-зачёт, выделены жирным.
🎙 Шесть реальных live-сегментов (из тех, что несут английские термины)
live-19 · 8 с · sp1 — короткий dev-промпт
Там обрати внимание, там еще один был fix, мы для него даже делали pull-request, про буфер обмена.
live-18 · 7 с · sp1 — английский корень сквозь русское склонение
Ты имеешь в виду в main моего форка, я надеюсь, PR?
live-21 · 11 с · sp1 — английская фраза-цитата внутри русской речи
А можешь объяснить, что значит Cargo isn’t available? И что это для нас значит для проекта, и что дальше?
live-13 · 62 с · sp1 — длинный сегмент, UI-лейблы Claude Code
Мы делали, какая история последних коммитов? Чуть-чуть погрузись в проект, и потом займемся уже задачами. Что я хотел с тобой сегодня обсудить: то есть вроде бы неплохо работает наша система, но бывают ситуации, когда разработка в нескольких окнах ведется активно, и у меня, например, на центральном мониторе есть промпт на подтверждение, и на правом мониторе тоже есть промпт на подтверждение, и получается, что я в этой ситуации не могу использовать горячую клавишу, потому что я не знаю, куда пойдет мой промпт. А особенно, если у них, например, на центральном мониторе у меня промпт типа Allow, Always allow, Deny, а на правом мониторе — Allow и Deny, где цифра «2» выполнит противоположные действия.
sp2-07 · 22 с · sp2 — второй голос, дизайн-домен, плотный микс
Слушай, тут такое дело… я начала тыкать в Figma всякие AI plugins, и, в общем, мне нравится, но непонятно, как это в нормальный workflow встроить. Например, я начинаю layout рисовать, потом, типа, кидаю prompt в плагин — а он мне выдаёт что-то совсем не то, что я ждала. Возможно, я неправильно prompt пишу? Или, может, есть какой-то конкретный плагин, который generate красивые wireframe сразу, без танцев с бубном? Хочу, в общем, как-то систематизировать.
sp2-10 · 35 с · sp2 — второй голос, клиентский бриф
Слушай, Claude, давай попробуем такое: у меня клиент — кофейня, надо сделать landing с акцентом на их фирменное обжарочное меню. Подумай, какой CTA лучше — забронировать столик или просто… нет, погоди, не CTA, а сначала как структурировать. И ещё хочу, чтобы у нас был единый design system на сайт и Instagram, потому что сейчас, как бы, всё врозь. Deadline у нас, короче, через две недели, ребята ждут feedback по первому варианту.
Medium (средние блоки). Тоже я, просто на отдельном корпусе (sp1m — это sp1 на medium-аудио). Кусок обучающего видео из моего курса, где я объясняю урок. Не чтение — живая речь на камеру. 6 блоков (первый — разогревочный, в зачёт не идёт, считаются 5), суммарно ~10 минут аудио.
Микрофоны и качество записи отличаются между спикерами. Я (sp1) записывал на хороший динамический микрофон через внешний аудио-интерфейс. Sp2 — на встроенный микрофон ноутбука. Это намеренное различие: реальная картина диктовки в IT-команде включает оба сценария — и запись на хороший внешний микрофон, и на встроенный микрофон ноутбука. Студийных условий тут нет ни у кого — разница именно в устройстве записи.
В сумме — 5 страт корпуса (sp1_L, sp2_L, sp1m_M, sp1_V, sp2_V), и каждую модель я прогонял по всем пяти.
Как я гонял более 100 000 прогонов
Все локальные Whisper-модели я гонял через свой форк Handy — опенсорсной десктоп-апки для voice-to-text. Из неё я сделал не приложение для диктовки, а комбайн для прогонов: можно поставить на ночь очередь на тысячи расшифровок — например, десяток моделей, каждую по 30 раз на одном и том же корпусе, — и утром забрать результаты. Каждый прогон сохраняется в отдельный JSON-файл сразу после завершения.
Cloud-API (OpenAI, Google Chirp 3, Deepgram) гонялись отдельно через прямые SDK — Handy там не нужен. Плюс отдельно через скрипты — Qwen3-ASR от Alibaba, VibeVoice от Microsoft, SeamlessM4T от Meta, Voxtral от Mistral, GigaAM v3 от SberDevices, Borealis от Vikhr, Canary и Parakeet от NVIDIA. Подробный разбор non-Whisper моделей — в следующей секции.
Модель T-one от Т-Банка я тоже хотел протестировать — её мне подкинул кто-то в комментариях к моему предыдущему посту на Хабре. Но её сразу дисквалифицировало одно: модель не ставит пунктуацию вообще. Для моих сценариев (надиктовка длинных промптов для LLM) этого достаточно, чтобы выкинуть её из теста — даже если бы она идеально распознавала слова. Yandex SpeechKit — closed API без open weights, поэтому в open-source-бенчмарк не попадает. До полного cloud-зачёта руки пока не дошли, но я закинул в неё вручную один свой файл — и сразу увидел две вещи: пунктуацию модель не ставит, а code-switching, похоже, не поддерживает — английские термины уходят в кириллицу, когда основной язык русский. Так что с уверенностью скажу: в моём зачёте она была бы внизу списка.
Зачем столько прогонов
ASR-модели недетерминированы: один и тот же файл при разных запусках может дать чуть разный текст. По дефолту в whisper.cpp (и в Handy, который его использует — а также в faster-whisper, популярном Python-runner’е поверх тех же моделей) температура = 0 — то есть в теории модель должна выдавать одинаковый текст на одинаковом входе. Но есть нюанс: если на куске аудио модель не уверена в своём варианте, включается temperature fallback — стандартный механизм Whisper. Модель поднимает температуру и пересэмплирует этот кусок заново, пытаясь выбраться из плохого варианта. Побочный эффект — выход перестаёт быть полностью детерминированным: на одном и том же файле разные прогоны дают чуть разный текст. Это плата за то, что модель реже застревает на совсем неудачном варианте.
Конкретные эффекты, которые я наблюдал:
- Зацикливание (loops): Whisper-семейство иногда залипает в петле — выдаёт одну и ту же фразу N раз подряд.
- Срыв в другой язык: иногда модель посреди русской фразы переключается на английский — выдаёт что-то вроде «я открыл terminal and ran the script» там, где было «я открыл терминал и запустил скрипт».
- No-punct без промпта: некоторые модели без промпта практически никогда не ставят знаки препинания (как Whisper Turbo). Другие иногда не ставят (как Whisper Large).
Прогоните модель один раз — получите один из её возможных вариантов. На втором прогоне результат может оказаться другим. Особенно если модель склонна к галлюцинациям и петлям.
И вот здесь есть важная тонкость, которую легко недооценить. У некоторых моделей — whisper-large-v3 в этом смысле известный пример — есть склонность к катастрофическим событиям: бесконечная петля одной фразы или срыв в случайный язык на куске файла. Я посмотрел по своим данным, насколько это часто. На сыром noprompt-конфиге large-v3 на сложном длинном аудио доля таких сбойных прогонов доходит до ~20%; с пунктуационным промптом и анти-галлюцинационными настройками падает до пары процентов, а на коротких live-сегментах вообще держится ниже 1%. Но даже пара процентов меняет арифметику: пяти прогонов на условие недостаточно. Если катастрофа случается в 5–7% случаев, на пяти прогонах вы её либо вообще не поймаете (кажется, что модель железная), либо поймаете один раз из пяти — получите искажённые 20%. Чтобы оценка стабилизировалась, нужны десятки прогонов.
Поэтому — десятки прогонов на каждое условие: обычно 15–30, в зависимости от модели. А верхушку лидерборда я прогонял помногу — топовые конфиги Breeze до 70 раз — специально, чтобы прижать доверительные интервалы и понять, реальный это отрыв или просто шум. Для cloud-API я гоняю один прогон. В OpenAI Transcription API temperature=0 стоит по умолчанию, и в моих скриптах это и так выставлено явно. Формально это режим «без температуры», но OpenAI в документации честно предупреждает, что полную детерминированность даже на нуле они не гарантируют — на сервере может быть какой-то fallback. На практике их выход всё равно гораздо стабильнее, чем у локальных моделей, и тратить на повторные cloud-прогоны деньги я не стал. В формуле Q разница в числе прогонов учтена нормализацией (попросту: ошибки каждой модели я делю на число её прогонов, прежде чем складывать в общий зачёт, — чтобы модель с 70 прогонами не весила в 70 раз больше, чем cloud с одним).
Итого: десятки тысяч прогонов в live-корпусе, тысячи в long-form и medium — всего больше 100 000 прогонов по 23 моделям в 60+ конфигурациях. Это самая «дорогая» по времени часть проекта: больше 120 часов — пять суток — чистого инференса на RTX 5070 Ti, включая 5–7 ночных сессий по 8–10 часов (плюс дневные).
Языковой параметр и LID — это не одно и то же
Прежде чем рассказывать про LID, поясню разницу. У Whisper (и большинства ASR-моделей) на входе есть языковой параметр — простой селектор. Это самый высокий уровень управления: вы говорите модели «настройся на русский», и она выбирает соответствующее распределение вероятностей токенов.
Я тестил два варианта этого параметра:
language="ru"— явно русский.language="auto"— автоопределение (модель сама решает по первым секундам).
На моём корпусе auto обычно работает лучше для code-switching, чем фиксированный ru — потому что модель не зажимает английские термины в русское распределение.
А вот LID (Language Identification) — это уровень глубже. Это последовательность language-токенов на старте декодирования. Можно передать один токен (ru) — поведение будет ближе к обычному language="ru". А можно передать пару — ru en или en ru. И порядок имеет значение. Я наткнулся на несколько paper’ов и обсуждений на форумах, где сообщали: игра с этими language-токенами даёт прирост именно на смешанной речи — декодер сразу «знает», что в записи будут оба языка, и в каком соотношении. Звучало ровно под мой сценарий, так что двойные комбинации я решил проверить.
В Whisper этот режим теоретически поддерживается, но почти нигде не выставлен в высокоуровневых обёртках.
Дальше — кишки форка; нужны, только если будете повторять под двойной LID. Неинтересно — прыгайте к «Хорошей новости» ниже (спойлер: овчинка выделки не стоила).
Пришлось делать custom fork в три уровня глубиной:
- whisper-rs-sys-fork — вендорнутый whisper.cpp 1.8.3 с патчем FFI-полей
sot_lang_tokens/sot_n_lang_tokensвwhisper_full_params. Патчинг обоих SOT-путей (with-state + DTW), чтобы они конкатенировали массив language-токенов вместо одного. - whisper-rs-fork — Rust-обёртка, экспонирует
FullParams::set_sot_lang_tokens(&[i32])иWhisperContext::lang_token_id("ru") -> Option<i32>. - transcribe-rs-fork — слой выше, прокидывает
WhisperInferenceParams::sot_lang_tokens: Option<Vec<i32>>до whisper.cpp.
И только после этого в Handy в src-tauri/Cargo.toml через [patch.crates-io] всё подменяется на локальные форки.
Хорошая новость: на выигравших конфигурациях (Breeze + capglue) LID-варианты не дали значимого прироста. Знание зафиксировано, патч под двойной LID можно дальше не катать. Полностью свернуть три уровня форков, правда, не выйдет: два из трёх (whisper-rs-fork и transcribe-rs-fork) нужны для двух других моих доработок — анти-галлюцинационных параметров декодера и хука под capglue. Так что они остаются в моём форке Handy. Самый нижний слой (whisper-rs-sys-fork с патчем FFI под массив language-токенов) уже можно не поддерживать — это была чисто LID-история.
Промпты — четыре версии и две идеи
С промптом получилась такая история. Когда я серьёзно занялся измерением его эффекта, я сразу подумал: почему я тестирую именно тот промпт, который собрал ещё в марте? Может, другие форматы работают лучше? Так появились четыре версии — две по схеме «примера-затравки» (как мой мартовский) и две инструкционные.
V1 — пунктуационный пример-затравка на русском (мой мартовский). Цель — показать декодеру разнообразие знаков препинания на естественном русском:
Привет! Как дела? Он сказал: «Сделаем это сегодня — пока есть время». Конечно, не всё так просто, как кажется на первый взгляд; нужно принять во внимание погоду.
V2 — пример-затравка с code-switching. Тот же тип, но с английскими вставками — чтобы декодер «увидел» латиницу в контексте русской речи:
Привет! Как дела? Наш English-speaking friend сказал: «Сделаем это сегодня — пока есть время». Мы выполняли эту разработку в Claude Code. Конечно, не всё так просто; нужно учесть погоду.
V3 — прямая инструкция на английском. Это уже не пример-затравка, а прямая инструкция модели, что от неё хотят. На английском, потому что Whisper и потомки лучше реагируют на инструкции на английском:
Bilingual Russian-English speech transcription. Russian text with embedded English IT terms. Preserve English in Latin: Claude Code, GitHub, feature branch, CI/CD pipeline, deployment.
V4 — инструкция с двуязычным примером. Инструкция плюс конкретный двуязычный пример, что именно мы хотим увидеть на выходе:
This is a recording where a bilingual speaker uses Russian and English. English words and terms are preserved in Latin script. Example: «Мы задеплоили feature в production через CI/CD pipeline, используя для этого Claude Code».
Полную сетку из четырёх версий промпта (плюс noprompt) я гонял не на всех моделях, а только на перспективных — turbo-семейство, Breeze, Medium; cloud и большинство аутсайдеров шли с одним конфигом. Каждый конфиг — по 30–70 прогонов на условие. Почему при этом в live набегает на порядок больше прогонов, чем в long-form и medium, — дело в арифметике: в live каждый из 37 коротких сегментов — отдельный вызов модели, а в long-form и medium один прогон покрывает целый блок-сет спикера.
Главные результаты — open-source
Сначала числа, потом интерпретация. Ниже у каждой модели показан её лучший конфиг (best-per-model). Полная развёртка отдельных prompt/AH/LID-вариантов — на интерактивной странице.
К Q-метрикам я добавил скорость — во сколько раз обработка быстрее реального времени (×realtime). ×20 значит, что модель перемалывает запись в 20 раз быстрее, чем она звучит: минуту аудио — за три секунды. (Для технарей: это обратная величина RTF, real-time factor; ×20 ≈ RTF 0.05. Дальше — только в разах быстрее реалтайма.) Скорость замерена на моём железе (RTX 5070 Ti, Vulkan backend для Whisper-family) и сведена к одной цифре на модель — взвешенно по всему корпусу (суммарная длительность аудио к суммарному времени обработки). На вашем железе абсолютные числа будут другими, но относительные показатели между моделями сохранятся — пока речь об одном движке (у Whisper-семейства это whisper.cpp). Сравнивать скорость через границу движков — с NeMo-моделями NVIDIA или с облаком — по этим числам нельзя; про это отдельная оговорка ниже.
Кто чемпион среди open-source — это и есть тот главный вопрос, ради которого всё затевалось. (Open-source, или OSS, — это модели с открытыми весами: их можно скачать и гонять у себя бесплатно. Ранг «# OSS» в лидербордах ниже — место модели внутри этого класса.)
Ещё про пометки у моделей: Q5_0 / Q4_1 / f16 рядом с названием — это уровень квантизации, то есть сжатия весов. f16 — полная точность (файл потяжелее), Q5_0 / Q4_1 — сжатые версии (легче и быстрее, обычно ~1 ГБ вместо нескольких). Иногда сжатие почти не бьёт по качеству, иногда наоборот — на эту тему дальше будет пара сюрпризов.
И про сами конфиги (строка под каждой моделью в лидерборде): prompt / promptv3 — это пунктуационный промпт (его версии разобраны выше), capglue — мой regex-постпроцесс под Breeze, lid — двойные language-токены, а ah — анти-галлюцинационные настройки декодера. Последнее стоит запомнить: это параметры, которые гасят склонность Whisper срываться в петли и повторы — те самые катастрофические события из прошлой секции. Дальше ah будет встречаться часто.
ASR-бенчмарк · только открытые веса
Лучшие open-source: общий зачёт
Только открытые веса — скачал и гоняешь у себя бесплатно. Балл Q (0–100); под каждой моделью — лучший конфиг и метрики (WER, EPI, скорость ×реалтайм).
open-source-зачёт · корпус русско-английской IT-диктовки
В этой верхушке спрятано сразу несколько сюрпризов. Первый — на #2 стоит Whisper Turbo: облегчённая, в два с половиной раза более быстрая версия Large v3, которая обошла все варианты Whisper Large. (Официальное имя — large-v3-turbo, коротко turbo: OpenAI срезали у Large v3 декодер с 32 слоёв до 4 и дообучили; сами они подчёркивают, что это не дистилляция в духе Distil-Whisper. В статье зову её Whisper Turbo или просто turbo.) Прямо за ним — #3, русский code-switching fine-tune turbo (новинка, до которой я добрался уже под конец, — отдельный разбор в разделе про российские попытки): он почти вничью с обычным turbo. А дальше — россыпь контринтуитивного: Whisper Medium f16 (#4) обходит любой Large v3, Whisper Large v2 (#5) — модель 2022 года — тоже выше любого Large v3 (причём даже без всякого тюнинга), и только потом, на #6–8, появляется тот самый штатный Large v3, который я рекомендовал в марте. Каждую из этих странностей разберу ниже.
Прежде чем разобрать остальные знакомые модели — давайте сначала про чемпиона. Что это вообще за breeze-asr и почему вдруг мандарин-английский fine-tune обогнал и Whisper Large v3, и русскоязычные дообучения, и turbo. Это центральный сюжет статьи, и без ответа на этот вопрос дальнейшие разборы будут висеть в воздухе.
Breeze-ASR — главный сюрприз
Breeze-ASR — это fine-tune Whisper Large v2, сделанный исследователями MediaTek (Тайвань). Цель — улучшить работу Whisper на тайваньском Mandarin-English code-switching. Тайваньская IT-индустрия говорит на смеси китайского и английского: технические термины — названия библиотек, методов, понятий — летят по-английски прямо посреди китайской фразы. Ровно та же картина, что у нас с русским и английским. MediaTek нужна была модель, которая не теряется на границе языков.
И вот эта модель обошла даже Whisper Large v3 — модель новее той (v2), на которой Breeze построена, — и обогнала все известные мне русскоязычные fine-tune’ы на корпусе русской IT-диктовки с английскими терминами. Среди open-source она заняла первое место. В лидерборде выше у неё одна строка (лучший конфиг), но если развернуть все её варианты по отдельности — с разными промптами и постобработкой, разберём это чуть ниже, — то верхние строки open-source ещё долго остаются за ней: несколько лучших конфигов подряд — это всё Breeze, и только потом подключаются другие модели.
Почему вообще v2, а не v3
Любопытная деталь: Breeze построена на Whisper Large v2, хотя v3 на момент её выхода уже существовала. И это не случайность. Сама OpenAI по сей день отдаёт через свой API (модель whisper-1) именно large-v2, а не v3. Причина в том, что v3 дообучали на огромном корпусе псевдоразметки — около 4 млн часов аудио, размеченных самой же v2. В результате v3 стала чаще срываться в галлюцинации и зацикленные повторы, особенно на «грязном» реальном звуке. v2 в этом смысле стабильнее.
Вывод для практиков: не считайте, что раз v3 новее — значит лучше. Для многих задач v2 предсказуемее — и то, что лучший open-source в моём бенчмарке построен именно на v2, в эту картину укладывается. Это не только теория: дальше я проверю v2 напрямую, голую — в разделе про vanilla Large v2.
Гипотеза, почему сработало
База — Whisper Large v2. У Whisper русский в multilingual датасете уже есть, исходно. Базовое «понимание русского» у Large v2 (базы Breeze) никуда не делось. Fine-tune добавил к этому навыки code-switching, не заменяя существующие языковые знания.
Ключевая мысль: навык code-switching между парами языков переносится лучше, чем кажется. Декодер учится «не путаться, когда речь меняет регистр или язык». Это абстрактный навык на уровне attention в декодере, не привязанный к конкретной паре языков.
Модель, обученная на Mandarin↔English, обошла на русско-английском миксе и модели на чистом русском, и специально дообученные на русско-английских IT-подкастах. Заодно она привыкла не транслитерировать иностранное — что и видно по высокому EPI в лидерборде выше.
Модель, обученная на Mandarin ↔ English, обошла на русско-английском миксе и модели на чистом русском, и специально дообученные на русско-английских IT-подкастах.
Почему сработал Breeze
Честная оговорка: сколько здесь именно от переноса code-switching, а сколько от того, что под Breeze лежит крепкая база Large v2, — чисто разделить я не могу. v2 и сама по себе в моём тесте держится на удивление хорошо (об этом — в разделе про vanilla Large v2 ниже), так что часть преимущества Breeze, возможно, унаследована от удачной базы, а не от мандаринского дообучения.
Особенности и болячки Breeze
У Breeze есть четыре заметные особенности. Три — это родовые недостатки, с которыми придётся смириться. Одна — скорее приятный побочный эффект.
Болячка 1: склейка предложений. Тут любопытный лингвистический след дообучения. В китайском письме пунктуация-то есть — свои, полноширинные точки и запятые (。，), — а вот пробелов между словами нет вообще: иероглифы идут сплошным потоком. Похоже, дообучение на мандарине частично перенесло эту привычку: Breeze на стыке предложений то не ставит пробел после точки, то и саму точку пропускает — и конец одного предложения склеивается с началом следующего. На длинной диктовке это вылезает регулярно — предложения наезжают друг на друга.
Болячка 2: перетягивание заимствований в латиницу. Бывает, что человек произносит слово, которое давно живёт в русском как заимствование — то есть выговаривает его по правилам русской фонетики, со всеми мягкими согласными и привычной интонацией, не пытаясь подделать английское произношение. А Breeze всё равно решает, что это английский термин, и переводит его в латинскую форму. Показательный пример: я говорю «текст» — Breeze пишет text. Или «спикер» (в смысле «выступающий») — выходит Speaker. Слова, которые уже стали полноценно русскими, всё равно перетягиваются в латиницу. Исправить сложно — модель систематически предпочитает английскую форму там, где она у неё есть. Это плата за наш высокий EPI=82–87 (в зависимости от среза).
Болячка 3: осторожность с вопросительными знаками. Я заметил это уже на своих повседневных диктовках: Breeze охотно ставит точки и запятые, но вопросительные знаки — чуть менее охотно. На корпусе она их в нужных местах всё-таки расставляла, и когда ставила — попадала. Просто общая модель поведения: лучше промолчать, чем поставить вопрос неуверенно. Тут есть нюанс — наличие или отсутствие вопросительного знака сильно меняет смысл предложения. «Ты идёшь» и «Ты идёшь?» — это констатация факта и вопрос, разные действия от собеседника. Поэтому пропущенные вопросительные знаки придётся доставлять руками, если не хотим терять смысл фразы. На длинной диктовке это набегает: пара забытых вопросов в куске — и сообщение читается совсем не так, как задумывалось.
Фича: склонение через апостроф. Это мне нравится. Breeze иногда производит конструкции типа fine-tune'ы, prompt'у, state'е — приклеивает русское окончание через апостроф к английскому корню. Носители IT-русского ровно так и пишут в чатах и в технических текстах. Иногда требует ручной правки (если вы пишете официальный документ — апостроф там лишний), но обычно — комфортно для глаза.
Postfix capglue — починка склейки
Болячку 1 лечит небольшой регекс-постпроцесс, который я назвал capglue. Он берёт готовый текст и наводит порядок на стыках предложений: вставляет потерянную точку с пробелом там, где строчная буква упёрлась прямо в заглавную (кулинариейПочему → кулинарией. Почему), добавляет пропавший пробел после точки (backup.Недавно → backup. Недавно), восстанавливает заглавную в начале предложения, если она потерялась (…кнопку. дальше я… → …кнопку. Дальше я…).
capglue — это просто regex поверх готового текста, никаких прогонов модели он не требует. Я сравнил 59 разных long-form-конфигов (модель + промпт + параметры) с capglue и без — в 49 из 59 случаев версия с capglue оказалась лучше. То есть постфикс почти всегда улучшает результат, но прирост по парам небольшой — чаще всего доли пункта Q, и лишь в верхней четверти пар он переваливает за ~0.7 пункта. Этого хватает, чтобы Breeze-конфиги перестали делить места с соседями и вошли в чистый top-10 open-source среди all-configs, но не хватает, чтобы вывести модель за пределы её родного класса. Без capglue Breeze всё равно в топе open-source — это добивка качества по мелочи, не решающий фактор.
Я не планирую предлагать эту доработку в main-ветку Handy. Это слишком местечковая фишка — заточена под одну специфическую модель (Breeze) и под одну специфическую языковую пару (RU+EN). Оформлю как fork в моём репо для тех, кто хочет повторить.
Промпт: для Breeze — добивка, для turbo — критическая опора
На Breeze я прогнал все четыре версии промпта — и все они укладываются в узкий коридор Q=89.7–90.7. Даже совсем без промпта (но с capglue) Breeze держит 89.3. То есть выбор конкретной версии решает меньше полутора пунктов Q — на практике я просто беру победивший конфиг (promptv3 + capglue) и не заморачиваюсь.
Совсем другая картина у Whisper Turbo. Лучший turbo с промптом — Q=89.6. Turbo без промпта — Q=83.5. Разница 6.2 пункта Q. Turbo без промпта из игры просто вылетает — без подсказки она практически не ставит знаки препинания.
И это не единственные показательные дельты — полную таблицу vanilla vs tuned по всем моделям разберём отдельной секцией ниже.
Маленькая оговорка про номер версии Breeze
Чтобы не было путаницы: модель, которая в Handy в списке называется просто breeze-asr, — это на самом деле Breeze-ASR-25. Это поколение, которое и попало во все мои рейтинги выше.
Пока я писал эту статью, MediaTek успели выкатить следующее поколение — Breeze-ASR-26. Я, конечно, воодушевился — следующее поколение моего же чемпиона, должно быть только лучше — пошёл ставить и тестировать. К сожалению, на нашем русско-английском материале модель оказалась неприменима: 26-я версия упрямо выводит результат в китайских иероглифах (видимо, в этой ревизии MediaTek ужесточили привязку к мандарину). Для русско-английского IT-микса она не работает совсем — отдельные знакомые латинские термины проскакивают, но всё остальное превращается в неразборчивый поток ханьцзы.
Так что если будете повторять мой setup — берите именно breeze-asr (это 25-я версия), а не breeze-asr-26. В Handy она есть в списке по умолчанию и грузится в один клик; на Hugging Face это MediaTek-Research/Breeze-ASR-25.
Turbo — главный челленджер чемпиону
Теперь — челленджер. Чемпиону дышит в спину не полноразмерный Large v3 и не русские дообучения, а облегчённая версия самого же Large v3 — Whisper Turbo: вдвое меньше параметров и в два с половиной раза быстрее на моём железе.
С пунктуационным промптом + AH turbo занимает rank 2 OSS (Q=89.6), при скорости ×53 против ×21 у Breeze.
Качество против скорости
Балл Q и скорость на RTX 5070 Ti (Vulkan). Всё семейство Whisper — скорость честно сравнима внутри одного движка.
Зелёные точки — Breeze (лидер, ×21) и Turbo (×53): почти равны по Q, но Turbo в ~2.5× быстрее. Правый-верхний угол = «быстро и точно».
Данные: собственный бенчмарк. Ось Y усечена (84–92) для читаемости различий. Ось X — логарифмическая, показан диапазон ×14–×64: ×N = в N раз быстрее реального времени (≈ 1/RTF). Non-Whisper модели (Voxtral, Qwen3) показаны ниже оси (Q 83.4 и 79.6 ↓) — другой рантайм, прямое сравнение скорости некорректно.
Сравнивать буду с мартовской рекомендацией — штатным Whisper Large v3 (f16 с промптом, Q=86.3, rank 8 OSS). При этом скорость у всего семейства Large v3 примерно одинаковая (×20–×21), так что выводы переносятся на любой его вариант, не только на f16:
Скорость. Large v3 — ×20, Turbo — ×53: turbo в два с половиной раза быстрее на одном и том же железе. На моей RTX 5070 Ti это разница между «секундной задержкой» и «мгновенно». Любопытно, что в анонсе OpenAI разрыв куда драматичнее: на их графиках (A100, родной PyTorch-инференс) turbo выдаёт ~×30 реального времени против ~×4 у large-v2/v3 — разница в шесть-семь раз. На десктопе через whisper.cpp эффект скромнее: урезанный декодер — та самая экономия turbo — лишь часть общего времени обработки, а энкодер и подготовка аудио у обеих моделей одинаковые. Так что мои ×2.5 — это не «turbo разогнали не до конца», это цена реальной обвязки.
Поведение без промпта. Whisper Turbo без промпта практически не ставит знаки препинания (Q проваливается до 83.5). Штатный Whisper Large v3 пунктуацию ставит сам. Но если использовать обе модели совсем без настройки, разгромного победителя нет: по композитному баллу голая turbo даже выше (83.5 против 81.1 у голой Q5_0) — Large v3 без анти-галлюцинационных настроек теряет на петлях больше, чем turbo на пунктуации. Просто ломаются они по-разному, и текст без единого знака препинания — простыня, которую тяжело читать и править: пригодный результат «как есть» даёт именно Large v3.
С промптом вопрос снимается. Turbo + promptv4 обходит любую Large v3-конфигурацию по качеству распознавания, терминам и скорости.
Практический вывод: если в вашем софте можно задать пунктуационный промпт — Turbo лучше штатного Large v3 практически по всем осям, да ещё и легче для железа. А вот если промпт задать негде (часть клиентов этого просто не умеет), Turbo резко проседает до простыни без знаков. Тогда лучший вариант «как есть» — не Large v3, а vanilla Large v2 (почему — в следующем разделе): она и пунктуацию ставит сама, и в бенчмарке стоит выше.
Самое важное здесь: вторая по качеству open-source модель работает в два с половиной раза быстрее лидера. Если Breeze у меня на RTX 5070 Ti перемалывает 60 секунд диктовки примерно за 3 секунды (для меня это уже комфортно, нет ощущения критической задержки), то у turbo та же расшифровка появляется за секунду с небольшим.
И отдельный вывод про железо: если Breeze у вас слишком медленная или железо её просто не тянет — переключайтесь на turbo с пунктуационным промптом: на русско-айтишной диктовке вы при этом почти ничего не теряете. Качество практически то же, скорость в два с половиной раза выше, тянется на скромных конфигурациях, а на Mac с M-чипом вообще летает благодаря Metal-ускорению.
И ещё: русских fine-tune’ов самого turbo в бенчмарке набралось целых три — «Подлодка» и две модели от автора coriollon: просто русская и заточенная под code-switching. Им посвящён отдельный раздел про российские попытки ниже.
Vanilla Whisper Large v2 обгоняет любой Large v3
Breeze-ASR построена на Whisper Large v2 — мы выше упомянули, что v3 у OpenAI считают менее стабильной из-за тренировки на псевдоразметке. Я решил проверить эту гипотезу напрямую и взял голую Whisper Large v2 в Q5_0-квантизации (~1 ГБ файл), прогнал без промпта, без AH, без LID. Результат — даже в таком виде она на 5-м месте open-source (88.3), выше любого Large v3 — хотя запас над лучшим v3-вариантом сжался до 0.2 пункта. (Её лучший конфиг — это просто пунктуационный промпт без AH, 88.6; но и голой уже хватает.)
Вот вся Large/Medium-секция семейства Whisper в одной мини-таблице — та же пятёрка, что в общем лидерборде, у каждой модели её лучший конфиг:
| # OSS | Модель | Лучший конфиг | Q | Комментарий |
|---|---|---|---|---|
| 4 | Whisper Medium (f16) | promptv4 | 88.7 | впритык к тюненой v2 — разбор ниже |
| 5 | Whisper Large v2 (Q5_0) | prompt | 88.6 | даже голая (noprompt) даёт 88.3 — всё ещё выше любого v3 |
| 6 | Whisper Large v3 (Q5_0) | promptv4 + ah | 88.1 | с промптом обгоняет полную f16 |
| 7 | Whisper Medium (Q4_1) | promptv4 + ah | 87.6 | |
| 8 | Whisper Large v3 (f16) | prompt + ah | 86.3 | штатный «Whisper Large v3» из мартовской рекомендации |
Что отсюда видно:
- Даже голая v2 (88.3) выше любого Large v3 — а ведь у всех v3-вариантов в таблице конфиги уже настроенные: и Q5_0 (88.1), и f16 (86.3), и русский fine-tune от antony66 (85.5) остаются позади.
- С промптом v2 подбирается к Medium f16 вплотную — 88.6 против 88.7. То есть два лучших полноразмерных Whisper в бенчмарке — вообще не Large v3, а эта пара; про Medium отдельный разговор ниже.
- Все Large v3-варианты — ниже обеих. Это эмпирическое подтверждение того, что в Breeze-секции говорилось теоретически: v3 из-за псевдоразметки нестабильнее, v2 предсказуемее.
Тюнинг ей почти не нужен — а кое-что даже вредит. Пунктуационный промпт добавляет к голой v2 всего +0.3 пункта Q, а вот анти-галлюцинационные настройки (AH) изолированно даже отнимают 0.2. Долго я видел только бандл «промпт + AH» — и думал, что «тюнинг вредит v2» (единственная отрицательная дельта в бенчмарке); стоило развести по осям, как выяснилось: вниз тянет именно AH, а не промпт. Рецепт для v2: пунктуационный промпт — да, AH — нет. Но это добивка по мелочи — голая v2 и так уже на #5.
Это ровно тот сюжет v2-стабильности, что разбирали в Breeze-секции (псевдоразметка v3, OpenAI до сих пор отдаёт v2 через whisper-1) — только теперь с прямым подтверждением на данных: даже голая v2 обходит best-tuned v3, а статистика катастроф (петли, языковые срывы) — это про v3, не про v2.
Что из этого вытекает практически — и почему vanilla Large v2 недооценён. Сравним честно, голое с голым, без всякой постобработки: vanilla Large v2 = 88.3 против голой Breeze (без capglue) = 88.7. По сути это паритет: vanilla-против-vanilla на моём корпусе чуть впереди оказывается Breeze, но разница тонет в шуме — фактически ничья, и при этом v2 обходится без единого костыля. Нюанс важный: Breeze нужен capglue, потому что модель склеивает предложения на стыках (болячка 1 выше); у Large v2 этой болезни нет — чинить нечего. Уверенно вперёд Breeze уходит, только когда добавляешь её обязательный capglue плюс промпт — тогда она и забирается на 90.7.
Отсюда практический вывод: если железо тянет полноразмерную модель, но возиться с настройкой (regex-постобработка, подбор параметров) не хочется или негде — vanilla Large v2 — это отличный вариант «скачал и пользуешься». Пунктуацию ставит сама, латиницу держит прилично, склеек не делает. Хочешь выжать ещё чуть-чуть — добавь пунктуационный промпт (но не AH — см. выше). Не лучшая модель в абсолюте — но лучшая из тех, что работают вообще без плясок.
А что с привычными моделями
С чемпионом, его челленджером и недооценённой v2 разобрались. Остались модели, которые мы все ожидали увидеть в топе, — семейство Large v3 и Medium.
Семейство Whisper Large v3 — где на самом деле оказалось
Здесь стоит развернуть карту, потому что за одним именем «Whisper Large v3» скрывается несколько разных моделей, и моя мартовская рекомендация в итоге оказалась не там, где её ждали.
| # OSS | Модель | Лучший конфиг | Q | WER | EPI | punct |
|---|---|---|---|---|---|---|
| 6 | Whisper Large v3 (Q5_0) | promptv4 + ah | 88.1 | 9.2 | 76.8 | 98.4 |
| 8 | Whisper Large v3 (f16) | prompt + ah | 86.3 | 11.0 | 73.8 | 99.9 |
Тут две квантизации одной модели. Штатный Whisper Large v3 — это и есть та модель, которую я рекомендовал в марте. Тут стоит признаться: тогда я про квантизацию почти ничего не знал и пользовался обоими своими клиентами как есть — в Handy подгружалась Q5_0-версия, в OpenWhispr — полная f16. То есть моя мартовская рекомендация на деле охватывала обе. В бенчмарке Q5_0 — на 6-м месте OSS (Q=88.1), полная f16 — на 8-м (Q=86.3). Δ от Breeze-чемпиона — 2.6–4.4 пункта Q. Заметный разрыв.
(Был ещё русский fine-tune этого семейства — antony66 от Антона Бабкина. Но раз уж русских дообучений в бенчмарке набралось много, я вынес их все в отдельный раздел про российские попытки — там и про него.)
Парадокс квантизации у Large v3. Странность, на которую сразу обращаешь внимание в этой таблице: Q5_0 (88.1) обгоняет полную f16 (86.3) на 1.8 пункта Q. Это контринтуитивно — обычно квантизация ухудшает, не улучшает. Гипотеза (не углубляюсь): квантизация работает как лёгкая регуляризация и снижает частоту тех самых катастрофических срывов в петли/иероглифы. Эмпирический факт: Q5_0 v3 предсказуемее, чем f16 v3.
Whisper Medium: середняк, который обошёл Large v3
Вот этой строчки в моих ожиданиях не было совсем. Whisper Medium (f16) на 4-м месте OSS с Q=88.7 — лучше любого Large v3 и лучше vanilla Large v2.
| Модель | Лучший конфиг | Q |
|---|---|---|
| Whisper Medium (f16) | promptv4 | 88.7 |
| Whisper Medium (Q4_1) | promptv4 + ah | 87.6 |
Лучший Medium (f16 с promptv4) обогнал любой Large v3-вариант — и штатный Q5_0 (Q=88.1), и f16 (Q=86.3), и русский fine-tune (Q=85.5). И это при том, что Medium в три раза легче Large v3 по параметрам и быстрее: ×27 против ×20.
Помните парадокс квантизации у Large v3 — там сжатая Q5_0 обошла полную f16? В Medium-линии он не повторяется. Полноразмерный f16 (88.7) ожидаемо обгоняет квантованный Q4_1 (87.6) на 1.1 пункта Q — full-precision лучше, как и должно быть; ровно обратное тому, что мы видели у Large v3. Что отсюда практически: не считайте, что квантизация всегда помогает или всегда вредит — она ведёт себя по-разному на разных моделях. Конкретно для Medium берите f16, для Large v3 — Q5_0.
А базовая интуиция «больше параметров — лучше качество» на этих данных проседает: на коротких сегментах русско-английской диктовки средняя по размеру модель оказалась полезнее большой. Возможно, Large v3 со своими дополнительными параметрами как раз чаще срывается в петли и галлюцинации, о которых я писал выше — и эти катастрофические события съедают её преимущество. Возможно, дело в том, что fine-tune’ы и обучающие данные для Large v3 (включая псевдоразметку из v2) дают модели «слишком много свободы», которую она применяет не к месту.
Какой бы ни была причина — если вы целитесь в Large v3-семейство, имеет смысл сперва попробовать Whisper Medium. А главный претендент на замену Large v3 — turbo — уже разобран выше.
Российские попытки: большие надежды, скромный результат
Отдельная линия сюжета — русскоязычные модели. Несколько команд берут Whisper или строят свою архитектуру и дообучают под русский. Логика для меня железная: уж русская-то модель должна понимать русскую речь лучше «общей». На каждую из них я возлагал надежды. Честный итог наперёд: на моём узком корпусе (русско-английский IT-микс, мой голос, мои метрики) ни одна не выиграла. Ближе всех подобрался один code-switching fine-tune: в общем зачёте он сыграл с обычным Whisper Turbo вничью, а на live-срезе — короткой спонтанной диктовке — даже обошёл его (90.2 против 89.1).
Вот кто участвовал:
| Модель | Тип | Q | # OSS | Что вышло |
|---|---|---|---|---|
| Whisper Turbo RU code-switch (coriollon) | дообучение Whisper | 89.5 | 3 | вничью с turbo в общем зачёте, на live выше него — лучший русский результат |
| Whisper Turbo RU «Подлодка» | дообучение Whisper | 85.6 | 9 | overfit на хостов подкаста + любит транслитерацию |
| Whisper Large v3 RU (antony66) | дообучение Whisper | 85.5 | 10 | прироста над стоковым Large v3 нет |
| Whisper Turbo RU (coriollon) | дообучение Whisper | 84.4 | 11 | худший turbo в бенчмарке |
| GigaAM v3 (Sber) | своя архитектура | 71.8 | 17 | SOTA для чистого русского, валится на терминах |
| Borealis (Vikhr) | своя архитектура | 65.7 | 18 | на моём корпусе не взлетела |
| T-one (Т-Банк) | своя архитектура | — | — | без пунктуации — дисквалифицирована |
Пройдёмся по каждой.
Whisper Turbo Russian code-switch (coriollon) — главная интрига
Я наткнулся на статью ребят, которые дообучали Whisper Turbo под русский, — они заявляли улучшенные результаты. Пошёл проверять, и тут выяснилось, что у них есть отдельная версия, специально заточенная под code-switching — ровно под мой сценарий. Пройти мимо я, конечно, не смог: снова поставил финализацию статьи на паузу и прогнал обе по полной матрице. И вот эта code-switching-версия — единственная русская модель, которая реально хороша: #3 среди open-source, Q=89.5 (coriollon/whisper-large-v3-turbo-russian-codeswitch). Но смотрите, в чём загвоздка. Обычный, ничем не русифицированный Whisper Turbo даёт почти столько же — в точных числах 89.62 против 89.53 (в лидербордах оба округлены до 89.6 и 89.5). То есть в общем зачёте code-switching-дообучение прироста над общей моделью не дало — вничью (разница 0.09 пункта явно тонет в шуме). Но один срез в её пользу всё же есть: на live — короткой спонтанной диктовке — она обычный turbo обходит, 90.2 против 89.1 (#3 против #4 в live-лидерборде). Разрыв в 1.1 пункта на тесной live-выборке статистически не подтверждён, так что это направление, а не приговор — но показательно, что всплывает оно ровно на том сценарии, под который модель затачивали. Если ваш кейс — именно короткая спонтанная диктовка, к этой модели стоит присмотреться.
Whisper Turbo Russian (coriollon) — худший turbo в бенчмарке
Второй fine-tune от coriollon — просто русский turbo, без заточки под code-switching (coriollon/whisper-large-v3-turbo-russian) — на моём корпусе оказался слабее всех собратьев. Его лучшая тюненая версия — Q=84.4, и это худший turbo в бенчмарке: ниже любого Large, ниже любого Medium, ниже «Подлодки». Надежда на «русский — значит лучше» тут не сработала — по крайней мере на моём узком сценарии.
Что роднит обе модели coriollon — гигантский отклик на тюнинг. Между голой и настроенной версией +19.2 пункта Q у code-switch и +18.4 у общей — это максимум по всему бенчмарку (для сравнения: у обычного turbo +6.2). Любопытная деталь: в голом виде на моём корпусе эти русские fine-tune’ы заметно слабее обычного turbo (Q=70 и 66 против 83.5 у голого turbo), но настолько отзывчивее к промпту, что лучшая версия подтягивается вплотную. Поначалу я думал: ну, это как у всех turbo — без промпта они просто не ставят пунктуацию, вот и весь прирост. Но цифры говорят другое: пунктуация в моей метрике Q стоит максимум 10 пунктов, а прирост 18–19. Значит, примерно половина прироста — это реальная точность (распознавание слов и сохранение терминов), а не только знаки препинания. Подробную раскладку — в разделе «Сколько даёт tuning» ниже.
Whisper Turbo «Подлодка» — overfit на хостов подкаста
Подлодка — дообучение Whisper Turbo на расшифровках одноимённого IT-подкаста. Логика казалась железной: айтишники, часами говорящие по-русски с английскими терминами, — ровно мой сценарий. Заняла 9-е место (Q=85.6). Моё предположение — overfit на специфическую речь конкретных хостов (общий навык code-switching не улучшился) плюс заметная склонность к транслитерации: она охотнее обычного переводит английские термины в кириллицу, а мой бенчмарк за это штрафует.
Whisper Large v3 Russian (antony66) — без прироста над стоковым
antony66 — русский fine-tune Whisper Large v3 от Антона Бабкина (antony66/whisper-large-v3-russian). Тоже большие надежды: прицельный fine-tune под русский, должен ведь выстрелить. Не выстрелил — 10-е место (Q=85.5), ниже стокового Large v3 в обеих квантизациях. То есть дообучение под русский фактически не дало прироста. Любопытная деталь: если зафиксировать всё остальное и сравнить только «с промптом» против «без промпта», то у antony66 промпт изолированно вредит — даёт −0.9 пункта. У большинства Whisper-моделей наоборот. Похоже, специфика конкретного дообучения: «анти-галлюцинационные настройки — да, промпт — нет».
Borealis от Vikhr — русская audio-LLM, не взлетела на моём корпусе
Borealis от команды Vikhr (Vikhrmodels/Borealis) — это уже не дообучение Whisper, а audio-LLM в духе Voxtral: аудио-энкодер плюс компактная языковая модель-декодер (Qwen2.5-0.5B-Instruct). Ребята делают интересные вещи, и я воодушевился — пошёл, загрузил, прогнал. Чуда на моём корпусе не случилось: Q=65.7, почти в самом низу. Ругать не хочу — это другой таргет, и под другой сценарий она, возможно, тренировалась. Но конкретно на моём голосе и моих метриках улучшения нет.
GigaAM v3 от SberDevices — SOTA для чистого русского, не для нашего корпуса
GigaAM v3 от Сбера — тоже своя архитектура, и по бенчмаркам Сбера это SOTA для чистого русского. Здесь нюанс: для чистого русского без терминов она, скорее всего, и правда отличная. Но на русско-английском миксе валится — английские термины не просто транслитерирует, а коверкает в неразборчивую кашу. Для моего сценария это дисквалифицирующий минус; для диктовки на чистом русском — может быть лучшим выбором.
T-one от Т-Банка — без пунктуации, дисквалифицирована
T-one от Т-Банка я даже толком не смог сравнить: она вообще не ставит пунктуацию. Для надиктовки длинных промптов это сразу выкидывает её из теста, как бы хорошо она ни распознавала слова.
Общий вывод. Здорово, что русское распознавание двигают сразу с двух сторон — и дообучениями Whisper, и собственными архитектурами: за этим стоят люди и компании, которым не всё равно. Но честный итог для моего узкого сценария — русско-английской айтишной диктовки с упором на латиницу — такой: ни один русский fine-tune и ни одна своя архитектура в общем зачёте не обошли общие модели. Просто конкретно мой кейс пока не их конёк. На чистом русском или на других голосах расклад вполне может быть иным.
Модели вне Whisper-семейства
Я старался собрать в бенчмарк всё, что имело смысл проверить: заметные и свежие модели с поддержкой русского, открытые и бесплатные — и привычной архитектуры, и новомодные audio-LLM. Помимо Whisper-семейства так набралось 8 non-Whisper моделей. Две из них — GigaAM и Borealis — русско-нативные, их я уже разобрал выше в разделе про российские попытки; здесь они для полноты таблицы. Спойлер: ни одна не дотянулась до top-OSS позиции, и большинство существенно медленнее Whisper-family.
| Модель | Производитель | Q | # OSS | Скорость | Комментарий |
|---|---|---|---|---|---|
| Voxtral Mini 4B Realtime | Mistral | 83.4 | 12 | ×1.4 | Лучший non-Whisper. Критически медленный — на грани real-time. |
| Qwen3-ASR 1.7B | Alibaba | 79.6 | 13 | ×7.1 | Audio-LLM 1.7B. С русским справляется приемлемо, с code-switching — посредственно. |
| VibeVoice-ASR 4-bit | Microsoft | 75.6 | 14 | ×2.9 | 4-bit квантованная, медленная для своего размера. Эксперимент с компрессией. |
| NVIDIA Parakeet TDT 0.6B v3 | NVIDIA | 75.2 | 15 | ×12 | Хорошая на английском, на русском серьёзный регресс. |
| NVIDIA Canary 1B v2 | NVIDIA | 74.3 | 16 | ×4.1 | English-first; на русско-английском миксе пасует. |
| GigaAM v3 (E2E CTC) | SberDevices | 71.8 | 17 | ×18 | SOTA для чистого русского, на миксе валится — подробнее в разделе выше. |
| Borealis | Vikhr | 65.7 | 18 | ×7.8 | Русско-нативная audio-LLM, на моём корпусе не взлетела — подробнее выше. |
| SeamlessM4T v2 Large | Meta | 56.0 | 19 | ×13 | Multilingual для перевода речи. На code-switching IT-домене не справляется. |
Voxtral от Mistral — лучший из non-Whisper, но критически медленный
Voxtral Mini 4B Realtime — audio-LLM от Mistral. На моём корпусе занимает rank 12 OSS (Q=83.4) — лучше любой другой не-Whisper модели по качеству. Минус — скорость ×1.4: это уже на грани реального времени. Для потоковой расшифровки на лету Voxtral хорош; для интерактивной диктовки на одной видеокарте — слишком тяжёлый.
Qwen3-ASR от Alibaba — приемлемое качество, посредственный code-switching
Qwen3-ASR 1.7B — audio-LLM нового поколения. На русско-английском IT-корпусе даёт Q=79.6 (rank 13 OSS) при скорости ×7.1 — медленнее Whisper-семейства, но быстрее Voxtral. Чистый русский тянет нормально, на code-switching заметно отстаёт от Breeze и Whisper Large v2. Если интересно попробовать LLM-based ASR без больших ожиданий — лёгкая отправная точка.
VibeVoice от Microsoft — экспериментальная 4-bit, не для интерактива
VibeVoice-ASR в 4-bit квантизации — экспериментальная модель Microsoft, фокус на агрессивной компрессии весов. На моём корпусе Q=75.6 (rank 14 OSS) при скорости ×2.9 — для такого размера это медленно, и по качеству VibeVoice уступает свежим audio-LLM (Voxtral, Qwen3). Скорее интересна как пример того, насколько далеко можно сжать модель, чем как production-выбор для русского IT. Если запускаете для эксперимента — окей; для повседневной диктовки берите Whisper-family.
Маленькая оговорка про скорость в этой таблице. Скорость non-Whisper моделей не сопоставима со скоростью Whisper-семейства из основного лидерборда. Это другой рантайм: NVIDIA-модели идут через NeMo, GigaAM — собственный движок, остальные — каждая своя реализация. Turbo в основном лидерборде — ×53, а Canary здесь — ×4.1, но на совсем другом рантайме. Сказать «Canary медленнее Turbo в 13 раз» по этим числам было бы некорректно. Внутри NeMo-моделей скорость между собой сравнима; через границу рантайма — только грубая оценка порядка.
Главный вывод этого блока: на нашем корпусе русско-английского IT-микса non-Whisper модели системно отстают от Whisper-family по качеству. Архитектурно свежие audio-LLM (Voxtral, Qwen3) ближе всех к Whisper по точности, но платят за это скоростью: они в разы медленнее Whisper-семейства, а Voxtral — в десятки раз.
Эти модели не обязательно плохие — просто они не для этого use case. Voxtral хорош для потоковой расшифровки на лету. Parakeet — для англоязычной диктовки. GigaAM — для русского без иностранных терминов. Seamless вообще заточена под перевод речи с языка на язык, а не под точную расшифровку как есть. Наша задача узкая: русско-английский IT-микс с акцентом на сохранение латиницы.
Cloud-API — премиум-референс
Сначала контекст. Модели семейства Whisper выкладывали в open-source: large-v2 — в декабре 2022, large-v3 — в ноябре 2023, turbo — осенью 2024. А вот следующее поколение — gpt-4o-transcribe и mini — OpenAI в открытый доступ уже не отдала — только через платный API. Похожим путём идут Google со своим Chirp и Deepgram с моделями Nova (этот провайдер широко известен щедрым стартовым кредитом — порядка $200 после регистрации). Платные облака — не основной объект этого бенчмарка, но мне было любопытно, что вообще можно получить за деньги.
Это отдельный тир: открытых весов нет, инференс — на стороне провайдера, цена — поминутная. Чтобы было с чем сравнивать, рядом с качеством я считаю и стоимость: цену за час аудио и, для наглядности, во что обходятся 20 и 50 часов диктовки в месяц напрямую от провайдера (без наценки подписочных сервисов).
| # | Модель | Лучший конфиг | Q | WER | EPI | punct | $/h | $/мес (20ч) | $/мес (50ч) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | OpenAI gpt-4o-mini-transcribe | auto noprompt | 92.1 | 5.7 | 83.4 | 99.9 | $0.18 | $3.60 | $9.00 |
| 2 | OpenAI gpt-4o-transcribe | auto noprompt | 91.0 | 6.4 | 80.8 | 99.7 | $0.36 | $7.20 | $18.00 |
| 3 | Google Chirp 3 | ru-RU | 91.0 | 7.9 | 84.3 | 99.9 | $0.96 | $19.20 | $48.00 |
| 4 | Deepgram Nova-3 | multi noprompt | 85.8 | 10.3 | 70.3 | 99.6 | $0.31 | $6.20 | $15.50 |
У cloud скорость — это network latency + время обработки на сервере, не локальный GPU-compute. Поэтому отдельной колонки скорости для cloud нет: это совершенно другой класс величины — round-trip API + сеть, а не работа модели. На практике Deepgram реагирует почти мгновенно, Chirp 3 тоже шустрый, OpenAI — посередине, но эти задержки определяются их инфраструктурой и вашим интернет-каналом, а не самой моделью.
Чемпион среди cloud — gpt-4o-mini-transcribe, $0.18/час, Q=92.1. Что меня удивило: дешёвая mini обогнала дорогую full-модель OpenAI. Mini вдвое дешевле — и впереди на пункт Q. Возможно, на десятках прогонов с ненулевой температурой full подтянулась бы — но в режиме temperature=0 (это дефолт OpenAI Transcription API, и в моих скриптах он зафиксирован явно) гонять одну и ту же запись много раз почти бессмысленно. Так что на моих данных mini и дешевле, и точнее. Обычно за качество доплачиваешь — здесь наоборот.
Cloud впереди open-source — но впритык
Если слить оба тира в один зачёт, cloud выигрывает 1.4 пункта Q (cloud-champion 92.1 vs open-champion 90.7). Запас есть. Но маленький — точечная оценка в пользу cloud, а вот доверительный интервал уже пересекает ноль (интервалы и пороги значимости разбираю в приложении). Кому реально стоит за это платить — отдельная секция ниже. Пока держите в голове одно: разрыв узкий.
ASR-бенчмарк · русско-английская IT-диктовка
Кто на самом деле лучше: общий зачёт
Композитный балл Q (0–100), лучший конфиг каждой модели. Cloud = платный API, OSS = открытые веса (локально бесплатно). Под моделью — конфиг, WER, EPI.
100 000+ прогонов · 23 модели · RTX 5070 Ti
Первые три места — cloud, сразу за ними Breeze, и дальше cloud в топе не появляется вплоть до Deepgram Nova-3 на 12-м месте (Q=85.8) — а он пропускает вперёд восемь open-source моделей. То есть «cloud лучше» — это про три конкретные модели, а не про весь платный тир.
Live (спонтанная диктовка) — другой чемпион
Long-form — это всё-таки чтение по бумажке. Реальный сценарий voice-to-text для меня — это короткая отрывистая live-диктовка: «напиши скрипт который…», «короче, эта задача про…», «давай добавим ещё API эндпоинт». Если ваш сценарий тот же — отдельный лидерборд по live-корпусу важнее, чем общий зачёт.
ASR-бенчмарк · сценарий «live-диктовка»
Live-диктовка: другой чемпион
Короткая спонтанная диктовка (промпты, заметки на ходу) — не чтение по бумажке. Под моделью — конфиг, WER, EPI.
live-диктовка · сценарий «промпты и заметки на ходу» · корпус русско-английской IT-диктовки
На live-корпусе картина смещается. В общем зачёте Breeze была четвёртой, за тремя cloud-моделями; а на live она выходит в чистый #1 (Q=91.9), оставляя OpenAI mini-transcribe на #2 (Q=90.4) — отрыв 1.5 пункта Q, даже больше, чем её собственное отставание от cloud-чемпиона в общем зачёте (1.4). Это то место в бенчмарке, где бесплатная локальная open-source модель с моими допилами обходит платный cloud-API OpenAI на самом важном для меня сценарии — короткой спонтанной диктовке. Допилы — тоже бесплатные: пунктуационный промпт, анти-галлюцинационные настройки и regex для починки склеек.
Это в чистом виде open-source-победа: не нужно платить за API, не нужно отдавать аудио в чужое облако — и при этом локальная связка ещё и точнее, чем то, за что обычно платят.
Бесплатная локальная open-source модель с моими допилами обходит платный cloud-API OpenAI на самом важном для меня сценарии — короткой спонтанной диктовке.
Live-зачёт
Важная деталь: на разных режимах речи лучшая модель может оказаться разной — long-form и live-рейтинги совпадают лишь частично. Цифры, насколько именно, я вынес в приложение; но если ваш сценарий — короткая отрывистая live-диктовка, ориентируйтесь на live-лидерборд, а не на общий зачёт.
Голос имеет значение
Один из важных уроков бенчмарка: модель — только половина дела. Вторая половина — кто говорит и в каких условиях. У нас два спикера, и картина у них разная — и тут на качество влияют сразу несколько вещей: индивидуальные особенности голоса (тембр, высота), дикция и техника записи (микрофон, расстояние до него, акустика помещения).
Конкретные числа (на лучшем Breeze-конфиге):
- Спикер 1 (я, мужской голос, динамический микрофон в кабинете): на long+live Q=91.9, на спонтанной диктовке Q=93.9.
- Спикер 2 (моя жена, женский голос, встроенный микрофон ноутбука): на long+live Q=89.4, на спонтанной диктовке Q=88.9.
- Δ примерно 2.5–5 пунктов Q в зависимости от среза. Заметная разница, но не пропасть.
Важная оговорка про методологию: по-честному голоса сравниваются на long-form — там оба спикера читают один и тот же текст, и разница в Q — это чистая разница голоса и записи. На live контент у каждого свой, так что часть live-расхождения — от разного материала, а не от спикера. Поэтому long-form тут — контролируемый замер, а live — скорее ориентир.
Если свести верх таблицы к одному виду (long+live, лучший конфиг каждой модели):
| Модель | Тир | sp1 Q | sp2 Q | Δ |
|---|---|---|---|---|
| Google Chirp 3 | cloud | 92.5 | 90.8 | −1.7 |
| OpenAI gpt-4o-mini-transcribe | cloud | 93.8 | 90.4 | −3.4 |
| OpenAI gpt-4o-transcribe | cloud | 93.1 | 89.7 | −3.4 |
| Breeze-ASR | OSS | 91.9 | 89.4 | −2.5 |
Просаживаются на sp2 все, но по-разному — от −1.7 у Chirp 3 до −3.4 у OpenAI.
Что меняется? В основном — WER (распознавание слов): на sp1 WER Breeze ~5–7%, на sp2 ~9–11%. EPI и пунктуация — стабильнее: sp1 EPI ≈ 86, sp2 EPI ≈ 82. То есть английские термины и знаки препинания модель держит у обоих похоже, а вот сами слова на записи sp2 распознаёт хуже — а в чём именно причина (голос, дикция, микрофон, акустика комнаты), по двум спикерам точно не скажешь.
С местами интереснее. На sp1 Breeze — лучший open-source, сразу за теми же тремя cloud-моделями (для OSS-чемпиона это нормально); на sp2, как видно по таблице, расклад тот же — первые три места у cloud, Breeze четвёртая. Самое любопытное — рокировка внутри самого cloud: на sp2 Chirp 3 выходит в #1 и обходит OpenAI mini, хотя на sp1 уверенно лидировала mini. Возможное объяснение — Chirp 3 обучен на более разнородном корпусе голосов и микрофонов и на менее «студийном» аудио держится лучше; но, честно говоря, на выборке sp2 (n=12) этот разрыв невелик, так что это скорее догадка, чем установленный факт.
Практический вывод простой: ваши результаты будут зависеть от вашей дикции, оборудования, шумовой обстановки и от того, как вы произносите английские слова (если вы хотите, чтобы модель ловила их как английские). Хороший внешний микрофон в тихом кабинете и чёткая дикция — будете ближе к верхней границе моих чисел. Встроенный микрофон ноутбука, фоновый шум, мягкое или неотчётливое произношение английских терминов — ближе к нижней.
Насколько этим цифрам можно верить
Короткий, но важный дисклеймер. Все различия я проверял не на глаз, а бутстрэпом: гонял повторное ресэмплирование по корпусу и считал доверительные интервалы — чтобы отделить реальный разрыв от случайного шума. Главное, что из этого следует для практики: верхушка таблицы тесная. Top-4 общего зачёта (три cloud-модели + Breeze) статистически друг от друга не отделены — внутри этой четвёрки выбирайте по цене и privacy, а не по десятым долям Q. Уверенно отделяться модели начинают только ниже: к штатному Whisper Large v3 разрыв от лидеров уже не повод спорить.
Поэтому и к «сюрпризам» выше (Medium и vanilla v2 по баллу выше Large v3, парадокс квантизации) относитесь как к описательной картине: направление устойчивое, но разрывы в верхушке небольшие, а точные пороги значимости — кто кого статистически обыгрывает, а кто нет — я вынес в приложение. Всю матчасть — как собрана метрика Q, что не так со стандартными WER/punct и как считались интервалы и пороги — я убрал в приложение («Приложение для гиков: как это посчитано»), чтобы не грузить ей основной текст.
Сколько даёт tuning
Один из побочных результатов бенчмарка — таблица «vanilla vs tuned» по каждой open-source-модели. Vanilla = модель в полностью голом виде: noprompt, noAH, noLID и без capglue — для всех моделей одинаково. capglue есть только у Breeze, поэтому её Δ вбирает в себя ещё и эффект этого regex-постпроцесса. Best tuned = её лучший конфиг с любой интервенцией. Δ показывает, сколько даёт весь tuning-стек поверх сырой модели.
Сколько даёт тюнинг
Балл Q модели в голом виде (vanilla) и в лучшем конфиге (с промптом / настройками). Δ — прирост. Шкала начинается с 64, а не 0 — честный зум на зону различий.
Δ = весь tuning-стек (промпт + анти-галлюцинации + capglue) поверх сырой модели; считается по неокруглённым значениям и может отличаться от разности подписей на 0.1. Шкала начинается с 64 для читаемости — не с нуля.
| Модель | tuned Q | vanilla Q | Δ | Что это значит |
|---|---|---|---|---|
| Whisper Turbo RU code-switch | 89.5 | 70.4 | +19.2 | гигантский разрыв; около половины прироста — не пунктуация |
| Whisper Turbo RU (coriollon) | 84.4 | 66.1 | +18.4 | тот же эффект, но из совсем слабой голой версии |
| Whisper Large v3 (Q5_0) | 88.1 | 81.1 | +7.0 | в основном ah срезает петли → WER падает |
| Whisper Large v3 RU (antony66) | 85.5 | 79.1 | +6.4 | почти весь прирост — ah; промпт изолированно вредит (Δ=−0.9) |
| Whisper Turbo | 89.6 | 83.5 | +6.2 | вот тут да — без промпта вообще не ставит пунктуацию |
| Whisper Large v3 (f16) | 86.3 | 80.4 | +5.8 | в основном ah (режет петли), не пунктуация |
| Whisper Turbo RU (Подлодка) | 85.6 | 83.3 | +2.3 | скромный эффект |
| Breeze-ASR | 90.7 | 88.7 | +2.1 | добивка (с учётом capglue), не критическая опора |
| Whisper Medium (Q4_1) | 87.6 | 86.2 | +1.4 | скромный |
| Whisper Medium (f16) | 88.7 | 87.5 | +1.3 | скромный |
| Whisper Large v2 (Q5_0) | 88.6 | 88.3 | +0.3 | плейн-промпт чуть помогает, AH вредит (см. раздел про vanilla v2) |
Δ считается по неокруглённым значениям, поэтому местами отличается от разности округлённых колонок на 0.1.
Что отсюда видно:
- Гигантские дельты (+18–19) — у двух русских turbo-fine-tune’ов от coriollon (разбор — в разделе про российские попытки). Прирост настолько велик, что одной пунктуацией не объясняется: пунктуация в Q стоит максимум 10 пунктов, а тут 18–19. Примерно половина приходится на пунктуацию, вторая половина — на реальную точность (распознавание слов и сохранение терминов).
- Большие дельты (+5–7) — но природа у них разная. У обычного Turbo прирост и правда про пунктуацию: без промпта целые куски текста остаются без знаков (vanilla punct ≈ 72 из 100), промпт поднимает до ~100. А вот у обеих квантизаций Large v3 и у antony66 пунктуация и без тюнинга на месте (vanilla punct 81–98) — их прирост даёт в основном
ah: анти-галлюцинационные настройки душат петли и срывы, и от этого резко падает WER. У antony66 это видно в чистом виде — почти весь его +6.4 — это снижение WER, а промпт ему даже вредит (см. ниже). - Скромные дельты (+1–2) — у моделей, которые уже из коробки ставят пунктуацию: Breeze, Medium, «Подлодка». Tuning у них — добивка качества, не превращение mid-tier в high-tier.
- Поучительный случай — Whisper Large v2: общий Δ всего +0.3, но если развести по осям (см. раздел про vanilla v2), плейн-промпт помогает совсем на чуть-чуть (+0.3), а AH изолированно вредит (−0.2). Прежнее «тюнинг вредит v2» было артефактом бандла промпт+AH — теперь видно, что вниз тянет именно AH, а не промпт.
- Тонкость про antony66: vanilla→tuned даёт +6.4 — но это благодаря AH-параметрам декодера. Если зафиксировать AH и сравнить только prompt vs noprompt — промпт даёт −0.9. То есть для antony66 формула не «промпт обязателен», а «AH да, промпт нет».
Практический вывод: берёте Turbo — обязательно с пунктуационным промптом (без него теряете ~6 пунктов Q). Берёте Large v3 или antony66 — обязательно с анти-галлюцинационными настройками (ah): именно они вытягивают WER, иначе теряете те же 6–7 пунктов. Дальше — по убыванию отдачи: у Breeze тюнинг даёт заметные +2.1 (capglue плюс промпт — без них она своё первое место не удерживает), Medium — немного, но непренебрежимо (+1.3–1.4), и только Large v2 можно брать действительно как есть: вся её дельта — +0.3 (простой промпт, без AH).
Что такое AH (анти-галлюцинационные настройки)
AH мелькает в каждой второй таблице этой статьи — пора раскрыть, что стоит за этим сокращением. Ничего секретного: это всего два флага декодера whisper.cpp, которые я выставляю вместо дефолтов.
n_max_text_ctx=128. Whisper при декодировании каждого следующего сегмента подаёт декодеру текст предыдущих как затравку — механизм condition_on_previous_text, через который сегменты наследуют стиль друг друга. У этого механизма есть тёмная сторона: если в контекст попал кусок с зацикленной фразой, петля воспроизводит сама себя и едет дальше по всему файлу. По умолчанию лимит этого контекста фактически отключён (16384 токена — больше, чем декодер вообще способен взять); я жёстко режу его до 128. Модель видит только короткий хвост предыдущего текста — петле не на чем разгоняться, а для связности диктовки короткого хвоста хватает.
entropy_thold=2.8. У whisper.cpp есть встроенный детектор вырожденного выхода (аналог compression_ratio_threshold из оригинального Whisper): если энтропия токенов сегмента слишком низкая — текст подозрительно однообразный, скорее всего это петля, — сегмент бракуется и передекодируется с поднятой температурой (тот самый temperature fallback из секции про 100 000 прогонов). Дефолтный порог — 2.4; я поднимаю до 2.8, то есть делаю детектор строже. Цена — чуть больше передекодов, выигрыш — зацикленный сегмент чаще ловится и чинится сам.
Вместе эти два флага бьют по одному врагу — петлям и повторам на длинном «грязном» аудио, — но с двух сторон: первый не даёт петле распространяться между сегментами, второй ловит её внутри сегмента. Отсюда и эффект из таблицы выше: у моделей, склонных к срывам (Large v3, antony66), AH вытягивает +6–7 пунктов Q почти в одиночку, а стабильной Large v2 даже слегка вредит (−0.2) — петель у неё и так нет, чинить нечего. Оба флага — специфика whisper.cpp (на нём работает Handy и большинство десктопных клиентов); если запускаете модели другим раннером, ищите аналогичные ручки в его настройках.
Cloud vs Open-source — где проходит граница
Разница между cloud-чемпионом и open-source-чемпионом по Q — 1.4 пункта. Что это значит на практике?
WER cloud-чемпиона — 5.7%, у open-source-чемпиона — 7.8%. В абсолюте 2 ошибки на 100 слов — кажется, мелочь. Но если сравнить их между собой — open-source ошибается примерно на 37% чаще (5.7 → 7.8): если вы правите за моделью транскрипцию (а я обычно правлю), работы прибавится — больше чем на треть. Незначительной такую разницу я бы не назвал.
Конкретные цены — на 10 июня 2026:
| Модель | $/час | $/мес (20ч) | $/мес (50ч) |
|---|---|---|---|
| OpenAI gpt-4o-mini-transcribe | $0.18 | $3.60 | $9.00 |
| Deepgram Nova-3 (multilingual) | $0.31 | $6.20 | $15.50 |
| OpenAI gpt-4o-transcribe | $0.36 | $7.20 | $18.00 |
| Google Chirp 3 | $0.96 | $19.20 | $48.00 |
Для ориентира: 20 часов аудио в месяц — это примерно час диктовки в день в рабочие дни (даже чуть меньше), 50 часов — два с небольшим часа в день.
Open-source как бонус для уже существующего железа
Open-source — $0/час API cost. И тут важный момент про железо: у IT-специалиста, который активно работает с ML, играет, рендерит или занимается другими GPU-задачами — GPU обычно уже есть. В этом случае marginal cost запуска breeze-asr на нём = 0.
Облако оправдано, только если GPU нет и покупать его исключительно под транскрипцию вы не планируете, а диктуете при этом немного. Если вы готовы выложить $700 за RTX специально под voice-to-text — это, скорее всего, нерациональный вариант, дешевле и проще платить за облако по pay-per-use.
И отдельный плюс локальной модели, который часто упускают: можно бесплатно загнать в неё любое количество аудио. YouTube-видео, обучающий курс, многочасовая запись звонка, подкаст в фоновом режиме — пять часов, десять, двадцать. Без оглядки на счёт. Никаких $5–10 сверху к ежедневной диктовке.
Сборная рекомендация: есть GPU + privacy важна → breeze-asr. Нет GPU + privacy не критична + мало диктуете → openai-gpt-4o-mini-transcribe через свой API key (не через подписки). Разница в Q между ними — 1.4 пункта, в практических ошибках — около 2 на 100 слов.
А что про WisprFlow, SuperWhisper и прочие платные апки?
В этой арифметике остался один неназванный игрок — подписочные диктовочные приложения. Если вы прямо сейчас платите $10–15 в месяц за WisprFlow или подобный сервис — задумайтесь, что у них внутри. Точных данных о внутренностях этих сервисов они публично не раскрывают — поэтому всё, что я скажу дальше, это моё предположение по косвенным признакам.
Моё предположение: подобные сервисы используют open-source Whisper-модели (вероятно large-v3 или turbo), которые они сами хостят в своём облаке, плюс какую-то дополнительную LLM для постобработки — чистка текста, восстановление пунктуации, форматирование. Это сочетание объясняет и фиксированную подписочную модель ($10–15/мес flat), и не топовое качество транскрипции (если бы они гоняли топовый OpenAI Transcribe — было бы видно по результатам).
Альтернатива, если эта картина похожа на правду: возьмите open-source клиент типа OpenWhispr и подключите свой OpenAI API key напрямую. Тогда вы платите $0.18/час pay-per-use, а не $10/мес flat. При типичной нагрузке 20 ч/мес — это $3.60 вместо $10–15. И на бэкенде у вас будет реальная топовая модель, которая в этом бенчмарке rank-1. Граница здесь та же, что и во всей секции: платить имеет смысл за модель, а не за обёртку вокруг открытых весов.
Практика: как поставить и настроить
Какую модель выбрать под свой случай
Короткая развилка по железу, privacy и объёму диктовки
promptv3 + capglue
breeze-asr
Нет GPU + мало диктуешь → gpt-4o-mini-transcribe через свой ключ
Как поставить breeze-asr за 10 минут
Железо: Breeze идёт в Handy как GGML-модель в Q5_K-квантизации — файл ~1 ГБ, и для инференса достаточно около 4–6 ГБ VRAM на видеокарте. На любой современной игровой GPU (включая старые RTX 20xx и младшие 30xx с 6 ГБ памяти) — спокойно. На встроенной графике, увы, в большинстве случаев будет слишком медленно для интерактивной диктовки — нужна хотя бы дискретная видеокарта (исключение — Apple Silicon: там Metal-ускорение тянет Whisper и без дискретной GPU).
Самый простой путь — моя сборка. В неё уже зашиты промпты, regex для Breeze (capglue включён сразу), анти-галлюцинационные настройки для всего семейства Whisper и ещё пара мелочей. Останется включить промпт и анти-галлюцинации в Advanced — и пользуешься: github.com/egsok/Handy-nevinovata.
1. Скачать сборку из github.com/egsok/Handy-nevinovata
2. Settings → Model → выбрать "Breeze-ASR" (есть в списке встроенных)
3. Settings → Advanced → включить промпт и анти-галлюцинационные настройки (capglue для Breeze уже включён)Альтернатива — официальный Handy. Если хотите чистый upstream: качаете handy.computer и выбираете Breeze-ASR в списке моделей. Но скажу честно: поля для промпта в официальной сборке сейчас нет, так что промпт-тюнинг из этой статьи там недоступен. Capglue и анти-галлюцинационных настроек — тоже. Либо миритесь с потерей (голая Breeze — это Q≈88.7 вместо 90.7), либо нужен форк с доработками: мой выше или собственный — например, попросить агента перенести нужные коммиты из моей сборки.
Какой промпт выбрать
Единого промпта-победителя в бенчмарке нет: у разных моделей выиграли разные версии — promptv3 у Breeze, promptv4 у turbo и Medium, promptv2 у русского code-switch turbo, V1 у Large v2, а antony66 вообще лучше без промпта. Решает само наличие промпта: на русских turbo-дообучениях оно даёт до +19 пунктов Q (с 70 до 89.5), у обычного turbo — +6.2. Выбор конкретной версии вторичен — между вариантами разница 0.2–1.1 пункта, и зависит она от модели, голоса и корпуса. Тексты всех четырёх версий с разбором — в секции «Промпты — четыре версии и две идеи». Практическая рекомендация простая: возьмите из таблицы лидерборда лучший конфиг для своей модели — промпт в нём уже указан.
Что делать, если железо не тянет
Прямо скажу: на чистом CPU вообще ни одна Whisper-модель не работает приемлемо для интерактивной диктовки. Даже самый быстрый Whisper Turbo на обычном десктопном CPU работает, как правило, не быстрее реального времени — около ×1 или медленнее, а на старых ноутбучных процессорах счёт идёт на десятки раз медленнее. Минутная диктовка превращается в минуту-другую ожидания — это уже не «отпустил кнопку, увидел текст». Для оффлайн-расшифровки в фоне на CPU (часовая лекция за час-два) — терпимо. Для интерактивной диктовки — нет. А вот на средней видеокарте оффлайн идёт уже в 20–50 раз быстрее реального времени: ту же часовую запись Whisper перемалывает за пару минут.
Что делать в порядке предпочтения:
- Если есть Mac с Apple Silicon — Metal-ускорение работает с Whisper-family. Конкретно: на MacBook Pro M4 Pro (14 ядер) Whisper Large комфортно тянется, на обычном M4 — на грани (по отзыву моей жены — у неё как раз такая конфигурация: Large для повседневной работы слишком медленный, turbo — нормально). M1, M2, M3 я не тестировал — будьте готовы к тому, что Large может не вытягивать, и переходите на turbo. Turbo с правильным промптом на Apple Silicon — реалистичный вариант для интерактивной диктовки.
- Если GPU нет вообще (старый ноут или мини-ПК без дискретной видеокарты и без вменяемой встроенной графики) — для чистого русского без терминов посмотрите на GigaAM. Она сильно легче Whisper-family и работает почти мгновенно даже на слабой машине. Минус — с английскими терминами не дружит, как разбирал выше.
- Если первые два пункта не про вас — берите cloud. OpenAI gpt-4o-mini-transcribe за $0.18/час через свой API key — самый дешёвый и качественный вариант. Trade-off — privacy.
Что я сам использую
Десктоп (RTX 5070 Ti): breeze-asr с promptv3 + capglue через мой форк Handy на Vulkan-ускорении. Это мой ежедневный инструмент для общения с LLM, заметок, набросков — больше часа диктовки в день.
Мобильный (iPhone): SuperWhisper и WisprFlow — оба на бесплатных тарифах. Диктую с телефона немного, хватает.
OpenWhispr и Handy — закинул в оба по PR на редактируемый промпт; что-то из этого, надеюсь, вмержат. А пока все мои наработки под Breeze живут в форке: github.com/egsok/Handy-nevinovata.
Оговорка: это мой стек на июнь 2026. Сам ландшафт ASR-моделей быстро меняется — OpenAI уже отошла от Whisper в сторону мультимодального gpt-4o-transcribe, появятся новые игроки, цены поползут вниз.
И к тому, с чего я начал. В заголовке стоит «Я ошибался» — и в марте я действительно промахнулся дважды: и в методе (выбирал модель по ощущениям, а это не бенчмарк), и в самой модели, которую советовал. Метод теперь честный, рекомендация — другая. Каждую новую модель, что влетала на радар, пока я писал статью, я успел протестировать, — но ландшафт меняется быстро, так что не зарекаюсь: может, когда-нибудь вернусь и обновлю. Для того таблица на интерактивной странице и живая — снимок состояния на эту дату, а не высеченная в камне истина.
Интерактивная таблица — покрутите сами
В статье я показал свои рейтинги при своих весах (0.65/0.10/0.25). Но мои веса — не ваши веса.
Если вы диктуете 95% чистого русского без английских терминов — поставьте EPI в 0 и перевзвесьте. Если у вас всё на английских терминах — поставьте EPI в 0.5 и WER в 0.4. Получите свой рейтинг.
Интерактивная таблица — egorsokolov.ru/ai/asr-leaderboard/
Что там:
- Все 23 модели и их 60+ конфигураций, все WER / punct / EPI / Q и скорость в одной таблице.
- Три слайдера весов с автонормализацией (сумма всегда = 1.0).
- Фильтры: cloud only / open-source only / все; long / live / medium / mixed.
- Переключатель best-per-model ↔ all-configs (полная развёртка).
- Сортировка по любой колонке.
- На телефоне работает, но таблица широкая — листается вбок, со смартфона удобнее в горизонтальной ориентации.
Что осталось за кадром
Этот бенчмарк решает узкую задачу — русско-английская IT-диктовка двух конкретных спикеров. Что не покрыто:
- Носители английского и других языков. Корпус — два носителя русского.
- Сильно отличающиеся голоса и микрофоны. Как мы видели в разделе про sp1 vs sp2 — даже между двумя нашими спикерами Δ Q доходит до 5 пунктов, а на отдельных live-выборках больше. Если у вас командный сценарий с разными голосами — закладывайте погрешность.
- Шумные среды. Кабинетная запись с приличным микрофоном (или встроенным микрофоном макбука). Call-center audio, конференц-залы, машина в пробке — другая задача.
- Streaming / real-time. Все модели тестировались в pre-recorded режиме.
- Сильный акцент в английском. Мой английский — свободный, с небольшим русским акцентом. Если у спикера акцент сильный — числа могут плыть.
- T-one (Т-Банк), Yandex SpeechKit. T-one — без пунктуации, не подходит под мой use case. Yandex — closed API без open weights, в open-source-зачёт не попадает; до полного cloud-зачёта руки не дошли, но ручная проверка одного файла показала отсутствие пунктуации и code-switching (термины уходят в кириллицу) — так что в моём зачёте она была бы внизу.
Честные оговорки:
- Агрегация по семействам: пробовал агрегировать на уровне семейств моделей — Holm-значимость не улучшилась, поэтому в основной зачёт это не пошло.
- OpenAI prompt-matrix: я не прогонял OpenAI с разными prompt-вариантами — при поминутной тарификации это лишние траты на тест. Возможно, с подобранным промптом OpenAI ушёл бы ещё дальше.
- Σ-pool vs macro: для основного зачёта я использую pooled-агрегацию (суммирую ошибки по всему корпусу, потом делю на сумму слов). Без поправки это бы подыгрывало моделям с большим числом прогонов — на каждом дополнительном прогоне модели достаётся больше «попыток усреднить шум». В моих скриптах поправка есть: счётчики ошибок и слов делятся на
n_runsдля каждой ячейки, прежде чем уйти в общий пул. То есть модель с 70 прогонами и модель с 5 прогонами получают равный вес в финальной агрегации. - Скорость (×realtime). Это числа из логов прогонов на моём железе (RTX 5070 Ti), одной цифрой на модель, взвешенные по длительности аудио — суммарная длительность аудио к суммарному времени обработки, — не часть eval-методологии. Под капотом это обратная величина RTF (real-time factor). Сравнимо только внутри рантайма: whisper.cpp-семейство (Breeze, Large v2/v3, Turbo, Medium) — между собой ОК; NeMo-модели (Canary, Parakeet) — между собой ОК; cloud-API — это сетевой round-trip, не GPU-compute, поэтому отдельной колонки в cloud-таблице нет. Через границу рантайма скорость сравнивать нельзя.
Приложение для гиков: как это посчитано и где проходят пороги значимости
Сюда я убрал всю статистическую кухню, чтобы она не мешала основному тексту. Если вам хватило вывода «верхушка тесная, разрывы небольшие» — этот раздел можно пропустить.
Где проходят пороги значимости
В best-per-model виде (23 модели, Holm-Bonferroni при α=0.05): rank-1 (OpenAI gpt-4o-mini-transcribe) Holm-значимо обыгрывает только модели с rank ≥ 5. То есть top-4 — OpenAI gpt-4o-mini, Google Chirp 3, OpenAI gpt-4o, Breeze-ASR — статистически не отделены друг от друга. На моих данных нельзя сказать «модель X лучше модели Y» внутри этой четвёрки — выбирайте между ними по цене и privacy, не по Q. С rank 5 (Whisper Turbo) Holm уже начинает уверенно отделять. К штатному Whisper Large v3 (rank 6–8 OSS в зависимости от кванта) — это уже очевидная разница в Q, не повод спорить.
Long-form против live: насколько совпадают рейтинги
Ещё про разницу режимов речи (упоминал в разделе про live). Ранжирования моделей на long-form и на live коррелируют лишь средне: Kendall τ-b = +0.548 — заметно выше нуля, но далеко от единицы. Из топ-10 каждого режима совпадают лишь 3 модели (top-10 Jaccard = 0.176); в топ-15 пересечение чуть богаче (Jaccard = 0.364), но единства всё равно нет. Простыми словами: расхождение двух моделей в long-form не гарантирует такого же расхождения в live, и лучшая модель на разных режимах может оказаться разной. Поэтому, если ваш сценарий — короткая отрывистая live-диктовка, ориентируйтесь на live-лидерборд, а не на общий зачёт.
Как собрана метрика Q
Метрику Q я переделывал — стандартные формулы оказались слишком грубыми. Изначально я взял штатные WER и punct_F1, которые мне предложил Claude при старте проекта, и сильно их доработал.
WER. Сама формула стандартная — (S + D + I) / N через библиотеку jiwer. Но перед сравнением и эталон, и гипотеза проходят через слой нормализации, который приравнивает то, что для нашей задачи ошибкой не является. Что именно приравнивается (и потому в WER не штрафуется):
- числа цифрами и словами:
1000и «тысяча» (со всеми склонениями — «тысячи», «тысяче») — одно и то же; - единицы измерения: «гигабайт» = «ГБ» = «GB», «миллиметр» = «мм» и так далее;
- латиница и её кириллическая транслитерация по вручную собранному словарю:
GitHub= «гитхаб»,bug= «баг»,pipeline= «пайплайн». Это сделано специально, чтобы WER не штрафовал дважды за то, что отдельно меряет EPI: переходGitHub → гитхаб— это потеря латиницы (минус по EPI), но не ошибка распознавания слова (по WER — попадание); - плюс мелочи: ё→е, регистр, пунктуация и тире вычищаются перед подсчётом.
Отдельно для спонтанной live-речи есть «снисходительный» вариант WER, который перед сравнением выкидывает с обеих сторон слова-филлеры (эээ, ну, как бы, типа) — чтобы не штрафовать модель за честно расшифрованное мычание, которого в эталоне нет.
Пунктуация. Базовое сравнение по позициям знаков (запятая vs точка, ёлочки vs кавычки) штрафует любые стилистические расхождения. Но в русском знаки препинания часто взаимозаменяемы — даже носитель, печатая, может поставить тире, двоеточие или запятую в одном месте. Штрафовать это как ошибку странно. В финальной формуле пунктуация почти бинарная: на каждом 50-словном непересекающемся окне считаем, сколько в гипотезе знаков из класса разрывов (. ! ? … , ; : —), и сравниваем с ожидаемой плотностью эталона. Если плотность достигает ~50% от ожидаемой — окно засчитано как «пунктуация есть». Метрика не штрафует за выбор знака, не штрафует за позицию — только за тотальное отсутствие. У топовых моделей реальная проблема не «перепутали запятую с тире», а «вообще пропустили всю пунктуацию в куске». Это и ловим.
EPI. Изначально была бинарной: латиница = 1, кириллица = 0. Потом я ввёл многоуровневую шкалу со словарём допустимых форм и какое-то время даже давал частичный балл за грамотную транслитерацию — «гитхаб» получал 0.5. Но в финальной версии этот кредит убрал, и шкала стала строгой: транслитерация любого качества — 0. Причина — двойная награда. Грамотный транслит уже полностью прощён на оси WER: в нормализации «гитхаб» приравнен к GitHub (см. выше), хороший транслит не стоит модели ни одной WER-ошибки. Давать за него ещё и полбалла в EPI значило бы засчитать одну и ту же заслугу дважды — и заодно размыть смысл индекса, который называется English Preservation: переключив алфавит, модель английский термин не сохранила, как бы аккуратно она его ни передала. Композит при этом информацию не теряет: «гитхаб» (WER-попадание, EPI 0) и «гип хап» (WER-штраф, EPI 0) по-прежнему различаются — просто теперь на правильной оси.
Тут возникает законный вопрос: почему латинская опечатка (Githab) получает 0.5, а грамотная транслитерация — ноль; разве опечатка не хуже аккуратного транслита? Дело в том, что EPI и WER меряют разное. За саму опечатку модель уже оштрафована в WER — там Githab просто неправильное слово. А EPI смотрит на другое: осталось ли слово английским термином в латинице. По этой оси Githab задачу почти выполнил — латиница на месте, термин узнаётся и ищется, потеряна одна буква, — а «гитхаб» алфавит потерял. Единственное исключение строгой шкалы — устоявшиеся заимствования («баг», «коммит»): для них кириллица — каноническое русское написание, и EPI за неё не штрафует.
Доверительные интервалы и поправка на множественность
Доверительные интервалы — paired-stratified pooled BCa CI. Разберём по словам:
- paired — для каждой пары моделей разности считаются на одних и тех же ячейках. Снимает межблочный шум.
- stratified — ресэмплирование внутри каждой страты (
sp1_L,sp2_L,sp1m_M,sp1_V,sp2_V) отдельно. Не теряем структуру корпуса. - pooled — внутри страты пересчитываем pooled-WER, micro-EPI, pooled-punct, потом Q.
- BCa — bias-corrected accelerated CI через jackknife.
- n_iter = 10 000 — для устойчивых хвостов CI.
Multiple testing — Holm-Bonferroni step-down. Без коррекции вероятность хоть одного false positive раздувается до >90% при 45 сравнениях. Holm контролирует family-wise error rate.
Важный нюанс: BCa CI и Holm-p-value тестируют разные гипотезы, и проверять стоит обе. Тот самый cloud-vs-open cross-tier: Δ = +1.4 пункта Q, BCa CI95 = [−0.22, +2.76] пересекает 0, sign-flip p_holm = 0.127 не проходит α=0.05. Корректная формулировка: это слабое положительное описательное свидетельство, не α=0.05 Holm-claim — точечная оценка в пользу cloud, но и интервал, и Holm-тест согласны, что отличить этот разрыв от нуля на моих данных нельзя. То есть «cloud скорее лучше, но запас небольшой» — не «cloud значимо лучше».
FAQ
Почему GigaAM провалилась?
Я тестировал snapshot gigaam-v3-e2e-ctc. По бенчмаркам Сбера — SOTA для чистого русского. На моём корпусе она занимает 17-е место среди open-source с Q=71.8. Фатальный минус — английские термины. Причём беда даже не в транслитерации (это было бы полбеды) — модель их коверкает: натыкаясь на незнакомое английское слово, выдаёт искажённую кашу, иногда вообще не те звуки. Для русско-английского IT-микса это критично. Это не «модель плохая» — это «модель не для этой задачи». Если ваша диктовка на 100% чистый русский — GigaAM может оказаться лучшим вариантом. Возможно, новые версии Сбера справятся лучше.
Подлодка же специально для IT — почему провалилась?
whisper-podlodka-turbo — Whisper Turbo, fine-tune на подкасте «Подлодка». Я возлагал большие надежды — IT-домен, русско-английский микс. Заняла 9-е место среди open-source (Q=85.6). Моё предположение: overfit на специфическую речь конкретных хостов (нет улучшения базовой code-switching) + большая склонность к транслитерации, которую мой бенчмарк штрафует.
А русские модели — Borealis, GigaAM, дообученные Whisper — стоит на них смотреть?
На моём узком корпусе (русско-английский IT, мой голос, мои метрики) ни одна не обошла общие модели. Я прогнал и русские дообучения Whisper (antony66, Подлодка и две новые turbo-версии), и русско-нативные модели (GigaAM от Сбера, Borealis от Vikhr, T-one от Т-Банка). Ближе всех — code-switching-дообучение turbo (#3 OSS): в общем зачёте — вничью с обычным Whisper Turbo, а на live-срезе даже чуть выше него (90.2 против 89.1). Полный разбор — в разделе «Российские попытки». Но учтите: для чистого русского без английских терминов расклад может быть совсем другим — там та же GigaAM очень сильна.
Какой WER в процентах у топа?
- Cloud champion (openai-gpt-4o-mini-transcribe): pooled WER ≈ 5.7%.
- Open-source champion (breeze-asr promptv3 + capglue): pooled WER ≈ 7.8%.
- Штатный Whisper Large v3 (f16, с промптом): pooled WER ≈ 11.0%.
- Whisper Large v3 (Q5_0, с промптом): pooled WER ≈ 9.2% (квантизация неожиданно помогает Large v3).
- Whisper Large v3 — русский fine-tune от antony66 (без промпта): pooled WER ≈ 10.2%.
- Whisper Large v2 (vanilla, Q5_0): pooled WER ≈ 8.0%.
- Whisper Medium (f16, с промптом): pooled WER ≈ 8.8%.
Разница 5.7% vs 7.8% — 2 ошибки на 100 слов в пользу cloud, но это +37% относительных ошибок.
Чем Whisper Large v3 отличается от Whisper Turbo на русском с английскими терминами?
На моём корпусе штатный Whisper Large v3 с пунктуационным промптом даёт Q=86.3 (f16, rank 8 OSS) или Q=88.1 (Q5_0, rank 6 OSS — в Handy по умолчанию подгружается именно Q5_0). Whisper Turbo с пунктуационным промптом — Q=89.6 (rank 2 OSS). Главные отличия — скорость (Turbo в два с половиной раза быстрее, ×53 против ×20) и поведение без промпта: Turbo практически не ставит знаки препинания, Large v3 ставит. С промптом Turbo обгоняет штатный Large v3 практически по всем осям. Русский fine-tune от antony66 без промпта (rank 10 OSS, Q=85.5) прироста над штатной моделью не даёт — идёт даже чуть ниже её (про русские дообучения — отдельный раздел). Подробный разбор — в основной части статьи.
А что с Whisper Medium?
Если коротко — на моём корпусе Whisper Medium (с правильным промптом) обогнал любой вариант Whisper Large v3. Лучшая Medium-конфигурация — ggml-medium promptv4, Q=88.7, rank 4 OSS. Это выше и базового Large v3 (rank 6–8), и русского fine-tune’а Large v3 (rank 10). Возможные причины разбираю в основной части — но практический совет такой: если целитесь в Large-семейство, имеет смысл сначала попробовать Medium.
А что с Whisper Large v2 — он же старый?
Старый, но удивительно живой. У меня в бенчмарке vanilla Large v2 в Q5_0 без промпта занимает rank 5 OSS — выше любого Large v3 и Medium Q4_1, и чуть позади Medium f16. Это перекликается с тем, что OpenAI до сих пор отдаёт через свой whisper-1 API именно v2, а не v3. Гипотеза: v3 дообучали на псевдоразметке (~4 млн часов, размеченных самой v2) и она стала менее стабильной. Тюнинг ей почти не нужен: плейн-промпт добавляет всего +0.3, а анти-галлюцинационные настройки (AH) изолированно даже вредят — Large v2 хороша уже голой. Поэтому это отличный no-config выбор: если железо тянет полноразмерную модель, но возиться с промптами и regex-постобработкой не хочется или негде — берите vanilla Large v2 как есть. В голом виде она идёт практически вровень с голой Breeze (88.3 против 88.7 — формально чуть впереди оказывается Breeze, но разница тонет в шуме), а склеек, ради которых Breeze нужен capglue, у неё нет вовсе. Уверенно Breeze обходит её только в полной форме — с capglue и промптом.
А Aqua Voice / WisprFlow?
Aqua Voice я тестировал. У них на выбор несколько моделей — в основном это Whisper (про него мы всё знаем, так что это, по сути, ещё одно красивое приложение поверх Whisper-моделей) плюс собственная проприетарная модель Avalon. Avalon как раз интересна — она заточена именно под IT-лексику, — но, к сожалению, на момент моих тестов работала только на английском, для русского недоступна. WisprFlow тоже использовал — про мою гипотезу об их внутренностях см. секцию выше.
Можно ли использовать ASR локально, без облака?
Да, и это один из главных мотивов всего бенчмарка. Whisper-семейство (Large v3, Large v2, Turbo, Medium, Breeze-ASR), GigaAM, Voxtral, Qwen3-ASR — все они работают локально. На NVIDIA GPU с 6+ ГБ VRAM модели идут через CUDA или Vulkan, на Mac с Apple Silicon — Metal-ускорение. Без GPU интерактивная диктовка проблематична: даже самый быстрый Whisper Turbo на обычном CPU работает, как правило, не быстрее реального времени (около ×1 или медленнее) — минутная диктовка обрабатывается минуту и дольше, это уже не «отпустил кнопку, увидел текст». Для оффлайн-расшифровки в фоне на CPU (часовая лекция за час-два) — терпимо, а на средней видеокарте та же запись расшифруется за пару минут. Для интерактивной диктовки CPU не годится — практически нужен GPU или Apple Silicon. Trade-off локального запуска: privacy и $0 за обработку против разовых трат на железо. Если железо уже есть для других задач — marginal cost = 0.
Где код?
Мой форк Handy со всеми наработками: github.com/egsok/Handy-nevinovata. Сырые аудио из корпуса не публикуются (privacy голосов спикеров).
Какой Whisper-runner использовать на практике — whisper.cpp или faster-whisper?
Это два самых ходовых способа запускать Whisper-семейство локально. whisper.cpp — C++-реализация от ggerganov, на ней работает Handy и большинство десктопных GUI (OpenWhispr и другие); быстро стартует, минимум зависимостей, годится для интерактивной диктовки. faster-whisper — Python-обёртка над CTranslate2, оптимизированный inference для тех же моделей: удобна для оффлайн-обработки больших аудио из скриптов (pip install faster-whisper — и работает). Качество распознавания у обоих одинаковое, модель та же; различие только в скорости старта, удобстве встраивания и зависимостях. Мой бенчмарк гонялся через whisper.cpp (Handy-фронтенд) — но если вы пишете свой скрипт для расшифровки YouTube или подкастов, faster-whisper будет проще.
capglue postfix будет в основном Handy?
Скорее всего, нет — слишком местечково (одна модель + одна языковая пара). Что он делает — в разделе «Postfix capglue» выше; для повторения оформлю как fork в моём репо.
Этот пост — часть моего канала Нейросеть не виновата. Там я разбираю практические находки и эксперименты с нейросетями, без хайпа и пресс-релизов.
