ZoomGain-9B 与 MathForm 8B：两个无法胜任彼此任务的 9B 检查点

ZoomGain-9B 和 MathForm-8B 背后藏着一个暗含陷阱的问题：两者都是约 90 亿参数的微调模型，都在同一个 80 天窗口内发布，都是中国实验室发布的、附有论文的、与 Apache-2.0 相近的研究发布，都用强化学习在几千个样本上做了后训练，也都带着一个对其规模而言看似不可能的基准分数。人们忍不住想给它们排名。问题是，其中一个从未见过图像，另一个从未见过 Lean 证明，所以这个排名没有可依据的维度。

ZoomGain-9B 是 inclusionAI 于 2026 年 11 月 10 日发布的视觉语言检查点，通过在从裁剪图像细节中挖掘出的 9,000 个问题上使用 GRPO 训练而成，其报告的最佳结果是 HR-Bench 4K 上的 90.25。MathForm-8B 是 OpenBMB 于 2026 年 8 月 14 日发布的自动形式化器，先经过监督微调，随后在约 367,000 个 Lean 4 示例上进行强化学习训练，其报告的最佳结果是六项自动形式化基准上语法检查 pass@8 平均值达到 88.06%。这两个数字都不能说明另一个模型的任何情况。真正把两者联系起来的，是比排名更有用的东西：这两个发布都就小型微调模型如何击败大得多的通用模型提出了异常相似的主张，而它们论证这些主张的方式差异足够大，能告诉你针对什么该信任哪一个。

空白列，命名为

ZoomGainBench 不包含纯文本模型。它是一组关于照片的问题——属性识别、计数和 OCR——因此没有视觉编码器的模型无法参赛，MathForm-8B 也没有参赛。相反，MathForm 的六个评估基准是 FormalMATH、ProverBench、CombiBench 和三个 FATE 划分，全都是自然语言数学到 Lean 4 的翻译任务。ZoomGain-9B 从未在其中任何一个上运行过，也没有理由认为它会有好的表现，因为它的训练中没有任何内容涉及形式语言。

这不是关于基准测试的技术细节，而是决策的整体形态。如果你的任务生成图像并消耗一个简短的事实性答案，那么 MathForm-8B 是一个文本模型，无法尝试该任务。如果你的任务接收一个数学陈述并生成一个机器可检验的 Lean 4 证明，那么 ZoomGain-9B 是一个视觉模型，从未被要求做这件事。二者没有可供衡量的重叠部分，这意味着诚实的比较应针对构建方式、证据和运营成本——而这些方面最终差异很大。

两个强化学习配方，都很小，以及它们之间有何不同

ZoomGain 的训练集包含 9,000 条记录，覆盖 7,713 张源图像。训练一个 epoch，批量大小为 64，每个问题进行八次 rollout，采用 GRPO，其奖励函数会检查所选选项是否与参考答案匹配。这些数据是生成的，而非标注的：由多个模型定位一个区域，对裁剪图生成描述并与全场景描述进行比较，裁剪图所揭示的细节则转化为关于完整图像的问题。人工仅参与筛选——论文明确表示，未进行任何人工问答编辑。

MathForm 的训练集是 FormalVerse，约 367,000 个经过验证的 Lean 4 示例。先进行监督微调，然后使用来自 Lean 编译和语义一致性检查的反馈进行强化学习。数据构建在生成前使用 Mathlib 检索，生成后进行迭代优化，并由编译器诊断信息指导修订。

• 基础模型 — ZoomGain-9B 基于 Qwen3.5-9B 进行后训练（32 层，隐藏维度 4,096，中间维度 12,288，262,144 个位置，线性注意力与全注意力按 3:1 调度）。MathForm-8B 基于 Qwen3-8B 进行后训练（36 层，全部为全注意力，隐藏维度 4,096，中间维度 12,288，40,960 个位置，32 个查询头对 8 个 KV 头，头维度为 128，RoPE theta 为 1e6）。

• 共享维度——两者都从各自的 Q​wen 父模型继承了 4,096 的隐藏宽度和 12,288 的中间宽度，这是它们之间最显著的巧合，并且这是该模型家族的属性，而非微调所带来的属性。

• 词汇表——ZoomGain-9B 为 248,320 个 token，而 MathForm-8B 为 151,936 个。MathForm 的词汇表属于 Qwen3 世代，这一点很重要：Lean 4 代码、Unicode 数学符号和证明 token 在两者中的分词方式并不相同。

• 背景——ZoomGain-9B 的模型卡未说明任何内容，其配置声明为 262,144；MathForm-8B 的配置声明为 40,960，其推荐的服务命令上限为 16,384，且 max_new_tokens 为 16,384 个 token。对于自动形式化，输出长度才是约束性限制，而非输入长度。

• 模态 —— 一个以图像和文本为输入、以文本为输出；另一个以文本为输入、以文本为输出。

• 许可证 — ZoomGain-9B：代码采用 Apache 2.0，检查点条款待定，且 Hub 元数据中没有许可证标签。MathForm-8B：采用 Apache 2.0，仓库中包含 LICENSE 文件。

• 分发 — ZoomGain-9B 提供 BF16，以及 F16、Q8_0 和 Q4_K_M 的 GGUF。MathForm-8B 提供分为四个分片的 BF16 safetensors，总计约 16.4 GB，另有社区 GGUF 和 MLX 构建，但没有厂商自行提供的量化版本。

MathForm-8B 的数值，以及为什么它们比看上去更容易核对

