Duo-1.0-causal-base：153 GB 的權重、一篇論文，卻沒有發布貼文

11 月 12 日 06:32 UTC，一個名為 Duo-1.0-causal-base 的 Hugging Face 儲存庫進行了初始提交：80 個檔案、153.46 GB，以及一個包含視覺語言骨幹、視聽擴散 Transformer、兩個編解碼器、一個語音辨識器和一個強制對齊器的套件。其背後的論文已在前一天登上 arXiv。二十四小時內又出現了三個同系列儲存庫，其中一個到今天早上仍在上傳。該儲存庫自家日期為 11 月 13 日的新聞區塊，將這一切稱為一次發布。幾乎沒有其他來源這麼稱呼。我找不到任何發布貼文、託管端點、定價頁面，也找不到針對 Duo-1.0-causal-base 的獨立基準測試——而存放在那 153 GB 之中的授權條款檔案，其授權範圍排除歐盟、英國、韓國與美國。

所以這不是一篇發布報導，因為根本沒有發布。這也不是一篇洩密報導，因為權重是公開、無需授權且完整的。以下內容要釐清每當研究實驗室以儲存庫而非產品形式釋出時，常被混為一談的兩件事：檔案與論文實際確立了什麼，以及至今還沒有人證實什麼。

什麼已落地，以及順序為何？

此序列可從儲存庫中繼資料讀出，這點很重要，因為它是唯一的第一方紀錄。

• 論文——arXiv 2611.15131，Duo：用於全雙工互動的互惠世界模型，二十位作者，從 Hengyuan Cao 到 Zhenzhong Lan，於 2026 年 11 月 11 日提交。Hugging Face 論文頁面顯示 27 個讚，除此之外沒有任何報導。

• 權重——inclusionAI 組織下的四個儲存庫；該組織自稱是螞蟻集團 AGI 計畫的所在地，其專案頁面帶有 2026 Ant Research 著作權標示。Duo-1.0-causal-base 與 Duo-1.2-causal-base 分別於 11 月 12 日 UTC 06:30 和 06:32 建立；Duo-1.0-distill 早二十五秒；Duo-1.0-distill-quant 則於今早 UTC 08:09 建立。

• 程式碼——github.com/inclusionAI/Duo，Apache-2.0，於 11 月 6 日建立，但僅含一個提交，時間戳為今日 09:13 UTC，截至撰寫時有六個星標且沒有分支。

• 這項聲明——README 新聞區塊中全部三行、日期皆為 2026/11/13 的內容：論文、vLLM-Omni 與 SGLang-Omni 串流管線，以及 v1 權重與離線推論程式碼。

套件大小是讀者首先能夠據以行動的項目，因為它們彼此不能互換。

• Duo-1.0-causal-base — 共 80 個檔案、153.46 GB。Realization 權重 69.07 GB、Intent 模型 66.73 GB、視訊與音訊編解碼器 11.02 GB、語音堆疊 6.54 GB，以及一個 84.8 MB 的轉接器。

• Duo-1.2-causal-base — 80 個檔案共 153.46 GB，僅被描述為「生成品質提升」，其蒸餾與量化變體則列為即將推出。

• Duo-1.0-distill — 2.78 GB，共八個檔案。它是疊加層，不是模型：會下載到與基礎套件相同的目錄，並把取樣器設定改成 Euler、四步與 flow shift 5.0，而基礎版則是五十步與 1.0。

• Duo-1.0-distill-quant — 47.03 GB。在 ModelOpt FP8 中同樣採用四步疊加，並搭配逐通道縮放；而且模型卡明確指出，執行環境必須支援該格式，或提供轉換途徑。

兩個模組和一個 708 毫秒的時鐘

架構從設定檔就能清楚看出來，這比大多數模型卡所能提供的還多。Duo 把工作拆成兩部分。

