MiniCPM-V 4.7 1B 与 MiniCPM-V 4.7：两个检查点，同一名称，截然不同的任务

没有一个叫 MiniCPM-V 4.7 的检查点。OpenBMB 从未发布过这样的检查点，而本该存放它的模型 URL 返回的是授权错误，而不是权重页面。这个名字指的是整个系列。2026年10月12日，该系列发布了两样东西，读者若用这个名字，很可能指的就是其中任一：MiniCPM-V 4.7 1B，一个为驻留在手机工作内存中而打造的稠密15.5亿参数模型；以及那个350亿参数的稀疏专家混合（MoE）检查点，它承载了此次发布中的每一项头条主张——端侧演示、帕累托前沿图，以及“首个可在端侧流畅运行的开源 MoE”这句话。比较二者并不是一场公平的较量，也从来就不是。问题在于你愿意花多少内存，以及厂商自己的数字是否足够强，足以证明为此花费内存是合理的。

这个名称是一个系列，而不是一个型号

有两个仓库以 MiniCPM-V 4.7 为名，第三个则带后缀沿用该名称。openbmb/MiniCPM-V-4.7-1B 创建于 2026 年 10 月 6 日 17:40 UTC。openbmb/MiniCPM-V-4.7-35B-A3B 随后于 10 月 7 日 07:07 UTC 发布。openbmb/MiniCPM-V-4.7-1B-DSpark —— 一个面向小模型的 2.13 亿参数推测草稿头 —— 于 10 月 8 日上线。三个仓库均采用 Apache-2.0 许可。而仅叫 openbmb/MiniCPM-V-4.7 的仓库并不存在，这一点值得明确说明，因为不少报道写得好像它存在一样，并把一组数字冠以另一个仓库之名引用。OpenBMB 的 README 将此次发布本身标注为 10 月 12 日，如果你需要一个日期，就用这个：仓库先上传，四天后才公布，属于常规顺序。

因此，对“1B vs 4.7”的诚实表述，并不是在同名的小模型和大模型之间做比较。它是在该系列实际提供的两个规模档位之间做比较，而这两个档位中，恰好有一个是仅凭系列名就能找到的唯一一个。

1B实际上是什么

从 safetensors 元数据来看，这个稠密检查点为 BF16 下的 1,554,476,272 个参数——单个权重文件约 3.11 GB，这正是任何考虑在手机上部署的人最关注的核心数字。其语言主干被标记为 qwen3_6_text，深度为 24 层，隐藏层大小为 1024，其注意力采用三线性对一全注意力的模式：24 层中有 18 层走线性路径，六层运行常规注意力。词表大小为 248,094 个 token。视觉塔是该谱系自有的 minicpmv4_7_vision——27 层，隐藏层大小 1152，patch 大小 14，图像大小 980，在第 6 层插入语言栈。对于文档处理而言，有两个设置比其他设置更重要：downsample_mode 为 16x，而 mrope_mode 为 canvas，这是该系列用来在切片图像中保持空间结构完整的多模态旋转嵌入方案。最大位置嵌入为 262,144，因此上下文窗口是名副其实的 256K，而非名义上的。

在撰写本文时，该仓库显示有 14 次下载和 22 个点赞。这个数字很小，但它如实衡量了迄今为止社区对该模型的使用程度。

旗舰到底是什么

35B-A3B 检查点在 BF16 下共有 35,212,875,824 个参数——70.4 GB，分布在十六个 safetensors 分片中，单次下载的体积是稠密模型的 22 倍。在架构上，它完全是另一种生物：40 层、隐藏维度 2048，以及拥有 256 个专家、每个 token 激活其中 8 个的稀疏 MoE 前馈结构，moe_intermediate_size 设为 512。词表大小为 248,144，比 1B 略宽。注意力模式是同一思路在更深层数上的体现——30 个线性层对 10 个全注意力层。它是 MiniCPM-V 系列中的第一个 MoE，也正是厂商效率叙事真正围绕的那个检查点：OpenBMB 声称在 iPhone 17 Pro Max 上以约 3 GB 内存实现每秒 13 个以上 token，并借助 Lookahead Expert Scheduling 跨层预取专家权重，使稀疏路由不会因内存带宽而停滞，此外还配有配对的 MTP 头以及 4x/16x 混合视觉 token 压缩。这些都是厂商数据，由厂商在自家演示上测得。目前还没有其他人复现过。该仓库显示 166 次下载和 43 个点赞——受到的关注比 1B 多出一个数量级。

