MiniCPM-V 4.7 迎来模型卡：OpenBMB 公布了基准测试、许可证与端侧声明

在其生命的前六天里，MiniCPM-V 4.7 是一个 70 GB 的 bfloat16 张量文件夹，没有 README——没有模型卡、没有许可证标签、没有基准测试表，也没有任何东西告诉你它是做什么用的。这种情况在 2026 年 10 月 12 日发生了变化，当时 OpenBMB 向 openbmb/MiniCPM-V-4.7-35B-A3B 提交了一份完整的模型卡，声明采用 Apache-2.0 许可证，重写了 MiniCPM-o 仓库的 README，使其以新系列开头，并宣布其为一个面向 iOS、Android 和 HarmonyOS 设备的开源 MLLM 版本。同一轮文档更新也涉及 1B 同系列小模型，它现在带有相同的模型卡结构。这篇文章讲的是其中的差异——模型卡实际声称了什么，其中哪些说法你可以自行核查，以及哪些说法如今只以供应商提供的 PNG 中的像素形式存在。

10月12日到达的是什么，以及原本就在那里的是什么

权重没有变动。openbmb/MiniCPM-V-4.7-1B创建于 2026 年 10 月 6 日 17:40 UTC，而openbmb/MiniCPM-V-4.7-35B-A3B则创建于 10 月 7 日 07:07 UTC；但两者至今仍显示最后修改时间为 10 月 12 日，因为那最后一天花在了文字上，而不是参数上。35B 仓库中 10 月 12 日的提交记录是一场文档冲刺：添加模型卡于 16:08，更新模型卡于 16:15，重命名 35BA3B于 16:23，添加元数据于 16:26，使用绝对资源 URL于 16:50，四个添加入门指南提交一直持续到 17:07，以及链接 LES 文档于 17:09。历史记录中这条分界线以下的一切都是初始化。这个仓库在大约一个小时的时间里，从十八个文件、没有模型卡，变成了一个配有图片、评估图表、部署说明和许可证的、有完整文档的发布版本。

这对你如何解读这则公告很重要，因为发布帖和真正的发布不是一回事。10月12日，这个检查点本身没有任何变化。变化在于，MiniCPM-V 4.7 不再是一个未作解释的上传，而成了一个可以在纸面上评估的产品。

这两个变体，以及它们为何不是同一个发行版本

该公告描述了两个模型，它们在视觉塔以下的部分架构上并无关联——一个是稀疏专家混合模型，另一个是小型稠密模型。

• MiniCPM-V 4.7 35B-A3B — 作为稀疏 MoE，总参数量为 352 亿，拥有 256 个专家、每个 token 激活 8 个，40 个文本层，隐藏维度 2,048，16 个查询头对 2 个键/值头，最大位置 262,144 个 token，词表大小 248,144。

• MiniCPM-V 4.7 1B——稠密的 qwen3_5_text主干，24 层、隐藏维度 1,024，8 个查询头对 2 个键/值头，相同的 262,144 token 上下文，词表 248,094，单个 3.1 GB safetensors 文件。

• 共享视觉塔——minicpmv4_7_vision，27 层，隐藏维度 1,152，patch 大小 14，图像大小 980，插入在文本堆栈的第 6 层。

• 压缩 — 混合 4 倍与 16 倍的视觉 token 下采样，其采用的 ViT 内部早期压缩技术被 OpenBMB 归功于 LLaVA-UHD v4；默认为 16 倍，而 4 倍则是更精细的细节设置。

• 注意力形状 — 两个变体中均呈现三比一的重复模式：每三个线性注意力层之后接一个全注意力层，在35B模型的40个文本层中重复十次。

• 许可证——两者均为 Apache-2.0，并在卡片前置信息中予以声明，这是这两个仓库首次就授权条款作出任何说明。

35B-A3B是公告中率先介绍的那个，也是工程实现上最有意思的那个：整个卖点在于，一个拥有350亿存储参数的稀疏MoE可以被做到在手机上流畅运行。