Intent 模組宣告為 Qwen3VLForConditionalGeneration——64 層、隱藏維度 5120，64 個注意力頭與 8 個 key-value 頭，中間維度 25600，詞彙表共 151,936 個 token，以及一個 patch 大小為 16 的 27 層視覺塔。各分片合計為 66.71 GB 的 bfloat16 權重。這是一個大型視覺語言模型，而規格卡從未標示參數數量，因此其規模等級是從設定推斷而來，而非廠商提供的數字。在其之上還有一個 LoRA 適配器，rank 為 8、alpha 為 16，針對 query、key、value 與 output 投影以及語言模型頭，並包含四個可訓練的特殊 token：<wait>、<blank>、<chunk_708> 與 <speak>。

那組 token 就是整個構想的縮影。每一個 chunk，Intent 模組會發出帶有文字的 <speak>，或不帶任何內容的 <wait>。決定何時開口，與決定要說什麼，是兩項分開的預測；這正是差別所在：一種模型只在你停下來時才回答，另一種則能插話、保持沉默，或在你說話時繼續說。

Realization 模組是一個 MiniMaxH3DiTModel：5376 隱藏維度下共 50 層、56 個 Dimension 為 128 的注意力頭、前饋網路寬度 14336、1×2×2 的 patch、影片 24 個潛在通道與音訊 32 個潛在通道，以及一個兩層的 token refiner，能將 Intent 模組的隱藏狀態融入條件表徵之中。它由 MiniMax H3 權重初始化，NOTICE 檔案載明了上游授權。各分片共 535 個張量，總計 66.28 GB。

將它們串接起來的時鐘，是那個值得記住的數字。互動以每區塊 17 個視訊影格運行，在每秒 24 影格下——即 708 毫秒。每個區塊會編碼成五個視訊潛在表徵，採 1-4-4-4-4 的影格切分；也會編碼成 2×29 個音訊潛在表徵，因為音訊在 32 kHz 下以每聲道每秒 40 個潛在表徵運行，每 25 毫秒一個。位置編碼是以播放時間為基準的三維 RoPE。注意力遮罩的建構方式，讓任何區塊都看不到自身未來的乾淨媒體；這正是讓整套系統具備因果性且可串流的原因，而不是像擴散模型那樣，必須先有完成的片段才能開始。

延遲宣稱是真的，而且這是八顆 GPU 的宣稱。

論文中的串流章節是這次發布裡最具體的部分，卻也是最難在大多數讀者手邊硬體上重現的部分。

• 意圖推論 — 每區塊 90 至 160 毫秒。

• 聯合潛在生成於 768×576 — 200 至 450 毫秒。

• 串流解碼 — 每四幀群組約 30 毫秒。

• 額外開銷 — 約 40 毫秒。

• 總計 — 330 至 650 毫秒，相較於 17/24 秒的週期目標；若話語在取樣窗中途結束，還會再多 708 毫秒的取樣延遲。

這些數字來自八 GPU 配置。Intent 模組與語音辨識器一起在 GPU 0–3 上以四個 rank 執行張量平行；擴散 transformer 分散於全部八張 GPU，並針對每個區塊，依在記憶體限制下哪種方式能最小化週期時間，選擇張量平行或序列平行；串流 VAE 在 GPU 4–7 上以四路進行空間切塊。GPU 0–3 為區塊 k+1 執行 Intent，而 GPU 4–7 解碼區塊 k。輸出以一個單幀錨點加上四個四幀封包的形式釋出，而最短播放間隔為 1/24 秒、約 41.7 ms，刻意比 30 ms 的解碼時間更長，讓緩衝區能吸收抖動。

現在拿 README 的要求來對照這件事。參考的離線部署需要兩張 CUDA GPU——一張給 Intent 和編解碼器，一張給 Realization——還需要兩個 Python 環境，因為鎖定版本的 qwen-asr 套件會挾帶自己的 Transformers 版本，而且 PATH 中要有 FFmpeg。那正是隨附 demo 實際運行的配置。330 到 650 毫秒這個數字，假設的是八張 GPU，但未說明是哪種模型。這兩個數字都是誠實的；它們回答的是不同問題，而兩者之間的落差，正是論文結果與你本週就能組出來的一台機器之間的距離。

