Как мы за шесть месяцев создали реляционную систему для отзывчивого голосового ИИ03.08.2026 07:00

В голосовом ИИ понимание того, когда именно нужно заговорить, оказывается сложнее, чем кажется на первый взгляд. Люди с легкостью передают друг другу слово за доли секунды, однако предыдущие голосовые системы на базе ИИ не успевали за этим ритмом. Их архитектура, основанная на чередовании реплик, опиралась на небольшие модели, известные как детекторы реплик (turn detectors), перед которыми стояла невыполнимая задача: угадать слишком рано — и пользователя перебьют; угадать слишком поздно — и ответ покажется заторможенным. Только после того, как детектор принимал решение, к работе могла приступить гораздо более крупная языковая модель (LLM).

GPT‑Live⁠, наша голосовая система третьего поколения, исключает детектор реплик из аудиотракта. Ее голосовая модель является полнодуплексной, что означает способность слушать и говорить одновременно. Это устраняет необходимость в отдельном детекторе и делает общение более непосредственным и естественным. Когда требуется более глубокий анализ или использование инструментов, GPT‑Live также может обращаться к нашим передовым моделям, таким как GPT‑5.5, не прерывая ход беседы. В совокупности эти возможности наделяют GPT‑Live беспрецедентным сочетанием оперативности и интеллектуальности в диалоге.

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

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

В этой статье мы объясним, почему более ранние системы с поочередными репликами не отвечали нашим требованиям, и расскажем, как мы спроектировали новую систему для достижения высокой отзывчивости на каждом уровне. Мы рассмотрим инференс с сохранением состояния (stateful inference), динамическое управление контекстом, асинхронное делегирование и оптимизацию на уровне протоколов — все они работают в слаженном взаимодействии, чтобы сделать GPT‑Live по-настоящему живой.

Предыдущие голосовые архитектуры унаследовали поочередный характер текстовых LLM, но каждая реплика в них была представлена в виде отдельного блока аудиоданных, а не текста. В каскадных системах преобразование речи в текст, LLM и синтез речи работали последовательно. Такая цепочка увеличивала задержку и игнорировала такие нюансы, как тон и темп речи.

Модели «речь-речь» усовершенствовали этот подход за счет непосредственной обработки аудио. Обучение модели на исчерпывающее понимание и генерацию речи позволило ей сохранять детали, терявшиеся при транскрипции, и реагировать быстрее. Тем не менее, система по-прежнему зависела от детектора реплик, решавшего, когда можно начинать инференс. Модель стала обрабатывать больший объем взаимодействия, но само взаимодействие оставалось поочередным.

GPT‑Live перекладывает управление диалогом на голосовую модель: аудиопотоки поступают в модель и исходят из нее, в то время как более глубокий анализ и использование инструментов происходят асинхронно. Главная задача системы — поддерживать бесперебойный медиацикл. Остальная работа, такая как вызов передовых моделей и сохранение истории диалога, выполняется вне основного потока в реальном времени.

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

Предыдущие разработки в области ChatGPT Voice и Realtime API заложили для нас важную основу. Мы уже перестроили нашу голосовую инфраструктуру⁠ для прямой потоковой передачи аудио и видео в наши системы и обратно с меньшей и более предсказуемой задержкой. В GPT‑Live этот подход развит дальше: медиаданные передаются потоком прямо в модель через новую систему инференса с сохранением состояния, созданную для непрерывного общения.

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

Одним из наших ранних решений стало четкое разделение потока медиаданных и логики приложений/бизнеса. Аудиопередача между клиентом и голосовой моделью осуществляется по выделенному высокоскоростному каналу. Делегирование, использование инструментов и другие прикладные задачи выполняются за асинхронной границей RPC. Медленный вызов инструмента или бэкенд-сервиса может задержать собственный результат, но не способен заблокировать поток медиаданных.

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

Мы написали фронтенд для работы с медиаданными и логику инференса на Go, заменив прежнюю реализацию на Python asyncio. Это значительно повысило плавность доставки кадров: показатель p95 новой системы сопоставим с показателем p50 предыдущей.

Фундаментом для транспортировки служит WebRTC. Эта технология разработана для передачи медиаданных с низкой задержкой и способна продолжать работу в условиях потери пакетов, дрейфа системных часов и изменений клиентского подключения. Если пакеты приходят с опозданием, WebRTC может незаметно растянуть аудио, чтобы предотвратить пропуски, а затем ненадолго ускорить воспроизведение, чтобы снова догнать реальное время.

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

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

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

