MiniCPM-V 4.7 将 35B 视觉模型装进 3 GB：厘清 100 tok/s 的说法

一个 350 亿参数的模型不可能装进 3 GB 里。可 MiniCPM-V 4.7 35B-A3B 偏偏就跑在约 3 GB 之内，两句话又都是真的——这正是它的全部玄机所在，也是围绕这次发布流传的那些数字值得慢下来细看的原因。该模型是 OpenBMB 在 MiniCPM-V 系列中的首个稀疏混合专家（MoE）作品：存储参数 35.2 亿…… 准确说 352 亿个参数，每个 token 约激活 30 亿，Apache-2.0 许可，权重发布在 Hugging Face。它能读图像、多图集合与视频，以文本作答。自 10 月 10 日起，它还进入了上游 llama.cpp，多数人正是由此认识它的。下文将把大家反复念叨的三个数字——3 GB、35B 和 100 tok/s——拆开来看，并指明其中哪些是 OpenBMB 真正公布过的。200 多个托管模型，一个密钥，服务商标价按 0% 加价透传。看看 OrcaRouter 如何路由开放权重的检查点留在你自己的硬件上；托管这条逃生通道只是一个端点。像这次发布背后那些有据可查的 AI 故障与智能体事故，都收录在OrcaRouter AI 事故档案之中，每一条都附有自己的来源、严重程度、置信等级与争议标记。

3GB、350亿参数，且毫无矛盾

只有当你把“在内存中”理解为“全部都在内存中”时，这笔账才显得不可能。MiniCPM-V 4.7 35B-A3B 让约 30 亿参数常驻，其余专家则在路由器请求时流式加载进来——模型卡自己的说法是 Lookahead Expert Scheduling，这是一种跨层路由预测器，会预取下一层可能需要的专家，并将这一加载过程与已经在途的计算重叠起来。模型卡特意说明，预测只驱动预取和调度；token 仍然遵循模型的真实路由，而预测器漏掉的专家也会像任何其他专家一样被加载和评估。

这种区别有一个可衡量的后果。GGUF 仓库会以所有常见的量化格式发布整个模型，而这些文件没有一个是 3 GB 大小：

• Q4_K_M — 磁盘占用 21.2 GB。

• Q8_0 — 36.9 GB

• F16 — 69.4 GB。

视觉投影器 — 4 倍压缩下为 0.9 GB，f16 下为 1.1 GB。

所以，“3 GB”是手机上进行专家流式处理时的常驻内存数值，不是下载大小，也不是台式机的显存需求。如果你正在规划部署，决定磁盘占用和首次加载的是 Q4_K_M 下的 21.2 GB；决定手机稳态占用的是厂商给出的约 3 GB。这两个数字都在发布内容中。它们回答的是不同问题，而大多数报道把它们混为一谈了。

100 tok/s 来自哪里，又不来自哪里

有一点值得直说。OpenBMB 并未公布 MiniCPM-V 4.7 达到 100 tok/s 的数据。模型卡上的数字是：在 iPhone 17 Pro Max 上、内存占用约 3 GB 时，达到 13+ tokens/s。这是该发布中唯一的端侧吞吐量声明，而且是由厂商在实验室外无人复现过的硬件上测得的。

更高的数字确实存在，但它们来自另一个制品。OpenBMB 的 llama.cpp-omni 分支——承载端侧优化的仓库——为 35B-A3B 目标发布了自己的表格，并按启用了哪些优化项进行分层：

• iPhone 18 Pro Max，12 GB — 基线 3.38 tok/s，采用前瞻专家调度（Lookahead Expert Scheduling）后为 11.34，加入混合精度后为 17.16，再加上 DSpark 草稿头后为 20.51。

• iPad Pro 11 英寸 M4，16 GB — 基线 2.97 tok/s，使用 LES 时为 9.81，使用混合精度时为 14.92，使用 DSpark 时为 17.39。

这些是该模型已公布的最高端侧数据，而阶梯顶端是 20.51 tok/s——100 的五分之一。这一差距很重要，因为它改变了模型的用途。在 13 tok/s 下，手机应用能在几秒内回答一个关于照片的问题。达到 100 tok/s 时，你才会考虑把它用作视频的流式首轮读取器。前者是真实产品。后者并非实际交付的东西，任何按推文中的数字做预算的人都会因五倍的差距而失望。

对 100 tok/s 这一说法最诚实的解读是：它把三个彼此独立的事实——3 GB、可在本地运行、比上一代快出一大截——压缩成了一个任何来源都不包含的数字。代际提升真实且巨大：在同类设备上从 3.38 到 20.51 tok/s 是 6 倍提升，而这是通过叠加三项技术而非更大的芯片实现的。

这次发布不是一天的事，日期很重要。

MiniCPM-V 4.7 的亮相方式，和如今许多开放权重模型的发布如出一辙：文件先行，说明随后，而框架支持则介于两者之间。

• 10月6日 17:40 UTC — 1B 模型及其 AWQ、GPTQ 和 int4 变体出现在 Hugging Face 上，此外还有 18:05 的 GGUF 构建版本。