比较，逐维度进行

六个维度，双方，并附注说明每个数字所占的权重。

• 参数与形态 —— MiniCPM-V 4.7 1B：1.55B 稠密模型，每个 token 上所有参数均处于激活状态。MiniCPM-V 4.7 的旗舰版：总计 35.2B，稀疏，每个 token 激活 256 个专家中的 8 个。这两个总量并非可相互比较的量；决定每 token 计算量的是 MoE 的激活预算，而 OpenBMB 并未公布这一数据。请把“A3B”理解为名称的一部分，而非一项测量指标。

• 权重占用空间 — MiniCPM-V 4.7 1B：单个 BF16 文件 3.11 GB，这正是它存在的全部理由。MiniCPM-V 4.7 35B-A3B：BF16 下跨十六个分片共 70.4 GB。厂商宣称的 3 GB 端侧数值仅适用于较大模型在量化并采用专家流式加载之后的情况，而不是原始下载大小。

• 注意力与上下文——两者兼具：256K 位置、3:1 的线性与全注意力比例，以及相同的 canvas mRoPE 模式。MiniCPM-V 4.7 1B 在 24 层上运行它；旗舰版则在 40 层上运行。这是两个模型真正采用相同设计、仅规模不同的唯一维度。

• 视觉路径——两者相同：均采用该家族自有的 minicpmv4_7_vision 塔，并采用 16 倍下采样。差异出现在压缩步骤的另一侧：旗舰版的图表宣称采用 4x/16x 混合方案，而 1B 并未作出这一宣称。

• 许可证 — 两者皆是：Apache-2.0，在仓库中声明，并在项目 README 中予以确认。这一点很重要，因为它与同一系列一周前的情况恰好相反；对于这两个检查点，这里都无需报告任何歧义。

• 质量证据——MiniCPM-V 4.7 1B：仅有厂商图表。MiniCPM-V 4.7 35B-A3B：厂商图表、一段在 iPad M4 和 iPhone 上的厂商演示视频，以及一项已发布的端侧每秒 token 数声明。两者均无独立评估，也都未由第三方在固定测试框架下进行基准测试。

供应商自己的图表所声称的内容

OpenBMB 为两个检查点都发布了基准测试图表，而它们所能支持的内容之间的差异很能说明问题。1B 图表将模型置于 MMBench 83.17、OCRBench 86.10 和 OmniDocBench v1.6 85.39，在同一张图中与它相邻的上一代 1.3B 级模型之上，三项指标均领先（分别为 81.89、83.80、82.52）。这些数据由厂商报告且未经复现，而且图表自身的列标签必须仔细阅读，因为其中一行印出的数值对于这种规模的模型而言并不可信。把绝对数值当作营销宣传，而把与上一代相比的差值视为唯一具有内在逻辑的部分。

35B-A3B 那张图表更易读，因为对比对象更密集。它报告 MMMU 80.22、MathVista 88.00、OCRBench 91.20、OCRBench_v2 68.47、OmniDocBench v1.6 94.24、CharXiv 推理 75.60、TextVQA 84.99 和 CCOCR 81.14，而对手阵营中包括两个 35B-A3B 级别的混合专家模型、一个 31B Gemma 和一个 27B Qwen3.8。按厂商自己给出的数字，这个 MoE 在大多数行中以微弱优势胜出，也输掉了几行——MMMU-Pro 和 MathVision 则结果相反。再次强调：这是厂商自报、未经复现的数据，唯一公允的解读是“厂商认为它已达到或优于同级水平”，而不是“它已达到或优于同级水平”。

