WeVisOne-VL-2B 與 UI-Venus-2-9B：名稱所隱藏的規模差距

九十億參數並不是這場對決所說的那樣。按照大多數人的寫法——WeVisOne-VL-2B 對上 UI-Venus 2.9B——這組搭配讀起來像是兩個權重相近的小型視覺模型，是一場由騰訊微信視覺團隊全新的 2B 檢查點，對上螞蟻集團 inclusionAI 稍大一些的模型之間的公平較量。這個假設的後半部分是錯的。UI-Venus-2-9B 是九十億參數的 UI-Venus 2，從 Qwen3.5-9B 初始化；其中的「2」是世代，不是規模。WeVisOne-VL-2B 於 2026 年 10 月 22 日推上 Hugging Face，是基於 Qwen3-VL 主幹的二十億參數模型。因此，真正的比較是：一個小上四倍半、主幹世代更舊，而且會給出完全不同類型答案的模型。

它同樣是在沒有發表會的情況下登場。有一個 Hugging Face 儲存庫、一個只有單一初始提交的 GitHub 儲存庫、一篇 arXiv 論文和一個研究專案頁面——卻沒有廠商公告、沒有部落格文章，也沒有把這些串在一起的定價頁面。這也決定了本文能誠實做到哪些事。權重、架構、授權條款文字和論文表格如今都可查證。獨立評測、吞吐量、延遲與價格則否，因為它們目前都還不存在。Tencent 的模型卡完全沒有公布任何基準測試數字；下文歸屬於 WeVisOne-VL-2B 的每一項分數，都來自其作者自己的七張任務表格，並如實標註來源。UI-Venus-2-9B 較舊且文件較完整，但其數字同樣完全是自報的。

這兩個名稱實際上描述的是什麼

WeVisOne-VL-2B 是一個感知模型。給它一張影像和一個短語，它會回傳幾何資訊：一個邊界框、一個點、一個計數、一個二元遮罩，或一張連續的 alpha 遮罩。其語言端會將座標輸出為專用 token，範圍涵蓋 <0> 到 <1000>，並依影像正規化；在密集任務中，它會以一個位於 id 152,678 的特殊 <OBJ> token 結束每個框。這些 token 在 mask_decoder.pt 讀取其背後的隱藏狀態之前，都只是標記——這是一個必要的 9,511,460 參數構件，作為第二個檔案隨附，模型卡將其描述為「必要的核心元件，而非可選的附加元件」。沒有它，你得到的是框。有了它，你得到的是遮罩和步長為 1 的 alpha 遮罩。

UI-Venus-2-9B 是一個代理。交給它一張螢幕截圖和一項任務，它就會回傳一個動作：下一次點按、點擊或按鍵，以及產生該動作的推理 token，整個過程位於封閉的觀察—推理—行動迴圈中。它是在僅以螢幕截圖進行的互動上訓練而成，涵蓋 grounding、CAPTCHA、行動裝置、網頁與電腦操作；其已發布的 vLLM 設定方案將 262,144 的最大模型長度與 Qwen3 推理解析器搭配，因為推理軌跡會先於每個動作輸出。

把兩者並排放，立刻就能看出不匹配：

• 回傳內容 — 來自 WeVisOne-VL-2B 的邊界框、點、計數、OCR 範圍、遮罩與 alpha matte；以及來自 UI-Venus-2-9B 的一個螢幕動作及其推理軌跡。

• 參數 — WeVisOne-VL-2B 為 2B，加上獨立的 9.5M 解碼器；UI-Venus-2-9B 為 9B 稠密模型，權重約為 4.5 倍。

• 主幹 — WeVisOne-VL-2B 採用 Qwen3-VL，28 個文字層、隱藏維度為 2,048；UI-Venus-2-9B 則採用 Qwen3.5-9B。不同的世代，不同的文字堆疊。

• 磁碟上的權重 — 兩者皆為 bfloat16，但 2B 的約 4GB，而 9B 則是四個 BF16 分片、總計約 18.8GB。

• 上下文上限——兩者皆為 262,144 個位置，分別讀取自 WeVisOne-VL-2B 的設定檔與 UI-Venus-2-9B 的服務指令。兩家廠商都未展示使用任何類似的功能。

• 已發表的證據 — Tencent 的論文中有七個任務表格，模型卡上卻一個也沒有；inclusionAI 的模型卡上有一長串廠商基準測試清單，論文中則沒有任何表格。

