一、传统流水线没有错,但它把对话切成了批处理
传统语音助手依次运行语音识别、文本模型和语音合成。每个模块都容易替换、评测和调试,这仍是准确客服、可审计流程和低成本系统的合理选择。
问题出现在交互边界:系统通常必须先判断用户是否说完,才能把完整转写交给语言模型。短暂停顿可能被误判为轮次结束;助手开始播放后,用户的新语音又常被外围 VAD 当成一个“取消播放”信号,而不是与旧输出重叠的新语义。
二、全双工的精确定义:模型在输出时仍持续理解输入
在语音模型语境中,全双工是指模型持续接收用户音频,同时持续生成助手音频,并在同一上下文中学习沉默、轮换、重叠、附和和打断。它不等于“WebSocket 可以双向传输”,也不等于“播放时检测到声音就停止播放器”。
| 系统类型 | 何时开始推理 | 用户插话时发生什么 | 能否自然建模重叠 |
|---|---|---|---|
| ASR → LLM → TTS | 通常在 VAD 判定轮次结束后 | 外部逻辑停止播放,再创建新轮次 | 通常不能 |
| 流式半双工 S2S | 输入轮次结束前后即可开始 | 取消当前 response | 有限 |
| 原生全双工 S2S | 持续推理 | 新输入直接改变模型的输出状态 | 可以作为训练分布的一部分 |
双向 WebRTC 或 WebSocket 为什么还不够?
传输层只能保证麦克风数据和播放数据可以同时通过网络。若服务端仍等 VAD 发出 end_of_speech 后才调用模型,那么交互语义仍是轮次式。模型级全双工要求推理状态本身持续吸收用户音频。
三、Moshi 如何把一场对话变成 17 轨时间线
Moshi 是理解原生全双工最清楚的开放基线。它先用 Mimi 神经音频 codec 把 24 kHz 波形压缩为每秒 12.5 帧,也就是每 80 ms 一组离散 Token。每组包含 8 个码本:第一层侧重语义,其余残差码本逐层补充音色、韵律和声学细节。
模型共同处理 17 条流:1 条助手对齐文本、8 条助手音频码本、8 条用户音频码本。线上推理时,用户侧 8 条来自麦克风,模型采样助手文本和助手音频;双方不需要争夺同一个“当前说话人”位置。
Inner Monologue 不是隐藏思维链
Moshi 先预测与助手语音对齐的文本 Token,再生成语义和声学 Token。论文称其为 Inner Monologue,但它更像语言脚手架:帮助模型继承文本 LLM 的知识与语言质量,而不是向用户隐藏的推理过程。Moshi 论文的消融实验将其列为影响语言质量的关键设计之一。
它表示没有三个彼此等待、通过完整文本交接的独立服务。文字 Token、音频 Token 和对话时序仍可在一个联合模型中共同训练。
四、PersonaPlex 没有重做 Moshi,而是补上角色与声音条件
PersonaPlex 沿用 Moshi 架构,在会话开始前加入 Hybrid System Prompt:文字片段规定角色、任务和业务信息,短语音片段规定目标音色。后续助手音频同时受两者影响,因此无需再外接声音克隆 TTS。
文字提示:你是银行客服,只依据给定政策回答。
语音提示:一段目标说话人的短音频
持续对话:用户音频流 → PersonaPlex → 目标角色、目标声音的语音流
NVIDIA 为公开 checkpoint 增加了 7,303 段、1,217 小时 Fisher English 真实对话,用来加强附和、情绪和自然节奏;另以合成问答与客服对话训练任务遵循。官方在 FullDuplexBench 报告平滑轮换延迟 170 ms、用户打断响应延迟 240 ms。数字来自 NVIDIA 的发布 checkpoint 评测,不等同于所有硬件和真实通话环境的端到端延迟。
nvidia/personaplex-7b-v1 的模型卡标记 English,真实对话数据来自 Fisher English,论文也没有提供中文理解、发音或全双工行为评测。偶尔能生成外语词,不构成正式语言支持。
五、GPT-Live 把“说话”和“深度思考”拆成快慢两条路径
OpenAI 明确将 GPT-Live 与上一代轮次式语音模型区分:GPT-Live 持续处理输入并生成输出,不再让独立 turn detector 决定何时启动大模型。它可以多次每秒决定继续听、开始说、暂停、打断或调用工具。
已经确认的能力
- 真正同时听说,处理停顿、插话、快速轮换和 backchannel。
- 用户可以要求模型等待、放慢语速或改变当前会话的语气和表达风格。
- 实时翻译、Web 搜索、记忆、文字和图片输入,以及天气、股票、体育等视觉卡片。
- Instant、Medium、High 三种推理强度;发布时分别委派给 GPT-5.5 Instant 或 GPT-5.5 Thinking。
- 在桌面 Work/Codex 场景中,可用语音启动、查询、打断和重定向后台 Agent 任务。
没有公开的模型细节
OpenAI 没有披露 GPT-Live 的参数量、音频 Tokenizer、码本数量、Transformer 层数、是否存在文本内心独白,或是否采用 Moshi 的对称双音轨。因此,最多只能确认它是原生全双工、状态化、持续推理的语音模型;不能把“行为相似”写成“架构相同”。
GPT-Live、GPT-Realtime-2.1 和 GPT-Live-Transcribe 是同一个模型吗?
不是。GPT-Live-1 与 GPT-Live-1 mini 是 ChatGPT Live 语音体验的全双工模型;开发者目录当前主要列出 gpt-realtime-2.1 作为实时语音 Agent API;gpt-live-transcribe 只负责低延迟流式转写,不负责语音对话。
六、Moshi 之后没有统一冠军,只有不同优化方向
截至 2026 年 8 月,开放与闭源系统已经沿多条路线演进。下面的“优势”指各项目公开设计或作者报告,不是同一硬件、同一数据集上的总排行榜。
| 模型 | 交互类型 | 相对 Moshi 的重点 | 适用场景 | 主要边界 |
|---|---|---|---|---|
| PersonaPlex-7B | 原生全双工 | 角色提示、零样本声音条件 | 英语角色助手 | 英语为主,仍受 Helium 7B 底座限制 |
| VoiceChat-11B | 端到端全双工 | 更新的语言骨干、实时工具调用 | 本地语音 Agent | 2026-08 新模型,独立复现仍少 |
| Lychee-FD | 原生多流全双工 | 拆分语义、声学与控制分支 | 语义保持与研究 | 部署较重,优势来自作者评测 |
| MiniCPM-o 4.5 | 全双工 omni streaming | 中文、视觉、主动提醒、Apache-2.0 | 本地多模态助手 | 官方列出误读和中英混杂等限制 |
| BayLing-Duplex | 单 AR LLM 全双工 | 不用外部 VAD 或 turn controller | 中文全双工研究 | 生态和真实通话验证有限 |
| GPT-Live | 闭源原生全双工 | 异步前沿推理、搜索和 Agent | ChatGPT 连续语音交互 | 无权重,底层结构未披露 |
| Gemini 3.1 Flash Live | 实时原生音频 | 音视频、Google 工具生态 | 商业多模态 Agent | 公开接口仍包含 VAD/轮次语义 |
| Qwen3-Omni | 流式端到端 S2S | 开放、多语言、音视频理解 | 多语言多模态问答 | 官方未声明 Moshi 式原生全双工 |
Moshi 的 160 ms 是 codec 帧加 acoustic delay;PersonaPlex 的 170/240 ms 来自特定 benchmark;VoiceChat 的约 450 ms 是官方 turn-taking 指标。它们可能分别测算法延迟、停止响应、首音频包或用户听到首声,分母并不相同。
七、模型全双工不等于产品自动获得自然通话
模型只是实时系统的一层。扬声器播放的助手声音会重新进入麦克风;若没有声学回声消除,模型可能把自己当成用户。网络抖动、播放缓冲和 GPU 推理尖峰也会把几十毫秒的模型优势变成明显卡顿。
评估时至少应覆盖四类真实录音:正常轮换、用户短暂停顿、助手中途被打断、双方自然重叠。记录首声延迟、停止发声延迟、误打断率、恢复后的语义正确性,以及十分钟以上的角色与声音漂移。
按需求选择
- 研究自然重叠和声音/角色条件:优先 PersonaPlex。
- 本地语音 Agent 与实时工具调用:关注 VoiceChat-11B。
- 中文、视觉与宽松许可:关注 MiniCPM-o 4.5。
- 全双工下的语义保持:关注 Lychee-FD 或 BayLing-Duplex。
- 商业搜索、推理和 Agent:GPT-Live 或当前可用的 Realtime API。
八、哪些结论还不能从演示和 benchmark 推出来
“端到端”是否必然比级联更准确?
不必然。端到端模型减少模态交接和轮次等待,也能保留语气与非语言线索;但专用 ASR、强文本 LLM 和高质量 TTS 可以分别优化,并更容易审计、缓存和替换。高风险客服或严格脚本场景仍可能更适合级联或混合系统。
“能被打断”是否证明模型是原生全双工?
不能。客户端检测到人声后取消播放也能制造相似演示。更强的证据是:模型在输出期间持续接收语音、理解重叠内容,并在没有外围 turn controller 的情况下恢复语义。
GPT-Live 是否已经证明采用更好的底层语音架构?
它证明了更好的产品行为和系统拆分,但 OpenAI 没有公开神经网络结构。合理结论是“持续交互路径与异步深度工作被解耦”,而不是猜测它用了多少码本、多少层或某个开源模型的结构。
开放模型能否直接复制商业体验?
权重只是起点。商业体验还包含回声消除、媒体传输、状态恢复、安全控制、工具调度和服务容量。开放模型更可检查和定制,闭源产品通常拥有更完整的系统工程;两者比较必须明确边界。
全双工把语音助手从“轮次请求”改造成“连续互动”。Moshi 给出了可检查的多流实现,PersonaPlex证明角色与声音条件可以加入该框架,GPT-Live 则展示了实时交互模型与异步前沿推理协作的产品路线。哪条路线更好,最终取决于语言、工具、部署、审计和通话环境。
参考资料
- Moshi: a speech-text foundation model for real-time dialogue,Kyutai,2024。
- Moshi 官方代码与架构说明。
- NVIDIA PersonaPlex 官方项目页,2026。
- PersonaPlex: Voice and Role Control for Full Duplex Conversational Speech Models。
- PersonaPlex-7B v1 官方模型卡。
- Introducing GPT-Live,OpenAI,2026。
- How we built a realtime system for responsive voice AI in six months,OpenAI,2026。
- GPT-Live System Card。
- GPT-Realtime-2.1 官方模型页。
- NVIDIA NemotronLabs VoiceChat-11B 官方模型卡。
- Lychee-FD 官方项目页与 ACL 2026 论文。
- MiniCPM-o 官方仓库。
- BayLing-Duplex 官方代码与模型说明。
- Qwen3-Omni 官方仓库。
评论加载中...