Whisper vs GigaAM: что лучше для транскрибации на русском — бенчмарк
Реальные бенчмарки Whisper и GigaAM на русском языке: WER, скорость, диаризация, сегментация. Честно про провалы с DSP, VAD и обновлённые цифры после повторного теста.
Whisper от OpenAI или GigaAM от Сбера? Оба open-source, оба заявляют поддержку русского. В интернете куча статей "Whisper лучше всех" — но почти все они основаны на английском или на коротких чистых записях. Реальных цифр на русской речи с шумом и несколькими спикерами почти нигде нет.
Мы прогоняем через транскрибацию сотни часов реальных встреч, консультаций и звонков каждую неделю. Синтетические бенчмарки на 30-секундных аудиофайлах нам ничего не говорят о том, что произойдёт с полуторачасовой записью с фоновым шумом. Поэтому решили протестировать сами — на своих данных, на своём железе — и опубликовать цифры как есть, включая то, что пошло не так.
Обновление: мы переделали этот бенчмарк заново, глубже разобрались в сегментации аудио и нашли настройку, которая заметно меняет цифры к лучшему для GigaAM. Ниже — актуальная версия с честным объяснением, почему числа отличаются от тех, что мы публиковали раньше.
Как тестировали (и почему именно так)
Железо: NVIDIA GB10 (Grace-Blackwell, 128GB unified memory), CUDA 13.2
Данные:session_7min.wav (430 сек, 16kHz моно, 13.1 MB) и session_80min.wav (4805 сек, 16kHz моно, 147 MB) — одна и та же психотерапевтическая сессия, 2 спикера, фоновый шум, короткая и полная версии
Эталон: транскрипция от Gemini 2.5 Flash — 1050 слов (7 мин) и 6655 слов (80 мин) после нормализации. Референс на 80 минут покрывает всю запись целиком (таймкоды переключаются с MM:SS на HH:MM:SS)
Метрика: WER (Word Error Rate) — процент неверно распознанных слов относительно эталона
Нормализация текста оказалась критичнее, чем сам выбор модели
Мы прогнали один и тот же результат через нормализацию и без неё — разница оказалась больше, чем разница между многими конфигурациями моделей: 21.74% WER без нормализации против 8.95% с нормализацией — 12.79 процентных пункта чистой методологической погрешности. Полный пайплайн нормализации из 10 шагов:
``
`
Если сравниваете модели без такой нормализации — вы в основном измеряете формат вывода, а не качество распознавания речи.
Почему цифры в этой версии отличаются от прошлой публикации
Мы уже публиковали цифры по этому бенчмарку раньше. При повторном прогоне числа заметно изменились — и мы решили не тихо подменить их, а показать разницу и причину:
Тест
Прошлая версия
Текущая версия
Причина разницы
GigaAM, 7 мин
5.82%
8.67%
Другой референс (865 слов против 1050 — старый был без односимвольных филлеров)
GigaAM, 80 мин
23.9%
22.75%
Внутренняя longform-сегментация pyannote вместо внешнего чанкования по VAD
Whisper, 7 мин
22.6%
22.00%
Совпадает в пределах погрешности
Whisper, 80 мин
35.7%
48.23%
Другой референс + не использовалась внешняя VAD-предобработка в этом прогоне
Это не единый академический датасет — это два репрезентативных для нас файла на одном и том же реальном разговоре. Если у вас другие данные и железо, абсолютные цифры будут другими, но качественные выводы (про сегментацию, overlap, DSP) должны переноситься.
Результаты на 80-минутной записи
Подход
WER
Слов
Время
Скорость
GigaAM — internal longform (patched pyannote)
22.75%
5929
43.6с
110x
GigaAM — pyannote VAD + фиксированные чанки 24с
24.93%
5760
66.5с
72x
Whisper antony66 TRT-LLM (beam=4)
48.23%
4222
174.8с
27x
Результаты на 7-минутной записи
Подход
WER
Время
Скорость
GigaAM — internal longform (patched pyannote)
8.67%
11.3с
38x
GigaAM — фиксированные чанки 24с
9.43%
—
49x
GigaAM — pyannote VAD + highpass 60Hz
11.60%
14.6с
30x
onnx-asr (CPU-only, чанки 25с)
10.29%
27.7с
15x
Whisper antony66 TRT-LLM (beam=4)
22.00%
22.9с
19x
Разбор результатов
Главное открытие: как вы режете аудио важнее, чем сама модель
Самая большая находка этого прогона — не про модель, а про сегментацию. Мы сравнили внешнее VAD-чанкование (нарезать аудио заранее и кормить кусками) с внутренней longform-логикой pyannote (модель сама решает, где границы речи) — и внутренняя сегментация выигрывает на обоих файлах:
7 минут: 8.67% против 9.43% у лучшего варианта с фиксированными чанками
80 минут: 22.75% против 24.93%, и при этом почти в 1.5 раза быстрее (43.6с против 66.5с)
Дальше начинается интересное — мы перебрали способы нарезки на внешнем VAD и получили контринтуитивные результаты.
Overlap (перекрытие соседних чанков) всегда делает хуже, и чем больше overlap — тем хуже:
Overlap
WER
Скорость
нет
10.67%
51x
+1с с каждой стороны
12.29%
65x
+2с
15.43%
61x
+3с
17.24%
65x
+5с
17.24%
60x
Интуиция подсказывает, что overlap должен спасать слова на границах чанков — на практике для GigaAM это не так: энкодер ожидает чистые границы речи, и расширение чанков контекстом с соседей путает его сильнее, чем помогает.
Чанки, выровненные по VAD (VAD-aligned), оказались хуже фиксированных по размеру — тоже неожиданно:
Подход
WER
Чанков
Средняя длина
Фиксированные 24с
9.43%
18
24с
VAD-aligned, gap 0.3с
13.90%
80
4.6с
VAD-aligned, gap 0.5с
13.52%
60
~5.8с
Причина простая: VAD режет по паузам и получает много мелких чанков — а больше чанков означает больше границ, на которых теряются слова. Если всё же используете внешнее чанкование (не longform), для GigaAM ориентир — 24 секунды: короче — слишком много границ, длиннее — упираетесь в лимит longform-режима модели.
Качество: у Whisper потери в 3 раза больше, и это не про то, что он "не расслышал"
На 7-минутной записи у GigaAM 66 удалённых слов против 206 у Whisper — то есть Whisper теряет втрое больше слов, а не просто ошибается в написании. При этом substitutions (неправильно распознанные слова) почти одинаковы: 23 у GigaAM против 22 у Whisper. Разница в качестве — это разница в том, когда каждая модель предпочитает промолчать, а не в том, что она слышит неправильно.
На 80-минутной записи у GigaAM (22.75% WER) картина ошибок такая:
Тип ошибки
Доля
Deletions (пропущено)
73%
Substitutions (неправильно)
~23%
Insertions (лишнее)
~4%
Почти три четверти ошибок GigaAM — это пропущенные слова, а не искажённые. И это не проблема границ чанков: пропуски равномерно распределены по всей записи, дублирования на границах — 1 случай из 17.
Кто теряется чаще всего — короткие слова и филлеры, причём чем короче слово, тем выше шанс, что оно потеряется:
Слово
Доля пропусков
"э"
87%
"угу"
51%
"все"
40%
"ну"
33%
"и"
31%
"вот"
27%
"что"
18%
"как"
18%
"я"
17%
"не"
16%
Это структурная особенность CTC-декодера, на котором построен GigaAM — он склонен "проглатывать" короткие токены независимо от DSP или чанкования. Подробнее о том, . Если для вашей задачи важно сохранить именно слова-паразиты и междометия (например, в психотерапии или качественных интервью, где "угу" — это часть содержания, а не шум), стоит иметь это в виду отдельно от вопроса "какая модель точнее в среднем".
VAD: pyannote быстрее Silero почти на порядок
На той же 7-минутной записи pyannote VAD обрабатывает файл за 2.1 секунды, Silero — за 30.2 секунды: разница в 14 раз. При этом WER у pyannote тоже немного лучше (10.67% против 12.55%). Отдельно от этого мы когда-то находили баг, из-за которого pyannote выглядел медленным на длинных файлах — pipeline.instantiate() вызывался на каждый запрос вместо старта сервиса, что превращало 4.5 секунды в 333 секунды. После фикса разница в пользу pyannote стала однозначной и на длинных, и на коротких записях.
DSP: простой highpass почти не влияет — а вот агрессивное шумоподавление всё ещё может всё сломать
В этом прогоне highpass-фильтр на 60Hz дал разницу меньше 0.1 процентного пункта — на практике нейтрально, можно оставлять для борьбы с низкочастотным гулом от техники без риска для качества.
Это не противоречит тому, что мы находили раньше с более агрессивной обработкой: полное спектральное шумоподавление (STFT-based noise gate, вычитание шумового профиля) в одном из прошлых тестов на этой же записи довело WER до 100% — модель не ошиблась, а буквально не увидела речь, потому что короткие слова-паразиты по амплитуде похожи на шум и вычитались вместе с ним. Подробнее мы пишем об этом в статье про . Вывод остаётся: простой highpass — нейтрален, агрессивное шумоподавление — риск, разница именно в агрессивности обработки, а не в DSP как таковом.
Инфраструктурные грабли: TRT-LLM, HF pipeline и ARM64
Три технические проблемы, на которые мы наткнулись при развёртывании — если решите повторить тест на похожем стеке, это сэкономит время.
Whisper через TRT-LLM переводит на английский при пустом промпте. Без явного указания языка модель по умолчанию переключается в режим перевода. Фикс — задать промпт явно:
`
TEXT_PREFIX = "<|startoftranscript|><|ru|><|transcribe|><|notimestamps|>"
`HF pipeline для Whisper не работает с chunk_length_s=30. Ломается на этапе декодирования через torchcodec. Работоспособный вариант — вызывать model.generate() напрямую с ручным чанкованием, а не через удобный pipeline-интерфейс.
pyannote на ARM64 (Grace-Blackwell / GB10) требует патча. torchcodec не собран под ARM64 — библиотеки предполагают x86_64, системный FFmpeg 7.x несовместим по версии libavcodec, отсутствует libnvrtc.so.13. Рабочее решение — добавить в pyannote fallback на soundfile + ffprobe вместо torchcodec для чтения и метаданных аудио. Если разворачиваете ASR-стек на ARM64-железе (Grace-Blackwell, Grace-Hopper) — готовьтесь к этому заранее, это не единичный баг, а системное несоответствие экосистемы torchcodec архитектуре.
LLM-постобработка всё ещё не улучшает точность
Здесь новых данных не появилось, вывод из прошлого теста остаётся: прогон расшифровки через LLM подчищает пунктуацию и форматирование, но не может восстановить слово, которое ASR-модель не услышала — у LLM просто нет доступа к аудио, чтобы отличить "модель ошиблась" от "человек так и сказал".
GPU не обязателен, но платите за это качеством и скоростью
onnx-asr (CPU-only реализация) на 7-минутной записи с чанками по 25 секунд дал WER 10.29% за 27.7 секунды — это хуже GigaAM на GPU (+1.6 п.п. к лучшему результату) и медленнее в 4 раза. Разумный вариант, если GPU в принципе недоступен, но не замена ему.
Настройки для продакшена
Если хотите повторить или проверить — вот конфигурация, которая дала лучшие результаты у нас:
Пайплайн GigaAM:`
Аудио → pyannote segmentation (internal longform) → GigaAM transcribe_longform → текст
`
Без DSP, без overlap, без внешнего чанкования. Нужен HF-токен с доступом к pyannote/segmentation-3.0 (обычный gated-репозиторий на Hugging Face, токен получаете в своём аккаунте).
Пайплайн Whisper (если он всё же нужен):`
Аудио → Silero VAD → чанки 30с → TRT-LLM (beam_size=4, русский промпт) → текст
``
Внешняя VAD-предобработка у Whisper даёт прибавку порядка 4 процентных пунктов к WER по сравнению с прогоном без неё — используйте её, если сравниваете модели по-честному.
Нормализация для WER: ё→е, схлопывание стаммеров, удаление всех аннотаций и меток — обязательный шаг. Без него разница между моделями тонет в разнице форматов вывода.
Когда что выбирать
GigaAM — для точности на русском
Критерий
Почему GigaAM
Русскоязычные данные
Обучен именно на русском, разрыв с Whisper растёт с длиной записи
Длинные записи (10+ мин)
Internal longform-сегментация даёт лучший WER и скорость одновременно
Нужна диаризация
Проще интегрируется в пайплайн с pyannote
Бюджетные видеокарты
~3GB VRAM
Whisper — для скорости и универсальности
Критерий
Почему Whisper
Мультиязычные данные
99 языков в одной модели
Нет GPU
Работает на CPU, хоть и медленно
Сообщество
Больше готовых сборок, документации, примеров
Когда важны именно слова-паразиты и филлеры
Если в вашей задаче "угу", "ну", "э-э" — не шум, а часть смысла (терапия, качественные интервью, разметка эмоционального состояния) — учтите, что и GigaAM, и Whisper теряют именно такие слова чаще всего, у GigaAM это структурная особенность CTC-декодера. Ни одна из моделей не решает эту проблему полностью "из коробки".
Частые вопросы
Можно ли запустить GigaAM без GPU?
Технически да, но по нашим тестам CPU-реализации (например, onnx-asr) заметно медленнее и немного хуже по точности, чем GigaAM на GPU. Для CPU-only сценариев Whisper — более обкатанный вариант.
Работает ли GigaAM с английским или другими языками?
GigaAM обучен и оптимизирован именно под русский. Для мультиязычных данных или английского Whisper — более надёжный выбор.
Стоит ли резать длинную запись на чанки перед распознаванием?
По нашим тестам — по возможности нет: внутренняя (internal longform) сегментация pyannote даёт лучший WER и выше скорость, чем ручное чанкование. Если чанкование всё же нужно — не добавляйте overlap и ориентируйтесь на чанки около 24 секунд.
Стоит ли включать шумоподавление перед распознаванием?
Простой highpass-фильтр — можно, он почти не влияет на WER. От агрессивного спектрального шумоподавления лучше отказаться: в одном из тестов оно довело WER до 100%, стерев короткие слова вместе с шумом.
Почему в статье об этом бенчмарке цифры менялись?
Мы дважды пересчитывали бенчмарк с разным референсом и разной сегментацией — см. таблицу сравнения выше. Числа отличаются из-за методологии, а не потому, что модели изменились.
Уроки
Нормализация текста для WER важнее, чем кажется. Разница до и после — 12.79 процентных пункта, больше, чем между многими конфигурациями моделей.
Дайте модели самой сегментировать аудио, если она это умеет. Internal longform pyannote обошёл ручное чанкование и по WER, и по скорости.
Overlap чанков — интуитивно правильная идея, которая не работает для GigaAM. Чем больше перекрытие — тем хуже WER.
VAD-aligned чанки не всегда лучше фиксированных. Больше мелких чанков = больше границ = больше потерянных слов.
73% ошибок GigaAM — это пропуски, а не искажения, и они не привязаны к границам чанков — это фундаментальное свойство CTC-декодера на коротких словах.
ARM64 — не x86_64 с другим набором инструкций, а отдельный источник багов для всего стека torchcodec/ffmpeg/pyannote.
LLM-постобработка решает форматирование, а не точность распознавания.
Как попробовать
TEOM использует GigaAM как основную модель для русского языка — с настройками из раздела "Настройки для продакшена" выше. Если хочется проверить на своих записях: бесплатно доступно 5 часов транскрибации в месяц, без ограничений на длину файла.
Бенчмарки получены на нашем железе (NVIDIA GB10, Grace-Blackwell) на реальных записях, а не на академическом датасете. Результаты на другом железе и данных могут отличаться. Эталон Gemini не идеален — WER считается относительно него, а не относительно идеальной ручной расшифровки. Это вторая версия бенчмарка; таблица выше показывает, что изменилось по сравнению с первой и почему.