MiniCPM-V 4.7杀入手机端：35B-A3B MoE模型只吃3GB内存

面壁智能今天（10月13日）发布新一代端侧多模态大模型 MiniCPM-V 4.7，核心看点不是又多了一个视觉问答模型，而是它把一个总参数量 35B、激活参数量 3B 的 MoE 模型，推进到了手机端运行的现实区间。

官方给出的数据是：MiniCPM-V 4.7-35B-A3B 在 iPhone 17 Pro Max 上运行时，内存占用约 3GB，解码速度超过 13 token/s。模型同时提供 1B 版本，支持 iOS、Android 和鸿蒙，并适配 Intel、AMD、Arm、瑞芯微、后摩等处理器平台。

这次更新，重点不是“参数变大”

MoE 是一种只激活部分专家参数的模型架构。 MiniCPM-V 4.7-35B-A3B 的“35B”代表模型总参数量约 350 亿，“A3B”代表每次推理实际激活约 30 亿参数，因此它的计算成本更接近 3B 级模型，而不是传统稠密 35B 模型。

这也是 4.7 最值得关注的变化：MiniCPM-V 系列首次采用 MoE 架构，并且面向端侧部署做了专门优化。传统稠密模型像是一家只有一个超大团队的公司，每次请求都要让大量员工一起处理；MoE 更像是拥有多个专家组的组织，面对 OCR、图像理解、数学推理等不同任务时，只调度其中一部分专家。

但 MoE 并不等于“35B 模型变成了 3B 模型”。模型权重仍然需要以某种形式存储，推理过程中也存在专家路由、内存访问和算子调度成本。它真正降低的是每个 token 的计算量，而不是简单地把模型文件缩小到 3B 级别。因此，官方宣称的 3GB 内存表现，更多说明 MiniCPM-V 4.7 在权重压缩、运行时调度和芯片适配上做了系统性优化。

LES解决的是端侧MoE最难的调度问题

LES（Lookahead Expert Scheduling，前瞻专家调度）是一种提前预测并安排后续专家计算的推理加速技术。 面壁智能表示，MiniCPM-V 4.7 基于 LES 技术提升端侧推理效率，目标是减少 MoE 模型在移动设备上的专家切换和等待时间。

MoE 模型部署到服务器上时，可以依靠更大的显存带宽和并行硬件隐藏一部分调度开销；手机则完全不同。移动芯片的算力、内存带宽和缓存都更有限，模型每生成一个 token，若频繁切换专家，就可能出现“算力够用，但数据搬不动”的情况。此时，理论上的 3B 激活参数并不能自动转化为流畅体验。

LES 的思路可以理解为“提前准备下一批要用的专家”。系统根据当前 token、上下文和路由结果，预判后续计算路径，将需要的参数或算子提前安排到更合适的缓存和计算单元中。它未必改变模型本身的能力，但能减少推理链路中的空等时间。

需要注意的是，目前公开信息主要披露了 LES 的定位和最终速度，没有给出完整的调度算法论文、端到端延迟拆解、不同芯片上的吞吐对比，也没有说明 13+ token/s 是在何种输入分辨率、上下文长度、量化精度和并发条件下测得。因此，这个数字很有吸引力，但开发者在复现时不能直接把它当作所有手机上的通用性能。

13+ token/s意味着什么

13+ token/s 是指模型每秒生成超过 13 个文本 token 的解码速度。 对视觉问答、截图分析、文档识别这类交互任务来说，这已经接近“边生成边显示”的可用体验，而不是只能等待数十秒的离线演示。

以手机端拍照问答为例，用户上传一张发票、菜单或设备面板照片后，模型需要先处理视觉输入，再生成解释。如果纯文本解码速度只有 2～3 token/s，回答过程会明显拖沓；达到 13 token/s 后，短回答通常可以在几秒内完成，长回答也能连续输出，交互感会更接近云端助手。

不过，token/s 只覆盖解码阶段，不等于完整响应延迟。端侧多模态应用还包括图像预处理、视觉编码器计算、模型加载、首 token 延迟和内存搬运。真正影响用户体验的指标至少包括：

• 首 token 延迟： 用户点击发送后多久开始出现文字；
• 图像编码耗时： 高分辨率图片进入语言模型前需要经过视觉编码；
• 持续解码速度： 生成过程是否稳定，是否会因专家切换出现抖动；
• 峰值内存： 包括模型权重、KV Cache、视觉特征和运行时缓存；
• 长上下文表现： 输入多页文档或多张图片时，速度是否明显下降。

