MiniCPM-V 4.7 对比 Gemma 4 12B：一个发布基准测试结果，另一个发布这些结果的图片

打开 MiniCPM-V 4.7 的模型卡并滚动到评测部分。你会发现三张图：性能与推理时间的前沿图、总体视觉语言对比，以及总体语言对比。你不会找到表格。现在打开 Gemma 4 12B 的模型卡并滚动到同一位置。你会发现 MMLU Pro、AIME 2026、LiveCodeBench v6、GPQA Diamond、Codeforces ELO、MMMU Pro、MATH-Vision 以及一个文档解析错误率，每一项都带有一个你可以复制到电子表格里的数字。两个模型都是开放权重，都是 Apache 2.0，都被定位为可运行在你自己硬件上的多模态模型——而其中只有一个能让你核验它的工作。像这次发布背后的有记录 AI 故障和智能体事件都收集在the OrcaRouter AI Incident Archive中，其中每条记录都带有自己的来源、严重程度、置信等级和争议标记。

那种不对称才是真正的比较所在。OpenBMB 于 2026 年 10 月 12 日发布的 MiniCPM-V 4.7，以及 G​oogle DeepMind 于 2026 年 6 月 3 日发布的 Gemma 4 12B，并不是同一类对象，差别也不在规模。而在于每个厂商愿意把自己主张中的多少内容写进文本。

用数字看每家供应商会告诉你什么

Gemma 4 12B 的模型卡公布了其与五个同系列模型及一个前代模型对比的得分，并针对每项基准注明了所用的评测框架。具体到 12B Unified 变体，厂商报告称：MMLU Pro 为 77.2，AIME 2026 在不使用工具的情况下为 77.5，LiveCodeBench v6 为 72.0，GPQA Diamond 为 78.8，Codeforces ELO 为 1659，Tau2 三次运行平均为 69.0，MMMLU 为 83.4，以及最能如实说明 12B 模型定位的数字——Humanity's Last Exam 在不使用工具的情况下为 5.2。视觉方面，其报告称 MMMU Pro 为 69.1，MATH-Vision 为 79.7，OmniDocBench 1.5 上的平均编辑距离为 0.164，该指标越低越好。

这些是厂商给出的数字。独立方没有义务认同它们，而对于一个部署如此广泛的模型来说，其中一些数字在换用不同的评测框架后是经不起检验的。但它们是可证伪的，而这正是关键所在。如果你自己的评测在 MMLU Pro 上得到 62 分，你就知道你的配置或显卡有问题。

MiniCPM-V 4.7 的模型卡在正文中提出了四项数值主张，却完全没有基准测试表格。35B-A3B 变体在 iPhone 17 Pro Max 上使用约 3 GB 内存时，解码速度达到每秒 13 个或更多 token。Lookahead Expert Scheduling 在真实设备上实现了 5 倍加速。1B 变体在总体得分和推理效率上均优于 Qwen3.5 0.8B。而在 Instruct 模式下，35B-A3B 相比 Qwen3.6 35B-A3B，以更少的推理时间达到了更高的总体得分。其余所有内容——比较的每一个维度——都存在于图表图像中。

那不是不诚实。图表承载信息，而且前沿图可以说比一张在不同批大小下测得的各基准分数表更能总结速度与质量之间的权衡。但图表无法被引用，无法被重新推导，也无法在没有人读取像素位置的情况下与另一家厂商的图表进行比较。当一个模型唯一的公开评估只是一张图片时，正确的姿态是：在有人对其进行测量之前，就把它视为未被测量。

这两种架构解决的是不同的问题

略过评估部分继续往下读，各设计方案就会明显分化，这比任何单一评分都是更有用的信号。

