OpenAI揭秘:如何让语音AI像真人一样低延迟对话

语音AI只有在对话速度跟上人说话时，才称得上自然。一旦网络拖后腿，用户立刻就能察觉到——尴尬的停顿、被截断的插话、迟缓的打断响应。

这对ChatGPT语音、Realtime API开发者、交互式工作流里的智能体，以及需要边听边处理的模型来说，都是致命伤。

服务9亿周活用户的三大硬指标

OpenAI的实时交互团队给出了三个必须同时满足的要求：

最近，他们彻底重构了WebRTC协议栈，核心是为了解决三个在超大规模下开始互相打架的约束：

WebRTC不只是浏览器视频通话的技术，它是一套开放标准，把交互媒体中最难啃的骨头都标准化了：

对AI产品来说，最关键的一点是音频以连续流的形式到达。 spoken agent可以在用户还在说话时就开始转录、推理、调用工具、生成语音，而不是等整段音频上传完。这就是"像对话"和"像对讲机"的区别。

OpenAI还直接挖来了WebRTC生态的两位奠基人：Justin Uberti（WebRTC原始架构师之一）和Sean DuBois（Pion库的创建者和维护者），现在都是OpenAI的正式员工。

SFU（选择性转发单元）是多人视频会议的经典方案，每个参与者连到SFU，SFU再选择性地转发流。这种模型适合多人通话、在线课堂、协作会议。

但OpenAI的 workload不一样——绝大多数是1:1，一个人对一个大模型，或者一个应用对一个实时agent。延迟敏感，每一轮对话都要快。

所以他们选了transceiver模型：一个WebRTC边缘服务终止客户端连接，然后把媒体和事件转换成更简单的内部协议，交给模型推理、转录、语音生成、工具调用和编排。

transceiver是唯一拥有WebRTC会话状态的服务：ICE连通性检查、DTLS握手、SRTP加密密钥、会话生命周期。后端服务不需要懂WebRTC，可以像普通微服务一样扩展。

OpenAI的初版实现是一个单体的Go服务（基于Pion），同时处理信令和媒体终止，支撑了ChatGPT语音和Realtime API。

但他们想让这个服务像其他服务一样跑在Kubernetes上——弹性扩缩容、跨主机迁移。

问题来了：传统WebRTC的"一端口一会话"模式，依赖大量公共UDP端口范围，这在K8s里很难暴露、安全管控和维护。每次pod增删改迁，端口范围都要跟着变，autoscaling形同虚设。

新架构把信令和媒体拆分：

Relay（中继）
：跑在边缘，只负责UDP包的转发和路由，不碰WebRTC状态。它用少量固定端口监听，把包按会话ID路由到对应的transceiver
Transceiver
：跑在K8s里，专注于WebRTC状态终止和媒体处理，不再需要大量公共端口

这样relay处理"在哪里"（路由），transceiver处理"是什么"（WebRTC语义）。两者可以独立扩缩容，relay可以按地理位置分布，transceiver可以按负载弹性伸缩。

这套架构现在支撑着ChatGPT语音和Realtime API的全球流量。OpenAI在博客里放出了架构图和关键代码思路，供整个行业参考。

从工程角度看，这不是简单的"扩容"，而是一次针对AI workload的协议栈重构——让WebRTC从"视频会议工具"变成了"AI交互基础设施"。