一座体素宝塔、减少 10% 的 Token，以及 OpenBMB 真正为之背书的那一句话

本周关于 MiniCPM-V 4.7 35B-A3B 被引用最多的一句话并不在它的模型卡里。它是一条推文，发布于 2026 年 10 月 13 日，内容写道：“MiniCPM-V 4.7 35B-A3B 不仅用了更少的 token，还生成了比 Qwen 3.6 35B-A3 更好的体素宝塔。”它所指的演示是一段视频：两个语言模型各自编写一座 3D 体素日式宝塔的代码，并排渲染出来。这确实是一件很有意思的作品——它展示了一个视觉语言模型根据图像提示，用三维方式复现一座已建成的建筑，这比给图像写说明要难得多。但有必要把这条推文是什么、不是什么区分开来，因为三种不同的说法被揉进了同一句话里，而它们背后的证据强度各不相同。MiniCPM-V 4.7 35B-A3B 是 OpenBMB 发布的真实权重文件，问世大约一周；Qwen3.6-35B-A3B 则是一个已有九个月历史的开源权重对手，同样是 Apache-2.0 许可，同样是标称规模相同的稀疏混合专家模型。下面要谈的，是围绕这两者的一系列效率说法中，哪些是可核查的，哪些不过是一张图表的 JPEG 截图。

一句话里藏着三个主张

这条推文捆绑了三件可分开来看的事情，而它们值得被分开来看，因为其中只有一件是有据可查的。

• “使用的 token 更少”——这是一个关于单个任务 token 消耗量的可衡量陈述。与演示一同流传的数字是：比 Qwen3.6 35B-A3B 少 10% 的 token。该数字来自开展这项对比的第三方创作者，而非 OpenBMB 的评测，并且它只是单个提示词对，而非基准测试。

• “生成了一个更好的体素宝塔”——这是一种判断，源于对两座渲染出的宝塔的观察。没有评分细则，没有评分工具，也没有独立第三方。这是那种人类三秒钟就能做出、而基准测试根本无法做出的断言，因为“更好的宝塔”没有真值。

“效率加质量才是真正的战场”——这部分是一个论点，而且恰好是 OpenBMB 在模型卡中确实以书面形式、附上数字所论证的那个论点。只是它并不是那句流传开来的话。

这一点很重要，因为前两种说法令人难忘，而第三种才是站得住脚的那个。如果你正在决定是否要花 70 GB 的下载量去下载一个检查点，你需要的是第三种。

OpenBMB 究竟写了什么，以及何时写的

先说时间线，因为它已被转述压缩了。权重是悄然上线的：openbmb/MiniCPM-V-4.7-1B创建于 2026 年 10 月 6 日 17:40 UTC，openbmb/MiniCPM-V-4.7-35B-A3B则于 10 月 7 日 07:07 UTC 创建。当时两者都没有模型卡、许可证标签或基准测试——本刊当时对此进行了报道，而对于一次 350 亿参数的上传，这种状况颇为反常。六天后，即 2026 年 10 月 12 日，OpenBMB 一口气提交了全套文档：模型卡、Apache-2.0 许可证、评估图表、以新系列开篇的重写版仓库 README，以及一份公告。那天参数没有变，变的是解释。

诚实的说法不是“MiniCPM-V 4.7 35B-A3B 本周发布了”，而是“MiniCPM-V 4.7 35B-A3B 本周才变得可查证”。关于它，如今所有可供引用的内容，要么是在 6 日和 7 日上传的，却没有任何文档说明；要么是在 12 日写下的，且属于厂商的一家之言。

模型卡确实提出的主张

以下是卡片上的原句，逐字引用，且比推文范围更窄：在 Instruct 模式下，35B-A3B 变体“在比 Qwen3.6 35B-A3B 更少的推理时间内取得了更高的总体得分”。仅此而已。没有 token 数量，没有领先幅度，也没有以文字形式给出的逐基准拆解。其背后的证据是一张散点图——纵轴为平均评测得分，横轴为以对数刻度表示的推理时间（秒）——图中 MiniCPM-V 4.7 35B-A3B 位于 Qwen3.6-35B-A3B 的左上方。图表自身的脚注将平均值定义为五项基准的均值：MMStar、MMMU-Pro、CharXiv reasoning、BLINK 和 MathVista。圆形表示 Instruct 模式，菱形表示 Thinking 模式。

