MiniCPM-V 4.7 35B-A3B 對比 Qwen2.5-Omni：十九個月後，其中一款依然聽得見你

把 MiniCPM-V 4.7 35B-A3B 和 Qwen2.5-Omni 放在同一張規格表上比較，較新的模型幾乎每一行都勝出。它的上下文長度是後者的八倍，採用稀疏架構，每個 token 只啟用十二分之一的參數，還享有長達十年的推論工具鏈，而這些工具在較舊模型推出時根本不存在。接著看到音訊那一列，MiniCPM-V 4.7 35B-A3B 在那裡卻完全付之闕如。Qwen2.5-Omni 於 2025 年 3 月下旬發布，能接收音訊並串流輸出自然語音；MiniCPM-V 4.7 的權重則在 2026 年 10 月問世，能接收文字、圖像和影片並回傳文字。在這組特定配對中，十九個月的進展並沒有催生出更好的全模態模型，而是催生出一個更好的視覺模型，但這個模型並不做較舊模型當初圍繞打造的那件事。

這樣的說法並不是在貶抑其中任何一方。這正是這項比較的整體樣貌，也是為什麼一位需要語音的讀者，和一位需要閱讀上千頁掃描文件的讀者，最後應該得出不同的答案。就資料來源而言：Qwen2.5-Omni 的數字來自廠商 2025 年 3 月的資料，至今已十九個月，且部分已透過大規模部署獲得驗證。MiniCPM-V 4.7 35B-A3B 的數字則出自 OpenBMB，於 2026 年 10 月 12 日發布在模型卡上——那是它的第一張模型卡，距離權重首次問世僅十天——而這些數字沒有任何一項在實驗室外被重現過。

較舊的型號實際上究竟是什麼

Qwen2.5-Omni 是該系列中首個端到端全模態模型，而廠商當時的說法很明確：它是對「專家模型大雜燴」問題的解答——在該問題中，轉錄、視覺與語音各自都需要一個獨立模型和一層獨立的黏合層。這個 7B 模型接受文字、圖像、音訊與視訊作為輸入，並以文字或串流自然語音回覆，內建 Chelsie 與 Ethan 兩種固定語音。它宣稱在 OmniBench 融合基準測試上取得最先進的結果，領先 Gemini-1.5-Pro，並且語音生成品質分數達 4.51，廠商形容這是人類水準。

這套工程設計之所以站得住腳，是因為它是針對限制本身而設計，而不是繞過限制。Thinker-Talker 把工作拆成兩部分：Thinker 轉換器融合音訊與影像編碼器，產生語意與文字；而 Talker 則從 Thinker 的隱藏狀態串流輸出語音 token，並共享完整的對話歷史。時間對齊的多模態 RoPE 交錯排列視訊與音訊位置，讓兩個串流保持同步；區塊式串流則讓編碼器進行感知工作，同時由語言模型處理長序列——這正是低延遲口語回覆得以實現的關鍵。

這些限制同樣真實，而且它們是記憶體的限制，而非上下文的限制。廠商自家的表格指出，搭配 FlashAttention-2 的 BF16 推論，15 秒影片約需 31 GB GPU 記憶體，30 秒約 42 GB，完整一分鐘約 60 GB，對比之下，上下文視窗為 32,768 個 token。在 7B 模型上、在你所能租到的最大單一 GPU 之一上，一分鐘影片的這個數字，就是必須謹記的數字——它是後來一切被打造出來要摧毀的數字。

新模型改為做什麼

MiniCPM-V 4.7 35B-A3B 則完全走另一條路。它是 OpenBMB 在 MiniCPM-V 系列中的首個 MoE：40 層中有 256 個專家、每個 token 啟用 8 個，具備 262,144 token 的上下文視窗與 248,144 token 的詞彙表，換算下來，總參數 35.2B 中約有 3B 為活躍參數。視覺透過 SigLIP2 模組運作，搭配 LLaVA-UHD v4 的 ViT 內早期壓縮，以及可選的混合 4x/16x token 壓縮模式——預設為 16x，當精細細節值得耗費 token 時則用 4x。它能處理單一影像、多影像集合與影片。並以文字回答。

