OpenAI 如何打造 GPT-Live

如果你用过语音助手，大概遇到过意料之外被打断的情况。你正和系统说话，刚停顿片刻想找个合适的词，它就开始说话了。于是你只好打断它，才能继续说下去。这种令人抓狂的情况很常见，因为大多数语音模型要么能听，要么能说，却无法同时兼顾两者。

像 OpenAI 的 GPT-Live-1 这样的新一代语音模型改变了这一点，它能边听边说。模型会持续判断自己应该保持安静、打断对方，还是开口说话。这让对话感觉更自然，也减少了无意的打断。

在底层，这些系统将新一代语音模型架构与针对低延迟优化的服务系统结合在一起。为了从头到尾理解它的运作方式，我们拜访了 GPT Voice 团队的工程师 Zahan Malkani 和 Justin Uberti（WebRTC 的创造者）。感谢他们两位与我们分享这些细节。

在本文中，你将了解到：

语音系统的三代演进

语音系统的输入是用户的音频，输出则应以音频形式将回复播放给用户。虽然输入和输出始终是音频，但中间发生什么取决于我们如何设计系统。语音系统已经经历了三代架构：

让我们逐一深入了解。

1. 级联式设计

级联式设计将三个独立的模型串联起来。自动语音识别（ASR）模型将用户的语音转写为文本，LLM 随后生成文本回复，文本转语音（TTS）模型最终将回复朗读给用户。

该设计中的每个模型都专注于自己擅长的任务。ASR 擅长将语音转换为文本，它不具备 LLM 所拥有的知识，因此只专注于转换。LLM 则依靠自身能力理解用户的查询并据此作出回应。一旦 LLM 生成回复文本，TTS 模型只需将其合成为听起来自然的语音。

级联式设计在实践中可行，但存在两个主要问题。首先是信息丢失。LLM 只能看到转写文本，因此语调、情感等声音信息对模型来说是不可用的。

其次，系统复杂且缓慢。由于三个阶段串行运行，它们的延迟会累加。用户必须等到三个阶段全部完成。此外，运行三个模型意味着要构建、服务和扩展三套独立系统，这在实践中非常复杂。

由于这些局限，第二代语音系统应运而生：基于轮次的语音到语音模型。

2. 回合制、语音到语音

第二代引入了端到端语音模型，即一个经过训练、能够以音频为输入并直接生成音频输出的单一模型。

这一设计解决了级联系统的一个关键局限：由于直接处理音频，模型得以将声音信息纳入考量。

尽管这是一项不错的改进，交互本身仍然是回合制的。一个被称为回合检测器的小模型仍然负责判断用户何时说完，只有在这之后，主语音模型才开始工作。回合检测器在这里并非新事物。级联设计中的停顿检测步骤就是同一个组件。两代系统都依赖它，而这种回合制设计正是不自然感的根源。

检测器的工作颇具挑战性。如果检测过早，它会在用户思路中途将其打断。如果判断过晚，用户就会经历尴尬的延迟。打断也面临同样的挑战。当用户开始盖过语音系统说话时，需要一个单独的机制来停止音频并清空缓冲区。如果打断检测过于敏感，背景噪音就可能触发误打断。如果检测过于保守，打断耗时过长、感觉迟钝，而像“是”和“不”这样的简短插话则可能被完全漏掉。Justin 指出，正是这套机制导致早期语音系统让人感觉不自然。

这些模型的更新成本也很高。当出现一个能力更强的新预训练 LLM 时，就需要在该检查点之上重新进行一次完整的语音到语音训练。因此，语音模型总是落后于最新的前沿模型。

第三代语音模型——全双工架构——解决了轮次转换问题。

3. 全双工架构

全双工模型的设计目标是能够同时听和说。模型持续生成音频 token。当它应当保持沉默时，就简单地生成静音 token。同样，它持续处理输入的音频 token。当用户沉默时，那些也只是静音 token。这种设计彻底移除了轮次检测器。

为了更好地理解，我们以开源全双工模型 Moshi [x] 作为参考。Moshi 将音频转换为离散 token，类似于文本被转换为 token 供 LLM 使用的方式。模型将这些 token 作为输入进行处理，并以固定时钟发出新的 token，大约每 80 毫秒一帧。静音只是另一种 token，解码后即为静音。因此，模型只需在训练中学习这种行为，并从训练数据中隐式理解何时该听、何时该说。

全双工解决了打断问题和对话中的不自然感，但它带来了两个新的工程挑战。第一，由于模型始终在运行并预测下一个 token，服务成本高昂。第二，模型需要在毫秒级内响应，因此其容量不能太大。

OpenAI 于 2026 年 7 月推出了 GPT-Live-1，这是一个全双工语音模型系列。它围绕上述挑战进行设计。语音模型保持小巧快速，以便能在毫秒级内响应。它还依赖委托机制在对话持续进行的同时执行昂贵的推理。

