Streaming ASR в проде – Whisper, Deepgram и AssemblyAI в 2026

Коротко

Потоковое распознавание речи (streaming ASR) – это превращение живого аудио в текст, пока человек ещё говорит, и именно эта технология стоит за живыми субтитрами, голосовыми агентами, расшифровкой созвонов и переводом в реальном времени. В 2026 году почти любой продакшен выбирает один из трёх вариантов: OpenAI Whisper (открытая модель под лицензией MIT, которую вы сами оборачиваете в потоковый цикл), Deepgram (быстрый облачный API, изначально созданный для реального времени) или AssemblyAI (облачный API, построенный специально под голосовых агентов). Whisper не рассчитан на стриминг – он читает аудио блоками по 30 секунд, – поэтому потоковый режим достигается умным циклом с перекрытием поверх модели, и открытый стандарт здесь – политика LocalAgreement-2, которая подтверждает слово только тогда, когда два последовательных прохода на нём сошлись. Облачные API избавляют от этой работы: Deepgram Nova-3 даёт примерно 6,8% ошибок (WER) при задержке менее 300 мс и цене около $0,46 за час аудио, а AssemblyAI Universal-Streaming выдаёт «неизменяемые» слова примерно за 300 мс по $0,15 за час и встраивает определение конца реплики, нужное голосовым агентам. Выбор почти никогда не сводится к «чья модель точнее вообще» – он определяется бюджетом задержки, набором языков, требованиями к месту хранения данных и тем, есть ли у вас команда, способная держать парк GPU; всё это разбираем ниже.

Зачем это нужно

Если ваш видеопродукт превращает речь в текст, пока человек ещё говорит, – значит, у вас работает streaming ASR, неважно, написали вы его сами или купили. Живые субтитры на вебинаре должны показывать слова в пределах секунды-двух после того, как они прозвучали. Голосовой агент, который записывает на приём, должен поймать момент, когда звонящий закончил говорить, чтобы ответить и не перебить. Расшифровщик созвона должен вести бегущий транскрипт, чтобы суммировать его сразу по окончании встречи. Телемедицинская консультация требует точной записи устных заметок врача с низкой задержкой. Все четыре сценария – одна и та же задача: преобразование живого аудиопотока в инкрементальный текст, и ломаются они одинаково: слова появляются слишком поздно, ранние догадки переписывают сами себя, система перебивает пользователя, а счёт оказывается в десять раз больше, чем обещал прототип. Эта статья даёт продакт-менеджеру, основателю или техлиду достаточно понимания, чтобы выбрать между тремя главными вариантами 2026 года, понять, что на самом деле даёт «задержка 300 мс», и обойти ловушки по стоимости и точности, которые топят большинство первых внедрений.

Что такое «streaming ASR» на самом деле

Разложим термин. Автоматическое распознавание речи (automatic speech recognition, ASR) – технология, которая берёт записанный звук с речью и выдаёт текст сказанного. Это движок внутри диктовки, субтитров и голосовых ассистентов. Слово потоковое (streaming) описывает, когда происходит работа: аудио обрабатывается по мере поступления, вживую, а не после сохранения полной записи. Противоположность стриминга – пакетный режим (batch): вы отдаёте системе готовый аудиофайл и ждёте полный транскрипт.

Разница важнее, чем кажется. В пакетном режиме система может увидеть всю запись до того, как зафиксирует хоть одно слово. Она использует то, что идёт после сложного слова, чтобы понять, каким оно было, – так же, как вы перечитываете запутанную фразу до конца, прежде чем понять её первую половину. В потоковом режиме система обязана выдавать текст посреди предложения, не зная, что прозвучит дальше. Это разница между переводом речи, транскрипт которой у вас на руках, и синхронным переводом её вживую в кабине. Стриминг сложнее, и сложнее он именно в том, что напрямую сказывается на пользовательском опыте.

Главное понятие в streaming ASR – различие между частичным (partial) и финальным (final) результатом. Частичный результат – это лучшая текущая догадка системы, и ей разрешено меняться по мере поступления аудио. Финальный результат – слово, на котором система зафиксировалась и которое больше не пересмотрит. Представьте живые субтитры, где текст на миг мерцает и переписывает сам себя, прежде чем устаканиться: мерцающий текст – это поток частичных результатов, а момент, когда он перестаёт меняться, – финал. Каждая потоковая система выбирает между тем, чтобы показывать частичные результаты рано (быстро, но дёргано и иногда неверно) и ждать финалов (стабильно, но медленнее). Понять этот компромисс – почти то же, что понять streaming ASR.