93.3% 是作者自己批改自己的考卷

這項評估有其不尋常之處，值得在任何地方引用該百分比之前先加以說明。

三十個即時雙工案例在共享時間軸上並排重播，並以正常播放速度搭配聲音進行評判，依據六項附有書面失敗條件的二元標準：內容反應性、語言遵循、語音清晰度、視覺身分穩定性、影音同步，以及影音情緒一致性。在一百八十項檢查中，有一百六十八項通過——通過率為 93.3%。語言遵循、語音清晰度與視覺身分穩定性三項合計九十項全數通過。情緒一致性為 96.7%，唇形對齊為 90.0%，內容反應性為 73.3%，亦即三十項中有二十二項通過。

接下來有三件事，而只有第一件是討喜的。

首先，在 180 項附有書面失敗條件的二元檢查中達到 93.3%，這比排行榜上的 Elo 分數更是可證偽的主張；而且失敗分析異常具體：玩笑和需要模型讀出字面言外之意的隱晦評論，以及只有把語音和視訊合起來解讀才能釐清的意圖——論文中的例子是，一名在室內的用戶在開始下雨時提到共享單車，模型卻把它當成尋求建議的請求，而不是場景變化。

第二，評審就是作者本人。沒有第三方執行，沒有盲測的成對研究，也沒有外部審查小組。附有書面條件的二元評分量表是正確的工具；把它套用到自己的輸出上，並不是獨立驗證。

第三，也是最說明問題的一點，論文中完全沒有任何基線比較。唯一的定量對照是資料合成上的一項消融：在由十個六秒區塊組成、總長六十秒的序列中，基線方法到第九個區塊時損失了 34.2 個亮度階，而所提方法則穩定在約 99。相關工作——Moshi、Qwen-Omni、Wan-Streamer、EMO、OmniHuman、LiveTalk、Self Forcing、CausVid——僅以定性方式討論，沒有直接對比的數字。論文也從未說明參數量或訓練資料量。因此，誠實的總結是：Duo v1 是對照評分規準來衡量，而不是與另一個模型比較。

授權就是決定你一週的那個關鍵部分

這是會改變採購決策的章節，而它被埋在 17 KB 的 LICENSE 檔案裡，而不是放在模型卡的說明文字中。

權重不是 Apache-2.0。程式碼儲存庫是；權重不是。每個 Duo 檢查點都帶有 minimax-h3-community-license，因為 Realization 模組是從 MiniMax H3 初始化而來，而授權會隨著衍生作品移轉。套件包內的協議日期為 2026 年 8 月 2 日，並將「M​iniMax」定義為 Nanonoble Pte. Ltd.

其授權在地域上受到限制。「適用領域」指全球，但不包括排除領域；排除領域為歐洲聯盟、英國、大韓民國及美利堅合眾國。授權條款文字邀請這些領域內的任何人聯絡 M​iniMax，以取得「基於健全控制與護欄」的授權；這是一條途徑，而非一項許可。

實務上：新加坡、瑞士、日本、印度、巴西或加拿大的研究團隊，今天就能依所述條款下載並執行這項工具。舊金山、倫敦、柏林或首爾的團隊，則依該文件的字面解讀不能這麼做，而且不應該在為期兩週的整合結束時才發現這件事。這種不對稱也正是為什麼在你安排任何時程之前，該檢查的是授權條款——而不是基準測試。

你今天實際能運行什麼

{{1}}離線路徑有文件記載，而且很短。{{/1}}複製儲存庫，建立兩個虛擬環境——一個給 {{2}}Realization{{/2}}，一個給語音堆疊——下載基礎套件包，將 {{3}}configs/inference.example.json{{/3}} 複製到 {{4}}configs/inference.json{{/4}}，讓它指向權重與兩個 Python 執行檔，然後啟動 {{5}}run_demo.py --config configs/inference.json --port 4173{{/5}}。介面是位於 {{6}}/video/index.html{{/6}} 的瀏覽器頁面。

