MiniCPM-V 4.7 35B-A3B vs MiniCPM-V 4.7：这两个名称中有一个不是模型

搜索 MiniCPM-V 4.7，你会找到一张模型卡、一张基准测试表、一个手机演示和一个下载按钮。搜索 MiniCPM-V 4.7 35B-A3B，你会找到同样的东西，因为它们是同一个发布——而这正是比较它们的全部难点。OpenBMB 的模型卡开篇一句话就定了调：MiniCPM-V 4.7 是该系列的最新模型，提供 35B-A3B 变体，而 35B-A3B 是该系列中首个 MoE。裸名称是一面旗帜。带后缀的名称是一个检查点。把 350 亿参数的稀疏专家混合模型放在一边，把一面旗帜放在另一边，你得到的不是比较，而是一个问题：你到底想下载哪个产物。回答这个问题，本页其余部分就是一份规格表。

名称，已解析

有三样东西都对应“MiniCPM-V 4.7”这个名称，而其中只有两样可以下载。

• openbmb/MiniCPM-V-4.7——并不存在。该 URL 返回的是授权错误，而非权重页面。从来就没有以这个名称发布的裸检查点，而把一组数据冠以另一个名称来报道的做法，等于是在用一个背后根本没有仓库的名字引用 35B 的数值。

• 该系列——由 OpenBMB 维护的一个 Hugging Face 集合，在 4.7 的名号下收录了十三个仓库：基础版 35B-A3B 检查点、其 GGUF 构建版、FP8、AWQ、GPTQ 与 int4 量化版本、与之配套的 DSpark 投机草稿头，以及小模型同样的一整套六种版本组合。当 "MiniCPM-V 4.7" 被用作产品线名称时，所指的就是这个集合。

• openbmb/MiniCPM-V-4.7-35B-A3B——该公告所涉及的检查点，创建于 2026 年 10 月 7 日 07:07 UTC，采用 Apache-2.0 许可，并于 10 月 12 日补充了完整的模型卡。这是该系列中目前唯一带有厂商基准测试表格的模型。

所以，对于“MiniCPM-V 4.7 与 MiniCPM-V 4.7 35B-A3B”这个问题，诚实的答案是：它实际上归结为同一系列内部的变体选择，而仅凭系列名称并不能让你拿到一个文件。它唯一能让你拿到的文件是 35B-A3B，这正是读者会一来就以为两者是同一个东西的原因。

这次发布实际上包括哪些内容

OpenBMB 自己的 README 描述了两个变体和一个共享视觉塔，并将发布日期定为 2026 年 10 月 12 日——也就是权重上传后的第五天和第六天。如果你要引用发布日期，这个间隔很重要。这些仓库创建于 10 月 6 日和 7 日；模型卡、许可证标签、图表和公告都在 12 日上线。参数并没有在 12 日变动。文档变了。

文档涵盖的内容，适用于两个变体：

• 两个检查点——一个 35B-A3B 稀疏 MoE 和一个 1B 稠密模型，共享一个谱系名称和一个视觉塔，除此之外底层再无其他共同之处。

• 一条共享的视觉通路——该系列自有的minicpmv4_7_vision塔，27 层、隐藏维度 1,152、patch 大小 14、图像尺寸 980，在第 6 层拼接进语言栈，其前方还含一项 ViT 内部的早期压缩，OpenBMB 将其归功于 LLaVA-UHD v4。

• 混合 4x/16x 视觉 token 压缩——可按请求选择，默认使用 16x 以提升吞吐量，使用 4x 以保留细节。卡片指出，其对比表中没有其他模型提供这种选择，并且该设置必须同时传递给聊天模板和 generate 调用，否则占位符数量和视觉编码器就会不一致。

• 一个不再围绕权重展开的部署叙事——面向 iOS、Android 和 HarmonyOS 的目标平台，来自 Rockchip、Houmo、Intel、AMD 和 Arm 的首日芯片支持，适用于 Intel CPU/GPU/NPU 的 OpenVINO，以及对 SGLang、vLLM、llama.cpp 和 Ollama 的框架支持。在这里，产品是应用和量化构建版本，而不是 BF16 下载包。

两个检查点，逐个维度

六个维度，两边，并附注说明每个数字实际意味着什么。

• 参数与形态——MiniCPM-V 4.7 35B-A3B：35,212,875,824 个存储参数，稀疏，256 个专家，每个 token 激活 8 个，专家中间层大小为 512，外加一个同尺寸的共享专家。MiniCPM-V 4.7 的 1B 变体：1,554,476,272 个参数，稠密，每个 token 都会激活其中每一个。这两个总数不是同一个量，而且 MoE 的每 token 激活预算并未公布，所以请把“A3B”当作名称的一部分来读，而不是当作一个可以与稠密模型进行比较的测量值。

• 下载体积 — MiniCPM-V 4.7 35B-A3B：在 BF16 下，70.4 GB 分散于十六个 safetensors 分片，尚未计入任何 KV 缓存。MiniCPM-V 4.7 1B：约 3.1 GB，位于单个权重文件中。一侧的下载量是另一侧的二十二倍，而这才是衡量其中哪一个开箱即为手机端模型的诚实标准——两者都不是，除非你从量化阶梯中选取一种量化。

• 文本主干与深度 — MiniCPM-V 4.7 35B-A3B：一个 Qwen 家族的稀疏 MoE 文本堆栈，40 层，隐藏维度 2,048，16 个查询头对 2 个键/值头，词表大小 248,144。MiniCPM-V 4.7 1B：一个 Qwen 家族的稠密文本堆栈，24 层，隐藏维度 1,024，8 个查询头对 2 个键/值头，词表大小 248,094。同样的设计思路，只是低了一档。

