OpenAI показала архитектуру GPT-Live как пример того, как строить continuous stateful voice interaction без потери отклика. Ключевой вопрос здесь не в модели, а в том, как отделить latency-critical media path от всего, что может ждать.
Архитектурная проблема в GPT-Live начинается там, где голосовая сессия должна оставаться непрерывной, а вокруг неё возникают операции с переменной задержкой. Если в один критический путь свести media processing, delegation, tool use, persistence и другие application logic, система быстро упирается в latency. Для real-time AI это означает простой принцип: “voice must flow”, а всё остальное должно подчиняться этому требованию.
OpenAI выбрала асинхронную границу между live path и приложенческой частью. Внутри live path остались media pipeline и inference loop. Всё, что может терпеть задержку, ушло за asynchronous RPC boundary. Это прагматичный trade-off: меньше связности в критическом контуре, но больше инженерной дисциплины вокруг обмена состоянием и согласованности поведения.
Отдельный слой сложности — stateful inference. GPT-Live использует dedicated, stateful inference для каждой session, но при этом session context может мигрировать на другой model instance, если текущий instance draining или разговор приближается к context limit. Такой подход помогает совмещать удержание состояния и операционную гибкость. Система может резервировать capacity на назначенном instance, но при этом перераспределять новые и уже активные сессии по доступной ёмкости.
Это не бесплатное решение. Чем больше состояние привязано к live interaction, тем внимательнее приходится относиться к availability, elasticity и operational complexity. Но в данном случае компромисс выглядит осмысленным: модель диалога остаётся непрерывной, а инфраструктура получает возможность масштабироваться и освобождать ресурсы без разрыва сессии.
Для transport layer OpenAI сохранила WebRTC. Это тоже инженерный выбор, а не дань инерции. WebRTC уже даёт battle-tested low-latency media stack и built-in error recovery. Альтернативы вроде RTP over QUIC выглядят перспективно, но в текущем виде они закрывают только транспортный слой, а не полный media pipeline. Кроме того, на уровне транспорта всё ещё не хватает ряда возможностей, включая GCC congestion control и RTT-aware path selection.
Вместо замены стека OpenAI пошла по пути его упрощения. Компания добавила WARP improvements, включая SPED, DTLS 1.3 и SNAP, а также Instant Connect, чтобы сократить startup latency. Важный плюс такого подхода в том, что каждое улучшение можно выкатывать независимо и проверять его эффект изолированно. Это снижает риск и упрощает операционную валидацию. Дополнительный эффект для экосистемы тоже заметен: существующие WebRTC applications получают улучшения без изменения кода.
Наиболее показательный момент — silent test. Перед запуском OpenAI зеркалировала реальные Voice sessions в GPT-Live, но output просто отбрасывался. Система работала в effectively read-only mode и без user credentials. Это позволило прогнать живой traffic через media loop и inference service без влияния на customer experience. Важная деталь здесь в том, что synthetic tests не дали бы той же картины. Реальный поток показал географическое разнообразие, нагрузочное поведение и сбои, которые не воспроизводились на canned speech.
Именно silent test выявил деградацию под нагрузкой, которую пришлось исправлять targeted optimizations и bug fixes. Один из примеров — в некоторых регионах GPUs не были colocated с CPUs, которые подавали на них данные, и это создавало unexpected latency. Такой дефект трудно увидеть в лабораторном load testing, если тестовый профиль слишком ровный. Production traffic оказался честнее, потому что он принес настоящую вариативность и распределение нагрузки.
В сумме GPT-Live выглядит как эволюционное улучшение архитектуры для real-time AI. OpenAI не пыталась заменить весь стек целиком. Она разделила критический путь и вспомогательную логику, сохранила знакомый media foundation и отдельно усилила слабые места. Для архитекторов здесь важен не сам набор технологий, а способ мышления: сначала удержать responsiveness, затем аккуратно разложить state, transport и observability around the live path.