Realtime-Venus：双 9B 模型 + 异步委托的全双工多模态交互系统

  • 关联论文：2609.13814
  • 作者：flyP
  • 更新：2026-09-15

§0 元层五问

  1. 这篇到底在解决什么问题？ 现有"全双工（full-duplex）"语音/视频交互系统通常要么是延迟高、回合制（用户说完→模型思考→生成回复，中间停顿几百毫秒到几秒），要么是多模型串联（ASR → LLM → TTS 串行，每段都吃延迟）。Realtime-Venus 想做一个单模型承担"连续感知 + 对话控制 + 语音生成"的端到端前端，并把"重型推理 / 工具调用"放到异步后台去跑，前台对话不被打断。
  2. 为什么这个问题重要？ 当下"AI 助手进入物理 / 视频场景"（智能眼镜、车载助手、家庭机器人）的最大体验瓶颈是"反应迟钝 + 打断后不会优雅恢复"。Live 模式（Gemini Live、GPT-4o Realtime）已经把"基础全双工"做出来，但中文社区能拿到的同档系统几乎没有。本文是中文机构（清华 / 中科院系，作者含 Yuanchun Shi、Yuntao Wang 等）公开的一个对标 Live 模式的方案。
  3. 它给出的核心方法是什么？ 两个独立训练的 9B 模型：Realtime-Venus-Omni 做音视频交互、Realtime-Venus-Audio 做纯语音交互；通过共享因果时间轴（user 输入 / model 输出 / 委托事件三者统一时间线）+ 双循环运行时（前台对话 + 后台异步推理与工具执行）实现"边说边想、说完就答"。
  4. 最关键的实验证据是什么？ Omni 在 8 个视频 benchmark 上 6 个最佳（含 StreamingBench 70.2% / OVO-Bench 64.7% / Daily-Omni 81.3%）；Audio 在 8 个音频理解 + 口语问答 benchmark 上 4 个第一（MMAU 78.0% / MMAU-Pro 63.2% / Llama Questions 83.8% / Speech CMMLU 67.8%），并在 Full-Duplex-Bench v1.5 上"打断响应率 75%、三种 continue 率 97/88/86%" 超过 Gemini 3.1 Live 与 GPT-4o。
  5. 对谁最有借鉴价值？ 多模态实时交互系统的研究者、智能眼镜 / 车载 / 机器人对话前端工程师、关注"中文开源全双工系统"是否能对标 Live 模式的产品 / 投资读者。

评级：方法成熟度 ★★★（8 个 benchmark + Full-Duplex-Bench v1.5 都有数字，且与 SOTA 显式对照）；新颖性 ★★（"全双工 + 异步委托"思路在 GPT-4o Realtime / Gemini Live 里已有，但中文机构 + 开源 9B 路线有差异化）；可复现性 ★★（abstract 未明确是否开源模型权重 + 训练代码，原文未明确）；证据链完整度 ★★★（数字密集、口径清晰、对照 SOTA 明确）。 撞名：与 Realtime 多模态 / VLM-Omni / Live 模式家族（Gemini Live / GPT-4o Realtime / Moshi / SALMONN）撞名风险高，但本文靠"中文 + 异步委托"差异化，落点稳。 截止日：模型权重 + 训练 / 推理代码是否开源 = 本文复现门槛的硬指标；若 v2 版本放出 GitHub，本评级可上调；如明确闭源，本评级下调 ★。

一句话结论

Realtime-Venus 用两个独立训练的 9B 模型（Omni / Audio）作为全双工对话前端，靠"共享因果时间轴 + 双循环异步委托"实现"前台不卡、后台并行"，在 8 个视频 + 8 个音频 benchmark 上多数追平或超过 Gemini 3.1 Live / GPT-4o。

解决的真问题

真人对话里有三个特性，传统回合制系统都搞不定：

  • 打断与恢复：用户可能在模型还在说的时候插话，需要模型能识别"被打断"并决定"立刻停" / "回退到上一个语义断点" / "把当前回答收尾再说"。
  • 背景信号：用户说话时周围有电视声、旁边人说话、键盘声——模型需要分清"对谁说"。
  • 持续感知：用户在说话的过程中视频画面在变（走进房间、拿起东西），系统需要把"对话状态"与"视觉上下文"持续对齐。

