Перевод речи в реальном времени в WebRTC-звонке и в наушниках

Кратко

Перевод речи в реальном времени позволяет мгновенно преобразовывать высказывания одного человека на другой язык – достаточно быстро, чтобы поддерживать живой диалог. При этом единый четырёхэтапный процесс работает независимо от источника звука – будь то наушники или видеозвонок: сначала речь распознаётся, затем слова записываются, переводятся и, наконец, озвучиваются или отображаются в виде субтитров. «Наушники с переводом в реальном времени», которые появятся в продаже в 2026 году – AirPods, Pixel Buds, Galaxy Buds – не являются волшебными устройствами: это всего лишь микрофон и динамик, окружающие тот самый конвейер, а всю тяжёлую работу выполняет смартфон или облачный сервер. В многопользовательском WebRTC-звонке этот конвейер размещается на том же медиа-сервере, что и так пересылает аудио всех участников – на SFU – что позволяет перевести речь каждого говорящего один раз и разослать результат каждому слушателю на его родном языке. В статье подробно описан весь путь от начала до конца: четыре этапа, почему переведённый текст обновляется по мере поступления новой речи, допустимая задержка, под которую проектируется система, где расположен конвейер в звонке и какова его стоимость в минуту.

Почему это важно

Язык – последний серьёзный барьер в живом видео. Если ваш продукт собирает людей в звонок – глобальный вебинар, телемедицинскую консультацию с пациентом, говорящим на другом языке, виртуальный класс или линию поддержки – перевод решает, смогут ли вообще участвовать половина ваших потенциальных пользователей. Инженерные вопросы конкретны, и у каждого есть дорогой неправильный ответ: где работает перевод, какую задержку готовы терпеть пользователи, услышат ли слушатели синтезированный голос или прочитают субтитры, и каков будет счёт за минуту на язык. Эта статья – для продакт-менеджера, основателя или техлида, которому нужно описать функцию перевода, поставить реалистичную цель по задержке и обсудить её с инженерами, не утонув в аббревиатурах. Мы используем потребительские наушники с переводом как точку входа – потому что все уже видели, как они работают, – а затем показываем ту же самую механику внутри WebRTC-звонка. О движках перевода по отдельности – с разбором по вендорам – читайте в сравнении систем перевода речи; эта статья – про архитектуру вокруг них.

Что на самом деле значит «перевод речи в реальном времени»

Начнём с самого предмета, потому что за словом «перевод» скрываются четыре отдельные задачи, идущие одна за другой, и почти все дальнейшие решения связаны с тем, как их расставить.

Представьте, что кто-то говорит по-испански в микрофон, а вам, говорящему по-английски, нужно следить за разговором в реальном времени. Чтобы это сработало, должны произойти четыре вещи.

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

Далее система должна перевести полученный текст с испанского на английский – это задача машинного перевода, или MT. Это тот же движок, что лежит в основе веб-переводчика, но оптимизированный под высокую скорость.

Наконец, система должна доставить результат вам – либо в виде текста на экране, либо озвученным голосом. Для этого используется синтез речи, или TTS – программа, превращающая письменные слова в естественно звучащий звук.

Классическая форма – это цепочка: звук → ASR → MT → TTS → звук. Инженеры называют её каскадом, потому что каждая ступень передаёт свой результат следующей, словно вода стекает по ступеням. Держите эту картину в голове – она станет основой всей статьи.

Есть и вторая, более новая форма – её стоит назвать сразу, потому что она меняет правила игры. Вместо трёх отдельных движков одна модель может принять речь на одном языке и выдать речь на другом напрямую, не записывая слова по пути. Это называется прямым переводом речь-в-речь, или S2ST, и модели Seamless от Meta, Realtime API от OpenAI и Gemini Live от Google – примеры 2026 года. Мы сравним обе формы «лоб в лоб», как только разберёмся с деталями. Пока запомните: каскад – это три движка подряд, а прямая модель – один движок, выполняющий весь переход.

Ваши наушники – это WebRTC-звонок, который вы не видите

Люди ищут именно «наушники с переводом в реальном времени» – с них и начнём. А потом откроем занавес: на самом деле наушники – самый простой способ понять разговор по телефону.

