WeVisOne-VL-4B 與 UI-Venus-2-9B：一個回傳遮罩，另一個回傳點擊

把同一張結帳頁面截圖交給 WeVisOne-VL-4B 和 UI-Venus-2-9B，會得到兩類不同的答案。前者給你幾何資訊：購物車圖示外的一個框、折扣欄位外的一層分割遮罩，以及把產品照片從背景中裁出的 alpha 去背遮罩。後者給你一個動作：下一個點擊的座標，以及產生該座標的推理過程。騰訊微信視覺團隊在沒有發布公告的情況下，將 WeVisOne-VL-4B 發布到 Hugging Face，並將其技術論文標註日期為 2026 年 10 月 23 日；inclusionAI 的 UI-Venus-2-9B 自 2026 年 8 月 26 日起即可下載。它們被歸在同一模態標籤下，但彼此並非替代品。

這使得這場比較的核心存在一個不尋常的問題：這兩個模型沒有任何共同的基準測試。兩張成績表上沒有任何一項分數同時出現。兩者都未經獨立評測，都沒有由推論服務供應商部署，也都沒有公布價格。能夠誠實比較的，是兩者各自輸出什麼、各自如何被訓練成拒絕回答、執行成本是多少，以及你會依哪一種授權條款發布——這正是本文所做的，而且每當出現廠商自報的數字時，都會標明其為廠商自報。

這兩個模型回答的並不是同一個問題

WeVisOne-VL-4B 是一個感知模型。它建構於 Qwen3-VL 骨幹之上，並加入一個必需的 960 萬參數像素解碼器——mask_decoder.pt，作為第二個產物隨附——該解碼器會將語言模型的框預測轉換為實例遮罩，再轉換為步長為 1 的 alpha 遮罩。座標會以專用 token 輸出，範圍涵蓋 <0> 到 <1000>，並正規化至影像；而在密集任務中，特殊的 <OBJ> token（id 152,678）會為每個框收尾。論文中的任務清單是一系列幾何任務：開放詞彙偵測、指稱定位、計數、指向、OCR 定位、指稱分割，以及可提示的 alpha 遮罩。

UI-Venus-2-9B 是一個代理。它從 Qwen3.5-9B 初始化，並透過中期訓練、離線步驟級強化學習與多教師同策略蒸餾，在五個任務家族中接受僅以螢幕截圖進行互動的訓練——這五個家族分別是視覺接地、CAPTCHA、行動裝置、網頁與電腦。它的輸出是封閉觀察–推理–行動迴圈中的一個動作，而其 vLLM 配方將 --max-model-len 262144 與 --reasoning-parser qwen3 搭配，因為它會在每個動作之前產生推理符元。

把規格並排對照，差異立刻一目了然：

• 輸出內容 — 來自 WeVisOne-VL-4B 的框、點、遮罩與 alpha 遮罩；來自 UI-Venus-2-9B 的一個動作及其推理軌跡。

• 主幹 — Qwen3-VL 用於 WeVisOne-VL-4B；Qwen3.5-9B 用於 UI-Venus-2-9B。不同世代、不同系列的文字堆疊。

• 大小 — 儘管名稱是「4B」，儲存庫上列出的是 5B 參數，另外還有一個獨立的 9.6M 參數解碼器；UI-Venus-2-9B 是 9B 稠密模型，分佈於四個 BF16 分片，約 18.8 GB。

• 權重格式 — WeVisOne-VL-4B 的模型卡上採用 F32 safetensors，這在此規模下並不尋常，且使得下載檔案比參數量所暗示的還要大；UI-Venus-2-9B 則為 BF16。

• 授權條款 — WeVisOne-VL-4B 採用 Apache 2.0；UI-Venus-2-9B 則「待最終確認」。

實務上的後果是：你不能拿一個去換另一個，而任何幫你選出贏家的文章，回答的都是你沒問的問題。一個能回傳完美遮罩的感知模型仍然不會點擊。一個能完美點擊的代理程式仍然無法交出你產品攝影想要的去背遮罩。

在它們真正重疊之處：兩支團隊都教各自的模型說不。

這是兩個版本都做出的同一項設計決策，也是這對組合中最有意思的地方。開放詞彙定位模型會以一種特定且代價高昂的方式失敗：在沒有滅火器的房間裡要求找出滅火器，而一個總是有問必答的模型會自信地把散熱器框選出來。在下游，這要麼是資產管線中的幻覺物件，要麼是自動化迴圈中點錯的目標。

