OpenAI 4 мая опубликовала детали базовой инфраструктуры для голосового ИИ — чтобы поддерживать голосовой ИИ-сервисы для 900 млн еженедельно активных пользователей (Weekly Active Users), команда заново спроектировала стек WebRTC, заменив архитектуру традиционного «один порт на одну сессию» на тонкий relay на Go, а все состояния WebRTC session сосредоточив в одном сервисе под названием «transceiver». В официальном блоге OpenAI объяснили, что эта архитектура одновременно поддерживает голосовой режим ChatGPT, Realtime API и несколько исследовательских проектов. Для любой команды, работающей над голосовым ИИ-инжинирингом, это редкий технический материал о том, «как в глобальном масштабе держать голосовой ИИ».
Три технических ограничения: традиционный WebRTC в масштабе OpenAI упирается в потолок
Инженерная команда OpenAI в тексте прямо указывает три ограничения, которые «вылезают и сталкиваются» при масштабировании:
Подход с завершением медиа «одна session — один порт» (per-session port termination) не подходит для инфраструктуры OpenAI — когда каждую неделю 900 млн пользователей могут одновременно открывать голосовые session, и каждая занимает по одному порту, это быстро исчерпывает сетевые ресурсы.
Сессионные разговоры с состоянием ICE (Interactive Connectivity Establishment) и DTLS (Datagram Transport Layer Security) — им нужен стабильный владелец; в распределённых системах, если состояние session распределено между несколькими сервисами, отказы и миграции становятся крайне сложными.
Глобальная маршрутизация должна удерживать низкую задержку первого хопа (first-hop latency) — «естественность» голосового ИИ определяется плавностью turn-taking (переключением реплик), и если первый хоп дольше 100 мс, это заметно «подвисает».
Список требований OpenAI тоже сформулирован однозначно: глобальный охват (для покрытия 900 млн+ пользователей), быстрое установление session (пользователь открыл рот — и может говорить), низкое и стабильное время round-trip для медиа (включая низкий джиттер и потерю пакетов).
Решение: тонкий Go relay + централизованный сервис transceiver
Архитектура OpenAI состоит из двух уровней:
Relay-уровень — написан на Go, и реализация намеренно держится узкой. Обычный процесс на Go: читает из сокета заголовки пакетов, обновляет небольшое количество состояний потока трафика, пересылает пакеты и не завершает WebRTC. Это ключ к горизонтальному масштабированию relay — не нужно хранить полное состояние WebRTC, relay можно взаимозаменять безболезненно, а одиночный отказ не должен обрывать всю session.
Transceiver-уровень — единственный сервис, который владеет состоянием WebRTC session; включает проверки ICE-соединения, DTLS-handshake, SRTP-ключи шифрования и управление жизненным циклом session. Сосредоточив эти состояния в одном сервисе, легче понять, кому принадлежит session, и бэкенд-сервисы могут масштабироваться как обычные сервисы, не становясь каждый сам WebRTC peer.
Тонкость этого дизайна в том, что «часть, которой нужен state» и «часть без state» строго разделены. Relay — безсостоявшая плоскость данных (её можно массово копировать), transceiver — управляющая плоскость с состоянием (её немного, но она полностью отвечает за state). Такое разделение тоже позволяет OpenAI масштабироваться по горизонтали с ростом нагрузки, не опасаясь взрывного роста числа WebRTC-соединений.
Почему именно Go: логика выбора для инженерии голосового ИИ
OpenAI в статье явно объясняет, что relay пишется на Go и намеренно делается максимально узким. За этим выбором стоит инженерная логика:
goroutine в Go нативно поддерживают IO-bound задачи вроде «обрабатывать десятки тысяч соединений на одном порту» — без необходимости в сложных event loop
пакет net из стандартной библиотеки напрямую читает UDP-пакеты, не требуя привязки к C-библиотекам
после компиляции получается единый статический binary — деплой, контейнеризация и кросс-архитектурность (x86/ARM) упрощаются
управление памятью в Go дружелюбно к «множеству объектов с коротким сроком жизни» (каждый пакет нужно разбирать), а паузы GC можно контролировать
Это также объясняет, почему проникновение Go в современные инфраструктурные слои (Cloudflare, Tailscale, HashiCorp и т.п.) растёт — дело не в том, что «Go сильнее других языков», а в том, что в IO-bound и задачах, требующих горизонтального масштабирования, Go писать проще и прямее всего.
Сопоставление с Cloudflare: поле боя Realtime Voice AI
Параллельно (в начале мая) Cloudflare тоже опубликовала техблог〈Cloudflare — лучшее место для построения realtime voice-агентов〉 и, сопоставляя с OpenAI, предложила собственный вариант. Пути расходятся:
OpenAI: строит свой стек WebRTC relay/transceiver, не полагается на третьих лиц и включает медиа-слой в свой технологический стек
Cloudflare: рассматривает WebRTC-медиа-сервис как расширение своей платформы Workers и даёт разработчикам «всё в одном» инфраструктурное решение
Для команд с небольшими/средними AI-приложениями маршрут Cloudflare практичнее — напрямую вызываешь API и не нужно самостоятельно строить WebRTC-инфраструктуру. Для команды в масштабе OpenAI самостоятельная сборка — неизбежный путь: SLA внешних сервисов, структура биллинга и география не смогут идеально совпасть.
Дальнейшие наблюдения: open-source transceiver, масштаб Realtime API, ответ конкурентов
Фокус следующего этапа:
Откроет ли OpenAI исходники transceiver/relay — конкуренты вроде Anthropic, Google, xAI тоже строят свои голосовые стеки, и если OpenAI откроет код, это может стать промышленным стандартом
Биллинг Realtime API и масштаб — сейчас в основном всё держится на подписке ChatGPT; если доход от API вырастет, станет ли он отдельной продуктовой линией
Соответствие Anthropic и Google — Claude и Gemini уже поддерживают голос, но по задержкам и масштабам OpenAI всё ещё впереди; ускорит ли эта техническая демонстрация их инженерные шаги
Для разработчиков AI-приложений в Тайване голосовой AI — ключевое поле битвы во второй половине 2026 года: для поддержки клиентов, образования, автомобильных систем, IoT и других сценариев нужны низколатентные диалоги. Эта инженерная раскрытка от OpenAI — один из самых важных ориентиров, чтобы понять: «собирать свой голосовой стек или использовать сторонний API».
Эта статья о том, как OpenAI перестроила WebRTC-голосовой стек: 900 млн недельно активных пользователей, relay на Go в качестве ядра, впервые появилась в Lianxin ABMedia.
