首页近期，OpenAI 发布了一篇关于他们如何在大规模下实现低延迟语音 AI 的技术博客，引发了业内的广泛关注。在 WebRTC.ventures 最新的一期访谈中，业内专家 Tsahi 对这篇博客进行了深度解读。这段视频访谈讨论了 OpenAI 最近公开的 WebRTC 架构设计，强调了其在语音 AI 领域的技术突破。
访谈深度解析了OpenAI 并未遵循行业传统的 SFU（多方视频服务器） 架构，而是构建了一个支持大规模、低延迟通信的定制化网关。该方案通过取消 TURN 服务器并采用单端口 UDP 路由，极大地简化了网络传输路径。这种架构更接近云游戏的模式，证明了 WebRTC 在非视频会议场景下的强大潜力。
总的来说，这是一次对大型科技公司如何通过技术透明度推动实时通信标准进步的深度解析。以下是本次访谈揭示的核心亮点内容总结，非常适合作为技术团队与开发者的参考。
一、 终结争论：对 WebRTC 最强力的生产级背书
一直以来，业内都在争论大规模实时语音 AI 是否应该放弃 WebRTC，转而使用 WebSocket，或是尚在探索中的 WebTransport。OpenAI 的这篇博客直接给出了答案：他们在生产环境中、在极其庞大的规模下，坚定地使用了 WebRTC。
Tsahi 特别指出，OpenAI 展现了极其罕见的技术透明度。在过去两三年里，几乎没有任何公司会像他们这样，不仅公布“做了什么”，还事无巨细地公开“为什么这么做”背后的技术决策逻辑。博客中不仅透露了其底层基于 Go 语言构建，还公开致敬了 Pion 开源项目的贡献者 Sean DuBois，以及现任 OpenAI 团队成员的 WebRTC 巨头 Justin Uberti。
二、 极其反直觉的架构抉择：抛弃 SFU 与 TURN 服务器
OpenAI 的架构设计几乎完全违背了 WebRTC 行业目前的“常规最佳实践”，但在其特定的语音 AI 场景下却无比精妙。
1. 彻底放弃 SFU（选择性转发单元）
行业的默认做法： 目前绝大多数语音 AI 应用（如接入 Live、Pipecat 或 Daily）都会默认使用 SFU 及其媒体服务器基础设施。
OpenAI 的反叛： 他们拒绝引入 SFU。正如业内专家 Gustavo Garcia 在他最近的文章中所指出的，SFU 对于这种场景只是一个不必要的“活动部件”（Moving part）。
云游戏视角的降维打击： Tsahi 认为，OpenAI 的使用场景更类似于“云游戏”。服务器只需要直接连接到单一用户即可，完全不需要经过 SFU 进行多路媒体转发。
关键提醒： 访谈中特别强调，这并不意味着所有应用都要抛弃 SFU。如果你在构建一个标准的多人视频会议工具，哪怕是有 AI 语音助手加入会议，你依然必须使用 SFU。OpenAI 的架构不可盲目照搬。
2. 为什么没有 TURN 服务器？
这很大程度上受到了 Justin Uberti 过去在 Google 经验的影响。就像 Google Meet 也不使用 TURN 服务器一样，OpenAI 的客户端永远是直接连接到公共互联网上完全可达的服务器，因此 TURN 服务器在这里毫无用武之地。
三、 极致剥离复杂性：网络入口与单点路由扩展
1. 单一 UDP 端口与 Docker 局限性考量
OpenAI 规定所有的 UDP 网络流量（TCP 本身总是单端口）全部通过一个单一的 IP 端口进入。
背后的原因： OpenAI 团队重度使用 Docker。然而，Docker 在动态管理大量网络端口时，面临着扩展性和安全性上的诸多难题（访谈中戏称为“security blah blah blah”）。为了规避 Docker 的这些短板，他们强制采用了单端口策略。
行业对比： Tsahi 指出，这与业内其他巨头（如 Cloudflare 的 TURN 服务器、Twilio 或 Zoom 的专有方案）的做法完全不同，证明了在解决特定问题时，存在截然不同但同样有效的路径。
2. 极其专一的无状态路由与 ufrag 黑科技
OpenAI 将所有最硬核、最复杂的扩展难题，全部从客户端和普通后端剥离，集中放置在负载均衡器后方的一个单一功能的路由节点上。他们专门针对这一个组件进行极致扩展。
客户端通过 WebRTC 连接到边缘节点后，会在系统内部被“网关（Gateway）”转化为系统所需的其他内部协议（Tsahi 强调这里是 interworking 而不是 interoperability）。
ufrag 黑客级复用： 为了让负载均衡器保持完全无状态（Stateless），他们复用了 SDP（会话描述协议）中 ICE 协商里的 ufrag 字段来进行数据包的路由识别。ufrag 的协议标准初衷并非用于这种复杂路由，但在面对无数不同客户端、难以区分数据包来源时，OpenAI 巧妙地利用这个现成字段，精准识别了数据包的归属。
四、 返璞归真的操作系统（OS）级底层优化
在追求极致性能时，OpenAI 并没有钻牛角尖去修改复杂的 Linux 内核空间（Kernel Space），而是让整个 UDP 管道运行在用户态（User Mode），因为这已经足够高效。他们仅仅采用了两项拥有 10 到 20 年历史、但极其经典的 OS 级优化策略：
多进程、单线程处理 UDP： 虽然外部入口只有一个端口，但在多核服务器内部，他们运行了多个单线程进程来处理路由。每个进程分配不同的套接字（Socket）。即便来自同一个用户的不同数据包被分配到了同一台机器的不同进程上，底层的路由机制依然能完美接管并处理。
CPU 绑定（CPU Pinning）： 强制要求特定的进程始终在同一个 CPU 核心上运行。这能最大化地利用缓存（Caching）和线程局部性（Thread Locality），避免上下文切换的损耗。
五、 WebTransport、Websocket 与未来的演进猜想
尽管博客通篇只字未提 WebSocket 或目前热门的 WebTransport，但这代表 WebRTC 就是终局吗？
没有什么是永久的： 经历过 H.323 到 3G-324M 再到 WebRTC 演进的 Tsahi 认为，技术栈永远在变。
20-30 毫秒的阈值： OpenAI 渴求的是最快连接、极高扩展和超低延迟。未来如果有任何协议（如 WebTransport）能在延迟上再压缩 20 到 30 毫秒，OpenAI 绝对有动力去尝试。
9 亿月活的底气： 凭借高达 9 亿的周活跃用户量，OpenAI 完全有能力在底层同时支持 WebRTC 和 WebTransport。他们甚至可能出于降低成本或特定场景的考虑，在文本交互层面继续保留 WebSocket。
参考来源