Нажмите, чтобы увеличить

Как речевая модель «слышит»: окно в 30 секунд

Чтобы понять, почему стриминг сложен, нужен один факт о том, как устроены современные речевые модели. Модель вроде Whisper не слушает сырой звук. Сначала аудио превращается в мел-спектрограмму – картину того, как энергия звука распределена по высотам тона во времени, масштабированную примерно под то, как громкость воспринимает человеческое ухо. Если нужны детали аудиоинженерии – что такое мел-спектрограмма и почему она так устроена, – это другая тема, и мы разбираем её в уроке по основам аудио для видео; здесь считайте её «изображением звука, которое модель и читает».

Whisper читает это изображение фиксированными блоками по 30 секунд. Это число зашито в модель: её обучали на 30-секундных окнах, и она ожидает 30 секунд контекста, чтобы работать лучше всего (Radford et al., 2022). Для пакетной расшифровки это нормально – вы режете запись на 30-секундные куски, и модель обрабатывает каждый. Для стриминга это проблема: у вас нет 30 секунд будущего аудио, когда говорящий произнёс лишь три слова. Вы либо ждёте 30 секунд (недопустимая задержка), либо подаёте модели короткое, неполное окно и миритесь с тем, что догадка будет хуже и может измениться.

Это коренная причина почти всех трудностей streaming ASR. Модель хочет контекст; стриминг контекста лишает. Всё дальнейшее – стратегии, как дать модели как можно больше контекста, всё ещё быстро выдавая текст.

Вариант 1 – Whisper, заставленный стримить

Whisper – открытая речевая модель OpenAI, выпущенная в 2022 году под разрешительной лицензией MIT, то есть её можно бесплатно запускать на своих серверах и встраивать в коммерческий продукт (Radford et al., 2022). Это Transformer encoder-decoder: энкодер читает мел-спектрограмму аудио, а декодер пишет текст по одному токену – то же семейство архитектур, что лежит в основе больших языковых моделей. Модель обучали на 680 000 часов аудио, собранного из веба, размеченного через так называемое слабое наблюдение (weak supervision): обучающие пары не проверяли вручную эксперты, а собирали в больших объёмах. Поэтому Whisper необычно устойчив к акцентам, фоновому шуму и 99 языкам – и поэтому же иногда галлюцинирует, выдавая складный текст для аудио, где речи не было, например в долгой тишине.

Загвоздка из прошлого раздела: Whisper по своей сути пакетный. Декодер не задумывался для инкрементальной выдачи текста. Чтобы он стримил, его оборачивают в цикл, который раз за разом прогоняет пакетную модель на растущем буфере аудио и решает, какие слова достаточно стабильны для фиксации. Открытый эталон такого цикла – Whisper-Streaming, опубликованный исследователями Карлова университета в 2023 году (Macháček et al., 2023).

Приём LocalAgreement

Сердце Whisper-Streaming – правило, когда слово безопасно фиксировать, называемое LocalAgreement-2. Идея формулируется в одном предложении: фиксируй слово только когда два последовательных прохода модели на нём сошлись. Система держит буфер недавнего аудио. Каждый раз, когда приходит новый кусок звука, она прогоняет Whisper на всём буфере и получает свежий транскрипт. Затем сравнивает новый транскрипт с предыдущим и находит самый длинный общий префикс – самую длинную с начала цепочку слов, общую для обоих транскриптов. Эти согласованные слова становятся финалами; всё после них остаётся частичным результатом и ждёт подтверждения на следующем проходе.

Это работает, потому что слово, которое два независимых прохода выдают из слегка разного объёма аудио, почти наверняка верно. Слово, что появилось в одном проходе и исчезло в следующем, было догадкой, от которой модель отказалась, услышав больше. LocalAgreement-2 придуман не для Whisper – он пришёл из исследований синхронного перевода и выиграл соревнование IWSLT 2022, – а авторы Whisper-Streaming нашли, что согласование по двум проходам («2» в названии) – золотая середина между скоростью и стабильностью (Macháček et al., 2023).

Несколько вспомогательных приёмов делают цикл практичным. Буфер подрезается при конце предложения, чтобы не вырасти за 30-секундный предел Whisper. Последние 200 подтверждённых слов подаются обратно в модель как подсказка (prompt), давая ей межфразовый контекст, который иначе теряется. А опциональный детектор речевой активности (voice activity detector, VAD) – маленькая дешёвая модель, решающая, есть ли в куске аудио речь вообще, – включается, чтобы пропускать тишину, что улучшает и точность, и стоимость.

Нажмите, чтобы увеличить

