WebRTC 里很多机制最初是针对人类感官调优的……那些专为人类会议场景打造的设计，搬到 AI 时代都需要重新审视与校准。——Justin Uberti

如果你在浏览器里打过视频电话、开过在线会议，背后大概率都有 WebRTC 的影子。Justin 是 WebRTC 最初的架构师之一，曾任 Google 杰出工程师，参与推动 Meet、Duo、Stadia 等实时通信与流媒体产品。如今，他担任 OpenAI Realtime AI 负责人，带领团队把 WebRTC 从「连接人与人」的基础设施，继续推进为「连接人与 AI」的实时交互底座。

OpenAI 近期披露的 GPT-Live 架构，正是 Justin 与团队用六个月搭建并落到 ChatGPT Voice 生产规模的实时语音系统：让模型持续接收和生成音频，把复杂推理与工具调用放到异步路径，并通过 Go、WebRTC、WARP 等工程优化压低延迟。也就是说，这次访谈不是概念讨论，而是一位 WebRTC 创建者在亲手建设下一代语音 AI 之后，对实时通信架构的重新审视。

这场对话从 WebRTC 为人类感官留下的历史假设讲起，一路谈到 GPT-Live 的全双工架构、双模型解耦、1 RTT 建连、Python 到 Go 的迁移，以及「永远在线」的 AI 交互。我们摘录并整理了其中最值得开发者关注的部分，希望能给大家带来一些新视野。Enjoy~

核心观点

Justin Uberti

OpenAI 实时 AI 负责人、WebRTC 的创造者

• GPT-Live 从轮次对话走向持续流式： 端到端音频模型持续接收并生成语音，不再让小型轮次检测器决定何时开口；实时听说与深度推理采用双模型解耦，工具调用和搜索在异步路径完成，不阻塞语音循环。

• 我们需要面向机器重新校准 WebRTC： NetEQ 的丢包隐藏、抖动缓冲和 AEC 的非线性处理原本为人耳设计，但在 AI 场景中可能掩盖信息或损伤语音，需要从「听起来更顺」转向「让模型获得更真实的信号」。

• 实时语音 AI 仍然绕不开 WebRTC： 当模型在亚秒级时间线上持续处理音频，每一毫秒都会影响体验，低抖动传输、丢包恢复、前向纠错和连续媒体流因此成为系统的基础能力。

• 从 Chrome 到 OpenAI，小团队可以更快实验： AI 编程工具把许多实验从几天压缩到几小时，让更小的团队也能快速验证实时交互的新架构，但核心系统仍需要扎实的工程判断。

• 「都 2026 年了，我们应该有那种启动速度快得离谱的东西」： WARP 与 Instant Connect 把建连压到 1 个 RTT。通过并行 ICE 与 DTLS、预协商 SCTP 和数据通道，并在用户点击前准备好连接参数，WebRTC 可以显著缩短语音 AI 的启动等待。

• 实时系统的核心指标是能否按时交付每一帧： OpenAI 用 Go 重写 Python asyncio 媒体前端，并以 missed deadline 衡量系统是否过载；在连续音频场景中，稳定的尾部延迟比平均吞吐更重要。

• 无需唤醒词的「永远在线」交互正在成为可能： 当模型能够持续理解上下文、判断用户是否在对它说话，并在用户思考时保持安静，语音 AI 将从被动响应工具逐步走向长期陪伴式的实时界面。

---

Built with WebRTC 直播

嘉宾： Justin Uberti（Justin Uberti，OpenAI 实时 AI 负责人、WebRTC 的创造者）

主持人： Tsahi Levent-Levi（独立分析师，BlogGeek.me）

注：为便于阅读，本文内容已作精简，并非完整对话。你可以访问原文收听完整版播客。

---

在迈向人机交互时代的过程中，WebRTC 的哪些设计需要重新校准？

Tsahi： 2011、2012 年你们开始做 WebRTC 的时候，把很多假设被固化到了架构之中。现在 15 年过去了，你从一个构建者变成了使用者，尤其是从「人对人」变成「人对机器」，这些假设里有哪些需要重新审视？

Justin Uberti： 总的来说 WebRTC 跑得很好——视频会议、游戏串流，现在又到了 AI。但现在我是 WebRTC 的「消费者」而不是「所有者」，会更清楚地意识到它由 Google 主导，你必须去对齐它的节奏。

最近我们一直在研究：机器感知和人类感知有什么不同？ WebRTC 里很多机制是为人类感官调优的，我举两个例子。

