Как OpenAI обеспечивает низкую задержку голосового AI в глобальном масштабе

Если голосовой AI делает паузу перед ответом — это уже провал. Пользователь чувствует неловкость, разговор рассыпается. Именно поэтому команда OpenAI, отвечающая за взаимодействие в режиме реального времени, провела масштабную перестройку своего WebRTC-стека. Цель — сделать задержку «невидимой».

OpenAI перестроила WebRTC-стек для работы голосового AI в реальном времени с низкой задержкой, глобальным масштабом и естественным переключением реплик в разговоре.

Что такое WebRTC и почему он важен для голосового AI

WebRTC (Web Real-Time Communication) — открытый стандарт для передачи аудио, видео и данных с минимальной задержкой между браузерами, мобильными приложениями и серверами.

Без WebRTC каждому клиенту пришлось бы по-своему решать задачи установления соединения через NAT (трансляция сетевых адресов), шифрования медиапотока, выбора кодеков и адаптации к меняющимся условиям сети. С WebRTC можно строить на уже реализованном стеке протоколов, который поддерживается во всех браузерах и мобильных платформах, сосредоточив усилия на инфраструктуре, связывающей медиа в реальном времени с моделями.

Для AI особенно важно одно свойство протокола: аудио поступает непрерывным потоком. Это позволяет голосовому агенту начать транскрибацию, рассуждение, вызов инструментов или генерацию речи, пока пользователь ещё говорит — вместо того чтобы ждать полной загрузки. Именно это отличает систему, ощущающуюся как живой разговор, от неудобного режима «нажмите и говорите».

Три проблемы, которые столкнулись на масштабе

Команда столкнулась с тремя ограничениями, которые при масштабировании начали конфликтовать между собой: схема «один порт на сессию» плохо вписывается в инфраструктуру OpenAI; сессии ICE (Interactive Connectivity Establishment — протокол проверки доступности соединения) и DTLS (Datagram Transport Layer Security — безопасность транспортного уровня для UDP) требуют стабильного владельца; глобальная маршрутизация должна минимизировать задержку первого перехода.

Разберём каждый пункт подробнее.

1. Проблема «один порт — одна сессия»

В стандартной схеме каждая WebRTC-сессия привязана к отдельному UDP-порту. При большом числе параллельных разговоров это означает необходимость держать открытыми тысячи портов — это сложно обезопасить, трудно балансировать и практически невозможно вписать в Kubernetes-инфраструктуру OpenAI.

2. Состояние сессии требует стабильного владельца

Процесс, создавший сессию, должен продолжать получать её пакеты — для проверки ICE-соединений, завершения DTLS-рукопожатия, расшифровки SRTP и обработки изменений сессии (например, ICE-перезапуска). Если пакеты одной сессии попадут на другой процесс — соединение может не установиться или медиапоток прервётся.

3. Глобальная маршрутизация с минимальной задержкой

Пользователи OpenAI находятся по всему миру. Голосовой пакет, отправленный из Москвы, не должен сначала ехать в дата-центр в США. Первый «прыжок» — от клиента до ближайшего сервера — критически влияет на ощущение реального времени.

Архитектура решения: Split Relay + Transceiver

OpenAI разработала архитектуру «разделённого реле плюс трансивер» (split relay + transceiver), которая сохраняет стандартное поведение WebRTC для клиентов, меняя при этом маршрутизацию пакетов внутри инфраструктуры.

Роль трансивера (Transceiver)

Для 1:1-трафика выбрана модель трансивера: граничный WebRTC-сервис принимает клиентское соединение и преобразует медиа и события во внутренние протоколы для вывода модели, транскрипции, генерации речи, вызова инструментов и оркестрации. В этом дизайне трансивер — единственный сервис, которому принадлежит состояние WebRTC-сессии: ICE-проверки, DTLS-рукопожатие, SRTP-ключи шифрования и жизненный цикл сессии.

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

Роль реле (Relay)

OpenAI рассмотрела несколько подходов, включая TURN (Traversal Using Relays around NAT — обход NAT через реле), где пограничное реле принимает клиентские соединения и пересылает трафик от их имени. В итоге была выбрана архитектура, разделяющая маршрутизацию пакетов и завершение протокола.

Сервис реле написан на Go с намеренно узкой функциональностью. На уровне Linux ядро сети получает UDP-пакеты от сетевого интерфейса и доставляет их в сокет. Реле работает в пространстве пользователя: обычный Go-процесс читает заголовки пакетов из сокета, обновляет небольшой объём состояния потока и пересылает пакеты, не завершая WebRTC.