Цена в задержке и железе

Числа из статьи Whisper-Streaming – честная отправная точка. На несегментированной длинной английской речи, при запуске большой модели на NVIDIA A40, система достигала средней задержки около 3,3 секунды при минимальном размере куска в одну секунду и WER примерно на 2 процентных пункта хуже, чем та же модель в пакетном режиме (Macháček et al., 2023). Задержка чувствительна к железу и размеру куска: меньший кусок снижает задержку, но даёт меньше контекста, повышая долю ошибок.

Практическая заметка про скорость. Эталонная реализация не запускает оригинальный код OpenAI Whisper; она использует faster-whisper – переписанную версию на движке вывода CTranslate2, которая, по словам авторов, работает примерно вчетверо быстрее стандартной реализации при 16-битной точности (Macháček et al., 2023). Если вы строите стриминг на Whisper, вы почти наверняка запускаете faster-whisper или сопоставимый оптимизированный рантайм, а не ванильную модель: ванильная слишком медленна, чтобы успевать за живым аудио на доступном железе.

Причина выбрать Whisper – контроль и экономика на масштабе. Лицензия бесплатна, модель целиком работает внутри вашей инфраструктуры (что важно для медицинского или регулируемого аудио, которое не может покидать серверы) и поддерживает 99 языков одной моделью. Причина не выбирать – теперь у вас на руках парк GPU, потоковый цикл и бюджет задержки, который облачный API отдал бы вам за пару центов в час.

Вариант 2 – Deepgram, созданный для реального времени

Deepgram – облачный API распознавания речи, спроектированный под стриминг с самого начала, а не пакетная модель, согнутая в потоковую форму. Вы открываете websocket – двустороннее сетевое соединение, которое остаётся открытым, чтобы аудио шло вверх, а текст вниз непрерывно, – подаёте в него куски аудио и получаете обратно частичные и финальные транскрипты. Флагман 2026 года – модель Nova-3.

Числа, которые публикует Deepgram для Nova-3, на переднем крае: около 6,8% WER на потоковом реальном аудио в доменах вроде медицины, финансов и колл-центров, при задержке менее 300 мс (Deepgram, 2026). Поддерживается более 45 языков, есть всё, что нужно продакшен-расшифровке: диаризация дикторов (разметка, кто говорил в каждом сегменте), умное форматирование (превращение «два тридцать» в «2:30») и keyterm prompting (заранее сообщить модели о необычных словах вроде названий продуктов, чтобы она их верно распознала).

По цене Nova-3 в стриминге стоит около $0,0077 за минуту аудио, то есть примерно $0,46 за час (Deepgram, 2026). Deepgram также даёт $200 бесплатных кредитов новым аккаунтам – этого хватит на аудио для сборки и тестирования настоящего прототипа до первой оплаты.

Задача голосового агента: знать, когда говорить

В 2026 году Deepgram выпустил отдельную модель Flux, нацеленную прямо на голосовых агентов – автоматические системы, ведущие устный разговор с человеком. Самое сложное в голосовом агенте – не расшифровать слова, а поймать точный момент, когда человек закончил свою реплику, чтобы агент ответил, не перебивая и не оставляя неловкую паузу. Традиционные системы угадывают это по тишине – ждут полсекунды молчания и считают, что человек закончил, – и это ломается, когда кто-то делает паузу посреди мысли или затихает.

Flux встраивает определение конца реплики (end-of-turn detection) прямо в речевую модель, опираясь на смысл и ритм речи, а не только на тишину, и сообщает решения о конце реплики менее чем за 400 мс (Deepgram, 2026). В апреле 2026 Deepgram расширил Flux до десяти языков с возможностью переключать язык посреди разговора (Deepgram, 2026). Если вы строите голосового агента, а не субтитры или расшифровщик, эта способность к определению реплики часто оказывается решающей – и её открытый цикл Whisper из коробки не даёт.

Вариант 3 – AssemblyAI, созданный под голосовых агентов

AssemblyAI – третий доминирующий облачный вариант, и его потоковый продукт Universal-Streaming вышел в середине 2025 года с голосовыми агентами как явной целью (AssemblyAI, 2025). Он делает одно проектное решение, которое выделяет его и стоит понимания, даже если вы им не воспользуетесь: его транскрипты неизменяемы (immutable) с момента поступления.