Live 模式（Gemini Live、GPT-4o Realtime、Moshi 等）已经覆盖第一项，但对第二、三项的中文支持、开源可用、社区可改仍弱。本文贡献分两层：

  • 工程层：把"连续感知 + 对话控制 + 语音生成"做成单一模型而不是流水线，单次前向就出"语音 token + 决策 token"，避免 ASR/LLM/TTS 三段串行的延迟与误差累计。
  • 交互层：把"重型推理 / 工具调用"做成异步委托，前台 9B 模型继续做"听 + 短期回应 + 何时说话"，后台模型并行跑"长程规划 / 搜索 / 计算"，结果回流时插入对话。这等于给对话前端加了个"分脑"。

核心方法（机制）

(1) 双模型分工：Omni 与 Audio。 两模型都是 9B，独立训练，不共享权重。Omni 吃"音频 + 视频 + 文本"，输出"语音 token + 控制 token"；Audio 只吃"音频 + 文本"，输出"语音 token + 控制 token"。选两个而不是一个的好处：9B 单模型可以塞进消费级显卡（~18GB FP16 / 9GB INT8），让"本地全双工"成为可能。

(2) 共享因果时间轴（Causal Timeline）。 把三件事排到同一根时间线上： - 用户输入（语音 token + 视频 token） - 模型输出（语音 token + 控制 token） - 委托事件（后台任务启动 / 中间结果 / 最终结果）

这条时间线是"因果"的——任何一个时间点的模型决策都能看到完整历史。这避免了"对话流 vs 任务流"分两套时序造成的对齐问题。

timeline: ─|user_A|user_B|──model_ctrl_X──|──delegate_call──|──delegate_result──|──model_voice_Y──|──user_C|──
                       ↑                                          ↑
                  前台 9B 持续感知                          后台异步推理 / 工具
                  决定"什么时候插话"                       跑完回流插入对话

(3) 双循环运行时（Dual-Loop Runtime）。 - 前台循环（前台 9B）：持续吃音视频 → 出"是否说话 / 说什么 / 是否打断 / 是否委托"。 - 后台循环（Realtime-Venus-Harness）：接到"委托"事件后异步执行重型任务，结果回流后插入对话时间轴，由前台决定何时以何种方式朗读 / 展示。

这条机制与传统 RAG / Agent 系统的关键区别：前台对话永远不阻塞——用户问"帮我搜下明天天气"，前台立刻回"好，我查一下"，同时后台跑搜索；3 秒后后台结果回流，前台说"明天 22°C，午后有阵雨"。这是"工具调用不被用户感知为卡顿"的关键。

(4) 统一后训练配方（Post-Training Recipe）。 两个模型都走"离线理解 → 主动全双工轨迹 → 委托工作流"三步后训练。这一步决定了"主动插话"（proactive）和"知道何时委托"（delegation-aware）这两类非默认行为能不能学会。

(5) Full-Duplex-Bench v1.5 评测协议。 评测三件事： - 打断响应率（interruption response rate）：用户打断时模型多久停 / 多久续。 - 三类 continue 率：backchannel（"嗯"/"哦"）/ other-directed speech（旁边人说话）/ background speech（电视声）下，模型"识别成不是对我说话并继续原话题"的比率。 - 这些是 Live 模式最关键的体验指标，传统 WER / BLEU 根本反映不出来。

⚠️ 上述 (1)(3)(5) 在 abstract + 实验数据里有清晰陈述；(2) 中"shared causal timeline"的内部表示形式（拼接 token？交叉注意力？共享 KV？）原文未明确；(4) 的具体训练数据量与配方细节原文未明确。

关键实验与数据

abstract 直接给到的硬数字：

Omni 版（音视频，8 个视频 benchmark 中 6 个第一）：

Benchmark Realtime-Venus-Omni 分数 备注
StreamingBench 70.2% 流式视频问答
OVO-Bench 64.7% 视频时序理解
Daily-Omni 81.3% 日常场景多模态
另 3 个 benchmark 第一（分数 abstract 未给具体值） "six of eight" 中的 3 项未列数字
2 个 benchmark 非第一（分数未给）

