Speech-to-speech – Realtime API, Gemini Live, SeamlessM4T

Автор: Николай СапуновОбновлено: август 202632 мин чтения
Содержание статьи +

Коротко

Speech-to-speech – это система, которая воспринимает устную речь и отвечает голосом, при этом ей не нужен промежуточный текстовый этап; это максимально близкое к естественному разговору, что может предложить программное обеспечение. Такие системы можно построить двумя способами: традиционный подход объединяет три отдельные модели (распознавание речи, обработка и синтез), а современный использует единую модель, выполняющую все задачи одновременно – она работает быстрее и лучше сохраняет «человечность» голоса, но сложнее в тестировании и исправлении. В статье мы разберём обе архитектуры, а затем рассмотрим три системы, определяющие ландшафт 2026 года: OpenAI Realtime API (единая speech-to-speech-модель, доступная через WebRTC, WebSocket или телефонную сеть), Google Gemini Live (модель с нативным аудио, стоимость минуты которой заметно ниже, чем у OpenAI) и Meta SeamlessM4T (открытая модель для речевого перевода примерно на 100 языков). К концу статьи вы поймёте, какая архитектура подходит вашему продукту, сколько на самом деле стоит минута разговора и какие две ошибки – измерение не той задержки и игнорирование обработки перебиваний – губят большинство первых прототипов.

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

Если ваш продукт будет вести голосовой диалог – ассистент на совещании, который отвечает вслух, приёмная линия в телемедицине, голосовой агент поддержки, синхронный переводчик в видеозвонке или языковой репетитор – вы рано или поздно столкнётесь с ключевым решением, от которого зависят задержка, стоимость и возможность дальнейшей отладки системы. Это решение: использовать единую модель speech-to-speech или собрать систему из отдельных компонентов – распознавания речи, языковой модели и синтеза речи.

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

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

Что такое «speech-to-speech» на самом деле

Начнём с простейшего определения. Система speech-to-speech, сокращённо S2S, принимает на вход звуковой сигнал речи и выдаёт на выходе звуковой сигнал речи. Вы говорите – она отвечает. За этой общей формой скрываются две разные задачи, и их важно сразу разделить, потому что к этому различию мы будем возвращаться на протяжении всей статьи.

Первая задача – разговор: вы задаёте вопрос на английском, и система отвечает на английском, как голосовой ассистент. Вторая задача – перевод: вы говорите на английском, а система произносит тот же смысл на испанском, как синхронный переводчик. Обе системы принимают голос и выдают голос, поэтому обе относятся к типу «speech-to-speech», но их устройство и лидеры рынка различаются. OpenAI Realtime API и Google Gemini Live ориентированы в первую очередь на диалог; Meta SeamlessM4T – на перевод. Мы будем чётко различать, что есть что.

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

Два способа построения: связать три модели или использовать одну

Любой продукт speech-to-speech строится одним из двух способов, и выбор определяет всё остальное. Разберём работу на три этапа. Сначала – услышать: преобразовать входящий звук в данные, с которыми машина может работать. Затем – подумать: решить, что ответить. И наконец – сказать: превратить это решение обратно в звук.

Старый, более распространённый способ предполагает использование для каждого шага отдельной специализированной модели. Модель распознавания речи – программное обеспечение, превращающее устную речь в письменный текст, сокращённо ASR (automatic speech recognition) – отвечает за «услышать». Языковая модель – та, что лежит в основе чат-бота, – отвечает за «подумать»: она анализирует текст и генерирует на его основе ответ. Модель синтеза речи, сокращённо TTS (text-to-speech), отвечает за «сказать»: она преобразует этот текстовый ответ обратно в звук. Инженеры называют такую последовательность каскадом или пайплайном, потому что выход одной модели поступает на вход следующей, как вода, стекающая по ступеням.