Когда вы носите наушники с функцией перевода, а собеседник напротив говорит, происходит следующее. Микрофон наушника улавливает его голос и передаёт сигнал на более мощный компьютер – ваш телефон или сервер, с которым он связан. Этот компьютер запускает стандартный четырёхэтапный процесс: ASR распознаёт речь, MT переводит текст, TTS озвучивает результат, и переведённая речь поступает вам в ухо. Сам наушник ничего не переводит. Он выступает лишь как микрофон и динамик – уши и рот, подключённые к «мозгу», который находится где-то в другом месте. «Волшебный наушник» – это маркетинговая метафора; с инженерной точки зрения он представляет собой всего лишь аудиоинтерфейс перед конвейером перевода.

Этот единственный факт и есть причина, по которой наушники и видеозвонки – одна и та же задача. WebRTC-звонок – а WebRTC – это стандартная технология, позволяющая браузерам и приложениям передавать друг другу живой звук и видео, – тоже сводится к передаче аудио между точками в конвейере. Замените микрофон наушников на микрофон ноутбука участника, динамик – на наушники других участников, и механика обработки сигнала в середине останется прежней.

Где наушники 2026 года действительно отличаются друг от друга – это где сидит мозг, и это реальный инженерный выбор, который встанет и перед вами. Apple Live Translation, представленный с iOS 26 для AirPods Pro 2 и новее, скачивает языковые модели на iPhone и обрабатывает весь конвейер на устройстве, так что разговор не покидает телефон – приватно, но ограничен языками и вычислительными возможностями самого телефона. Системы Google Pixel и Samsung Galaxy используют связку «телефон плюс облако»: у Google она работает на моделях Gemini и поддерживает более 70 языков, сохраняя интонацию говорящего. Компромисс – старейший в этой области: на устройстве – приватность и работа без интернета, но ограниченность «железом»; в облаке – больше мощности и языков, но передача звука за пределы устройства и зависимость от сети. Та же дилемма встанет перед вами, когда вы решите, где будет работать конвейер в вашем продукте – на клиенте или на сервере.

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

Каскад против прямой модели: два способа собрать мозг

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

Каскад объединяет три специализированных движка последовательно: ASR распознаёт речь, MT переводит текст, TTS озвучивает результат. Его сильные стороны – в этом разделении. Вы можете выбрать лучший распознаватель речи под ваш аудиоформат, лучший переводчик под нужную языковую пару и лучший голос под ваш бренд – и при этом заменить любой из компонентов, не затрагивая остальные. Вы можете извлекать текст на каждом этапе, чтобы логировать его, бесплатно показывать субтитры, пропускать через глоссарий имён собственных вашего продукта и точно определить, на каком этапе возникла ошибка. Эта отлаживаемость – причина, по которой, как показывает наше сравнение вендоров, каскады выигрывают тендеры, даже когда прямые модели побеждают в демо.

Слабости каскада тоже связаны с разделением. Ошибки накапливаются: если ASR не распознал слово, MT добросовестно переведёт неправильное, а TTS уверенно его озвучит. Каждая ступень добавляет задержку, так что общее отставание складывается из времени работы трёх движков и сети между ними. А эмоция исходного говорящего – темп, ударение, интонационный подъём в вопросе – теряется в тот момент, когда речь превращается в плоский текст, поэтому синтезированный голос в итоге звучит ровно, если над этим не поработать.

Прямая модель, преобразующая речь в речь за один проход, как раз устраняет эти слабые места. Отсутствие текстовой стадии в середине позволяет сократить задержку с трёх до одного этапа, уменьшает количество точек, где могут накапливаться ошибки, и – в выразительных вариантах, таких как SeamlessExpressive от Meta – обеспечивает передачу интонации говорящего, а иногда и самого его голоса, до самого выхода. Платой за это становится потеря «шва» – промежуточного результата, который можно было бы проверить. Нет чистого текстового представления, пригодного для логирования, субтитрирования или редактирования глоссария, что делает прямую модель сложнее в аудите и затрудняет соответствие требованиям в регулируемых отраслях, например, в здравоохранении. Два подхода складываются следующим образом:

