← 首页|2026-07-10-deep-2606-09186
cs.HC · 2606.09186 · 8 Jun 2026
DuplexOmni: Real-Time Listening, Seeing, Thinking, and Speaking for Full-Duplex Interaction
Muye Huang, Lingling Zhang, Xingyu Yu, Lei Shi, Zhanyu Ma, Jun Xu, Jiuchong Gao, Jinghua Hao, Renqing He, Jun Liu
Duplex-Agent
Full-Duplex
Multimodal
Real-Time
Async-Architecture
Voice-Agent
Open-Source (Planned)
一句话:DuplexOmni 把 duplex agent 最核心的矛盾——实时响应 vs 深度推理——通过两层异步架构化解:Interaction Layer(480ms 时间片,实时听、看、说)与 Thinking Layer(可插拔 LLM/Agent,深度推理、工具调用)并行运行,互不阻塞。DuplexBench ToR 达 72.6%(竞品 24–36%),同时 Big Bench Audio 达 77.2%(超越所有公开竞品)。核心数据发现:全双工质量独立于 thinking layer 强弱;thinking layer 决定推理天花板;interaction layer 提升 thinking 效用。计划开源。
核心问题:全双工与深度推理的不可能三角
人类对话天然是连续的、多模态的、全双工的——说话的同时在听,听的同时在思考,随时可以打断或被打断。现有 omni 模型在统一语音/视觉/文本建模上已有进展,但面临一个核心矛盾:
实时响应路线
轻量级模型 + 低延迟,能维持连续互动节奏,但推理能力弱,无法处理复杂任务、工具调用、多步推理。
深度推理路线
大模型 + CoT / Tool use,能处理复杂任务,但推理阻塞交互——用户说话时模型在想,无法实时接收输入、控制节奏、做出即时反应。
"Combining seamless real-time interaction with complex reasoning and tool use remains challenging."
DuplexOmni 的解法:把这两条路线拆开做,并行跑,异步通信——而非试图在单一模型内同时完成。
系统架构:两层异步设计
Thinking Layer(S2)
可插拔 LLM / Agent。接收用户上下文 → 深度推理、工具调用 → 流式返回中间结果给 Interaction Layer。完全异步,不阻塞交互层。可换用任意 LLM(论文实验默认用 Gemini-3.1-Flash-Lite)。
↕ 异步通信
Interaction Layer 发出 thinking request → Thinking Layer 流式返回结果片段 → Interaction Layer 在合适位置注入响应,或在条件变化时发出 [WAIT] 取消当前推理流
Interaction Layer(S1)
DuplexOmni 模型本体(端到端)。持续接收流式音频 + 视频帧 → 持续输出文本 + 语音响应。以 480ms 为单位时间片处理,在 S2 推理期间负责节奏控制、即时反应、中间状态管理。
灵感来源:人类认知的快慢系统(fast/slow thinking)。S1 对应直觉快速反应,S2 对应深度慢速推理。两者并行而非串行。
两层解耦的核心优势
- 实时性与能力上限解耦:可以独立升级 Thinking Layer(换更强的 LLM)而不影响交互延迟
- 故障隔离:Thinking Layer 超时/出错不会导致交互层卡顿
- 灵活组合:Thinking Layer 可以是任意 Agent——工具调用 Agent、代码执行 Agent、RAG Agent
- 渐进增强:Interaction Layer 的即时响应已有独立价值,Thinking Layer 的结果是增量注入
480ms 时间片建模:全双工的实现细节
全双工的核心技术挑战是:模型如何在持续生成输出的同时,持续接收输入?DuplexOmni 的解法是把连续交互切分为 480ms 时间片。
每个时间片 t 的输入 → 输出
输入:
- 对话历史 + Thinking Layer 中间结果(截至当前)
- 第 t−1 片的 480ms 音频段
- 同一时间片采样的视频帧
输出(三个并发产物):
- Thinking 控制信号(是否触发/取消 S2 推理)
- 对最新用户输入的语义解释
- 助手文本 + 对应 480ms 语音响应
480ms 的粒度意味着模型每半秒做一次"听 + 看 + 想 + 说"的完整循环。在此循环内,它同时接收 S2 的流式结果、控制自身的输出节奏、并决定是否触发或取消 S2。
关键设计决策:时间片长度是一个核心超参。480ms 是延迟(用户感知响应速度)与上下文完整性(足够的音频让 ASR 有效)之间的权衡点。更短的片(如 160ms)会增加实时性但 ASR 更难;更长的片(960ms+)上下文更丰富但增加感知延迟。
Thinker-Talker 语音生成架构
DuplexOmni 的 Interaction Layer 内部基于 Qwen-Omni 的 Thinker-Talker 架构(但在此指 S1 内部的文本/语音解耦,非 S1/S2 的宏观分层):
Thinker(内部 MLLM 骨干)
处理完整上下文(历史 + S2 中间结果 + 当前音视频),生成助手文本 token,输出 token embedding Eₜ 和 hidden states Hₜ。
Talker(流式语音生成)
将 Thinker 的语言状态转换为流式语音,通过 RVQ codec 输出。Talker 的 conditioning 信号为:
ct,ℓ = f_text(et,ℓ) + f_hidden(ht,ℓ)
每个 slice 生成
6 个 codec 帧,经 Code2Wav 解码为波形。使用 MTP(Multi-Token Prediction)模块预测残差 codebook,提升语音质量。
Thinker 和 Talker 的推理路径在 inference 时解耦为异步流水线,消除串行延迟积累——这是实现 RTF(Real-Time Factor) < 1 的关键。
控制 Token 体系:六个时序控制信号
DuplexOmni 引入 6 个特殊控制 token,对连续交互中的时序事件进行精细建模。这是整个系统的"语义时钟",驱动两层之间的协调行为:
| Token | 归属方 | 语义 |
| [THINK] |
用户侧 |
在用户话语末尾触发,启动 S2 后台推理 |
| <…> |
助手侧 |
在相关事实前注入 S2 结果片段(流式插入) |
| ^(caret) |
助手侧 |
标记对方开始说话的字符偏移位置(用于重叠语音检测) |
| [CUT] |
助手侧 |
标记助手音频停止位置;之后的文本为"幽灵文本"(ghost text,计入 loss 但不合成语音) |
| [WAIT] |
用户侧 |
暂停/重置当前 S2 推理(用户打断时发出) |
| [PENDNS] |
用户侧 |
编码 N 秒共享静默(N=1–35),让模型感知对话节奏中的自然停顿 |
Ghost Text 机制
[CUT] 之后的文本是助手"本想说但被打断的内容"。这部分文本参与损失计算(让模型学习被打断前的完整意图),但在 TTS 合成时被剥离。这是全双工训练中的关键设计——模型需要学会"知道自己在说什么",即使最终没说出来。
六 Token 的组合覆盖了哪些场景
- 用户问复杂问题:[THINK] 触发 → S2 推理 → <…> 注入结果 → 助手自然回答
- 用户打断助手:^ 标记重叠点 → [CUT] 停止当前音频 → [WAIT] 重置 S2
- 对话静默:[PENDNS] 保持对话状态感知,不误判为对话结束
- 助手主动发起:无需用户触发,助手可在 [PENDNS] 后主动提问
Writer-Director 数据流水线
全双工交互数据天然稀缺——传统对话数据都是轮次分离的,无法表达时序控制信号。DuplexOmni 设计了 Writer-Director 两阶段流水线从头构造训练数据:
阶段一:场景与内容构建
Scenario seeds(~62 万个)定义交互模式:谁先发起、用户是否会修改条件、助手如何处理 turn-taking 事件。
原始内容来源:UltraChat、WildChat、BELLE、COIG、no-robots、OASST2。
内容被过滤并改写为语音友好格式(去除特殊符号、过长句子)。
生成模型:Qwen3.5-397B-A27B(全流水线各阶段统一使用)。
阶段二:Writer-Director 时序标注
Writer
按场景 seed 生成自然语言对话剧本——处理数学任务、打断、助手主动发起等场景。输出是人类可读的线性剧本,不含时序控制信息。
Director
把 Writer 的剧本转换为带时序控制信号的结构化样本。不改变对话内容,只添加时序因果性。输出包含全部六个控制 token 的标注位置。最后用字符级时间戳构造时间片训练样本。
一致性过滤移除:冲突控制 token、缺失 thinking 触发、无因果来源的信息注入、不合理的打断点。
数据规模与分布
| 交互模式 | 出现比例 |
| 延迟推理([THINK] + S2 片段) | 94.3% |
| 共享静默([PENDNS]) | 68.2% |
| 助手主动发起 | 50.0% |
| 重叠语音(^ + [CUT]) | 49.8% |
| 打断并重置([CUT]+[WAIT]) | 41.9% |
| 含 ≥2 种交互模式的样本 | 90.7% |
数据设计洞察:94.3% 的样本包含延迟推理模式,说明 Thinking Layer 的参与是常态而非例外。90.7% 的样本含多种交互模式,体现了真实对话的复杂时序交织。这种高密度的组合模式是用合成数据构造真实感全双工训练数据的核心挑战。
| Thinking Layer 参与程度 | 比例 |
| 高参与 | 23.6% |
| 中参与 | 46.0% |
| 低参与 | 24.9% |
| 无参与 | 5.5% |
训练设置
基座模型:Qwen3-Omni
训练策略:两阶段 SFT
- Stage 1:大规模语音交互数据 → 基本全双工听/说能力
- Stage 2:高质量交互数据 + 视频通话数据 → 复杂交互 + 视觉理解
优化方式:每个阶段内交替优化(Thinker 和 Talker 分别冻结对方)
- Thinker LR:
1e-5,Talker LR: 1e-4
- Batch size: 128
基础设施:Megatron-swift-3.12,128 × Nvidia H20
RTF 优化:Thinker(文本生成)与 Talker(语音生成)推理路径解耦为异步流水线,配合 KV-cache 增量解码和图执行优化,实现 RTF < 1(即生成速度快于播放速度)。
实验结果与关键发现
主实验(Table 1)
| 模型 | DuplexBench ToR ↑ | Big Bench Audio ↑ | LibriSpeech WER ↓ | 延迟(s) ↓ |
| DuplexOmni |
72.6% |
77.2% |
0.1192 |
0.506 |
| MiniCPM-o 4.5 | 36.3% | 36.0% | — | 0.502 |
| Doubao | 27.8% | 47.9% | — | 1.82 |
| Qwen3-Omni-Realtime-Flash | 25.2% | 32.1% | 0.013 | 1.28 |
| Qwen3.5-Omni-Realtime-Flash | 26.4% | 35.0% | 0.011 | 1.25 |
| Gemini-3.1-Flash-Live | 24.1% | 57.9% | 0.041 | 2.57 |
| Gemini-3.1-Flash-Lite | — | 58.9% | 0.038 | — |
⚠️ 注意:DuplexOmni 的 LibriSpeech WER(0.1192)明显高于 Qwen 系列(0.011–0.013)和 Gemini 系列(0.038–0.041)。这反映了全双工 ASR 的固有难度——在持续生成语音的同时进行 streaming ASR,特别是短话语(见下方 Table 3)。这不是 bug 而是 full-duplex 的代价。
消融实验(Table 2):三个关键发现
| 配置 | DuplexBench ToR | Big Bench Audio |
| DuplexOmni(完整) | 72.6% | 77.2% |
| 弱 Thinking Layer(Gemini Lite → 更弱模型) | 72.1% | 50.3% |
| 无 Thinking Layer | 65.2% | 22.2% |
| 无 Thinking Layer + 无 ASR | 67.2% | 18.1% |
| 仅 Thinking Layer(无 Interaction Layer) | — | 58.9% |
发现 1:全双工质量独立于 Thinking Layer 强弱
换用弱 Thinking Layer,ToR 仅从 72.6% → 72.1%(-0.5pp)。全双工互动节奏由 Interaction Layer 决定,与 S2 推理能力解耦。
发现 2:Thinking Layer 决定推理天花板
移除 Thinking Layer,Big Bench Audio 从 77.2% 崩至 22.2%。S2 是系统的能力上限控制变量——Interaction Layer 负责实时节奏,S2 负责实际智能。
发现 3:Interaction Layer 提升 Thinking 效用
仅用 Thinking Layer(无 Interaction Layer)只达 58.9%,而完整系统达 77.2%(+18.3pp)。Interaction Layer 过滤/整理输入,让 S2 收到更高质量的上下文。
全双工 ASR 分析(Table 3):短话语是最难的
| 话语长度(词数) | Gemini Lite WER | Gemini Live WER | DuplexOmni WER |
| 1–5 词 | 4.9% | 7.8% | 25.1% |
| 6–10 词 | 5.3% | 4.4% | 15.4% |
| 11–15 词 | 3.4% | 3.3% | 12.0% |
| 16–20 词 | 2.9% | 2.2% | 10.6% |
| 21+ 词 | 3.2% | 4.6% | 8.8% |
| 总体 | 3.75% | 4.09% | 11.92% |
DuplexOmni 在长话语(21+词)上与竞品差距收窄(8.8% vs 3–5%),但短话语(1–5词)差距显著(25.1% vs 5–8%)。短话语上下文匮乏,在全双工流式设置下 ASR 上下文更少,是当前最硬的技术挑战。
局限性与未来方向
视频能力偏弱
视频通话数据(1万条)和视觉场景数据相对稀少,视觉理解能力受限。未来需要更大规模的视觉交互数据。
英语语音弱于预期
训练数据 ~70% 中文 / ~30% 英文,导致英语语音质量弱于中文。平衡多语言语音训练是计划中的改进方向。
计划开源
模型权重、训练数据、训练/推理实现均计划开源——这对 duplex agent 方向的研究社区有重要价值。
研究者视角:对 duplex agent 方向的含义
核心架构洞察:解耦是正确的抽象
DuplexOmni 最重要的贡献不是具体的模型结构,而是把 duplex agent 的设计空间拆解为两个独立的优化目标:交互质量(latency, turn-taking, natural rhythm)和推理质量(reasoning depth, tool use, accuracy)。消融实验严格证明了这两个目标在系统中确实是可以独立优化的——这个验证比架构本身更有价值。
对 duplex agent 研究者的含义:你可以独立评估和改进这两个维度,不用在单一模型内寻找 trade-off 的平衡点。
480ms 时间片:从架构决策到研究问题
论文选择 480ms 但没有详细的消融实验验证这个选择。这是一个开放的研究问题:
- 更短时间片(160ms)可能改善短话语 ASR 问题,但每次决策的上下文更少
- 动态自适应时间片(根据音频内容动态调整)是一个未被探索的方向
- 480ms 约等于人类对话的最小感知单元(syllable-level),这可能不是巧合
控制 Token 体系:全双工对话的形式化
六个控制 token 实质上是对全双工对话时序事件的完整形式化。覆盖了:推理触发([THINK])、结果注入(<…>)、打断检测(^)、发言停止([CUT])、推理取消([WAIT])、静默感知([PENDNS])。这个 token 集合可以看作 duplex agent 协议的一个候选规范——未来的系统可以在此基础上扩展(例如增加情绪状态 token、置信度 token)。
Writer-Director pipeline 的迁移价值
从任意对话数据生成全双工时序标注数据的 Writer-Director 方法,本质上是一个对话数据的时序增强框架。对于构建任何需要时序控制的 agent 交互系统(不限于语音),这个数据构造范式都有参考价值。特别是 Director 阶段只添加时序因果性、不改变内容的设计,让数据构造与内容质量解耦,大幅降低了高质量全双工数据的构造成本。
与 AI 实时语音产品的关系
当前主流实时语音产品(GPT-4o Voice、Gemini Live、Doubao)在 DuplexBench ToR 上均低于 30%,而 DuplexOmni 达 72.6%。ToR(Turn-taking Objective Rate)衡量的是模型在正确时机打断/等待/接话的能力——这是用户感知自然对话的核心维度,但一直缺乏系统性解法。DuplexOmni 填补了这个方向的工程空白,且一旦开源将成为研究基准。
▶ 与相关工作的关系(Qwen-Omni、Moshi、GPT-4o Realtime 等)
- Qwen3-Omni:DuplexOmni 基于 Qwen3-Omni 初始化,继承 Thinker-Talker 内部架构,但在其上叠加了 S1/S2 的宏观双层设计和全套 full-duplex 训练数据管道。Qwen3-Omni 的实时 Flash 版本在 DuplexBench ToR 上只有 25–26%。
- Moshi(Kyutai):也是 full-duplex 语音系统,但 Moshi 是单一模型内的 inner monologue 机制,没有外部 thinking layer 的可插拔设计。Moshi 不在本文 benchmark 对比中。
- GPT-4o Realtime:未在 DuplexBench 上公开报告,但从使用体验看 turn-taking 仍有明显限制。
- Gemini-3.1-Flash-Live:DuplexBench ToR 24.1%,Big Bench Audio 57.9%。大参数规模但 full-duplex 能力弱于 DuplexOmni。
来源: arXiv:2606.09186 · Huang et al. · 8 Jun 2026 · CC BY 4.0 · 精读整理:高松灯