概述
全双工大模型(Full-Duplex LLM)正在重塑人机交互范式——从"对讲机式"的回合制对话迈向"电话式"的自然交流。从2023-2024年的级联管道时代(Whisper+GPT-4o+TTS),到2024年中末期的端到端语音模型兴起,再到全双工语音对话突破(Moshi、SALMONN-Omni、Freeze-Omni、DuplexMamba、DuplexCascade等模型百花齐放),最终演进至2025-2026年的全模态全双工(Stream-Omni、MiniCPM-o 4.5、GPT-Live、Seeduplex)。

全双工与半双工的区别首先体现在通信模式上。FireRedChat论文给出了三种交互模式的精确定义:
“在单工交互中,只有一方能说话;在半双工交互中,用户和代理必须轮流发言,等待对方说完才能说话(即回合制对话);在全双工交互中,双方可以同时说话,允许用户在代理说话时打断或插入”。
这一定义揭示了本质区别:半双工是串行处理(串行模式),全双工是并行处理(并行模式)。
| 对比维度 | 半双工AI助手 | 全双工大模型 | 本质差异 |
|---|---|---|---|
| 通信模式 | 串行:说完→处理→回复 | 并行:边听边说 | 架构范式差异 |
| 打断支持 | 不支持或需等待当前轮次结束 | 随时可打断(barge-in) | 交互自由度差异 |
| 话轮控制 | 依赖外部VAD/轮次检测器 | 模型自主决策(神经FSM/状态token) | 控制主体差异 |
| 信息保留 | ASR转文本后丢失副语言信息 | 直接处理语音/视频,保留丰富信息 | 信息完整性差异 |
| 响应间隙 | 2-5秒(需等待用户说完+处理) | 200-300ms(实时流式处理) | 延迟量级差异 |
| 附和反馈 | 需单独模块实现,不自然 | 原生支持(backchanneling) | 对话自然度差异 |
| 重叠说话 | 无法处理 | 支持自然重叠说话 | 对话动态性差异 |
| 延迟特征 | 突发式(处理完一轮才响应) | 连续流式(持续响应) | 延迟模式差异 |
上表从八个维度系统对比了半双工与全双工的本质区别。最核心的差异在于架构范式(串行vs并行)和控制主体(外部检测器vs模型自主决策)。OpenAI在GPT-Live中"直接从音频路径中剔除了轮次检测器",让全双工语音模型自身控制对话节奏,这标志着控制主体从外部模块向模型内部的根本转移。
技术演进
全双工大模型的技术演进,是一部从"串行接力"到"并行交响"的压缩史诗——仅用三年时间,便走完了从概念验证到规模化落地的完整旅程。本章系统梳理2023年至2026年的四阶段技术演进脉络,深度解析每个阶段的代表模型、核心创新和关键技术突破,揭示"局限→突破→新局限→新突破"的螺旋上升逻辑。
四阶段技术演进总览
全双工大模型的技术演进可划分为四个阶段,每个阶段的质变点由听说控制机制的根本性变革驱动。以下时间线呈现了从级联管道到全模态全双工的完整路径。
| 阶段 | 时间范围 | 范式特征 | 关键突破 | 代表模型 | 解决的前代局限 |
|---|---|---|---|---|---|
| 一 | 2023–2024中 | 级联管道(串行) | 首次实现LLM语音交互 | Whisper+GPT-4+TTS | — |
| 二 | 2024中–2024末 | 端到端语音(半双工) | 语音理解与生成统一建模 | GPT-4o语音模式 | 级联延迟与信息丢失 |
| 三 | 2024中–2024末 | 全双工语音突破 | 同时听说+自主话轮控制 | Moshi、SALMONN-Omni、Freeze-Omni、DuplexMamba、DuplexCascade | 回合制与打断不支持 |
| 四 | 2025中–2026 | 全模态全双工 | 看+听+说+主动行为 | Stream-Omni、MiniCPM-o 4.5、GPT-Live、Seeduplex、PersonaPlex | 单一模态与被动响应 |
表3.1呈现了四阶段技术演进的核心脉络。每个阶段的划分依据并非简单的时间切割,而是听说控制机制的质变:从"外部VAD强制轮次"到"模型自主决策话轮",从"单模态语音"到"全模态融合"。值得注意的是,第二阶段与第三阶段在时间上存在重叠——端到端语音模型兴起与全双工突破几乎同时发生,这反映了技术演进的并行性而非严格的线性递进。
四阶段演进的驱动力是"听说控制机制"的迭代升级,而非LLM参数规模的简单堆砌。每个阶段的核心矛盾从"延迟过高"演变为"无法打断",再演变为"模态单一",最终指向"被动响应"。
第一阶段:级联管道时代(2023–2024中)
架构解析:Whisper+GPT-4+TTS三段式流水线
第一阶段的技术架构可概括为三段式级联管道:用户语音→[ASR(Whisper)]→文本→[LLM(GPT-4)]→文本→[TTS]→语音回复。这是OpenAI于2023年推出的ChatGPT语音功能的底层架构,也是当时业界的标准范式。
该架构的核心特征是串行执行:每个模块必须等待前一个模块完成输出后才能开始工作。OpenAI工程师在DevDay Realtime API演讲中明确承认,这种多模型pipeline方法的延迟很长——GPT-4需要约1秒才能开始生成响应,STT和TTS模型又增加了1–2秒,总延迟在GPT-3.5下平均2.8秒、GPT-4下平均5.4秒。
局限性与根本原因
级联管道的局限性可从"感知-决策-回复"三维框架逐一分析:
| 维度 | 级联管道表现 | 根本原因 | 用户体感影响 |
|---|---|---|---|
| 感知 | ASR转文本后丢失副语言信息 | 语音→文本的不可逆信息压缩 | 无法感知用户情感、语气 |
| 决策 | 依赖外部VAD判断话轮结束 | VAD基于声学能量而非语义理解 | 思考停顿被误判为话轮结束 |
| 回复 | 文本生成+TTS合成,机械感强 | TTS与LLM独立训练,风格割裂 | 语音缺乏情感与韵律变化 |
表3.2揭示了级联管道在三个维度上的系统性缺陷。最根本的问题在于信息在模块交接处的不可逆丢失:ASR将丰富的语音信号压缩为纯文本,LLM无法从文本中恢复韵律特征;TTS将LLM生成的文本重新合成为语音,但无法还原LLM未曾"理解"的情感意图。这种"信息压缩→信息丢失→信息失真"的级联效应,使得整个系统的上限被最弱环节锁定。
延迟量化分析
级联管道的延迟由各环节串行累加:
其中,VAD沉默检测窗口长度决定了延迟的方差——短窗口导致误判(用户尚未说完即触发回复),长窗口膨胀延迟。标准差达489ms,P90延迟高达2,318ms。延迟抖动(jitter)比单纯延迟更破坏体验,因为用户无法预测AI何时会回应。
级联管道的根本局限不是某个模块不够快,而是串行架构本身决定了延迟的下限——即使每个模块都优化到极致,模块间的等待与交接仍构成不可消除的延迟floor。
第二阶段:端到端语音模型兴起(2024中–2024末)
GPT-4o语音模式:从级联到端到端的范式跃迁
2024年5月,OpenAI发布GPT-4o,这是首个原生多模态模型,能够直接处理音频输入和输出,不再需要外挂ASR和TTS模块。GPT-4o语音模式的核心突破在于语音理解与语音生成共享同一套隐状态表示——音频信号进入模型的瞬间,语义特征和声学特征已在隐空间中交叉激活。
GPT-4o将平均延迟从级联管道的2.8–5.4秒压缩至约300ms,提升了近10倍。更重要的是,它保留了副语言信息——模型可以直接感知用户的语气、情感和节奏,并在回复中自然表达笑声、叹息等非语言声音。
端到端的局限:仍是半双工
尽管GPT-4o在延迟和信息保留上实现了重大突破,但它仍然主要依赖轮次判断——系统必须先判断用户是否说完,才决定模型是否应该开始回答。这种基于"静音检测"的机制导致它极容易被背景噪音误导,且无法支持自然打断。OpenAI在介绍GPT-Live时,明确将此前的Advanced Voice Mode称为"回合制语音模型(turn-based voice model)"。
端到端架构解决了级联管道的延迟和信息丢失问题,但并未解决"回合制"这一根本性交互瓶颈。从"串行"到"并行"的跃迁,需要的是听说控制机制的革命,而非仅仅是架构的统一。
3第三阶段:全双工语音对话突破(2024中–2024末)
第三阶段是全双工大模型技术演进的核心阶段,六个代表模型从不同技术路径实现了"同时听说"的突破。这一阶段的共同特征是:模型不再等待外部VAD指令,而是自主决策何时说话、继续说或停止说。
Moshi:双轨并行的开创者
Moshi由法国非营利性AI研究机构Kyutai开发,于2024年9月发布,是首个开源的全双工端到端语音对话模型。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2024年9月(arXiv:2410.00037) |
| 开发团队 | Kyutai(8人团队,6个月研发) |
| 架构 | 双轨并行(语义轨+声学轨)+内部独白 |
| 音频编解码器 | Mimi(80ms帧延迟,12.5Hz帧率,1.1kbps带宽) |
| 参数规模 | 基于Helium 7B LLM |
| 理论延迟 | 160ms(实际约200ms) |
| 核心创新 | Inner Monologue机制 |
Moshi的架构核心是双流并行建模:将用户输入流和模型输出流在当前位置求和,以预测下一步模型输出。这种设计消除了显式的说话人轮次,支持任意对话动态——包括重叠说话和自然打断。
内部独白(Inner Monologue) 是Moshi的关键创新:模型在生成音频token之前,先预测时间对齐的文本token作为前缀。这一机制不仅显著提升了生成语音的语言质量,还提供了流式语音识别和文本转语音的附带能力。可以将其理解为模型的"内心独白"——在开口说话之前,先"想"好要说什么。
Mimi编解码器是另一项重要贡献:基于残差矢量量化(RVQ)技术,将24kHz音频压缩至1.1kbps(压缩比约349倍),延迟仅80ms,性能却优于现有的非流式编解码器。
SALMONN-Omni:首个codec-free方案
SALMONN-Omni由清华大学团队开发,发表于2024年11月(arXiv:2411.18138),是首个不依赖音频编解码器注入的独立全双工语音LLM。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2024年11月 |
| 开发团队 | 清华大学 |
| 架构 | 流式编码器+LLM主干+流式合成器(codec-free) |
| 核心创新 | 动态"思考"机制+连续embedding |
| 关键优势 | 避免模态差距与灾难性遗忘 |
SALMONN-Omni的核心突破在于用连续embedding替代离散token,彻底摒弃了音频编解码器。Moshi等模型将音频量化为离散token注入LLM词表,需要大规模语音-文本配对数据来弥合模态差距,且容易导致模型对原有文本知识的灾难性遗忘。SALMONN-Omni通过隐藏层嵌入将LLM主干与流式语音编码器和合成器集成,避免了量化带来的信息损失。
动态"思考"机制是SALMONN-Omni的另一项关键创新。模型在每个时间块中决定是否应该发生状态转换,通过生成特殊token(THINK、START、END)来控制"说话"与"思考"状态。显式"思考"策略将状态转换token混合到LLM输入序列中,让模型像人类一样在对话中"思考"何时开口——这比隐式策略性能更优,因为训练LLM生成由正常回复和状态转换token组成的完整序列,与其内在机制自然契合。
在全双工模式下,SALMONN-Omni比此前最佳结果至少提升30%。
Freeze-Omni:冻结LLM主干的最低成本方案
Freeze-Omni由腾讯优图实验室开发,发表于2024年11月(arXiv:2411.00774),其核心思想是在整个训练过程中保持LLM参数完全冻结。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2024年11月 |
| 开发团队 | 腾讯优图实验室 |
| 架构 | 冻结LLM主干+语音编码器+语音解码器 |
| 核心创新 | LLM全程冻结,仅训练适配器和控制模块 |
| 训练数据 | ASR/TTS配对数据+仅60,000条多轮QA数据 |
| 训练成本 | 8个GPU即可完成 |
Freeze-Omni的三阶段训练策略极为精巧:
- 语音编码器对齐:使用ASR数据训练语音编码器,以ASR任务为优化目标将编码器与LLM做模态对齐,LLM冻结;
- 语音解码器训练:利用文本-语音配对数据训练基于自回归的语音解码器,采用prefix KV-cache微调策略将解码器转移到LLM输出空间;
- 双工对话能力:将编码器和解码器同时连接到LLM,使用chunk-wise状态预测任务实现全双工对话能力。
这种设计的最大优势是成本极低——不需要百万小时级别的语音问答数据,避免了灾难性遗忘问题,且可以支持任何具有文本模态的LLM。如果需要改变响应风格,只需用相应风格的文本数据对LLM进行微调即可。
DuplexMamba:线性复杂度的实时流式方案
DuplexMamba发表于2025年2月,是基于Mamba架构的端到端多模态全双工对话模型。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2025年2月 |
| 架构 | Mamba选择性状态空间模型 |
| 核心创新 | O(N)线性复杂度替代O(N²)自注意力 |
| 适用场景 | 7×24小时实时流式场景 |
DuplexMamba的核心价值在于用Mamba的选择性状态空间模型替代Transformer的自注意力机制。Transformer的自注意力复杂度为O(N²),当处理长序列语音时计算量和内存消耗急剧增长;Mamba通过结构化状态空间模型(S3M)实现O(N)线性时间复杂度和O(1)常数时间递归推理。
这意味着无论输入语音被切分成多少个时间片,计算量的增长都是线性的而非平方级。对于需要7×24小时持续运行的实时语音交互场景,DuplexMamba的线性复杂度意味着更低的推理成本和更可预测的延迟——这正是部署到生产环境的关键要求。
Mamba(选择性状态空间模型):一种新型序列模型架构,其核心创新在于"选择性"——模型参数(状态转移矩阵等)不再是固定的,而是输入内容的函数。这使得模型能"选择性"地记忆或忽略历史信息,在保持线性复杂度的同时获得接近Transformer的全局建模能力。类比:如果把Transformer比作"全员大会"(每个人都能和所有人发言),Mamba则像"智能秘书"——只记住重要的信息,忽略无关的噪音。
DuplexCascade:级联管道也能实现全双工
DuplexCascade(以小红书FireRedChat为代表)证明了一个反直觉的结论:级联管道也能实现全双工 。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2025年9月(arXiv:2509.06502) |
| 开发团队 | 小红书FireRed团队 |
| 架构 | 级联/半级联+可插拔轮次控制器 |
| 核心创新 | 外部控制模块升级半双工为全双工 |
| 打断检测 | 170ms内检测插话 |
| 打断成功率 | 90% |
| 误打断率 | 10.2% |
FireRedChat将全双工语音交互解耦为三个核心模块:轮次转换控制器(基于自研pVAD与轻量EoT)、交互模块(支持级联和半级联两种模式)、对话管理器(支持工具调用和上下文管理)。其关键洞察是:全双工的核心不在于架构是否端到端,而在于是否有精确的轮次控制机制。通过可插拔的控制模块,任何半双工系统(级联、半级联或语音到语音)都可以升级为全双工。
这种设计的最大优势是可维护性最高——每个模块可以独立优化和替换,功能更新无需重新训练整个模型。在开源产品中,FireRedChat的端到端延迟已接近工业级闭源系统。
第三阶段六模型对比
| 模型 | 架构类型 | 听说控制机制 | 核心创新 | 延迟 | 优势 | 局限 |
|---|---|---|---|---|---|---|
| Moshi | 端到端 | 双流并行+内部独白 | 首次开源全双工 | ~200ms | 开创性,功能完整 | 需大规模训练数据 |
| SALMONN-Omni | 端到端 | 动态"思考"token | codec-free连续embedding | 数据待确认 | 避免灾难性遗忘 | 训练复杂度高 |
| Freeze-Omni | 端到端 | chunk-wise状态预测 | LLM全程冻结 | 较低 | 成本最低 | 依赖适配器质量 |
| DuplexMamba | 端到端 | Mamba状态空间 | O(N)线性复杂度 | 低 | 适合7×24运行 | 生态成熟度低 |
| DuplexCascade | 级联 | 外部pVAD+EoT | 可插拔升级 | ~170ms打断 | 可维护性最高 | 模块间误差传播 |
表3.3对比了第三阶段六个代表模型的技术路线差异。一个关键发现是:全双工的实现路径并非只有端到端一条路。DuplexCascade证明,级联管道通过精确的外部控制模块同样可以实现全双工,且在某些场景下(如需要快速迭代、模块独立优化)更具工程优势。
第三阶段的六大模型从不同技术路径实现了全双工突破,但它们的共同核心不是LLM规模,而是听说控制机制的设计——无论是内部的"思考"token、双流并行,还是外部的pVAD+EoT,本质上都是在解决"何时说、何时听"的决策问题。
第四阶段:全模态全双工(2025中–2026)
第四阶段的质变在于从"听和说"扩展到"看、听、说",并从被动响应升级为主动行为。这不仅是模态数量的增加,更是交互范式的根本转变——AI从"等待指令的工具"变为"参与思考的伙伴"。
3.5.1 Stream-Omni:差异化对齐策略
Stream-Omni由中国科学院计算技术研究所自然语言处理团队开发,发表于2025年6月(arXiv:2506.13642),是同时支持文本-视觉-语音多模态交互的大模型。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2025年6月 |
| 开发团队 | 中科院计算所 |
| 架构 | LLM主干+底部语音层+顶部语音层+视觉编码器 |
| 核心创新 | 差异化对齐:视觉拼序列、语音映射到层 |
| 训练数据 | 仅2.3万小时语音的多模态数据 |
Stream-Omni的核心创新是差异化模态对齐策略:视觉模态与文本模态之间具有语义互补性,因此采用序列维度拼接(类似LLaVA架构);语音模态与文本模态之间应语义高度一致,因此采用层级维度映射——在LLM底部引入语音层学习语音到文本的映射(CTC损失监督),在顶部引入语音层完成文本到语音的生成。
这种设计的优势在于:基于CTC的语音-文本映射为语音和文本在表示和结构上的对齐提供了更直接的监督,使得Stream-Omni仅用2.3万小时语音数据即可将LLM主干的文本能力迁移至语音模态。此外,层级维度映射使得模型在语音交互过程中能同步输出中间文本结果(即指令和回复的转录文本),为用户提供更全面的多模态体验。
3.5.2 MiniCPM-o 4.5:首个端侧可运行的全模态全双工模型
MiniCPM-o 4.5由面壁智能联合OpenBMB开源社区、清华大学THUNLP实验室和THUMAI实验室发布,技术报告发表于2026年4月(arXiv:2604.27393),是首个可在边缘设备运行的开源全双工全模态大模型 。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2026年2月(模型),4月(技术报告) |
| 开发团队 | 面壁智能+OpenBMB+清华大学 |
| 参数规模 | 9B |
| 运行要求 | <12GB RAM(INT4量化仅需11GB显存) |
| 架构 | Omni-Flow统一流式框架 |
| 核心创新 | 共享时间轴+TAIL时间对齐交错语音生成 |
| RTF | 0.4(RTX 5070) |
MiniCPM-o 4.5的核心创新是Omni-Flow统一流式框架:将全模态输入与输出沿共享时间轴对齐,借鉴时分复用技术将连续交互划分为细粒度时间窗口,在每个窗口内同时纳入新到达信号并生成输出,将传统回合制交互转化为时间局部更新的连续流。
TAIL(Time-aligned Interleaved speech generation) 策略是该框架的关键组件,确保语音生成与时间轴精确对齐。这意味着模型可以在持续感知环境(看视频、听声音)的同时进行思考和响应——AI从被动工具转变为能主动帮助人类的助手。
MiniCPM-o 4.5的端侧部署能力具有里程碑意义:最低仅需12GB显存的RTX 5070即可流畅运行全双工模式,且支持Windows/macOS一键安装包(Comni),无需联网即可在个人电脑上实现"边看、边听、边说、还能主动提醒"的类人交互。
OpenAI GPT-Live:架构解耦的规模化落地
GPT-Live由OpenAI于2026年7月8日正式发布,是首个真正的全双工语音大模型产品,同步升级ChatGPT语音模式。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2026年7月8日 |
| 开发团队 | OpenAI |
| 版本 | GPT-Live-1(付费)+ GPT-Live-1 mini(免费) |
| 架构 | 全双工语音层+后台推理层(GPT-5.5)解耦 |
| 核心创新 | 语音交互与深度推理分离 |
| 覆盖 | 全球1.5亿周活用户 |
GPT-Live最核心的架构创新是语音交互层与推理层的彻底解耦:GPT-Live留在前台持续听和说,维持对话流畅度;当问题需要网络搜索或复杂推理时,任务被无缝交给后台的GPT-5.5处理,期间对话不必停下来。
GPT-Live每秒多次判断是否说话、继续倾听或打断,用户可以随时打断AI发言,模型也会通过"嗯""对""明白"等简短回应表明倾听状态。OpenAI研究负责人Kundan Kumar在发布会上强调,旧版高级语音模式下模型必须等用户说完才能回应,短暂停顿常被误判为发言结束;GPT-Live则彻底消除了这一问题。
WARP协议的引入将WebRTC启动从6个网络往返降至1个,进一步降低了连接延迟。
字节Seeduplex:双塔-三流一体化设计
Seeduplex由字节跳动Seed团队于2026年4月9日发布,是较早实现规模化落地的全双工语音大模型,已在豆包App全量上线。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2026年4月9日 |
| 开发团队 | 字节跳动Seed/豆包大模型团队 |
| 架构 | 双塔-三流一体化 |
| 端到端延迟 | 50ms级(S2S闭环) |
| 打断准确率 | 97.3%(词级实时打断) |
| MOS | 4.67(超越人类坐席4.55) |
Seeduplex的双塔-三流一体化设计是其核心架构创新:
- 听塔(Listener Tower):流式语音编码器+语义理解模块,负责实时转写与意图解析;
- 说塔(Speaker Tower):文本-语义解码器+神经声码器,负责生成回复文本并同步合成语音;
- 全双工协调器(Duplex Orchestrator):基于强化学习的冲突检测与抢占机制,确保打断、插话、背景噪声抑制下的自然交互。
Seeduplex在50ms级延迟下实现97.3%的词级实时打断准确率,在2万小时真实客服场景测试中MOS达4.67,首次超越人类坐席4.55的基线。在复杂声学场景下,误回复率和误打断率较半双工模型减少了一半。
NVIDIA PersonaPlex:基于Moshi架构的7B全双工模型
PersonaPlex由NVIDIA于2026年1月开源发布,是基于Moshi架构改进的7B参数全双工语音对话模型。
| 属性 | 详情 |
|---|---|
| 发布时间 | 2026年1月 |
| 开发团队 | NVIDIA |
| 参数规模 | 7B |
| 架构 | 基于Moshi架构+Helium LLM+Mimi编解码器 |
| 打断延迟 | 170–240ms |
| 轮替接管率 | 90.8% |
| 许可 | MIT协议(代码)+ NVIDIA开放模型许可(权重) |
PersonaPlex保留了Moshi的核心双流架构,但将底层语言模型替换为Kyutai自研的Helium 7B LLM(在超过2万亿token的多语言语料上训练,支持32k上下文窗口)。训练数据融合了真实对话与合成场景:真实数据来自Fisher英语语料库约1,217小时通话,合成数据包括约410小时助理对话与1,840小时客服对话。
PersonaPlex的独特价值在于角色提示与音色调节能力——通过纯文本角色提示实现人格控制,输入"你是一位耐心幽默的物理老师",模型即以对应语气、语调和知识深度回应。
第四阶段模型性能数据汇总
| 模型 | 参数规模 | 延迟 | 打断能力 | 模态覆盖 | 部署场景 | 核心优势 |
|---|---|---|---|---|---|---|
| Stream-Omni | 8B | 数据待确认 | 半双工 | 文本+视觉+语音 | 云端 | 差异化对齐,数据效率高 |
| MiniCPM-o 4.5 | 9B | RTF 0.4 | 全双工 | 文本+视觉+语音 | 端侧 | 首个端侧全双工全模态 |
| GPT-Live | 闭源 | <300ms | 全双工 | 语音 | 云端(1.5亿周活) | 语音-推理解耦,规模化 |
| Seeduplex | 闭源 | ~50ms | 97.3%准确率 | 语音 | 云端+App | 极致延迟,超越人类MOS |
| PersonaPlex | 7B | 170–240ms | 90.8%接管率 | 语音 | 本地(单A100) | 角色可控,MIT开源 |
表3.4汇总了第四阶段五个代表模型的关键性能数据。值得注意的是,延迟与参数规模之间不存在简单的正相关——Seeduplex以闭源架构实现50ms级延迟,而PersonaPlex以7B参数实现170–240ms打断延迟,GPT-Live则通过架构解耦在保持对话流畅的同时支持深度推理。这进一步印证了关键结论:全双工的核心在于听说控制机制的设计,而非LLM规模本身。
第四阶段的质变是从"语音双工"到"全模态双工"、从"被动响应"到"主动行为"。MiniCPM-o 4.5的端侧部署能力和GPT-Live的语音-推理解耦架构,分别代表了开源和闭源两条路径的规模化落地方案。
技术路线分类体系
基于对上述所有模型的架构分析,可建立如下技术路线分类体系:
| 路线 | 定义 | 代表模型 | 感知方式 | 回复决策 | 回复方式 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|
| 级联式 | ASR→LLM→TTS多模块串行 | DuplexCascade/FireRedChat | ASR转文本,易丢失副语言 | 外部VAD/控制模块 | 文本生成+TTS合成 | 模块独立可维护 | 误差传播,信息丢失 |
| 端到端 | 语音理解与生成统一建模 | Moshi、SALMONN-Omni、Freeze-Omni、DuplexMamba | 直接处理语音/音频编码 | 模型自主预测状态token | 直接输出语音音频 | 信息保留完整,延迟低 | 训练复杂,黑盒特性 |
| 混合式 | 端到端+外部控制/级联元素 | GPT-Live(语音-推理解耦)、Seeduplex(双塔协调器) | 直接处理语音 | 内部机制+外部协调 | 语音+后台推理 | 兼顾灵活性与性能 | 架构复杂度高 |
表3.5呈现了三条技术路线的分类标准。关键发现是:级联式与端到端并非简单的替代关系,而是互补关系。DuplexCascade证明级联式通过精确的控制模块也能实现全双工;GPT-Live和Seeduplex则展示了混合式架构在规模化落地中的优势。
对比评价
三条技术路线六维度对比总表
| 对比维度 | 级联式(FireRedChat为代表) | 端到端(Seeduplex为代表) | 混合式(GPT-Live为代表) | 选择策略依据 |
|---|---|---|---|---|
| 感知方式 | ASR转文本,副语言丢失 | 直接语音处理,信息完整 | 直接语音处理,信息完整 | 端到端/混合式信息保真度更高 |
| 回复决策 | 外部pVAD+EoT | 模型自主三态决策 | 语音层自主+推理层异步 | 语义联合判断优于纯声学 |
| 回复方式 | 文本+TTS,情感可能脱节 | 直接语音,韵律自然 | 直接语音+后台推理 | 端到端/混合式MOS更高 |
| 智能能力 | 受限于ASR质量 | 潜力大但存在模态冲突 | 语音-推理解耦,兼顾两者 | 混合式在复杂推理场景占优 |
| 优化难度 | 低,模块独立可插拔 | 高,黑盒,4.8万GPU日 | 中,架构复杂但可独立迭代 | 级联式工程友好 |
| 回复延迟 | ~1.3s(P50) | 320ms | <300ms | 端到端/混合式延迟优势显著 |
全双工代表模型关键指标对比
| 模型 | 架构路线 | 参数规模 | 端到端延迟 | 打断准确率 | MOS | 部署场景 | 核心优势 |
|---|---|---|---|---|---|---|---|
| FireRedChat | 级联式 | 可插拔 | ~1.3s | 90% | — | 私有化 | 可维护性最高 |
| Moshi | 端到端 | 7B | ~200ms | — | — | 云端 | 首个开源全双工 |
| SALMONN-Omni | 端到端 | — | — | — | — | 云端 | codec-free |
| Freeze-Omni | 端到端 | 可插拔 | 较低 | — | — | 云端 | 成本最低(8 GPU) |
| DuplexMamba | 端到端 | — | 低 | — | — | 云端 | O(N)线性复杂度 |
| Seeduplex | 端到端 | 20B | ~50ms | 97.3% | 4.67 | 云端+App | 极致延迟,超越人类 |
| GPT-Live | 混合式 | 闭源 | <300ms | — | — | 云端(1.5亿周活) | 语音-推理解耦 |
| MiniCPM-o 4.5 | 混合式 | 9B | RTF 0.4 | — | — | 端侧 | 首个端侧全双工全模态 |
| PersonaPlex | 端到端 | 7B | 170–240ms | 90.8% | — | 本地 | 角色可控,MIT开源 |
-
综合评价:
- 当延迟与交互自然度是首要目标(实时对话、陪伴式AI、虚拟人)时,端到端或混合式更优——Seeduplex(50ms级延迟、MOS 4.67)和GPT-Live(<300ms、1.5亿周活)是最佳实践。
- 当可维护性与私有化部署是首要目标(金融、医疗、政企)时,级联式更优——FireRedChat的可插拔架构允许以最低成本升级存量系统。
- 当端侧部署是硬约束(个人电脑、移动设备)时,MiniCPM-o 4.5(9B参数、12GB显存)是当前最优解。
- 当深度推理与实时对话需并行时,混合式(GPT-Live路线)是唯一选择——语音层负责实时交互,推理层异步处理复杂任务。