Xiaomi-Lens-0 想打入現成 Transformers——而它的遮罩解碼器正是癥結所在

今天 UTC 12:01，一個編號 50028 的 pull request 被提交到huggingface/transformers，標題是該儲存庫裡最平淡無奇的那種：「Add Xiaomi-Lens-0」。這不是佔位用的空殼。差異涉及 19 個檔案、新增 4,251 行，其中 2,199 行是單一模型檔案，另有 552 行測試與 143 行文件頁面。它的狀態是平淡無奇的部分——開放中、未審核、未合併。背後的模型才是有意思的部分，而它已在 Hugging Face 上待了六天，沒有任何發布貼文。Xiaomi-Lens-0 是基於 Qwen3.5-4B 建構的 4B 多模態模型，會把區域遮罩表示為 token，而實際影響範圍雖窄卻真實：在這類變更正式發布之前，你完全無法用標準 Transformers 類別載入它。

那道落差——介於模型「可下載」與模型「成為日常」之間——將由接下來幾週決定。以下內容會區分 Xiaomi 已發布的東西與框架 PR 所提議的東西，因為那是兩種不同層級的確定性，而迄今的報導一直把兩者混為一談。

小米實際推出了什麼，以及何時推出

這次發布是在五天內分批進行的，這也是它讀起來更像一次研究成果的釋出、而非產品發表的部分原因。

• 論文 —「Xiaomi-Lens-0 Technical Report」，arXiv:2610.23279，於2026年10月16日提交，10月19日修訂。

• 權重與程式碼 — 於 10 月 21 日公開於 SeerRay-Lab/Xiaomi-Lens-0Hugging Face，並在 GitHub 上提供對應的推論儲存庫。

• 授權 — 權重採用 Apache 2.0，基礎 Qwen3.5-4B 權重亦為 Apache 2.0。模型卡將基礎部分歸屬於阿里雲，修改部分歸屬於小米。

團隊 — 掛名為 Xiaoai Plus 與 SeerRay 團隊，即 Xiaomi 的視覺理解團隊。

• 尺寸 — 標題、論文與模型卡說明文字全都寫 4B；Hugging Face 的中繼資料則回報 BF16 的 5B 參數。小米並未解釋這項落差，而誠實的解讀是：「4B」描述的是語言骨幹，含視覺塔的完整檢查點參數量則更高。

• 託管 — 卡片側邊欄顯示，該模型未由任何推論供應商部署。沒有第一方 API，也沒有可呼叫的託管端點。

• 熱度 — 權重上架六天後，最近一個月有 723 次下載，Hugging Face 儲存庫獲得 25 個讚。

我找不到的是一場發表：沒有小米的官方部落格文章、沒有團隊的討論串、也沒有產品頁面。相關報導可追溯至技術報告，以及模型權重釋出後的業界報導。這對任何想確認該模型日期的人來說都很重要——10 月 16 日是論文，10 月 21 日是實際產物，而兩者都不是發表公告。

一個遮罩就是一個 token，而不是第二個模型

從視覺語言模型取得像素遮罩的常見做法，是在模型上外掛一個分割器。你從語言端取得邊界框或點，把它們交給類似 SAM 風格的解碼器，並為此付出第二個網路、第二組權重和第二次前向傳遞的代價。

Xiaomi-Lens-0 跳過了這一點。模型會生成一個特殊的 <|mask|> token，而該 token 的隱藏狀態——論文稱之為視覺潛在表徵——會被用作查詢，對照視覺編碼器的 patch 網格。單一 Transformer 精煉層、線性投影、對每個 patch 做點積，接著兩步轉置卷積上採樣與一個 sigmoid。patch 特徵是在空間合併器之前取得的，因此網格仍然精細，且每張影像只計算一次，並由回應中的每個 mask token 重複使用。

訓練分為兩階段，一旦架構清楚，流程並不令人意外。第一階段凍結主幹，僅用內部資料加上 Objects365、LVIS、PACO、PhraseCut 與 RefCOCO 系列來訓練遮罩解碼器。第二階段則以標準的下一詞元目標，加上結合像素 BCE 與 Dice 的遮罩損失，聯合微調主幹與解碼器。

真正值得關心的後果並不是參數節省。而是遮罩可以出現於推理過程中，而不只是出現在最終答案裡。Xiaomi 訓練的是有依據的推理軌跡，其中思維鏈會引用區域，並在推理過程中產生遮罩，這就是為什麼 4B 模型在回答「這兩者中哪一個是我該拿起的」時，能讓遮罩附在中間步驟上，而不只是附在最後一句上。

正確解讀的基準表

