Muse Realtime Avatar vs Realtime-Venus：视频输出对比视频输入

相隔九天宣布的两套系统都自称实时，都打着音视频的旗号，却沿着同一条轴指向相反的方向。Muse Realtime Avatar由 Meta 于 2026 年 9 月 23 日发布，它接收一张照片，生成其开口说话的视频——视频是输出结果，448×768 的竖屏画面，每秒 25 帧，由音频驱动的 Diffusion Transformer 生成，并与 Muse Realtime Voice 共享同一 token 流。Realtime-Venus由蚂蚁集团 Venus 团队联合清华大学于 2026 年 9 月 12 日上传至 arXiv，消费视频：Realtime-Venus-Omni 检查点将摄像头画面经由 SigLIP2 编码器流式处理，并就其所见展开对话；而 Realtime-Venus-Audio 检查点则是同一主干网络在加载时关闭了视觉。一个渲染出一张脸。另一个注视着那张脸。两者都无法调用，且只有其中一个可以下载——而事实证明，这才是更具实质影响的差别。

这种可用性上的颠倒值得在讨论其他任何事情之前先直白说明，因为它与人们对 Meta 产品和研究实验室发布的所有预期都相悖。Meta 的系统是封闭的：在 Connect 上宣布，在研究文章中演示，嵌入 Muse 智能体，却没有 API、没有权重、没有价格，也没有日期。蚂蚁集团的系统是开放的：两个 9B 检查点，以 BF16 safetensors 形式、在 Apache-2.0 许可下发布于 Hugging Face 的 inclusionAI/Realtime-Venus，并附带自定义 Transformers 代码、依赖文件、参考音色、项目页面以及配套的 GitHub 仓库。拥有消费级产品的公司没有交付任何你能拿到手的东西。研究团队则交付了整套东西。

每个对帧的处理方式

视频的方向就是整个架构上的差异，而不是侧重点的问题。

• 视频 —— Muse Realtime Avatar 以语音 token、参考图像以及近期视频 latent 的滚动窗口为条件生成视频；Realtime-Venus-Omni 则对其进行感知，其 SigLIP2 视觉编码器将视频帧与音频一同流式送入模型。

• 音频 — Muse Realtime Avatar 直接根据 Muse Realtime Voice 的语音 token 驱动生成，这些 token 同时承载内容与韵律；Realtime-Venus 将语音生成为离散的 S3 token，再由流式流匹配解码器解码，而不是在末端外挂一个独立的文本转语音模型。

• 主干 — Meta 的架构是一个音频驱动的 Diffusion Transformer，规模未公开；Realtime-Venus 则建立在 Qwen3-8B 语言主干之上，并配备 Whisper-Medium 音频编码器，其模型卡上写明 Omni 检查点改编自 MiniCPM-o 4.5。

• 权重 — Muse Realtime Avatar 的权重尚未发布，也没有任何迹象表明会发布；Realtime-Venus 提供了两个 9B 检查点，均为 BF16，两者的上下文长度均为 40,960 token，采用 Apache-2.0 许可。

• 访问 — Muse Realtime Avatar 没有 API，也没有日期；Realtime-Venus 同样没有 API，其卡片明确说明它并未由任何推理提供商部署。

• 运行在哪里 — Muse Realtime Avatar 在 Muse 应用内运行，面向 Meta 尚未枚举的用户，按 18+ 条款；而 Realtime-Venus 今天就能在你自己 的 GPU 上运行，前提是你有相应的硬件和意愿。

把最后两行连起来读，实际的差别就显现出来了。这两个系统都无法调用。而其中一个可以运行。

9B 下载是真的，你为此付出的代价也是真的

Realtime-Venus 并不是一个空壳仓库。权重就在那里，自定义加载代码也在那里，顶层许可证是 Apache-2.0。在围绕它做规划之前，有两件事值得了解。

第一点是权重中不包含的东西。让这套架构与众不同的双循环运行时——一秒的交互循环，外加一个被论文称为 Realtime-Venus-Harness 的后台调度器，它针对对话状态的隔离快照执行被委派的任务，因此长时间运行的作业不会因对话继续推进而遭到破坏——在 GitHub 仓库中作为独立组件存在。而委派设计，也就是这份报告中真正新颖的想法，正是需要你自己去组装并信任的那一部分。

