面壁 MiniCPM-V 4.7：35B 模型如何跑进手机 3GB 内存

35B 参数、4bit 量化后权重约 17.5GB，而一台 12GB 内存手机留给模型的可用内存只有约 8GB。面壁智能的选择是让专家权重留在闪存里，再用一套前瞻调度把读取时间藏进计算时间——同一台 iPhone 上，解码速度从 3.38 token/s 变成 20.51 token/s。

10 月 13 日，面壁智能与 OpenBMB 开源社区发布 MiniCPM-V 4.7，包含 35B-A3B 与 1B 两个版本。官方技术博客在 10 月 20 日公开了背后的推理系统 LES（Lookahead Expert Scheduling，前瞻专家调度），代码已进入 llama.cpp-omni 仓库。这件事值得拆开看，因为它暴露了端侧大模型真正的约束在哪里。

一、先算清账：为什么一开始"装不下"

把模型塞进手机，先要区分两种空间。闪存是购买时标注的 256GB 或 512GB，用来存照片、应用和模型文件；运行内存是 12GB 或 16GB，是真正参与计算的工作区。

面壁智能联席首席科学家姚远给出的账是：配置较好的 12GB 手机，扣除系统占用后留给模型的可用内存最多 8GB 左右。而 35B 模型即便按较激进的 4bit 量化，仅权重就约 17.5GB（另一种口径按 Q4 计约 15GB），比可用内存大了近一倍。

结论很直接：一次性加载不可行，问题不是"跑得慢"，而是"根本放不进去"。

MoE 架构在这里提供了转机。35B-A3B 意味着 350 亿总参数、每个 token 只激活约 30 亿。专家之间彼此独立、并行计算，因此没必要把全部专家同时放进内存——大部分权重可以留在闪存，用到哪个读哪个。

二、装得下之后，问题变成"等不起"

按需加载的思路很自然，代价也很直接：模型每生成一个 token 都要穿过几十层，每层都要先确定用哪几个专家，再从闪存读取。读取延迟一旦落在关键路径上，计算单元就只能空转。

面壁的实测是：iPhone 17 Pro Max 上直接采用这种朴素方式，每秒只能输出 3.38 个 token。这个速度连"能用"的门槛都够不上——团队把实时性定义为解码速度高于 8 token/s，3.38 显然在门槛之下。

瓶颈因此从算力转移到了闪存读带宽与延迟。这是端侧推理与云端推理最本质的区别：云端拼 FLOPS，端侧拼内存带宽和 I/O 调度。

三、LES：不等确定了再读，而是提前猜

LES 的核心动作只有一句话：在 token 还没走到下一层之前，就把下一层可能需要的专家从闪存预读进内存。

实现上依赖一个经验观察——相邻层的 router 输入分布高度相似。于是推理引擎把当前层的 router 输入提前喂给下一层的 router，据此推测下一层会激活哪些专家，后台线程随即开始预读。这里没有训练额外的预测器，成本压在了调度逻辑里，而不是再挂一个小模型。

几个关键工程细节：

• 召回率约 80%：预读命中率不是 100%，但足以覆盖大部分 I/O 等待。
• 真正的 router 仍然做最终选择：预测只影响"提前读什么"，不影响"实际算什么"，路由结果不被篡改。
• 命中先算、未命中边算边等：已在内存的专家先参与计算，未命中的在计算进行中陆续到位。
• 专家权重连续布局：一个专家对应一段连续的文件区域，避免一次读取拆成多次随机 I/O。
• 逐层混合精度：专家权重用 Q3_K，其余用 Q4_K_M，权重文件从 19.7GB 降到 14.44GB，官方称五个基准的平均分从 FP16 的 78.28 变为 78.12。
• 投机解码：把 DeepSeek 与北京大学提出的 DSpark 方案适配进 llama.cpp，相关 PR 已合并上游。

消融数据：每一步各值多少

官方在同一台 12GB iPhone 上做了逐项叠加，这段数据比"20 token/s"这个结论本身更有信息量。