因此，MiniCPM-V 4.7 的 13+ token/s 是一个重要的端侧解码指标，但还不能单独代表完整应用的响应速度。对于开发者而言，后续更值得关注的是官方是否公布统一测试脚本、输入规格和不同芯片的首 token 延迟。

与前代和同尺寸模型怎么比

MiniCPM-V 4.7提供了“35B-A3B大模型规格”和“1B轻量规格”两条产品路线。 前者强调在端侧获得更强的视觉理解能力，后者则强调更低的部署门槛和更广的设备覆盖。

官方表示，35B-A3B 版本在 Instruct 模式下，以更短的推理时间取得了高于 Qwen3.6 35B-A3B 的综合得分；1B 版本相比 MiniCPM-V 4.6 继续提升基础能力，并在综合得分和推理效率上显著领先 Qwen3.5 0.8B。

这里需要把“综合得分更高”和“推理时间更短”分开看。前者反映模型在官方测试集合上的能力，后者反映运行效率；两者同时成立，才说明模型在性能—速度平衡上有优势。遗憾的是，当前参考资料没有披露具体榜单名称、各项分数、测试样本数量和硬件配置，所以不能把“领先”进一步换算成一个未经证实的百分比。

| 模型 | 参数规格 | 官方定位 | 端侧信息 | 当前可确认的对比结论 | |---|---:|---|---|---| | MiniCPM-V 4.7-35B-A3B | 总参数35B，激活约3B | 端侧MoE多模态模型 | iPhone 17 Pro Max约3GB内存，13+ token/s | Instruct模式下官方称综合得分高于Qwen3.6 35B-A3B，推理时间更短 | | MiniCPM-V 4.7-1B | 1B级 | 轻量端侧多模态模型 | 支持移动端和多类芯片平台 | 官方称综合得分、推理效率领先Qwen3.5 0.8B | | MiniCPM-V 4.6 | 约1.3B级 | 上一代端侧多模态模型 | 已支持iOS、Android、鸿蒙 | 4.7 1B版本在基础能力上继续提升 | | Qwen3.6 35B-A3B | 35B-A3B | 同级MoE模型 | 需以官方部署条件为准 | 4.7官方宣称在Instruct综合评测中领先 | | Qwen3.5 0.8B | 0.8B级 | 轻量模型 | 需以官方部署条件为准 | 4.7 1B官方宣称在综合得分和效率上领先 |

从产品判断上看，35B-A3B 版本的意义大于 1B 版本。1B 多模态模型已经有不少竞争者，MiniCPM-V 4.6 也证明了小模型可以在手机上运行；而“35B 总参数、3B 激活、手机端流畅运行”如果能在更多设备上复现，才可能真正改变开发者对端侧 MoE 的预期。

支持三大移动系统，开发门槛仍取决于运行时

MiniCPM-V 4.7支持 iOS、Android 和鸿蒙，意味着它的目标不是单一手机演示，而是覆盖消费电子和本地计算设备。 官方还列出了 Intel、AMD、Arm、瑞芯微、后摩等芯片平台，覆盖手机、平板、PC、边缘设备和部分国产硬件生态。

这类跨平台支持对开发者很重要，但“支持某个平台”和“在某个平台上达到同样速度”是两回事。不同芯片的 NPU、GPU 和 CPU 架构差异很大，算子支持、量化格式、内存布局以及图编译工具链都会影响最终性能。iPhone 17 Pro Max 上的 13+ token/s，不能直接外推到一台 Arm 开发板或中端安卓手机。

实际部署时，开发者大概率需要根据硬件选择不同模型格式和后端。Hugging Face 页面已经列出了 35B-A3B 的 GGUF、FP8、GPTQ、AWQ、int4 等变体，以及 1B 版本的 GGUF、GPTQ 等格式。这意味着项目方正在同时覆盖通用本地推理、低比特量化和特定硬件加速路线。

但量化版本并非越低比特越好。4-bit 权重通常能显著降低内存占用，却可能影响 OCR、小字识别、复杂图表理解和长文本一致性；FP8 更接近原始精度，但硬件和运行时要求更高。端侧项目不应只比较模型文件大小，还要在目标设备上同时测试视觉准确率、峰值内存、首 token 延迟和持续吞吐。

