PRODUCT

Realtime API 是 OpenAI 的實時語音交互接口，在 24 年的 DevDay 首次亮相，當時還是 beta，調用貴到離譜，音頻輸出 200 刀/百萬 token：

兩個月后新加坡 DevDay，我在現場看了多語言混合輸入輸出的演示，情緒和語氣都非常到位，比 Whisper 鏈路的效果好了一個量級

之后經歷了 WebRTC 支持、SIP 電話接入、圖片輸入、多輪調價，到 2025 年 8 月正式 GA。現在這套系統服務數億周活用戶，語音 AI 這條線上，目前沒有第二家能打的

Realtime API 這個東西，最牛逼的是延遲：從你對著手機說一句話開始，到聽到 AI 返回聲音為止，只需要不到 0.3 秒

在這個過程中，聲音變成數據包，穿過 Wi-Fi、運營商的網絡、橫跨大半個互聯網，到達 OpenAI 的服務器。然后，服務器跑完推理、生成語音，再原路返回。整個過程必須快到讓你感覺不到延遲，就像跟一個真人在說話

對于這玩意兒是怎么實現的，OpenAI 今天發了個技術 Blog，來詳細介紹了下

https://openai.com/index/delivering-low-latency-voice-ai-at-scale/

然后...第二作者，是麥當勞

核心信息包括：

→ OpenAI 沒有用行業默認方案，自己設計了relay + transceiver兩層架構，前者只負責轉發數據包，后者負責所有通話狀態

→ relay 極其輕量，不解密、不解碼、不參與任何協商，只看數據包頭部的一小段標記就知道往哪兒轉

→ 全球各地部署了相同的 relay 入口，用戶的數據包在離自己最近的地方進入 OpenAI 的網絡

→ relay 用 Go 語言寫的，沒有用更底層的高性能方案，因為夠用了

→ 整套架構跑在 Kubernetes 上，對外只暴露少量固定端口

技術方案選型

OpenAI 用的實時通信協議叫WebRTC，就是你平時微信視頻通話、Google Meet 開會時底層跑的那套技術。它是一個開放標準，能在瀏覽器、手機和服務器之間傳輸低延遲的音頻和視頻

做 WebRTC 服務，行業里有一個默認選擇叫SFU（選擇性轉發單元）。簡單說就是一個中轉站，每個參與者跟它建一條連接，它負責把聲音和畫面轉發給其他人。多人視頻會議用這個方案很合適，音視頻編解碼、錄制、策略控制都集中管理

SFU 方案：AI 作為 WebRTC 參與者加入，適合多方通話

OpenAI 的場景不一樣。絕大多數會話是 1:1，一個用戶對一個模型，每一輪對話都對延遲極度敏感。SFU 帶來的多方通話基礎設施，在這個場景里是多余的

他們還評估過另一個常規方案TURN，這是 WebRTC 穿透防火墻時常用的中繼方式。但 TURN 要求中繼節點持有客戶端的連接分配狀態，不夠輕量

最后選的方案叫 transceiver 模型：在網絡邊緣部署一個 WebRTC 服務，負責跟客戶端完成連接建立、加密握手這些協議工作，然后把收到的音頻轉成更簡單的內部協議，分別送給后面的推理、轉錄、語音合成服務。所有通話狀態集中在 transceiver 一個地方，后端的 AI 服務可以當普通服務來擴展，完全不需要懂 WebRTC

transceiver 方案：在邊緣終止 WebRTC，轉換為后端協議

端口占用問題

選定 transceiver 方案之后，還有一個工程問題要解決：端口占用

傳統 WebRTC 部署里，每個通話需要占用一個獨立的網絡端口。當同時通話的用戶有幾百萬個的時候，端口會不夠用。OpenAI 的基礎設施跑在容器化平臺 Kubernetes 上，沒法給每個容器預留幾千個公網端口

他們的做法是把數據包的「轉發」和「處理」拆成兩層

relay是第一層，部署在面向公網的入口。它是一個極輕的 UDP 轉發服務：不解密通話內容，不跑任何協議狀態機，不參與編解碼協商，不知道你在說什么。它只做一件事，讀取數據包頭部的一小段標記來判斷這個包屬于哪個會話，然后轉發給對應的 transceiver

transceiver是第二層，在 relay 后面。它擁有通話的全部協議狀態，包括 ICE 連通性檢查、DTLS 加密握手、SRTP 媒體解密，以及會話的整個生命周期。從用戶的手機或瀏覽器來看，通話行為沒有任何變化

relay 只做無狀態轉發，transceiver 持有完整會話狀態

relay 持有的信息極其精簡：一條內存中的轉發映射（這個客戶端的包往哪個 transceiver 送），加幾個監控計數器和過期定時器。沒有持久化，沒有協議參與。如果 relay 重啟了，下一個數據包到達時就能自動重建路由