WeVisOne-VL-4B 透過傳回 None 來處理，而論文將拒答率作為與準確率並列的獨立指標來報告。在 RefCOCOg 上，4B 模型達到 67.4 的拒答率，而其 Qwen3-VL-4B 基礎模型為 18.8。在 WeChat 內部的 WeRef-Bench 上，它報告的拒答率為 96.4，基礎模型則為 61.9；在 Ref-ZOM 上為 86.0，UniPixel-7B 則為 0.3。這些是今天發表的一篇論文中的自我報告數據，且拒答基準大多為作者自建——請將方向視為可信，但確切差距未經證實。

UI-Venus-2-9B 從代理端處理同一個問題，承襲 UI-Venus 系列的拒絕感知定位能力：模型經過訓練，當要求的元素不在畫面上時會拒絕作答，而非猜測一個看似合理的位置。其定位數據——ScreenSpot-Pro 73.0、VenusBench-GD 77.1、OSWorld-G-R 78.5——為廠商自行提報，且該說明卡明確指出，這並不能消除有害動作的風險，並建議採取人工確認加上應用層級的防護措施。其安全表格則顯示了它確實聲稱的效果：在 OSHarm 上的攻擊成功率為 11.3%，而 Qwen3.5-9B 基礎模型為 25.3%；在 OSBlind 上則為 48.8%，對比 79.4%。

所以這兩個模型都是由親眼見過定位器說謊的團隊所打造，而兩者都寧可棄權，也不追求覆蓋率。如果你的應用程式的失效模式是「自信地答錯」，那麼這項共同的優先考量，比參數量更為重要。

Tencent 模型卡未顯示的數字

迄今每篇關於 WeVisOne-VL-4B 的報導都說了同一件事，而且說得沒錯：模型卡並未公布任何基準測試結果。技術論文則有公布，該論文於 2026 年 10 月 23 日發布，這使得這部分內容成為整件事中尚未流傳開來的部分。這些全都是作者自行報告，無一經過獨立重現，而且模型才問世一天——因此請把這些當成有輪廓的主張，而非已成定論的結果。

與其自身的 Qwen3-VL-4B 基礎模型相比，這些差距大到即使大打折扣後仍然值得關注：

• 偵測，COCO 零樣本平均 F1 — WeVisOne-VL-4B 為 57.1，Qwen3-VL-4B 為 48.7；而在 LVIS 上則為 55.3 對 44.0。

• 偵測，Dense200 平均 F1 — 71.3 對 15.2。這不是論文表格裡的筆誤；密集小物件場景正是基礎模型崩潰之處。

• 指稱偵測方面，RefCOCOg 驗證集 — 80.8 對 74.1，拒絕率為 67.4 對 18.8。

• 計數，PixMo-Count 驗證集精確匹配 — 93.7 對 69.6；在 MixCount 驗證集上，42.0 對 3.5。

• 指向、PointBench F1 — 71.9 對 57.1。

• OCR 定位，SROIE 平均 F1 — 68.1 對 40.4，並領先 PP-OCRv5 的 58.6。

• 指稱分割，ReasonSeg 驗證 gIoU — 71.2，而 LISA-13B 為 65.0。

• 可提示式去背，AM-2K 框提示 MAD 為 5.0，SAM2-Matting 則為 12.1；在 WeRefMat 指稱提示上為 9.8，對比 51.9。

去背結果才是值得停下來細看的部分，因為這是這個價位帶中，沒有其他東西能透過提示詞提供的能力。向視覺語言模型要求「以 alpha 遮罩呈現的那個人」，並得到一個在 MAD 上勝過 SAM2 去背流程的 stride-1 輸出，這和附帶遮罩的偵測頭是截然不同的產品。這也是論文對自家 4B 最不客氣的地方：在 P3M-500-NP 框提示上，2B 模型的得分是 6.6 MAD，而 4B 是 7.3，所以更大的變體並非一律更好，而作者如實刊出這一點。

UI-Venus-2-9B 的數字衡量的是什麼，以及為何它們無法轉移

把這兩套基準測試套件並排來看，不可比性就不再只是技術細節。UI-Venus-2-9B 的主要結果，全都是環境中的終態成功率：在卡片預設步數預算下，AndroidWorld 為 80.2、OSWorld-Verified 為 70.8、WebVoyager 為 90.8、Online-Mind2Web 為 74.0、MobileWorld 為 65.8，而在 100 步時為 75.2。這些數字衡量的是任務是否完成，並把感知、規劃、記憶與錯誤恢復全都摺疊進單一數字。

