论文

Realtime-Venus:一个带异步委托的全双工交互系统

Realtime-Venus:一个带异步委托的全双工交互系统

自然交互需要连续感知与及时响应:语音对话依赖声学与语言线索,视频交互还需将对话锚定在不断演化的视觉语境中。我们提出 Realtime-Venus,一个具备异步委托能力的主动式全双工交互系统,包含两个独立训练的 9B 模型——Realtime-Venus-Omni(音视频交互)与 Realtime-Venus-Audio(语音对话)。 每个模型都是完整的对话前端,通过共享的因果时间线整合连续感知、对话控制与原生语音生成,统一用户输入、模型输出与委托事件。双循环运行时 协调实时交互与后台推理及工具执行:前台交互持续进行,Realtime-Venus-Harness 异步执行任务并回传结果融入当前对话。两个模型采用共同的 post-training 配方,结合离线理解、主动式全双工轨迹与委托工作流。 实验结果如下: - 视频:Realtime-Venus-Omni 在八个视频基准中的六个取得最高分,包括 StreamingBench (70.2%)、OVO-Bench (64.7%)、Daily-Omni (81.3%)。 - 音频:Realtime-Venus-Audio 在 MMAU (78.0%)、MMAU-Pro (63.2%)、Llama Questions (83.8%)、Speech CMMLU (67.8%) 上领先,并追平 VoiceBench AlpacaEval 最佳得分 4.81。 - 全双工:在 Full-Duplex-Bench v1.5 上,它对 75% 的用户打断作出响应,在 backchannels、other-directed speech、background speech 下的延续率分别为 97%、88%、86%,三项指标均超过 Gemini 3.1 Live 与 GPT-4o。

论文精读

TL;DR Realtime-Venus 用两个 9B 模型分别处理音视频与语音,以统一因果时间线和双循环运行时实现主动式全双工对话与后台异步工具执行,在多个视频/音频基准取得最高分,全双工续接率超过 Gemini 3.1 Live 和 GPT-4o。

问题

问题背景

实时多模态交互系统正从“问题-回答”式对话转向持续感知 + 主动响应的全双工模式,同时需要将外部工具执行结果无缝融入对话流。

现有方法局限

  • 感知、对话控制与语音生成分离:传统管线级联 ASR、LLM、TTS,带来高延迟与误差累积;模型若要同时处理视频理解,还要额外接入视觉编码器,缺乏统一因果时间线。
  • 异步工具调用打断对话:现有 agent 在等待工具返回时常常阻塞退出实时模式,无法在用户持续说话时后台执行并稍后插话。
  • 全双工行为不足:公开模型在用户打断、背景语音、其他指向语音等场景下继续说话比例低,且缺乏原生语音生成能力,难以建模重叠语音和回传通道。
  • 训练数据与协议缺失:大多数 post-training 数据仅覆盖单轮理解或离线工具调用,没有 proactive 全双工轨迹和 delegation workflows。

为什么难/重要

  • 实时交互要求毫秒级首包延迟下的多模态流同步,视觉、音频、文本 token 需在共享因果时间线上对齐;全双工要求模型能听、能说、能实时决策是否回应、打断或等待。
  • 异步 delegation 的工程复杂性高:需要 dual-loop runtime 协调前台交互和后台执行,保证任务结果在对话中可追溯、不丢失上下文。
  • 业界对实时多模态 agent(视觉助手、语音助手、远程协作)投入极高,能同时处理音频/视频并原生生成语音的系统仍稀缺,因此该问题被广泛关注。

类比:这类似于自动驾驶中的并行决策——车辆需要在持续感知道路的同时,后台规划路线并随时向驾驶员汇报进展,而不能在规划时暂停对环境的响应。

核心洞察

  • 全双工交互与异步委托被统一到一条共享的因果时间线上,使得模型可以在不中断前台对话的情况下发起后台任务并自然融合结果。相较于传统语音助手将工具调用作为外部回调或独立 turn 处理,Realtime-Venus 把用户输入、模型输出和委托事件都编码进同一序列流,让模型能够自主决定何时委托、何时继续说话、何时重新接入,真正实现‘边说边做’。
  • 系统采用两个独立训练的 9B 模型分别处理音频视觉和纯音频交互,但共享同一套训练配方与运行时抽象。这与当前主流的单一多模态大模型路线不同,其优势在于:针对不同模态特性分别优化模型架构与数据配比,避免跨模态干扰;同时双循环运行时保证了前台实时响应与后台工具执行的解耦,在部署灵活性和推理效率上更适配真实产品环境。
  • 训练数据管线显式地将全双工行为与委托行为耦合构造,通过主动全双工轨迹和委托工作流合成数据,让模型学会在持续对话中处理打断、背景语音和工具调用结果的重融入。该策略解决了大多数对话模型只能被动响应或仅支持简单工具调用的局限,使模型具备主动打断、边听边想、异步执行并自然回归对话的能力。