解決首響應問題

Realtime API 最牛逼的地方，是在 0.3 秒內完成首響應，這就需要對首包進行路由管理。用戶發出的第一個數據包到達 relay 時，relay 還沒有任何關于這個用戶的信息，但它必須立刻知道往哪里轉發。在這一步中，如果停下來查數據庫或者問別的服務都會增加延遲，是不行的

OpenAI 利用了 WebRTC 協議自帶的一個機制：ICE ufrag（ICE 用戶名片段）。這是在通話建立階段雙方交換的一個短標識符，之后客戶端發的每個連通性檢查包都會帶上它。OpenAI 在服務端生成 ufrag 時，把路由需要的信息編碼在了里面

具體流程：通話建立時，transceiver 分配好會話狀態，在協商應答（SDP answer）里返回一個共享的 relay 虛擬 IP 和 UDP 端口。客戶端看到的是一個固定的目標地址，比如203.0.113.10:3478，背后其實是整個 relay 集群

客戶端發出的第一個數據包通常是一個 STUN binding request。relay 只解析這個包頭部的 ufrag 字段，解碼出路由提示，把包轉發給擁有該會話的 transceiver。之后這個客戶端的所有后續包都走同一條已建立的路

從連接建立到媒體傳輸的完整時序：Client → LB → Relay → Transceiver

容災方面，Redis 緩存了「客戶端 IP:Port → transceiver IP:Port」的映射。relay 重啟后可以在下一個 STUN 包到來之前就從 Redis 恢復轉發路徑，進一步縮短中斷窗口

進行全球部署

如果用戶在北京說一句話，如果數據包要跑到美國西海岸才開始處理，單程網絡延遲就可能超過 150 毫秒，一來一回 300 毫秒。對話體驗會明顯卡頓。解決辦法是讓數據包盡早進入 OpenAI 自己的高速網絡

relay 的公網暴露面縮到少量固定地址和端口之后，同一套轉發邏輯就能在全球各地復制部署。OpenAI 把這個叫Global Relay，一組地理分布式的 relay 入口點，都運行相同的包轉發行為

Global Relay 接收全球客戶端的數據包，轉發給 transceiver 集群

用戶的數據包在離自己最近的入口進入 OpenAI 網絡，然后通過內部骨干網到達 transceiver。跟直接穿越公網相比，延遲更低，抖動更小，丟包更少

整套架構跑在 Kubernetes 上不需要暴露成千上萬個 UDP 端口。更小且固定的暴露面更容易做安全策略和負載均衡，擴展時也不需要預留大段公網端口范圍

底層是 Go 寫的

做實時媒體轉發，常規選擇是 C/C++ 或者 Rust，有些追求極致的團隊甚至會上 kernel bypass，繞過操作系統內核讓程序直接操作網卡。OpenAI 的 relay 用 Go 寫，這在行業里算非常規

他們在 Go 運行時層面做了幾個針對性優化：

→SO_REUSEPORT讓同一臺機器上多個 relay 進程共享同一個 UDP 端口，操作系統內核在它們之間分配數據包，避免單一進程成為瓶頸

→runtime.LockOSThread把每個負責讀 UDP 數據的 goroutine 釘在一個固定線程上，配合 SO_REUSEPORT，同一個通話的包傾向于落在同一個 CPU 核心，緩存命中率更高

→ 預分配內存緩沖區，最小化數據拷貝，避免在轉發熱路徑上觸發 Go 的垃圾回收

這套實現撐住了全球的實時媒體流量，relay 集群規模相對不大。所以他們沒有進一步走 kernel bypass 路線

補充一個細節：OpenAI 使用了Pion，一個 Go 語言的 WebRTC 開源庫。Pion 的作者 Sean Der 在 Hacker News 上確認了這一點

三條設計原則

對于這個項目，OpenAI 在總結了三條原則，對任何做實時系統的團隊都有參考價值：

→硬性狀態集中在一個地方transceiver 擁有 ICE、DTLS、SRTP 和會話生命周期，relay 只轉發。狀態集中意味著出了問題只查一個地方

→在已有信息上做路由ICE ufrag 是協議自帶的標識符，把路由信息編碼在里面，首包到達時就能路由，不需要在熱路徑上加外部查詢

→夠用就不換Go 配合幾個內核級優化對當前負載已經夠用，就沒有上 kernel bypass。先跑起來，再決定要不要換更重的方案

實時語音 AI 能跑起來，靠的是基礎設施讓延遲變得感知不到

OpenAI 改變的是 WebRTC 部署的內部形態，但沒有改變客戶端對 WebRTC 協議的預期

openai.com/index/delivering-low-latency-voice-ai-at-scale