第一，NetEQ（网络抖动缓冲区） 的丢包隐藏机制对人耳好，对机器未必。 当包迟到或丢失时，WebRTC 会拉伸前一段音频来填补空白。人耳听起来更顺，但机器有很强的语义补全能力，直接补静音或标记丢包，可能反而更好。

第二，回声消除里的非线性处理（NLP）会损伤用户语音。 NLP 是一把挺重的锤子，在双讲场景（double‑talk scenario，AI 和用户同时说话）中，AEC（回声消除，Acoustic Echo Canceller）为了不让系统听到自己的回声，会用「重锤」削掉残余回声，但也会把用户语音削坏。对人来说回声很讨厌，但机器能处理听到自己的回声，却很难恢复已经被削薄或失真的语音。

所以这些为人类会议场景做的设计取舍，放到 AI 场景里需要重新校准。

Tsahi： 你之前说，我们可能不需要像 WebRTC 里那样处理丢包或抖动缓冲，这指的是机器这一侧？

Justin Uberti： 对。人类这一侧还是老样子——浏览器或客户端需要处理网络抖动、丢包、回声等。但在把音频送进模型之前，NetEQ 的语音延展（PLC）和抖动缓冲对人耳更好听，却不一定对机器更好。你直接告诉模型「这里有一段丢包」或保持静音，大模型很擅长推断缺失内容。

另外，模型产生音频的方式和麦克风不一样。

人类说话是连续采样的，而模型可能一次吐出一整段音频。这意味着那些保护「连续麦克风流」的网络机制，对「块状模型输出」未必最优——你需要保护的是整段输出，而不是逐采样流。我们也在看怎么扩展 NetEQ 的思路来适应这种新世界。

Tsahi： 那你会不会干脆建议今天在客户端关掉 AEC，让服务器拿到更干净的用户语音？

Justin Uberti： 问题变复杂了。客户端 DSP 链里 AEC、AGC、降噪都缠在一起：如果你关掉 AEC，回声的强信号会迫使 AGC 做出不自然的动作，整个链都会乱。所以我们真正想要的不是关掉 AEC，而是别让 NLP 这把重锤打得太狠。对人来说，会议室里谁有回声谁就是灾难；但对 AI 来说，让它听到一点自己的回声，也比用户语音被削薄或失真要好——机器能处理回声，却恢复不了被 NLP 破坏过的语音。希望未来能通过 AEC3 的配置暴露更多控制，让开发者选择只做线性消除或降低 NLP 强度。

---

GPT Live 的架构革命：端到端音频流 + 双模型解耦

Tsahi： 最近发布的 GPT Live，和之前两三个月前宣布的东西有什么本质区别？

Justin Uberti： 这次发布相当于把 GPT Live 背后的系统「揭开窗帘」。之前语音模式收到最多的批评是两点：

一个是模型太笨。 有很多有趣的情况，比如「我应该走路去洗车店还是开车去」，这种问题上模型会出错。另外，如果你说话时停顿了一下，模型可能会打断你。

另一个是说话不自然、容易被背景噪音或停顿打断。 如果有背景噪音，模型可能会说「我没听清」。有很多情况会让你立刻从这种沉浸感中脱离出来，只要环境条件稍微不对就会这样。

所以我们真正的两个目标是：让它说话更自然、更擅长口语表达，以及让它更聪明。我们觉得我们基本同时实现了这两个目标，对此感到很兴奋。

背后是两大架构变化。

第一，端到端音频流。 过去常用的架构是：先把你的语音转录成文字，然后输入给语言模型，再把输出传给语音合成 TTS。这种架构其实用得还不错，但它非常依赖一个脆弱的组件：turn detector（轮次检测器）。这个检测器的作用基本上是判断你什么时候说完了，或者你什么时候开始再次说话以进行打断。这些模型通常很小，甚至有些像 WebRTC VAD 这样的技术也被用在这个地方。

但它们是小模型，工作方式更像是传统机器学习，而不是大语言模型 LLM 的方法。

因此它们只能通过「是否有静音」这类音频层面的特征来推断你是否说完了，而无法利用语义线索之类的东西。我在前一家创业公司 Ultravox 工作时，有很多基于这种架构的产品，我们觉得很难取得进展。

如果你只能依赖这种轮次检测器，用一个小小的外部大脑来控制大模型什么时候运行，我称之为「一个小孩在替大人做决定」。