有一个标注问题值得指出，而不是解决。该仓库名为 1B。Hugging Face 侧边栏将该模型描述为 2B 参数。safetensors 元数据显示为 1,554,476,272——约 1.55B。厂商自己的图表将该行标为 1.3B。四个来源，四个数字，而其中最小的那个就在营销所指的图表里。这一切都不改变模型能做什么，但如果你要根据规格表来预算内存，请按 3.11 GB 的文件来预算，而不是按其中任何一个标签。

你到底想要哪一个？

如果约束条件是一台手机、一台笔记本电脑、一块小型 GPU，或任何有功耗预算的设备，那么这些选项里只有一个能成为候选。MiniCPM-V 4.7 1B 之所以存在，正是为了让一个具备 256K 上下文的多模态模型能塞进几 GB 的空间；它采用的许可证允许商业使用，而且量化生态也已经就绪——GGUF、AWQ、GPTQ、int4 和 FP8 构建版本，再加上 Rockchip、Houmo、Intel、AMD 和 Arm 硬件厂商以及 OpenVINO 的首日支持。对于以 3 GB 占用实现端侧 OCR、截图理解和文档解析而言，它就是该系列中能回答这个问题的那个版本。

MiniCPM-V 4.7 35B-A3B 回答的是另一个问题。它并不是同一产品的更大版本；它是在每个 token 只付出 8 个专家开销的同时，试图保持 35B 级模型质量的尝试，而如果厂商的吞吐量声明站得住脚，它就是两者中更有意思的工程成果。此外，它在 BF16 下达到 70.4 GB，是一个服务器或工作站级别的下载项，其端侧方案依赖量化和专家流式加载，而不是你从 Hub 获取的那个文件。

路由器适合用在哪里，又不适合用在哪里

这两个检查点都没有托管在 OrcaRouter 上。MiniCPM 完全没有出现在我们的目录里，而对于想要运行其中任何一个的人来说，正确的建议是自己下载权重并自行部署服务——llama.cpp、Ollama、vLLM 或 SGLang 都支持这一架构，而且上面那份首日支持列表对于一个如此年轻的版本来说宽泛得非同寻常。路由问题要到下一步才会出现，也就是当某个具体请求用一个小型本地模型不够用、这项工作不得不交给托管方案时会发生什么。这次交接是一个路由决策，而不是第二份合约：OrcaRouter 把几百个托管模型放在一把密钥之后，按各家提供商的标价计费，不额外加价，并在某个提供商服务降级时进行故障转移。那份列表上的托管视觉模型中，有几个与 1B 处于同一量级——qwen/qwen3-vl-8b-instruct以及它的思考变体，qwen/qwen3-vl-235b-a22b-instruct用于重负载一端，以及deepseek/deepseek-v4-flash-vision-exp用于长上下文文档处理。那是高于这一系列的一档，而不是它的替代品，并且有必要明确每个模型处在界线的哪一侧。

看什么

有两件事能为这番比较定论，而两者目前都还不存在。第一件是独立评测——用同一套测试框架、在相同硬件上分别跑两个检查点，且提示词不由厂商来挑选。在这类评测出现之前，本文中的每一个准确率数字都出自厂商自己，引用时都应附带这一说明。第二件是 DSpark 草稿头（draft head），它已针对 1B 发布，正是能让小模型在手机上推理显著提速的机制。如果推测解码在这一规模上确如宣传所言，那么稠密版 1B 的表现会比它的体量所暗示的好得多，而 35B-A3B 则仍是那种只在请求确实需要时才去动用的模型。

不需要等待任何东西的，是许可证、架构、资源占用和工具链。它们都在代码仓库中，两个检查点均为 Apache-2.0 许可，足以让你今天就决定这两者之中哪一个属于你的硬件。

该模式中托管的那一半属于路由决策，而非第二份合同。各提供商的标价，我们不额外加价MiniCPM-V 4.7 的两个 checkpoint 都不是 OrcaRouter 上的托管模型——两者都是需由你自行部署的权重。