GPT-Live 系统的工作原理

本节将说明 OpenAI 如何围绕全双工架构构建语音助手。我们将介绍使其能够在生产环境中大规模落地的思路与技术。

将“说话”与“思考”分离

通常，前沿 LLM 可能需要先推理、搜索网页，然后再作出回应，这可能会耗费数秒。在语音系统中，这就意味着几秒钟的沉默，显然并不理想。

为了解决这个问题，OpenAI 将“说话”与“思考”分离。一个语音模型负责与用户对话。另一个能力更强的模型则为更复杂的查询执行必要的推理和工具调用。服务系统也围绕这一思路构建。它在需要时将请求委派给能力更强的模型，同时继续与用户对话。

如下图所示，像“昨晚的比赛谁赢了”这样的问题无法由语音模型直接利用其内部权重回答，因此语音模型会将其委派给 GPT-5.5。它在搜索进行的同时保持对话继续，并在答案可用后为用户读出答案。

这种设计显著降低了速度与质量之间的权衡。当前沿模型查找信息时，语音模型仍可继续聊天。此前，如果你想要更聪明的回答，就需要接入更多系统，响应时间也会更长。如果你想要快速响应，就会使用更小的模型，而答案质量也会变差。用一个模型负责说话、另一个模型负责思考，语音系统便能两者兼得。

这种设计的另一个好处是模块化。当有新的前沿模型可用时，将语音助手切换到该模型所需的工程工作更少。

两条服务路径

同时服务两个模型并非易事。音频帧应当每隔几毫秒就发送一次，但一次委派却可能耗时数秒。因此，我们无法让两者共用一个进程。GPT-Live 将流量分流。实时路径只承载音频，它以尽可能快的速度在客户端与语音模型之间传输音频。异步路径则处理音频之外的任何事务，这些事务可以耗时更长。这样一来，一次缓慢的工具调用可能会拖慢异步路径，但不会拖慢实时路径。

如何让实时路径保持快速？

实时路径的核心要求是：音频必须在用户与模型之间按固定时钟传输。模型实时地将帧作为输入处理，并作为输出产生。因此，一旦出现延迟，用户就会听到。正如 Zahan 所解释的，每当某个瓶颈使系统落后，它就会开始产生可听见的杂音。

为满足这一要求，需要大量优化。例如，连接必须快速建立，模型必须跟得上传入的流，帧必须按时送达。以下是 OpenAI 为保持实时路径快速而采用的一些工程技术：

1. 一次往返即启动会话

当用户点击语音按钮时，客户端必须先建立连接，音频才能开始流动。这需要若干次网络往返，具体取决于底层协议。GPT-Live 使用 WebRTC，大多数视频通话应用都采用它。但一个标准的 WebRTC 会话在能够发送哪怕一帧音频之前，需要六个步骤才能建立。在单次往返耗时 60 毫秒的移动网络上，仅建立连接就可能花掉超过三分之一秒。

为了改进这一点，OpenAI 构建了 WARP（WebRTC Abridged Roundtrip Protocol，WebRTC 精简往返协议）。它基于这样一个思路：不再让各个步骤依次进行，而是让它们同时发生。这样就把网络往返次数缩减到仅一次。

2. 实现低成本的持续推理

要理解全双工系统为何服务成本高昂，我们不妨将其与聊天机器人做个对比。在聊天机器人中，请求到达后，模型生成 token。当响应完成时，模型便处于空闲状态。而全双工模型则没有空闲时间。音频持续流入模型，模型持续产出帧。即使用户话说到一半，或停下来思考，这一过程也不会停止。

对每个用户每秒多次持续采样模型，成本很高。OpenAI 通过将每个对话常驻在模型上来降低这一成本。这样，就不必在每次请求时重新读取整个对话，而是让每个会话始终连接到那个将对话保存在 GPU 内存中的模型实例。当新的音频帧到达时，模型只处理这一帧。此外，还可以采用批处理和推测解码等常见技术来保持系统的高速运行。

3. 在模型实例之间交接进行中的对话

将对话常驻在一个模型实例上会带来一个新问题。模型实例可能会变得不可用。它们需要根据需求启停，或接收更新。它们偶尔也可能发生故障。在常规系统中，这很容易处理，因为我们可以把请求发送到另一个可用的实例。而在 GPT-Live 中，会话与那个将对话保存在 GPU 内存中的实例绑定在一起。

OpenAI 创建了一套托管式交接机制。系统会预先准备好一个替换实例，并提前加载完整对话。一旦新实例可供使用，就会发生切换，因此对话可以毫无中断地继续下去。当需要执行其他操作时，这套机制同样有用。例如，当上下文需要压缩时，缩短后的对话会在一个替换实例上准备，而原始实例继续对话。随后切换以同样的方式发生。

异步路径