第二个是血统。卡片上写明，Omni 检查点改编自 MiniCPM-o 4.5，即 OpenBMB 于 2026 年早些时候开源的 9B 全模态模型。这不是一句脚注。它意味着蚂蚁集团的贡献在于后训练、运行时，以及叠加在他人流式主干之上的委派设计——相比"一个全新的 9B 全模态模型"，这是一个更窄、也更具体的说法，而且更有用，因为它告诉你：如果视觉编码器出了什么岔子，该从哪里查起。

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

这就是两个系统以一种无益的方式趋同的地方：两者都没有一个独立的评估。Meta的四个数字是由公司报告的，对比的是Meta选择的基线。Realtime-Venus的数字是由作者在一份技术报告中报告的，没有第三方发布过运行结果，也没有排行榜条目可供核对。没有由未构建任一系统的人对任一系统进行过公开测量。

Meta 公布的四个指标如下：从你的发言结束到同步语音视频回复的首字节，耗时 870 毫秒；448×768 竖屏视频，每秒 25 帧；模型评估次数比其自身基线少 60 倍；在一台 NVIDIA GB200 上支持 12 路并发实时会话，相比 Meta 的两步 BF16 基线实现了 8 倍的容量提升。Meta 还披露了与两个商用虚拟形象系统的偏好对比结果，其中它报告称，其中一个系统在举止表现上与持平状态在统计上无法区分——这一披露值得赞赏，因为这是大多数发布帖都会省略的那类结果。

蚂蚁集团（Ant Group）的，如已发布：在报告采用的八项视频基准测试中，有六项取得最佳分数，包括 Omni 检查点的 StreamingBench 70.2、OVO-Bench 64.7 和 Daily-Omni 81.3；而在 Audio 检查点上，MMAU 78.0、MMAU-Pro 63.2、Llama Questions 83.8、Speech CMMLU 67.8，以及 VoiceBench AlpacaEval 得分 4.81，报告称其与最佳对比数字持平。

证据中的一处不对称值得点出。蚂蚁集团的数据是带有具名测试集的基准分数——原则上，任何愿意下载权重并运行该套件的人都可以复现。Meta 的标志性数字是在 Meta 自家服务栈上测得的延迟，Meta 之外无人能够复现，因为 Meta 之外无人拥有这套系统。换言之，这次开放发布同时也是更可核查的那一个。

为什么这两者都是变相的路由问题

两个系统都不是完整的智能体，而且这一点对两者而言同样成立。Muse Realtime Avatar 是一个加装在 Muse Realtime Voice 上的渲染层；后者是某个智能体的对话层，而该智能体的推理运行在 Muse Spark 上。Realtime-Venus 会把任何超出其内联能力的事情——检索、工具调用、高难度推理——委托给一个执行框架，由该框架基于对话快照在后台执行这些工作。在这两种设计中，用户与之对话的对象都是前端，而思考发生在一个单独的文本模型中。

那个单独的文本模型正是你可以路由的部分。在 OrcaRouter 上，一个端点即可接入来自 15 家提供商的 196 个模型，按提供商标价原样透传、零加价，并在模型出错或超时时自动故障转移——当另一端是无人独立评估过的自托管检查点时，这一点比平时更重要。我们不托管 Realtime-Venus：它是一个下载项，我们也不提供它。我们也不托管 Muse Realtime Avatar，因为没人托管它。我们承载的是两种架构都把繁重工作交给它的那一层，因此对话任一端未经证实的组件只是配置中的一行，而不是一场生产赌注。

这些当中哪一个实际上进展得更远？

直觉上会说是 Meta 的，因为 Meta 有产品和演示视频。但证据表明的情况更有意思。Meta 的系统在生产工程上更胜一筹——在 GB200 上跑 12 个并发会话是一项服务层面的成果，而针对已上市虚拟形象产品公开的偏好测试，是两套系统仅有的正面交锋数据。蚂蚁集团的系统则具有更好的可验证性：具名基准测试、已发布的权重、Apache-2.0 许可证，以及一份任何人都可以尝试复现的报告。

两者都不具备的，是为之付费的方式。而更接近可用的那个，并不是拥有消费级应用的那个——而是你今晚就能下载、在自己的硬件上、用自己的数据亲自去发现的那个，无需任何发布公告。

如果你正在做选择，问题不在于哪个型号更好，而在于你想要一张你无法呼唤的脸，还是一台你能操控的相机。