最近半年，技术媒体、各家发布会的主角，基本都是大模型和视觉模型。
文本能写代码，图像能看懂图表，模型之间的差距越来越小。
但有一条线也在往前走，只是没什么人聊：语音模型。
这条线的变化其实很剧烈。
最早是 ASR + LLM + TTS 三段拼起来；后来收进一个端到端模型；再到现在，出现了能边听边说的全双工模型。
今年 7 月，OpenAI 放出 GPT-Live，等于给这条线按了一下快进键。
它顺带把一个词打爆了：全双工。
从那以后，产品页上"全双工"“全模态”"端到端"开始混着用。
前阵子为了接几种方案，我把各家的协议文档翻了一遍，发现：很多页面写的架构，和它实际跑的不是一回事。
所以，今天分享，先聊聊 GPT-Live 到底做了什么。
01 GPT-Live 是什么
GPT-Live 是 7 月 8 日发布的，7 月 31 日又补了一次更新。
两个版本：
GPT-Live-1：Go / Plus / Pro 订阅用户的默认语音模型
GPT-Live-1 mini：Free 用户的默认语音模型
官方给的定位很直白——它是全双工语音模型，用来驱动 ChatGPT Voice，每周超过 1.5 亿人在用。
OpenAI 在工程上做了不少优化：
媒体前端和推理逻辑从 Python asyncio重写为 Go；
用 WebRTC 做传输层，管理丢包、时钟漂移、网络变化。
开发了自己的 WARP 协议（WebRTC Abridged Roundtrip Protocol），将媒体和数据启动从 6 次网络往返减少到 1 次。
除了工程上的创新，它做的三件事，大多数人只讨论了第一件。
1.1 第一件：真全双工
传统语音模型是：“你说完，它听；它说完，你听”。
GPT-Live 的架构是同时听和说：一边生成语音，一边继续处理你的输入，并且不断做决策：
继续听、开始说、暂停、被打断、去调工具、还是保持安静。
这类决策可以每秒做很多次。
落到体感上：
• 可以随时打断，可以停下来思考，可以要求它说慢一点
• 它会用 “mhmm”“yeah”“got it” 这类接话表示"我在听"，而不是突然沉默
• 你要求它安静听，它就真的安静听
• 交通噪音、旁边有人说话的环境里，它更能专注在你的声音上
• 支持实时翻译
1.2 第二件：前台聊天，后台干活
我认为这是真正值得抄的设计。
GPT-Live 不只负责说话。
当问题需要网页搜索、更复杂的推理、更 agentic 的任务执行时，它会把任务委托给后台的前沿模型——比如 GPT-5.5。
关键是：后台在干活的时候，前台继续跟你聊。
这解决的是实时语音的老矛盾——说话要快，思考要慢，一个模型不可能同时满足两头。
GPT-Live 给出的架构是：
交互层负责流畅，推理层负责深度，中间用委派连起来。
我认为，这才是"实时语音 Agent"该有的形状。
不管后台怎么接，前台模型都得自己决定"这事要交出去"、拿到结果、再决定什么时候念给你听。
会发起动作、能接收返回，这就是 Agent 能干活的底层机制：Function call。
1.3 第三件：说话中途能刹车
语音是没法"撤回"的，说完就说完了。
所以，GPT-Live 有可以在模型说话过程中介入的机制。
检测到潜在不安全输出时，引导它转向更安全的回答。
高风险情况下，直接结束语音对话。
安全评估也扩了：输入音频评估 + 合成音频评估，覆盖自残、精神病与躁狂、对 AI 的情感依赖、暴力、性内容。
青少年侧：模型被训练成年龄适当行为，家长可以控制青少年能否使用。
1.4 它没做的
几条限制值得记着：
•没有视频输入，也没有屏幕共享，官方说这两项在开发中；现在想用，得退回旧的 Standard / Advanced Voice Mode
• 语言支持 ChatGPT 里最常用的几种，其余语言有非母语口音或流利度不足
• 音色是两套账：ChatGPT 里只能用内置音色；API 侧开了 Custom voices，能传参考音频做定制，但要本人先录一段授权声明。
API 已经开放，前端语音层$0.05/分钟，后端模型和 Agent 那部分另算。
02 实时语音的三种架构
实时语音有三种架构，GPT-Live 换掉的正是这一层。
2.1 级联
你说话 → VAD 判"这句说完了"→ 语音转文字 → 大模型思考 → 文字转语音 → 你听到最早一批语音助手都是这个结构。
判"你说完了"靠的是VAD（语音活动检测）：静音超过一个阈值，就认定这句结束，把文字交给下一步。
好处是每一环都能换、能查、能插工具——文字层是透明的，你想在哪一步做什么都行。
代价是：转成文字那一刻，你的语气、迟疑、重音基本没了；延迟逐层叠加；对话感天然不连贯。
2.2 回合制端到端
你说话 → 【一个模型：听 + 判"说完了"+ 想 + 说】→ 你听到识别、理解、生成收进同一个模型，延迟明显下降，语气和情绪保住了。
但它仍然要判轮次：得先认定"用户说完了"，才进入生成。
这一步通常是 API 层一个可配置的组件。
OpenAI Realtime 的 turn_detection 就给了两档：
• server_vad：等静音。静音攒够 silence_duration_ms（默认 500 毫秒）就判定你说完了，这是语音对话的默认档
• semantic_vad：看语义。用一个分类器判断"这句话说完整了没"，你拖着尾音犹豫，它会等更久
这道判定就是那半秒尴尬的来源。你停顿思考，它以为你说完了；背景有人说话，它以为你在说。
属于这一档的有：
• 云端：OpenAI 的 gpt-realtime-2.1、Gemini Live 的 native audio 系列
• 开源： Qwen3-Omni 和 Step-Audio 2 mini。
2.3 全双工
你说话 ⇄ 【一个模型：一边听，一边决定说不说、说什么】⇄ 你听到没有"判你说完"这道闸门。输入流一直开着，模型在生成的同时继续处理输入。
属于这一档的：
• 云端：GPT-Live-1、Gemini Live、百炼 Qwen3.8 Omni Realtime；
• 开源：Moshi（纯音频）和 MiniCPM-o 4.5（带视频帧）。
顺带解释下术语：
• 单工只能一个方向；
• 半双工能双向但不能同时——对讲机就是，按下说话、松开听；
• 全双工能同时——打电话就是，随时可以插话。
2.4 一张表看区别
三种架构有啥区别：
所以，全双工贵啊，云上按分钟卖。
而，级联的 STT/TTS 可以批量池化，LLM 走连续批处理，并发能高出一个量级。
看懂架构，就能看清宣传页上那几个词的分工了：
•全模态：管的是能吃几种输入、能吐几种输出。
•端到端：管的是中间换不换手。识别、理解、生成三步由一个模型干完，所以链路短、语气保得住；但该等你说完，还是得等。
•全双工：管的是听和说能不能同时进行。模型一边生成语音一边处理你的输入，你一插话它就能收声。
03 于是"全双工"被用坏了
3.1 不是全双工，写成全双工
•“首包延迟低至几百毫秒，实时对话随时打断”—— 延迟降了不等于会同时听，多数仍是回合制。
•“支持视频输入，像真人视频通话”—— 各家都是摄像头采帧 + JPEG 上行，常见上限1 帧/秒。这是每秒拍一张照片，不是视频流。
•“支持语音打断”—— 多是 VAD 判轮次后掐掉。副作用：分不清是你在说还是电视在说。
•“全模态，文本音频图像视频都能吃”—— 这是模态清单，不承诺同时听说，也不承诺会调工具。
•“全新一代 Realtime / Live”—— 名字里带 Live 不构成架构证据。
判据只有一条：它说话的时候你插话，它能不能同时处理。
3.2 是全双工，被当成全能
开源里，原生做全双工的模型没几个，MiniCPM-o 算一个。
我们为了接它，把官方接入文档翻了一遍。
它全双工、吃音频和视频帧，体验确实像打电话。
但公开 Realtime 协议里没有定义结构化的 function-call 事件。
会不会调工具，门槛就在这儿，三件事得同时成立：
• 协议定义了 function-call 事件
• 模型能在对话中自主发出调用
• 结果注回后能自然续行
一个全模态 + 全双工的模型，就因为缺这一层，办不成事。
3.3 全双工的代价
边听边说当然是进步，但想做到，得先付四笔账：
• 会话变独占：并发难扩，云上按时长卖
• 训练目标从"答对"变成"何时说"：评测体系要重做
• 安全要能在说话中途介入：事后审核没用了
• 协议要重新设计：MiniCPM-o 调不了工具，缺的就是这一层
写在最后
GPT-Live 给我们最大的启示是：流畅归交互层，深度归推理层。
这个拆分，比"全双工"这个标签更有生命力。
下篇来聊：
能"边听边说"的语音模型，我拉表盘了 11 个：开源占 2 个。
全双工、工具调用、视频、并发、出域，一次盘点完。