它没有足够的理解能力，没有足够的语义能力。它永远是一个脆弱的环节，即使 95% 的时间能工作，也不够好。

所以我们需要找到一种方法，能够持续不断地把音频输入给大模型。这是最重要的一点：我们改变了整个系统的流程。不再是让轮次检测器决定大模型什么时候运行，而是大模型始终在接收音频并生成音频。

第二，双模型解耦。 我们意识到训练模型来理解语音并生成语音，往往需要消耗相当多的神经回路（neural circuits），当神经回路被分配给语音处理时，用于通用信息理解的资源就少了。这些模型虽然能处理实时音频，很酷，但结果变得更笨了。于是我们把它拆成两个模型：

一个专门实时听说（GPT Live 模型），另一个负责深度推理、搜索、工具调用（前沿模型）。

通过这样做，我们能够把前沿模型的最强思考能力，与新的 GPT Live 模型的出色说话能力结合起来。具体如何运作还有很多细节，但现在你拥有了一个非常擅长说话的系统，它持续接收和发出音频。当它需要更多信息时，可以咨询前沿模型，进行更深入的推理、思考、搜索等。这种解耦从一开始就带来了很多可能性。

GPT-Live 系统架构示意图。 系统分为实时媒体路径和异步委托路径两条通路。用户的语音流通过媒体前端与 GPT-Live-1 语音模型进行实时双向交互；当需要复杂推理或外部工具支持时，媒体前端会将任务异步委托给应用服务器，由 GPT-5.5 文本模型调用搜索、代码、检索等工具完成处理，并将结果返回给前端以继续对话。

Tsahi： 我想确认一下我的理解是否正确。你们的实时模型（Live model）本质上是一个「说话模型」——它的专长是语音交互的自然度和流畅度，而不是复杂推理。真正的智能来自后端的前沿模型，可能是 GPT-5、GPT-6 乃至更远的版本。

而且因为两者解耦，你可以独立升级前沿模型（GPT-5、GPT-6……）而不改动 Live 语音模型。

当对话进入需要深度思考的环节时，Live 模型可以通过类似人类「停顿思考」的方式争取时间，向后台模型请求结果，再将其转化为自然的语音回应。

这种分离也意味着，模型的压缩与部署可以和对话过程并行。你可以持续把更大、更强的前沿模型做轻量化，并实时替换上线，而不会干扰前端的实时对话。

这种解耦从一开始就带来了很多可能性。

Justin Uberti： 是的。我觉得有些人可能会看这个系统然后说，你看，最终还是得在后台某处调用一个 LLM，像一个级联系统。但我认为这里有一个非常重要的细节：

「我们把这一切都变成了异步的，语音循环永远不会被编排或工具调用阻塞」

这个语音模型虽然没有所有信息，但它本身也相当聪明，可以去向这些前沿模型请求更多信息。它甚至会像人一样说：「我觉得你应该选 A……哦不对，选 B 吧」。这不仅是实时更新理解的一种方式，也让人感觉非常像人类。

使用 GPT-5.5 Instant 的 GPT-Live-1 对话示例

Tsahi： 这很有意思，因为我以为我们有了某个能说话的东西。然后关于这一点你纠正了我。它本身其实挺聪明的，只是没有前沿模型所能提供的全部答案。只要它能回答简单问题，或者利用自己的聪明才智在等待完整答案时推进对话，这就足够了，而且它的上下文中通常已经包含了不少信息。

Justin Uberti： 比如你问「我们刚才聊了什么」之类的问题，它不需要说「让我查一下」，因为它已经有这个信息了。但你问「我最近的 PR 状态是什么？」，说话模型可以继续跟你闲聊，同时异步让前沿模型去查 GitHub。

这种边说边想、实时自我纠正的感觉非常像人类。

你问「2023 年超级碗谁赢了」，它也可以边说边从记忆里检索答案。

这已经不再是回合制，而是流式的了。

---

为什么实时语音 AI 绕不开 WebRTC？

Tsahi： 既然变成流式，那还要 WebRTC 吗？WebSocket、WebTransport、Media over QUIC 不行吗？

Justin Uberti： 前几代的架构通常是这样：它给人一种实时的感觉，但实际上发生的是，系统会在你说话时缓冲你的音频，等待轮次检测器判断"哦，他们说完了」，然后一次性把所有音频喂给模型，说：去转写、生成、把文本给我。然后你做 TTS，生成语音，再把这段语音发回给用户。因为处理的是这种一块一块的音频，所以即使只用 WebSocket 之类的方案也能走得相当远。因为你相当于一次性拿到所有信息，再一次性发给客户端。当然，你仍然要处理打断这类问题，但它不需要严格意义上的实时，因为模型不是实时被喂数据的。

