如果你用过语音助手，很可能遇到过意外打断。你正在和系统说话，只是稍微停顿一下，想找一个准确的词，它就开始说话了。于是，你又得打断它，才能继续说下去。这是一种常见的烦恼，因为大多数语音模型要么听，要么说，却不能同时做这两件事。
OpenAI 的 GPT-Live-1 等新一代语音模型改变了这种情况，它们可以同时听和说。模型会不断判断自己应该保持安静、插话，还是开始说话。这让对话听起来更加自然，也减少了无意间的打断。
在底层，这类系统把新一代语音模型架构与针对低延迟优化的服务系统结合在一起。为了从头到尾了解它的工作原理，我们采访了 GPT Voice 团队的两位工程师 Zahan Malkani 和 Justin Uberti（WebRTC 的创造者）。感谢他们与我们分享这些细节。
本文将介绍：
- 三代语音系统，包括级联式流水线、轮次式端到端模型和全双工模型
- 把思考交给另一个模型：GPT-Live 背后的核心思想
- 服务系统背后的工程实现，包括实时路径和异步路径
- 全双工语音系统的评估有何不同
- 构建实时系统的工程经验，以及语音技术的下一步
三代语音系统
语音系统的输入是用户的音频，输出则应该是以音频形式播放给用户的回答。输入和输出始终都是音频，但中间发生什么，取决于我们如何设计系统。语音系统的架构经历了三代演进：
- 级联式设计
- 轮次式端到端架构
- 全双工架构
下面逐一详细了解。
1. 级联式设计
级联式设计把三个独立模型串联起来。自动语音识别（automatic speech recognition，ASR）模型先把用户的语音转写成文本，接着由 LLM 生成文字回答，最后由文本转语音（text-to-speech，TTS）模型把回答读给用户听。
这种设计中的每个模型都专注于自己擅长的任务。ASR 擅长把语音转换成文本，却不具备 LLM 所拥有的知识，因此它只负责转换。随后，LLM 凭借自身能力理解用户的问题，并作出相应回答。LLM 生成回答文本后，TTS 模型只需把它合成为听起来自然的语音。
级联式设计在实际应用中行得通，但有两个主要问题。首先是信息损失。LLM 只能看到转写文本，因此无法获得语气和情绪等声音信息。
其次，系统既复杂又缓慢。三个阶段串行运行，延迟会叠加起来。用户必须等到三个阶段全部完成。而且，运行三个模型意味着要分别构建、提供服务并扩展三套系统，在实践中十分复杂。
由于这些限制，第二代语音系统应运而生：轮次式语音到语音模型。
2. 轮次式语音到语音架构
第二代系统引入了端到端语音模型：用一个模型直接接收音频输入，并直接生成音频输出。
这种设计解决了级联系统的一个关键限制：模型直接处理音频，因此可以把声音信息考虑在内。
这是一个很好的改进，但交互本身仍然按轮次进行。一个叫作话轮检测器的小模型仍要判断用户何时说完，只有在那之后，主语音模型才开始工作。话轮检测器在这里并不是新组件，级联式设计中的停顿检测步骤就是同一个组件。两代系统都依赖它，而这种轮次式设计正是不自然感的来源。
检测器承担着一项困难的工作。如果检测得太早，它会在用户还没说完一个想法时打断用户；如果判断得太晚，用户就会经历尴尬的延迟。处理打断也面临同样的难题。当用户在语音系统说话时插话，需要由一套独立机制停止音频并清空缓冲区。如果打断检测过于敏感，背景噪声就可能触发错误打断；如果检测过于保守，打断生效会太慢，显得迟钝，“yes”和“no”这样的简短插话甚至可能被完全漏掉。Justin 认为，正是这套机制让早期语音系统显得不自然。
更新这类模型的成本也很高。每当出现能力更强的新预训练 LLM，都需要基于该 checkpoint 重新完成一次完整的语音到语音训练。因此，语音模型总是落后于最新的前沿模型。
第三代语音模型采用全双工架构，解决了轮流说话的问题。
3. 全双工架构
全双工模型的设计目标是同时听和说。模型会持续生成音频 token；需要保持安静时，它只需生成静音 token。与此同时，它也会持续处理输入的音频 token；用户没有说话时，输入的也只是静音 token。这种设计彻底移除了话轮检测器。
为了更好地理解，我们以开放的全双工模型 Moshi [x] 为例。Moshi 会把音频转换成离散 token，就像 LLM 把文本转换成 token 一样。模型把这些 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 创建了一套受管的切换机制。系统会准备一个替代实例，并提前加载完整对话。新实例可以使用后才会执行切换，因此对话可以不受打断地继续进行。这套机制在需要完成其他操作时也很有用。例如，需要压缩上下文时，系统会在替代实例上准备好缩短后的对话，同时让原实例继续说话，随后再以同样的方式完成切换。
异步路径
异步路径处理音频以外的一切，例如委派和工具调用。这类任务本身规模较大，可能需要更长时间才能完成。不过，结果仍要足够快地返回，才能让两个模型像一个系统。回到前面的会话示例：用户询问昨晚的比赛谁赢了，语音模型随即发起委派。语音模型可以确认一下问题，或者短暂地边想边说，为自己争取一点时间；但如果答案耗时太久，它也无能为力。因此，委派循环中的一切，包括 prompt 处理和路由，都必须迅速完成。
要缩短延迟，首先应该了解延迟来自哪里。大部分时间花在读取请求上。模型收到请求后，必须先处理完整 prompt（prefill），才能开始生成 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 阶段，但前方仍有许多有趣的问题。