為文章生成的標題卡:以大號字體顯示模型名稱 ZoomGain-9B,副標題寫著「未經公告即發布」,較小的一行寫著「一份儲存庫讀數」,背景為白色,帶有柔和的藍色與青色漸層點綴,右下角有 OrcaRouter 標誌。
Engineering & Research

ZoomGain-9B 無預警發布:儲存庫實際上怎麼說

作者

Gideon Frost

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

論文於 2026 年 11 月 10 日上傳到 arXiv。GitHub 儲存庫早一天、在 11 月 9 日建立,其首次提交的標題是「Release ZoomGain init」。權重於 11 月 10 日 11:42 UTC 出現在 Hugging Face,隨後在 11 月 11 日 03:16 出現一個 GGUF 儲存庫。沒有發布部落格文章、沒有廠商公告、沒有託管端點,檢查點儲存庫本身也沒有授權標籤。這就是 ZoomGain-9B 的全部公開紀錄;它是 inclusionAI 的 94 億參數視覺語言模型,而 inclusionAI 是螞蟻集團的開放模型部門,這也是本文寫成儲存庫解讀、而非發布報導的原因。

值得關注的不是它的隱匿性,而是對於一個無人宣布的東西而言,這個儲存庫異常完整:論文、1,000 題基準測試、9,000 筆記錄的強化學習資料集、評估器、訓練啟動器、4B 與 9B 的兩個檢查點,以及三個 GGUF 量化版本,全都在大約兩天內釋出。你今天就能閱讀方法、重新執行評估並重現訓練。唯一缺少的,是公司裡有人出面說它存在。

實際上按順序落地的是什麼

• 2026 年 11 月 9 日 — inclusionAI GitHub 儲存庫建立。它採用 Apache 2.0 授權,並包含資料建構與訓練程式碼,但不含權重。

• 2026年11月10日 — arXiv:2611.14076v1,〈ZoomGain:挖掘從全局到局部縮放的感知落差,以實現細粒度視覺監督〉,作者為 Haozhan Shen、Liangbo He、Jun Lan、Huijia Zhu、Weiqiang Wang、Tiancheng Zhao 與 Jianwei Yin,所屬機構為螞蟻集團、浙江大學、Om AI Research 及濱江研究院。

• 2026年11月10日 11:42 UTC — inclusionAI/ZoomGain-9B 與 inclusionAI/ZoomGain-4B 在 Hub 上建立,兩者各自有一個 18.82 GB 與 9.08 GB 的 BF16 safetensors 檔案。

2026年11月11日 03:16 UTC — inclusionAI/ZoomGain-9B-GGUF 隨 Q4_K_M、Q8_0 與 F16 版本以及相應的 mmproj 投影器檔案一同出現,這一步讓研究用檢查點變成筆記型電腦也能嘗試的東西。

有個小細節值得注意,因為這正是協調式發布不會出現的情況:模型卡自己的「Updates」區塊把論文、基準、資料集和檢查點的日期全都標成 2026.11.11,而儲存庫的建立時間戳記和 arXiv 提交日期卻都寫著 11 月 10 日。這張卡是事後由某個人整理時一氣呵成寫下的。

這個想法,用一段話來說,因為它確實就是一個想法。

視覺模型往往能回答關於影像某個區域的問題,但當同一區域出現在整個畫面中時,它卻答不出來。作者將這種現象稱為「全域到放大的感知落差」,並把它轉化為監督訊號。第一階段:多個模型各自在完整場景中定位所描述的目標,並根據它們的一致結果找出要裁切的區域。第二階段:比較裁切區域的圖說與完整場景的圖說,凡是裁切區域顯示、但完整視野未顯示的細節,就成為針對原始影像提出的問題。第三階段:在裁切區域上重新檢查答案,濾除模稜兩可的問題,以及可從語言先驗回答的問題,並為選擇題格式生成合理的誘答選項。

訓練是在 7,713 張來源影像上建立的 9,000 筆紀錄上進行 GRPO——一個 epoch、batch size 64、每個問題八次 rollout——並使用內附的 EasyR1 程式碼。評估預設為 temperature 0,且停用 Qwen3.5 thinking;OCR 與計數題維持開放式作答,而屬性題則改為選擇題。這些本身都不稀奇;稀奇的是,產生訓練資料的流程同時也產生了基準測試,而論文對此毫不諱言。

