Realtime-Venus 与 SeedRealtime：两种截然相反的不可用方式

Realtime-Venus 与 SeedRealtime 是同一个 2026 年故事的两半，而它们败在截然相反的考验上。SeedRealtime 是字节跳动原生的音视频全双工模型，于 2026 年 8 月 5 日在豆包 App 内免费上线，触达其开发者口中数以亿计的受众——没有 API、没有模型标识符、没有定价，也没有延迟目标。Realtime-Venus 则是蚂蚁集团 Venus 团队与清华大学推出的两个 9B 检查点，于 2026 年 9 月 12 日以 Apache-2.0 许可发布，附有一份技术报告，却没有任何公告，静静躺在一个任何工程师都能下载、却几乎无人能真正部署的代码仓库里。其中一个，你无法调用。另一个，你能下载下来，然后发现根本没有东西可供你调用它。两者都确实处在这一能力的前沿，而它们也都没有任何一份由其作者之外的人复现过的基准测试。

“你得不到它”的两种说法

值得说得精确一些，因为“不可用”这个说法掩盖了一个真实的差异。

SeedRealtime 的“不可用”更像是一种消费级产品的不可用：它真实存在、运行正常、也有用户，只是大门对开发者紧闭。没有 API，没有费率表，没有文档门户，也没有公布任何相关时间表。字节跳动的上市路径一直是这款应用本身，而这款应用已经足够。作为开发者，你能得到的只是一个可以体验却无法集成的演示。

Realtime-Venus 不可用，其不可用的方式正如一件研究制品不可用的方式：权重是公开的，许可证是宽松的，代码就在那里，却没有人运行它。该代码库没有被任何推理提供商部署，下载量也完全没有被追踪，因此无论是否被采用，都没有公开信号。它对研究者重要的意义上可用，对产品经理重要的意义上不可用。

综合起来，它们勾勒出了这整个类别目前深陷其中的核心问题：真正好用的模型都藏在消费级应用背后，而你能自己运行的模型则根本没有在任何生产环境中落地。

两者都处于真正区分2026年的层级

解读实时领域的一个有用方法是分成三个层次。第一层是半双工语音再外挂视觉——能看见但仍需轮流发言的回合制助手。第二层是音频全双工，没有摄像头，却能同时听和说：ByteDance 自家的 Seeduplex、OpenAI 的 GPT-Live、xAI 的 Grok Voice Think Fast 2.0。第三层是视听全双工，感知与表达持续贯穿视频和音频。

SeedRealtime 是第三层级中首个实现大规模商业化部署的模型。Realtime-Venus 是同一层级的开放权重入局者——视频经由 SigLIP2 编码器处理，音频经由 Whisper-Medium 处理，骨干网络为 Qwen3-8B，并配备一个永不停止感知的一秒交互循环。其模型卡声明，它改编自 MiniCPM-o 4.5，即 OpenBMB 于 2026 年早些时候发布的全模态模型，这意味着 Ant Group 的贡献在于后训练与运行时，而非基础架构。

它们共同之处，也是让它们比纯音频系统高出一筹的地方，在于两者都不会停下来去看。说话时持续的视觉感知，与描述单帧画面是真正不同的能力，而这两款模型都是围绕这一能力构建的。

每一个的数字各值多少

两个模型都没有第三方基准测试。不过，这些证据并不对等，而这一差别很重要。

• SeedRealtime 完全没有公布任何基准测试。字节跳动给出的只是一个说法：根据端到端的人工评估，对话节奏方面的问题——抢话、回应迟缓、被陌生人的噪音触发——相比级联系统大约减少了一半。其底层数据并未公布。

• 前代产品的数据形态相同。据报道，字节跳动于 2026 年 4 月将其纯音频模型 Seeduplex 部署到豆包中，在大规模 A/B 测试中将误响应率和误打断率减半，将端点延迟缩短约 250 毫秒，将过早响应减少 40%，并将通话满意度提升 8.34 分。以上均为厂商报告数据。

• Realtime-Venus 发布了一张表格。其报告声称在八项视频基准测试中的六项上取得了最佳成绩，包括 StreamingBench 70.2、OVO-Bench 64.7 和 Daily-Omni 81.3，并在音频检查点上以 MMAU 78.0、MMAU-Pro 63.2、Llama Questions 83.8 和 Speech CMMLU 67.8 领先。

• 两者均未被复现。已发表却无人核对的表格，与未发表且无人能够核对的 A/B 测试，属于不同类型的未经验证。两者都不是你可以据以做出采购决策的证据。

