OpenAI 低延遲 Voice AI 架構：WebRTC 能解規模問題，也暴露 Voice AI 傳輸層取捨

AI Infrastructure / Voice AI

OpenAI Voice AI 的傳輸層難題：低延遲、完整語音、全球規模，很難同時滿足

這則 Threads 只貼了 OpenAI 技術文〈Delivering low-latency voice AI at scale〉。真正值得保存的是它背後的架構問題：Voice AI 不只是模型與 TTS，還有即時語音封包、瀏覽器協議、UDP routing、Kubernetes scaling、load balancing、packet loss 與安全權限的整套基礎設施取捨。

來源 caveat：OpenAI 原文頁面在本次擷取時被 bot protection 擋住，本文以 Threads 暴露的官方 URL、可擷取的 secondary technical deep dive，以及 MoQ 作者對 OpenAI WebRTC 架構的評論交叉整理。OpenAI 官方主張與 MoQ 批評需分開看：前者是在描述已落地的可擴展架構，後者是在質疑 WebRTC 是否是 Voice AI 的長期最佳協議。

OpenAI 解的問題

Realtime Voice AI 需要把使用者語音低延遲送到模型，再把 TTS 音訊即時回傳。這要求瀏覽器 / mobile client、媒體協議、全球 routing、推理 backend 能一起低延遲運作。

WebRTC 的現實優勢

WebRTC 是目前瀏覽器端即時音訊最成熟的原生方案：支援 NAT traversal、media transport、jitter handling、跨平台 client，不需要每個產品重造輪子。

OpenAI 架構重點

secondary source 指出 OpenAI 使用 relay + transceiver：relay 做無狀態 UDP/STUN routing，transceiver 保留 WebRTC session state、ICE/DTLS/SRTP 與媒體處理。

爭議點

MoQ 作者批評：WebRTC 是為視訊會議的「寧可丟包也要低延遲」設計；Voice AI 則更需要完整 prompt，丟掉音訊可能比多等 200ms 更糟。

面向	WebRTC / OpenAI 當前路線	MoQ / QUIC 批評與替代思路
瀏覽器支援	成熟、原生、可立即落地	WebTransport / MoQ 還在成熟中，短期落地成本較高
弱網策略	偏向保低延遲，可能丟 audio packet	Voice AI 可能應偏向 prompt 完整性，必要時多等一點
TTS 回放	WebRTC 依到達時間渲染，buffer control 受限	QUIC / app-level protocol 可設計更明確的 buffer 與可靠性策略
連線建立	ICE / DTLS / SCTP 等流程可能需要多個 RTT	QUIC + TLS 合併握手，理論上 1 RTT 起步
負載均衡	需處理 UDP session affinity、relay routing、可能依賴 shared state	QUIC Connection ID / QUIC-LB 可做 stateless routing
產品風險	現在可用，但協議複雜度高	架構更乾淨，但標準化與 ecosystem 尚未完全取代 WebRTC

對 Voice AI 產品團隊的設計啟發

傳輸協議是產品決策，不只是 infra 決策。使用者寧願快但聽錯，還是慢 200ms 但 prompt 完整？不同產品答案不同。