为文章生成的标题卡:大号字体的模型名称 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上,随后一个GGUF仓库于11月11日03:16出现。没有发布博客文章,没有厂商公告,没有托管端点,检查点仓库本身也没有许可证标签。这就是ZoomGain-9B的全部公开记录。ZoomGain-9B是蚂蚁集团开放模型部门inclusionAI推出的94亿参数视觉语言模型,也正是本文写成一篇仓库解读、而非发布报道的原因。

真正值得关注的地方不是它的隐秘性,而是对于一个无人宣布的项目来说,这个代码仓库完整得异乎寻常:论文、1000 道题的基准、9000 条记录的强化学习数据集、评估器、训练启动器、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 上创建,二者各自带有一个 BF16 safetensors 文件,分别为 18.82 GB 和 9.08 GB。

• 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、批大小 64、每个问题八次 rollout——并使用捆绑的 EasyR1 代码。评估默认采用温度 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 个裁剪细节问题进行的定向强化学习运行应该呈现的样子。

什么是可知的,什么是被主张的,以及什么只是尚未确认的

今天就能从仓库中确认,无需听信任何人的说法:架构,因为配置是公开的,并标明了一个 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 显存的显卡,并且在此之上还要有舒适的余量。

值得在预算中同时考虑评估协议和权重。作者在温度 0 且关闭思考的情况下运行,属性问题按所选选项的精确匹配评分,计数按预测整数的精确匹配评分,OCR 按带 0.7 下限的 ANLS 评分。如果你在开启思考的情况下评估,或使用不同的提示模板,你测量的就是作者未报告的内容,不应指望他们的数字能够迁移。

OrcaRouter 并不托管 ZoomGain-9B,本文也不会假装它托管了。我们实际提供的是一个密钥即可按提供商标价使用 200 多个模型,且不额外加价,这一点在这里有一个具体而实用的原因:要判断你的流水线错误是否属于细粒度错误,最快的方法就是把同一批图像跑过托管视觉模型,并对比失败案例。我们目录中的 Qwen3-VL-8B-Instruct在 131K 上下文下,每百万输入 token 收费 $0.18,每百万输出 token 收费 $0.70,支持图像和视频输入;它不会比一个用裁剪图挖掘问题训练出来的模型更强,但它能在一个下午内告诉你,这块 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 是一次文档完备的研究发布,方法清晰可懂,评测框架可复现,训练集/留出集划分诚实得不同寻常,但没有任何第三方为其背书。这比大多数低调发布所能提供的更多,却仍少于一个产品。