這些重點數字很強勁，而且全都來自 Xiaomi。截至目前，沒有 Artificial Analysis 的收錄條目、沒有 arena 排名，也沒有第三方重現。請將以下內容視為廠商宣稱，並附有異常詳盡的附錄，而非實測事實。

• 指稱分割——在八個 RefCOCO / RefCOCO+ / RefCOCOg 分割上平均 cIoU 為 81.4，相較之下 Qwen3-VL-Seg 4B 為 78.6。而 SAM 3 在小米自家表格中、同樣這八個分割上的平均值約為 71.7。

• 指稱理解 — 相較於 Qwen3.5-4B 主幹，Prec@0.5 平均提升 5.6 分，其中 RefCOCO+ 提升 7.6 分。

• COCO 2017 上的多實例定位 — 平均 F1 為 63.9，領先 GroundingPI 的 63.0 與 Qwen3-VL 4B 的 46.5。

• 推理分割 — 在 ReasonSeg Test 上達到 68.0 gIoU，為比較模型中表現最佳者。

• 具身指稱 — 在 RoboRefIt TestA 上達到 87.0 gIoU。

• 計數 — 在 CountQA 上為 50.6，較主幹模型的 43.8 提升 6.8。

其中兩項值得再看一眼，因為四處流傳的摘要把它們過度簡化了。

第一個是 COCO 多實例定位。Xiaomi-Lens-0 在平均 F1 上勝過 GroundingPI，但在寬鬆的 IoU 0.50 門檻下，它其實落敗——80.4 F1 對上 81.2。它的勝勢來自嚴格的一端：在 IoU 0.95 時為 27.4 F1，對手則是 22.8。這是本質上截然不同的差異。該模型產出的是更貼合的遮罩，而非更多的遮罩，而只檢查寬鬆重疊程度的流程將無法看出這項進步。

第二個是 LensBench，這是小米與模型一同建置並發布的 1,200 個單元、4,800 條指令的基準測試。它涵蓋一般、空拍、駕駛與全景影像，並經人工審查，對於任何在 RefCOCO 之外工作的人來說，這是此次發布中最有用的東西。它同時也是該模型表現最不出色的那項測試。在一般影像上，Qwen3.8-Max 以 74.2 cIoU 領先，而 Xiaomi-Lens-0 為 63.9。在隱含指令上，該模型排名第五，落後於 Qwen3.8-Max、GPT-5.6-Sol、Gemini-3.6-Flash 與 Seed-2.1-Pro。小米發表了一份自家模型無法全面橫掃的基準測試，這比一份完美無瑕的成績單更有價值。

4B 模型真正失效的地方

這種失敗模式並非隨機發生。它是「明確指稱該事物」的描述與「僅暗示該事物」的描述之間的落差。

• 從顯式到隱式——在 LensBench 上，mask cIoU 從 71.4 降至 54.7，box Prec@0.5 從 85.0 降至 70.0。

• 全景場景中的多個目標——論文中表現最差的切片，其中 box Prec@0.5 從 81.3 降至 48.7，cIoU 從 71.8 降至 48.9。

• 小型、被遮擋與不明確的區域——卡片明確指出，在這些情況下，預測可能會漏掉物件，或產生不準確的邊界框與遮罩。

• 計數 — 在 CountQA 上拿到 50.6 分，是 6.8 點的進步，但仍大致相當於擲硬幣，只是態度好一些。

還有一個實作上的注意事項，任何把這接進產品的人都會踩到。遮罩是在處理器的影像畫布上解碼，不是在你的原始檔案上。如果你在推論前調整大小，卻忘了反轉映射，遮罩回來時形狀正確，位置卻錯了。卡片上說要保留調整大小與座標映射；它沒說不這麼做會怎樣，而答案是一個無聲、看似合理的錯誤。

提取要求變更了什麼，以及沒有變更什麼

PR 50028 自 10 月 23 日以來一直在進行中——共四次提交，最後一次約在拉取請求開啟前一分鐘落地。它新增了一個設定檔、一個模組化檔案、一個 2,199 行的建模檔案、一個處理器、一個權重轉換腳本、模型、影像處理器與分詞器的自動對應、一個文件頁面，以及 552 行的測試。CI 機器人已要求針對 xiaomi_lens0 執行慢速測試套件。目前沒有任何審查。

如果它被合併，會有三件事改變。載入方式會變成 AutoModel 和 AutoProcessor，而不是對小米的儲存庫執行 pip install -e .。模型會出現在人們真正會讀的文件中。而且它將能使用生態系工具——量化、適配器、訓練框架——這些工具在處理檢查點之前，會先假設已有 Transformers 類別存在。

