MiniCPM-V 4.7 1B 對上 UI-Venus 2 9B：一個塞得進口袋，另一個得靠機架

MiniCPM-V 4.7 1B 與 UI-Venus 2 9B 之間的比較差距並不小，而這正是它有用之處。MiniCPM-V 4.7 1B 是 OpenBMB 推出的 15.5 億參數通用視覺語言模型，於 2026 年 10 月 6 日上傳，廠商發布說明標註日期為 10 月 12 日，採用 Apache 2.0 授權，小到足以在手機應用程式內執行。UI-Venus 2 9B 則是 inclusionAI 的 94.1 億參數 GUI 代理，於 2026 年 8 月 26 日發布，專門訓練來查看螢幕並決定點擊、輸入或滑動的位置，而且它需要前方有 vLLM 伺服器的 GPU。像這類發布背後的已記錄 AI 失敗與代理事件，都收集在 OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

把它們放進同一個句子裡，會引來錯誤的問題——哪一個比較好——而正確的問題其實是各自適合什麼用途。一個能塞進 1.8 GB 量化記憶體的通用視覺模型，和一個在 ScreenSpot-Pro 上拿下 73.0 分的螢幕代理，並不是彼此的替代品。它們是行動自動化堆疊中兩個不同的層次，而真正有趣的地方，在於這兩層之間的界線究竟落在哪裡。

兩份從遠處看很相似的工作

兩款模型都能接收螢幕截圖，並回傳描述其內容的文字。相似之處僅止於此。

MiniCPM-V 4.7 1B 能讀取影像並進行描述、轉錄、擷取或回答。問它收據總額是多少、表單欄位包含什麼、圖表是否呈現上升趨勢，或 PDF 的某一頁寫了什麼，它都會產生答案。它具備高解析度影像的切片控制、可切換的 4×/16× 視覺 token 壓縮比，以及影片的影格取樣參數。其文件涵蓋單圖對話、多圖對話、影片、OCR、PDF 解析與視覺定位——也就是文件與螢幕閱讀的工作負載。

UI-Venus 2 9B 會讀取螢幕並發出動作。它的卡片描述了一個封閉迴路：觀察介面、推理任務狀態、執行動作，並將環境的回饋納入下一次決策。輸出是座標點與動作序列，而非散文文字。在其周圍，inclusionAI 提供了參考提示、動作解析器，以及可執行的範例，涵蓋行動裝置、電腦、瀏覽器、grounding 與 CAPTCHA 任務。模型本身是一套策略，而圍繞著它的測試框架，則占了產品價值的一半。

那個區別在任何基準測試被參考之前，就已經決定了架構。需要讀取收據的手機應用程式採用第一種。需要在應用程式內完成任務的系統——點完結帳流程、填寫表單、解滑塊 CAPTCHA——則採用第二種，而且無論它的 OCR 多好，都無法以第一種替代。

執照是第一道篩選，而非基準。

UI-Venus 2 9B 的卡片包含一個多數報導都略過的發布狀態區段。在「Model weights」下，它寫著權重已包含在內；在「License」下，它寫著模型權重授權為 待最終確認，並會在公開發布前補上，且 Apache-2.0 聲明之所以刻意未沿用，是因為上游資料含有相互衝突的授權聲明。

把那段話讀兩遍。權重可以下載，基準測試已經公布，技術報告在 arXiv 上，而授權條款仍未確定。對研究團隊來說，這沒問題。對一家計劃在商業產品中推出螢幕代理程式的公司來說，這意味著法務審查無法結案。該模型最終可能採用 Apache 2.0，也可能不會，而從目前可取得的產物來看，根本無從得知。

MiniCPM-V 4.7 1B 以 Apache 2.0 釋出，完全沒有這種模糊地帶。光是這一點，就讓這兩款模型中的一款在大量商業用途中被排除——不是因為它比較差，而是因為授權懸而未決是沒人會編列預算的時程風險。

硬體算術，在任何計分之前

