Speech-to-Speech · Continuous Interaction

全双工语音模型

用户停顿半秒,助手不该抢答;用户中途改口,助手也不该把旧答案说完。要做到这些,模型需要学习一场连续对话,而不只是把语音转换成文字再读出来。

同时听说全双工的关键不是更快的 TTS,而是模型在同一时间轴上持续决定何时听、说、停、附和或接受打断。
问题定义MoshiPersonaPlexGPT-Live模型选择部署边界资料

一、传统流水线没有错,但它把对话切成了批处理

传统语音助手依次运行语音识别、文本模型和语音合成。每个模块都容易替换、评测和调试,这仍是准确客服、可审计流程和低成本系统的合理选择。

问题出现在交互边界:系统通常必须先判断用户是否说完,才能把完整转写交给语言模型。短暂停顿可能被误判为轮次结束;助手开始播放后,用户的新语音又常被外围 VAD 当成一个“取消播放”信号,而不是与旧输出重叠的新语义。

轮次式流水线与全双工时间线的区别 上半部分展示用户说完后依次经过 ASR、LLM 和 TTS;下半部分展示用户音频与助手音频在同一时间线上同时推进。 轮次式:先听完,再回答 用户语音等待轮次结束 ASR转写 LLM生成文字 TTS合成声音 播放可被取消 全双工:两条音频轨道持续推进 用户“我想订明天……”停顿“等一下,改成后天” 助手持续监听“嗯,我在听”停止旧回答按“后天”重新回答 时间
概念图:全双工不只是降低 ASR、LLM、TTS 的串行延迟,而是取消“必须先划分完整轮次”这一交互假设。

二、全双工的精确定义:模型在输出时仍持续理解输入

在语音模型语境中,全双工是指模型持续接收用户音频,同时持续生成助手音频,并在同一上下文中学习沉默、轮换、重叠、附和和打断。它不等于“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 条来自麦克风,模型采样助手文本和助手音频;双方不需要争夺同一个“当前说话人”位置。

Moshi 的两级多流生成架构 用户语音由 Mimi 编码为八条音频流,与助手文本及助手音频流一起进入 Temporal Transformer;Depth Transformer 在每个时间片内生成文本、语义和声学 Token,最后由 Mimi 解码。 用户波形24 kHz Mimi Encoder12.5 Hz8 个码本 Temporal Transformer每 80 ms 前进一步1 条助手文本8 条用户音频8 条助手音频 Depth Transformer当前帧内逐层补齐 Token Mimi Decoder助手波形 两级自回归的分工 横向:跨时间理解对话大模型每帧只运行一次 纵向:帧内生成音频细节文字 → 语义 → 声学码本 理论算法延迟:80 ms Mimi 帧 + 80 ms acoustic delay = 160 ms;论文报告实际约 200 ms。
概念图,依据 Moshi 论文 §3.3–3.4。大型 Temporal Transformer 不必为 17 条流各跑一次,这是实时性的关键。

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 决定何时启动大模型。它可以多次每秒决定继续听、开始说、暂停、打断或调用工具。

GPT-Live 的实时语音路径与异步委派路径 用户音频持续进入 GPT-Live-1,模型持续生成语音;复杂任务通过独立异步路径交给前沿推理模型和工具,结果再返回实时语音层。 持续用户音频语气、节奏、内容 GPT-Live-1 / mini实时交互层听 · 说 · 停 · 附和打断 · 翻译 · 调工具保持媒体循环不中断 持续助手语音自然、可被打断 异步前沿模型与工具发布配置:GPT-5.5 Instant / Thinking搜索 · 推理 · Agent 工作 结果返回后注入实时对话
概念图,依据 OpenAI 公开的系统边界,不代表未披露的神经网络内部结构。实时媒体路径保持低延迟,搜索、推理和工具走独立异步路径。

已经确认的能力

  • 真正同时听说,处理停顿、插话、快速轮换和 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-1GPT-Live-1 mini 是 ChatGPT Live 语音体验的全双工模型;开发者目录当前主要列出 gpt-realtime-2.1 作为实时语音 Agent API;gpt-live-transcribe 只负责低延迟流式转写,不负责语音对话。

六、Moshi 之后没有统一冠军,只有不同优化方向

截至 2026 年 8 月,开放与闭源系统已经沿多条路线演进。下面的“优势”指各项目公开设计或作者报告,不是同一硬件、同一数据集上的总排行榜。

模型交互类型相对 Moshi 的重点适用场景主要边界
PersonaPlex-7B原生全双工角色提示、零样本声音条件英语角色助手英语为主,仍受 Helium 7B 底座限制
VoiceChat-11B端到端全双工更新的语言骨干、实时工具调用本地语音 Agent2026-08 新模型,独立复现仍少
Lychee-FD原生多流全双工拆分语义、声学与控制分支语义保持与研究部署较重,优势来自作者评测
MiniCPM-o 4.5全双工 omni streaming中文、视觉、主动提醒、Apache-2.0本地多模态助手官方列出误读和中英混杂等限制
BayLing-Duplex单 AR LLM 全双工不用外部 VAD 或 turn controller中文全双工研究生态和真实通话验证有限
GPT-Live闭源原生全双工异步前沿推理、搜索和 AgentChatGPT 连续语音交互无权重,底层结构未披露
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 推理尖峰也会把几十毫秒的模型优势变成明显卡顿。

AEC消除扬声器回声,避免模型被自己的输出打断。
RTF < 1持续生成速度必须快于音频播放速度,并留出抖动余量。
语义恢复停止旧输出只是第一步,模型还要理解插话并接上新意图。

评估时至少应覆盖四类真实录音:正常轮换、用户短暂停顿、助手中途被打断、双方自然重叠。记录首声延迟、停止发声延迟、误打断率、恢复后的语义正确性,以及十分钟以上的角色与声音漂移。

按需求选择

  • 研究自然重叠和声音/角色条件:优先 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 则展示了实时交互模型与异步前沿推理协作的产品路线。哪条路线更好,最终取决于语言、工具、部署、审计和通话环境。

评论加载中...