在 Realtime-Venus 的数字中，唯一值得做的比较，是与它自己的基座相比。MiniCPM-o 4.5 在 Daily-Omni 上报告 80.2；Realtime-Venus-Omni 报告 81.3。在一个该模型本就能处理的基准上，相较它所适配而来的模型取得一个百分点的提升，对于后训练和运行时工作来说是一个合理的结果——而且这比“八项中六项最佳”单看时所表达的主张要小得多。

话轮转换问题，而这正是全双工的用武之地。

全双工并不是一种延迟特性，而是一组行为：知道一段停顿意味着“我正在思考”而不是“我说完了”，能把旁人的交谈与正在和你说话的人区分开，并在对方发出附和信号时保持安静，而不是把“嗯哼”当成打断。

SeedRealtime 的做法是原生地建模对话状态，并彻底去掉外部的语音活动检测器，因此轮次转换是网络内部习得的行为，而不是施加在音频流上的阈值。这正是 Realtime-Venus 所做出的相同架构承诺，两者都针对那些需要单独组件来判断谁在说话的级联系统。

证据的不同之处在于，SeedRealtime 的说法针对的是规模化部署——数亿用户、真实房间、真实噪声——而 Realtime-Venus 的说法针对的是一个基准测试。Realtime-Venus-Audio 的 Full-Duplex-Bench v1.5 结果——对打断的响应率为 75%，在反馈性话语（backchannels）下的延续率为 97%，在面向他人的语音下为 88%，在背景语音下为 86%，在延续性上超过 Gemini 3.1 Live 和 GPT-4o——是这两个模型就此问题发布过的最直接相关的数字。它们也完全是自报的，而在反馈性话语下 97% 的延续率是一个惊人的数字，在任何人将其作为事实引用之前，都值得再找一个人审阅。

每个留下一个构建器的位置

实际的差距不在于质量，而在于报价的形态。

• SeedRealtime — 你可以在豆包中免费体验它，却永远无法集成它。从“这很惊艳”到“这已进入我的产品”之间没有路径。

• Realtime-Venus — 你可以下载它、微调它、在气隙隔离环境中运行它，并检查每一层。代价是两个采用 BF16 的 9B 检查点，每个约十八 GB 的权重，再加上一个持续的每秒流式循环，这意味着一个无论是否有人调用都会计费的 GPU 节点。

• 二者均无托管选项。均无法仅凭一个密钥和一个下午就完成试用。

最后一点正是这两个模型作为一对搭档比作为对手更有用的原因。它们共同表明，这个问题的两半都已解决——能力是有效的，权重也是可以发布的——同时也说明，还没有人把二者结合起来，做成开发者真正能够调用的东西。

有一种变通方案，很多团队都会采用，而它覆盖什么、不覆盖什么，值得说清楚。如果你拿不到语音层，你仍然可以构建负责思考的那部分。Realtime-Venus 会通过异步委派标记，把它昂贵的工作——检索、高难度推理、业务 API 调用——交给后台执行框架，而这条被委派出去的链路就是普通的文本推理。OrcaRouter 既不承载 Realtime-Venus，也不承载 SeedRealtime；这两个双工层都不在我们服务的范围内，我们也不托管其中任何一个。近 200 个文本模型，只需一个密钥，按提供商标价，无加价就是我们确实覆盖的那一半架构，具备自动故障转移，因此后台任务不会因为某个上游“下午不顺”而失败，一种用于将多个模型组合成一次调用的路由 DSL，以及当单个模型的判断力不够时的模型融合。它不是这些系统中困难的那部分。它是真正可以购买的那部分。

什么会改变这一比较？

三个进展才能让这件事尘埃落定，而目前一个都还没有出现。其一是对Realtime-Venus的独立基准测试，因为一张没有第二个读者核验的成绩表只是主张，而非结果。其二是SeedRealtime的API，因为目前部署证据最充分的模型，恰恰是谁都用不上的那个。其三是从二者中任一方公布延迟数据——首音频时间是这个品类据以成交的指标，而截至本文写作时，两个模型都没有给出这一数字。

在那之前，诚实的总结是：SeedRealtime 证明了音视频全双工在消费级规模上可行，而 Realtime-Venus 证明了权重可以开放，而这两个事实都无法让构建者更接近交付产品。这不是对任何一家实验室的批评。它描述的是一个已经解决了研究问题、却尚未解决分发问题的类别。