這張卡片的頭條宣稱是：這是首個具備無損、流暢裝置端推論的開源 MoE 模型，透過 Lookahead Expert Scheduling、細粒度逐層量化，以及經由獨立 DSpark 草稿進行的投機取樣達成，據稱在 iPhone 17 Pro Max 上達到每秒 13 個 token 以上。那個數字是廠商自行回報、未經重現且未附條件的——沒有量化格式、沒有建置版本、沒有提示詞、沒有測量方法。這張卡片也宣稱，在更短的推論時間內，其整體 Instruct 模式分數高於 Qwen3.6 35B-A3B；而該宣稱是以圖表圖片而非表格呈現，因此不能當作數字引用，也不應被視為數字。

七個維度，雙方

• 輸入模態 — Qwen2.5-Omni 接受文字、圖像、音訊與影片；MiniCPM-V 4.7 35B-A3B 接受文字、圖像與影片，完全沒有音訊路徑。

• 輸出 — 文字加上以兩種固定語音串流播放的自然語音，有別於純文字。

• 上下文 — 32,768 個 token，對比 262,144，增加了八倍。

• 參數——廠商用來命名模型的 7B 數字，對比 MiniCPM 這邊總計 35.2B、其中 3B 為活躍參數。該儲存庫本身將此檢查點列為 11B 參數，因為 7B 只計算語言模型，而不包含與其並存的視覺與音訊編碼器——這是有用的提醒：這裡的「7B」既是名稱，也是一種量測。

• 記憶體佔用 — 廠商自家的表格顯示，15 秒的影片約需 31 GB，一分鐘則約 60 GB；MiniCPM-V 4.7 光是 BF16 權重就約 70 GB，這還不含任何 KV 快取，這正是為何它的量化版本與裝置端方案在這張卡上占了如此大的篇幅。

• 授權條款 — 兩者皆採用 Apache-2.0，這是他們唯一毫無保留地達成一致的一點。

• 部署工具 — 十九個月的社群量化與工具開發，涵蓋對 SGLang、vLLM、llama.cpp、Ollama 與 OpenVINO 的支援、GGUF/BNB/AWQ/GPTQ/FP8 建置，以及 iOS、Android 與 HarmonyOS 應用程式。

• 公開評估——一個已持續十九個月、廣受引用的 OmniBench 0.561 排名，相較於一張完全沒有可引用評估表的卡片。

音訊孔就是整個決定

如果你的管線需要模型能聽見聲音，這場比較在第一段就結束了。Qwen2.5-Omni 是兩者中唯一能接收音訊的，唯一能發聲的，也是唯一背後有成熟語音堆疊——Thinker-Talker、TMRoPE、區塊式串流、兩種固定語音——支撐的。它也是兩者中唯一有人大規模部署過的，而當你試圖在本季把模型導入應用程式時，十九個月來社群的量化版本與工具鏈，比一份規格表更有價值。

MiniCPM-V 4.7 所換來的，是更長的記憶，以及針對長篇視覺文件低得多的每 token 運算成本。262K 視窗與 3B 活躍參數，和 32K 視窗搭配 7B 稠密模型相比，是真正不同的工具——而對於動輒數千張頁面影像、螢幕截圖或長篇影片逐字稿的工作負載來說，較新模型的形態才是對的。只是，它無法成為那個接電話的模型。

這就是取捨，說得直白一點：觸及範圍對上廣度。較舊的模型涵蓋更多義項。較新的模型涵蓋更多頁面。

兩條截然不同的證據線索

這裡的不對稱性朝相反方向運作，而這點值得精確說明。