Новый способ объединяет все три этапа в одну модель, которая принимает звук и сразу выдаёт звук, минуя промежуточный текстовый этап. OpenAI называет такой подход «speech-to-speech-моделью» и подчёркивает: в отличие от традиционных пайплайнов, где распознавание и синтез речи работают отдельно, эта модель «обрабатывает и генерирует аудио напрямую через одну модель и один API», что «снижает задержку, сохраняет нюансы речи и даёт более естественные, выразительные ответы» (OpenAI, 2025). Исследователи называют её end-to-end-моделью – «от края до края», поскольку одна модель решает всю задачу целиком.

Вот аналогия, которая делает компромисс понятным. Каскад – это эстафета: три бегуна, каждый отлично справляется со своим этапом, но каждая передача палочки требует времени, а палочку можно уронить. End-to-end-модель – это один бегун, проходящий весь путь: меньше передач, быстрее, и он сохраняет интонацию и эмоции до самого финиша, которые теряются при передаче палочки. Цена – нельзя заменить одного слабого бегуна: вы получаете либо всего бегуна, либо никого.

Рис. 1. Каскадная архитектура объединяет три специализированные модели с промежуточным текстом между ними; end-to-end-модель выполняет всю обработку за один проход, жертвуя прозрачностью ради скорости и естественности.

Почему каскад до сих пор выигрывает у многих команд

Легко решить, что новая end-to-end-модель просто лучше. В 2026 году это не так. Для большинства продакшен-внедрений каскадный пайплайн остаётся выбором по умолчанию, поскольку обеспечивает прозрачность, отладку и возможность заменить любой компонент, не затрагивая остальные (Coval, 2026). Если система дала неверный ответ, можно проследить текст на каждом этапе и понять, где именно произошла ошибка – на этапе «услышать», «подумать» или «сказать». У end-to-end-модели нет промежуточного читаемого текста, поэтому выявить проблему сложнее.

Каскад позволяет выбрать лучшую модель для каждого этапа: наиболее точное распознавание, самую умную языковую модель, самый естественный голос – от разных поставщиков. End-to-end-модель – это единая точка зрения одного вендора на все три задачи сразу, и тогда вы вынуждены мириться с её самым слабым звеном. Это и есть vendor lock-in – ситуация, когда сложно или невозможно легко перейти к другому поставщику.

Почему end-to-end выигрывает, когда важна целостность восприятия

End-to-end-модель выигрывает по двум параметрам, где каскадные системы терпят неудачу: скорости и естественности. Отсутствие промежуточных этапов снижает задержку. Модель не преобразует ваш голос в текст и обратно, поэтому сохраняет всё, что теряется при таком переводе: смех, паузы, вопросительную интонацию, акцент. End-to-end speech-to-speech-модели отвечают мгновенно и естественно справляются с сменой реплик, поддакиванием и перебиваниями, тогда как каскадные пайплайны дают более точные ответы, но с задержкой, растущей по мере увеличения размера модели (Coval, 2026). В премиальной поддержке, в приложениях-компаньонах или там, где эмоциональная окраска голоса – это сам продукт, такая естественность оправдывает потерю прозрачности.

Число, которое решает, живой ли разговор

Есть одно число, которое отличает настоящий разговор от общения, напоминающего голосовое меню, – и его легко измерить. Правильная метрика – задержка от голоса до голоса (voice-to-voice): промежуток времени между тем, как вы перестали говорить, и тем, как услышали первый звук ответа. Это та тишина, которую реально переживает собеседник.

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

Что достижимо сегодня? OpenAI сообщает, что с Realtime API можно достичь задержки около 800 миллисекунд от начала речи до ответа голосом, при этом время до первого байта от модели составляет примерно 500 миллисекунд в регионах США. Это оставляет около 300 миллисекунд на захват звука с микрофона, определение окончания речи, передачу аудио по сети и воспроизведение ответа (OpenAI, 2026). Обратите внимание на структуру этого временного бюджета: модель занимает лишь половину времени. Вторая половина – это всё, что происходит вокруг модели, и именно на этом этапе команды часто допускают ошибки.

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