端侧这一主张才是真正的新颖之处，而这是一个调度问题

任何尝试在手机上运行 MoE 的人都知道这种故障模式。总参数存放在存储中，每个 token 只激活少数几个，而在没有足够 RAM 或带宽容纳所有专家的设备上，权重会被换入换出。结果就是解码速度慢到无法进行对话。显而易见的变通方法——将路由器锁定为整个提示词都使用固定的专家子集——虽然能提速，却会悄悄削弱能力，因为 token 再也无法触达模型原本会选择的专家。

OpenBMB 的答案是三项技术叠加在一起，而这张卡片对每一项技术的作用描述得异常具体：

• Lookahead Expert Scheduling (LES) — 一种跨层路由预测器会预加载下一层可能需要的专家，在真实路由器实际选中的专家之间确定优先级，并将其计算与其余仍需完成的工作负载重叠执行。说明文档特意指出：预测只用于驱动预取与调度；计算仍遵循模型自身的 token 级路由，预测未命中的专家也会照常加载并参与计算。

• 细粒度逐层量化 — 缩小专家权重的占用空间与内存流量，使加载模式适配设备端内存与带宽。

• DSpark 投机采样 — 将草稿模型路径集成到设备推理循环中，与调度和量化并列。

头条数字是：在 iPhone 17 Pro Max 上，35B-A3B 达到每秒 13+ tokens。这是厂商的测量结果，发生在我们尚未见过的设备上，使用的是我们尚未运行过的应用；它是本次发布中最值得暂且存疑、直到实验室之外有人复现为止的单个数字。它也是整个“首个能在设备端流畅运行且不牺牲性能的开源 MoE”这一说法所依赖的论据——而从定义上讲，这一说法很难被证伪，因为“不牺牲性能”是相对于厂商自行选择的基线来衡量的。

卡片中真正属于新信息的部分：生态系统列表

10月12日之前，根本没有公开发布的部署方案。现在，模型卡列出了该模型预期可搭配使用的框架，而且这份清单足够广泛，无论基准测试结果如何都很有用：

• 推理 — SGLang、vLLM、llama.cpp 和 Ollama，并提供 transformers serve 路径以支持 OpenAI 兼容的本地端点，以及面向 Intel CPU、GPU 和 NPU 的 OpenVINO 路径。

• 微调——SWIFT 和 LLaMA-Factory，外加一套 OpenBMB 称为 Self-Replay Fine-Tuning 的训练配方，定位为一种低成本扩展能力、同时限制遗忘的方法。

• 量化 — GGUF、BNB、AWQ、GPTQ 和 FP8，并为 35B 模型的 AWQ、GPTQ、int4、FP8 和 GGUF 变体分别发布了独立的代码仓库。

• 硬件 — 宣称对 Rockchip、Houmo、Intel、AMD 和 Arm 芯片平台提供首日支持，并支持 iOS、Android 和 HarmonyOS 部署。

• 工具——一本 cookbook，包含单图对话、多图对话、视频、OCR、PDF 解析和视觉定位的任务指南，还有一个存放手机应用的边缘部署仓库。

• 投机解码 — 为 35B 和 1B 目标分别提供独立的 DSpark 草稿检查点。

实际效果是，MiniCPM-V 4.7 从“你得自己写加载器”变成了“至少在四个推理服务栈中都有成文的路径”。如果你之前是在等这张卡到手后再花时间做本地试用，那这种等待已经结束了；但如果你是在等独立证据来证明端侧跑出的数字是真实的，那还没有。

这些基准测试能证明什么，不能证明什么

该模型卡的评测部分对其性质如实说明：由厂商报告，而非独立复现。其中明确提出了两项对比性说法，且二者均以对比形式陈述，而非绝对分数。在 Instruct 模式下，据称 35B-A3B 相比 Qwen3.6 35B-A3B，能以更少的推理时间达到更高的总体得分——这是关于性能与延迟的说法，而非原始质量的说法。据称，1B 变体改进了 MiniCPM-V 4.6 的核心能力，并在总体得分和推理效率两方面都大幅优于 Qwen3.5 0.8B。

