MiniCPM-V 4.7把35B MoE装进手机

面壁智能今天发布了新一代端侧多模态模型 MiniCPM-V 4.7。此次更新最大的看点不是单纯增加参数，而是把一个总参数量 35B、激活参数量 3B 的 MoE 模型带到了手机端，并宣称在 iPhone 17 Pro Max 上仅使用约 3GB 内存即可达到 13+ token/s 的解码速度。

MiniCPM-V 4.7 是面壁智能 MiniCPM-V 系列的最新版本，提供 35B-A3B 和 1B 两种规格。其中，35B-A3B 是该系列首次采用 Mixture of Experts，也就是混合专家架构的模型。官方称，35B-A3B 版本基于 LES，也就是前瞻专家调度技术，实现了端侧运行时的动态专家选择，并在 iOS、Android 和 HarmonyOS 上提供支持。

这次发布的核心意义在于：过去 MoE 更像是数据中心里的大型发动机，模型虽然能通过稀疏激活降低单次计算量，但内存、权重加载和调度成本仍然让它很难进入手机；MiniCPM-V 4.7 则试图把这套架构压缩成一个能够在本地设备上稳定运行的方案。

35B-A3B到底意味着什么

35B-A3B 是一种总参数量约 350 亿、单次推理激活约 30 亿参数的稀疏 MoE 模型。 与传统稠密模型每次都调用全部参数不同，MoE 会把模型拆成多个专家网络，再由路由器根据当前输入选择少数专家参与计算。

可以把它理解成一家拥有 35B 名员工的公司，但每处理一个问题只安排约 3B 规模的专业团队上岗。这样做的好处是，模型可以保留更多“知识容量”，同时把每个 token 的计算成本控制在较低水平；代价则是需要额外处理专家权重存储、专家切换和内存访问问题。

对于云端 GPU 集群而言，专家调度可以依靠高速显存互联和大规模并行硬件完成。但手机的情况完全不同：内存带宽有限，系统还要为应用、图形渲染和后台服务留出空间。如果所有专家权重都常驻内存，35B 模型即使采用低比特量化，也很容易超出普通手机的可用内存。

MiniCPM-V 4.7 的关键，就是让“总参数很大”和“实际运行负担较小”同时成立。官方公布的测试结果显示，35B-A3B 版本在 iPhone 17 Pro Max 上只占用约 3GB 内存，解码速度超过 13 token/s。对于本地聊天、图片问答和短文本生成来说，这已经接近可交互使用的速度，而不是只能用于离线演示。

需要注意的是，13+ token/s 是官方在特定设备、特定量化和推理配置下给出的结果，不等于所有手机都能达到同样速度。实际表现还会受到上下文长度、输入图片分辨率、视觉编码器耗时、系统温度和后台负载影响。尤其是多图、长视频或复杂文档任务，视觉侧的预处理时间可能比文本解码更先成为瓶颈。

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

LES，即前瞻专家调度，是 MiniCPM-V 4.7 用于降低 MoE 端侧推理开销的推理加速技术。 它的核心方向不是让所有专家同时待命，而是提前预测后续计算需要哪些专家，并尽可能减少无效的权重调入和等待。

在传统 MoE 推理中，模型通常需要先完成路由判断，再把选中的专家调度到计算单元中。对于服务器，这个过程可以通过显存和高速互联隐藏一部分延迟；但在手机上，专家权重的读取、缓存命中率和内存搬运会直接影响速度。很多时候，算力并没有被真正耗尽，系统却在等待数据。

前瞻专家调度的价值，类似于把超市的补货从“顾客开口后再去仓库取货”改成“根据购物车提前把可能需要的商品放到货架旁”。如果预测准确，专家切换带来的等待时间就能被压缩；如果调度策略足够稳定，系统也不必为每个 token 频繁搬运完整权重。

面壁智能没有在目前公布的信息中披露 LES 的完整实现细节、专家数量、路由策略和不同量化配置下的内存曲线，因此还不能仅凭 13+ token/s 判断它在所有端侧场景都已经解决了 MoE 的部署问题。但从产品方向看，LES 让 MiniCPM-V 4.7 不再只是一个“把大模型压小”的项目，而是在尝试重构端侧推理过程本身。

两个版本，分别瞄准性能和普及度

MiniCPM-V 4.7 同时提供 35B-A3B 和 1B 版本，前者强调能力上限，后者强调更广泛的设备覆盖。