Qwen2.5-Omni 的數字已經夠舊，部分已透過使用獲得驗證。一個已有十九個月大、擁有廣受引用的基準地位、十年的下游量化成果以及龐大安裝基礎的模型，在任何正式意義上都不是已獲證實的可靠項目，但它的主張已有很長時間可供反駁，卻始終未被反駁。尤其是記憶體數字，當初是作為工程限制條件而非行銷素材發布的，而它們的表現也確實像工程限制條件。

MiniCPM-V 4.7 的數據已經過了兩週，卻仍是零外部驗證。該模型於 10 月 6 日在沒有文件的情況下發布，而模型卡、授權條款與宣稱部分則在 10 月 12 日上線。目前仍沒有評估表、沒有技術報告，也沒有任何第三方公布結果。唯一有實際公布數據的地方，是另一個獨立的 DSpark 草稿檢查點，其每步接受 token 數數據出自 OpenBMB 自家，而該實驗室尚未為母模型公布這些數據。

所以，對這個新模型的正確立場是：把架構視為已知（它就在設定檔裡），把發布內容視為真實存在（權重以六種格式存在），並把每一項效能數字都視為有待第二意見的宣稱。最後這一點並非永久狀態。這只是 10 月 13 日當下的情況。

執行其中任何一個，以及路由器的用途是什麼

這兩個都是你自己提供服務的檔案。MiniCPM-V 4.7 35B-A3B 與 Qwen2.5-Omni 都不在 OrcaRouter 的託管目錄中，而且這裡沒有任何內容應被解讀為我們有在路由它們——MiniCPM-V 4.7 是兩週前才發布的檢查點，若要以未量化方式執行，你需要兩顆加速器；而 Qwen2.5-Omni 是 2025 年的開放權重模型，實務上最適合的運行環境是由你自己營運的 vLLM 執行個體。

路由器真正發揮價值的地方，在於那條線的另一側。多數執行自架視覺模型的團隊，仍然需要一個託管模型來處理本地模型無法勝任的情況——長程推理、工具使用，以及 MiniCPM-V 4.7 不接受的音訊輸入。OrcaRouter 讓 200 多個託管模型共用同一把金鑰，以各供應商的定價原價轉供，我們不加收任何費用，並在供應商服務品質下降時自動容錯切換，這意味著加入第二個模型只是路由設定的變更，而不是再簽一份合約。與 MiniCPM 模型最接近的託管形態是 Qwen3.6 35B A3B——總參數 35B、啟用參數 3B、262K 上下文，支援文字、圖像、影片輸入——每百萬輸入 token 0.25 美元、每百萬輸出 token 1.48 美元，這是衡量自架究竟能省下多少的合理基準。

哪一個，以及何時？

如果你需要音訊或語音功能，就選 Qwen2.5-Omni；如果你想要一個背後有十九個月部署實績的模型，也選它；或者，如果 32K token 以及每分鐘影片 60 GB 的上限落在你的預算之內，那同樣選它。它的限制是已知且有文件記載的，而這在你準備出貨時反而是一項優點。

如果你的問題在於長視覺上下文與文字輸出，如果你想要的是寬鬆授權，而且如果你願意當個早期採用者——因為你確實就會是早期採用者——那就選 MiniCPM-V 4.7 35B-A3B。沒有第三方跑過它，裝置端的主張尚未被重現，而且基準測試根本不存在。你換到的是：一個有文件記載、可量化、支援多種執行環境的模型，具備 262K 視窗與一套看似合理的效率說法，而且你會成為那個親自查明這套說法是否站得住腳的人。

能改變答案的是：一份來自 OpenBMB 的基準測試表，或 DSpark 草稿中可重現的接受長度——仍然是為這個系列取得外部數字最便宜的路徑。不會改變答案的是更多時間。十九個月並沒有讓 MiniCPM-V 4.7 獲得聽的能力，而路線圖上也沒有任何跡象顯示這即將到來。