Realtime-Venus：蚂蚁集团的全双工 9B 未举行发布会便已上线

2026年9月12日，arXiv 上出现了一篇技术报告，介绍 Realtime-Venus——一个由两个分别训练的 9B 模型构建的全双工交互系统，其中 Realtime-Venus-Omni 用于音视频交互，Realtime-Venus-Audio 用于语音交互——署名为蚂蚁集团 Venus Team 与清华大学合作。几天之内，Hugging Face 上位于inclusionAI/Realtime-Venus之下的一个 Apache-2.0 仓库就托管了两个检查点，可下载为 BF16 safetensors，同时还有一个项目页面和配套的 GitHub 仓库。没有出现的是真正值得注意的部分：没有发布公告，没有产品页面，没有 API，没有价目表，蚂蚁集团自己的渠道上也没有任何东西宣布其中任何一项的存在。这是一次除公告之外什么都发布的发布，这使得区分已确立的事实与各种声称成了全部工作。

磁盘上实际上有什么

该仓库并非空壳。它包含两个模型目录，每个目录都带有分片的 safetensors 权重、一个配置文件，以及模型卡指示你使用 trust_remote_code=True 加载的自定义 Hugging Face Transformers 代码。此外还有一个依赖需求文件、一个存放 token 到波形资源与参考语音的 assets 文件夹，以及顶层的 Apache-2.0 许可证。模型卡记录了在 Python 3.10 搭配 CUDA 与 FFmpeg 环境下的安装方式，并同时提供了 ModelScope 镜像和 Hugging Face 两条下载路径。权重是真实存在的，代码就在那里，今天你就能把它下载下来，没有任何阻碍。

两处缺失与内容本身同样具有信息量。第一处是，该仓库明确表示它未被任何推理提供商部署——没有托管端点，没有无服务器选项，也没有任何第三方平台承载它。第二处是，下载量完全未被追踪，这意味着没有公开信号表明有多少人拉取过它。在 Hugging Face 上，一个模型可能看起来被采用或被忽视；而这个模型却无法以这种方式解读。

两个检查点，以及它们之间的区别

两者都是 9B，都共享同一种流式骨干，而它们之间的区别在于它们能感知到什么。

• Realtime-Venus-Omni — 音视频检查点。用于流式帧的 SigLIP2 视觉编码器、Whisper-Medium 音频编码器，以及 Qwen3-8B 语言主干。接受视频或图像、音频和文本；返回文本，并可选返回语音波形。

• Realtime-Venus-Audio — 相同的主干网络，但在加载时关闭了视觉。音频和文本输入，文本和语音输出。它适用于摄像头无关、且你希望更小内存占用和更简单路径的场景。

• 共享规格——两者均为 40,960 token 上下文，均使用 BF16 权重，语音生成为离散的 S3 token，由流式流匹配解码器解码，而非在末端外挂一个单独的文本转语音模型。

• 血统 —— 模型卡指出，Omni 检查点改编自 MiniCPM-o 4.5，即 OpenBMB 于 2026 年早些时候开源的 9B 全模态模型。这不是一个无关紧要的脚注。这意味着蚂蚁集团的贡献在于后训练、运行时和委托设计，这些是叠加在他人流式骨干之上的，这与“一个新的 9B 全模态模型”是不同且更具体的说法。

唯一真正新颖的想法：将委托作为一等流事件

2026年的每个全双工系统都必须解决同一个矛盾。对话控制以毫秒到一秒的粒度运行。工具调用、检索和复杂推理则需要数秒到数十秒。一个停下来思考的模型就不再是全双工；一个从不暂停的模型则无法使用工具。

Realtime-Venus 通过双循环运行时来给出响应。交互循环以固定的一秒时间片运行，持续摄入音频与视频特征、更新对话状态，并决定是聆听还是发言，同时流式输出文本与对齐的语音。当后台工作正在进行时，它不会暂停。第二个循环是一个调度器，论文中称之为 Realtime-Venus-Harness：当前端判断某项任务超出其内联处理能力时，它会通过嵌入自身隐藏序列中的私有标记发出异步委派，随后由该 harness 在后台执行该任务，并将结果重新整合进正在进行的对话中。

让这份设计不只是一张示意图的细节，是论文中所称的因果任务捕获——被委派的任务是在对话状态的一份隔离快照上执行的，因此长时间运行的后台任务不会因为对话在其运行期间继续推进而遭到破坏。正是这种失效模式，让大多数“委派出去、继续对话”的设计在实践中栽了跟头，而这也是这份报告中最有意思的一点。

框架并不在权重里。它作为独立组件存在于 GitHub 仓库中，这意味着，让该架构与众不同的那部分，正是你必须自己组装并信任的部分。

这些数字，以及它们究竟属于谁

下文的每一项数字都来自技术报告和模型卡。其中没有任何一项被作者之外的任何人复现过，没有第三方发布过评估，也没有可供对照核验的排行榜条目。请把它们当作作者自己给出的测量结果来看待。

• 视频基准测试，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% 的用户打断作出响应，在反馈信号下延续率为 97%，在指向他人的言语下为 88%，在背景语音下为 86%。报告称，在这三项延续指标上，它均超过了 Gemini 3.1 Live 和 GPT-4o。

