它解决了什么问题

过去一年，实时语音交互的闭源方案接连出现（官方点名的有 TML-Interaction-Small、SeedRealtime、Qwen-Omni-Realtime），共同短板是：要么只能轮流说话，要么在需要调用外部能力时被迫「静音等待」。蚂蚁 AI 安全实验室与清华大学人机交互实验室的解法是开放权重的 Realtime-Venus，把全双工交互与后台任务委托一起交给开发者，支持自行部署、定制与扩展。

两款模型与一套运行时

  • Realtime-Venus-Omni：9B 音视频模型，持续看与听，判断要不要、什么时候回应，在同一条因果时间线上生成文本与语音，支持主动交互、语义级打断处理与免训练的长视频记忆。
  • Realtime-Venus-Audio：同一流式底座上的音频档，做音频理解与语音对话，输出文本或语音。
  • Realtime-Venus-Harness：异步运行时。模型在流内发出委托请求，Harness 在后台执行外部任务并把结果送回对话，前台的对话不被阻塞。

规格上两款均为 9B、BF16 权重、上下文 40960 tokens，底座为 MiniCPM-o 4.5 / Omni-Flow，视觉编码器 SigLIP2（Audio 档推理时不用），音频编码器 Whisper-Medium，语言主干 Qwen3-8B，语音用离散 S3 token 加流式 flow-matching 解码器生成。部署需要 Python 3.10、CUDA 与 FFmpeg。

公开的评测数字

  • Omni：在评估的在线模型中拿下 8 项视频基准里的 6 项最高分，包括 StreamingBench 70.2%、OVO-Bench 64.7%、Daily-Omni 81.3%。
  • Audio：在 8 项音频理解与口语问答基准上领先，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%；在附和、第三方说话、背景人声三种情形下的「继续说下去」比例分别为 97%、88%、86%，三项均超过 Gemini 3.1 Live 与 GPT-4o。
  • 委托判断：自建的 Delegate Benchmark 上路由准确率 Omni 75.93%、Audio 68.89%——这个分数只衡量「该不该委托」，不衡量任务本身成不成功。
  • 完整任务：两款模型的 Pass@1 分别是 43.0% 与 42.0%，官方明确说参数准确性与多步执行仍有提升空间。

落地时该关注什么

  1. 先把「沉默窗口」量出来。全双工的意义在于用户说完之后不必等，这个时延是可以直接测的指标，也是它相对轮流说话方案最实在的差异。
  2. 区分「会接话」与「能办事」。43% 的完整任务成功率意味着端到端自动化还不现实，更稳的做法是让模型负责判断与对话、把真正的执行交给确定性流程。
  3. 长视频有个坑要提前处理：需要在导入 minicpmo.utils 之前设置 MAX_NUM_FRAMES，否则超过 64 秒的视频会被截断到默认帧上限。
把工具调用从对话的关键路径上摘出去——这个架构选择比任何单项分数都更影响真实体验。