OpenBMB 报告称，在其六个基准上，语法检查 pass@8 平均为 88.06%，一致性检查 pass@8 平均为 72.37%。在同一张表中，ReForm-8B 达到 81.76 和 66.21，Goedel-Formalizer-V2-32B 达到 78.28 和 63.74，StepFun-Formalizer-32B 达到 63.65 和 44.47。三个 FATE 划分正是专用模型崩溃而 MathForm 没有崩溃的地方：FATE-X 的语法为 54.00、一致性为 37.00，而 ReForm-8B 为 45.00 和 21.00。

有两件事让这些数字比典型的厂商表格更可信。第一，这些任务具有一种感知任务所不具备的机械性——Lean 4 陈述要么能编译，要么不能，而一致性检查会将含义与源命题进行比较。一个部分可由机器验证的基准更难被乐观地评分。第二，论文指出仅使用 SFT 的模型更差：MathForm-8B-SFT 的语法得分为 84.38，一致性得分为 66.53，因此 RL 阶段在做可测量的工作，而不是为一个已完成的模型做装饰。

还有一个对比值得引用，因为它与模型自身的说法相悖。在同样的六个基准上，Qwen3.7-Plus——一个通用商业端点——语法得分为 86.33，一致性得分为 83.38。MathForm-8B 在语法上以 1.7 分胜出，在一致性上落后 11 分。这个专门微调模型在精确匹配任务上胜出，但在要求形式化结果与源语句含义一致的任务上落败。如果你的流水线需要一个可编译的语句，小型专用模型很划算。如果它需要一个忠实的语句，带检索的通用模型可能仍然更胜一筹。

ZoomGain-9B 的数据，采用相同的统计口径

作者报告称，在 HR-Bench 4K 上得分为 90.25，而基础模型为 82.13；在 V*Bench 上为 93.19，对比 86.91；在 VisualProbe 上为 56.31，对比 44.66；在 MMVP 上为 70.00，对比 60.00；在 O3-Bench 上为 68.12，对比 56.52。十三个基准上的留出平均分为 66.10，对比 59.75。在 ZoomGainBench 上——该基准由与训练数据相同的流程构建——模型得分为 55.48，论文将该列标注为“Held-in”，而不是掩盖这一区别。

与 MathForm 的证据相比，结构上的差异在于，ZoomGain 的基准无法以同样的方式进行机器验证。选择题答案是精确匹配，计数是对整数进行精确匹配，OCR 则按 ANLS 评分——但问题本身是生成的，而作者自己的检查是答案可以在裁剪视图上得到验证。一个答案经过验证的生成问题仍然是一个生成问题。

两个版本在制作过程中都部分使用了模型作为标注者。ZoomGain 的附录列出了这些角色：Qwen3.5-397B-A17B 负责场景描述、grounding 和最终 MCQ 验证；Qwen3-VL-235B-A22B-Instruct 和 Kimi-K2.6 负责基于裁剪区域的验证和盲答；DeepSeek-V4-Pro 负责干扰项聚类。MathForm 的 FormalVerse 由一个流水线构建：先从 Mathlib 中检索，然后让编译器拒绝不良生成。一个流水线依赖一个无法被说服而表示同意的验证器；另一个则依赖模型检查其他模型的工作，仅辅以人工筛选。

用你的运营团队会问到的术语来交付它们

ZoomGain-9B 在 BF16 下为 18.82 GB，可在 vLLM 0.19.1 和 transformers 5.7.0（即作者使用的确切版本）下运行，也可在支持 Qwen3.5 多模态的 llama.cpp 构建下运行，并使用 GGUF 文件外加一个投影器。其以线性注意力为主的主干在长序列长度下仍能保持较小的 KV 缓存，而正是这一特性在单个请求携带高分辨率图像而非长文档时至关重要。

MathForm-8B 在 BF16 下约为 16.4 GB，可由 vLLM 以 16,384 的最大模型长度提供服务，或由 SGLang 在相同上下文下提供服务，温度为 0.6、top-p 为 0.95，输出预算为 16,384 个 token。其评估需要运行中的 Kimina Lean Server 和 Lean 4.21.0，而这正是人们容易低估的部分：你不仅是在部署一个模型，还要在它旁边部署一套 Lean 工具链。编译反馈在训练期间是奖励信号，在评估期间是验收测试，因此没有 Lean 的流水线无法衡量这个模型是否正常工作。

这两者目前都不在 OrcaRouter 的目录中，本文也没有作此声称。我们能做的是把周边的工作路由起来。一条先读取扫描页面、再核对其上数学内容的文档流水线分为两半：视觉调用和推理调用。一个密钥即可覆盖 200 多个模型，按供应商标价计费、不额外加价，一条把每一半都送往能够达到你门槛的端点的路由规则，以及任一半停滞时的自动故障转移——这正是支撑这两半的底层，也正是为什么双模型流水线不必意味着两家供应商和两份合同。

要下载哪一个

如果你的问题是形式化的，而且工具链已经是 Lean，就选 MathForm-8B。证据更强，许可证明确无疑，输出可机器检查，而相对于通用模型 11 个百分点的一致性差距是你投入前应当了解的真实局限。尤其是在 FATE 划分上更应选它，专用基线的一致性降至 21%，而它保持在 37%。

如果问题在于图片中的某个细节，而且答案很短，那就选 ZoomGain-9B。它的留出集增益在 9,000 个样本上可信，其基准可以下载，因此你可以自行核实这一说法，而许可证是你在交付前必须阅读的一项内容。不要指望它作为通用视觉助手来选择它；发布内容中没有任何测试涉及这一点。

如果你希望得到一个判定，说明哪个才是更好的 90 亿参数模型，那么发布说明比任何排行榜都更能回答这个问题：它们是为对照不同类型的地面真值而构建的，而这些地面真值中只有一种能编译。