Вспомните компромисс «частичный против финального». Большинство потоковых систем выдают изменяемые частичные результаты, которые переписывают сами себя, пока не придёт финал, – и это заставляет разработчика выбирать между действием по быстрым-но-нестабильным частичным результатам и ожиданием медленных-но-стабильных финалов. AssemblyAI переворачивает это: каждое выданное слово финально в момент получения и никогда не пересматривается. Эти неизменяемые слова выдаются примерно за 300 мс, и компания сообщает, что делает это на 41% быстрее по медиане, чем Deepgram Nova-3 – 307 мс против 516 мс на выдачу слова, – и почти вдвое быстрее на 99-м перцентиле (AssemblyAI, 2025). Выгода для голосового агента конкретна: агент может начать «думать» над ответом, пока пользователь ещё говорит, потому что уже полученные слова гарантированно не изменятся.

Universal-Streaming стоит фиксированные $0,15 за час времени сессии, с неограниченным числом параллельных потоков и без доплат за поток (AssemblyAI, 2025). Как и Flux от Deepgram, он встраивает определение конца реплики нативно, комбинируя акустические и семантические признаки с традиционным детектированием тишины. Новый уровень Universal-3 Pro Streaming добавляет диаризацию дикторов в реальном времени (за дополнительные $0,12 в час), keyterm prompting и поддержку 99+ языков, а WER на этом уровне компания оценивает примерно в 6,3% в среднем по английским доменам (AssemblyAI, 2026). AssemblyAI также публикует drop-in интеграции с платформами оркестрации голоса, которые использует большинство команд, – среди них LiveKit и Pipecat, – так что подключение к WebRTC-звонку становится задачей конфигурации, а не исследования. О том, как эти кусочки real-time ИИ собираются внутри живого видеозвонка, см. урок про real-time ИИ в пайплайне WebRTC; о раздаче одного транскрипта многим зрителям – урок про live-субтитры с fan-out на SFU.

Три варианта рядом

Таблица ниже собирает опубликованные числа 2026 года, чтобы сравнивать по осям, которые реально определяют внедрение. Считайте цифры задержки и точности данными вендоров на их собственных тестовых наборах – независимые результаты варьируются по доменам аудио, и единственное число, которое в итоге важно, – то, что вы измерите на своём аудио.

Источники: Macháček et al. (2023); Deepgram (2026); AssemblyAI (2025, 2026).

Разбор на числах – во что обходятся живые субтитры

Числа в отрыве не помогают решению по бюджету, поэтому подставим реальные. Допустим, вы добавляете живые субтитры в вебинарный продукт и ожидаете 2 000 часов потокового аудио в месяц – скажем, 1 000 часовых вебинаров с двумя дикторами или любой эквивалентный набор.

На AssemblyAI Universal-Streaming по $0,15 за час месячный счёт за расшифровку такой:

2 000 часов × $0,15/час = $300 в месяц.

На Deepgram Nova-3 в стриминге по примерно $0,46 за час тот же объём:

2 000 часов × $0,46/час = $920 в месяц.

Теперь путь со своим хостингом Whisper. Модель бесплатна, так что стоимость – это GPU. Один средний облачный GPU-инстанс, способный гонять faster-whisper в реальном времени, стоит порядка $0,50–$1,50 в час аренды, и один такой инстанс тянет несколько параллельных потоков. Но вебинарный продукт не льёт аудио ровно по месяцу – 2 000 часов могут сгуститься в пики рабочего дня, где нужно много инстансов разом и ни одного ночью. Если заложить пик в, скажем, десять параллельных GPU-инстансов по $1,00 в час, и каждый работает в среднем 200 часов в месяц, то:

10 инстансов × 200 часов × $1,00/час = $2 000 в месяц – только в сырой стоимости GPU, до зарплаты инженера, который держит парк на ходу.

Это и есть ловушка, которая ловит большинство команд. На 2 000 часах в месяц облачный API радикально дешевле своего хостинга, потому что вы платите только за реально обработанное аудио, а вендор поглощает стоимость простаивающих мощностей. Свой хостинг выигрывает по цене за час только на очень большом и очень ровном объёме – независимые оценки кладут точку безубыточности куда-то в район сотен тысяч минут в месяц, и только если учесть время инженеров на эксплуатацию. Ниже этой черты «бесплатная модель» – самый дорогой пункт меню.

Частая ошибка – действовать по частичным результатам как по финальным

Самая разрушительная ошибка, которую мы видим, и та, что невидима на демо, – относиться к частичному транскрипту как к зафиксированному финалу. В быстром тесте частичные результаты выглядят отлично: слова появляются быстро и обычно верно. В проде частичный результат, который пересматривается после того, как вы уже по нему действовали, рождает класс багов, мучительных для отладки.

