WeVisOne-VL-2B vs MiniCPM-V 4.7 1B：相差 0.45B，各司其職

名稱暗示了二比一的差距。檢查點卻不是這麼回事。MiniCPM-V 4.7 1B 以 bfloat16 形式提供 1,554,476,272 個參數，而 WeVisOne-VL-2B 約有 20 億個——所以它們之間真正的差距大約是 4.5 億個參數，而不是 10 億個。把它們放在同一張磁碟上，佔用的空間相當。把它們放在同一項任務上，它們會徹底崩潰，因為 MiniCPM-V 4.7 1B 是為了閱讀文件、觀看影片並就其進行對話而打造，而 WeVisOne-VL-2B 則是為了尋找物件並回傳遮罩而打造。

兩者皆採用 Apache 2.0。兩者都夠小，足以讓想以單一 GPU 進行開發建置的人感興趣。兩者都很新——MiniCPM-V 4.7 1B 於 2026 年 10 月 6 日上傳，並在 OpenBMB 的發行說明中標註為 10 月 12 日；WeVisOne-VL-2B 則是 10 月 22 日。這種相似與差異的組合，正是這組配對值得用一頁來討論的原因：幾乎每一項主要規格都很接近，但幾乎每一種實際用途卻不然。

首先，更正後的名稱

OpenBMB 的命名方式相當寬鬆，這種鬆散已在比較表中造成混淆。名為 1B 的模型依其自身 safetensors 中繼資料有 15.5 億個參數；廠商資料在不同地方則分別寫成 1.3B 和 1.38B。262,144 個 token 的上下文長度是真的，並且設定在模型設定中。其架構為 24 層、隱藏維度 1024 的文字主幹，衍生自 Qwen3.5，採用線性注意力與完整注意力 3:1 的比例，搭配一個 27 層、以 980 像素圖塊運作的 SigLIP2 風格視覺塔，以及可選的 4× 或 16× 視覺 token 壓縮模式，以細節換取每次請求的成本。

騰訊的命名更為嚴謹。WeVisOne-VL-2B 是基於 Qwen3-VL 打造的 20 億參數模型，另有一個獨立的 9,511,460 參數像素解碼器，模型卡稱其為「必需的核心元件，而非可選的附加元件」。這個解碼器在部署層面上絕非可忽略的細節：少了它，模型只會輸出邊界框與點，所有遮罩或去背輸出都不復存在。

所以正確的說法不是「小對大」，而是 1.55B 對 2B——權重相差 29%——且輸出契約完全不同。

兩套永不相交的基準詞彙

這是大多數比較會弄錯的部分，因此值得在任何數字出現之前先說明。OpenBMB 在通用多模態基準上評估 MiniCPM-V 4.7 1B：OCRBench 86.1、MMMU 56.89、MathVista 74.30、MMBench 83.17、MMStar 69.53、MMMU-Pro 38.03、MathVerse 60.41、CharXiv Reasoning 48.8、LongVideoBench 53.4 與 MotionBench 54.55。這些是廠商自行跑出的數字，主要以圖表而非附有評測框架細節的表格呈現，且尚無獨立機構重現這些結果。

騰訊在感知基準上評估 WeVisOne-VL-2B，卻完全沒有回報任何通用多模態分數。在其七個表格中，完全沒有 MMMU、沒有 MMBench、沒有 MathVista、沒有 DocVQA，也沒有任何圖像描述結果。它改為回報的是任務特定指標：偵測 F1、計數完全匹配、指向 F1、OCR 定位 F1、分割 cIoU 與去背誤差。

OCR 上的衝突最為明顯，因為兩個模型都宣稱自己具備這項能力。MiniCPM 的 86.1 是 OCRBench——一項轉錄分數，問的是模型是否正確讀出字元。WeVisOne 的 OCR 數字則是 0.5 IoU 閾值下的定位 F1：SROIE 上為 62.1、ICDAR2015 上為 42.6、TotalText 上為 42.5、HierText 上為 30.5，衡量的是模型是否在文字周圍畫出正確的框。一個模型可以在一項上表現優異，在另一項上表現平庸。印出「86.1 對 62.1」會是在拿拼字測驗跟指認測驗相比。

沒有任何一項基準測試能讓兩個模型都以相同方式計算並回報數字。這不是修辭上的誇飾——這是本次比較的核心發現，而這意味著你所看到的這兩個模型的任何排名，都是由無法相互比較的部分拼湊而成的。

262,144 個 token 能換來什麼，以及 WeVisOne 不肯說的事

MiniCPM-V 4.7 1B 發佈了 262,144 個 token 的上下文，以及一條預設最多接受 128 幀、每幀一個切片的影片路徑。這是一台處理文件與影片的機器：長篇 PDF、多頁掃描檔、一分鐘的影片片段。4× 與 16× 壓縮切換之所以存在，正是因為保留那麼多視覺細節的代價高昂，而 OpenBMB 讓你能按每次請求選擇要保留多少。