• 權重 — 1.55B 稠密模型，BF16 約 3.1 GB，Q4_K_M 下為 0.67 GB，另加 0.90–1.11 GB 的視覺投影器；對比 9.41B，BF16 約 18.8 GB，分散於四個 safetensors 分片 • 執行環境 — iOS、Android 與 HarmonyOS 應用程式；Rockchip、Houmo、Intel、AMD 與 Arm 的首日晶片支援；對比 GPU 服務路徑，已於 vLLM 以 --max-model-len 262144 與 --reasoning-parser qwen3 記錄 • 上下文 — 帳面上為 262,144 個 token，全長時 KV 快取的代價高於權重本身；對比 262,144 個 token，繼承自 Qwen3.5-9B 基礎模型 • 視覺堆疊 — 27 層、1152 隱藏維度的編碼器，處理 980 像素圖塊，並具備編碼器內部的 token 壓縮；對比 Qwen3.5-9B 視覺塔，沿用自基礎模型 • 授權 — Apache 2.0；對比尚待確認，且明確未提出 Apache-2.0 聲明 • 評估風格 — 五個文字敘述的數字，加上僅以圖表呈現的比較；對比涵蓋行動裝置、電腦、網頁、grounding、CAPTCHA 與安全性的完整數值附錄 • 獨立評估 — 截至本文撰寫時，兩款模型皆無；對比亦無，不過 arXiv 2609.00028 的技術報告是一份可供第三方查核的實質性成果

這裡的記憶體差距大約是一個數量級：量化後為 1.8 GB，對比 BF16 的 18.8 GB；若採用 4-bit 量化，則約為 5 GB。這就是應用程式與服務之間的差別。這也是為什麼這兩個模型通常會在不同文章中被討論——一個是邊緣部署問題，另一個是推論成本問題。

9B 在哪裡證明它的規模

UI-Venus 2 9B 的各項數字，全部由廠商在其模型卡與技術報告中回報，使其接近 10B 以下 GUI 模型級別的頂端。在衡量高解析度專業軟體上元素定位能力的 ScreenSpot-Pro 上，它回報 73.0。在 VenusBench-GD 上為 77.1。在 OSWorld-G-R 上為 78.5。在 AndroidWorld 上為 80.2。在 WebVoyager 更新後的 595 項任務劃分上為 90.8。在 OSWorld-Verified 上為 70.8。在其自家的 VenusBench-CAPTCHA 上，於八種互動類型中為 78.1 pass@1。

這些不是 10 億參數通用模型會產出的數字，也本就不是要如此。讓這些數字可信而非裝飾性的，是訓練描述：一個由 170 多個多語言應用程式組成的行動裝置池、一個涵蓋 19 個類別共 4,000 多個網域的網路池、三階段訓練（多模態中期訓練、跨五個任務族群的離線強化學習、多教師同策略蒸餾），以及一套驗證機制，該機制建立在與任務相關的視覺關鍵點上，並採用多模型投票，而非由單一評審檢視最終畫面。這張卡也報告了安全結果：在 OSHarm 上的攻擊成功率為 11.3%，在 OSBlind 上為 48.8%，相較於 Qwen3.5-9B 基礎模型的 25.3% 與 79.4%；並將其定位為與該基礎模型的比較，而非絕對穩健性主張，這是正確的定位。

這一切都不會轉移到 1B 模型上。GUI 代理能力是訓練出來的，而不是從一般視覺能力中自然湧現的；再高的 OCR 準確率，也無法取代一個知道「下一步」按鈕有何作用的策略。

在 1B 無論如何都會勝出的地方

三個名次，而且它們不是安慰獎。

延遲與可用性。 本地的 1B 模型沒有網路往返、沒有佇列、沒有供應商中斷，也沒有每次請求的成本。對於一天使用五十次的掃描功能而言，這就是整個產品體驗。放在 vLLM 伺服器後面的 9B 模型很快——但它的快，就跟任何託管模型一樣，而一旦連線中斷，它就不再快了。

