OpenAI объяснила, как перестроила WebRTC для голосового ИИ с низкой задержкой

OpenAI раскрыла детали того, как переделала свою WebRTC-инфраструктуру для голосовых функций ChatGPT и Realtime API. Цель была простой: чтобы разговор с ИИ не разваливался из-за сетевых задержек даже при глобальной нагрузке и сотнях миллионов пользователей.

Почему старый подход не годился

Для голосового ИИ недостаточно просто распознавать речь и быстро генерировать ответ. Разговор должен идти в темпе человеческой речи: без неловких пауз, обрезанных перебиваний и секундного ожидания перед реакцией модели. В OpenAI пишут, что на их масштабе это упирается сразу в три требования: глобальный охват для более чем 900 миллионов недельных активных пользователей, быстрое установление соединения и низкое стабильное время прохождения аудио туда и обратно.

«Голосовой ИИ ощущается естественно только тогда, когда разговор движется со скоростью речи».

Проблема была в том, что классический WebRTC-подход плохо сочетается с облачной инфраструктурой OpenAI. Если каждому сеансу нужен отдельный публичный UDP-порт, то при высокой параллельности приходится открывать и защищать огромные диапазоны портов. Это неудобно для Kubernetes, усложняет балансировку, делает автоскейлинг более хрупким и увеличивает поверхность атаки. При этом сами сессии ICE и DTLS остаются stateful: пакетам важно попадать ровно в тот процесс, который владеет конкретным соединением.

Relay плюс transceiver

После сравнения нескольких вариантов OpenAI отказалась от схемы, где модель выступает обычным WebRTC-участником через SFU. Для их нагрузки типичен сценарий один на один: один пользователь говорит с одной моделью или один клиент общается с одним real-time агентом. Поэтому компания выбрала модель transceiver: edge-сервис завершает клиентское WebRTC-соединение, а затем переводит медиа и события во внутренние протоколы для инференса, транскрибации, синтеза речи, вызова инструментов и оркестрации.

Ключевая идея новой архитектуры — разделить маршрутизацию пакетов и завершение протокола. Relay стал лёгким UDP-слоем на входе с маленьким публичным сетевым следом, а transceiver остался stateful-компонентом, который держит ICE, DTLS, SRTP-ключи и весь жизненный цикл сессии. Relay не расшифровывает медиа, не ведёт переговоры о кодеках и не пытается притворяться WebRTC-peer.

Он лишь читает минимальный объём метаданных из пакета и пересылает трафик туда, где живёт нужная сессия. Самый интересный трюк связан с первым пакетом. OpenAI использует ICE username fragment, или ufrag, и встраивает в него ровно столько маршрутизационной информации, сколько нужно relay для выбора кластера и конкретного transceiver.

Во время сигналинга клиент получает общий relay VIP и фиксированный UDP-порт, а первый STUN-пакет даёт системе достаточно данных, чтобы сразу отправить поток по правильному пути без отдельного обращения к внешнему lookup-сервису. После установления маршрута сопоставление адресов дополнительно хранится в Redis, чтобы быстро восстанавливаться после перезапуска relay.

Как снизили задержку

Когда публичную UDP-поверхность удалось свести к небольшому числу стабильных адресов и портов, OpenAI масштабировала эту же схему глобально. Так появился Global Relay — распределённый набор входных точек, которые принимают пакеты ближе к пользователю и заводят их в сеть OpenAI без лишнего первого прыжка через далёкий регион. Для сигналинга компания использует географическое и proximity-роутирование Cloudflare, поэтому и начальный HTTP/WebSocket-запрос, и первый ICE-check приходят в ближайший подходящий кластер.

• Маленький и фиксированный публичный UDP-слой вместо тысяч открытых портов Маршрутизация первого пакета через данные, уже встроенные в ICE ufrag Общий UDP-сокет на стороне transceiver вместо сокета на каждый сеанс Короткоживущая in-memory state плюс Redis-кэш для быстрого восстановления маршрута `SO_REUSEPORT`, привязка потоков к OS-thread и минимизация аллокаций для высокой пропускной способности Сам relay OpenAI написала на Go и сознательно оставила его узким по ответственности: он не завершает WebRTC-сессию, а только быстро разбирает нужные заголовки, обновляет минимальное состояние потока и пересылает пакеты дальше. Компания отдельно подчёркивает, что ей не понадобился kernel bypass: аккуратной оптимизации на уровне `SO_REUSEPORT`, thread pinning и сокращения лишних копирований хватило, чтобы обслуживать глобальный real-time медиатрафик с относительно небольшим relay-слоем и без отказа от стандартного поведения WebRTC на клиентах.

Что это значит

Для пользователей всё это выглядит как «голосовой режим стал отзывчивее», но для рынка важнее другое: OpenAI показала, как строить массовый voice AI поверх стандартного WebRTC без кастомных клиентов и без болезненного разрастания сетевой инфраструктуры. Это хороший ориентир для разработчиков real-time ассистентов, голосовых агентов и продуктов, где задержка в полсекунды уже ломает весь пользовательский опыт.