OpenAI Developers 发布新动态，提升开发者接入体验（🎙️ Voice AI only feels natural when conversati

🎙️ 只有当对话与语音同步时，语音 AI 才会感觉自然。以下是我们如何使用瘦中继和状态收发器重建 WebRTC 堆栈，以保持 ChatGPT 语音、实时 API 等实时媒体的快速传输。

Voice AI只有在对话与语音同步时才自然，OpenAI重建WebRTC堆栈，使用瘦中继和状态收发器，提升ChatGPT语音及Realtime API的实时传输速度。

• OpenAI 升级 WebRTC 堆栈，降低语音延迟
• 瘦中继与状态收发器是核心优化点
• 对 Realtime API 和 ChatGPT Voice 直接受益
• 开发者可参考架构或直接使用 API
• 关注后续开源与成本信息

这是什么信号？

OpenAI 开发者团队披露了其 WebRTC 堆栈的架构升级，核心是引入瘦中继和状态收发器，以降低语音交互的延迟。这标志着 OpenAI 将实时语音质量作为优先级，而非仅停留在模型能力上。

为什么重要？

语音 AI 从“能说”到“像真人一样对话”的关键在于延迟控制。传统 WebRTC 方案在复杂网络下易出现抖动，而 OpenAI 的定制化改造意味着它正为大规模实时语音交互铺设底层基础设施。这对所有依赖语音接口的开发者是直接利好。

对谁有价值？

1. 语音应用开发者：可直接借鉴其架构思路或使用 Realtime API 构建低延迟产品。2. AI 产品经理：理解实时性如何影响用户留存。3. 技术决策者：评估自建 vs 调用 API 的 trade-off。

可以怎么行动？

1. 阅读原文技术细节（链接已附），评估是否适配自身场景。2. 对比其他语音方案（如 Azure Speech），测试延迟差异。3. 关注 OpenAI 后续是否开源或标准化该 relay 方案。

风险或限制

该方案目前仅针对 OpenAI 自身接口，通用性有限。若网络环境恶劣，瘦中继可能成为瓶颈。此外，实时 API 的成本和可用性尚不透明。

信息差价值：多数人只关注 ChatGPT 的模型迭代，忽略了底层传输层的优化。这篇分享揭示了 OpenAI 对实时性的技术投入，是普通开发者难以从公开文档中获取的细节。

业务启发：如果你的产品涉及语音交互，延迟不是“优化项”而是“必选项”。可借鉴其 relay 思想，在客户端与服务端之间增加轻量代理层，而非全双工直连。

可沉淀动作：1. 将本文归档至“AI 基础设施”选题库，作为语音实时性案例。2. 对比测试 OpenAI 与竞品的语音延迟，输出测评内容。3. 与团队分享后，纳入技术选型 checklist。

• @OpenAIDevs 原帖