Этот же базовый механизм поддерживает динамическое сжатие контекста. По мере продолжения диалога накапливаемый контекст может в итоге превысить лимит модели. Сжатие позволяет уменьшить размер контекста, чтобы уложиться в лимит, но эта операция требует времени. Кроме того, поскольку она изменяет прошлый контекст, это приводит к аннулированию кэша ключей-значений (KV-кэша) модели, в котором хранятся ключи и значения внимания (attention) для ранее обработанных токенов. Воссоздание этого состояния требует повторной предзагрузки, что влечет за собой дополнительную задержку.

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

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

Способность GPT‑Live вызывать существующие передовые модели дает ей огромные возможности, эффективно отделяя процесс «разговора» от более глубокого «мышления». Однако для того, чтобы эта архитектура из двух моделей воспринималась как единая система, потребовалось решить две взаимосвязанные инженерные задачи.

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

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

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

Затем мы поддерживаем доступность этого сеанса инференса в течение всего голосового разговора и используем стабильное закрепление сеансов (session affinity) для последующих запросов. В сочетании с кэшированием промптов эти методы улучшают задержку, в то время как сбой воркера остается легко восстановимым.

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

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

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

Накладывание голосов друг на друга усложняет эту задачу. Краткое подтверждение от ассистента во время речи пользователя (например, «угу» или «хорошо») не должно обязательно становиться отдельным сообщением. Однако существенная реплика ассистента часто должна ею стать. Аналогичным образом мы уделяем приоритетное внимание связности отображаемых ответов ассистента, даже если пользователь говорит посередине.

Любая политика сегментации балансирует между оперативностью и достоверностью. Слишком раннее фиксирование приводит к фрагментированной истории и нестабильному порядку; слишком долгое ожидание задерживает расшифровки и функции, которые от них зависят. Поэтому система поддерживает два связанных представления разговора: спекулятивное (предварительное) представление текущего состояния и авторитетную запись того, что было сказано. Представление разговора в пользовательском интерфейсе приложения может обрабатывать обновления, поэтому оно использует предварительное представление. Однако логирование в аналитический конвейер требует финальной расшифровки.

Это дает остальной части ChatGPT стабильное представление об обмене репликами без навязывания очередности реплик в живом голосовом канале.

Отзывчивость начинается сразу же, как только пользователь нажимает кнопку. В случае с GPT-Live системе необходимо установить медиаканал и начать передачу аудио через модель до того, как сможет начаться разговор. Это ставит каждый этап последовательности запуска на критический путь.

Как отмечалось выше, WebRTC обеспечивает надежную основу реального времени, но запуск стандартной сессии WebRTC требует удивительного количества рукопожатий протокола и сетевых обращений туда и обратно (round trips). WebRTC появился раньше, чем фокус на минимизации обращений, который сформировал более поздние протоколы, такие как QUIC. В результате его базовые протоколы иногда дублируют работу при совместном использовании. Например, каждый протокол включал собственный механизм защиты от DDoS, даже когда это не требовалось в контексте всего стека WebRTC.

Мы проанализировали стек и разработали сокращенный протокол рукопожатия WebRTC (WARP⁠), который сокращает запуск медиаданных и данных с шести сетевых обращений всего до одного. WARP достигает этого с помощью набора обратной совместимости улучшений протокола: совмещения рукопожатия DTLS поверх ICE (SPED⁠), использования более быстрого рукопожатия DTLS 1.3⁠, предварительного согласования рукопожатия SCTP (SNAP⁠) и предварительного согласования каналов данных вместо использования DCEP⁠.

Мы разработали WARP как набор открытых спецификаций, сотрудничая с участниками сообщества WebRTC, чтобы более широкая экосистема могла извлечь выгоду из этой работы. Мы продвигаем эти предложения через рабочую группу TSVWG организации IETF, и поддержка WARP уже добавлена как в libwebrtc, так и в Pion, а также ведутся работы в других реализациях WebRTC.

После оптимизации медиарукопожатия выделялась еще одна задержка: обмен сигналами, используемый для совместного использования параметров SDP перед подключением WebRTC. Чтобы исключить этот обмен из критического пути, мы разработали то, что называем Instant Connect (Мгновенное подключение). Оно согласовывает эти параметры заранее без резервирования емкости сервера и без каких-либо изменений в существующих реализациях WebRTC.

