OpenAI 重构 WebRTC 语音堆栈：9 亿周活用户、Go 编写的 Relay 为核心

OpenAI 5 月 4 日公布语音 AI 基礎建设細節—为了支撐每週 9 亿活躍用戶（Weekly Active Users）的语音 AI 服務、團队重新设计 WebRTC 堆疊、把媒體连線層从傳统「一个埠对一个 session」的架構、改寫为以 Go 撰寫的薄型 relay、把所有 WebRTC session 狀態集中在一个叫「transceiver」的服務。OpenAI 官方部落格解釋、这套架構同时支援 ChatGPT 语音模式、Realtime API、与多項研究專案。对任何在做语音 AI 工程的團队、本案是「全球規模语音 AI 怎麼撐起来」的少见技術文獻。

三个技術限制：傳统 WebRTC 在 OpenAI 規模下都撞牆

OpenAI 工程團队在文中明確指出三个「在規模放大后互相衝撞」的限制：

傳统「一 session 一埠」的媒體終結（per-session port termination）方式不适合 OpenAI 基建—当每週 9 亿用戶可能同时开啟语音 session、每个都佔用一个埠的设计会耗盡網路资源

有狀態的 ICE（Interactive Connectivity Establishment）与 DTLS（Datagram Transport Layer Security）会話、需要穩定的擁有者—在分散式系统裡、若 session 狀態被多个服務分擔、容错与迁移会極为複雜

全球路由必須維持低首跳延遲（first-hop latency）—语音 AI 的「自然感」決定於 turn-taking（对話切換）的順暢、首跳超过 100ms 就会明顯卡頓

OpenAI 的需求清單同樣明確：全球觸及（覆蓋 9 亿+ 用戶）、快速 session 建立（用戶开口就能说話）、低且穩定的媒體 round-trip time（包含低 jitter 与封包遺失）。

解法：Go 寫的薄 relay + 集中式 transceiver 服務

OpenAI 的架構分为两層：

Relay 層—用 Go 撰寫、实作刻意保持簡單。一个普通的 Go process、从 socket 读封包標头、更新少量流量狀態、转发封包、不終結 WebRTC。这是让 relay 可橫向擴展的关鍵—不需要維持完整 WebRTC 狀態、relay 之间互換无痛、單点故障也不会中斷整个 session。

Transceiver 層—唯一擁有 WebRTC session 狀態的服務、包含 ICE 连線檢查、DTLS 握手、SRTP 加密金鑰、与 session 生命週期管理。把这些狀態集中到一个服務、让 session 的歸屬好推理、后端服務可以像普通服務那樣擴展、不必各自当 WebRTC peer。

这个设计的精妙之處在於：把「需要狀態的部分」和「无狀態的部分」嚴格分离。Relay 是无狀態的數據平面（可大量複製）、transceiver 是有狀態的控制平面（少量但狀態完整）。这个分層也让 OpenAI 可以随用量水平擴展、不必擔心 WebRTC 连線數量爆炸。

为什麼用 Go：语音 AI 工程的选擇逻辑

OpenAI 文中明確说明 relay 用 Go 寫、实作刻意保持窄。这个选擇背后的工程逻辑：

Go 的 goroutine 对「一个埠處理數万连線」这類 IO-bound 任務原生支援、不必複雜的事件迴圈

標準函式庫的 net 套件可直接读 UDP 封包、不必綁定 C 函式庫

編譯后是單一靜態 binary、部署、容器化、跨架構（x86/ARM）都簡單

Go 的記憶體管理对「大量短壽命物件」（每个封包都要解析）友好、GC 暫停时间可控

这也说明为什麼 Go 在现代基建層（Cloudflare、Tailscale、HashiCorp 等）的滲透率持续上升—不是「Go 比某语言更厲害」、而是「Go 在 IO-bound、需橫向擴展的基建场景中、寫起来最直接」。

Cloudflare 的对位：Realtime Voice AI 戰场

Cloudflare 同期间（5 月初）也发布技術部落格〈Cloudflare 是建構即时语音代理最好的地方〉、与 OpenAI 对位提出自家方案。两家路線分歧：

OpenAI：自建 WebRTC relay／transceiver 堆疊、不依賴第三方、把媒體層也納入自家技術棧

Cloudflare：把 WebRTC 媒體服務作为自家 Workers 平台的延伸、給开发者「一站式」基建

对中小型 AI 应用團队、Cloudflare 路線更实用—直接呼叫 API、不必自建 WebRTC 基建。对 OpenAI 規模的團队、自建是必经之路—外部服務的 SLA、计费結構、地理分佈都不可能完全配合。

后续觀察：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 语音堆栈：900M 週活用户、Go 写的 relay 为核心 最早出现在 链新闻 ABMedia。