隱私源於設計本身。收據、身分證件、醫療表格或私人對話的截圖，都可以留在裝置上。這不是行銷口號；而是你能在受監管產業中推出的功能，與不能推出的功能之間的差別。UI-Venus 2 9B 自身的安全評估，關注的是模型在伺服器端出現不當行為。而 1B 的隱私特性，則是影像永遠不會離開手機。

邊際成本。用託管的 9B 模型讀取一張截圖，每一次請求都要花錢，每一次請求，永遠如此。用本地的 1B 模型來讀，代價則是電池電量。低用量時，託管方案比較便宜；高用量時——外勤應用程式裡的掃描器、無障礙工具、一萬張收據的批次處理——本地模型是唯一邊際成本趨近於零的選擇。

大多數團隊最終實際建構出來的技術堆疊

不是在兩者之間做選擇，而是將它們層層疊加。

裝置端的 1B 模型負責感知：讀取螢幕、擷取文字、找到欄位、描述當下內容。大多數時候這樣就夠了，請求從不離開手機。當任務需要採取動作——點這裡、滑那裡、完成這個流程——工作就交給代理程式，而代理程式需要更大的模型與動作詞彙。

那個交接正是路由層發揮價值的地方，值得精確說明它做了什麼、沒做什麼。OrcaRouter 透過一個相容於 OpenAI 的端點，以 0% 加價提供 200 多個託管模型，將各家供應商的標價原樣傳遞，並具備自動容錯移轉，以及可在一次呼叫中同時容納主要與備援模型的路由 DSL。這所促成的模式並不花俏，卻很實用：手機先試用本地的 1B 模型，應用程式再把困難案例透過它用於其他一切的同一個金鑰，升級到託管視覺模型；而某家供應商狀況不佳時，會變成一次容錯移轉事件，而不是服務中斷。MiniCPM-V 4.7 1B 和 UI-Venus 2 9B 都不在該目錄中——兩者都是你自己執行的檢查點——所以路由器是整個堆疊外圍的層，而不是呼叫這兩個模型中任一個的方法。

兩種值得事先規劃的失效模式

第一個是當作代理使用的 1B 通用型模型。它能正確讀取螢幕畫面，卻完全不知道接下來該做什麼。如果你的產品需要完成一個流程，而不是描述流程，那麼 1B 就是錯誤的工具，再怎麼寫提示詞也無法補救。

第二個是依模型卡授權狀態發布的 9B 代理程式。UI-Venus 2 9B 的模型卡指出，授權仍在待定，且 Apache-2.0 聲明是刻意暫緩發布。在此事釐清之前，無論 ScreenSpot-Pro 的分數多好，該模型就商業用途而言仍是研究產物。圍繞「它大概會是 Apache 2.0」來做規劃的團隊，正承擔他們尚未計入成本的時程風險。

這個選擇實際上取決於什麼

如果問題是「我能不能在手機上、離線、免費，用一個我可以隨產品交付的授權來讀取這張截圖」——MiniCPM-V 4.7 1B 的答案是肯定的：量化後約 1.8 GB，採用 Apache 2.0 授權，而你唯一需要確認的，是自己裝置的記憶體餘裕。

如果問題是「這個模型能不能實際操作介面，而不只是描述介面」——UI-Venus 2 9B 正是具備訓練、基準測試與評測框架的那一個，而且在它需要其他任何東西之前，它先需要一張 GPU 和一項授權決定。

如果問題是「兩者都要，放在同一個產品裡」——那麼你正在打造的是兩層式系統：由 1B 在裝置上做感知，由代理在伺服器上做行動；而工程工作的重點在於兩者之間的交接，而不是在兩者之間做選擇。

這個比較看起來一面倒，因為它確實如此。1B 的通用型模型和 9B 的 GUI 專家不屬於同一個量級、同一個部署級別，也不處於同一個授權定位。錯誤會是把它解讀成「其中一個更好」。它們回答的是不同問題，而最快挑選的方法是寫下你實際在問哪個問題。