Realtime-Venus：螞蟻集團的全雙工 9B 未經發布即推出

2026年9月12日，arXiv 上出現了一篇技術報告，描述 Realtime-Venus：一套全雙工互動系統，由兩個分別訓練的 9B 模型構成——用於視聽互動的 Realtime-Venus-Omni，以及用於語音互動的 Realtime-Venus-Audio——並由 Ant Group 的 Venus Team 與清華大學合作開發。inclusionAI/Realtime-Venus幾天內，Hugging Face 上一個位於 inclusionAI/Realtime-Venus 底下的 Apache-2.0 儲存庫就收錄了這兩個檢查點，以可下載的 BF16 safetensors 形式提供，同時還有一個專案頁面和一個配套的 GitHub 儲存庫。沒有出現的，才是值得注意的部分：沒有發布貼文、沒有產品頁面、沒有 API、沒有價目表，Ant Group 自家平台上也沒有任何內容宣告這一切存在。這是一次除了公告之外什麼都發布了的發布，因此，區分已確立的事實與各種說法就成了全部工作。

磁碟上實際上有什麼

這個儲存庫不是空殼。它包含兩個模型目錄，每個目錄都有分片的 safetensors 權重、一份設定檔，以及模型卡指示你使用 trust_remote_code=True 載入的自訂 Hugging Face Transformers 程式碼。頂層有一個 requirements 檔案、一個存放 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 生成，再由串流 flow-matching 解碼器解碼，而非在末端外掛一個獨立的文字轉語音模型。

• 血統——模型卡指出，Omni 檢查點改編自 MiniCPM-o 4.5，這是 OpenBMB 於 2026 年初開源的 9B 全模態模型。那不是附註。這意味著 Ant Group 的貢獻在於後訓練、執行環境，以及疊加在他人串流骨幹之上的委派設計，這與「一個新的 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。如果這兩個數字都站得住腳，那麼大規模後訓練與執行期投入所帶來的改進，在一項基礎模型原本就已擅長的基準上大約只有一分——對這類工作來說，這是個務實的結果，也比「八項中有六項最佳」這個標題來得不那麼戲劇化。

什麼尚未確立？

未解問題的清單比已有定論的問題清單還長，而這就是一個問世僅六天的模型所處的誠實狀態。

• 不存在任何獨立評估。沒有競技場排名，沒有第三方重現，也沒有任何曾公布數字的外部團體。

• 沒有以毫秒為單位的延遲數據。報告描述了以一秒為單位的互動節奏，而產品卡記錄了每秒的串流呼叫，但沒有公布首次音訊時間（time-to-first-audio）的數字，而這正是這個類別實際購買時所依據的指標。

• 沒有 API，也沒有價格，更沒有任何說法表示其中任何一項即將推出。這究竟是一款等待問世的產品，還是會一直停留在可下載形式的研究產物，實在無從得知。

• 廠商並未表明任何意圖。未發布公告，並不構成低調發布策略的證據；這也同樣符合一個僅為論文而發布的儲存庫，別無其他。

• 沒有 harness 在生產環境的實證。它是這套架構的承重元件，卻也是文件記載最少的一環。

為什麼安靜的路線不斷出現

這是今年第二次，螞蟻集團的模型工作不是透過發表會，而是透過儲存庫向大眾公開。該實驗室的 GUI 代理 UI-Venus-2-9B 於 2026 年 8 月底出現在 Hugging Face 上，沒有論文、沒有專案頁面，也沒有任何公告——而此後才有一份報告隨之而來。Realtime-Venus 的登場順序則相反：先有報告，儲存庫同步現身，公告仍舊未發布。

這種模式並非螞蟻集團獨有。尤其是中國的實驗室，一直把研究產物和消費者端部署推向世界，卻把面向開發者的公告留到之後，或乾脆略過。對任何關注這個領域的人來說，這很不方便，因為通常的訊號——一篇發布文章、一張價目表、一個說明文件網站——正是缺失的那一部分。如今，產物本身就是公告，仔細閱讀它是了解實際推出了什麼的唯一方法。

如果你想要執行它的話

對於這麼新的發布版本來說，這張卡實用得非比尋常。載入方式很標準：AutoModel.from_pretrained搭配本機檢查點目錄、信任遠端程式碼、SDPA 注意力，以及 bfloat16。全雙工串流只要呼叫一次即可進入，該呼叫會把模型切換成雙工模式，之後官方文件記載的迴圈就是先跑一秒的streaming_prefill，接著跑streaming_generate，如此反覆。長影片記憶功能透過設為四十的記憶分鐘數參數啟用，並被描述為免訓練，這對於通常需要微調才具備的能力來說相當值得注意。文件記載了兩項注意事項，而不是要你自己踩雷才發現：一個影格上限，除非在匯入工具程式之前調高某個常數，否則它會默默截斷長影片；以及一項 CJK 字型需求，用於渲染進雙工影片中的非拉丁字幕。

這張卡沒能給你的是硬體門檻。一個 BF16 的 9B 模型，在還未計入任何活化記憶體之前，權重就大約是十八 GB，這使得即時雙工推論必須落在夠力的 GPU 上，也超出了它所衍生的 MiniCPM-o 系列當初部分就是為其設計的筆電部署所能及。

這裡有一道值得命名的接縫，因為這正是路由器真正切入的位置。Realtime-Venus 把它吃重的工作——檢索、複雜推理、商業 API 呼叫——委派給背景模型。這段被委派的環節就是一般的文字推論，而正是這個環節決定了你的對話前端是有用，還是只是話說得漂亮。OrcaRouter 不含 Realtime-Venus 的任何部分；這裡的雙工層是自行架設的下載項目，我們並不提供。它所交出去的推理，才是我們涵蓋的部分：近 200 個模型，一個金鑰即可取用，依供應商牌價計費，不加價，上游鬧脾氣時自動容錯切換，一套能把多個模型組成單次呼叫的路由 DSL，以及在某個模型的判斷不足時派上用場的模型融合。委派標記是前端的決定；由哪個模型來回應則是配置選擇，而把這個選擇留在權重之外，正是讓你不必重新訓練任何東西就能更改它的關鍵。

什麼能解決這件事？

有三件事能讓 Realtime-Venus 從一篇附帶權重的論文，變成任何人都能評估的模型。由獨立團隊重現 Full-Duplex-Bench 的續接數字，因為在附和語情境下達到 97% 是個非凡的數字，而非凡的數字需要第二位讀者。一個公開的延遲數字，因為全雙工系統的成敗取決於首次音訊時間，而這個系統尚未說明目標值。以及測試框架（harness）的文件，因為非同步委派設計是這次發布中唯一真正全新的部分，而現在它是你能讀到、卻不容易採用的部分。

在那之前，準確的描述既狹隘又乏味，而這正是它值得被寫下來的原因：兩個 9B 全雙工檢查點的真正 Apache-2.0 發布，建構於開放主幹之上，有著強勁的自我回報基準測試，沒有獨立驗證，沒有 API，也沒有任何公告。那條線以上的一切都是推論。