就串流而言，README 指向兩個分支：{{1}}vLLM-Omni{{/1}}（標示為推薦）以及 {{2}}SGLang-Omni{{/2}}。那是延遲數據所描述的路徑，也是需要八張 GPU 配置的那一條。

關於你會看到的內容，有兩點需要留意。專案頁面的示範內容取自訓練資料與離線推論——頁面本身有說明，並補充即時全雙工結果「將於近期加入」。而且這次發布明確是預覽版：「Duo v1 是供研究人員使用的預覽版」，支援「基本的視聽對話」，並承諾 v2 會讓 Realization 直接以使用者的音訊與視訊為條件，以進行視覺互動。如果你感興趣的是能觀察你並對物件做出反應的模型，這項能力並不在這次發布中。

本週誰該留意，誰該再等等

• 全雙工互動研究——這是該類別中最具體的公開釋出：一篇附有延遲預算、區塊時鐘、蒸餾配方，以及真的能下載的權重的論文。雙重 rollout 蒸餾——先 rollout 凍結的 Intent 模組，再從模型自身的輸出（而非錄製的歷史）生成媒體——才是可轉移的概念，即使你從未執行 Duo。

• 正在打造虛擬化身或陪伴型產品的團隊——單就 708 ms 這個切入角度就值得一讀。這個數字決定了一次插話感覺像真人，還是像延遲；而這是一項你不必採用該模型也能採用的設計限制。

位於排除地區的團隊——且慢，並把授權洽談視為關鍵路徑，而非 GPU 預算。

• 任何想要 API 的人——這不是那種東西。模型卡明確指出，目前沒有任何推論供應商在提供它，也沒有廠商端點。

最後一點，正是路由器真正適用與不適用的分界。OrcaRouter 不託管 Duo-1.0-causal-base，也無法路由它：一個 153 GB、雙模組的擴散堆疊，搭配固定的 708 毫秒區塊時脈，並不是聊天補全的目標，再多的路由也改變不了這點。可路由的是大多數團隊在雙工實驗於功能旗標後運行時所部署的回合制備援——語音輸入、語言模型、語音輸出。語音輸出這一段可以是託管的文字轉語音模型，而不是同一兩張 GPU 上的另一個程序；透過單一 API 存取超過 200 個模型，並以 0% 加價轉嫁供應商定價，當供應商調整價格時，成本計算仍維持不變。自動容錯移轉應放在那些託管環節，而不是自託管環節：它能在供應商不穩時讓示範持續運作，但對你在自有硬體上運行的堆疊毫無幫助。

另一個誠實的用途是評估紀律。讓生產路徑使用你能呼叫的模型，並把 Duo-1.0-causal-base 視為附有書面評分規準的檯面實驗——鑑於現有唯一的評分規準是由其作者套用的，這正是它的本質。

什麼會改變判決

三件事，依其重要性由低到高排列。

由第三方依照六項標準，對 Duo 團隊未選擇的提示詞進行評分。評分規準已經公布，因此這件事對任何人來說成本都很低；但如果內容回應性在未見案例上真的有 73.3%，那對模型來說代價就很高。

一個不會預設需要八張 GPU 的託管端點或服務配置。雙 GPU 的離線示範與八 GPU 的延遲宣稱兩者皆屬實，而兩者之間的落差，正是大多數讀者實際所處的境地。

授權條款涵蓋了被排除的地域。架構的任何部分都改變不了那個算術，再多的基準測試改善也同樣做不到。

在那之前，對 Duo-1.0-causal-base 的精確描述是這樣：一個完整、不受限制的 153 GB 研究套件，具備真實的延遲預算與自評評估，以論文和程式碼庫的形式發布，附上一行註明日期的消息，背後卻沒有產品。這比預印本更多——權重就在那裡，示範也能跑——但也遠少於一個你能據以規劃一整個季度的模型。未解的問題不是 Duo 能否以 708 毫秒的切片進行對話，而是團隊以外的人是否會被允許查核。