MiniCPM-V 4.7 的“3B 活跃参数”并不在模型卡中——我从权重里测了出来

关于 MiniCPM-V 4.7 35B-A3B 被重复最多的那个数字，并没有印在它自己的任何文档里。这一说法——“只有 3B 激活参数（！）——它甚至能在 iPhone 上运行”——来自 2026 年 10 月 13 日的一篇第三方帖子，而厂商的模型卡、仓库 README 和发布说明都完全没有给出激活参数数字。与其说这是对该说法的批评，不如说这是一个值得填补的空白：检查点本身就编码了答案。所以，在这里开始任何其他事情之前，我拉取了 openbmb/MiniCPM-V-4.7-35B-A3B 的 safetensors 索引和每一个分片头文件并进行统计。作为对比，同一篇帖子中的另一个模型——2026 年 8 月 13 日发布的 Qwen3.8-27B——是稠密的 27B，没有这类需要解决的歧义：每个参数在每 token 上都是激活的。有趣的问题是，“3B 激活”能否在与权重接触后依然成立，而答案是：它成立，但前提是你按厂商的方式定义“激活”这个词；一旦把你无法避免运行的部分也算进去，诚实的数字更接近 4B。

从检查点本身读取的账本

索引文件列出了 40 个语言层，外加一个视觉塔和一个投影器，BF16 下总共有 35,212,875,824 个参数——需要下载 70.43 GB 的权重。这与名称中的“35B”相符。MoE 的问题在于，每个 token 会触及其中的多大比例：

• 总存储量 — 35.21B 参数，BF16 精度下为 70.43 GB。无论是否使用，每个专家都存储在磁盘上。

• 路由器预算 — 每个 MoE 层中，每个 token 从 256 个专家中选出 8 个专家。在 config.json 中配置为 num_experts_per_tok: 8。每个专家都很小：3.15M 个参数。

• 每层 MoE 路径 — 8 个专家（25.17M）+ 1 个共享专家（3.15M）+ 路由器门控（0.52M）≈ 28.83M。

• 每层的注意力路径 — 该架构是混合的：40 层中有 30 层使用线性注意力（每层 33.72M），10 层使用全注意力（每层 27.26M）。所有 40 层的注意力加上 MoE 算术总计 ≈ 2.44B，每个 token 重复。

• 再加上你无法跳过的部分——token embeddings 508.2M、LM head 508.2M、vision tower 522.3M、projector 30.7M。

• 两个站得住脚的答案——仅注意力与MoE路径上的活跃参数就约为24.4亿；如果把嵌入、输出头、视觉塔和投影器也算进去（视觉请求确实会用到这些），则约为40.1亿。

所以，“3B active”并没有错。它是对 2.44B 向上取整的结果，并且落在上面两个数字之间的空档里。只是它不是 OpenBMB 公布的数字，也与“A3B”后缀不是一回事——这个后缀是模型名称的一部分，厂商自己的资料从未把它变成一项测量指标。

为什么后缀和数字不是同一回事

开放权重生态中的命名惯例暗示了激活参数量：名为 30B-A3B 或 235B-A22B 的模型是在告诉你，它每个 token 大约激活那么多参数。这种暗示通常是可靠的——但这只是一种惯例，并非契约；而 MiniCPM-V 4.7 就是这样一个案例：模型卡、README 或发布帖中，没有任何内容把“A3B”转换成一个你可以据此规划内存的数字。在有人实际数过之前，这个后缀只是一个标签。

上面的计数是算术，而不是从那个标签推断出来的。这也是~2.44B和~4.01B这两个数字存在差异的原因：是否把嵌入表和输出头算进去是一个真实的决定，而不是吹毛求疵。在稠密模型中，嵌入只占27B预算的一小部分。在稀疏模型中，每个token的计算路径只有几十亿参数，一个508M的嵌入表和一个508M的LM head就不再是噪声了——它们合计约占活跃路径的五分之一，而且它们以全宽度存储，而专家则被量化。