这是一个关于二维权衡的真实而具体的说法，也是该发布内容中最有力的部分。同样值得注意的是，这张图无法告诉你什么：绘制的数据点上没有数值标签，因此你无法读出分数或时间，只能看出一个方向。按图中所画，这个方向同时在两个轴上都偏向 MiniCPM。

而且它是由厂商自己测的。这张模型卡的评测数据带有这样一行说明：“结果来自公开报告，以及我们使用官方检查点进行的本地评测。”本地评测意味着 OpenBMB 的硬件、OpenBMB 的测试框架、OpenBMB 的模式选择。对模型卡来说，这么做很正常；把它洗白成事实，就不正常了。没有任何独立第三方用同一套测试框架跑过这两个检查点。没有任何榜单收录过其中任何一项结果。截至本文写作时，这一说法只有一个来源，而这个来源正是卖这个模型的人。

token 效率本应来自哪里

效率论点并不建立在基准测试图表之上，而是建立在三项工程选择之上，而这些选择值得深入了解，因为它们决定了这种优势能否转移到你的硬件上。

• 前瞻专家调度（LES）——核心亮点技术。稀疏混合专家模型存储的参数远多于每个 token 所激活的参数，而在无法将所有专家都驻留在内存中的设备上，权重会被反复换入换出，导致解码停滞。LES 利用跨层路由预测来预加载下一层可能需要的专家，并优先计算真实路由器实际选中、且恰好已加载的专家。OpenBMB 特别说明，该预测仅用于驱动预取和调度；模型的 token 级路由保持不变，预测器漏掉的专家仍会被加载并计算。模型卡声称，由此可在真实设备上实现 5× 加速，且能力无损。

• 细粒度逐层量化——缩小专家权重的占用空间和内存流量，这是让端侧加载模式得以适配的另一半。

• DSpark 投机采样——一条配对的草稿模型路径，已另行发布为 openbmb/MiniCPM-V-4.7-35B-A3B-DSpark，并与调度和量化工作一同集成。

叠加起来，这些便产生了本次发布的主打数字：在 iPhone 17 Pro Max 上使用约 3 GB 内存，每秒超过 13 个 token。这是一个厂商给出的数字——在厂商硬件上、用厂商软件跑出来的，而且这款应用由 OpenBMB 编写。这类说法要么就是产品的全部，要么什么都不是；而目前公司外部的人无从核实，因为复现它需要手机演示所运行的那套设备端技术栈。

Token 效率确实存在，但在这里它是一个矩阵，而不是一个标量

这次发布中有一个细节，在每一份关于它的摘要里都被抹平了，而它恰恰是真正决定代币经济学的那个细节。

MiniCPM-V 4.7 35B-A3B 支持 4x 与 16x 混合视觉 token 压缩，可按请求选择。16x 设置会合并视觉 token 以提升速度；4x 则保留四倍的视觉 token，以保留细节。该模型卡的默认设置为 16x，且该参数必须同时传给聊天模板和 generate 调用，否则占位符数量与视觉编码器会不一致。

• 供应商自己的视觉语言对比表记录了每个模型所在行所用的压缩设置。在该表中，MiniCPM-V 4.7 35B-A3B 行处于 4x——即保留细节的设置，也就是代价高昂的那个——而 Qwen3.6 35B-A3B 行处于 16x。一个 31B 的 Gemma 4 行列在 9x；两个 27B 的 Qwen 行则在 4x。

• 脚注明确指出，MiniCPM-V 4.7 支持任一设置，而表中的其他模型仅支持固定的压缩比。

把这些放在一起读，情况就变了。如果 MiniCPM 那一行是在耗 token 的设置下取得其视觉语言分数，而 Qwen 那一行是在省 token 的设置下取得分数，那么这两列比较的就是不同数量的视觉细节，而效率叙事就不是“相同输入，更少 token”——而是“可调输入，而这一列在质量上胜出”。这比推文中的说法更有趣，也更诚实，而 OpenBMB 把它放在脚注里，而不是以此作为主要宣传。

这也意味着，你真正在意的那个数字——每单位视觉细节对应的 token 数——根本无法从这张表中读出。它需要以相同设置运行两个模型，而这一点没有人公布过。

该表格，附带注意事项

