Перевод речи в реальном времени в 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