ZoomGain-4B 与 MiniCPM5 2B：可移植性是一项无人发布的基准测试

两张模型卡都缺少一个数字，而正是这个数字决定大多数部署。 MiniCPM5-2B 提供 GGUF、MLX、GPTQ 和 LiteRT 构建，配有用于投机解码的 DSpark 草稿模型，而且——最能说明问题的细节——带有面向九种不同加速器家族的 FlagOS 构建，包括 Ascend、Hygon、Kunlunxin 和 Metax。 ZoomGain-4B 以三种精度提供 GGUF 构建，并且用模型卡自己的话说，需要“支持 Q​wen3.5 多模态的 llama.cpp 构建”。其中一个模型几乎能在任何地方运行。另一个只能在你能构建特定运行时的环境中运行。两张模型卡都没有把这称为基准测试，而对于任何必须真正运行模型而非仅引用模型的人来说，这一行比任一模型的准确率列都更重要。

那种说法并不是在回避准确率比较——比较在后面，而且准确率比较最终并没有看起来那么有决定性，因为这两个模型并不是在同一维度上衡量的，也不可能在同一维度上衡量。来自 OpenBMB 的 MiniCPM5-2B 是一个文本模型：25.2 亿参数，发布于 2026 年 9 月 6 日，针对智能体、工具调用、代码和长上下文进行了调优。来自 inclusionAI 的 ZoomGain-4B 是专注于视觉语言的专用模型，于 2026 年 11 月 11 日发布，通过强化学习在关于精细视觉细节的问题上进行训练。接下来要说的是：每个模型衡量的是什么、部署每个模型需要多少成本，以及真正诚实的分界线在哪里。

缺失的那一行：运行每一个需要付出什么

从工件列表开始，因为它是两家发行商中任何一家给你的最具体的东西。

• MiniCPM5-2B。一个基于标准 LlamaForCausalLM 类的稠密因果 Transformer——42 层，GQA，16 个查询头和 2 个 KV 头，131,072 token 上下文，总参数 2,516,756,480 个，其中 1,981,982,720 个为非嵌入参数。由于架构是标准的，它继承了所有已为 Llama 形态模型编写的服务路径。该组织将 SFT、Midtrain 和 Base 变体作为独立仓库发布，此外还有 GGUF、MLX 和 GPTQ 量化版本，用于推测解码的 DSpark 草稿模型，用于设备端 Android 的 LiteRT，以及具有相同变体集的 1B 同级模型。

• ZoomGain-4B. 共有 4,539,265,536 个 BF16 参数，分布在语言模型和独立的视觉编码器中。提供三种 GGUF 精度——Q4_K_M 为 2.71 GB、Q8_0 为 4.48 GB、F16 为 8.42 GB——每种精度都搭配一个 mmproj 投影器文件，模型卡称该文件是图像输入所必需的。没有 MLX 构建，没有 GPTQ，没有 ONNX，也没有草稿模型。唯一明确指定的运行时是支持 Qwen3.5 多模态的 llama.cpp，这个要求实际上比听起来更窄：你需要一个足够新、能识别 qwen35 架构的构建版本，而且模型卡要求你显式提供这两个文件，而不是指向一个现成的路径。

这种不对称并不是对 inclusionAI 的批评。一个九天前才发布、从未正式宣布过的视觉模型，本就不该被指望具备 Android 运行时。这只是现状而已，而它意味着这两个模型在真正花钱的那个维度上并不能互换：MiniCPM5-2B 可以在你已有的硬件上运行，包括手机；ZoomGain-4B 则只能在 GPU 上、在你可能还得自行编译的运行时里运行，除此之外别无他处。

“小”的两种不同定义

两者都被称为 small 模型，而这个词在两种情况下所起的作用并不相同。