最接近共同比較軸的是 GUI 定位。UI-Venus-2-9B 在 ScreenSpot-Pro 上拿到 73.0；這個基準測試是在高解析度螢幕截圖中定位小型介面元素，而 WeVisOne-VL-4B 並未回報這項結果。WeVisOne-VL-4B 回報了 OCR 定位與密集指向的結果，而 UI-Venus-2-9B 並未回報這些項目。因此，誠實的說法是：這項比較中最有用的一個數字目前還不存在：讓 WeVisOne-VL-4B 跑 ScreenSpot-Pro，就能看出一個 5B 的感知專家是否能在尋找按鈕上勝過一個 9B 的代理；而在有人實際跑過之前，任何拿這兩個模型在定位能力上排名的人，都只是在猜測。

代理自身的測試套件也將其弱點公開呈現。在 OSWorld 2.0 上，9B 模型取得 7.5 的部分分數與 0.0 的二進位分數；27B 的同系列模型則達到 13.2 的部分分數與 2.8 的二進位分數。此規模的模型尚未解決長時程桌面工作，而卡片也如實說明了這一點。

為它們提供服務的差距比基準差距更大。

對一個正在決定下週要執行什麼的團隊來說，營運上的差異會比任何分數都更重要。UI-Venus-2-9B 是單一模型，只要用一個 vLLM 指令就能啟動，並提供與 OpenAI 相容的端點，張量平行度為 1。WeVisOne-VL-4B 需要從 GitHub 取得其推論套件，外加獨立的解碼器產物，並且要透過它自己的 WeVisOneVL(...) 包裝函式並帶入 task 參數來呼叫——predict(image, task="matting", query="person", temperature=0.0)。其模型卡文件記載了 Transformers、vLLM 與 SGLang 路徑，但像素解碼器並非選用項：單靠語言模型無法產生遮罩。

記憶體佔用比參數量所暗示的更接近。在 bf16 下，5B 主幹在解碼器之前約為 10 GB，而 UI-Venus-2-9B 的四個分片約為 18.8 GB。就權重而言，兩者都能放進單張 24 GB 顯示卡；差別在於還剩多少空間留給上下文。

而在上下文方面，這兩份配置的一致之處很容易被過度解讀。WeVisOne-VL-4B 的配置提供 262,144 的 max_position_embeddings——與 UI-Venus-2-9B 以其 262,144 最大模型長度所提供的上限相同。但兩者用途不同：智能體將長上下文視為情節記憶，保存任務的截圖歷史，而感知模型公佈的評估則以每張影像 1,960 個視覺 token 運行。對於單輪、純影像模型而言，256K 視窗是上限，而非已展示的能力，且模型卡將影片網格列為直接被像素解碼器拒絕的項目。

許可證：其中一個已確定，另一個尚未。

WeVisOne-VL-4B 採用 Apache 2.0 授權，其中由騰訊撰寫的程式碼也適用相同條款。你可以閱讀它、分支它、將它出貨到產品中，而不必為此諮詢律師。

UI-Venus-2-9B 的模型卡寫道，模型權重授權尚待最終確認，並會在公開發佈前補上；早先的 Apache-2.0 宣告是刻意未沿用，因為上游資料含有相互衝突的授權聲明。那句話自八月起就一直留在模型卡上，未曾改變。這不會阻止你評估該模型，也不會阻止大多數組織的內部使用——但這確實意味著，以那些權重建構的外部產品是建立在一個未解決的問題上，而再高的基準測試分數也無法解決這一點。如果你要為打算出貨的專案在這兩者之間做選擇，授權欄位會比準確率欄位更快幫你決定。

既然兩者都沒有標價，每一個各要多少錢？

這兩款模型都沒有廠商設定的每 token 價格。WeVisOne-VL-4B 的頁面指出，它並未由任何推論服務供應商部署；UI-Venus-2-9B 則沒有第一方端點，inclusionAI 也沒有公布費率表，因此第三方託管商對它收取的任何費用，都是該託管商的數字，而不是該團隊的。對這兩者而言，成本都是在您租用或自有的硬體上花費的 GPU 小時，這表示比較的重點不是「輸入價格 vs 輸出價格」，而是「我需要多少張顯卡，以及它每秒能處理多少張影像」。