| 模型 | 架构定位 | 官方披露重点 | 更适合的场景 | |---|---|---|---| | MiniCPM-V 4.7 35B-A3B | 首个 MiniCPM-V 系列 MoE 模型 | 约 3GB 内存、13+ token/s、支持端侧无损流畅运行 | 高质量图像问答、复杂文档理解、本地助手、端侧智能座舱 | | MiniCPM-V 4.7 1B | 轻量级端侧多模态模型 | 基础能力和推理效率继续提升 | 手机 App、嵌入式设备、低功耗终端、批量部署 | | MiniCPM-V 4.6 | 上一代轻量端侧模型 | 已支持 iOS、Android、HarmonyOS | 现有端侧应用升级和兼容性部署 | | Qwen3.6 35B-A3B | 同规模 MoE 对比对象 | 官方称 MiniCPM-V 4.7 35B-A3B 在 Instruct 模式综合得分更高、推理时间更短 | 云端或高性能本地部署对比 | | Qwen3.5 0.8B | 小参数量对比对象 | 官方称 MiniCPM-V 4.7 1B 在综合得分和推理效率上领先 | 轻量端侧模型选型 |

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

这里需要保留一个判断边界：官方目前给出的信息主要是相对结论，并没有在发布消息中完整列出评测任务、硬件、量化精度、上下文长度和每项 benchmark 的具体分数。因此，这些结果可以说明 MiniCPM-V 4.7 的性能效率取向，但还不足以证明它在所有视觉语言任务上全面超过对手。开发者在选型时，仍应重点关注 OCR、文档解析、视频理解、空间推理和多图输入等与自身业务直接相关的指标。

1B版本可能比35B-A3B更容易真正落地

35B-A3B 是发布会里最吸引注意力的型号，但 1B 版本可能才是 MiniCPM-V 4.7 大规模部署的主力。原因很简单：端侧项目通常不是只追求一次演示中的最高能力，而是要考虑安装包体积、启动时间、持续功耗、温升、内存峰值和设备兼容性。

对于手机 App 来说，一个 1B 级多模态模型更容易常驻后台或与其他本地模型协同。它可以承担截图理解、相册分类、简单 OCR、商品识别、离线问答等任务；遇到复杂问题时，再由更大的本地模型或云端服务接管。这样的分层策略通常比让一个 35B 模型处理所有请求更实际。

35B-A3B 则更适合对理解质量有要求、同时又不希望图像数据离开设备的场景。例如，企业内部文档、工业现场照片、车内摄像头画面和个人相册都可能涉及隐私。模型在本地完成视觉编码和文本推理，可以减少数据上传需求，也能在没有网络的环境中保持基本能力。

从图片问答走向动态世界理解

端侧多模态模型是能够在本地设备上同时处理图像、视频和文本输入的模型。 它与普通端侧语言模型的差别，不只是多了一个图片输入框，而是需要在有限算力下完成视觉编码、视觉 token 压缩、跨模态对齐和文本生成。

MiniCPM-V 系列此前已经把重点放在高效视觉理解上。公开资料显示，MiniCPM-V 4.6 基于 SigLIP2-400M 和 Qwen3.5-0.8B LLM 构建，并支持单图、多图和视频理解；更早的 MiniCPM-V 4.5 还通过 3D-Resampler 增加视频帧压缩效率，在相同视觉 token 开销下接收更多视频帧。

这条技术路线对于端侧设备尤其重要。传统视频理解常常每秒抽取 1 帧，模型看到的更像是视频的“幻灯片摘要”，容易错过物体移动、手势变化和短暂事件。更高密度的视频压缩能够让模型看到更多连续画面，但同时也会增加视觉编码和内存压力。

因此，MiniCPM-V 4.7 的价值不应只看文本生成速度。真正值得测试的是：它能否在本地对连续视频保持稳定理解，能否正确读取复杂表格和小字号文本，能否在长上下文中保持前后画面一致，以及在持续运行十几分钟后是否出现明显降频。

开源SRFT，降低二次训练门槛

Self-Replay Fine-Tuning（SRFT）是一种通过自回放数据参与微调、帮助模型扩展新能力并减轻灾难性遗忘的微调方案。 面壁智能此次同步开源 SRFT，目标是让开发者在定制端侧多模态模型时，不必完全依赖大规模人工标注数据。

端侧模型微调经常面临一个矛盾：开发者希望模型学会某个垂直领域的术语、格式和工作流程，但过度训练新数据后，模型可能忘记原本具备的通用图像理解、OCR 或对话能力。SRFT 的思路，是在学习新任务的同时，让模型通过回放旧能力或自生成样本保持原有能力分布。

这对于企业部署尤其有用。例如，一家制造企业可以让模型学习本公司的设备编号、巡检标准和故障描述格式，同时保留通用图片问答能力；一家手机厂商也可以围绕系统截图、相册标签和本地文档建立专属能力，而不必从头训练一个视觉语言模型。

不过，SRFT 并不意味着微调可以完全摆脱数据质量和评测。自回放数据可能放大模型原有的错误，领域数据覆盖不足也会造成新的偏差。实际项目仍然需要建立训练集、回归集和安全评测集，并对微调前后的 OCR 准确率、幻觉率、长上下文稳定性进行对比。