Читайте по своему продукту. Телемед-платформе, которой нужны письменные записи и аудит, подходит каскадная архитектура. Для звонка между двумя людьми, где важно, чтобы собеседник казался говорящим на вашем языке, нужна прямая модель. Многие продакшен-системы хеджируют: используют каскад как надёжную основу для субтитров и контроля, а прямую модель – на тех языковых парах, где естественность голоса имеет решающее значение. Подробнее о самих движках – Seamless, OpenAI Realtime API, Gemini Live – в статье про речь-в-речь.

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

Перевод, который переписывает себя

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

Корень проблемы – в том, что языки используют разный порядок слов. Например, в немецком главном глаголе часто отводится место в конце предложения. Если система начинает переводить первую часть фразы сразу, как только её услышала, она вынуждена угадывать, какой глагол будет использоваться. Когда же настоящий глагол наконец появляется, ранний перевод может оказаться неверным и потребовать переписывания. Живой синхронный переводчик сталкивается с тем же давлением и решает его, немного задерживаясь: он отстаёт от говорящего на пару секунд, удерживая начало предложения в памяти, пока не накопится достаточно информации для безопасного перевода. Переводчики называют этот временной зазор отставанием (ear-voice span), и исследования показывают, что оптимальный диапазон составляет от двух до шести секунд, при этом три секунды считаются золотой серединой. Подождать слишком мало – и можно перевести не то; подождать слишком долго – и разговор застопорится.

Софт сталкивается с тем же компромиссом, и у него есть название: политика read-write (читать или писать). В каждый момент система решает: читать – ждать ещё входящей речи, – или писать – приступать к переводу уже имеющегося. Простейшее правило, называемое wait-k, – держаться на фиксированное число слов позади говорящего, ровно как трёхсекундное отставание переводчика. Умнее, адаптивные политики ждут дольше, когда предложение двусмысленно, и приступают раньше, когда оно ясно.

Вот почему ваш клиентский код должен обрабатывать входящий перевод так же, как код живых субтитров – как черновую догадку: как строку, которая заменяет текущую незавершённую, а не добавляется под ней, пока система не пометит её финальной. Команды, добавляющие каждую правку, получают субтитры, которые дергаются и повторяются; команды, заменяющие до финала, – чистое, стабильное поведение, которого ждут пользователи. Если вы строите и речевой путь, нестабильность становится острее: ведь TTS уже произнёс переведённую фразу вслух, и отозвать её нельзя. Поэтому речевой путь должен дождаться более стабильного входа, чем путь субтитров, прежде чем начать работу. Дисциплина та же, что мы описываем для черновика против финала в живых субтитрах; перевод просто повышает ставки, потому что изменение порядка слов может затронуть большую часть строки.

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

Бюджет задержки вслух

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

Переведённая фраза проходит шесть этапов. Звук говорящего отправляется туда, где работает конвейер (десятки миллисекунд на приличной сети). ASR распознаёт речь и выдаёт первые слова. MT переводит их. TTS генерирует первый фрагмент озвученного звука. Этот звук возвращается к слушателю. Наконец, устройство слушателя воспроизводит его. Подставим представительные числа 2026 года для потокового каскада:

задержка перевода ≈ 80 мс (звук на сервер)
                  + 300 мс (ASR первый черновик)
                  + 150 мс (MT)
                  + 400 мс (TTS первый кусок)
                  + 60 мс (звук обратно)
                  + намеренное отставание read-write
задержка перевода ≈ 1,0 с машинной работы, плюс ~2-3 с, что вы держите специально

Из этой суммы выпадают два урока. Первый: намеренное ожидание – задержка, которую вы вводите, чтобы порядок слов успел устояться, – как правило, больше, чем вся машинная задержка в совокупности. Инженерная цель – не нулевая задержка; речь идёт о честной, стабильной задержке, отражающей работу живого переводчика. Второй: самым затратным компонентом системы является TTS, потому что произнесение слов требует времени. Один опубликованный разбор 2026 года показывает, что большая часть вычислений в каскаде приходится на этап TTS, а самое ценное улучшение – стримить озвученный вывод по частям, а не ждать завершения всего предложения.