最值得停下来细想的，是 Daily-Omni 的那个数字。这个检查点所改编自的模型 MiniCPM-o 4.5，在同一基准测试中报告了 80.2。Realtime-Venus-Omni 报告的是 81.3。如果这两个数字都站得住脚，那么大规模后训练与运行时投入所带来的提升，在这个基础模型本已擅长的基准上大约只有一个点——对这类工作来说，这是一个现实的结果，也远不如“八项中六项最佳”这样的标题那样具有戏剧性。

什么尚未确立？

未解决的问题清单比已解决的问题清单更长，这就是一个问世仅六天的模型的真实状态。

• 不存在独立的评估。既不是竞技场排名，也不是第三方复现，更没有哪怕一个外部团体公布过任何数字。

• 未给出以毫秒计的延迟数字。报告描述的是 1 秒的交互节奏，卡片中记录的是每秒的流式调用，但并未公布首音频时间（time-to-first-audio）这一数值，而这恰恰是该品类实际购买时所看重的指标。

• 没有 API，没有价格，也没有任何关于二者即将推出的声明。这究竟是一款蓄势待发的产品，还是一个将永远停留在下载形式的研究产物，目前确实无从知晓。

• 厂商未声明任何意图。没有公告并不能证明存在低调发布的策略；它同样符合仅为论文发布代码库、别无其他的情况。

• 测试框架缺乏生产环境的验证。它是架构中承重的组件，却是文档记录最少的。

为什么安静路线总是发生

这是今年第二次，蚂蚁集团的模型工作通过代码仓库而非正式发布进入公众视野。UI-Venus-2-9B 是该实验室的 GUI 智能体，于 2026 年 8 月底出现在 Hugging Face 上，既无论文、项目页面，也没有公告——此后才有一份报告跟进。Realtime-Venus 的到来顺序则相反：报告先行，代码仓库同步出现，公告仍未公布。

这种现象并非蚂蚁集团独有。尤其是中国的实验室，一直在将研究成果和面向消费者的部署推向外界，却把面向开发者的公告留到以后，或者干脆跳过。对任何关注这一领域的人来说，这都很不方便，因为通常的信号——发布文章、价格表、文档站点——恰恰是缺失的那部分。如今，制品本身就是公告，仔细阅读它是了解实际发布了什么的唯一途径。

如果你想运行它

对于这么新的发布版本来说，这张卡异常实用。加载是标准流程：AutoModel.from_pretrained在本地检查点目录上，信任远程代码，采用 SDPA 注意力与 bfloat16。全双工流式传输通过一次调用进入，该调用会将模型切换到双工模式；之后，文档所述的循环就是一秒的 streaming_prefill，随后是 streaming_generate，如此重复。长视频记忆通过一个设为四十的 memory-minutes 参数启用，并被描述为无需训练，这对于一项通常需要微调的能力来说很值得注意。有两项注意事项是文档中写明的，而不是需要自行发现的：一个帧数上限，除非在导入实用工具之前提高某个常量，否则它会静默截断长视频；以及将非拉丁字幕渲染到双工视频时对 CJK 字体的要求。

这张卡没有提供给你的，是一个硬件门槛。一个采用 BF16 的 9B 模型，在还没算上任何激活内存之前，就已有约 18 GB 的权重；这使实时双工推理只能落在高性能 GPU 上，超出了它所源自的 MiniCPM-o 系列原本部分为之设计的笔记本电脑部署范围。

这里有一道接缝值得点明，因为路由器真正的用武之地正在于此。Realtime-Venus 把它的重活——检索、复杂推理、业务 API 调用——委派给一个后台模型。被委派的那条链路是普通的文本推理，而正是这条链路决定了你的对话前端是有用，还是仅仅流利。OrcaRouter 不含 Realtime-Venus 的任何部分；这里的双工层是一个自托管下载，我们并不提供该服务。它交出去的那部分推理，才是我们覆盖的内容：近 200 个模型，一个密钥即可调用，按供应商标价计费、不加价，上游状态不佳时自动故障转移，一套可将多个模型组合成一次调用的路由 DSL，以及模型融合，用于单个模型的判断力不够的场合。委派这一标记由前端决定；由哪个模型来应答则是一项配置选择，而把这一选择放在权重之外，正是让你无需重新训练任何东西就能更改它的原因。

什么能解决这个问题

有三件事能让 Realtime-Venus 从一篇带有权重的论文，变成任何人都能评估的模型。一个独立团队复现 Full-Duplex-Bench 的续接数值，因为在反馈语下达到 97% 是一个非同寻常的数字，而非同寻常的数字需要第二位读者。一个已公布的延迟数值，因为全双工系统成败取决于首音频时间（time-to-first-audio），而这个系统尚未说明目标。以及测试框架的文档，因为异步委托设计是本次发布中唯一真正全新的部分，而现在它是你能读到、却不容易采用的部分。

在此之前，准确的描述既范围狭窄又平淡无奇，而这正是它值得被记录下来的原因：一次真正的 Apache-2.0 发布，包含两个 9B 全双工检查点，构建在开放骨干之上，拥有强劲的自报基准，没有独立验证，没有 API，也没有公告。这条线以上的一切都是推断。