3GB 内存，跑一个总参数 350 亿的模型——这不是云端推理的账单，而是一台手机上正在发生的事。2026 年 10 月 13 日前后，面壁智能（ModelBest）与清华 THUNLP 背景的 OpenBMB 团队发布了 MiniCPM-V 4.7，官方仓库更新日志记于 10 月 12 日，中文媒体随后集中报道。这一代的最大卖点可以压缩成一句话：它是官方口径下「首个端侧无损流畅运行的开源 MoE 多模态模型」，提供 35B-A3B 与 1B 两个版本，前者就是那个塞进 3GB 内存的 350 亿参数大家伙。
项目入口：OpenBMB/MiniCPM-V，仓库地址：github.com/OpenBMB/MiniCPM-V。截至 GitHub API 2026-10-15 快照，这个 2024 年 1 月建仓的老牌项目已有 26,753 星、2,096 fork，最近一次推送在 2026-10-14——发布热度还在持续兑现成社区活跃度。
把时间轴拉长看，「把大模型塞进手机」是 MiniCPM 系列从 2024 年起就立下的主赛道：第一代的技术报告标题就是《MiniCPM-V: A GPT-4V Level MLLM on Your Phone》，仓库主页的口号至今是「See, hear, and interact on your local devices」。区别在于，前几代解决的是「小模型能不能用」，4.7 这次动的是 MoE——一个公认端侧跑不动的架构。
端侧跑 MoE，到底难在哪
MoE（混合专家）架构的账面诱惑很大：总参数撑起模型能力上限，每个 token 只激活其中一小部分。MiniCPM-V 4.7 的 35B-A3B 就是总参 350 亿、每 token 激活 30 亿的组合——按激活量算，它是一个 3B 模型的工作量；按能力算，它吃到的是 35B 模型的天花板。
问题出在「存货」。官方仓库文档把这件事讲得很清楚：MoE 的存储需求并不等于激活参数。路由器每层每 token 都可能挑不同的专家，全量专家权重加起来远超手机内存；如果要跑，这些权重平时只能待在闪存（SSD）里，用到谁加载谁。官方文档承认，这确实让大模型推理「成为可能」——但反复加载造成的停顿会让解码速度慢到无法支撑实时对话。
业界的另一种思路是做减法：给整个 prompt 固定一个专家子集，减少加载次数。官方文档同样指出了代价——这等于替模型预设了路由结果，后续 token 可能需要、但不在子集里的专家会被排除，模型能力随之受损。速度快了，答案变笨了。
所以真正的题目从来不是「能不能跑起来」，而是官方反复强调的那八个字：无损、流畅——能力不打折，吞吐还够用。这是一道内存容量、闪存带宽和模型能力的三约束优化题。
LES：让专家权重提前起跑
面壁给出的答案叫 LES（Lookahead Expert Scheduling，前瞻专家调度）。官方文档的类比是接力赛的接棒人提前起跑——下一棒还没交，人已经在外面加速了。
拆开看，LES 做三件事。第一，跨层路由预测：用预测模型提前判断下一层可能需要哪些专家，把它们预先加载进内存。第二，优先调度：当真实的路由器做出选择时，在它选中的专家里优先计算那些已经预取到位的，省掉等待时间。第三，计算与加载重叠：已到位的专家在算，没到位的专家还在路上加载，两条流水线并行跑。
这里有一个容易被忽略、但决定成败的设计细节：预测只影响预取和调度，完全不改计算路由。模型该选哪个专家还是选哪个，预测没蒙中的专家照常加载、照常计算。这就是「无损」的工程含义——LES 优化的是权重到位的时机，而不是模型的决策路径。牺牲一点内存带宽去赌预测命中率，赌错了也不影响正确性。
按官方口径，LES 在真机上带来 5 倍提速，官方称这是业界独家开源的方案。围绕它还有两件配套：细粒度分层量化压缩专家权重的存储体积和访存量，让加载更贴合端侧内存与带宽的现实约束；DSpark 投机采样则从另一个方向（一次猜多个 token）继续抬解码效率。三者叠加，才有 35B-A3B 那个 3GB 内存的运行数字。
值得一提的还有 LES 的落地载体：官方推理加速仓库 OpenBMB/llama.cpp-omni，仓库地址：github.com/OpenBMB/llama.cpp-omni，描述为「Omni inference in C/C++」，基于 llama.cpp 改造、采用 MIT 许可。GitHub API 2026-10-15 快照显示它 2026-10-13 才建仓，目前 16 星、2 fork——非常新，星数不能说明什么，但它就是 4.7 端侧推理的官方主路径。
双版本与成绩单
MiniCPM-V 4.7 提供两个规格。35B-A3B 是系列首个 MoE 模型，主打端侧旗舰体验；1B 则是「小而够用」的极致压缩，面向更广的存量设备。
速度数字以官方仓库文档为准：35B-A3B 在 iPhone 17 Pro Max 上、3GB 内存条件下，解码速度 13+ token/s（README 与模型文档 minicpm_v4dot7_en.md 一致原文）。第三方转述中出现过 15+、17+ 等不同口径，均与官方文档不符，本文不采用。官方文档的示例区附了三段未剪辑真机录屏——35B-A3B 分别跑在 iPhone 17 Pro Max 与 iPad（M4）上、1B 跑在 iPhone 17 Pro Max 上，官方以此展示移动端直接问答的效果。
成绩单方面需要先立规矩：以下是官方称，未经第三方独立复核。官方称 35B-A3B 在 34 项权威基准（覆盖多模态理解、STEM 推理、OCR、长视频理解）上全面领先同档；1B 处于同尺寸第一梯队。官方文档给出的横向对比是：Instruct 模式下，35B-A3B 比 Qwen3.6 35B-A3B 用更少的推理时间拿到更高的总分；1B 在总分和推理效率两个维度都大幅领先 Qwen3.5 0.8B，同时在此前一代 MiniCPM-V 4.6 的核心能力基础上继续提升。官方把这套叙事概括为「性能-效率帕累托前沿」的推进——用更少的每 token 计算量换不缩水的能力。
多模态一侧还有自己的省法。4.7 延续了系列的混合 4×/16× 视觉 token 压缩，并引入基于 LLaVA-UHD v4 的 intra-ViT 早压缩技术，在视觉编码器内部就提前压缩视觉 token，减少后续所有层的计算量。开发者可以按任务在 4×（更细的视觉细节）和 16×（更高的推理效率）之间切换——看文档 OCR 时要细节，闲聊时省 token，一进一出由 downsample_mode 参数控制。
生态盘点：从权重到微调的全家桶
开源项目值不值得跟，一半看生态厚度。4.7 这次给得相当齐：
权重全家桶。 Hugging Face 与 ModelScope 双渠道，35B-A3B 和 1B 各自配有 FP8、int4、AWQ（W4A16）、GPTQ（W4A16）、GGUF 量化变体，外加 DSpark 投机解码草稿头——桌面 GPU 用户有 FP8/AWQ 可选，纯 CPU 用户走 GGUF，端侧用户用官方分层量化，一条产线覆盖到头。
推理与微调框架。 官方文档列出的推理框架包括 SGLang、vLLM、llama.cpp、Ollama，微调框架包括 SWIFT 和 LLaMA-Factory；另有 OpenVINO 的 Intel 平台 Day-0 支持，官方 notebooks 里有现成示例。配套的 MiniCPM-V 4.7 Cookbook 覆盖单图、多图、视频、OCR、PDF 解析、视觉定位六类任务指南。
自回放微调（SRFT）。 官方同步开源的定制方法，主打低成本扩展新能力的同时减少旧能力遗忘——对想拿 4.7 做垂直定制的团队，这比「全量微调赌运气」靠谱。
平台与芯片。 iOS、安卓、鸿蒙三系统官方支持，应用与源码放在姊妹仓库 OpenBMB/MiniCPM-V-Apps（官方文档口径）；芯片 Day-0 名单按官方文档为 Intel、AMD、Arm、瑞芯微、后摩智能五家，其中 Intel 平台还有 OpenVINO 的 Day-0 支持与现成 notebook 示例。官方生态公告另称，经众智 FlagOS 还适配了华为昇腾、摩尔线程、沐曦等一批国产芯片（官方称）。
系列背书。 官方称 MiniCPM 系列全球累计下载已超 6000 万次，覆盖文本、视觉、语音全模态。这个数字无法独立核实，但 26,753 星的仓库和连续两年多的更新记录（4.5、4.6 到 4.7，每一代都有独立文档）至少说明这不是一锤子买卖。
权重许可：读原文再说商用
权限问题不猜，只看原文。主仓库 LICENSE 文件为 Apache-2.0（已核原文）；README「License & usage」一节给的三件套是：Apache-2.0（代码）、Model license（指向 docs/project_en.md 的 Model License 节）、Usage statement（免责声明）。
权重许可的最终依据是 docs/project_en.md 的 Model License 节，原文要点：「The MiniCPM-o/V model weights and code are open-sourced under the Apache-2.0 license」——权重和代码统一按 Apache-2.0 开源。原文链接：github.com/OpenBMB/MiniCPM-V/blob/main/docs/project_en.md。
落到实用层面：Apache-2.0 是宽松许可，允许商用、修改和再分发，附带的义务是保留许可证与 NOTICE 文件、对修改做出声明，并包含专利授权条款。也就是说，商用不需要向官方申请或登记，合规动作就是照 Apache-2.0 的通用条款执行。官方在 Model License 节还附了一份登记问卷，原文措辞是「would deeply appreciate it if you could consider optionally filling out」——关键词是 optionally（可选）：填了帮官方了解用户构成，不填不影响任何使用权利。最后别忘了 Usage statement 那部分是标准免责声明：模型生成内容不代表开发者观点，使用风险自担。
这套「代码+权重同许可、登记可选」的组合在开源多模态模型里算清爽的——没有自定义条款、没有分用途门槛，读一遍 Apache-2.0 就能确定边界。
延伸阅读
FAQ
Q1： 为什么在端侧跑 MoE 模型这么难？
A1： MoE 的存储需求不等于激活参数。每个 token 在每层都可能路由到不同专家，全量专家权重远超手机内存。把权重放闪存按需加载，反复加载的停顿会让解码慢到没法对话；限制可用专家子集能提速，但等于替模型预设路由结果，会损失能力。「无损流畅」要求能力与吞吐都不妥协，这是内存、闪存带宽和模型能力的三约束问题。
Q2： LES（前瞻专家调度）是什么原理？
A2： LES 通过跨层路由预测，提前把下一层可能用到的专家权重预加载进内存；真实路由做出选择后，优先计算已预取到位的专家，并让计算与剩余专家的加载重叠进行。关键设计是预测只影响预取与调度、不改计算路由，预测失误的专家照常加载计算，因此不损失模型能力。官方称真机 5 倍提速。
Q3： 3GB 内存运行 35B 模型，这个数字该怎么理解？
A3： 这是运行时内存占用而非全量权重体积，更不是整机门槛：35B-A3B 每 token 只激活 30 亿参数，配合官方细粒度分层量化后，专家权重平时留在闪存、被调度时按需进内存。官方口径为 iPhone 17 Pro Max 上 3GB 内存跑出 13+ token/s 解码速度；但官方 App 硬件要求表另给整机建议——35B-A3B 推荐整机 RAM ≥12GB（验证机即 12GB 版 iPhone 17 Pro Max），1B 推荐 ≥4GB，内存更小的设备会自动缩小专家缓存、速度明显变慢。引用「3GB」时注意区分这两个口径。
Q4： MiniCPM-V 4.7 和上一代 4.6 是什么关系？
A4： 4.6 于 2026-05-11 发布，是稠密架构，2026-06-25 进入 Ollama 官方模型库；4.7 是系列首个 MoE 模型，架构上换代。官方称 1B 版本在 4.6 的核心能力基础上继续提升，35B-A3B 则把同档能力密度推到新水平。两代共用混合 4×/16× 视觉 token 压缩等系列技术。
Q5： MiniCPM-V 4.7 的权重可以商用吗？
A5： 可以，依据是官方文档原文而非推断：docs/project_en.md 的 Model License 节写明权重和代码均以 Apache-2.0 开源。Apache-2.0 允许商用、修改与再分发，义务是保留许可证与 NOTICE、声明修改；官方的登记问卷是可选动作，不构成商用前提。此前一些开源模型「代码宽松、权重另设条款」的双轨制在这里不存在，但具体项目仍建议以官方文档最新原文为准。
写在最后
把 350 亿参数的 MoE 塞进 3GB 内存，技术上的三件套是 LES 前瞻调度、分层量化与投机采样；工程之外的信号是：端侧跑大参数模型的门槛，正在从「有多少显存」转向「怎么调度」。对开发者来说，权重、推理代码、微调代码全部开源且许可宽松，意味着这条端侧多模态路线第一次真正可以「拿走自用」。如果想跟着装一遍，从手机到桌面的三条部署路线，见同批的部署实操篇。