兩篇論文都沒有公布吞吐量或延遲，因此對兩者來說，第二個數字都未知。可確定的是成本結構：UI-Venus-2-9B 在一個 episode 的每一步都要付出一次 9B 前向傳遞加上推理 token 的代價，而一個代理 episode 包含許多步。WeVisOne-VL-4B 每張影像要付出一次 5B 傳遞加上一次解碼器前向的代價，而一張影像就是一次呼叫。若你的工作負載是十萬張產品照片，感知模型的成本效益是按影像計算且可預測；若是瀏覽器任務，代理的成本會隨任務需要多少動作而增加，而這正是你無法從規格卡預測的數字。

這也正是路由層能真正發揮價值、而不只是口號的地方。今天這兩個模型都不在 OrcaRouter 上，本文也不會假裝它們在——WeVisOne-VL-4B 完全沒有推論供應商，而 UI-Venus-2-9B 是由第三方代管服務提供，並非來自我們自己的目錄。對於 OrcaRouter 確實有提供的模型，它提供的是橫跨 200+ 個模型、以 0% 加價計費的單一 OpenAI 相容端點，供應商定價原樣傳遞，因此廠商降價當天就能反映到你身上，而不是等到下一次合約續約。對於依序呼叫感知模型與代理模型的架構而言，路由 DSL 正是這種組合所在之處——兩次模型呼叫，同一個地方可替換任一段——而 自動容錯移轉能在其背後的模型於執行過程中劣化時，讓代理迴圈繼續運作。一旦這兩個模型其中任何一個登上供應商，那就是確認它是否適合納入你技術堆疊的最便宜方式。

該選哪一個

這項決定是一份職務說明，而非排名。

• 如果你需要的輸出是幾何資訊——要送入標註流程的邊界框、供編輯工具使用的遮罩、產品影像用的 alpha matte、密集航拍畫面中的物件計數，或附帶座標的 OCR——就選 WeVisOne-VL-4B。在開放的 5B 級別中，沒有其他模型能從文字提示回傳遮罩，而論文中相對於 SAM2 流程的 matting 數據，是這次發布中最強的主張。

• 如果你需要的輸出是完成一項任務——填好一份表單、操作一個應用程式、解開一組 CAPTCHA、透過螢幕截圖驅動一套桌面工作流程——那就選 UI-Venus-2-9B。它只要一行 vLLM 指令就能部署，並提供與 OpenAI 相容的端點，這樣的工作量是一天而非一週；而它的 AndroidWorld 與 WebVoyager 成績，正是你可以拿來對照自家環境的數字。

• 如果你需要獨立證據、已公布的價格，或可供出貨產品使用的確定授權，那暫時兩者都別選。UI-Venus-2-9B 的授權，以及兩個模型的基準測試，這三項全都缺。

• 如果你正在建構一個必須操作影像、而不只是點擊瀏覽畫面的代理，這兩者都要納入考量。有意思的是它們的組合方式：由 UI-Venus-2-9B 決定在哪裡行動，WeVisOne-VL-4B 則產出該動作所瞄準的像素級精準成品。這樣的組合每步要花兩次模型呼叫，換來的是單一模型都無法具備的精準度。

什麼會改變這個答案

四件事，依它們能推動它的程度排序。

WeVisOne-VL-4B 在 ScreenSpot-Pro 上的一次跑分。這是雙方都可能合理採用的唯一基準，也能判定一個規模只有一半的感知專門模型，是否能在本地化表現上勝過專門打造的 UI 代理。任何有 GPU 和一個下午的人都能產出它，卻沒有人做。

對任一模型進行獨立評估。本文中的每個數字都可追溯至模型卡，或由打造該模型的團隊所撰寫的論文。這在發布當天很正常，但它仍然是一項缺失。

UI-Venus-2-9B 的授權問題已有結果。「等待最終確認」已在卡片上掛了八週。若最終確定為寬鬆授權，這個代理就明顯更容易被推薦用於商業工作；若否，則問題會得到相反的答案。

無論是哪一方，第一方端點都是關鍵。目前兩家廠商都未提供自家模型的服務，這使得受眾僅限於願意運行服務堆疊的團隊；而在 WeVisOne-VL-4B 方面，則僅限於願意操作自訂推論套件的團隊。廠商公布費率後，成本比較將從算術問題變成單一明細項目。

在那之前，公允的總結是這樣的：騰訊推出了一套感知工具包，做到了此前任何小型開源模型都未曾做到的事，而且低調到其自家的基準測試表格至今尚無人讀過；而螞蟻集團在一個半月前發布了一款代理，更易於運行，授權卻更難。它們並非競爭對手。真正的錯誤，是因為另一個在兩者並不共用的基準測試上得分更高，就挑選其中一個。