可以看到，单靠 LES 拿到约 1.9 倍，接近一半的收益来自后续的存储布局与量化配合。换句话说，预取解决的是"别空等"，而量化解决的是"少读一点"——两者乘起来才够用。同一代模型在 iPhone 18 Pro Max 上超过 20 token/s，在 M4 iPad 上以更大的专家缓存测得 18.0 token/s、峰值内存 7.8GB；最低内存档位下峰值约 3GB，速度 9.6–10.7 token/s。

四、"无损"这个词要打个折

官方把 LES 描述为"首个在手机上实时、无损运行 35B MoE"的系统。这里的两个词都有明确定义，也都有明确边界。

实时指解码速度高于 8 token/s，这是团队自订的门槛，不是行业标准。无损指保持原有网络结构、专家数量与路由不变，而不是与 FP16 输出逐位一致。量化的引入必然改变数值，78.12 与 78.28 之间的差距虽小，但确实存在。

全部速度与精度数据均为厂商自测，第三方复现尚未公开。好消息是 LES 与 DSpark 适配已在 llama.cpp-omni 开源，任何人可以在自己的设备上验证。

姚远在采访中还提到，最新 2.0 版本可在"精度损失可忽略"的前提下把速度提到 30 token/s。这类表述需要谨慎对待：在没有第三方基准的情况下，它更接近工程目标的宣示，而非可横向比较的结论。

五、千元机才是真正的战场

旗舰机跑通 35B 是技术展示，中低端机型能不能用才是规模问题。

按团队研究员蔡天驰的说法，上一代 MiniCPM-V 4.6 已在部分千元机上做到约 15 token/s，1B 版本"完全下探到千元机"，甚至覆盖部分百元设备。团队同时把 15 token/s 视为兼顾功耗、速度与回答质量的最佳权衡点——快于这个数字带来的体验增益开始递减，而功耗与发热上升明显。

已有商业化落地可查：今年 7 月公布的信息显示，MiniCPM 系列为三星 Galaxy Z Fold8 与 Fold8 Ultra 上的 Galaxy AI 提供端侧能力，涉及文本理解与多模态感知；最新版本正与多家厂商接触，部分处于测试中。这条线索和系统级入口的开放是同一件事的两面——千问接入 Apple 智能说明入口在打开，而 MiniCPM 进入三星说明供给端已经有量产验证。

六、给开发者的三条可执行结论

1. 端侧选型先看内存与带宽，而不是参数量。 35B 能跑、70B 未必不能跑，取决于激活参数比例、量化策略与 I/O 调度，而不只是总参数。评估时把"峰值内存"和"解码速度"并列成硬指标。
2. 外置专家 + 预取的思路可以迁移。 LES 依赖的是相邻层 router 的相似性，这一性质在其他 MoE 模型上同样存在，代码开源意味着可以直接拿现有模型试。若你在本地部署时遇到"模型稍大就慢"的问题，这篇关于本地 agent 的讨论里的困惑，本质上就是同一类 I/O 瓶颈。
3. 端云协同仍是主线。 面壁自己也把完整路径定义为端云协同，分界点在于终端能接住多少用户需求。把全部推理搬到本地并不现实，更合理的是按任务分层：高频、隐私敏感、低延迟要求的走端侧，长上下文与复杂推理仍回云端。这一点与云端小模型把价格压到 0.3 美元级别的趋势并不冲突——两边都在变便宜，选择权才真正回到架构设计上。

姚远用一个"等智能线"的概念描述终局：横轴是时间，纵轴是达到同等智能所需的最小参数量，这条线在快速下探；另一条上升曲线是端侧可有效运行的模型规模，两线交汇处，就是云端某个级别的能力落到手机上的时刻。他的判断是两年内 GPT-6 级别上机。

这个预测是否可以兑现，取决于硬件迭代速度、模型稀疏化程度与推理工程质量三条线是否同步。但从 3.38 到 20.51 这段消融数据看，至少推理工程这一条线，还有明显的余量可挖。

资料来源：面壁智能 LES 技术博客（2026-10-20）、界面新闻对姚远与蔡天驰的采访（2026-11-09）、科技日报报道（2026-11-10）。文中速度与精度数据均为厂商自测口径。