有一点值得直说：按狭义解读，这里的存储参数与激活参数之比约为 8.8 比 1。这正是 35B 模型可以被宣传为手机端模型的原因，也正是它并不像 3B 稠密模型那样算得上手机端模型的原因。当路由器忽略某个专家时，存储并不会缩小。

iPhone 的主张是一项单独的主张，有单独的证据基础

本次发布中所有关于端侧性能的具体内容均为厂商自报，未经复现。具体数字是在 iPhone 17 Pro Max 上约 3 GB 内存下达到每秒 13+ 个 token，同一检查点也在 iPad M4 上做了演示。OpenBMB 将其归因于三项协同工作的技术——Lookahead Expert Scheduling（预测跨层路由并预取专家）、细粒度逐层量化，以及 DSpark 投机采样——并将该成果描述为首个能在端侧流畅运行且不损失能力的开源 MoE 模型。公开记录中没有任何对该吞吐量的独立测量，没有第三方复现，也没有公布 3 GB 这一数字所假设的是哪种量化。

这件事之所以重要，有一个具体原因：3 GB 这个数字决定了那种说法对你是否有价值，而它恰恰是我们了解得最少的数字。一个 35B MoE，其专家权重大多存放在闪存上，它并不是一个 3 GB 模型，而是一个在路由预测、预取和量化专家缓存都各司其职时，常驻工作集恰好能装进 3 GB 的模型。这些正是基准测试吞吐量与真实场景吞吐量出现分化的条件——首个提示会预热缓存，而那种能在演示中让你达到每秒 13 个 token 的表现，是一种调度安排，而不是权重本身的属性。

把每秒 13 tokens 视为一项关于技术的说法，而不是关于该 checkpoint 的说法。checkpoint 才是你今天可以验证的东西：存储 35.21B，每个 token 从 256 个专家中路由 8 个，根据你的计算方式，活跃参数约为 2.44B 到 ~4.01B，Apache-2.0，GGUF、AWQ、GPTQ、int4 和 FP8 的 day-0 量化，以及一份支持的芯片厂商名单，包括 Rockchip、Houmo、Intel、AMD 和 Arm。

活跃计数决定什么和不决定什么

活跃参数量是一个算力代理指标。它告诉你每个 token 会发生多少矩阵乘法，而这对应着受 GPU 制约的解码跑得有多快。它并不会告诉你需要多少内存来容纳模型——这由总参数量决定：70.43 GB 的 BF16 权重，4-bit 下约为这个数字的四分之一，而这还没把 KV cache 算进去。在 256K 上下文的模型上，那份缓存也绝不是可以忽略不计的零头。

• 解码速度——由激活参数量决定（此处约为 2.44B–4.01B）。13 tokens/s 这一说法说的就是这个。

• 常驻内存——由总参数量（存储量为 35.21B）决定，随后因量化以及任何保持常驻的专家集合而减少。

• 存储与加载 —— 由 BF16 下完整的 70.43 GB 决定。稀疏路由并不会减少下载量。

• 是带宽，而非浮点运算——在手机上，约束瓶颈在于如何让专家通过内存总线，这正是调度技术存在的原因，也是仅凭活跃数量无法预测移动端延迟的原因。

实际意义在于：如果你的 GPU 显存足以装下量化后的权重，那么激活参数量才决定你的吞吐量，"3B active" 是件好事。如果你是那个让"能在 iPhone 上跑"这句话出现在帖子里的人，那么总参数量才是决定可行性的数字，而厂商在调度上做的工作，正是让这个总参数量变得可堪一用的关键。对同一个标题的这两种解读都成立，但它们并不是同一种解读。

那个帖子里的对比需要两个标签，而不是一个。

这次流传开的叙事框架是本地与昂贵硬件之争：MiniCPM-V 4.7 35B-A3B 是无需整套设备就能获得同等能力的模型，而 Qwen3.8-27B 是更聪明但需要整套设备的模型。其中关于能力的那一半来自 Qwen 自己的模型卡，并且和本页其他所有内容一样，属于厂商报告。Qwen 公布的 Qwen3.8-27B 数据包括 LiveCodeBench v6 上的 90.3、GPQA Diamond 上的 89.2、OSWorld-Verified 上的 84.3 以及 QwenSWEBench 上的 79.0，而我们自己的目录条目指出，对于 27B 稠密模型来说，这些是异常强大的智能体与编码结果。它是否“比 Opus 4.6 更聪明”是那条社交帖子中的说法，我手头没有能定论的独立评估——所以我不会把它当作事实再复述一遍。