• 参数，如实计数。 MiniCPM5-2B 在 2.52B 总参数中拥有 1.98B 非嵌入参数——这一数字决定每 token 的计算量。ZoomGain-4B 总参数为 4.54B，其中约五亿来自视觉编码器和投影器。去掉视觉栈后，两个语言主干的大小差异在舍入误差范围内。行为差异来自其上层所训练的内容，而非规模。

• 训练的目标。MiniCPM5-2B 的模型卡将其最强领域列为代码与数学推理、长上下文理解、工具使用和智能体任务，并将其目标定位为本地助手、编程智能体和端侧部署。ZoomGain-4B 的模型卡只涉及一件事：模型能否回答一个只有放大图像后才能看到答案的问题。

• 各发布方选择公开了什么。OpenBMB 发布了 MiniCPM5 的完整变体系列——基础版、中间训练版、SFT 版、RL-plus-OPD 最终版，外加一个草稿模型和面向九个芯片系列的预构建二进制文件。inclusionAI 发布了三个模型仓库、两个数据集，以及一个包含数据构建流水线和 GRPO 启动器的代码仓库。一个是产品线；另一个是附带了实验记录的研究发布。

• 许可证。MiniCPM5-2B 在模型卡上标注为 Apache 2.0，该许可同时适用于代码仓库和权重。ZoomGain 的代码采用 Apache 2.0，而检查点相关条款则以检查点仓库为准——截至本周，该仓库的元数据中尚未标注任何许可证标签。发布前请先阅读该文件。

基准列，以及它们为何不符合要求

这两个模型之间没有任何共同的基准。一个都没有。ZoomGainBench 是一组关于照片的问题，而 MiniCPM5-2B 没有图像编码器；MiniCPM5 表格中的其他所有基准都是文本，并且 ZoomGain-4B 从未在其中任何一个上运行过。因此，这里不做正面交锋，而是分别列出各发布方实际测量的内容，并有意将它们分开呈现。

MiniCPM5-2B，厂商报告其测试套件平均得分为53.9：

• 代码 — LiveCodeBench v6 69.1、OJBench 32.5、SWE-bench Verified 46.4。

• 数学 — AIME 2025 86.5，AIME 2026 86.5，MATH-500 94.6。

• 知识 — MMLU-Pro 70.8，GPQA-Diamond 70.2。

• 长上下文 — AA-LCR 59.0、NoLiMa 68.1、LongBench v2 43.7。

• 工具使用与智能体 — τ²-Bench Telecom 97.1，BFCL v4 66.6，BrowseComp-ZH 43.5，GAIA Text-103 88.7。

ZoomGain-4B，供应商报告：

• 感知，held-in 基准 — 在 ZoomGainBench 上得分为 55.81，而其父模型 Qwen3.5-4B 为 30.03。

• 感知，留出集平均分——在十个训练从未见过的基准上为 60.96，而父模型为 54.20。这就是值得引用的 6.76 分提升。

• 各留出集的变化 — Visual Probe 43.30 至 57.28，O3-Bench 54.20 至 63.19，HR-Bench 4K 81.25 至 87.25，MME-RealWorld-Lite 57.89 至 61.59。

把这两份清单并排来看，决策的走向就一目了然。MiniCPM5-2B 已在开发者关心的十七个方面接受过测试，并且在几乎所有方面都取得了相当不错的成绩；τ²-Bench Telecom 的 97.1 和 GAIA Text-103 的 88.7 是最亮眼的数字，其定位正是建立在这两个数字之上。ZoomGain-4B 只在感知方面接受过测试，基本上没有涉及其他方面，而它带来的提升——在未见过的基准上平均约七分——是真实的，但范围很窄。

如果只需要一句话：MiniCPM5-2B 是一个通用型小模型，却有着异常深厚的基准测试成绩单；而 ZoomGain-4B 是一个专才模型，其平均七分的提升在通用榜单上会不可见，因为通用榜单并不包含它擅长的题目。

两者实际共存之处