общий бюджет от голоса до голоса   = 800 мс   (цель «ощущается живым»)
   время до первого байта модели   − 500 мс   (задержка API, регион США)
   ───────────────────────────────────────────
   всё остальное                   = 300 мс   (захват + определение конца реплики
                                                + сетевые задержки + воспроизведение)

Эти 300 миллисекунд должны покрыть буфер микрофона, момент определения, что вы закончили говорить, задержку передачи данных до дата-центра и обратно, а также время запуска воспроизведения в наушниках слушателя. Если пользователи находятся далеко от региона с моделью, сеть может «съесть» почти всё это время. Поэтому утверждение «модель быстрая» – это не полный ответ, и выбор канала связи, о котором речь ниже, влияет на производительность не меньше, чем сама модель.

Рис. 2. Бюджет задержки от голоса до голоса – 800 мс. Модель занимает примерно половину времени; остальное приходится на захват, определение конца реплики, сетевой обмен и воспроизведение.

Три способа подключения: браузер, сервер или телефон

Speech-to-speech-модель живёт в дата-центре; голос пользователя начинается у микрофона где-то ещё. Путь между ними – транспорт – это реальный инженерный выбор с реальными последствиями для задержки, и ведущие API дают три варианта. OpenAI Realtime API поддерживает все три: WebRTC, WebSocket и SIP (OpenAI, 2025).

Первый – WebRTC, браузерная технология, разработанная специально для передачи живого аудио и видео между двумя точками и изначально спроектированная с учётом минимальной задержки. Используйте её, когда аудио захватывается или воспроизводится непосредственно в браузере или мобильном приложении – то есть когда устройство пользователя выступает одной из сторон соединения. Рекомендация OpenAI однозначна: для браузерных и мобильных клиентов, которые сами захватывают или воспроизводят аудио, следует использовать WebRTC (OpenAI, 2026).

Второй вариант – WebSocket, более простое постоянное соединение между двумя серверами. Используйте его, когда аудио уже поступает на ваш собственный сервер – например, из телефонной системы или вещательного потока, входящего в ваш бэкенд, – и вы хотите передать его модели. Рекомендация OpenAI: для серверных медиапайплайнов, таких как телефонные звонки или вещательный ингест, используйте WebSocket (OpenAI, 2026).

Третий – SIP, протокол публичной телефонной сети, та самая «сантехника» за каждым офисным телефоном. OpenAI добавила прямую поддержку SIP, чтобы голосовой агент мог отвечать на настоящий телефонный звонок, подключаться к офисным АТС и дозваниваться до других телефонных конечных точек без необходимости строить мост самостоятельно (OpenAI, 2025). Если ваш продукт – телефонная линия, вот ваша дверь.

Рис. 3. Выбирайте транспорт в зависимости от того, где находится аудио: на устройстве пользователя (WebRTC), на вашем сервере (WebSocket) или в телефонной сети (SIP).

Самое трудное, что не показывают в демо: уметь вовремя говорить

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

Первый – определение голосовой активности (voice activity detection, сокращённо VAD): небольшой и быстрый компонент, чья единственная задача – отличать речь от тишины и фонового шума. Именно он фиксирует, что вы начали говорить, и, что важнее, замечает, что вы закончили. Определение окончания реплики называют end-of-turn detection (обнаружение конца высказывания), и это сигнал, дающий агенту понять: «Теперь твоя очередь». Слишком короткий порог тишины заставляет агента перебивать вас на полуслове; слишком длинный – делает каждый ответ вялым и затянутым. Комбинация VAD с уверенностью модели распознавания повышает точность этого решения (Coval, 2026). Фоновый шум усложняет задачу – поэтому к speech-to-speech-функции часто добавляют подавление шума в реальном времени, о чём есть отдельный урок: чистый звук даёт VAD более чёткий сигнал.