Полезно привязать эти цифры к порогам, о которых уже договорились в отрасли. Стандарт обычного качества голоса – Рекомендация ITU-T G.114 – устанавливает комфортную одностороннюю задержку «рот-ухо» для прямого разговора на уровне ниже 150 миллисекунд. Стандарт профессионального удалённого синхронного перевода от ассоциации переводчиков AIIC определяет устойчивый верхний предел задержки «конец-в-конец» в три–пять секунд. Между этими крайностями практическое правило, к которому приходят как вендоры, так и наши собственные измерения, звучит просто: если первое переведённое слово появляется быстрее примерно 800 миллисекунд – оно ощущается живым; задержка от 800 миллисекунд до 1,5 секунды допустима для лекции или доклада; а при превышении двух секунд слушатели начинают говорить поверх перевода. Версию этой методики, применённую ко всему разговору, мы разбираем в статье про бюджет задержки до 100 миллисекунд; здесь она адаптирована к одному переведённому слову.

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

Как подключить конвейер к WebRTC-звонку

Всё до сих пор работает для одного слушателя. Групповой звонок добавляет интересный аспект и использует компонент, который вы, скорее всего, уже имеете. В звонке с более чем двумя участниками звук не передаётся напрямую между всеми – он проходит через медиа-сервер в центре, называемый Selective Forwarding Unit, или SFU. Этот сервер принимает один аудиопоток от каждого участника и пересылает нужные потоки остальным. О нём и о браузерных механизмах вокруг него мы подробно рассказываем в статье про интеграцию ИИ в WebRTC.

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

Этот вывод доходит до слушателей в одной из двух форм – и часто используются обе. Первая – переведённые субтитры: текст, передаваемый по data channel WebRTC – стандартному боковому каналу для передачи произвольных данных между участниками, описанному в IETF RFC 8831. Субтитры недороги в доставке, легко синхронизируются и позволяют каждому молча читать на своём языке. Вторая – переведённый звук: синтезированный голос, созданный с помощью TTS и вставленный обратно в звонок как новая аудиодорожка, передаваемая тем же кодеком Opus (IETF RFC 6716), что и основной голосовой поток. Звук воспринимается естественнее, но создаёт проблему, которой нет у субтитров: слушатель может слышать одновременно два голоса – оригинального говорящего и перевод. Решение – приглушить оригинал: автоматически понизить его громкость, пока звучит перевод, чтобы тот был на переднем плане, а оригинал оставался тихим фоном – как дубляж в кино оставляет след за голосом актёра.

Ещё одна тонкость, делающая всё это доступным по цене, – это тот же механизм, что управляет субтитрами: вы не переводите каждый аудиопоток постоянно. Дешёвый детектор под названием Voice Activity Detection – программа, отвечающая на вопрос «говорит ли кто-то в этом потоке прямо сейчас?» – включает дорогой конвейер только тогда, когда кто-то действительно говорит. Поскольку на реальной встрече одновременно говорят один-два человека, стоимость зависит от активных участников, а не от количества мест. Подробно этот механизм описан в статье про fan-out живых субтитров; здесь он ещё важнее, потому что конвейер перевода стоит в минуту дороже, чем простая расшифровка.

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

Стоимость вслух

Причина, по которой архитектура важна с коммерческой точки зрения, – это число, которое можно посчитать одной строкой. Посчитаем его. Конвейеры перевода тарифицируются за минуту обработанного звука – и вот в чём подвох: обычно за языковую пару, а не за сессию. Потоковый каскад в 2026 году попадает в грубый диапазон $0,08–$0,20 за минуту исходного звука при умеренном объёме; сильно оптимизированный self-hosted стек может снизить стоимость до пары центов.

Возьмём часовой общий созвон с одним активным докладчиком, транслируемый слушателям ещё на трёх языках. Работа сводится к одному конвейеру перевода на целевой язык, который работает только во время выступления. С VAD-гейтингом, ограничивающим время активной речи примерно до одного часа для одного докладчика, и тарифом $0,12 за минуту:

стоимость = 3 целевых языка × 60 мин × $0,12/мин
стоимость = 180 язык-минут × $0,12
стоимость = $21,60 за часовое мероприятие

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

Частая ошибка: начать переводить слишком рано

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