如果它被合併，有四件事不會改變。它仍然需要支援 bfloat16 和 FlashAttention-2 的 CUDA GPU。它仍然沒有託管端點。Mask 解碼仍然透過處理器執行，而不是單純的生成呼叫。而且數字仍會與今天一樣，完全依照廠商回報，因為框架移植是打包事件，不是評測。

也值得直言談談狀態。一個開啟中的 PR 並不等於功能已完成。Transformers 有自己的合併節奏，維護者尚未表態，而這種規模的移植通常要經過數輪才會落地。今天任何人若寫「Xiaomi-Lens-0 現在可在 Transformers 中運作」，都還差一次合併，因此會是錯的。

本週要讓它運作起來需要什麼

官方途徑是 Xiaomi 自家的套件，而且它假設你有一台真正的 GPU 主機。

• 設定 — Python 3.10 或更新版本、支援 bfloat16 與 FlashAttention-2 的 CUDA，然後在推論儲存庫內執行 pip install -r requirements.txt 和 pip install -e .。

• 單張影像 — infer.py 接收檢查點、影像、文字查詢與輸出路徑，並寫出標註後的影像以及生成的文字。

• 輸出格式 — 方框會在 <bbox> 標籤內正規化為 0–1000 的範圍，遮罩會以 <|mask|> 權杖的形式輸出於 <mask> 標籤內，而 thinking 區塊內的任何內容都會從最終疊加層中排除。

• 服務 — vLLM 支援已存在，但會以兩個共置服務執行：文字生成在 8000 埠，遮罩解碼在 8001 埠，且用戶端必須位於同一台機器上，因為它傳遞的是影像路徑而非位元組。若您覆寫 MAX_PIXELS，兩個服務需要相同的值。

目前有兩種社群方案，而兩者都不是小米的。一個名為 xiaomi-lens-mnn 的 PyPI 套件在 MNN 上針對 CPU 以 fp16 或 int8 重新實作推論，且不依賴 torch；另一個非官方 ComfyUI 節點包則回報其輸出與官方程式碼位元完全一致。兩者都是有用的訊號——尤其是 MNN 移植版，因為它顯示該架構簡單到足以重新實作，而不只是封裝。

Xiaomi 並未公布 VRAM 數字、延遲量測值或吞吐量數據。對 4B 模型而言，權重不是問題；高解析度下的視覺塔與遮罩解碼階段才是，而這兩者都沒有公開的成本數據。在圍繞它規劃機群規模之前，請先進行測量。

本週誰應該下載它？

如果你需要從自然語言描述取得像素級精確的遮罩，而且你能掌控硬體，這是寬鬆授權下可取得的較佳 4B 選項之一，且權重無需額外審核即可取得。其明確指令的數字可與規模大上數倍的模型匹敵，架構讓你的管線少掉一整個第二網路，而 Apache 2.0 代表法務審查很短。

如果你今天需要的是託管的影像分割端點，那並不是這個。Xiaomi-Lens-0 不在 OrcaRouter 目錄中——我們不提供它，這裡的任何內容都不應被解讀為另有聲稱。我們提供的是供比較用的模型。如果真正的問題是 4B 開源模型能否在你的影像上勝過託管視覺模型，誠實的做法是在本機執行 Lens-0，並透過同一把金鑰呼叫託管端。Qwen3-VL-8B-Instruct，例如，每百萬輸入 token 為 $0.18、每百萬輸出 token 為 $0.70，依供應商定價原價轉嫁、不加價，而同一把金鑰也能存取目錄中的其他模型，如果你想要第二意見，或是在某個供應商效能下降時自動容錯移轉。用你的資料做這項比較，比論文裡的任何表格都更有價值。

什麼會改變這項評估？

四件事，大致按影響程度排序。

合併 PR 50028，因為它把研究產物變成一般 Python 環境能載入的東西。由非小米的人員在 LensBench 或 RefCOCO 上進行的獨立評估，因為目前的數字只有一位作者，而論文自身表現較弱的切片顯示平均值掩蓋了真實變異。在 vLLM 或 SGLang 中提供原生 mask 路徑，將雙服務架構收斂成單一端點，這正是展示與部署之間的差別。以及任何人提供的託管服務，這會讓這個模型成為一項支出項目，而不是一個專案。

在那之前，正確的描述是精確的：Xiaomi-Lens-0 是一個真實、可下載、採用 Apache-2.0 的 4B 模型，其分割方法不同尋常且文檔詳盡，問世六天，擁有強勁的廠商數據、一個並不對它加以美化的已發表基準，以及一個僅被提出而非已交付的框架移植。這比「小米剛投下一個 Segment Anything 殺手」或「在它被合併之前，沒什麼值得關注的」都更有用。