Второй – обработка перебиваний, часто называемая barge-in: что происходит, когда пользователь начинает говорить, пока агент ещё говорит. Люди перебивают постоянно, и система, которая это игнорирует, ощущается сломанной. В каскадном пайплайне обработка – это явная работа: когда VAD ловит речь пользователя посреди фразы агента, он запускает событие перебивания, которое немедленно останавливает аудио агента, выбрасывает уже поставленный в очередь на воспроизведение звук и перезапускает проход слушания (Coval, 2026). End-to-end-модели обычно справляются со сменой реплик, поддакиванием и перебиваниями естественнее, потому что одна модель училась на ритме настоящего диалога, а не получила обработку перебиваний прикрученной задним числом (Coval, 2026). Эта врождённая беглость – один из сильнейших доводов взять end-to-end-модель, когда разговор должен ощущаться человеческим.

«Частая ошибка. Самая частая причина, по которой голосовой агент, «работавший в демо», падает в проде, – не модель, а определение конца реплики и barge-in. Команды настраивают порог тишины на своей чистой речи в тихой комнате, а потом запускают систему для пользователей с акцентами, фоновым шумом и привычкой делать паузы посреди фразы, чтобы подумать. Агент начинает обрывать людей. Всегда тестируйте определение конца реплики на реальном, «грязном» аудио ваших настоящих пользователей, прежде чем доверять порогу, и закладывайте инженерное время на обработку перебиваний как на полноценную фичу, а не как на финальную полировку.»

Три системы, определяющие 2026 год

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

OpenAI Realtime API – движок для диалогов в продакшене

OpenAI Realtime API – самая массово развёрнутая система голосового общения в формате speech-to-speech в 2026 году. Она стала общедоступной (то есть стабильной и поддерживаемой для коммерческого использования, а не экспериментальной) одновременно с моделью gpt-realtime – первой общедоступной speech-to-speech-моделью OpenAI, способной отвечать на аудио- и текстовые запросы через WebRTC, WebSocket или SIP (OpenAI, 2025). В течение 2026 года семейство API расширилось: в текущей документации указаны gpt-realtime-2 для голосовых агентов, отдельный gpt-realtime-translate для живого перевода и gpt-realtime-whisper для потоковой транскрипции, а новейшие голосовые модели способны рассуждать, переводить и транскрибировать прямо в процессе прослушивания (OpenAI, 2026; 9to5Mac, 2026).

Модель заметно превосходит версию декабря 2024 года, которую заменила. На бенчмарке Big Bench Audio, оценивающем способность рассуждать по аудиовходу, gpt-realtime набирает 82,8% против 65,6% у предыдущей модели; по следованию инструкциям – 30,5% против 20,6%; по вызову функций – способности модели запускать инструменты приложения в нужный момент – 66,5% против 49,7% (OpenAI, 2025). Последние два показателя особенно важны для реальных продуктов: агенту поддержки нужно дословно зачитать дисклеймер и вовремя проверить заказ, и обе эти способности значительно улучшились.

API также доступен через Microsoft Azure под названием «GPT Realtime API», поэтому команды, работающие в Azure, могут внедрить его, не покидая своё облако (Microsoft, 2026).

Gemini Live – нативное аудио по цене, рассчитанной на масштаб

Ответ Google – Gemini Live, режим живого разговора моделей Gemini. Его ключевая техническая идея – нативное аудио: одна модель обрабатывает сырой звук напрямую, а не преобразует его сначала в текст, и именно это позволяет сократить задержку (Google Cloud, 2026). В API живые модели принимают текст, изображения, аудио и видео и предназначены для низкозадержного диалога «туда-обратно», который осуществляется по WebSocket-соединению (Google, 2026).

