企业官网建设流程全解析

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.6（8B）、4.5（8B，基于 Qwen3-8B + SigLIP2-400M）、4.6（1.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 Scheduling（LES）技术，配合细粒度分层量化（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" 一节）：

• LES（Lookahead 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 attention（layer_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），专家层中间维度只有 512（moe_intermediate_size: 512），并配 shared expert。细粒度的小专家切分，一方面让路由选择更灵活，另一方面也让"按需换页"的粒度更细，天然契合 LES 的调度模型。
• 上下文窗口开到262144（max_position_embeddings），词表 248144，并带 1 层 MTP（multi-token prediction，mtp_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