异步路径处理所有非音频的事务，比如委派和工具调用。这些任务本质上规模较大，完成起来可能更耗时。尽管如此，结果返回的速度仍应足够快，让两个模型感觉像同一个系统。回到我们之前的示例会话。用户问昨晚的比赛谁赢了，语音模型随即启动一次委派。语音模型可以通过一些方式来争取一点时间，比如先确认一下问题，或者出声思考片刻。但当答案耗时过长时，它就无能为力了。因此，委派循环中的一切环节，包括提示处理和路由，都必须快速完成。

要削减延迟，我们首先应当弄清楚是什么导致了延迟。大部分时间花在读取请求上。接收到请求的模型必须先处理整个提示（预填充），然后才能生成 token。在一段很长的对话中，仅这一步就可能耗费可察觉的一小段时间。OpenAI 的解决办法是在需要之前就完成这次读取。当用户开始一段对话时，服务器会与前沿模型创建一个推理会话，并发送到目前为止的对话。等到第一次委派发生时，模型已经拥有了生成 token 所需的一切。

如何评估全双工语音系统？

基于轮次的语音模型可以一次评估一轮：发送一个请求，然后对响应打分。但在全双工架构中，根本不存在轮次。只有一条连续的音频流。这使得评估方式有所不同。

在全双工系统中，我们不再对轮次打分，而是可以评估三个部分：

1. 对话行为

第一个问题是模型在对话中是否表现良好。这主要归结为时机把握。模型必须持续判断自己应该保持沉默、打断对方，还是开口说话。当用户在模型说话时开口，模型必须判断这是真正的打断还是仅仅是背景噪音。这两个决策分别被称为端点检测（endpointing）和打断检测（barge-in detection）。

为了评估这些行为，每个决策都像预测一样被打分。模型是否正确检测到了轮次的结束？它是否识别出了真正的打断？评估的心智模型是一样的。我们收集评估数据（自然对话），按照想要测量的维度进行标注，在其上运行推理，然后进行评估。

2. 流的健康状况

评估的第二个维度是流本身是否健康。在大多数服务系统中，这通过像 p95 这样的百分位目标来回答。如果 p95 延迟表现良好，那么 20 个请求中有 19 个感觉很快。只要异常缓慢的情况保持在很低的水平，这种做法就没有问题。普通用户只是偶尔发送一个请求，所以一次慢的很快就会被遗忘。

但在全双工架构中，p95 并不可靠。鉴于模型持续运行，每 20 次推理就会出现一次 p95 事件，这意味着每分钟会发生数次。即便是 p99 事件也会频繁出现。因此，系统必须围绕 p999 来设计。在实践中，这意味着要针对快速恢复进行设计，因为每个会话中必然会出现一些慢帧。

3. 在真实生产流量上测试系统

最后一层评估检验系统在真实流量下能否可靠运行。安全地验证这一点的方法叫做静默上线。用户照常与旧系统对话，而一小部分语音会话被路由到新系统。这种静默上线能发现通常难以察觉的问题。例如，它能发现意料之外的瓶颈。在 GPT-Live 的静默上线中，团队发现某个 CPU 侧服务比 GPU 更早耗尽容量。这类问题通常很难通过普通测试发现。

其他团队能从 GPT-Live 学到什么

OpenAI 的 GPT-Live 给出的宏观启示是：为实时服务而构建，与传统服务不同，也更具挑战性。例如，在语音系统中，用户听到的是最差的那一帧，因此平均延迟不足以作为监控指标。尾部延迟更为重要，值得投入更多工程精力。此外，这类系统中的容量规划也截然不同。当用户正在进行对话时，会话在整个过程中都被占用。因此，容量应以并发会话数来衡量，而不是按请求数。

另一个启示是，复杂性应当在模型内部处理。例如，轮次检测过去是一个独立的小组件，也是不自然感的主要来源。将这一决策移入模型行为——即拥有最强推理能力的部分——使对话更自然，系统也更简单。总的来说，凡是留在模型之外的部分都应保持小巧，并专注于实时工作。这能确保系统保持简单且易于维护。

下一步是什么

OpenAI 相信，下一代人机交互将由语音驱动计算机。在 ChatGPT 桌面应用中，它会截取屏幕截图来了解你正在做什么，启动长时间运行的任务，并回报进展。在此过程中，你可以询问状态、回答问题，并在任务进行中改变它的方向。Zahan 说，这感觉就像科幻小说。

有些问题仍然悬而未决。Zahan 表示，语音模型在将任务委派给其他模型的同时，还要保持与用户的实时对话流畅进行，这仍然具有挑战性。委派路径或许可以容忍延迟，但实时对话更为敏感。一个通用协议将意味着“你大脑的一部分反应变慢”。Justin 说，语音 AI 当时还处在它的 GPT-3 时代。有了 GPT-Live-1，他认为它达到了 GPT-4 的水平，但前面还有许多有趣的问题。