Причина, по которой Gemini Live фигурирует в каждом сравнении «строить или покупать» 2026 года, – цена. Аудио тарифицируется по токенам звука: входное аудио оценивается в 32 токена в секунду, выходное – в 25 токенов в секунду (Google, 2026). На больших объёмах такая токенная модель оказывается заметно дешевле поминутного тарифа OpenAI – независимые сравнения 2026 года показывают, что стоимость входного аудио у Gemini примерно на порядок ниже, чем у OpenAI, при интенсивной голосовой нагрузке (Finout, 2026). Если ваш продукт обрабатывает миллионы минут разговоров, эта разница становится границей между функцией, которая окупается, и той, что остаётся убыточной. Точные цифры – в разделе о стоимости ниже.

SeamlessM4T – открытая модель перевода, которую можно использовать локально

Meta SeamlessM4T выделяется – и намеренно: она создана для перевода, а не для общения, и является open-weights, то есть обученная модель опубликована и может быть скачана и запущена на локальном оборудовании. Вторую версию выпустила команда Seamless Communication в Meta – это единая модель, выполняющая речевой перевод, распознавание речи, синтез речи и обычную транскрипцию на широком наборе языков: примерно 101 язык поддерживается на входе, а прямой речевой перевод на выходе доступен для десятков языков (Meta AI, 2023; Hugging Face, 2026).

Внутри это, по сути, каскад, скрытый в одном пакете: речевой энкодер на основе 24-слойной модели wav2vec-BERT, предобученной на 4,5 миллионах часов аудио, текстовый декодер, заимствованный из переводной модели Meta NLLB, и неавторегрессионный декодер единиц под названием UnitY2, который генерирует звуковые единицы переведённой речи, которые затем обрабатываются вокодером, превращающим их в слышимый аудиосигнал (Meta AI, 2023). UnitY2 – и есть главный прорыв v2: он предсказывает речевые единицы быстрее и эффективнее по использованию данных, чем v1, улучшая как качество, так и скорость (Hugging Face, 2026).

Подвох – в лицензии. SeamlessM4T выпущена под CC-BY-NC, где «NC» означает non-commercial (некоммерческая). Это значит, что свободно можно исследовать и прототипировать с ней, но использовать модель в продукте, который вы продаёте, можно только при наличии отдельной коммерческой договорённости с Meta (Hugging Face, 2026). Если вы планируете внедрить синхронный перевод, рассматривайте SeamlessM4T как эталонный дизайн и открытую базовую линию, и обязательно проверьте лицензию перед тем, как строить на ней бизнес. Что касается перевода внутри звонка в реальном времени, где важно, как он интегрируется в WebRTC-пайплайн, то эта статья передаёт эстафету отдельным урокам – мультиязычный речевой перевод в звонках в реальном времени и перевод речи в реальном времени в WebRTC-звонке, – а не дублирует их содержание здесь.

Как три системы соотносятся

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

КритерийOpenAI Realtime APIGemini LiveSeamlessM4T v2
Основная задачаРазговор (голосовой агент)Разговор (голосовой агент)Перевод (синхронист)
АрхитектураEnd-to-end speech-to-speechEnd-to-end, нативное аудиоКаскад внутри одного пакета
Держать или арендоватьАренда (хостинговый API)Аренда (хостинговый API)Держать (open-weights)
ПодключениеWebRTC · WebSocket · SIPWebSocketСвязываете сами
Языки на выходеМногоязычно, переключение в фразеМногоязычно~Десятки, прямой речевой перевод
Форма стоимостиАудио по токенам, ~$0,18–0,46/минПо токенам, ~10× дешевле входGPU + электричество (свой хостинг)
Читаемая серединаНет читаемого текстаНет читаемого текстаЕсть – текстовый этап открыт
ЛицензияКоммерческая, pay-as-you-goКоммерческая, pay-as-you-goCC-BY-NC (некоммерческая)
Когда братьПродакшен-агент, телефонная поддержкаВысокий объём при ограниченном бюджетеОткрытая база перевода, research