«Лучшее место для добавления сложности — тонкий слой маршрутизации, а не каждый бэкенд-сервис и не нестандартное поведение клиента.»

graph LR
    A[Клиент
браузер/мобайл] -->|UDP| B[Relay
Пограничный узел]
    B -->|Маршрутизация по ICE ufrag| C[Transceiver
Завершение WebRTC]
    C -->|Внутренний протокол| D[Inference Backend
GPT-Realtime модель]
    D -->|Аудиоответ| C
    C -->|SRTP| B
    B -->|UDP| A

Ключевые принципы архитектуры

Архитектура строится на трёх принципах: сохранение протокольной семантики на пограничном узле (клиенты говорят на стандартном WebRTC — совместимость с браузерами и мобильными платформами не нарушается); хранение жёсткого состояния сессии в одном месте (трансивер владеет ICE, DTLS, SRTP и жизненным циклом сессии, реле только пересылает пакеты); маршрутизация по информации, уже присутствующей в установке соединения.

ICE ufrag (уникальный фрагмент имени пользователя ICE) предоставляет хук маршрутизации по первому пакету без добавления зависимости от горячего поиска.

Как это работает: путь голосового пакета

Давайте пройдём по пути аудиопакета от момента, когда пользователь произносит слово, до момента, когда AI начинает отвечать.

Преимущества новой архитектуры

Работа внутри Kubernetes без тысяч портов

Архитектура позволяет запускать WebRTC-медиа в Kubernetes без открытия тысяч UDP-портов. Это важно: меньшая и фиксированная UDP-поверхность проще защищается и балансируется, а инфраструктура может масштабироваться без резервирования больших публичных диапазонов портов.

Глобальное покрытие с минимальным первым переходом

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

Бэкенд масштабируется как обычные сервисы

Дизайн сохраняет стандартное поведение WebRTC для клиентов и подтверждает, что схема без SFU (Selective Forwarding Unit — сервер выборочной пересылки) — правильный выбор по умолчанию для этой нагрузки. Большинство сессий точка-точка, чувствительны к задержке, и легче масштабируются, когда инференс-сервисы не обязаны вести себя как WebRTC-пиры.

От старого к новому: что изменилось в голосовом AI

Раньше голосовой AI строился на цепочке отдельных сервисов:

Пользователь говорит
    → Speech-to-Text (Whisper)
    → LLM (GPT-4)
    → Text-to-Speech
    → Пользователь слышит ответ

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

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

VAD (Voice Activity Detection — определение голосовой активности) делает разговор с AI менее похожим на транзакцию и больше на живой чат. Именно эта функция позволяет AI понимать, когда собеседник начал или закончил говорить — что абсолютно необходимо для естественного переключения реплик.

Задержка: сколько миллисекунд — это «нормально»?

Чистые WebRTC-звонки между людьми обеспечивают задержку «рот-в-ухо» около 60–120 мс в хороших условиях. Когда в цепочку добавляется AI-инференс, картина меняется: с OpenAI Realtime API первый частичный текст часто появляется за ~150–250 мс, а первая слышимая речь — за ~220–400 мс. Это всё ещё разговорный диапазон, особенно с потоковой передачей частичных результатов для снижения воспринимаемой задержки.

Такие модели, как OpenAI Realtime API, целятся в полную сквозную задержку ниже 300 мс — это в пределах диапазона естественного человеческого разговора.

Безопасность: эфемерные токены

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

Вместо этого сервер приложения создаёт короткоживущий токен для каждой сессии — и именно его передаёт браузеру для инициации WebRTC-соединения.

Открытый стандарт, опытная команда

Основополагающий вклад Джастина Уберти (одного из оригинальных архитекторов WebRTC) и Шона ДюБуа (создателя и мейнтейнера библиотеки Pion) позволил таким командам, как OpenAI, строиться на проверенной медиаинфраструктуре, а не изобретать заново транспортный уровень, шифрование и управление перегрузками. OpenAI повезло, что оба теперь работают в компании и помогают объединить WebRTC и реальное время AI.

Итог: инфраструктура как конкурентное преимущество

Голосовой AI в реальном времени работает только тогда, когда инфраструктура делает задержку «невидимой». Для OpenAI это означало изменение формы WebRTC-развёртывания, не изменяя того, чего ожидают клиенты от WebRTC.

Архитектура split relay + transceiver — это элегантное решение сложной инженерной задачи: сохранить полную совместимость с открытым стандартом для разработчиков снаружи, одновременно переписав внутреннюю маршрутизацию так, чтобы она работала в масштабах глобального AI-продукта.

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