OpenAI раскрыла устройство потоковой архитектуры GPT‑Live
OpenAI рассказала, как за шесть месяцев построила для GPT‑Live новую архитектуру голосового ИИ. Полнодуплексная модель способна слушать и говорить одновременно, а протокол WARP сокращает запуск медиасоединения WebRTC с шести сетевых циклов до одного. Для сложных рассуждений и работы с инструментами система асинхронно обращается к GPT‑5.5.
Технология лежит в основе новых возможностей ChatGPT Voice, включая управление компьютером и координацию агентов в настольном приложении ChatGPT. В перспективе та же платформа должна стать основой GPT‑Live API.
Почему OpenAI отказалась от очередности реплик
Прежние голосовые системы ждали решения отдельного детектора конца реплики. Если он срабатывал слишком рано, пользователь оказывался перебит; если поздно, ответ воспринимался как медленный. Только после решения детектора крупная языковая модель начинала обработку.
В GPT‑Live аудио непрерывно поступает в модель и возвращается пользователю. Первый анонс GPT‑Live для голосового режима ChatGPT раскрывает продуктовый контекст этой системы, а инженерная публикация OpenAI показывает, какие изменения потребовались на уровнях инференса, транспорта и управления состоянием.
Ключевым решением стало разделение медиапотока и прикладной логики. Аудио движется по выделенному быстрому пути, тогда как вызовы инструментов, делегирование и другие операции проходят через асинхронную границу RPC. Поэтому задержка внешнего сервиса не должна останавливать передачу звука.
Непрерывный инференс и сохранение состояния
Медиафронтенд и логику инференса разработчики написали на Go вместо прежней реализации на Python asyncio. По оценке OpenAI, показатель p95 новой системы по плавности доставки кадров соответствует p50 предыдущей. Транспортной основой остался WebRTC, способный компенсировать потерю пакетов, дрейф часов и изменения соединения.
Для длительных разговоров OpenAI реализовала бесшовную передачу сессии между экземплярами модели. Замена заранее прогревается, получает текущий контекст и некоторое время работает параллельно с исходным экземпляром. Переключение происходит после полной готовности новой модели.
Этот же механизм применяется при сжатии контекста. Пока действующий экземпляр продолжает разговор, система уменьшает накопленный контекст и восстанавливает KV-кеш на замене. Такой подход позволяет не прерывать медиапоток из-за служебной операции.
Делегирование задач и быстрый запуск
GPT‑Live поддерживает естественный темп разговора, а GPT‑5.5 может выполнять поиск, рассуждать и обращаться к инструментам в фоне. В начале голосовой сессии сервер создаёт для фронтирной модели отдельную сессию инференса и заранее обрабатывает исходный контекст. Затем используются привязка запросов к сессии и кеширование промпта.
Для ускорения WebRTC OpenAI разработала набор обратно совместимых спецификаций WARP. Он объединяет этапы установления ICE, DTLS и SCTP, использует DTLS 1.3 и предварительно согласует каналы данных. Поддержка уже добавлена в libwebrtc и Pion, а предложения продвигаются через рабочую группу TSVWG организации IETF.
Дополнение Instant Connect заранее согласует параметры SDP без резервирования серверных ресурсов. Если параметры действительны, сервер создаёт сессию при получении первого медиапакета; если нет, клиент продолжает стандартный обмен без дополнительной задержки. В сочетании с WARP это позволяет начать сессию одним UDP-пакетом.
Что показало производственное тестирование
До запуска OpenAI направляла небольшую и постепенно растущую долю реальных сессий ChatGPT Voice одновременно в Advanced Voice Mode и новую систему. Теневая ветка работала только на чтение, поэтому пользователи продолжали слышать ответы прежнего режима.
Испытание показало, что ёмкость голосовой платформы нельзя оценивать только по пропускной способности GPU. Процессорные обработчики потоков, очереди и сеть должны выдерживать число одновременных сессий и доставлять каждый аудиокадр по расписанию. Дополнительное влияние оказали география, длинные разговоры, переподключения и восстановление состояния.
Для бизнеса главный вывод состоит в том, что отзывчивый голосовой сервис требует оптимизации всего маршрута — от клиентского подключения до модели и инструментов. Разделение медиапотока, прикладной логики и фонового рассуждения позволяет развивать функции независимо, не превращая задержку отдельного компонента в паузу всего разговора.