Realtime-Venus vs SeedRealtime：兩種截然相反的無法使用方式

Realtime-Venus 與 SeedRealtime 是同一個 2026 年故事的兩半，而它們在彼此相反的考驗中失敗。SeedRealtime 是字節跳動（ByteDance）的原生音視覺全雙工模型，於 2026 年 8 月 5 日在豆包（Doubao）App 內免費啟用，觸及受眾規模被其開發者形容為數億計——卻沒有 API、沒有模型識別碼、沒有定價，也沒有延遲目標。Realtime-Venus 則是來自螞蟻集團（Ant Group）Venus 團隊與清華大學的一對 9B 檢查點，於 2026 年 9 月 12 日以 Apache-2.0 條款發布，附有技術報告，卻沒有發布公告，靜置於一個任何工程師都能下載、但幾乎沒人能實際部署的儲存庫中。其中一個你無法呼叫。另一個你能下載，然後發現自己沒有東西可以用來呼叫它。兩者都確實處於同一能力的最前沿，而兩者都沒有任何曾由其作者以外的人重現過的基準測試。

兩種「你無法擁有它」的風味

值得把話說清楚，因為「無法提供」這個說法掩蓋了真正的差異。

SeedRealtime 無法取得的方式，就像消費性產品無法取得那樣：它存在、它能運作、它有用戶，只是對開發者關上了大門。沒有 API、沒有價目表、沒有開發者文件入口網站，也沒有任何公開的推出時程。ByteDance 推向市場的路徑一直是那款 App，而這款 App 就已經足夠了。身為開發者，你能拿到的只是一個可以體驗、卻無法整合的展示。

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 年稍早發布的全模態模型，這使得螞蟻集團的貢獻在於後訓練與執行時，而非基礎架構。

它們的共同點，也是讓它們比純音訊系統高出一階的原因，在於兩者都不會停下來看。說話時持續進行視覺感知，與描述單一畫面是真正不同的能力，而兩個模型都是圍繞著這一點打造的。

每一個的數字價值是多少

兩個模型都沒有第三方基準測試。不過，兩者所依據的證據並不等同，而這個差異至關重要。

• SeedRealtime 完全沒有公布任何基準測試。字節跳動提供的只是一項宣稱：根據端到端的人工評估，對話節奏方面的問題——搶在使用者之前開口、回應延遲、被陌生人的噪音誤觸發——比串接式系統大約減少了一半。其背後的資料並未公開。

• 前代產品的數字如出一轍。Seeduplex 這款 ByteDance 於 2026 年 4 月導入 Doubao 的純音訊模型，據報導在一項大規模 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%、在附和語下的續接率 97%、在他向言語下 88%、在背景語音下 86%，在續接方面超越 Gemini 3.1 Live 與 GPT-4o——是這兩個模型針對這個問題所發表過最直接相關的數字。它們也完全是自我報告的，而在附和語下 97% 的續接率是個驚人的數字，在任何把它當成事實引用之前，值得再有第二個人審閱。

每個各自留下一個建構器之處

實務上的落差不在於品質，而是方案的形式。

• SeedRealtime — 你可以在 Doubao 中免費體驗它，卻永遠無法將它整合進去。從「這很令人驚豔」到「這已納入我的產品」，之間沒有任何路徑。

• Realtime-Venus — 你可以下載它、微調它、在氣隙環境中運行它，並檢查每一層。代價是兩個 9B 檢查點，採用 BF16 格式，每個約有十八 GB 的權重，再加上持續的每秒串流迴圈，這意味著一個 GPU 節點，無論有沒有人呼叫都會計費。

• 兩者都沒有託管版本。兩者都無法只憑一組金鑰和一個下午就試得起來。

最後一點正是這兩個模型作為一對搭檔比作為對手更有用的原因。它們共同證明問題的兩半都已解決——能力行得通，權重也可釋出——同時顯示尚沒有人把它們整合成開發者真正能呼叫的東西。

有一種變通做法，很多團隊都會想採用，而值得說清楚的是它涵蓋了什麼、又沒涵蓋什麼。如果你拿不到語音層，你仍然可以打造負責思考的那個部分。Realtime-Venus 會透過非同步委派標記，把昂貴的工作——檢索、艱難的推理、商業 API 呼叫——委派給背景執行框架，而那段被委派出去的部分只是一般的文字推論。OrcaRouter 既不提供 Realtime-Venus，也不提供 SeedRealtime；這兩個雙工層都不在我們所提供的範圍內，我們也兩者都不代管。近 200 個文字模型，用一把金鑰就能取用，以供應商定價提供、不加價是我們確實涵蓋的那半架構，具備自動容錯移轉，讓背景任務不會因為某個上游度過了一個糟糕的下午而失敗，還有一套路由 DSL，能把多個模型組合成單一次呼叫，以及在單一模型的判斷不足時所用的模型融合。這並不是這些系統中困難的部分。這是真正買得到的那個部分。

什麼會改變這個比較？

三項進展能讓這件事定案，而目前一項都還沒發生。第一，對 Realtime-Venus 進行獨立基準測試，因為沒有第二位讀者的表格只是宣稱，不是結果。第二，為 SeedRealtime 提供 API，因為擁有最強部署證據的模型，目前正是沒有人能使用的那一個。第三，由兩者之一公布延遲數據——首次音訊時間是這個類別在採購時所依據的指標，而截至本文撰寫時，兩個模型都尚未公布。

在那之前，誠實的總結是：SeedRealtime 證明了影音全雙工能在消費級規模運作，而 Realtime-Venus 證明了權重可以被開放，但這兩件事都無法讓開發者更接近推出產品。這不是對任一實驗室的批評。這是在描述一個已經解決了研究問題、卻尚未解決分發問題的類別。