35B 激活 3B、3GB 内存推理MiniCPM-V 4.7 深夜开源端侧多模态的天平又歪了【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型提供 35B-A3B 变体其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE混合专家模型。它在家族现有的单图、多图和视频理解能力基础上结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B端侧多模态大模型最近出了一个反常识的版本总参数量 350 亿、每次推理只激活 30 亿的混合专家MoE模型官方口径的端侧运行内存预算却只有3GB在 iPhone 17 Pro Max 上能跑出13 tokens/s的流畅生成速度。这就是面壁智能与 OpenBMB 深夜开源的 MiniCPM-V 4.7其 35B-A3B 变体也成为 MiniCPM-V 系列历史上第一个 MoE 模型。长期以来端侧模型想要高能力就得靠小参数 大力出奇迹而 MoE 模型虽然总参数大、单 token 激活量小却因为专家权重需要在有限内存里反复换入换出几乎与流畅二字无缘。MiniCPM-V 4.7 这一次把无损和端侧同时放在了 MoE 身上等于把这条赛道的天平又扳歪了一截。本文基于仓库源码README.md、config.json、model.safetensors.index.json逐条拆解这次发布背后的技术账。一、深夜开源的一记重拳发布关键信息逐条解读这次发布的核心事实可以浓缩为五条其一35B-A3B 是 MiniCPM-V 系列首个 MoE且同时提供了 1B 轻量变体。系列历史上 MiniCPM-V 2.68B、4.58B基于 Qwen3-8B SigLIP2-400M、4.61.3B都是 Dense 结构到 4.7 直接跨入 MoE总参数 350 亿、单 token 激活约 30 亿。仓库中同时出现了面向 1B 变体的性能图与端侧演示资源minicpm_v4dot7_assets/minicpmv4.7/overall_performance_1b_instruct.png、v47_1b_iphone_en.gif大小两头兼顾的意图非常明显。其二无损端侧 MoE 推理被当作核心卖点。README 的原话是MiniCPM-V 4.7 35B-A3B 成为首个在端侧流畅运行且不牺牲性能的开源 MoE 模型其解码速度在 iPhone 17 Pro Max 上达到 13 tokens/s、内存占用仅 3GB。支撑这套效果的是与模型同批开源的 Lookahead Expert SchedulingLES技术配合细粒度分层量化fine-grained layer-wise quantization与 DSpark 投机采样集成。其三性能-效率前沿被整体前推。README 给出的对标结论是在 Instruct 模式下35B-A3B 以更短的推理时间拿到了比 Qwen3.6 35B-A3B 更高的综合得分。同样是 35B-A3B 规格的模型能力与速度同时占优这正是仓库中performance_efficiency_frontier.png想表达的信息。其四平台与芯片的 day-0 覆盖。端侧部署支持 iOS、Android、HarmonyOS 三端芯片侧一次性给了 Rockchip瑞芯微、Houmo后摩、Intel、AMD、Arm 五家平台的 day-0 支持。这不只是适配了多少个系统的新闻点而是直接决定了模型能落进哪些形态的硬件里。其五生态配套一次给齐。推理侧支持 SGLang、vLLM、llama.cpp、Ollama量化侧在既有 GGUF、BNB、AWQ、GPTQ 之上新增了 FP8微调侧对接 SWIFT 与 LLaMA-Factory并随模型发布 Self-Replay Fine-Tuning一种在低成本扩展能力的同时抑制能力遗忘的微调方法另外还单独放出了一个用于投机解码的 DSpark 草案模型 MiniCPM-V-4.7-35B-A3B-DSpark。也就是说从跑起来、压下去到改得动整条链路都是开箱状态。二、源码级拆解一个 35B 的 MoE是怎么被无损塞进 3GB 的先说清楚端侧 MoE 难在哪。MoE 模型的总参数量可以很大但每个 token 只激活少数专家这是它省钱的原理可端侧部署的存储和内存账不能这么算——不同 token 在不同层会选中不同专家而设备内存往往装不下全部专家权重。于是一般有两条路一是允许权重常驻 SSD按需加载、用完释放模型确实能跑但反复加载带来的停顿会让解码慢到无法交互二是把专家子集焊死比如一个 prompt 全程只用固定的一批专家加载次数是少了但后续 token 的路由被限制在小范围内模型原本会选中的专家被排除在外能力受损。MiniCPM-V 4.7 的解法是把调度和计算解耦预测只负责预取计算始终忠于原始路由。具体拆成三块README On-Device MoE Inference 一节LESLookahead Expert Scheduling利用跨层路由预测提前预加载下一层大概率会用到的专家在真实路由器选中的专家中优先调度那些已成功预取的部分让它们的计算与其余专家的加载在时间上重叠。预测错了也没关系——漏掉的专家照常加载照常算不改变任何 token 的实际路由结果。这保证了流畅和无损可以同时成立。细粒度分层量化压缩专家权重的存储体积与内存流量让专家换页这件事在有限的带宽下变得更便宜同时尽量保住模型能力。DSpark 投机采样集成把投机解码引入端侧推理流程与专家调度、量化协同提高解码效率。优化前后的速度差距README 用一张对比动图展示minicpm_v4dot7_assets/minicpmv4.7/moe_speed_comparison_en.gif左为优化后、右为优化前再看架构层的证据。config.json 把 35B-A3B 的文本骨干暴露得很清楚40 层中只放了 8 层 full attention其余 32 层是 linear attentionlayer_types呈 3×linear_attention 1×full_attention 的周期排布full_attention_interval: 4。这是典型的混合注意力hybrid attention设计用线性注意力压低长上下文与 KV 缓存成本用周期性全注意力兜住质量。256 个专家、每 token 激活 8 个num_experts: 256、num_experts_per_tok: 8专家层中间维度只有 512moe_intermediate_size: 512并配 shared expert。细粒度的小专家切分一方面让路由选择更灵活另一方面也让按需换页的粒度更细天然契合 LES 的调度模型。上下文窗口开到262144max_position_embeddings词表 248144并带 1 层 MTPmulti-token predictionmtp_num_hidden_layers: 1这也是解码效率的一部分。视觉侧同样有明确的设计取舍。vision_config显示视觉塔为 27 层、hidden 1152、patch size 14、输入分辨率 980——这是 SigLIP2 风格的高分辨率视觉编码器。README 提到两点关键工程其一是沿用 LLaVA-UHD v4 的intra-ViT early compression视觉编码器内部早期压缩在编码器靠前的位置就把视觉 token 压下去后续层不再为冗余 token 白付算力其二是支持4x/16x 混合视觉 token 压缩16x 模式面向效率、4x 模式保留四倍细节开发者可以在看得细和跑得快之间按任务拨档。推理代码里对应的开关是downsample_mode且需要同时传给apply_chat_template与generate见 README.md 的 Inference 示例。全量权重层面model.safetensors.index.json 显示 bf16 原始权重约70.4GB、16 个分片从 70GB 到端侧 3GB 的落差正是由细粒度分层量化 端侧算子优化llama.cpp-omni 侧实现来填补的。值得注意的是仓库目录还完整保留了 FP8、int4、AWQ、GPTQ、GGUF 等量化变体的入口官方对全精度能跑、量化更能跑的梯度部署路径是刻意铺好的。三、3GB 内存流畅推理解禁了哪些场景13 tokens/s 是什么概念它处在逐字显示但无需等待的交互阈值之上——用户问完一句话模型能在几秒内把一段有内容的回答吐完这正好落在端侧语音助手、拍照问答这类实时交互可接受的范围里。而 3GB 的内存预算让一个 35B 总参数的模型第一次进入普通旗舰手机可以轻松长期驻留的区间。具体到场景可以列成四类1. 手机上的即时视觉问答。拍菜单问热量、拍植物问养护、拍产品说明书问用法这类看一眼就答的交互过去是云端 API 的活现在在端侧就能闭环。仓库里的实机录屏minicpm_v4dot7_assets/minicpmv4.7/v47_35ba3b_iphone2_en.gif展示的就是 iPhone 17 Pro Max 上的原生运行效果2. 离线与隐私敏感场景。医疗报告、合同、票据这类文档用户既想要 OCR 语义理解又不愿意把数据传到云端。3GB 内存 本地推理意味着这类数据不出设备的多模态能力可以做成默认选项而不是付费增值项。3. 视频与长文档理解的下沉。模型支持单图、多图与视频理解推理参数里max_num_frames默认 128 帧采样与stack_frames把视频拆帧的粗细交给开发者调。35B 级别的先验知识 多帧理解放在端侧意味着给一段视频做个结构化摘要这类需求在平板上就能直接完成——README 中 iPad M4 的实机演示v47_35ba3b_ipad_en.gif正是这个场景。4. IoT 与边缘设备的长尾市场。HarmonyOS 端支持 Rockchip/Houmo/Arm 的 day-0 适配指向的是智能家居中控、工业巡检手持终端、边缘盒子这类能装 App 但不一定有云的设备。对它们来说3GB 内存和 13 tok/s 是从演示级跨到产品级的临界点。一个值得玩味的对比是上一代 MiniCPM-V 4.6 只有 1.3B 参数官方给的运行内存是 6GB这一代 35B-A3B 总参数大了 27 倍端侧内存反而压到了 3GB。参数规模与端侧资源占用之间的强绑定关系在 MoE 调度优化面前第一次被真正松开——这也是3GB 内存流畅推理比35B 总参数更值得关注的原因。四、端侧多模态的天平对同赛道模型的直接冲击把这次发布放回赛道坐标里冲击是分层的。第一层能力密度的定义被改写。端侧多模态一直有个两难1B~4B 的小模型装得下、但复杂推理和世界知识有限云侧大模型能力强、但依赖网络与算力。MiniCPM-V 4.7 35B-A3B 走的是总参数上探、激活参数与内存下压的第三条路——能力对标 35B 量级资源账单按 3B 量级结算。同规格下比 Qwen3.6 35B-A3B 跑得更快、得分更高等于直接把35B-A3B 这个规格在端侧不可用的旧共识废掉了。第二层小模型路线的护城河被削薄。过去手机端多模态基本是 1B~3B Dense 模型的天下各家拼的是这么点参数还能挤出多少能力。现在一个 35B 总参数的 MoE 也能以 3GB 内存入驻手机小模型阵营引以为傲的轻量优势将被35B 的能力 小模型的开销组合反超。对 BlueLM-V-3B 这类面向移动设备做算法-系统协同设计的新研究社区已有相关论文讨论来说竞争基准一夜之间被抬高到了3GB 跑 35B-A3B。第三层硬件适配与生态形成乘数效应。芯片 day-0 支持Rockchip、Houmo、Intel、AMD、Arm 框架全覆盖SGLang、vLLM、llama.cpp、Ollama 量化全家桶GGUF/BNB/AWQ/GPTQ/FP8意味着模型不是一个孤立的发布而是一套改个量化档就能落进不同硬件的体系。对端侧芯片厂商和终端厂商而言从等一个能用的模型变成一个模型覆盖全产品线选型成本显著下降。第四层微调门槛被刻意压低。Self-Replay Fine-Tuning 的定位是低成本扩展能力、减少对既有能力的遗忘配合 SWIFT/LLaMA-Factory 的接入第三方可以基于 35B 级别的先验知识做领域定制而不必从头训一个大模型。这会让端侧私有化多模态从大厂专属变成团队级可及的事。如果说 MiniCPM-V 2.6 证明的是8B 也能跑端侧4.6 证明的是1.3B 也能很有用那么 4.7 35B-A3B 证明的是另一件事端侧模型的性能上限不该由设备内存来画线。当无损和端侧在 MoE 上不再互斥接下来的竞争焦点大概会从谁能跑转向谁跑得又准又稳又便宜——天平这次确实歪了但歪向的是真正把大模型装进口袋的那一侧。【免费下载链接】MiniCPM-V-4.7-35B-A3BMiniCPM-V 4.7 是 MiniCPM-V 系列的最新模型提供 35B-A3B 变体其中 35B-A3B 是 MiniCPM-V 系列中的首个 MoE混合专家模型。它在家族现有的单图、多图和视频理解能力基础上结合了更强的基础能力、高效的视觉编码以及端侧推理特性。项目地址: https://ai.gitcode.com/OpenBMB/MiniCPM-V-4.7-35B-A3B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考