Главный вывод: для разговорного голосового агента вы выбираете между двумя end-to-end-движками на условиях аренды, где OpenAI опережает по вариантам интеграции и готовности к продакшену, а Gemini – по цене при масштабировании. Что касается функции перевода, вы находитесь на другом рынке, где SeamlessM4T считается открытым эталоном, однако её некоммерческая лицензия становится серьёзным барьером, который придётся преодолеть.

Сколько на самом деле стоит минута разговора

Цена – это точка пересечения архитектурного выбора и бюджета, поэтому стоит хотя бы раз вслух пройтись по расчётам. Хостинговые speech-to-speech API тарифицируются по токенам, причём для аудио токен – это не фрагмент текста, а временной отрезок. В OpenAI Realtime API аудио пользователя считается по одному токену на 100 миллисекунд, а аудио ассистента – по одному токену на 50 миллисекунд (CallSphere, 2026). Переведём это в стоимость за минуту.

Возьмём минуту речи пользователя. Минута – это 60 секунд, то есть 60 000 миллисекунд. При одном токене на 100 миллисекунд:

токены аудио пользователя в минуту = 60 000 мс ÷ 100 мс/токен = 600 токенов

Теперь ответ ассистента занимает одну минуту при скорости одного токена за 50 миллисекунд:

токены аудио ассистента в минуту = 60 000 мс ÷ 50 мс/токен = 1 200 токенов

gpt-realtime тарифицируется в $32 за миллион входных аудиотокенов и $64 за миллион выходных (OpenAI, 2025). Значит, минута речи пользователя и минута ответа ассистента стоят:

стоимость входа  = 600 токенов   × $32 / 1 000 000 = $0,0192
стоимость выхода = 1 200 токенов × $64 / 1 000 000 = $0,0768
   ───────────────────────────────────────────────────────
   за минуту (в обе стороны, без кэша)            ≈ $0,096

На практике реальный агент передаёт историю диалога на каждом шаге – поэтому независимые замеры показывают, что типичная минута работы без кэширования обходится примерно в $0,18–0,46, а при включённом prompt caching – переиспользовании неизменной части промпта – стоимость падает до $0,05–0,10 (CallSphere, 2026). Здесь действительно есть рычаг: OpenAI тарифицирует кэшированный аудиовход по $0,40 за миллион токенов против $32 за свежий – то есть скидка составляет 80-кратную (OpenAI, 2025).

Именно здесь Gemini Live меняет правила игры. Поскольку входное аудио тарифицируется по значительно более низкой ставке за токен, продукт, обрабатывающий миллионы минут в месяц, может увидеть, как его основная статья расходов – входное аудио – сокращается примерно на порядок (Finout, 2026). На малом масштабе разница – шум; на большом – она может решить, будет ли фича вообще реализована. Дисциплина здесь проста: сравнивайте свои объёмы по обоим тарифам перед выбором – ровно так, как это показано в уроке о реальной стоимости ИИ в видеопродуктах. Одностраничная памятка ниже упаковывает это сравнение, чтобы вы могли провести его прямо на встрече.

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

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

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

  • Speech-to-speech включает две задачи: диалог (OpenAI, Gemini) и перевод (SeamlessM4T).
  • Каскадная архитектура объединяет модели «услышать – подумать – сказать»; единая end-to-end-модель работает быстрее и звучит естественнее, но её сложнее отлаживать.
  • Стремитесь к задержке меньше 800 мс от начала речи до ответа; сама модель занимает лишь около половины общего бюджета.
  • Выбор транспортного протокола зависит от того, где обрабатывается аудио: на устройстве (WebRTC), на сервере (WebSocket) или в телефонной сети (SIP).
  • Определение конца высказывания и обработка перебиваний чаще всего ломают демо, чем любые ошибки модели.
  • Аудио Gemini Live по стоимости обработки токенов примерно в 10 раз дешевле, чем у OpenAI, при больших объёмах.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.