方法

方法概述

输入:连续的音频流(Realtime-Venus-Audio)或音视频流(Realtime-Venus-Omni),其中包含用户语音、背景语音、回指、打断等真实交互信号。

关键模块:

  • 统一流序列化:将用户输入、模型输出、委派事件等所有交互事件编码到一条共享的 因果时间线 上,确保事件顺序与依赖关系一致,支持全双工实时响应。
  • 训练免费长视频记忆:针对长时视频上下文,采用训练无关的记忆机制,使模型能够跨长时间窗口保持视觉 grounding。
  • 双循环运行时:前台循环负责实时交互,持续处理输入并生成原生语音;后台循环运行 Realtime-Venus-Harness,异步捕获并执行委派任务,完成后将结果重新注入正在进行的对话。
  • Harness 设计:包含因果任务捕获(从对话流中识别可委派意图)、可扩展能力执行(调用外部工具或推理)、对话结果重集成(将工具输出以自然方式融入语音回复)。

训练配方:两个 9B 模型共享同一 post-training recipe,组合离线理解、主动全双工轨迹、委派工作流三类数据,使模型学会何时响应、何时打断、何时委派以及如何整合异步结果。

输出:系统直接生成原生语音回复,无需 ASR/TTS 级联,同时可并行执行工具调用,并在合适时机将结果插入对话。

差异点:与级联式语音助手或纯文本 LLM 相比,本系统将全双工交互与异步工具执行解耦,通过共享因果时间线和双循环运行时保持状态一致,且模型原生生成语音,降低端到端延迟。

行业影响

落地场景

  • 全双工语音助手 可应用于电商直播导购、车载语音交互、远程医疗分诊、企业会议实时助手等。模型原生集成连续视觉/语音感知与原生语音生成,支持用户实时打断与背景语音过滤,适合需要高自然度对话的场景。
  • 异步委托 机制让前台对话不被工具调用卡顿;例如在电商直播中,用户询问某商品库存或优惠券时,后台查询 API,数秒后结果自然融入当前话轮,不打断主播演示。

商业价值

  • 降本:减少人工客服 / 导播 / 助播的重复劳动;全双工打断处理降低无效对话轮次。
  • 体验提升:拟人化响应、连续视频上下文理解、背景语音续说能力(97% / 88% / 86% 的 continuation rates)直接提升用户留存与转化。
  • 增收:在直播带货、在线教育等转化链路中,实时商品信息注入与口语陪练纠错可提高转化率。

与现有产品 / 工作流集成

  • 模型可作为对话前端,替换现有 ASR+LLM+TTS 级联架构,降低延迟与模块间误差。
  • Realtime-Venus-Harness 可作为独立的异步任务执行层,对接企业现有的 API 网关、RAG 检索、数据库查询;通过 WebSocket/流式接口与业务后端通信。
  • 双循环架构 适配微服务部署:前台交互与后台工具执行解耦,便于独立扩缩容与监控。

具体落地用例覆盖电商直播实时导购和在线教育口语陪练;项目提供 GitHub 与 项目主页。

局限

  • - **部署成本与系统复杂度**:系统由两个独立 9B 模型(Realtime-Venus-Omni 与 Realtime-Venus-Audio)组成,实际部署需同时维护两套推理服务,算力与显存开销显著高于单模型方案。论文未提供量化、蒸馏或模型并行等轻量化策略,难以在边缘设备或低延迟生产环境中落地。双循环运行时与 Harness 的异步委派机制进一步增加了工程复杂度,论文未讨论委派任务失败重试、并发冲突解决、状态一致性等关键工程问题,对系统稳定性的评估不足。
  • - **评估覆盖与对比公平性**:视频基准仅列 8 个,全双工基准 v1.5 的指标聚焦于 interruption 响应与 continuation rate,缺乏对对话语义连贯性、任务完成质量、多轮记忆保持的细粒度评测。Delegate Benchmark 的具体规模与设置未在摘录中说明,可能样本量有限。与 Gemini 3.1 Live、GPT-4o 等闭源模型的对比未明确版本、访问接口和推理参数,公平性存疑。此外,未评估混合音频视频场景、多语言、强噪声等真实环境下的鲁棒性。
  • - **训练数据与泛化性**:主动全双工轨迹和委派工作流的数据构造需要大量高质量交互标注,论文虽提供了数据示例和统一流水线,但未公开数据规模、来源及清洗细节。模型可能过拟合特定对话风格或任务类型,跨领域泛化能力未经充分验证。同时,模型基座未说明是否开源,影响可复现性和社区验证;当前 GitHub 仓库 stars 极少,第三方评估尚缺。
论文Ruixiang Zhao2026-09-12原文

相关内容