两类方案都适用的工作负载有一个共同形态：一份文档、一张截图、一张照片、一份表单。必须有某个环节查看图像并提取出一个值，也必须有某个环节完成之后的一切——解析模式、调用正确的工具、验证、重试、转交给人工。

这种提取是 ZoomGain 式的。小字号文本、紧凑裁剪、非对即错的答案，以及一个针对“在裁剪图中读取标签”与“在完整画面中读取同一标签”之间的差异进行过专门训练的模型。ZoomGain-4B 在 HR-Bench 4K（训练后从 81.25 提升到 87.25）和 MME-RealWorld-Lite 上的留出集数字，恰恰呈现出一个在密集细节上变得更强、却没有在其他方面变差的模型特征。

其余部分也是 MiniCPM5 风格的；在工具使用方面，它相对于自身规模而言强得非同寻常——τ²-Bench Telecom 达到 97.1，这是大多数体积大三倍的模型都达不到的数字；BFCL v4 达到 66.6，说明其函数调用并非演示性质。

同时运行两者意味着两套运行时、两个许可证，以及多一个可能出故障的东西。这也正是路由器能证明自身价值、而不只是口号的地方：图像调用发往视觉端点，工具调用轮次发往廉价的文本端点，而任一端出现卡顿都会自动故障转移到另一端，而不是在你的流水线中以 504 的形式暴露出来。一个密钥、一张账单，故障转移逻辑集中在一处，而不是在两个 SDK 中重复。

值得明确说明我们提供什么、不提供什么。MiniCPM5-2B 目前不在我们的产品目录中。我们确实托管 Q​wen3.5 系列——35B-A3B 每百万 token 输入 $0.057、输出 $0.459，27B 为 $0.086 和 $0.688，两者均为多模态——而该系列正是 ZoomGain-4B 训练所基于的底座，因此，如果你想在决定采用自托管 4B 之前测试 crop-and-ask 是否能提升准确率，它是最接近的托管近似方案。至于工具调用这部分，同一产品目录也能提供你今天就能调用的东西。我们无法做的是托管 ZoomGain-4B，再多的路由也改变不了这一点：它是下载项，不是 API。

诚实的裁决

选择 MiniCPM5-2B，如果你想要一个小模型，能在本周部署到你已拥有的硬件上、运行在已有的运行时中，采用 Apache 2.0 许可证，并且有一张足够全面的基准测试表来预测它的表现。它是两者中完成度更高的那个。其 1.98B 非嵌入参数让每 token 成本很低，其工具调用数据是它那一列中最出色的，而芯片厂商构建版本意味着它并非只适用于数据中心。

如果符合以下情况，就选 ZoomGain-4B：你要消除的具体错误是视觉层面且细粒度的，并且你愿意用一个小众的 llama.cpp 构建版本来运行 GPU 来解决它。它的依据建立在一个可信数字上——基于 9,000 个训练样本，在十个留出感知基准上平均提升 6.76 分——并且依托一个基准、数据和评测框架，让你能自行核验这一说法，而不是盲目相信它。

如果你还没有衡量过自己的流水线在哪些地方出错，就不要选其中任何一个。MiniCPM5-2B 公布的最弱结果是搜索智能体和长文档推理（BrowseComp-ZH 43.5，LongBench v2 43.7），而 ZoomGain-4B 从未被问过一个与图片无关的问题。为了一个你尚未弄清其特征的问题而购买其中任何一个，正是三十亿参数模型最终进入生产环境却无所作为的原因。

不光彩的结论是：这两个模型并非竞争对手，而是同一项工作的两个相邻阶段；而这一比较之所以一再被框定为一场竞赛，是因为发布基准测试比说明可移植性更容易。MiniCPM5-2B 赢下的是会被发布的那一栏。ZoomGain-4B 赢下的是一个尚不存在的栏目，在单一任务上领先约七分，但附带一项运行时要求，会让大多数团队一开始就止步。