真正可核查的是结构上的差异：Qwen3.8-27B 是稠密模型，因此其 27B 参数全部激活，内存占用和计算开销是同一个数。MiniCPM-V 4.7 35B-A3B 则把这两个数字拉开了大约九倍。这就是整个架构层面的论点，而且它是真实的。只是它并不等同于基准测试比较，而让它出名的那个帖子把两者混为一谈了。

路由器在何处改变决策，又在何处不改变

这里有两件事都是真的，且值得区分开来，因为它们指向相反的方向。

首先，我们不提供 MiniCPM-V 4.7 的服务。它不在我们的目录中。如果你想要它，路径就是你自己的硬件——这正是本次发布的设计目标，随其一同发布的还有权重、量化以及端侧部署指南。托管式 API 对于在手机上运行模型毫无帮助，若暗示并非如此，则会产生误导。

第二点是，用来衡量这个模型的对照模型并不处于那个位置。Qwen3.8-27B 可通过我们的 API 获取，自主托管在我们自己的基础设施上，价格为每百万输入 token 0.33 美元、每百万输出 token 2.40 美元。如果你真正想问的是“我是否该用本地部署的 MiniCPM-V 4.7 取代我托管的 Qwen3.8-27B 调用”，那么诚实的回答是：在投入之前，你应该先做实验：端侧吞吐量数据尚未被复现，而能力对比用的是对方自己的模型卡。这正是故障转移存在的意义——把一小部分流量路由到新路径，让已被验证的路径留在后面兜底，这样糟糕的一周只会让你损失一小部分工作负载，而不是整个工作负载。0% 加价模式也让这笔账保持诚实：当供应商调整价格时，你支付的数字当天就会变动，因为他们的标价与你的账单之间没有任何利润层.

路由器做不到的，是让"本地部署还是托管"这个问题消失。这个问题由你的硬件、你的隐私约束，以及 70 GB 的下载量能否接受所决定——而活跃参数的数量，无论你怎么取整，都改变不了这三者中的任何一个。

什么能了结它

三件事，按有用程度从高到低排列。一个由 OpenBMB 发布的激活参数量数字，这样人人反复引用的那个数字就不再是第三方的算术——包括我给出的，如果你不认同它，我的数字可以从分片头信息复现。对手机上每秒 13 个 token 的独立测量，并说明量化设置，因为一个依赖调度配置的数字若不给出其设置，就不成其为规格。以及一次真正的评估，在相同任务上比较 MiniCPM-V 4.7 35B-A3B 与 Qwen3.8-27B，因为让这个模型备受关注的那项对比，目前不过是一家厂商的图表对另一家厂商的参数卡。

在那之前，稳妥的概括范围比那篇文章更窄：权重是真的，稀疏性是真的，下载量是 70.43 GB，而且每个 token，模型完成的工作量在 24 亿到 40 亿参数的等效计算量之间，具体取决于你如何计算那些无法绕开路由的部分。这是一个真正的工程成果。它还不是经过实测的手机基准测试，也不是对稠密 27B 的基准测试胜出。

来源：参数、专家数量、层类型、上下文长度和下载大小均直接读取自 openbmb/MiniCPM-V-4.7-35B-A3B 在 2026年10月13日的 config.json 和 safetensors 分片头。设备端速度、内存数值、基准测试结果以及 Qwen3.8-27B 的评估数值均由厂商报告，未经复现。“3B active parameters”和“比 Opus 4.6 更聪明”的说法源自第三方社交帖子，而非来自任一厂商。

这些都不是假设：像这样一个数字所引用的那些有据可查的 AI 故障和 AI 智能体事件，都汇集在OrcaRouter AI Incident Archive中，其中每一条记录都附有自己的来源、严重程度、置信度等级和争议标记。