• 授權條款 — 騰訊撰寫的程式碼採用 Apache 2.0；UI-Venus-2-9B 權重則「待最終確認」。

實際後果是，你無法用其中一個取代另一個；任何硬要替你選出贏家的文章，都是在回答你沒問的問題。一個能回傳完美遮罩的感知模型，仍然無法按下按鈕。一個能完美操作應用程式的代理，仍然無法把你想要用於產品照的去背圖交到你手上。

支持較小模型的理由，比 2B 對比 9B 所顯示的更為有力。

看到 2B 緊鄰 9B 時，直覺會認為小模型是預算妥協。但就它受訓所針對的工作而言，Tencent 的論文提出相反看法，而且它自己的一項結果還對自家更大的發布版本不利。這裡所有數字都是作者自己的，由作者自行執行，無人重現。

• 零樣本偵測——在 COCO 上平均 F1 為 55.2，在 LVIS 上為 53.3，在 Dense200 上為 61.4，在 VisDrone 上為 40.4。Qwen3-VL-2B 基線在同一張表上的得分為 45.2、40.8、10.0 和 23.1。值得留意的是 Dense200 的差距：在擁擠場景中是基礎模型的六倍。

• 計數 — 在兩個 PixMo-Count 分割上分別達到 90.9 與 88.1 的精確匹配，但在 CLOC 上只有 27.5 與 26.9，在 KubriCount 上為 29.5 與 32.4，在 CountQA 上則為 47.9。計數不是單一技能，而這個落差是整篇論文中最誠實的一點。

• OCR 定位 — 在 0.5 IoU 閾值下，HierText 上的平均 F1 為 30.5、ICDAR2015 上為 42.6、TotalText 上為 42.5、SROIE 上為 62.1。這些是附有座標的定位分數，而非轉錄準確率，因此無法與通常針對消費級 VLM 引用的 OCRBench 數值相比。

• 指涉式分割 — 在 RefCOCO 驗證集上達到 79.7 累積 IoU，RefCOCO+ 上為 73.1，RefCOCOg 上為 74.4，ReasonSeg 上則為 60.9 gIoU。

• 可提示式摳圖——在 P3M-500-NP 上使用框提示時，平均絕對差異為 6.6，SAM2-Matting 則為 15.4；在 AM-2K 上為 5.7，對比 12.1；在較難的 WeRefMat 指涉分割上為 15.8，對比 Qwen3-VL-8B 加 SAM2-Matting 管線的 23.0。整體而言，數值越低越好。

去背結果正是尺寸論點反轉之處。在同一個 P3M-500-NP 框選提示測試中，2B 得分 6.6，而騰訊自家的 4B 同系列模型得分 7.3。兩者之中，較小的模型反而是表現較好的去背模型；騰訊並未解釋原因，論文卻仍照樣刊出。如果你的工作是從影像中切出物件，那麼這個系列中最便宜的版本並不是降級——它目前是量測結果最佳的選擇。

論文沒有展示的內容同樣值得了解。七個表格中完全沒有 MMMU、MMBench、DocVQA，也沒有任何圖像描述基準；局限性一節承認，有限的通用訓練資料「可能損害相對於基礎模型的通用能力」。讓它在感知方面表現出色的微調，可能反而使它成為更差的通用助理，而發佈版本中沒有任何測試檢驗這一點。此外，也沒有任何思維鏈輸出、多輪記憶或影片支援——像素解碼器直接拒絕影片網格。

能為這件事下定論的那項基準測試並不存在。

把兩套評測套件並列在一起，這種不可比較性就不再只是技術細節。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-2B 無論是在其模型卡、論文或專案頁面上，都未報告任何 ScreenSpot-Pro 結果、任何 ScreenSpot-V2 結果，也沒有報告任何類型的 GUI 基準測試結果。反過來說，WeVisOne-VL-2B 報告了 OCR 定位與密集指向，而 UI-Venus-2-9B 兩者皆未報告。

有一個轉折讓這組標題配對顯得更加古怪。inclusionAI 已經推出一個基於 Qwen3-VL 的 2B 模型——UI-Venus-1.5-2B——而它的模型卡在 ScreenSpot-Pro 上報告 57.7，相較之下，其 8B 同系列型號為 68.4，30B-A3B 則為 69.6。那才是 WeVisOne-VL-2B 真正規模相符的對應模型，屬於同一個主幹家族，並且是在兩條產品線都關注的那個基準上測量。只是它並不是這次對決中被點名的模型。