Gemma 4 12B 是无编码器的。它没有单独的视觉塔，也没有单独的音频编码器：原始图像块和音频波形通过轻量级线性层直接投影到语言模型的嵌入空间。Google 给出的理由是延迟和单遍微调——一个模型、一次训练运行、涵盖所有模态。代价是，该公司正在押注一个仅解码器 Transformer 无需专用视觉前端也能学会看得足够好。其自身的 MMMU Pro 得分为 69.1，而确实带有约 550M 参数视觉编码器的 31B 同系列模型为 76.9，这表明这一押注在精细视觉推理上有所损失。

MiniCPM-V 4.7 走的是另一条路线。它保留了专用视觉塔——隐藏宽度 1152、27 层、980 像素图块——并把工程投入放在降低这座视觉塔的成本上。借鉴自 LLaVA-UHD v4 的 ViT 内部早期压缩，在编码器内部而非编码器之后削减视觉 token；混合 4×/16× 下采样开关则让调用方可以按请求在细节与成本之间进行选择。语言侧，35B-A3B 是一个 256 专家混合模型，每个 token 激活 8 个专家，并在 40 层中按线性注意力与全注意力 3:1 的比例分层排布。

这种设计带来的实际结果是，MiniCPM 的视频处理路径异常明确。模型卡中公开了 max_num_frames 为 128、stack_frames 参数（用于将子帧合成到主帧之间的网格中），以及针对图像（36）和视频（1）分别给出的切片数量指引。如果你要构建读取屏幕录制或讲座视频的应用，这种对采样内容的控制粒度本身就是其核心特性。Gemma 4 12B 同样能处理视频，将其作为帧序列来处理，但它的模型卡记录的是格式，而非采样策略。

真正起决定作用的那些行

• 参数 — 总计 35.21B，256 个专家中有 8 个激活，外加一个 1.55B 的稠密同级模型，对比 11.95B 的稠密模型

• 输入模态——文本、图像、视频，其中 OCR 和 PDF 解析被单独列出；对比文本、图像、视频和原生音频

• 上下文 — 262,144 个 token，对比 12B 上的 262,144 个 token，以及 E 系列同系列型号上的 128K

• 许可证 — Apache 2.0，权重可下载 对比 Apache 2.0，权重可下载

• 已发布的评估——前沿与对比图表，四项文字论述对比一张涵盖八个同系列模型的完整数值表

• 独立评估——截至本文撰写时，两个 4.7 变体在 Artificial Analysis 上均无条目，而对比对象是包含智能排名和吞吐量信息的 Artificial Analysis 页面

• BF16 下的内存占用——35B-A3B 的权重约为 70 GB，1B 约为 3.1 GB，相比之下约为 24 GB

• 已发布的量化格式——GGUF、bitsandbytes、AWQ、GPTQ、FP8、int4，与上游检查点相比，此外还有来自 G​oogle 及第三方的社区 GGUF 与 QAT 构建

• 由厂商命名的服务路径——SGLang、vLLM、llama.cpp、Ollama、Transformers、OpenVINO vs Transformers，更广泛的生态系统则由社区提供

• 端侧方案——iOS、Android、HarmonyOS 应用，加上对 Rockchip、Houmo、Intel、AMD 和 Arm 的首日支持，对比针对笔记本电脑和消费级 GPU 优化的设计

三个工作负载，三个答案

规模化屏幕与文档理解。 这正是 MiniCPM-V 4.7 的设计目标所在，也是其文档最有力之处。4× 下采样模式、36 切片设置、OCR 与 PDF 解析的 cookbook 条目，以及视频的显式帧采样控制，共同描述了一条将渲染内容转换为结构化文本的流水线。Gemma 4 12B 在这方面同样可信——其 OmniDocBench 编辑距离 0.164 是一个真实的文档解析指标——但厂商的模型卡将文档解析视为众多能力之一，而非组织原则。

任何需要听声音的场景。Gemma 4 12B 原生支持音频，其卡片上 CoVoST 为 38.5，FLEURS 为 0.069。MiniCPM-V 4.7 则不支持。OpenBMB 的音频工作归属于独立的 MiniCPM-o 系列，而 4.7 的卡片完全没有列出音频模态。如果你的输入包含语音，这场比较还没开始就已结束——一个模型需要在前端加一步转写，另一个则不需要。