但 Live 模式完全改变了这个动态——模型延迟完全取决于音频进出的速度，我们在亚秒级时间线上运作，每一毫秒都重要。当你感觉到模型在你还没反应过来之前就回应你了，这就是降低延迟带来的魔力。

WebRTC 的 NetEQ、低抖动缓冲、丢包恢复、前向纠错这些能力就变得非常关键。我们还必须把驱动模型的系统和 WebRTC 系统紧密耦合，遇到丢包时才能把对用户的打扰降到最低。

Tsahi： 你给模型喂的音频到底是什么格式？

Justin Uberti： 具体细节不能透露，但大致是带时间戳的连续音频帧。模型也接受过真实世界音频的训练：丢包、窄带/宽带、噪声、各种网络条件等，它需要知道真实对话听起来是什么样。

---

从 Chrome 到 OpenAI：更小的团队，更快的实验

Tsahi： 代 Serge提问（Google RTC 的产品经理），在 OpenAI 做软件和当年在 Google Chrome 做软件有什么不同？

Justin Uberti： Chrome 是上千人的大组织，做平台必须堆很多人。现在工具进步了，小团队也能做顶尖软件——并不是说整个项目都能靠 vibe coding 完成，而是每个开发者做实验的速度从几天变成几小时。

但有一件事我觉得 Google 和 OpenAI 非常相似，那就是在 Google 有一种观念：当发现了一种相当新颖的东西，就是把这些基于 Web 的应用放到云端，把资源放在云上，而不是沿用之前的模式。

每个人都会受到鼓励：如果我们把 Docs 放到云端会怎样？如果把邮件放到云端会怎样？如果把 Web 会议或视频会议放到云端会怎样？感觉好像很多东西都可以做「Cloud X」，说不定你真能做出一个爆款产品。

我觉得 OpenAI 这里也是一样：如果我们把 AI 加到 X 上会怎样？AI for finance（金融 AI）、AI for voice（语音 AI）等等。并不是所有尝试都会成功，但试错速度非常快。

Tsahi： 你个人怎么用语音 AI？

Justin Uberti： 我已经养成两个习惯。

一是「倒笔记」（dumping notes）： 把脑子里想的东西随口说出来，让 AI 整理，后续再追问「我们上次聊的那个点子，哪些值得继续？」

二是语音远程驱动 Codex： 我觉得想法随时都可能涌现。我就是这种人，比如遛狗时突然有灵感，就打开语音会话让 Codex 跑实验、改参数，实时汇报结果。Codex 就像在我耳边一起头脑风暴的伙伴，从念头到探索的路径变得非常短。

另外通勤时做简报、读消息也很有意思。iOS 客户端已经支持 CarPlay，但我开特斯拉，所以享受不到——未来还有很多空间。

---

WARP 和 Instant Connect：把 WebRTC 通话建立压到 1 个 RTT

Tsahi： 你们怎么把 WebRTC 通话建立时间压缩到 1 个 RTT（一次网络往返）？

Justin Uberti： 我们非常专注，我们真的想让进入语音的体验变得极其快、疯狂地快。先做了显而易见的事：对系统做性能剖析、去掉不必要的 RPC（远程调用）。但很快卡在往返次数上。

Matthew Kaufman（RTMFP 发明人、前 Microsoft/Skype WebRTC 首席架构师）多次指出 WebRTC 积累了太多历史包袱；后来我和 Philipp Hancke（WebRTC 资深贡献者、rtcstats 联合创始人）一起喝啤酒时聊，觉得每层都能省：

- SCTP 握手可以省掉，已有 DTLS/ICE 流程里就能交换 SCTP 所需信息；

- 数据通道预协商再省一轮；

- DTLS 1.3 比 1.2 少一轮握手；

- ICE 与 DTLS 并行，把本来串行的流程重叠起来。

最终把媒体面握手降到单个 RTT。

都 2026 年了，我们应该有那种启动速度快得离谱的东西。

背后的思路，简单来说就是：因为 WebRTC 里有多个协议需要协商，分析每个协议负责什么，如果它们做的是同一件事，我们就干脆去掉重复的部分，同时让前面的协议顺带完成我们之前已经做过的事情。