老實說，能站得住腳的範圍很窄。沒有任何已發表的數字在任何任務上比較過 WeVisOne-VL-2B 與 UI-Venus-2-9B，也沒有人把這個 2B 感知模型跑過任何 GUI grounding 資料集。在這項比較中，用 WeVisOne-VL-2B 跑 ScreenSpot-Pro 是最有用卻仍缺失的一項測量：它會告訴你，一個 2B 感知專家找介面元素的能力，比一個 9B agent 更好還是更差；而在有人實際跑過之前，任何人就「找東西」這件事替這兩者排名，都只是在從架構外推。

當物件不在那裡時，每一個分別會做什麼

物件不存在時的行為，正是感知模型悄然失效之處。在一個根本沒有滅火器的房間裡要求找出滅火器，一個總是給出答案的模型會自信滿滿地把散熱器框起來——而在自動化流程中，這就變成資產庫裡一個幻覺出來的物件，或代理迴圈中一次誤觸。

WeVisOne-VL-2B 則改為回答 None，而論文將拒絕作為獨立指標與準確率並列報告。在 RefCOCOg 上，針對不存在物件的查詢，其回報的拒絕率為 50.2，而同一張表中 Rex-Omni-3B 為 0.5、LocateAnything-3B 為 0.6。這與最大化召回率的設計目標不同，而正是這個數字讓小型模型可作為元件使用：一個會說「不存在」的幾何分支可安全地饋入規劃器，而一個會憑空捏造邊界框的幾何分支則會悄悄破壞它。

UI-Venus-2-9B 從動作端切入同一個問題，承襲 UI-Venus 系列的拒絕感知定位能力——它經過訓練，當要求的元素不在畫面上時會拒絕，而不是猜測一個看似合理的座標。其安全表顯示了它所聲稱的效果：在 OSHarm 上的攻擊成功率為 11.3%，而 Qwen3.5-9B 基礎模型為 25.3%；在 OSBlind 上為 48.8%，對比 79.4%。模型卡也明確表示，這並未消除有害動作風險，並建議人工確認加上應用層防護措施。兩個團隊都選擇棄權而非追求覆蓋率；但兩隊的這項選擇都尚未經過獨立測量。

將 2B 與 9B 並排運行

這兩個模型之間誠實的關係不是競爭，而是先後序列。一個回傳幾何資訊，另一個據此採取行動。如果你正在打造螢幕自動化系統，一個合理的架構是把 WeVisOne-VL-2B 放在前面，作為回報什麼東西在哪裡的元件——邊界框、OCR 範圍、遮罩——並把 UI-Venus-2-9B 放在它後面，作為決定該做什麼的元件。這是組合，不是競爭，而這也是唯一能讓這種搭配在運作上說得通的框架。

記憶體讓這種組合在單一機器上成本很低。在 bfloat16 下，2B 主幹在解碼器之前約有 4GB 權重，而 9B 則在四個分片中共約 18.8GB。兩者都能放進單張 24GB 顯卡，還留有上下文空間；單獨的 2B 更能放進 8GB 顯卡，這是更有趣的事實。上下文上限同為 262,144 個位置，但兩者意義不同：代理將長上下文用作情節記憶，保存螢幕截圖的歷史，而感知模型已發表的評估則以每張影像約 1,960 個視覺 token 執行。對單輪、僅影像模型而言，256K 視窗是上限，不是已證實的能力。

成本正是兩者形態分歧之處。兩家供應商都未公布每 token 的價格，因此對雙方而言，真正的成本都是你租用或自有硬體上的 GPU 小時。代理在每一步都要支付一次 9B 前向傳遞加上推理 token 的費用，而一個回合包含許多步——這是無法從規格表預測的數字。感知模型每張影像要支付一次 2B 前向傳遞加上一次解碼器前向傳遞，而一張影像就是一次呼叫。十萬張產品照片是可預測的逐影像算術；瀏覽器任務則不是。

這也正是路由層能證明自身價值、而非只是口號的地方。這兩個模型目前都不在 OrcaRouter 上——我們查對了 209 個模型的即時目錄，而 WeVisOne-VL-2B 的說明卡指出，它完全沒有被任何推論供應商部署。對於我們確有提供的模型，實用特性包括一個與 OpenAI 相容的端點、0% 加成，並原樣傳遞供應商定價、一套路由 DSL，可在單一介面後組合多個模型呼叫，以及自動故障轉移。對於像上述這種兩段式架構，DSL 正是組合邏輯所在之處，也是任一段都能在不重寫呼叫端的情況下替換的地方。等到這兩個模型之一登上某家供應商的那天，那就是找出它是否該納入你的技術堆疊的最便宜方式。

