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 授權發布於 inclusionAI/Realtime-Venus（位於 Hugging Face），並附有自訂的 Transformers 程式碼、requirements 檔案、參考語音、專案頁面，以及一個配套的 GitHub 儲存庫。擁有消費級產品的那家公司，沒有推出任何你能實際拿在手上的東西。研究團隊則把整套東西都釋出了。

每一個對影格的處理方式

影片的取向正是整體架構上的差異，而不是強調重點的問題。

• 影片 — Muse Realtime Avatar 會生成影片，其條件為語音符元、一張參考影像，以及近期影片潛在表示的滾動視窗；Realtime-Venus-Omni 則負責感知，並由 SigLIP2 視覺編碼器將影格與音訊一併串流送入模型。

• 音訊 — Muse Realtime Avatar 由 Muse Realtime Voice 的語音 token 驅動生成，這些 token 同時承載內容與韻律；Realtime-Venus 將語音生成為離散的 S3 token，再由串流 flow-matching 解碼器解碼，而非在末端另外接上一個獨立的文字轉語音模型。

• 主幹 — Meta 的架構是一種音訊驅動的擴散 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 毫秒；25 fps 的 448×768 直式影片；模型評估次數比其自身基準少 60 倍；以及在一顆 NVIDIA GB200 上同時進行 12 個即時工作階段，相較於 Meta 的兩步 BF16 基準，容量提升 8 倍。Meta 也揭露了與兩套商業化虛擬人系統相比的偏好結果，其中一套該公司回報在舉止神態上與持平表現不具統計顯著差異——這是一項值得肯定的揭露，因為這正是大多數發表貼文會略去的那類結果。

螞蟻集團的結果，如已公布：在報告採用的八項影片基準測試中，有六項取得最佳分數，包括 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 Realtime Voice 是某個代理的對話層，該代理的推理則運行於 Muse Spark 上。Realtime-Venus 會把任何超出它能在行內完成範圍的事——檢索、工具呼叫、困難的推理——委派給一套執行框架，由它在背景中依據對話的快照執行這些工作。在這兩種設計中，使用者與之對話的東西都是前端，而思考則發生在另一個獨立的文字模型中。

那個獨立的文字模型，就是你可以路由的部分。在 OrcaRouter 上，它是單一端點，適用於 橫跨 15 家供應商的 196 個模型，以供應商定價原價傳遞、零加成，並在模型發生錯誤或逾時時自動容錯移轉——當另一端的東西是沒有人獨立評估過的自行託管檢查點時，這點比平常更重要。我們不託管 Realtime-Venus：它是一個下載項目，我們也不提供它。我們也不託管 Muse Realtime Avatar，因為根本沒有人這麼做。我們所提供的，是這兩種架構都把最棘手的部分交給它處理的那一層，因此，對話兩端任一未經證實的元件，都只是一行設定，而不是一場正式環境的賭注。

這些當中，哪一個實際上進展得更遠？

直覺會說是 Meta 的，因為 Meta 有產品和示範影片。但證據顯示出更有意思的事。Meta 的系統在生產工程上更勝一籌——在 GB200 上同時執行 12 個工作階段是一項推論服務成果，而針對已上市虛擬化身產品所揭露的偏好測試，是兩套系統僅有的正面對決數據。Ant Group 的系統則有更好的可驗證性：具名基準測試、公開權重、Apache-2.0 許可證，以及一份任何人都能嘗試重現的報告。

兩者都欠缺的，是一套付費購買它的方式。而更接近可用狀態的那一個，並不是擁有消費者應用程式的那一個——而是你今晚就能下載，在自己的硬體上、用自己的資料親自一探究竟的那一個，而且不需要任何發表公告。

如果你正在做選擇，問題不在於哪個模型比較好，而在於你想要一張你無法呼喚的臉，還是一台你能操作的相機。