MiniCPM-V 4.7 35B-A3B:首个开源MoE多模态端侧模型

MiniCPM-V 4.7 35B-A3B 以 MoE 加系统级优化,把 35B 级多模态模型跑上手机端。
面壁智能发布 MiniCPM-V 4.7,推出该系列首个 MoE 变体 35B-A3B,宣称实现首个开源 MoE 模型的无损流畅端侧推理。其核心是一套组合技术:前瞻专家调度 LES、细粒度逐层量化和 DSpark 推测采样,使模型在 iPhone 17 Pro Max 上达到 13+ tokens/s 的解码速度。性能上,Instruct 模式以比 Qwen3.6 35B-A3B 更少的推理时间取得更高综合得分。视觉侧采用 LLaVA-UHD v4 的 ViT 早期压缩,支持 4x/16x 混合视觉 token 压缩。模型覆盖 iOS、Android、HarmonyOS,对 Rockchip、Houmo、Intel、AMD、Arm 提供 day-0 支持,并兼容主流推理与微调框架,同步发布 Self-Replay 微调方法。
面壁智能(OpenBMB)发布了 MiniCPM-V 系列的最新成员 MiniCPM-V 4.7,带来该系列首个 MoE 架构变体——35B-A3B。这个模型的出现,把「MoE 大模型跑在手机上」从概念验证推向了一个新阶段。
为什么 MoE 端侧部署一直是个难题
MoE(混合专家)架构的优势在于用更少的激活参数获得更强的能力,但它对显存和调度的要求让端侧部署变得棘手。专家路由的动态特性意味着推理过程中需要频繁切换权重,这在资源紧张的移动设备上很容易导致卡顿或降速。
MiniCPM-V 4.7 35B-A3B 针对这个矛盾给出了系统性的解法。官方将其描述为「首个开源 MoE 模型实现无损、流畅的端侧推理」,核心支撑是一套组合技术:Lookahead Expert Scheduling(LES,前瞻专家调度)、细粒度逐层量化,以及 DSpark 推测采样集成。三者协同让模型在 iPhone 17 Pro Max 上跑出了 13+ tokens/s 的解码速度——这个数字对于 35B 级别的 MoE 模型来说相当可观。
MoE(Mixture of Experts,混合专家) 是一种把单个稠密网络拆成多个「专家」子网络的稀疏架构。每个 token 在推理时只经过路由器(router)选中的少数专家,因此总参数量可以做到很大,而单次前向实际激活的参数(即激活参数,如 35B-A3B 中的 3B)却很小。这种「大容量、低激活」的特性理论上非常适合端侧——但代价是权重总量仍需全部驻留在内存中,且路由结果逐 token 动态变化,导致每一步要加载的专家权重不同,内存访问呈随机化,容易触发带宽瓶颈和调度抖动。
性能与效率的取舍有了新答案
模型能力的军备竞赛已经持续了很长时间,但端侧场景下的评判标准正在变化。资源受限设备上,单纯堆参数没有意义,真正重要的是「能力密度」——在有限的算力预算内能释放多少能力。
35B-A3B 变体在 Instruct 模式下,用比 Qwen3.6 35B-A3B 更少的推理时间拿到了更高的综合得分。官方的说法是「推进了多模态大模型的性能-效率帕累托前沿」。
这个比较值得关注的地方不在于谁高谁低,而在于它揭示了一个趋势:端侧多模态模型的竞争维度已经从「能不能做」转向「做得够不够划算」。
「35B-A3B」这类命名 指的是总参数量 35B、每 token 激活约 3B。其中的「A」即 Activated,衡量单次推理真正参与计算的参数规模。与之相对的是稠密模型,例如同样是 35B 的稠密模型每生成一个 token 都要动用全部 35B 参数。因此 A3B 的模型在单步计算量上接近一个 3B 小模型,但凭借稀疏激活的专家池,其表达能力仍可向 35B 级别靠拢。这也是为什么端侧 MoE 的核心挑战不在「算力」而在「访存」——决定速度的往往是把专家权重喂进计算单元的带宽,而非矩阵乘本身的浮点运算量。
视觉编码的架构优化
MiniCPM-V 4.7 在视觉侧采用了来自 LLaVA-UHD v4 的 ViT 内部早期压缩技术。简单说,视觉 token 在编码器内部就被提前压缩,后续层级的计算量随之减少。
更实用的一点是它支持 4x 和 16x 混合视觉 token 压缩。开发者可以根据任务需要灵活切换——需要精细识别时用低压缩比保留细节,追求速度时用高压缩比降低成本。这种可调节性在真实部署场景中比固定的压缩策略友好得多。
模型延续了 MiniCPM-V 家族的单图、多图和视频理解能力,基础能力相比前代有所增强。
ViT(Vision Transformer) 是把图像切成若干 patch、按序列建模的视觉编码器,输出的一串视觉 token 会被送进语言模型。分辨率越高,patch 越多,视觉 token 序列就越长,后续注意力和 MLP 的计算量随序列长度呈平方或线性增长,成为端侧多模态的主要开销来源。所谓 ViT 内部早期压缩,就是不必等编码器输出所有 token 再做筛选,而是在 ViT 的浅层就合并或丢弃冗余 token,让深层直接在更短的序列上计算。4x/16x 压缩比则指视觉 token 被压缩的倍数,倍数越高省算力越多,但细粒度信息损失也越大。
平台和芯片覆盖
端侧模型的落地能力很大程度上取决于生态覆盖。MiniCPM-V 4.7 支持 iOS、Android 和 HarmonyOS 三大移动平台,同时提供开源端侧部署方案。
芯片层面,它对瑞芯微(Rockchip)、后摩智能(Houmo)、Intel、AMD 和 Arm 的平台提供了 day-0 支持。所谓 day-0 支持,意味着模型发布当天这些芯片平台就能跑起来,不需要等待适配。对于做端侧产品的团队来说,这个细节能省下不少工程时间。
开发者工具链
推理框架方面,MiniCPM-V 4.7 兼容 SGLang、vLLM、llama.cpp 和 Ollama。微调框架支持 SWIFT 和 LLaMA-Factory。量化格式覆盖 GGUF、BNB、AWQ 和 GPTQ,并新增了 FP8 量化支持。GGUF 版本已经上传至 Hugging Face,方便社区直接下载使用。
官方还同步发布了 Self-Replay Fine-Tuning 方法,目标是在低成本扩展模型能力的同时减少对原有能力的遗忘。这个问题在微调实践中很常见——模型学了新任务,旧任务的表现就往下掉。Self-Replay 的思路是让模型在微调过程中回放自身已有能力,从而保持稳定性。
端侧多模态的下一步
MiniCPM-V 4.7 35B-A3B 传递的信号比较清晰:端侧多模态模型正在从「小参数、够用就行」的思路,转向「大参数 MoE + 系统级优化」的路线。13+ tokens/s 的手机端解码速度、多芯片 day-0 支持、以及混合压缩策略,共同构成了一个面向实际部署的完整方案。
接下来的看点在于:这套 LES + 量化 + 推测采样的组合方案能否被其他模型复用,以及端侧 MoE 推理的效率天花板到底在哪里。
「day-0 支持」 是开源模型生态中的一个时效性承诺:芯片厂商或框架方在模型发布的同一天就完成适配,使开发者下载即可在对应硬件上运行,而无需等待数周乃至数月的移植和调优。它对端侧落地的意义在于把适配成本从每个产品团队转移到模型与芯片的协同方。与之相关的还有推测采样(speculative sampling),即用一个小而快的草稿模型先连续猜出多个 token,再由大模型一次性并行校验,被接受的 token 直接保留,从而在输出质量几乎不变的前提下把串行解码变成半并行,这也是端侧提升 tokens/s 的常用手段。
相关推荐

@ai-sdk/vue 3.0.306 补丁发布 同步 [email protected] 更新
@ai-sdk/vue 3.0.306 发布,与 [email protected] 同步更新。这是 Vercel AI SDK 生态的一次常规补丁发布,无公开 API 变更,Vue 适配层保持与核心包版本对齐。

Gemini 4 Argon API发布:百万级输出Token时代来临
Google 正式发布 Gemini 4 Argon,稀疏 MoE 架构支持最高 100 万输出 token,Vals Index 以 68.90% 登顶,覆盖 API、AI Studio 和 Gemini 应用三端。

DukaanAI:用开源AI把商品照片变成库存清单
DukaanAI 是一款面向小零售商的 AI 库存工具,通过 Gemma 3 开源模型将商品照片转为库存条目,支持本地推理、字段编辑与 CSV 导出,探索 AI 辅助商品目录创建的可行路径。