以下是值得指出的一点。实际数字并不在文本中。评估部分由五张带链接的图片组成——35B 模型视觉语言任务的总体性能图、一张语言图、1B 图、一张性能-效率前沿图，以及一个设备端速度对比 GIF——而它们周围的文字承载的是叙述，而非数字。README 中没有逐项基准测试表，因此没有可供引用的机器可读分数， consequently 本文也就没有任何可作为数字引用的内容。“总体得分高于 Qwen3.6 35B-A3B”就是目前公开记录所能给出的最精确表述。

由此产生两个后果。首先，MiniCPM-V 4.7 没有出现在我们通常为进行经审计比较而参考的中立第三方排行榜上——没有推理指数，没有智能体指数，也没有独立评分的多模态得分。其次，OpenBMB 所绘制的汇总结果，是厂商自行在其选定基准组上合成的综合指标，这意味着“总体得分更高”这一说法有多大意义，取决于其背后的权重，而该权重同样未公开。这些都不代表这些数字是错的。它只是意味着这些数字未经审计，而这是另一回事；这种区别恰恰在数字最强的地方最为重要。

今天你可以自己验证的

剥去营销包装，剩下的是一个扎实、可核查的核心，所有这些都可以直接从代码仓库中读到，无需信任任何人：

• 权重字节数 — 35B 模型包含十六个 safetensors 分片，总计 70,425,903,448 字节，与 BF16 的 35.2B 检查点相符；而 1B 模型则是单个 3.1 GB 的文件。

• 架构 —— 上文的每一个结构性数字都记录在 config.json中，公开透明，并与卡片正文所述一致。

• 许可证——Apache-2.0，已在卡片前言中声明，现在明确无疑。对于商业用途而言，这是本次发布中最重要的一条信息，而且是新增的。

• 量化变体——AWQ、GPTQ、int4、FP8 和 GGUF 仓库均已存在且可下载，因此在权重层面，部署并非纸上谈兵。

• 采用信号——截至10月13日，这个35B仓库的下载量约为166次、点赞数为38，相比它作为一次未经说明的上传时的近乎为零的数字有所上升，但对于一个号称达到帕累托前沿的发布而言，这仍是一个很小的数字。

你无法验证的，是这次发布真正的卖点所在的那个说法：这是首个能在手机上运行、且不做出任何让步的开源 MoE，速度达到每秒 13 个 token 以上。而这还得等一位拿着 iPhone 和秒表的第三方来定论。

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

MiniCPM-V 4.7 并不由 OrcaRouter 提供服务。它是一个开放权重的检查点，这意味着模型本身需要你自己托管——无论是在工作站上、GPU 机器上，还是这张卡所瞄准的手机上。路由层真正发挥价值的地方，恰恰在这套安排的另一端：当自托管的视觉模型判断自己力有不逮、把棘手的画面交给更大的模型时，就是它派上用场的时候。OrcaRouter 用一个密钥接入 200 多个托管模型，以 0% 加价率原样传递各供应商的标价，因此厂商调价当天即可生效，并且当某家供应商服务降级时会自动故障转移——这正是混合方案所需要的形态：便宜的本地方模型处理常规工作，托管的模型承接它扛不住的请求。

接下来看什么

有三件事会让这次发布从一项有文档支撑的说法变成既定事实。对 35B 模型进行独立的设备端实测——由某个拥有 iPhone 17 Pro Max、已发布应用并能自行计时的人来做——将能确定整个宣传所依赖的那个数字。一张列出每项基准测试实际得分的表格，而不是图表，将能让 Pareto 宣称对照它所点名的基线得到核验。而在一个中立排行榜上运行一次，则会把 MiniCPM-V 4.7 与那些在并非由它选择的条件下接受评估的模型并列。在那之前，诚实的总结是：OpenBMB 发布了一个真实、采用 Apache-2.0、文档完善的模型，其效率叙事可信但尚未得到证实；而这两者之间的区别，正是规格卡与基准测试之间的区别。