• 10月7日 07:07 UTC — 35B-A3B 仓库上线。仍无模型卡。

• 10月8日 — DSpark 面向两种规模的推测解码头，以及 35B 的 FP8 构建。

• 10月10日 18:42 UTC — llama.cpp 合并了对该模型的支持。

• 10月12日 —— OpenBMB 提交模型卡，声明采用 Apache-2.0 许可证，并宣布以有文档记录的产品形式发布该版本。

• 10月15日 — DSpark 各头已从主卡片链接，并附有两个目标的 GGUF 草案。

那个顺序解释了很多二手报道中的困惑。有人在十月的第二周通过 llama.cpp 接触到该模型，当时运行的还是一个官方尚不存在的版本，既没有许可证标签，也没有基准测试图表；他们的吞吐量数字反映的是该框架自身的量化选择，而不是 OpenBMB 基准测试过的任何结果。

llama.cpp 支持：已合并，但尚未完全完成

那个加入 MiniCPM-V 4.7 的上游拉取请求对改动内容的说明异常清楚，而答案是：架构上几乎没有任何变化。该模型与 MiniCPM-V 4.6 几乎完全相同；差异在于 3D RoPE，即每个 token 使用由时间、行、列三个值组成的位置，而不是大多数视觉语言模型采用的单一标量。支持方式是把现有的 4.6 路径扩展为携带这个额外维度。该 PR 在 9 月 25 日创建时还把该模型标为“即将推出”，这相当合理地暗示了当时权重开始流传得有多早。

在你基于它构建 grounding 功能之前，这个遗留问题值得了解。自那次合并以来，上游 llama.cpp 在 MiniCPM-V 4.7 的提示词中给图像标记 token 分配了错误的位置：图像 token 本身的位置是正确的，但 <slice>、</slice> 和行末标记却像普通文本一样被编号，而没有像参考实现 get_rope_index 那样被赋予对应的瓦片角坐标。可见的症状是：当你询问图片中某个东西在哪里时，返回的坐标会系统性地偏低。一个附带单元测试的修复已作为未合并的拉取请求存在，日期为 10 月 14 日；截至 10 月 20 日，它仍未合并。如果你的工作负载是“描述这个”，你不会察觉。如果是“给我边界框”，你就会察觉，并且你应该要么等待合并，要么使用包含修正路径的 fork。

还有一点在往返之后依然成立：对 1B 模型来说，视觉投影器才是更大的下载项。Q4_K_M 权重为 672 MB；f16 投影器为 1.11 GB。因此，最小的可用 1B 部署大约是 1.8 GB 的文件，其中大部分是“眼睛”而非语言——任何“1B 就意味着 1 GB”的预期都会在这个细节上出错。

运行什么，以及在什么上运行

如果目标是在本周试用，阻力最小的路径是使用 llama.cpp 或 Ollama 对接 GGUF 仓库，并将多模态客户端指向匹配的 mmproj 文件。在 24 GB GPU 上，21.2 GB 的 Q4_K_M 几乎没有为上下文留出余量——8K token 窗口加上图像分块无法舒适地容纳，所以如果你还想要长提示词，就计划使用 Q4_K_S 或更小的量化。在拥有 32 GB 或更多内存的 Mac 上，Q8_0 可行，并且是最接近参考行为的选择。在手机上，只有厂商自己的应用和 llama.cpp-omni 分支承担了专家调度工作；原版 llama.cpp 能给你正确性，但达不到 20 tok/s。

路由层在这里真正体现价值的地方，是在本地调用之外的远端。手机上的 3B 激活参数模型非常擅长处理日常场景——读这张收据、看看这货架是否有货、这个标牌写的是什么——但它偶尔也会遇到无法完成的页面。OrcaRouter 用一个密钥接入 200 多个托管模型，以 0% 加价透传每家供应商的标价，因此供应商调价当天即可生效，上游服务降级时还会自动故障转移。行之有效的模式是本地优先，并保留托管服务作为应急出口，而不是只做本地。开放权重检查点仍由你托管；手机交出去的一切都由路由器处理。

MiniCPM-V 4.7 并非由 OrcaRouter 提供服务，我们也不会暗示相反的情况。它是你自己运行的检查点。

怎样才能确定这三个数字

对 35B 模型在一款具名手机上进行独立测量，并明确说明所用应用和量化方式，才能解决吞吐量问题——包括 20.51 tok/s 在别人的秒表下是否依然成立。公布 3 GB 这一数字的定义——常驻集、峰值分配，还是别的什么——才能解决内存问题。而一张列出真实分数的逐项基准表，而不是该模型卡目前随附的五张链接图表，才能对照 OpenBMB 所选择的权重设置来检验“用更少时间优于 Qwen3.6 35B-A3B”这一说法。这些目前都还不存在。在它们出现之前，准确的说法就是那句乏味的：一个 35B 稀疏模型，在手机上以据称每秒 13 个以上 token 的速度运行、占用约 3 GB，下载量为 21 GB，并且其合并后的框架路径仍有一个未解决的坐标 bug。