兩個不相同的數字

在 ZoomGainBench 上——這個由同一套流程建構、包含 1,000 道題目與 941 張影像的中英文基準——ZoomGain-9B 得分 55.48。其基礎模型 Qwen3.5-9B 得分 32.13。這是在一個由模型自身訓練資料所挖掘出的基準上提升了 23.35 分,而論文正是出於這個原因將該欄標為「Held-in」。

決策時應採用的數字,是十三項訓練從未接觸過的基準的平均值,其中不含 ZoomGainBench:ZoomGain-9B 為 66.10,Qwen3.5-9B 為 59.75。從 9,000 個樣本取得平均 6.35 點的提升,是紮實且可信的結果。這兩個數字都是真的。它們回答的是不同問題,而任何引用 55.48 卻未註明「held-in」的頁面,都只告訴你一半。

同一張表裡還有第二個似乎尚未有人注意到的反常之處:較小的同系列模型在 held-in 基準上擊敗 9B。ZoomGain-4B 在 ZoomGainBench 上得分 55.81,而 9B 為 55.48,但在 held-out 平均上以 63.96 對 66.10 落敗。在由訓練分佈建構的基準上,兩者在雜訊範圍內不相上下;一旦離開該分佈,規模又會重新佔上風。如果你只憑單一頭條數字在兩者之間做選擇,你會選錯。

Generated single-column scoreboard card for ZoomGain-9B, with six rows: HR-Bench 4K 90.25, V*Bench 93.19, VisualProbe 56.31, ZoomGainBench held-in 55.48, held-out average 66.10, and MMStar 73.87, plus a footer noting that all figures are author-reported on the released harness and not independently reproduced.

9,000 個樣本換來了什麼,逐項基準檢視

以下所有數據均為作者在論文表 3 中報告的數字,由作者自己的測試框架在已發布的評估器上運行得出,並非由任何人獨立重現:

• HR-Bench 4K — 90.25,較先前的 82.13 提升。這是摘要開頭率先點出的數字,也是整份發布內容中最強而有力的主張。

• V*Bench — 93.19,較 86.91 提升。高解析度下的小物件偵測。

• VisualProbe — 56.31,較 44.66 上升。此為保留基準之外最大的相對增幅。

• O3-Bench — 68.12,較 56.52 上升。多步驟感知與推理。

• MMVP — 70.00,從 60.00 提升。這項經典測試使用僅在一個細節上不同的成對圖像。

• MMStar — 73.87,較 71.73 提升。通用多模態能力,也是本組中增幅最小的。

• BabyVision — 17.53,較 15.98 上升。仍接近下限,這也提醒我們,提升集中在精細細節系列,而非平均分佈。

綜合來看,這個模式與其說符合一般能力提升,不如說與該方法一致:最大的差異出現在獎勵「在大畫面中找出小細節」的基準測試上,而最小的差異則出現在獎勵廣泛世界知識與一般視覺推理的基準測試上。這正是針對 9,000 個裁切細節問題進行定向 RL 訓練時應有的樣子。

什麼是可知的、什麼是被主張的,以及什麼只是單純尚未確認的

今天就能從儲存庫得知,無須聽信任何人的說法:架構,因為設定檔是公開的,並標明了一個 Qwen3.5-9B 文字主幹,具有 32 層、隱藏大小 4,096、中間層 12,288 與最大 262,144 個位置,外裹一座視覺塔;訓練資料,因為那 9,000 筆記錄的 Parquet 與來源影像都作為資料集隨附提供;方法,因為提示詞就在論文附錄裡;以及評估,因為評估器、標註與影像全都可以下載。

已聲稱但尚未確認:上述每一項基準測試分數。論文是在已釋出的測試框架上報告這些分數,這使它們比大多數廠商表格更容易查核——你可以重新執行這些測試——但作者名單以外的人至今尚未這麼做,也沒有獨立實驗室發表過 ZoomGain-9B 的結果。

完全未經證實,而且值得直言:

