面壁智能开源 MiniCPM-V 4.7：35B-A3B 端侧 3GB 内存跑 13+ token/s，官方称首个端侧无损开源 MoE

面壁智能联合清华大学自然语言处理实验室与 OpenBMB 开源社区，发布并开源了端侧多模态大模型 MiniCPM-V 4.7，一次给出 35B-A3B 与 1B 两个规格。35B-A3B 是 MiniCPM-V 系列第一个 MoE 模型：官方口径为总参数 350 亿、单次推理只激活约 30 亿。

这里有一个必须先交代的时间差。GitHub 官方仓库的更新记录写的是 2026-10-12，而华尔街见闻与北京市科委中关村管委会的报道口径都是 10 月 13 日发布。两个日期相差一天，本文并列呈现，不替官方选一个。10 月 15 日官方又追加了两档尺寸的 DSpark 投机采样头（BF16 与 GGUF 各一版）。

最抓人的数字是端侧：官方称在 iPhone 17 Pro Max 上，35B-A3B 仅占用约 3GB 运行内存，就能跑到 13+ token/s 的解码速度。北京市科委的盘点写的是 15+ token/s，华尔街见闻写的是「在 iPad Pro 上 15 个以上 Token/s」——同一件事出现两个数字，说明测试设备与量化配置并不统一，引用时应当带上出处而不是取最好看的那个。

另一处容易被误读的地方，华尔街见闻说得很清楚：约 3GB 是特定部署方案下的运行内存占用，不代表 350 亿参数的完整模型只需要 3GB 存储空间。这个区分写进合同和选型文档里都很重要。

MoE 在端侧的真正难点不是「能不能跑」，而是「跑起来还保不保留能力」。总参 350 亿、激活 30 亿，算力侧不难；难在每一层该叫哪几位专家要等上一层算完才知道，而手机内存装不下全部专家权重，只能放闪存按需读入。按需读得慢，预先固定一小组专家又会让模型失去原本会选的专家、掉能力。

官方的解法是自研 LES（前瞻专家调度）：利用相邻层输入特征高度相似的特点，在当前层还没算完时把路由输入送进下一层的路由器，提前预测并预取下一层可能用到的专家权重，同时调整计算顺序——已加载且在路由结果里的专家先算，其余并行加载。官方强调预测只用于预取与调度，最终每个 token 用哪些专家仍由模型原有路由决定，没猜中的专家照常加载参与计算，所以是「无损」而不是「剪枝」。量子位转述的技术细节是：该方案可提前备好超过 80% 的所需专家，且无需额外训练。

第二件是精细的层级量化加上权重存储布局重排：把专家权重压小、排成连续存储，减少零散读取，让闪存尽量顺序读。第三件是 DSpark 投机采样，草稿模型先提若干 token，主模型批量核验。三件事叠起来，官方称在端侧带来约 x5 的真实加速；量子位给出的实测环境是 16GB 内存的 iPad Pro M4 提升约 x5，16GB 内存的 M5 Mac 上 DSpark 平均再提 17%。

视觉侧也在省。4.7 沿用 LLaVA-UHD v4 的 ViT 内提前压缩，在视觉编码器内部就合并视觉 token，并开放 4 倍/16 倍混合压缩率切换——官方给出的取舍数据是，开到 16 倍时 MMBench 只从 91.72 掉到 90.87、OCRBench 从 91.20 掉到 90.40，几乎没拿精度换算力。这批数字同样属于官方口径，百器AI 未复现。

官方公布的 35B-A3B（Instruct 模式）成绩，经量子位转述为：MMBench 91.72、MMStar 80.67、MMMU 80.22、MathVista 88.00、Video-MME 76.40、LongVideoBench 68.90、OmniDocBench v1.6 94.24；纯文本侧 CMMLU 90.21、τ2-Bench 84.65。官方在文档里给出的结论性表述是：以更短推理时间取得比 Qwen3.6 35B-A3B 更高的综合得分，1B 版本在综合得分与推理效率上均显著领先 Qwen3.5 0.8B。

文档解析是这批数字里差距最大的一项：OmniDocBench v1.6 上 35B-A3B 拿到 94.24，官方对比图里另外四个模型都在 80 分上下，领先 12 分以上。对做票据、报表、PDF 转写这类活的人来说，这比 MMBench 的一个点更有参考价值。

但证据边界也要说清楚：官方基准是以图片形式发布的对比图，没有提供可复现的评测脚本、prompt 模板、few-shot 设置与推理配置。第三方要复现只能照着重做一遍实验，这不构成「可复现的公开基准」。本文所有分数都标注为官方口径，百器AI 未做任何跑分复现。

还有一个细节值得注意：官方文档没有给出 4.7 的技术报告或 arXiv 编号（4.5 与 o 4.5 都有），训练数据规模、训练 token 数也未披露。这意味着这批分数的来源链路只有「官方图表 → 媒体转述」两级，没有论文可供交叉核对。

把三代放在一条线上看，4.7 的变化不是「又大了一点」，而是换了打法。MiniCPM-V 4.5（2025 年，技术报告 arXiv:2509.18154）是这一代端侧多模态能力的基线；4.6（2026-05-11 发布，证券时报 5 月 13 日报道）走的是极致小尺寸路线，以 1.3B 参数、约 6GB 内存实现端侧流畅运行；4.7 保留了 1B 档（实际参数 1.3B，量子位口径）继续做同尺寸迭代，同时新增 35B-A3B 这个此前系列里没有的大尺寸 MoE 档，把「能力上限」抬到了端侧。

所以 4.7 与前代最实质的差异有三条：一是首次引入 MoE 与 35B 档，端侧可承载的参数规模上一个数量级；二是首次把 LES 这套「端侧 MoE 无损推理」工程方案与模型一起开源；三是量化矩阵补齐了 FP8，量化版本覆盖 BF16/FP8/int4/BNB/AWQ/GPTQ/GGUF。需要注意的是，4.5 的参数规模本次未核实，本文不做跨代参数的直接比较。

协议是这批信息里最干净的一条：官方仓库与资料页写明「本仓库中的模型权重和代码依照 Apache-2.0 协议开源」，Hugging Face 模型卡上的 License 字段同样是 apache-2.0。代码与权重同协议、无附加商用限制条款，对二次开发和商业集成是友好的。当然，Apache-2.0 不构成对模型输出内容合规性的担保，实际落地仍需自行做内容安全与数据合规评估。

端侧条件也算清楚了：系统层面支持 iOS、Android、鸿蒙，首日适配瑞芯微、后摩、Intel、AMD、Arm 芯片平台并提供开源端侧适配代码（Intel 侧另有 OpenVINO 首日支持）；服务端可走 SGLang、vLLM、llama.cpp、Ollama，微调支持 SWIFT、LLaMA-Factory；官方另开源了 SRFT（自回放微调），思路是先用模型自己回答一批覆盖原有能力的问题、筛出高质量回答混进新任务训练数据，用来自我「复习」，降低定制后的能力遗忘。

给选型者的实话：这套东西的价值在于「同一个模型既能在云上跑、也能塞进手机」，适合做端云同构的产品架构；但「13+ token/s」是官方在特定设备、特定量化配置下的数字，你的机型、你的上下文长度、你的多图和视频负载都会让结果偏离。等你自己在目标机型上跑过一轮再定，别拿发布会数字做容量规划。