Голосовой агент, который запускает действие в момент, когда частичный результат говорит «отмени мой заказ», отменит заказ даже если пользователь на самом деле сказал «отмени мой заказ – нет, стой, лучше поменяй адрес», потому что ранний частичный результат был зафиксирован до того, как пришла поправка. Функция живого перевода, переводящая каждый частичный результат, выдаёт дёргающуюся, самокорректирующуюся кашу на экране. Инструмент медицинских заметок, сохраняющий частичный результат как запись, может занести слово, от которого модель потом отказалась.

Лечение – точно знать, какие результаты ваш провайдер гарантирует стабильными, и действовать только по ним. У AssemblyAI каждое выданное слово неизменяемо, так что этот баг невозможен – в этом и смысл дизайна. У Deepgram и у цикла Whisper с LocalAgreement нужно дождаться явного финала (Deepgram его помечает; LocalAgreement подтверждает после двух согласных проходов), прежде чем предпринимать необратимое действие, а частичные результаты использовать только для обновления отображения, о котором пользователь понимает, что оно ещё может измениться. Заложите различие «частичный против финального» в модель данных в первый день, а не после первого непонятного инцидента.

Как выбрать – четыре вопроса

Решение сводится к четырём вопросам, по порядку.

Первый: должно ли аудио оставаться на ваших серверах? Если вы обрабатываете медицинские консультации, юридические записи или что угодно под строгими правилами места хранения данных, запрещающими отправлять аудио в сторонний облак, свой хостинг Whisper часто единственный вариант, удовлетворяющий комплаенс, и эксплуатационная стоимость – цена этого комплаенса. Если аудио может покидать серверы, облачный API почти всегда дешевле и быстрее в выводе на рынок.

Второй: вы строите голосового агента или транскрипт? Голосовой агент – всё, что отвечает пользователю – живёт и умирает на определении конца реплики, так что модель, которая его встраивает (Deepgram Flux или AssemblyAI Universal-Streaming), снимает с вас самую сложную инженерную задачу проекта. Функция субтитров или расшифровки, которой никогда не надо «знать, когда говорить», в определении реплики не нуждается и может взять самый простой и дешёвый вариант, попадающий в бюджет задержки.

Третий: каков ваш бюджет задержки? Если слова должны появляться за несколько сотен миллисекунд – для отзывчивого голосового агента или живых субтитров, ощущающихся мгновенными, – реалистичный выбор это облачные API на менее чем 300 мс; цикл Whisper со своим хостингом на многосекундной задержке будет вялым. Если задержка в две-три секунды приемлема – а многие сценарии субтитров и постзвонковой суммаризации её терпят, – Whisper снова на столе.

Четвёртый: какой объём и насколько ровный? На низком или скачкообразном объёме облачные API выигрывают по цене, потому что вы платите только за использованное. На очень большом, ровном объёме, при наличии ML-команды для эксплуатации, свой хостинг может выиграть – но только выше точки безубыточности и только если первые три вопроса вы уже решили в его пользу.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы встраиваем streaming-ASR функции в видеопродукты наших клиентов – живые субтитры для вебинаров и e-learning, расшифровку в реальном времени для телемедицинских консультаций, голосовых агентов и ассистентов встреч для конференц-платформ, поисковые транскрипты для OTT и архивов видеонаблюдения. Повторяющийся урок во всех этих проектах: выбор модели – простая часть; сложная – интеграция: достать чистое аудио из WebRTC-звонка, обработать различие «частичный против финального» без гонок, удержать задержку в обещанном продуктом бюджете и выбрать развёртывание, которое реально допускают правила комплаенса клиента. Мы запускали каждый из трёх описанных вариантов, выбирая их по четырём вопросам выше, а не по тому, у какой модели был лучший бенчмарк в том квартале.

Ключевые выводы

• Streaming ASR расшифровывает живое аудио; ядро компромисса – быстрые частичные против стабильных финалов.
• Whisper по сути пакетный; для стриминга нужен цикл LocalAgreement и свои GPU.
• Deepgram Nova-3 стримит менее чем за 300 мс по ~$0,46/час с широким набором языков и функций.
• AssemblyAI выдаёт неизменяемые транскрипты за ~300 мс по $0,15/час, заточен под голосовых агентов.
• Голосовые агенты живут на определении конца реплики – встроенной функции облачных API.
• Облачные API дешевле своего хостинга везде, кроме очень большого и очень ровного объёма.

Что почитать дальше

• WhisperX подробно – диаризация и пословные таймстемпы
• Диаризация дикторов с Pyannote в проде
• Многоязычный перевод речи в реальном времени в звонках