• 檢查點授權。程式碼採用 Apache 2.0,模型卡也如此標示。模型卡接著把模型與資料集條款交由「各資料集與檢查點的條款,請參閱其 Hugging Face 卡片」處理,而檢查點儲存庫在其 Hub 中繼資料中沒有授權標籤。這是出貨前必須透過閱讀檔案來補上的缺口,而不是你可以依賴的承諾。

• 上下文長度。模型卡未說明。設定中的 262,144 個最大位置繼承自 Qwen3.5-9B 主幹,這與後訓練檢查點經過實測的性質並不相同,而且論文中的每一項評估都是停用思考模式的單一影像。

• 一般助理行為。發布測試中沒有任何內容涵蓋聊天、工具呼叫、長篇生成或多輪使用。該模型經過訓練,以回答關於照片的問題,而這是唯一有證據支持的能力。

• 任何主機。此儲存庫在 Hub 的供應商對應為空。未列出任何廠商 API 或第三方端點,因此「試用」目前意味著「下載 18.82 GB」。

Screenshot of the inclusionAI/ZoomGain-9B model card on Hugging Face, showing the repository header with zero likes, the Safetensors and qwen3_5 tags alongside the arXiv identifier, the Model card, Files and versions and Community tabs, and the table of benchmark results reproduced inside the card.

如果你想的話,這週就執行它

GGUF 這條路徑成本較低:5.63 GB 的 Q4_K_M 版本加上 0.52 GB 的 mmproj 投影器,或 Q8_0 的 9.53 GB,或 F16 的 17.92 GB。影像輸入需要這兩個檔案——投影器不是選配,而且必須有支援 Q​wen3.5 多模態的 llama.cpp 版本作為前提。參考路徑較重,但文件較完整:vLLM 0.19.1 搭配 transformers 5.7.0,正是作者評估時所用的版本,採用 BF16 檢查點,至少需要 24 GB 的顯示卡,且最好還有充裕的餘裕。

值得把評估流程和模型權重一併納入規劃。作者在 temperature 0、關閉 thinking 的設定下執行,屬性題以所選選項的精確匹配計分,計數題以預測整數的精確匹配計分,OCR 則以 ANLS 計分並設 0.7 下限。如果你在開啟 thinking 或使用不同提示範本的情況下評估,你測量的是作者未報告的東西,且不應期望他們的數值能直接套用。

OrcaRouter 並未託管 ZoomGain-9B,而本文也不會假裝不是如此。我們真正擁有的是 一組金鑰即可存取 200 多個模型,按供應商定價且不加收任何費用,這在這裡有具體且實際的理由:要找出你的流程錯誤是否屬於細節錯誤,最快的方法就是把同一批影像送進託管的視覺模型,並比較失敗案例。 我們目錄中的 Qwen3-VL-8B-Instruct 每百萬輸入 token 為 0.18 美元、每百萬輸出 token 為 0.70 美元,上下文長度為 131K,可接收影像與影片,且不會比得上以從作物資料中挖掘出的問題訓練的模型——但它能在一個下午內告訴你 GPU 是否值得購買。

Screenshot of the inclusionAI/ZoomGainBench dataset card on Hugging Face, showing the Imagefolder format, a train split listing 944 rows, column previews that include the ZoomGain and ZWZ score columns, and a note in the card that scores are percentages.

什麼會改變這個故事

四件事,按影響程度由低到高排列。來自 inclusionAI 的公告,這會讓一次儲存庫瀏覽變成一次正式發布,而且很可能伴隨授權條款的釐清。模型檢查點授權標籤,這將解決目前阻礙商業採用的一個問題。託管端點,這會為所有沒有自己硬體的人移除 18.82 GB 的門檻。還有獨立評測,這才是真正能帶來改變的一項:9B 模型在 HR-Bench 4K 上達到 90.25 的說法,是那種要麼經得起第二個實驗室的驗證、要麼悄然消失的數字。

在那之前,誠實的總結是:ZoomGain-9B 是一份文件齊備的研究發布,方法清晰可讀,具備可重現的測試框架,有一份異常誠實的訓練內/留出切分,而且沒有任何第三方為其中任何部分背書。這比大多數低調釋出所能提供的更多,但還算不上一個產品。