OpenAI переформатувала WebRTC для голосового стеку: 900 млн щотижневих активних користувачів, Relay у центрі, написаний на Go

OpenAI 4 травня опублікувала деталі базової інфраструктури для голосового AI — щоб підтримувати голосові AI-сервіси для 900 млн щотижневих активних користувачів (Weekly Active Users), команда переробила стек WebRTC, замінивши архітектуру з традиційним підходом «один порт на один session» для медіаз’єднань на тонкий relay, написаний на Go, і зосередивши всю WebRTC-статусну інформацію в одному сервісі під назвою «transceiver». Офіційний блог OpenAI пояснює, що ця архітектура водночас підтримує голосовий режим ChatGPT, Realtime API та кілька дослідницьких проєктів. Для будь-якої команди, що створює голосовий AI, цей матеріал — рідкісна технічна публікація про те, як «побудувати масштабування глобального рівня» для голосового AI.

Три технічні обмеження: традиційний WebRTC в масштабі OpenAI впирається в стіну

Інженерна команда OpenAI в тексті чітко назвала три обмеження, які «наштовхуються одне на одне» після масштабування:

Традиційний підхід до завершення медіа «один session — один порт» (per-session port termination) не підходить для інфраструктури OpenAI: коли 900 млн користувачів можуть одночасно запускати голосові session, дизайн, у якому кожна з них займає окремий порт, швидко вичерпає мережеві ресурси

Становий ICE (Interactive Connectivity Establishment) і DTLS (Datagram Transport Layer Security) сесії, які потребують стабільного «власника»: у децентралізованих системах, якщо стан session розподіляється між кількома сервісами, відмовостійкість і міграції стають надзвичайно складними

Глобальна маршрутизація має підтримувати низьку затримку першого переходу (first-hop latency) — «природність» голосового AI залежить від плавного turn-taking (зміни реплік), і якщо перший перехід перевищує 100 мс, це буде помітно як «запинки»

Вимоги OpenAI також описані конкретно: глобальне охоплення (покриття 900 млн+ користувачів), швидке створення session (щоб користувач міг одразу говорити), низький і стабільний час round-trip для медіа (включно з низьким jitter і втратами пакетів).

Розв’язання: тонкий relay на Go + централізований сервіс transceiver

Архітектура OpenAI складається з двох рівнів:

Relay-рівень — написаний на Go, з навмисно простою реалізацією. Окремий звичайний Go-процес: він читає пакети зі сокетів разом із заголовками, оновлює мінімальний обсяг стану потоку трафіку, пересилає пакети й не завершує WebRTC. Саме це робить relay масштабованим горизонтально: не потрібно підтримувати повний WebRTC-стан, relay можна взаємозамінювати безболісно, а відмова одиничної точки не зламає весь session.

Transceiver-рівень — єдиний сервіс, який має WebRTC session-стан, і включає перевірки ICE-з’єднання, DTLS-рукостискання, SRTP-криптографічні ключі та керування життєвим циклом session. Коли ці стани зосереджені в одному сервісі, належність session легше визначати, а бекенд-сервіси можуть масштабуватися як звичайні сервіси, без того щоб кожен із них був WebRTC-peer.

Суть цього дизайну в тому, що «частини, яким потрібен стан», і «частини без стану» розділено максимально жорстко. Relay — безстатний площинний шар даних (його можна масово копіювати), transceiver — станний контрольний шар (невелика кількість, але з повним станом). Таке розділення також дозволяє OpenAI масштабуватися відповідно до навантаження по горизонталі, не боячись вибуху кількості WebRTC-з’єднань.

Чому саме Go: логіка вибору для інженерії голосового AI

У тексті OpenAI прямо пояснює, що relay пишуть на Go та свідомо тримають його «вузьким». За цим вибором стоїть така інженерна логіка:

goroutine у Go нативно підтримують IO-bound задачі на кшталт «обслуговувати десятки тисяч з’єднань через один порт» без потреби в складному event loop

пакет net із стандартної бібліотеки напряму читає UDP-пакети, без необхідності прив’язуватися до C-бібліотек

після компіляції виходить один статичний binary: деплой, контейнеризація та кросархітектурність (x86/ARM) прості

керування пам’яттю в Go добре підходить для «великої кількості короткоживучих об’єктів» (бо кожен пакет треба парсити), а паузи GC можна контролювати

Це також пояснює, чому проникнення Go у сучасні інфраструктурні шари (Cloudflare, Tailscale, HashiCorp тощо) зростає — не тому, що «Go кращий за іншу мову», а тому, що Go максимально прямо «лягає» в IO-bound і потребуючі горизонтального масштабування сценарії побудови інфраструктури.

Прив’язка до Cloudflare: поле бою Realtime Voice AI

Паралельно (на початку травня) Cloudflare теж опублікувала технічний блог «Cloudflare — найкраще місце для побудови миттєвих голосових агентів» і запропонувала власну відповідь у дусі конкуренції з OpenAI. Обидва підходи розходяться:

OpenAI: власний стек relay/transceiver поверх WebRTC без залежності від сторонніх, з перенесенням і медіа-слою у свій технічний стек

Cloudflare: розглядає WebRTC-медіасервіси як розширення власної платформи Workers, надаючи розробникам «все-в-одному» інфраструктуру

Для команд із середнім і малим розміром AI-застосунків маршрут Cloudflare практичніший — можна напряму викликати API, не будуючи власну WebRTC-інфраструктуру. Для команд масштабу OpenAI власна побудова — неминучий шлях: SLA зовнішніх сервісів, структура тарифів і географічний розподіл не можуть повністю збігатися.

Подальші спостереження: відкриття transceiver, масштаб Realtime API, реакції конкурентів

Ключові моменти для наступного спостереження:

Чи OpenAI відкриє transceiver/relay — антропічні конкуренти, Google, xAI та інші теж будують власні голосові стеки; якщо OpenAI відкриє код, це може стати галузевим стандартом

Тарифи Realtime API та масштаб — наразі це здебільшого тримається на розподілі через підписку ChatGPT; якщо дохід від API зростатиме, чи не стане воно окремою продуктовою лінійкою

Відповідь Anthropic і Google — у Claude та Gemini вже є підтримка голосу, але за затримкою й масштабом OpenAI досі попереду; чи прискорить це їхню інженерну роботу після цієї технічної відкритості

Для тайванських розробників AI голосовий AI — ключове поле бою в другій половині 2026 року: сценарії на кшталт служби підтримки, освіти, автомобілів, IoT потребують діалогів із низькою затримкою. Інженерне розкриття OpenAI цього разу — один із найважливіших орієнтирів, щоб вирішити: «будувати голосовий стек самим чи використовувати сторонній API».

Ця стаття «OpenAI перебудовує WebRTC-голосовий стек: 900M тижневих активних користувачів, relay на Go як ядро» вперше з’явилася на 鏈新聞 ABMedia.