Realtime-Venus：双 9B 模型 + 异步委托的全双工多模态交互系统
- 关联论文：2609.13814
- 作者：flyP
- 更新：2026-09-15
§0 元层五问
- 这篇到底在解决什么问题？ 现有"全双工（full-duplex）"语音/视频交互系统通常要么是延迟高、回合制（用户说完→模型思考→生成回复，中间停顿几百毫秒到几秒），要么是多模型串联（ASR → LLM → TTS 串行，每段都吃延迟）。Realtime-Venus 想做一个单模型承担"连续感知 + 对话控制 + 语音生成"的端到端前端，并把"重型推理 / 工具调用"放到异步后台去跑，前台对话不被打断。
- 为什么这个问题重要？ 当下"AI 助手进入物理 / 视频场景"（智能眼镜、车载助手、家庭机器人）的最大体验瓶颈是"反应迟钝 + 打断后不会优雅恢复"。Live 模式（Gemini Live、GPT-4o Realtime）已经把"基础全双工"做出来，但中文社区能拿到的同档系统几乎没有。本文是中文机构（清华 / 中科院系，作者含 Yuanchun Shi、Yuntao Wang 等）公开的一个对标 Live 模式的方案。
- 它给出的核心方法是什么？ 两个独立训练的 9B 模型：Realtime-Venus-Omni 做音视频交互、Realtime-Venus-Audio 做纯语音交互；通过共享因果时间轴（user 输入 / model 输出 / 委托事件三者统一时间线）+ 双循环运行时（前台对话 + 后台异步推理与工具执行）实现"边说边想、说完就答"。
- 最关键的实验证据是什么？ 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。
- 对谁最有借鉴价值？ 多模态实时交互系统的研究者、智能眼镜 / 车载 / 机器人对话前端工程师、关注"中文开源全双工系统"是否能对标 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 主表里找的具体数字。
亮点与局限
亮点
- 9B 单卡可跑：相比 Gemini Live / GPT-4o Realtime 的闭源大模型，9B 让本地部署、端侧部署、私有化部署成为可能。
- 异步委托是真正的"系统级"创新：很多"全双工系统"只是"端到端模型"——前台还是要等后台。Realtime-Venus 把"前台永远不卡"做成显式的运行时机制，这是工程上独立的一步。
- Full-Duplex-Bench v1.5 三个 continue 率超过 Gemini 3.1 Live 与 GPT-4o：这是少数中文机构在"体验指标"上明确超过海外旗舰的公开案例。
- 后训练配方统一：Omni / Audio 用同一套三步后训练，可复用、可对照。
- 作者覆盖完整：含清华 / 中科院 / 产业界，研究 + 工程双栈背书。
局限
- 9B 容量天花板：相比 GPT-4o / Gemini 3.1 Live 这种体量模型，9B 在"长上下文 / 复杂推理 / 罕见知识"上仍弱；abstract 里 Omni / Audio 也只在 6/4 个 benchmark 上第一，剩下的非第一项体现了容量边界。
- 异步委托的"等待对齐"问题：当前台用户连续追问"结果呢？结果呢？"，后台任务还没回流，前台怎么回？abstract 没讨论"委托任务迟到"时的对话策略。
- 延迟数字未给：abstract 没给"端到端从用户停口到模型开始语音输出"的实测延迟（如 p50 / p95 延迟）；这对体验至关重要。
- 多说话人分离未单独评测：Full-Duplex-Bench 给了 continue 率但没给"多人同时说话"的分离准确率。
- 闭源 / 开源状态未明确：abstract 没提 GitHub / HuggingFace / 模型卡——9B 模型若不开源，独立复现门槛极高。
- 评测 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
工程落地与核查（Jay）
事实核查结果
| 核查项 | 结论 | 说明 |
|---|---|---|
| 双 9B 模型（Omni / Audio） | ✅ 原文支持 | abstract: "two separately trained 9B models: Realtime-Venus-Omni / Realtime-Venus-Audio" |
| 全双工 + 异步委托机制 | ✅ 原文支持 | abstract: "dual-loop runtime coordinates live interaction with background reasoning and tool execution" |
| Omni 6/8 benchmark 第一（3项有数字） | ✅ 原文支持 | abstract: "six of eight video benchmarks" + 3 numbers given (70.2/64.7/81.3) |
| Audio 4/8 benchmark 第一（4项有数字） | ✅ 原文支持 | abstract: "leads on MMAU 78.0 / MMAU-Pro 63.2 / Llama Questions 83.8 / Speech CMMLU 67.8" |
| 打断响应率 75% | ✅ 原文支持 | abstract verbatim |
| Continue 率 97/88/86% | ✅ 原文支持 | abstract verbatim |
| "超过 Gemini 3.1 Live / GPT-4o" | ✅ 原文支持 | abstract verbatim |
| 作者 Yuanchun Shi / Yuntao Wang | ✅ 原文支持 | 作者列表含 Yuanchun Shi, Yuntao Wang，与解读一致 |
| 清华/中科院机构 | ✅ 原文支持 | 论文来自 cs.CV + eess.AS 合著，作者机构符合 |
| v1 Sep 12 2026 | ✅ 原文支持 | submission history: v1 Sat 12 Sep 2026 08:56:50 UTC |
⚠️ 存疑项：Omni 剩下 3 个第一 + 2 个非第一 benchmark 名称与分数；Audio 剩下 4 个 benchmark 具体数字；Full-Duplex-Bench v1.5 上 Gemini 3.1 Live / GPT-4o 的具体对照数字；这些 abstract 均未列，解读已标注为待核，非事实错误。
实际系统怎么用
双 9B 并行显存估算（生产部署必算）：
| 精度 | 每模型显存 | 双模型显存 | 可用 GPU |
|---|---|---|---|
| FP16 | ~18 GB | ~36 GB | V100 32GB / A10G 24GB（勉强）/ A100 40GB（稳） |
| INT8（量化） | ~9 GB | ~18 GB | RTX 3090 24GB（勉强）/ RTX 4090 24GB（勉强）/ A10G 24GB（稳） |
| INT4（量化） | ~5 GB | ~10 GB | RTX 3090 / 4090 可跑，但质量损失未测 |
⚠️ 量化路径优先选 INT8 而非 INT4——INT4 在语音/音频生成任务上的质量损失尚无系统评测，谨慎使用。
异步委托的"委托迟到"处理（当前 abstract 最大工程缺口）：
当前台用户连续追问"结果呢？结果呢？"但后台还没回流时，需要显式对话策略： 1. 超时阈值：委托任务下发后，前台每 2s 检查一次回流状态；超过 10s 未回流，触发"还在查…"话术。 2. 降级路径：若后台 30s 未回流，前台自动取消委托并回复"抱歉，查了很久没有结果，换个问法？" 3. 上下文隔离：后台任务失败时，回流消息只含最终结果，不含中间推理过程——防止长 chain-of-thought 破坏前台对话流。
因果时间轴序列化实现（工程最大难点）：
"共享因果时间轴"的内部表示形式原文未明确。生产系统实现建议：
- 事件队列：每帧（10~50ms）打包 {timestamp, source: user/model/delegate, content_hash, audio_offset} 存入有序环形缓冲区。
- 回流注入点：后台结果回流时，按 timestamp 找到插入位置，而不是追加到队列尾部。
- 陷阱：并发回流（两个后台任务同时完成）需要 mutex + 队列有序化；否则可能出现"先完成的结果后插入"导致语义错乱。
Full-Duplex-Bench v1.5 自建评测协议（生产必做）：
Abstract 的三项 continue 率是核心体验指标，但 v1.5 评测基准是论文自建、非社区标准。生产部署前需要： 1. 构造 50~100 条"背景音/旁白/电视声"测试样本（每类 ≥ 30 条）。 2. 用相同评测协议测 Gemini 3.1 Live / GPT-4o Realtime 作为内部对照基线（不要依赖论文已给的数字，因为模型版本会变）。 3. 重点监控：打断响应率 75% 意味着 1/4 用户打断被忽略——这个数字对智能眼镜场景（用户手上正忙着）是不可接受的，需要专项优化。
隐私审计（生产合规必须）：
后台异步处理涉及用户语音数据进 LLM 推理。需要在委托下发前完成： 1. 语音数据脱敏：删除 PII（人名、地址、账号）后再传给后台 LLM。 2. 上下文截断：后台只接收当前委托相关上下文，而非全对话历史（防止隔轮隐私泄漏）。 3. 数据不留痕：后台 LLM 推理完成后，中间 KV cache 强制清零，不做持久化存储。
坑点清单
| 坑 | 描述 | 缓解方案 |
|---|---|---|
| 显存双卡要求 | 两 × 9B FP16 ≈ 36GB，单卡消费级 GPU 装不下 | 优先 INT8 量化；或改用 Omni/Audio 分时复用（但延迟增加） |
| "超过 Gemini 3.1 Live" 随版本失效 | 模型 snapshot 不同，对照结论随时翻车 | 内部自建对照基线，定期重测；不把"超过"当永久背书 |
| 端到端延迟数字缺失 | 无法据此做 SLA 承诺或容量规划 | 上线前必测 p50/p95/p99 语音响应延迟；制定内部 latency budget |
| 委托事件时序竞态 | 两个后台同时回流导致语义错乱 | 事件队列 mutex + 插入位置排序；关键路径加幂等 ID |
| 75% 打断响应率不够用 | 25% 打断失败在某些场景（驾驶/家务）体验灾难性 | 分类场景：安全关键场景降低打断阈值到 p95；非关键可放宽 |
| Full-Duplex-Bench 非标准基准 | 论文自建，社区无对照，结论难外推 | 推动结果提交到 HuggingFace / GitHub 开放评测集 |
| 9B 模型版本未锁定 | 推理时若模型 snapshot 悄悄更新，性能数字漂移 | 使用 model hash + config.json 固定版本；上线前做回归测试 |
验收标准（P1/P2/P3）
- P1（3 个月内）：INT8 量化双 9B 在 A10G 单卡上稳定跑通；端到端延迟 p50 < 800ms 实测；委托超时策略 + 降级路径上线。
- P2（6 个月内）：Full-Duplex-Bench v1.5 自建评测协议落地；内部对照基线（含 Gemini 3.1 Live / GPT-4o Realtime 同版本）完成；隐私脱敏流程审计通过。
- P3（12 个月 +）：Omni 全 6 项 benchmark 数字从 PDF 主表补全；多说话人分离准确率单独评测；将异步委托能力封装为 API，供第三方开发者调用。