WeVisOne-VL-2B 並未公布上下文長度。模型卡未提及此事；論文的訓練階段以 4,096 與 8,192 個 token 執行，而推論時每張圖像上限為 1,960 個視覺 token，並採用貪婪解碼。這些都不是部署視窗，騰訊也未佯稱其中任何一個是。它還直接拒絕影片網格——像素解碼器僅支援圖像、單輪、無思維鏈。

這種不對稱說明了各家廠商分別為何最佳化。OpenBMB 最佳化的是單一模型能吞下多少輸入。Tencent 最佳化的是單一模型能多精確地指出它吞下了什麼，然後對輸入類型劃下嚴格界線，以讓解碼器保持簡單。

每一個實際上在哪裡執行

MiniCPM-V 4.7 1B 的部署範圍明顯更廣，遙遙領先：支援 Transformers 5.18 及更新版本、vLLM、SGLang、llama.cpp 與 Ollama，並提供 GGUF、AWQ、GPTQ、FP8、bitsandbytes 與 OpenVINO 版本，另支援 iOS、Android 與 HarmonyOS，且獲得 Rockchip、Arm 與 Apple 等廠商的首日晶片支援。OpenBMB 還推出獨立的 2.13 億參數 DSpark 草稿模型，用於推測解碼。

WeVisOne-VL-2B 有自己的 GitHub 套件、一條 Transformers 路徑，且模型卡上列出了 vLLM 與 SGLang。沒有 GGUF。沒有量化版本。沒有 ONNX。沒有行動端方案。而其稠密輸出是 stride-1、全解析度的 alpha matte，這意味著記憶體用量會隨影像規模擴展，而非隨參數量擴展——一個 2B 模型，持有成本低，但在 4K 下執行未必便宜。

如果你的目標是手機，本節的比較就到此為止。MiniCPM 正是為這項限制而打造，並在其格式清單中明言這一點。WeVisOne 則否，也未聲稱如此。

它們唯一打平的地方：授權條款

兩者皆採用 Apache 2.0。沒有營收門檻、沒有使用領域限制，也不需另行簽訂商業協議。在這個類別中，Liquid AI 採用自家設有營收上限的授權，Moondream 則採用原始碼可見授權，並附帶不得提供第三方服務的授予條款；在此情況下，兩個這種規模的 Apache 2.0 視覺模型值得注意——這意味著授權並非這裡的決定性變數，而這點不尋常到值得直言。

這也消除了團隊選擇較小模型最常見的理由。如果兩者都通過法律審查，你選的是能力與部署方式，而不是合約條款。

在它們之間做選擇

先問輸出要餵給什麼。如果它要餵給文件儲存庫、聊天視窗、影片索引或下游語言模型，MiniCPM-V 4.7 1B 就是你要的規格：它能產生長篇文字、能容納長輸入，並以可在消費級硬體上執行的格式提供。

如果它要餵入合成管線、影像編輯器、目錄清理工作或感興趣區域裁切，WeVisOne-VL-2B 就是你想要的形態：框、點、二值遮罩與連續 alpha 遮罩，外加一種比任何基準測試都更重要的拒絕行為。Tencent 回報，在 RefCOCOg 上針對物件不存在的查詢，拒絕率為 50.2，而同表上兩個專門的定位模型分別為 0.5 與 0.6。如果你的大多數影像並不包含你正在尋找的東西，那個數字就是能幫你省錢的數字。

還有第三種情況，是兩者彼此組合而非競爭：一個文件管線，由 MiniCPM 讀取頁面，並由 WeVisOne 找出讀取步驟需要隔離的區域——簽名、印章、產品照片。這與其說是路由問題，不如說是管線設計問題，而這正是 OrcaRouter 產品真正派得上用場、而非硬加上去的地方。這兩個模型都不在我們的目錄中；兩者都是自行託管，我們不會暗示相反。我們提供的是託管的那一半：只要一組 API 金鑰就能使用超過 200 個模型，價格為供應商牌價且不加價，並在供應商服務降級時自動容錯移轉，以及模型融合；模型融合讓一組模型共同回答同一個問題——當轉錄內容即將進入資料庫，而你想在它進入前取得第二意見時，這就很有用。

要記住的數字

不是 1B 和 2B——而是 1.55B 和 2B。這種命名讓它們看起來像是不同的量級，而模型檢查點又讓它們看起來像是彼此相近的鄰居，這兩種印象都具誤導性。區分 MiniCPM-V 4.7 1B 與 WeVisOne-VL-2B 的，不是規模、授權條款，甚至也不是新舊程度。而在於：一個回傳文字，另一個回傳像素；而且，無論是哪一家廠商公布的基準測試，都無法拿另一家的來相減，從而告訴你哪一個更能勝任你真正需要它扮演的角色。