Потом система сталкивается с реальным предложением на языке с инвертированным порядком слов и даёт сбой. Она озвучивает вслух: «У меня есть посылка», но затем приходит немецкий глагол, и правильное предложение оказывается: «Я отправил посылку обратно» – однако голос TTS уже начал произносить неверный вариант, и отменить это нельзя. Слушатель слышит уверенный, беглый, неправильный перевод, который хуже чуть более медленного, но точного, потому что у него нет способа понять, что перевод был предварительным. Решение – дисциплина read-write из предыдущего раздела: пусть речевой путь ждёт стабильного, окончательного сегмента, прежде чем озвучивать его, даже если это займёт лишние одну-две секунды, а быстрые черновые обновления оставьте для пути субтитров, где замена незавершённой строки незаметна и безвредна. Быстрота – не цель; достойная доверия отзывчивость – вот что важно. Перевод, на который пользователи не могут положиться, хуже его полного отсутствия, потому что он подводит молча.

Строить на фреймворке, покупать API или и то, и другое

Когда паттерн устоялся, практический вопрос – из чего его собирать, и насколько слои независимы.

Медиа-слой – это сам звонок. Можно использовать open-source SFU, например mediasoup, Janus или сервер LiveKit, и управлять аудиозаписью и вставкой дорожек самостоятельно, либо воспользоваться хостинговой real-time платформой, которая передаёт звук участников и позволяет публиковать новые дорожки обратно с минимальной обвязкой. LiveKit, в частности, рассматривает серверный агент перевода как полноценного участника – именно поэтому он так часто появляется в продакшен-решениях для перевода.

Слой конвейера – это движок перевода, и здесь вы почти всегда покупаете или размещаете модель, а не создаёте её с нуля. Вариант каскада означает использование потокового движка ASR, движка машинного перевода и потокового голоса TTS, каждый из которых можно заменить. Вариант прямого перевода – это единая модель «речь-в-речь»: например, самостоятельно размещаемый Seamless от Meta для хранения данных на месте и отсутствия поминутной оплаты при масштабировании, либо API OpenAI Realtime и Gemini Live для управляемого решения, причём последнее в 2026 году будет заметно дешевле по минутной ставке. Честное правило выбора, основанное на нашем сравнении вендоров, зависит от объёма: при нагрузке ниже примерно шестидесяти одновременных потоков облачные API выигрывают по общей стоимости владения; при значительно большем объёме окупается self-Hosting, и решающим фактором обычно становится не экономия, а требования комплаенса.

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

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

Мы создаём живые видеопродукты, где перевод устраняет жёсткий барьер – глобальные платформы вебинаров и конференций, телемедицинские консультации между языками, e-learning для международных групп и инструменты удалённого синхронного перевода. Мы строим систему перевода на стороне SFU, описанную в этой статье, потому что именно она выдерживает реальную нагрузку и проходит проверку заказчиком-аудитором.

Дисциплина, которую мы применяем, основана на следующих принципах: каждый говорящий переводится один раз на медиа-сервере, который вы и так используете; конвейер активируется голосовой активностью, чтобы стоимость зависела от говорящих, а не от количества участников; результат раздаётся по языку слушателя – субтитры через data channel и опционально приглушённый звук; задержка read-write настраивается так, чтобы перевод был точным, а не быстрым и ошибочным.

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

Главное

• Перевод в реальном времени проходит четыре этапа: распознавание речи (ASR), перевод (MT), синтез речи или генерация субтитров (TTS).
• Наушники с переводом – это микрофон и динамик, подключённые к конвейеру обработки; вычисления выполняются на телефоне или в облаке.
• Каскадная архитектура даёт доступ к промежуточному тексту и бесплатным субтитрам; прямая модель снижает задержку и сохраняет интонацию голоса.
• Вживую перевод постоянно корректируется, поскольку языки отличаются порядком слов – незавершённую строку нужно заменять до окончания высказывания.
• Намеренная задержка, как у живого переводчика (~2–3 с), обычно превышает суммарную задержку всей машинной обработки.
• В групповом звонке перевод выполняется один раз на сервере SFU и раздаётся участникам на нужный язык; VAD-детектор помогает контролировать нагрузку и стоимость.

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

• Перевод речи в реальном времени во время звонков
• Речь в речь – Realtime API, Gemini Live, SeamlessM4T
• Живые субтитры – паттерн fan-out ASR на стороне SFU