Instant Connect работает параллельно со стандартным потоком сигнализации. Если предварительно согласованные параметры действительны, сервер может материализовать сеанс при прибытии первого медиапакета. Если они устарели или недействительны, поток сигнализации уже запущен, поэтому клиент может вернуться к нему без дополнительных задержек.

В совокупности Instant Connect и WARP резко сокращают время от намерения пользователя до потока живых медиаданных. Поскольку обмен SDP исключен из критического пути, а WARP сворачивает транспортное рукопожатие, клиент теперь может запустить сеанс с помощью одного UDP-пакета. Сервер может ответить немедленно, позволяя остальной части системы начать делать то, что действительно волнует пользователя: слушать и отвечать.

Система может выглядеть быстрой на бумаге и при этом пробуксовывать при реальном голосовом трафике. Прежде чем разрешить пользователям общаться с GPT-Live, мы провели скрытое тестирование, которое направляло небольшую, постепенно увеличивающуюся долю производственных сессий ChatGPT Voice как в существующий режим Advanced Voice Mode, так и в нашу новую систему. Advanced Voice Mode продолжал обслуживать пользователей в обычном режиме, в то время как теневой путь выполнял инференс в режиме только чтения. Это подвергло систему воздействию реальных клиентов, сетей, длительностей сессий и географического распределения без изменения того, что слышали пользователи.

Одним из первых уроков стало то, что пропускную способность нельзя сводить к производительности графического процессора. Голосовые сессии остаются открытыми и непрерывно отправляют кадры, поэтому потоковые обработчики на стороне ЦП, очереди и сетевые пути должны масштабироваться параллельно с инференсом. При реальной нагрузке вспомогательный компонент насытился раньше, чем прогнозировали оценки наших тестов нагрузки, что привело к накоплению запросов на инференс и увеличению задержки. Мы изменили вопрос о пропускной способности с »Сколько запросов может обработать графический процессор? » на »Сколько одновременных сессий может выдержать система, поддерживая каждый кадр по расписанию? »

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

Другие сбои проявлялись только при реалистичных жизненных циклах сеансов. Долго выполняющиеся сеансы создавали нагрузку на память и постоянное хранение данных. Переподключения задействовали компакцию и восстановление состояния. Обычные отключения клиентов выявляли гонки в рукопожатии завершения работы. Эти проблемы редко проявлялись в коротких тестах нагрузки, поскольку они зависели от времени, накопленного состояния и поведения на границах служб.

Наконец, тестирование в продакшене заставило нас улучшить наблюдаемость (observability) и средства контроля развертывания. Мы обнаружили метрики, которые объединяли разные источники задержки, панели мониторинга, чьи агрегаты скрывали отдельные нездоровые движки, и дрейф конфигурации между протестированными и развернутыми системами. В ответ мы добавили более детальную телеметрию, проверку на соответствие известным рабочим конфигурациям, поэтапное наращивание нагрузки и возможность быстро изолировать или отключать отдельные пути. Скрытое тестирование превратилось в раннюю репетицию запуска — не только для того, сколько трафика может принять система, но и для того, как быстро мы сможем обнаруживать сбои, локализовывать их и восстанавливаться после них.

Внедрение GPT-Live в масштабе ChatGPT потребовало совершенно новой системы, построенной вокруг одного фундаментального принципа: голос должен течь. Потоковый инференс обеспечивает модель в дуплексном режиме аудиоданными. Выделенный медиаканал обеспечивает надежную доставку кадров. Асинхронное делегирование позволяет выполнять более глубокие размышления параллельно. Оптимизированный транспорт поддерживает отзывчивость интерфейса вплоть до самого пользователя.

Архитектура, лежащая в основе GPT-Live, уже становится более широкой платформой для взаимодействия в реальном времени. Она питает ChatGPT Voice по мере того, как он расширяется от разговора до агентной координации, и станет основой для предстоящего API GPT-Live. Со временем это позволит голосовым интерфейсам охватывать больше устройств, приложений и модальностей, не жертвуя при этом той непосредственностью, которая делает голосовой разговор живым.

Если вы хотите решать именно такие инженерные задачи, присоединяйтесь к нашей команде⁠.

Автор