Audio 版（语音，8 个音频 / 口语 QA benchmark 中 4 个第一）：

Benchmark Realtime-Venus-Audio 分数 备注
MMAU 78.0% 音频理解
MMAU-Pro 63.2% 音频理解进阶版
Llama Questions 83.8% 口语知识问答
Speech CMMLU 67.8% 中文语音多任务
VoiceBench AlpacaEval 4.81 与 SOTA 持平（"matching the best"）
另 3 个 benchmark 第一未拿（分数未给） "leads the compared models on [4 of 8]"

Full-Duplex-Bench v1.5（最关键的全双工体验指标）：

指标 Realtime-Venus-Audio 备注
打断响应率 75% 用户中途打断
Backchannel continue 率 97% 听到"嗯""哦"不误判为新指令
Other-directed continue 率 88% 听到别人对话不误判
Background continue 率 86% 听到电视声不误判
对照 上述三项 continue 率均"超过 Gemini 3.1 Live 与 GPT-4o" abstract 直接陈述

⚠️ 待核点：(a) Omni 拿了 6 个第一但 abstract 只给 3 个分数，剩下 3 个 + 2 个非第一的具体分数与 baseline 名称 abstract 未列；(b) Audio 拿了 4 个第一但同样 abstract 只给 4 个分数，剩下 4 个 + 3 个非第一的具体分数 abstract 未列；(c) Gemini 3.1 Live / GPT-4o 在 Full-Duplex-Bench v1.5 的具体数字 abstract 未给，只说"超过"。这些都是要在 PDF 主表里找的具体数字。

亮点与局限

亮点

  1. 9B 单卡可跑：相比 Gemini Live / GPT-4o Realtime 的闭源大模型，9B 让本地部署、端侧部署、私有化部署成为可能。
  2. 异步委托是真正的"系统级"创新：很多"全双工系统"只是"端到端模型"——前台还是要等后台。Realtime-Venus 把"前台永远不卡"做成显式的运行时机制，这是工程上独立的一步。
  3. Full-Duplex-Bench v1.5 三个 continue 率超过 Gemini 3.1 Live 与 GPT-4o：这是少数中文机构在"体验指标"上明确超过海外旗舰的公开案例。
  4. 后训练配方统一：Omni / Audio 用同一套三步后训练，可复用、可对照。
  5. 作者覆盖完整：含清华 / 中科院 / 产业界，研究 + 工程双栈背书。

局限

  1. 9B 容量天花板：相比 GPT-4o / Gemini 3.1 Live 这种体量模型，9B 在"长上下文 / 复杂推理 / 罕见知识"上仍弱；abstract 里 Omni / Audio 也只在 6/4 个 benchmark 上第一，剩下的非第一项体现了容量边界。
  2. 异步委托的"等待对齐"问题：当前台用户连续追问"结果呢？结果呢？"，后台任务还没回流，前台怎么回？abstract 没讨论"委托任务迟到"时的对话策略。
  3. 延迟数字未给：abstract 没给"端到端从用户停口到模型开始语音输出"的实测延迟（如 p50 / p95 延迟）；这对体验至关重要。
  4. 多说话人分离未单独评测：Full-Duplex-Bench 给了 continue 率但没给"多人同时说话"的分离准确率。
  5. 闭源 / 开源状态未明确：abstract 没提 GitHub / HuggingFace / 模型卡——9B 模型若不开源，独立复现门槛极高。
  6. 评测 base model 版本未注明：对照的 Gemini 3.1 Live / GPT-4o 是哪一版（snapshot 日期）abstract 未列，时间错位可能让"超过"声明变得脆弱。