图注： 左侧为标准 WebRTC 握手流程：SDP 交换后，ICE、DTLS、SCTP、数据通道打开（DCEP）依次进行，数据通道就绪需要 6 个 RTT。右侧为 OpenAI WARP 优化：将 ICE 连通性检测与 DTLS 握手合并到同一个 RTT 中，媒体与数据在 1 个 RTT 后即可开始传输。

但这还不够。信令交换也是 P95 延迟的大头。

我们设计了 Instant Connect（可理解为「预连接」或「瞬时连接」）：在用户按下通话按钮前，就把 ICE 候选地址、DTLS 参数、数据通道配置等预先协商好，但不在服务器上维持实际点对点连接。真正拨通时，只剩 1 个 RTT 的媒体面握手。

---

从 Python 到 Go：实时系统不能错过 20 毫秒的 deadline

Tsahi： 为什么从 Python 切到 Go？这几乎和 AI 行业的惯性相反。

Justin Uberti： AI 行业围绕 Python 是因为表达力强、生态好。但当我们需要在 10–20 ms 的节奏 上稳定运行时，Python 的 GIL（全局解释器锁）和各种类似问题会让尾部延迟变得很差，导致音频缓冲区下溢、不得不加缓冲。

现在有一股趋势，就是用 Go 和 Rust 重写系统。

我了解行业内正在进行的其他一些实时项目，它们也在走基于 Go 和 Rust 的系统这条路。我觉得，这个模型的一个关键方面就是它能够实时处理这些事情，这将成为未来交互式 AI 的基础。这只是一个例子，但未来还会有其他应用，任何需要在现实世界中运行的事物都需要具备同样的精度、同样的运行能力，也就是说，不能因为别人的异步处理程序卡太久而让你的系统也停止思考。

迁移分两步走。

第一步先围绕 Pion（Go 的 WebRTC 实现）重建实时音视频栈，这很成功。

第二步更大的争论是模型推理层是否也要切到 Go，Python 生态太强了。

但一旦把 Go 表面做出来，数字说明了一切——Go 的 P95 帧交付已经和 Python 的 P50 相当，平滑度和尾部延迟都好得多。

Tsahi： 从轮次请求变成持续流式推理后，扩容指标发生了什么变化？

Justin Uberti： 以前看 GPU 上能放多少个推理请求。但流式系统里，瓶颈可能出现在任何环节——这就是阿姆达尔定律（Amdahl’s Law）。当 GPU 负载上去后，我们看到截止时间被错过，用户能听到音频断档。

所以我们引入的新指标是错过截止期限的频率「missed deadline」——模型是否按时产出每一帧音频。它告诉我们系统是否跑得太热，而不仅仅是 GPU 利用率。

---

告别唤醒词：AI 可以永远在线倾听吗？

Tsahi： 好的，我再问一个来自观众的问题，这个问题来自 Alexander。这是否意味着未来会出现一直在线、无需唤醒词、持续理解上下文的系统？

Justin Uberti： 是的，这某种程度上就是我们正在迈向的未来，但但我想说得更谨慎一些。GPT Live 已经能自然判断你是否在对它说话，也知道你思考时不要插嘴，加上连续的上下文压缩与管理，我们可以拥有长期运行的实时 AI 会话，不再需要「Hey Siri」这样的唤醒词。

Tsahi： 我知道我学到了很多，等你做了其他项目，我一定会再邀请你，感谢。

---

参考与来源

• Built with WebRTC 直播回放：

  https://www.linkedin.com/events/7485922769654824960/

• OpenAI 解析 GPT-live 技术博客：

  https://openai.com/zh-Hans-CN/index/continuous-voice-interaction-with-gpt-live/

• Pion github：

  https://github.com/pion/opus

• WARP 协议：

  https://datatracker.ietf.org/doc/draft-uberti-tsvwg-warp/

往期 OpenAI 相关 Voice Agent 学习笔记

WebRTC 创建者刚加入了 OpenAI，他是如何思考语音 AI 的未来？

全网首拆 ChatGPT Voice for Codex 安装包：当语音成为 Coding Agent 的下一代实时交互入口

OpenAI Realtime API 重磅更新：锚定语音模型「深度推理+自主执行」演进路径

OpenAI 揭秘 Tolan 背后 AI 技术：如何让语音智能体拥有连贯记忆和稳定人格？

编译：@三水、@鲍勃

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么