授權、價格，以及尚無人證實的部分

WeVisOne-VL-2B 的卡片針對「此儲存庫中由騰訊撰寫的程式碼」授予 Apache 2.0，這是多數團隊想要的寬鬆授權答案。有一個細節讓情況變得複雜：GitHub API 將該儲存庫的授權回報為「Other」，且沒有 SPDX 識別碼。這些說法不一定互相衝突——第三方元件仍保有自己的條款——但這意味著在它接近產品之前，授權檔案值得先讀過，而不是只憑標章就照單全收。

UI-Venus-2-9B 的模型卡是尚未解決的那一項。它指出，模型權重的授權仍在等待最終確認，並會在公開發布前補上；同時也表示先前的 Apache-2.0 宣告是刻意未沿用，因為上游素材含有互相衝突的授權陳述。這句話從八月起就一直留在模型卡上，未曾改變。它不會阻礙評估或大多數內部使用，但以這些權重為基礎打造的外部產品，等於建立在一個未解的問題上，而沒有任何基準測試分數能消除這個問題。

這兩個模型都沒有廠商制定的價格。WeVisOne-VL-2B 沒有推論服務供應商，也沒有價目表。UI-Venus-2-9B 沒有第一方端點，inclusionAI 也未公布定價，因此第三方主機收取的任何費用都是該主機自己的數字，而非該團隊的定價。

該選哪一個

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

• 若你需要的答案是幾何資訊——把框送進標註流程、把遮罩交給編輯工具、為產品影像產生 alpha 遮罩、計算密集畫面中的數量，或取得附帶座標的 OCR——就選 WeVisOne-VL-2B，尤其是當你需要在小型硬體上執行時。它是這裡唯一能從文字提示回傳遮罩的模型，在去背表現上勝過自家更大的同系列模型，而且授權條款也是已定案的那一個。

• 如果你需要的答案是一項已完成的任務——表單已填好、應用程式已瀏覽、CAPTCHA 已解開、桌面工作流程已執行——就選 UI-Venus-2-9B。你買的是一個代理迴圈，而且你應該在知情的情況下入手：授權狀態尚未底定，且在此規模下，長時程桌面工作仍未獲解決——卡片自身的 OSWorld 2.0 數據是 7.5 部分分與 0.0 二元分。

• 如果你真正想要的是小型 GUI grounder，那就改選 UI-Venus-1.5-2B。它是 inclusionAI 產品線中基於 Qwen3-VL 的 2B 模型，在 ScreenSpot-Pro 上報告的成績為 57.7，也是這場對決名稱所暗示、卻未明確點名的同尺寸比較對象。

• 如果你要建置需要精確看見再據以操作的螢幕自動化，請依序執行兩者——先跑幾何部分，再跑代理部分，使用同一張 GPU。

• 等等，如果你的決策取決於 WeVisOne-VL-2B 的 GUI 定位數字。那它還不存在，而從參數量去猜測它並不是一種方法。

什麼會改變這個答案

四件事，依實用性排序。用 WeVisOne-VL-2B 跑一次 ScreenSpot-Pro 或 ScreenSpot-V2，就能把本文的核心缺口轉化為一項比較；考量到該模型才推出一日且採用 Apache 2.0，對任何有 GPU 和評估工具鏈的人來說，那只是週末的工作量。釐清 UI-Venus-2-9B 的授權，將可移除那個任何準確度數字都無法辯駁的唯一阻礙。若有推論供應商上架任一模型，就能以實際價格取代 GPU 小時的算術。而一項能解釋為何較小模型表現更好的 4B 對 2B 比較，將告訴買家這個系列的命名究竟有沒有意義。

在那之前，看待這兩者的有效方式，不是把它們當成排行榜上的競爭對手，而是把它們視為不同的工具：一個用來衡量影像，一個用來對螢幕採取行動。這場對決的名稱暗示你是在兩個幾乎同等的小型模型之間做選擇。其實你是在一個 2B 專家模型和一個 9B 代理模型之間做選擇，而它們真正共有的唯一習慣，就是說不。