OpenAI的GPT-Live-1用全双工语音模型和双路径服务解决抢话问题
ByteByteGo与GPT Voice团队工程师对谈，梳理全双工语音的三代架构、实时推理工程，以及p95指标为何在连续流场景下失效。
AI解读：语音助手抢话的根源在于传统模型要么听要么说，中间靠一个“轮次探测器”判断用户说完了没有。判早了打断用户，判晚了显得迟钝，背景噪音一大还容易误触发。GPT-Live-1作为全双工模型，把静音也当成一种输出token，模型持续产帧，从而把这个探测器整个去掉了。
全双工带来的直接代价是模型永远不空闲：用户闭嘴思考时它照样在采样。OpenAI的应对是把对话状态常驻GPU显存，新到一帧只处理一帧，不再重读历史；同时把“说话”和“思考”拆开，语音模型负责聊天，复杂查询交给前沿模型异步查完再念出来。
服务端因此拆成live和async两条路径，音频走live好保证按固定时钟收发，工具调用这类慢活走async，彼此不互相堵。为了压低建连延迟，OpenAI自研了WARP协议，把标准WebRTC的六次往返压到一次。这些是产品可用的前提，而不是锦上添花。
评测方式也得跟着改。全双工系统没有“轮次”可打分，改为看端点检测和抢话识别这类时序判断，以及音频流本身的健康度。p95在这种连续推理下不再够用——模型每秒采很多次，p95每 20 次推理就出现一次，意味着每分钟都会卡好几回，工程目标要往p999走。
对普通用户来说，最直接的收益是对话少被打断、插话不用等。但原文只描述了架构和工程手段，没有公开端到端延迟、打断准确率等实测数字，所以“更自然”目前是设计目标而非可核验结论。
用语音助手时最常见的尴尬，是短暂停顿想措辞，助手却以为你说完了，抢着开口；你只好打断它，它再停下。ByteByteGo在 2025 年发布的一篇技术解析中称，这个问题的根源在于多数语音模型要么只听、要么只说，不能同时进行。
文章基于对OpenAI GPT Voice团队工程师Zahan Malkani和Justin Uberti（WebRTC的创造者）的对谈，梳理了三代语音系统架构，以及GPT-Live-1这类全双工模型的工程实现。据该文，OpenAI于 2026 年 7 月发布GPT-Live-1，它是一个全双工语音模型系列。
全双工模型持续产出音频token，该保持安静时就产出静音token，同时持续处理输入音频token，用户不说话时输入也是静音token。这样一来，轮次探测器被完全移除。
代价是模型不再有闲置时间。聊天机器人是收到请求才产出token，回复完成就空闲；全双工模型则一直运行，音频不断流入、帧不断产出，即使用户说到一半或在思考停顿也一样。
以下事实均来自ByteByteGo的这篇解析，其中引用的工程师说法已注明归因。
三代语音架构：从串联三模型到端到端再到全双工
第一代是级联设计，串联三个独立模型：自动语音识别（ASR）把用户语音转成文本，大语言模型生成文本回复，文本转语音（TTS）模型再把回复读出来。每个模型专注自己擅长的任务。
级联设计有两个主要问题。一是信息丢失：大语言模型只看得到转写文本，语调、情绪这类声音信息对它不可见。二是又复杂又慢：三个阶段串行，延迟累加，用户要等三段全部完成；同时运行三个模型也意味着要搭建、服务和扩展三套系统。
第二代是轮次式的端到端语音模型，单个模型直接吃音频、出音频。这解决了级联的一个关键局限——模型能直接处理音频，从而利用声音信息。但交互本身仍是轮次的：一个叫轮次探测器的小模型负责判断用户是否说完，只有它判断完毕，主语音模型才开始工作。级联设计里的停顿检测用的也是同一个组件。
文章把这种轮次式设计称为“不自然”的来源。探测器的活很难干：判太早会打断用户思路，判太晚用户会觉得反应迟钝。打断也是同样的难题——用户开始抢话时，需要另一套机制停止音频并清空缓冲区；检测太敏感会被背景噪音误触发，太保守则打断反应迟缓，像“对”“不对”这种短促插话还可能完全漏掉。Justin Uberti认为，正是这套机制让早期的语音系统显得不自然。
此外，这类模型更新成本高。出现新的、更强的预训练大语言模型时，需要在检查点之上重新做一次完整的语音到语音训练，因此语音模型总是落后于最新的前沿模型。
GPT-Live-1的两条路径：说话归说话，思考归思考
全双工解决了打断和对话不自然的问题，但带来两个新的工程挑战：模型一直在运行并预测下一个token，服务成本高；模型必须在毫秒级内响应，因此容量不能太大。文章称GPT-Live-1正是围绕这两个挑战设计的——语音模型保持小而快，同时依靠委托机制在对话继续的同时完成昂贵的推理。
其核心思路是把“说话”和“思考”分开。语音模型负责与用户对话，另一个能力更强的模型负责复杂查询所需的推理和工具调用。当问题无法由语音模型凭内部权重直接回答时——比如“昨晚谁赢了比赛”——语音模型把它委托给GPT-5.5，同时继续与用户对话，答案就绪后再念出来。
文章称这一设计显著缓解了速度与质量之间的取舍。过去想要更聪明的回答就要接入更多系统、响应更慢；想要快速响应就用更小的模型，回答质量下降。一个模型说话、一个模型思考，语音系统可以两者兼得。另一个好处是模块化：新的前沿模型出现时，把语音助手切换到它所需的工程工作更少。
服务两个模型并不容易：音频帧每隔几毫秒就要发送，而一次委托可能耗时数秒，因此不能共用同一个进程。GPT-Live把流量拆开：live路径只走音频，在客户端和语音模型之间尽可能快地搬运音频；async路径处理音频以外的一切，耗时可以更长。这样一次慢的工具调用会拖慢async路径，但不会拖慢live路径。
live路径的核心要求是音频必须按固定时钟在用户和模型之间流动。模型实时处理输入帧、产出输出帧，所以一旦出现延迟，用户就会听到。Zahan Malkani称，只要某个瓶颈让系统跟不上，它就会开始产生可听见的瑕疵。
- 会话建立压缩到一次往返：GPT-Live基于WebRTC（多数视频通话应用使用），但标准WebRTC会话在发送第一个音频帧前需要六步建立；在单次往返 60 毫秒的移动网络上，仅建立就超过三分之一秒。OpenAI自研了WARP（WebRTC Abridged Roundtrip Protocol），让原本依次进行的步骤并发执行，把网络往返压缩到一次。
- 廉价连续推理：OpenAI把每个对话常驻在模型上，会话持续连接着在GPU显存中持有该对话的模型实例；新音频帧到达时只处理这一帧，而不是每次请求重读整段对话。此外还可采用批处理和投机解码等常规技术保持速度。
- 实例间热交接：会话绑定在GPU显存中持有对话的实例上，实例可能因负载启停、更新或故障而不可用。OpenAI构建了受管交接机制：提前准备好替换实例并载入完整对话，新实例就绪后再切换，对话不中断。上下文需要压缩时也用同样方式——在原实例继续说话的同时，在替换实例上准备缩短后的对话，然后切换。
- 委托链路提前预填充：委托和工具调用这类任务耗时长，但结果要足够快返回，才能让两个模型感觉像一个系统。延迟大头在读取请求——模型收到请求后要先处理整个提示词（prefill）才能产出token，长对话里这一步就要花掉可观的时间。OpenAI的做法是提前读：用户开始对话时，服务器就与前沿模型建立推理会话并发送已有的对话，等第一次委托真正发生时，模型已具备产出token所需的一切。
没有轮次可评分：全双工语音的评测与p95为何失效
轮次式语音模型可以一轮一轮地评测：发一个请求，给回复打分。全双工架构里没有轮次，只有一条连续的音频流，评测方式因此不同。文章提出可以从三部分评估：对话行为、流的健康度、在真实生产流量上的测试。
对话行为主要看时序。模型必须持续判断自己该保持安静、打断还是开口；当用户在其说话时开口，它还要判断这是真打断还是背景噪音。这两个判断分别叫作端点检测和抢话检测。评测时把每个判断当成一次预测来打分：模型是否正确检测到轮次结束？是否识别出真实打断？流程仍是收集评测数据（自然对话）、按要度量的维度标注、跑推理、再评估。
第二个维度是音频流本身是否健康。大多数服务系统用p95这类分位数目标来回答这个问题：p95延迟好，20 个请求里 19 个就感觉快。这在慢请求保持在极低水平时是成立的，因为普通用户偶尔才发一次请求，慢一次很快就被遗忘。
但在全双工架构下p95不可靠。模型持续运行，p95事件每 20 次推理就发生一次，相当于每分钟出现好几次，连p99事件也会规律出现。因此系统必须围绕p999来设计。实际上这意味着要设计成能快速恢复，因为每个会话里必然会出现一些慢帧。
最后一层评测检查系统在真实流量下是否可靠。安全做法叫静默上线：用户照常用旧系统，一小部分语音会话被路由到新系统。文章称这能抓到常规测试难以发现的问题，比如意料之外的瓶颈。在GPT-Live的静默上线中，团队发现一个CPU侧服务先于GPU耗尽容量。
文章给出的通用教训
文章总结，实时服务的构建方式与传统服务不同，也更难。在语音系统中，用户听到的是最差的那一帧，所以平均延迟不足以作为监控指标，长尾更值得投入工程资源。容量规划也不同：用户在进行对话时，会话会一直占用资源。
原文正文在此处被截断，没有给出完整的容量规划结论，也没有公开GPT-Live-1的端到端延迟、打断准确率等实测数字。因此上述内容属于该文描述的架构与工程手段，尚不构成可核验的效果结论。