Голосовые агенты снова уперлись в старую инженерную проблему: человек не готов ждать, пока модель думает в трубке. OpenAI заявляет для GPT-Live-1 задержку смены реплик около 800 мс, а Google через пять дней после релиза конкурента вывела Gemini 3.8 Live и Gemini 3.8 Live Extended Thinking в Gemini API и Google AI Studio. Для русскоязычных команд, которые строят саппорт, продажи и внутренних ассистентов, это не спор о красивых демо, а вопрос стоимости, контроля и того самого неловкого молчания в звонке.
По данным The New Stack, OpenAI и Google выбрали противоположные архитектуры. Gemini 3.8 Live Extended Thinking держит речь, рассуждение и вызовы инструментов внутри одной stateful-сессии. OpenAI, наоборот, разделяет роли: GPT-Live-1 отвечает за живой голосовой диалог, а сложную логику, работу с инструментами и reasoning отдает отдельной backend-модели. В заголовке оригинала это сформулировано жестко: голосовая модель OpenAI не думает. И именно в этом идея.
Проблема проявляется не тогда, когда ассистент отвечает на вопрос о погоде. Она начинается, когда агенту нужно проверить заказ, найти клиента в CRM, вызвать внешний API, сверить доступность товара или пересчитать условия тарифа. В текстовом чате пауза в две секунды обычно терпима. В голосе та же пауза звучит как обрыв связи, плохой колл-центр или человек, который забыл, зачем позвонил. Поэтому поставщики моделей теперь продают не только качество ответа, но и способность продолжать разговор, пока работа идет на фоне.
У Google ставка на единый контур. Если функция помечена как неблокирующая, Gemini может продолжать говорить, уточнять детали или комментировать ход выполнения, пока внешний вызов еще не вернулся. Для разработчика это выглядит аккуратно: меньше собственного middleware, меньше ручной синхронизации между голосовым слоем и reasoning-слоем, больше поведения из коробки. Есть и настройка усилия рассуждения: low, medium или high на запрос. Обычный Gemini 3.8 Live пропускает расширенное рассуждение, чтобы снизить задержку и расходы.
У OpenAI подход более модульный. GPT-Live-1 держит full-duplex-разговор, а более тяжелая backend-модель отдельно решает задачу и ходит в инструменты. Плюс такого подхода очевиден для зрелых инженерных команд: backend можно менять, настраивать, удешевлять, заменять на собственный агентный слой или даже на стороннюю модель. Минус тоже очевиден: приложение должно само протаскивать контекст между слоями, следить за состоянием фоновых задач и решать, что произойдет, если пользователь перебил ассистента на середине операции.
Самый неприятный крайний случай у обеих схем один и тот же: устаревшая работа. Пользователь попросил проверить бронь, ассистент запустил вызов API, через секунду пользователь сказал: нет, отмена, нужна другая дата. В интегрированной схеме Google такая работа остается внутри сессии, но у разработчика меньше прозрачности, где именно остановился tool call. В схеме OpenAI контроль выше, зато и ответственность грубее: нужно отменять pending jobs, чистить очереди и не дать старому результату вернуться в разговор как ни в чем не бывало. Иначе голосовой агент превращается в очень уверенного собеседника, который отвечает на позапрошлый вопрос.
Экономика тоже расходится. Стандартный Gemini 3.8 Live идет по тарифам Gemini Live API: $0,005 за минуту входящего аудио и $0,018 за минуту исходящего. Extended Thinking добавляет плату за reasoning-токены и дополнительные типы входа вроде видео или документов. GPT-Live-1 стоит $0,05 за голосовую минуту только для фронтового голосового слоя; backend reasoning, function calls и внешние агентные операции оплачиваются отдельно. Для пилота разница может выглядеть косметикой. Для контакт-центра с тысячами часов разговоров в месяц это уже строка бюджета, которую финансовый директор заметит без подсказки.
Есть и продуктовый контекст. Google подчеркивает, что сравнивать Gemini Live как developer API с ChatGPT Voice или Claude Voice напрямую некорректно: последние являются готовыми продуктами, а не только моделями для сборки агентов. Это важная оговорка. Разработчик покупает не голос как магию, а набор компромиссов: где живет состояние, кто управляет прерываниями, сколько стоит молчание, можно ли подключить свою бизнес-логику и насколько легко отлаживать разговор после жалобы клиента.
Для российских и русскоязычных команд вывод практичный: голосовые агенты больше нельзя проектировать как чатбота с прикрученным синтезом речи. Нужны метрики первого аудиофрейма, p95-задержки, тесты на перебивания, акценты, шум, плохую связь и долгие tool calls. Нужна трассировка не только LLM-ответа, но и всей цепочки: микрофон, VAD, модель, API, очередь, TTS, playback. Без этого демо на стенде будет бодрым, а реальный звонок с клиентом — дорогим способом услышать тишину.
Главный вопрос теперь не в том, какая модель говорит приятнее. Рынок выбирает между двумя школами: интегрированной сессией, где поставщик прячет большую часть сложности, и модульной архитектурой, где разработчик получает контроль вместе с обязанностью все это удержать. Победит не та схема, которая красивее на диаграмме, а та, где голосовые агенты смогут делать реальную работу без пауз, фантомных ответов и счета, от которого хочется вернуться к обычному IVR.