WeVisOne-VL-2B：Tencent 推出了一個感知模型，卻沒有告訴任何人

WeVisOne-VL-2B 模型卡中最關鍵的一行，並不是在談模型本身。它談的是一個名為 mask_decoder.pt 的檔案，具 9,511,460 個參數，並以一句平鋪直敘的話描述為「必備核心元件，而非可選附加項」。Tencent 這款新感知模型的一切行為——無論你得到的是邊界框、點、二值遮罩，還是連續 alpha 遮罩——全都取決於那個解碼器。而它所屬的模型幾乎毫無鋪張地登場：WeVisOne-VL-2B 的權重於 2026 年 10 月 22 日 09:47 UTC 上傳到 Hugging Face，GitHub 儲存庫早了五十分鐘出現，同日發布了一篇論文，而 Tencent 並未發布任何發布貼文或公告來配合這一切。

對讀者而言，這意味著什麼，範圍狹窄但有用。這不是你就能註冊使用的產品。這是一份可供下載的研究釋出，附有一篇論文，報告了模型卡未重複提及的數字，以及一組模型卡比多數供應商更直白陳述的限制。以下是可從儲存庫查核的內容、論文中宣稱的內容，以及尚無人驗證的內容。

什麼已經落地，以及那些顯示一切有多悄無聲息的時間戳記

這裡的每個日期都來自公開時間戳，而不是新聞稿，因為根本沒有新聞稿：

• Hugging Face — tencent/WeVisOne-VL-2B於 2026-10-22 09:47:50 UTC 建立。4B 同系列模型則在二十四秒後建立，這正是組織以單一批次推送檔案時的上傳樣貌。

• GitHub — Tencent/WeVisOne-VL於同日上午 08:58:16 UTC 建立。截至本文撰寫時，它僅包含一個提交「Initial public release of WeVisOne-VL」，時間戳為 2026-10-23 08:14 UTC，並有 46 個星標。

• 論文 — arXiv 2610.31329，〈WeVisOne-VL：從物件到像素的統一視覺感知〉，v1 於 2026 年 10 月 22 日提交，作者為 Tianming Liang、Junyi Pan、Yuxi Li、Canmiao Fu、Zhipeng Huang、Chong Sun、Chen Li 與 Jing Lyu，所有人均隸屬於 Tencent Inc. 的 WeChat Vision。

• 專案頁面 — tencent.github.io/WeVisOne-VL 已上線，包含示範、方法章節與結果表格。這是研究頁面，不是產品頁面：沒有定價、沒有 API、沒有註冊。

卡片本身在查看時顯示三個讚，而 4B 上則是一個讚。下載計數器顯示為零，這大多說明計數器有延遲；誠實的總結是，實驗室之外幾乎還沒有人碰過這個東西，而本週發表的任何文章——包括這篇——都是依據論文和儲存庫，而不是依據結果。

有一個細節值得提出，因為採購時會遇到：模型卡針對「{{1}}本儲存庫中由 Tencent 撰寫的程式碼{{/1}}」授予 Apache 2.0 授權。GitHub API 將該儲存庫的授權條款回報為「Other」，且沒有 SPDX 識別碼。這兩種說法未必互相衝突——第三方元件保留其自身條款，而模型卡也如此說明——但這表示，在它被用於任何產品之前，授權檔案值得先讀一遍。

這個架構是把賭注押在 token 上，而不是押在更大的模型上。

WeVisOne-VL-2B 以 Qwen3-VL 為基礎建構，擁有約 20 億個參數，並做了就視覺語言模型而言略顯不尋常的事：它將尋找與繪製。

語言端負責處理尋找。它具備專用的座標符記，<0> 到 <1000>，用以編碼正規化後的框與點，因此一次偵測實際上就是模型與其文字在同一串流中輸出的一串符記。當查詢的目標不存在時，它會回傳 None，而不會憑空捏造一個框。對於密集任務，它會多輸出一個特殊符記 <OBJ>，符記 ID 為 152678，緊接在每個預測框之後——這個標記表示「此實例在下方延續」。

像素端負責繪製。 mask_decoder.pt會讀取每個<OBJ>的隱藏狀態，並將其與傅立葉編碼的框先驗結合，然後產生實際遮罩。它有三個階段：一個視覺特徵適配器，作用於多層級 Qwen3-VL 合併前 ViT 特徵；一個由框引導的查詢解碼器，包含六個可變形交叉注意力區塊；以及一個密集預測頭，其建構圍繞騰訊所稱的 FullCanvasAlphaCascadeHead，會在 S/4、S/2 和 S/1 進行精煉，以步長 1 輸出全解析度連續 alpha matte。

真正重要的設計選擇是最後一項。多數具備 grounding 能力的 VLM 會回傳二元遮罩或多邊形。Alpha matte 是一種軟邊、逐像素的不透明度圖——這正是將人物合成到新背景、又不讓頭髮周圍出現光暈時所需要的東西。那是與分割不同的輸出類型，也是這個模型之所以作為獨立版本發布、而非作為通用 VLM 微調版本的原因。

論文所主張的內容，以及這張卡片不會告訴你的事

模型卡中沒有基準測試表。沒有上下文長度，沒有吞吐量數據，沒有訓練 token 數量，沒有硬體需求，沒有價格。模型卡提供的是介面、架構、預期用途與限制。

數字都在論文裡，橫跨七個任務表格，以及 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 的差距最為驚人：是基線的六倍，而且是在一個關於擁擠場景的基準測試上。