芯片适配比模型参数更决定体验

MiniCPM-V 4.7 宣称支持 iOS、Android 和 HarmonyOS，并适配 Intel、AMD、Arm、瑞芯微、后摩等芯片平台。这个信息的意义在于，它不只面向手机应用，也在向 PC、嵌入式设备、边缘计算盒子和智能座舱延伸。

端侧模型的实际体验，往往由“模型权重、推理框架、编译器、硬件后端和内存系统”共同决定。相同的模型文件，在不同设备上可能出现完全不同的速度和功耗表现。手机端需要关注 GPU、NPU 或统一内存的利用率；嵌入式设备更看重持续功耗和散热；汽车平台则要考虑多摄像头输入、系统实时性和长时间运行稳定性。

官方开源仓库此前已经提供 iOS、Android 与 HarmonyOS 的本地推理示例，并围绕 GGUF 模型文件、设备内存需求和 llama.cpp-omni 推理层维护部署资料。对于开发者而言，MiniCPM-V 4.7 是否好用，最终要看权重格式、量化版本、视觉编码器支持和硬件后端是否同步开放，而不只是看模型名称和参数规模。

我的判断：这是一次“推理工程”升级，而非参数竞赛

MiniCPM-V 4.7 最值得关注的地方，是它把端侧模型竞争从“谁的参数更少”推进到了“谁能更有效地管理参数”。35B-A3B 的总参数规模并不轻，但通过 MoE 稀疏激活、前瞻专家调度和端侧优化，模型试图同时获得更大的知识容量与较低的运行成本。

如果官方公布的 3GB 内存和 13+ token/s 数据能够在更多设备、更多上下文长度和更多视觉任务中复现，那么 MiniCPM-V 4.7 会成为目前开源端侧多模态模型中很有竞争力的一款方案。特别是在隐私敏感、网络不稳定和需要实时响应的场景，本地运行的价值远不止节省推理费用。

但它也不是一个可以无条件替代云端大模型的产品。35B-A3B 的真实部署仍然会受到量化精度、模型加载时间、长视频输入、持续功耗和芯片后端成熟度影响；1B 版本虽然更容易普及，却可能在复杂推理和细粒度视觉任务上存在能力上限。对开发者来说，最合理的做法不是只看综合榜单，而是把模型放进真实业务链路，测量从图片输入到最终输出的完整延迟。

截至 2026 年 10 月 13 日，MiniCPM-V 4.7 的发布释放了一个清晰信号：端侧多模态模型正在从“能在手机上跑”进入“能以接近实时的速度稳定工作”阶段。MoE 不再只是云端大模型的架构选项，也开始成为移动设备争夺多模态能力上限的一条现实路线。

适合哪些开发者关注

• 移动端开发者：可以重点评估 1B 版本的包体积、启动耗时、量化精度和后台功耗。
• 隐私计算团队：可以测试 35B-A3B 在本地文档、医疗影像描述和个人相册场景中的数据闭环能力。
• 智能座舱开发者：应重点验证连续视频理解、多摄像头输入和长时间运行温升。
• 边缘设备厂商：需要确认 Intel、AMD、Arm、瑞芯微和后摩平台上的算子覆盖与推理后端支持情况。
• 模型微调团队：可以研究 SRFT 对领域适配、灾难性遗忘和小样本学习的实际收益。

结论

MiniCPM-V 4.7 是面壁智能首次在 MiniCPM-V 系列中引入 MoE 的版本，35B-A3B 通过约 3B 激活参数、LES 推理加速和端侧部署优化，瞄准的是“更强能力与手机级实时性同时存在”的目标。官方披露的 iPhone 17 Pro Max 测试结果——约 3GB 内存、13+ token/s 解码——让它成为今天最值得关注的端侧开源多模态模型之一。

它的最终竞争力，仍取决于开源权重、量化方案、芯片适配和第三方复现结果。但从技术方向看，MiniCPM-V 4.7 已经不再只是一次常规版本迭代，而是在回答一个更重要的问题：当模型规模继续扩大时，端侧设备能否通过稀疏架构和更聪明的调度，把原本属于云端的多模态能力真正带到用户手里。

参考来源

1. IT之家：面壁智能发布 MiniCPM-V 4.7 —— 提供本次发布的型号、端侧内存占用、解码速度、平台适配和官方对比信息。
2. OpenBMB/MiniCPM-V GitHub 中文 README —— 提供 MiniCPM-V 系列定位、端侧部署资料、模型架构和历史版本信息。
3. MiniCPM-V-Apps GitHub 项目 —— 提供 iOS、Android、HarmonyOS 本地推理示例及设备部署说明。