这张卡附带两张厂商表格，一张用于视觉语言，一张用于语言；两者均处于 Instruct 模式，且都与一个包含两款 35B-A3B 级 Qwen 模型、一款 31B Gemma 和两款 27B Qwen 的模型组进行对比。下面的数字是从厂商自己的 PNG 图表中读出的，而需要说明的局限是结构性的：这些数字仅以像素形式存在于该图表中，而不是以表格形式存在，因此以下内容是通过机器读取提取的，可能存在少量转录错误。

• OCRBench — MiniCPM-V 4.7 35B-A3B 为 91.20，对比 Qwen3.6 35B-A3B 的 90.40。差距为 0.8 个百分点，且是在厂商自家的运行结果上。

• OmniDocBench v1.6 — MiniCPM 约为 98.2，而 Qwen 模型约为 93.3，这是表中最大的单项差距，也是如果能复现的话影响最大的一项，因为文档解析通常是消耗 token 预算的环节。

• MMMU — 大约 80.2 对 80.0，在图表图像的分辨率下可谓不分伯仲。

• MMMU-Pro — 约为 69.7，对比 67.7；而在同一行中，27B Qwen 比这两者都高。

• 语言表——形状相同，但在指令遵循和代码方面的数据格更引人注目。IFBench 列出的约为 47.7 对 35.3，LiveCodeBench-v6 约为 97.0 对 54.3。这两个差距足够大，因此在其他人运行它们之前，它们应被视为本次发布中最不可信的数据：在一个代码基准上，两个规模相近的开源 MoE 模型之间出现 43 个百分点的差距，却由两方中的一方测量，这种说法需要第二个测量工具。

厂商自报、厂商自测、未经复现。这就是全部。如果这些数字能在独立测试框架下站得住脚，帕累托前沿的说法就成立，宝塔视频不过是个脚注。如果站不住脚，那就只有宝塔视频了。

采用数据所说明的，与质量毫无关系

在这个比较中，有一个数字无人质疑，而且它并不是基准测试。Hugging Face 下载计数器在 2026 年 10 月 13 日读取时显示 630，即 openbmb/MiniCPM-V-4.7-35B-A3B而大约 360 万，即 Qwen/Qwen3.6-35B-A3B——这个仓库创建于 2026 年 4 月 15 日，因此在采用曲线上大约领先九个月。这个差距衡量的是时间，而不是优劣，这也正是这里会提出效率问题的原因：新来者必须在每个 token 的基础上进行论证，正因为它还没有九个月的时间来走完采用曲线。

列表中还有一处值得指出的轻微内部矛盾。该仓库带有从同系列其他模型继承来的“设备端模型”标签，而一个拥有 352 亿参数、以 70.4 GB BF16 权重表示的稀疏 MoE，在任何下载者会认可的意义上都不是设备端模型。设备端的故事是真实的，但它依托于检查点之上的量化和专家流式传输，而不是检查点本身。做预算时应对照量化构建版和应用，而不是对照这个标签。

这周对此该怎么办

实际立场狭窄而明确。如果你想验证效率方面的说法，目前还没有什么可验证的——那只是一家厂商的图表，而唯一附带了每任务数字的那个数（少 10% 的 token，一个 pagoda）来自第三方的单次演示。如果你想运行这个模型，权重是 Apache-2.0，架构有文档，下采样设置由你选择，这是一个真实存在且被低估的杠杆：吞吐量重要时用 16x，当图表向你展示的是一份文档时用 4x。

这个对比中的一半如今可以通过托管 API 访问，另一半则不能，而值得把哪一半是哪一半说清楚。qwen/qwen3.6-35b-a3b是 OrcaRouter 上的一个托管模型——它就摆在目录里，一把密钥即可调用，按 Qwen 自家的标价计费，不额外加价，会调度到当时健康的供应商，而不是你锁定的那一家。MiniCPM-V 4.7 并非由我们托管；它是一个开放权重的检查点，需要你自己部署。这种不对称恰恰是这里的有用之处。你今天下午就能把这个对比里 Qwen 这一侧纳入基线，拿 OpenBMB 的评测工具在你自己的数据上对它跑一遍，让厂商的图表成为假设，而不是答案。

而鉴于整场争论的核心本就是你的硬件上的效率，这注定是唯一能一锤定音的衡量指标。