• 注意力——两者皆是：线性注意力与全注意力以固定的三比一比例重复。35B 的四十层中有三十层走线性路径，其余十层为传统路径；1B 的二十四层中有十八层走线性路径，其余六层为传统路径。正是在这一维度上，两个模型确实是同一架构的缩放版本，这也是两者能够承载 256K 上下文而 KV 缓存不会爆炸的原因。

• 上下文——两者均为：最多 262,144 个位置，并采用相同的 canvas 多模态旋转嵌入模式。没有变体代价，小模型上也不做截断。

• 许可证 — 两者均为：Apache-2.0，在仓库前置元数据中声明，并在 README 中予以确认。两者也都发布在 Hugging Face 和 ModelScope 上。条款上并无差异需要权衡。

基准表是为其中之一而存在的

真正左右决策的不对称就在这里。35B-A3B 检查点带着 OpenBMB 的对比表格——MMMU 约 80.2，OCRBench 约 91.2，OmniDocBench v1.6 处在九十几的高位，CharXiv 推理在七十几的中段，TextVQA 在八十几的中段——对照的是两个 35B-A3B 级别的 Qwen 模型、一个 31B 的 Gemma 和两个 27B 的 Qwen，均为 Instruct 模式。本文在记录这次发布时已经谈过这些表格值多少分量；简而言之，它们是厂商自报、厂商自测、未经复现，而且取自 PNG 图表，而非公布的分数表。

1B 在同一份文档中有自己的图表，那里的对比对象是一个更小的范围。如果你要在两种规模之间做选择，这些卡片给你的有用信息并不是一个分数——而是：那个更大的检查点才是效率论证所针对的对象。支撑整个发布版本的那个端侧数字——在 iPhone 17 Pro Max 上、约 3 GB 内存下每秒 13 个以上 token——是 35B-A3B 的数据，它借助 Lookahead Expert Scheduling 通过量化权重跨层预取专家而产生。小型密集模型不需要那套机制，因为 15.5 亿个密集参数无需其中任何一项就能放进手机的工作内存。

这是一个值得深思的反转：小模型简单直接，但在基准测试方面缺乏文档；大模型文档详尽，却难以运行。两种处境都没有哪一个明显更好。

人们实际下载的是哪一个？

Hugging Face 的计数器揭示了一个两个模型卡都未提及的事实，而这一事实支持更大的模型。于 2026 年 10 月 13 日读取时，基础openbmb/MiniCPM-V-4.7-35B-A3B 仓库显示 630 次下载；而-gguf 构建版的同一检查点则显示略高于 10,000 次下载，约为其流量的十六倍。对于 1B，基础仓库及其 GGUF 构建分别为 263 和 2,064，比例相近，但绝对规模小得多。

两种解读，都与数据相符。要么是人们先拉取量化版本，因为能跑起来的是它；要么是 BF16 的数字只是滞后，因为 BF16 检查点并不是任何人实际部署的东西。无论哪种情况，下载计数器衡量的都是哪个产物才重要——而重要的并不是名字里带着其大小的那个。如果你要为这个决策做量级评估，就对着 GGUF 或 AWQ 版本来估算，而不是对着 70.4 GB。

还有一条列表详情是反着来的。两个仓库都带有从 MiniCPM-V 系列其余成员继承而来的“On-Device Model”标签，而在 70 GB BF16 MoE 上，这个标签的含义只有在经过量化和专家流式处理后，才等同于它在 1B 的 3.1 GB 文件上的含义。请把这个标签当作系列标签，而不是规格说明。

托管 API 改变问题之处

这两个检查点都没有托管在 OrcaRouter 上，而对这次比较来说，这最终成了决定性的结构性事实。两者都是你自行部署的开放权重，这意味着 35B-A3B 需要你很可能没有的硬件，而 1B 需要你肯定有的硬件——而“某块 GPU”和“一部手机”之间的差距，才是“35B-A3B vs 4.7”的真正内容。

路由器真正体现价值的地方在于边界。如果你选了 1B 模型，而它不足以处理某个请求，这项工作就必须有去处，而这个去处通常是一个你不想逐家供应商去管理的托管模型：OrcaRouter 覆盖了数百个托管模型，只需一个密钥，按各家供应商的标价提供，不额外加价，并且当某家供应商服务降级时在供应商之间故障转移。其中一个托管模型 ID，qwen/qwen3.6-35b-a3b，正是本文所讨论的检查点的直接托管对应版本——相同的 35B-A3B 形态，无需自己拥有加速器即可访问，这使它在把 70 GB 自己的磁盘空间投入本地版本之前，成为天然的测试上限。

这是路由决策，而非第二次集成；而且它是这个选择中唯一可以零成本撤销的部分。

精选

如果约束条件是手机、笔记本电脑或单块小型 GPU，那么 1B 是唯一候选——3.1 GB、允许商业使用的许可证，以及从第一周起就已发布的量化阶梯。如果目标是 OpenBMB 实际上在争论的效率结果，那么你要的是 35B-A3B，而且你要的是量化构建版，而不是 70 GB 的原始版，因为那是其他所有下载者都拿走的版本，也是端侧声明所测量的版本。

你不应做的是把这两个名称当作可以互换的。其中一个是今天下午就能运行的检查点。另一个是一个标签，无论你本意是两者中的哪一个，它都会一直返回 35B-A3B 的模型卡。