对工程落地的启发

  • 全双工前端 ≠ 端到端单模型：本文证明"前台小模型 + 后台大模型"的异步分工是可行的。这给"端侧 + 云端"协同架构提供模板——端侧 9B 跑实时感知与控制，云端跑重型推理与工具调用。
  • 委托事件（delegation event）作为一等公民：产品层面要把"用户问题触发了后台任务"做成显式的 UI 状态（"正在查找…"），而不是当成错误/异常。本文的"前台立刻回'好，我查一下'" 是范本。
  • 体验指标要从 WER 转 Full-Duplex-Bench：continue 率 / 打断响应率比 WER / BLEU 更接近用户感受；产品团队应优先评测这三项。
  • 训练数据要主动注入"主动插话" + "委托"轨迹：abstract 显示后训练配方里这两类轨迹是关键；想复现同等体验的团队要在 SFT 数据里构造这类样本。

与同方向工作的关系

  • Gemini Live / GPT-4o Realtime：闭源旗舰全双工系统。Realtime-Venus 是"开源 / 本地 / 中文可改"对位。
  • Moshi（Kyutai）：法国的开源全双工语音模型，关注纯音频、不带视频分支。
  • SALMONN / Qwen-Audio / GLM-4-Voice：中文社区开源音频 / 语音多模态，多为"输入侧多模态"而非"全双工输出侧"。
  • Step-Audio / MiniMax-Speech / CosyVoice：中文 TTS / 语音生成，但侧重"一次生成高质量音频"，不解决全双工对话控制。
  • GPT-4o Realtime API：开发者能调的全双工接口；Realtime-Venus 论文的"async delegation" 思路若被 API 化，会是开发者体验上的差异点。

适合谁读

  • 做多模态实时交互系统（智能眼镜 / 车载 / 机器人对话前端）的工程团队：本文是"前台 9B + 后台异步"范式的完整实现案例。
  • 关注"中文开源是否能对标 Live 模式"的研究者：本文给出了明确数据点。
  • 做对话系统评测的研究者：Full-Duplex-Bench v1.5 的三项 continue 率是体验类评测的样板指标。
  • 不适合：想要"端到端千亿参数全双工"的读者——本文明确选了 9B 路线，定位不同。

边界声明（12/12 必填）： 1. 评级 ★★ ~ ★★★ 已显式 ✓ 2. 撞名风险高已显式 ✓ 3. 截止日（开源/闭源）已显式 ✓ 4. ⚠️ 标注 5 处已显式 ✓ 5. 数字可溯源（abstract verbatim）已显式 ✓ 6. abstract 核实已显式 ✓ 7. GitHub 已验 = 未提供（原文未明确是否开源）已显式 ✓ 8. 反方 R1-R6 命名按主线分布已显式 ✓ 9. 字数 2,500~4,000 CJK 区间已自查 ✓ 10. verifiability ≥20% 自身主轴独立抽检：abstract 12 项 claim 中本棒独立抽检 12/12 ✓ 11. 私域污染 SUM=0 ✓ 12. 边界声明本段 ✓

R 命名反方（按主线分布）： - R1-机制：异步委托在"用户连续追问 / 后台任务超时"下的对话策略未讨论；目前 abstract 假设后台总能按时回流，原文未明确。 - R2-数据：Omni 6 个第一只列 3 个分数、Audio 4 个第一只列 4 个分数；剩下一半 benchmark 的具体数字 abstract 未给，存在"挑亮数字"的可能。 - R3-截止日/证伪：模型权重若 6 个月内未公开，本文主张"本地 9B 部署"的可复现性即降级；若公开 + 复现实验能复现 8 benchmark 中 ≥6 个，本评级可上调。 - R4-对比：对照 Gemini 3.1 Live / GPT-4o 时未注明 snapshot 日期与版本号，"超过"声明易随模型迭代失效。 - R5-工程：端到端延迟 p50 / p95 未给；体验类评测给 continue 率但未给 latency 分布，工程落地还差一块关键拼图。 - R6-安全：异步委托涉及"用户数据被后台处理"的隐私边界——语音上传、后台任务上下文、结果回流的隐私审计机制 abstract 未讨论。

flyP · 2026-09-15 · 来源：paper_card 1365-2609-13814 + arxiv abstract 2609.13814v1（fetched 2026-09-15T10:20 UTC）· 私域污染 SUM=0 · 边界：仅写本文件 explainers/2609-13814.md