预算固定，只有一块消费级 GPU。Gemma 4 12B 在 4-bit 下可装入 8 GB 以内，还能为上下文留出空间；35B-A3B 在 4-bit 下无法装进一张消费级显卡，而它自己的模型卡上的性能说明讲的是手机保持 3 GB 常驻内存，而不是一块有 70 GB 专家权重需要分页的 GPU。如果约束是“你已拥有的一张卡”，那么 12B 就是答案，而 1B 变体是唯一适用的 MiniCPM。

买方应计入定价的差距

两个模型都可以免费下载，因此许可证这一项打成平手，真正的成本在于其后的所有环节。对于 Gemma 4 12B，生态系统已经有四个半月的时间来跟进：Google 自家的量化构建、社区 GGUF 转换、QAT 检查点，以及独立索引——让你能在同一尺度上把它与上百个其他模型进行比较。对于 MiniCPM-V 4.7，你进入一个新架构才八天——新的 model_type、新的注意力布局、最低 Transformers 版本要求——而且厂商自己的模型卡一开头就指出，CUDA 版本不匹配会通过 torchcodec 破坏视频解码。

这并不是对模型的批评。这是任何东西在最初两周被采用时都要付出的标准代价，也正是为什么一个只带图表评估的静默发布，不适合作为生产路径的候选，却很适合作为并排测试的候选。让这种测试变得廉价的方法，是在评估新来者时让现有系统继续提供服务——这是一个路由问题，而不是建模问题。

OrcaRouter 通过一个与 OpenAI 兼容的端点运行 200 多个托管模型，加价为 0%，按提供商标价直接透传，因此尝试第二个模型的成本只是一次配置更改，而不是再签一份合同。它的路由 DSL 可以在单次调用中同时容纳主路径和回退路径，并且自动故障转移能在某个提供商出现故障时段时保持主路径存活。这里的覆盖范围说明才是重点：我们的目录包含 Gemma 4 26B-A4B 和 Gemma 4 31B，而不包含这个 12B；并且完全不含 MiniCPM-V 4.7。本文讨论的这两个模型都是自行运行的检查点——路由器是围绕它们存在的基础设施，而不是调用它们的方式。

什么能解决这件事

这种对比目前的失衡很容易说明，也很容易解决。Gemma 4 12B 给出的是你可以争论的数字。MiniCPM-V 4.7 给出的则是你只能接受或拒绝的说法：每秒 13 个 token、3 GB、5 倍加速、在未具名的综合得分上优于某个具名竞争对手。其中每一项如果做成表格中的一行都会更有用，而 OpenBMB 显然有能力做出这样一张表——该系列早先的模型卡就带有标准基准测试表格。

因此，这种有用的定位是有意做成不对称的。如果你本周就需要做出决定，那么 Gemma 4 12B 就是那个你可以根据已公布数据预测其行为的模型，而它的音频支持是无论等多久都不会加到 MiniCPM-V 4.7 上的能力。如果你是在为手机、HarmonyOS、Rockchip 开发板构建，或者用于读取屏幕和文档，而 4× 下采样路径恰好适合这些场景，那么 MiniCPM-V 4.7 的工程实现比 Google 在这个规模上交付的任何东西都更贴合你的问题——而缺失的表格是让你自己去测量的理由，而不是轻视它的理由。

最后还有一点值得直说，因为它恰恰是两家厂商的叙事框架都装不下的部分。这两款模型争夺的并不是与前沿 API 相同的买家。它们真正要战胜的，是"干脆不在本地跑模型"这个决定。Gemma 4 12B 最有力的论据是：四个月的生态积累意味着那条乏味的老路确实走得通；MiniCPM-V 4.7 最有力的论据则是：一个 3 GB 的 1B 模型能跑在 12B 去不了的地方。先确定约束条件，再选模型——等那张基准测试表出来，它也只会在你已经选定的类别内部重新排列模型而已。