SRFT让二次开发更值得关注

Self-Replay Fine-Tuning（SRFT）是一种通过自回放数据辅助微调、降低能力遗忘的训练方案。 MiniCPM-V 4.7此次同步开源 SRFT 微调方案，官方将其定位为帮助开发者低成本扩展模型能力并减少灾难性遗忘。

多模态模型微调的难点不只是让它学会新数据，还要避免“学会新技能后忘掉旧能力”。例如，企业希望模型理解自家设备说明书，直接在内部数据上持续训练，可能导致通用 OCR、图像问答或指令遵循能力下降。SRFT 的核心价值，是在训练新领域数据的同时，通过模型自身生成或回放的样本保留原有能力边界。

这对端侧模型尤其有价值。云端模型可以通过更大的训练集和更长的训练周期修复遗忘，手机端模型则通常受限于参数规模、算力和存储空间。一个更稳定的微调流程，能让开发者把 MiniCPM-V 4.7 改造成票据识别、工业巡检、教育辅导、设备维护等垂直模型，而不必从头训练一个视觉语言模型。

当然，SRFT不是“无需数据就能完成行业定制”。开发者仍需要准备高质量图文样本、设计评测集，并检查模型是否出现幻觉、敏感信息泄露和领域偏置。特别是在医疗、金融和工业安全场景中，端侧运行降低了数据出端风险，但不会自动消除模型判断错误的风险。

开源端侧多模态，真正的竞争才刚开始

MiniCPM-V 4.7的最大价值，是把端侧多模态竞争从“小模型能不能跑”推进到“更大模型能否稳定跑”。 过去，端侧部署通常意味着牺牲模型规模和能力，换取速度与隐私；4.7试图通过 MoE、前瞻调度和量化，把这条取舍曲线向更好的方向移动。

对开发者来说，最适合优先尝试的场景包括：

1. 离线图像问答： 手机拍照后直接分析物体、文档、设备面板和环境信息；
2. 本地OCR与文档理解： 发票、合同、课件和表格不上传服务器，适合隐私敏感场景；
3. 端侧智能助手： 将视觉输入和文本指令结合，用于相册搜索、屏幕理解和设备控制；
4. 边缘设备巡检： 在工厂、仓储或户外环境中运行，减少网络依赖和云端成本；
5. 垂直模型二次开发： 结合 SRFT，对行业图像和术语进行低成本适配。

它暂时不适合被简单包装成“手机上运行的完整GPT-4o替代品”。一方面，官方披露的评测细节还不够完整；另一方面，多模态模型的能力高度依赖图片分辨率、上下文长度、量化方案和后端实现。对于需要高可靠事实核验、复杂长链推理或实时视频理解的应用，仍然需要更严格的端到端测试。

OpenAI Hub判断：方向正确，但要看复现率

MiniCPM-V 4.7值得关注的不是单个跑分，而是它把 MoE 端侧化做成了一个可下载、可量化、可二次开发的完整方案。 35B-A3B 规格解决能力上限，1B 规格解决普及门槛，LES解决推理效率，SRFT解决行业适配，这四部分共同构成了一个比单纯发布模型更完整的产品路线。

但这次发布仍有两个需要继续观察的变量。第一，3GB内存和13+ token/s能否在不同批次设备、不同输入尺寸和不同量化格式下稳定复现；第二，35B-A3B在真实业务中的视觉理解质量，能否把评测领先转化为用户能感知的优势。

如果后续官方补充完整技术报告、统一基准测试和多芯片实测数据，MiniCPM-V 4.7可能成为开源端侧多模态模型的重要参照物。就今天的发布信息来看，它已经足够让开发者把“手机运行几十亿级激活参数的视觉语言模型”从概念验证，推进到值得认真做产品原型的阶段。

参考来源

• IT之家：面壁智能发布MiniCPM-V 4.7 —— 提供发布时间、模型规格、端侧内存和解码速度等发布信息。
• OpenBMB/MiniCPM-V GitHub仓库 —— 提供模型项目说明、部署与微调相关资料及开源进展。
• Hugging Face MiniCPM-V 4.7模型集合 —— 提供35B-A3B、1B及GGUF、FP8、GPTQ、AWQ、int4等模型文件信息。