• 拒絕——在 RefCOCOg 上，2B 對不存在的物件查詢回報 50.2 的拒絕率。同一張表上的兩個專門定位模型 Rex-Omni-3B 和 LocateAnything-3B，回報的分別是 0.5 和 0.6。能夠說「不在那裡」，正是區分感知系統與示範的大半關鍵。

• 計數 — 在 PixMo-Count 驗證與測試分割上，完全匹配率為 90.9 與 88.1，但在 CLOC 上僅 27.5 與 26.9、在 KubriCount 上為 29.5 與 32.4，而在 CountQA 上為 47.9。各計數資料集之間的落差，是這篇論文裡最誠實的一件事：計數不是單一技能，而這個模型擅長其中某些技能。

• OCR — 在 HierText 上的平均 F1 為 30.5，在 ICDAR2015 上為 42.6，在 TotalText 上為 42.5，在 SROIE 上為 62.1。這些是在 0.5 IoU 閾值下的定位感知 F1 分數，並非轉錄準確率，因此無法與你看到針對消費級 VLM 所引用的 OCRBench 數值相提並論。

• 分割 — 在 RefCOCO 驗證集上達到 79.7 累積 IoU，RefCOCO+ 驗證集上為 73.1，RefCOCOg 驗證集上為 74.4，ReasonSeg 驗證集上為 60.9。論文明確指出，RefCOCO 系列的數值為 cIoU，ReasonSeg 的數值為 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。以上各項數值皆為越低越好。

在你引用 4B 之前，有一個內部不一致之處值得先了解：在 P3M-500-NP 去背（matting）上，較小的模型其實勝過較大的模型，6.6 對上 7.3 MAD。騰訊並未解釋原因，而這也提醒我們，這些是單次執行的表格，並非已成定論的排名。

在證據薄弱之處

論文自己的限制章節異常直接，而這應該影響你如何解讀上述所有內容。它指出，有限的通用訓練資料「可能削弱相對於基礎模型的通用能力」。換句話說：讓它在感知方面表現優異的微調，可能反而讓它作為通用助理的表現變差。論文中沒有任何內容測試這一點——七個表格裡完全沒有 MMMU、MMBench、DocVQA，也沒有任何圖像描述基準。

其他三項限制屬於架構性問題，無法靠提示詞修復。模型為了推論效率，會在沒有思維鏈的情況下產生結構化輸出；它是單輪的；而且像素解碼器會拒絕影片網格。騰訊也指出，基準測試的提示詞「清晰、格式良好且無歧義」，而真實使用者的指令往往含糊——這坦率承認了評估設定對模型有所美化。

而實務上的缺口，正是工程師最先會碰到的。目前沒有公布上下文長度。論文中的訓練階段使用 4,096 與 8,192 個 token，推論時則以貪婪解碼將每張圖片限制在 1,960 個視覺 token，但這些都不是明確標示的部署上下文視窗。沒有 GGUF、沒有量化版本、沒有 ONNX 匯出，也未提及 Apple Silicon。騰訊沒有提供託管端點，也沒有任何推論供應商提供服務。

如果你想的話，就執行它。

支援的路徑是騰訊自家的套件。請從 GitHub 儲存庫安裝，然後依名稱載入檢查點，並以影像、任務、查詢與溫度呼叫 predict。該卡片也展示了透過圖像轉文字管線的 Transformers 路徑，並列出 vLLM、SGLang、Docker、Colab 與 Kaggle 作為部署途徑。

任何只快速掃過的人都會遇到兩個問題。第一，mask_decoder.pt並非可有可無——它必須連同權重一起下載，否則密集任務就沒有東西可執行。第二，預設是在溫度零下進行貪婪解碼，而模型卡建議維持這個設定；這是個會輸出結構化座標的模型，取樣對它沒有任何好處。

這也正是路由層真正派得上用場的地方，而值得精確說明這在此處意味著什麼。OrcaRouter 並不提供 WeVisOne-VL-2B——它不在我們的目錄中，我們也不會假裝不是如此。路由器有幫助的地方，在於它周遭的比較：如果你正在評估自架式感知模型，並將其與託管的通用視覺模型相比，那些託管模型位於一個 API 金鑰、依供應商牌價且不加價之後，因此建立評估框架並不代表要簽三份合約。自動容錯移轉可讓該框架的託管端在你的 GPU 機器忙碌時保持運作，而路由 DSL 讓你能把自架式呼叫和託管呼叫放在單一端點後面，同時由你決定哪一個值得在生產環境中佔有一席之地。

什麼會讓這個從一個儲存庫變成一個故事？

有三件事，目前都还不存在。独立复跑是最重要的一件：上面每个数字都是 Tencent 的，跑在 Tencent 的评测框架上，而拒绝率和抠图差值正是那种一旦由别人复跑就会变动的指标。第二件是公告——仓库、论文和项目页面都是第一方的，但它们没有一个是正式发布，而一篇像样的报道很可能会包含论文中压缩掉的训练细节。第三件是框架支持：模型卡列出了 vLLM 和 SGLang，但已合并的内核或官方 checkpoint 转换，与部署表格里的一行相比，是不同层级的承诺。

在其中一項落地之前，對 WeVisOne-VL-2B 的準確描述是這樣。它是一個具備智慧介面的 2B 感知模型——座標作為 token、實例作為標記、像素交給獨立解碼器——它在偵測、拒判與去背上，相對自身基礎模型有大幅提升，卻完全沒有公布任何通用能力數字，而且任何人都無法透過 API 呼叫它。如果你需要從照片中把人抠出來並保留頭髮，這樣的組合已足夠有趣，值得下載。如果你需要一個能回答圖片問題的視覺助理，這不是你正在找的檔案，而論文也坦率地這麼說。