你可以把 MoE 模型想成一家有许多专家小组的机构：每处理一个 Token——模型读写文字时使用的基本单位——只请少数几组工作。麻烦是，手机内存放不下所有专家，只能把大量权重留在容量更大、读取却更慢的 Flash 存储里。模型临时点到谁，再等谁“赶来上班”，计算就会被搬运卡住。
OpenBMB 这次给出的思路不是缩小模型，也不是少叫几位专家，而是提前安排接班。根据 Reddit 用户 GasSmooth7439 对 OpenBMB 工程文章的转述，MiniCPM-V 4.7 这款 35B-A3B MoE 模型可在 iPhone 18 Pro Max 本地运行，并达到 20.51 tok/s。这里的 35B 指总参数规模；A3B 通常表示每个 Token 只激活约 3B 参数，并不等于手机内存同时装下全部 35B 参数。下文数字均来自这一篇转述，尚无原始文章、论文、代码仓库或独立复现实测可供交叉核验。
难点不是算不动，而是等得久
MoE——Mixture of Experts，混合专家模型——会在每一层根据当前 Token 选择少量专家。这个选择过程叫“专家路由”。它随输入变化，系统很难提前知道下一层需要从 Flash 搬来哪些权重。
这造成一个尴尬：MoE 已经用“只激活少数专家”降低了单步计算量，手机却可能把省下来的时间花在等待数据上。Flash 像仓库，运行内存像工作台。仓库装得多，但从仓库取工具远慢于使用工作台上的工具。
把权重留在 Flash、需要时再搬进内存，并非新路线。Apple 研究者在 2023 年底发表《LLM in a Flash》，研究的正是让超过设备内存容量的模型按需读取权重。OpenBMB 面对的是更难预测的 MoE：不仅要搬，还要猜下一层会点到哪几位专家。
先猜下一棒，再安排出场
Lookahead Expert Scheduling（LES，前瞻专家调度）的核心，是预测下一层可能使用的专家。在当前一层仍在计算时，系统就从 Flash 预加载这些专家的权重，让搬运和计算重叠进行。
预测不可能总是完美。猜错会浪费带宽，猜晚了仍要等待。LES 的另一处安排，是优先执行权重已经就绪的专家。像厨房一边备下一道菜，一边先处理食材已经到位的工序，尽量不让灶台空等。
这项工作的卖点也在这里：转述称，它没有跳过或丢弃专家，也没有改变模型实际选择的路由。换句话说，系统调整的是专家抵达和执行的顺序，而不是替模型改答案路径。
20.51 tok/s 是整套工程的结果
LES 并非单独完成全部提速。转述称，它还结合了权重布局优化、混合精度量化和 DSpark speculative decoding。混合精度量化，是用不同精度保存不同部分的数字，减少权重占用；speculative decoding（推测解码）则通过先猜一段、再验证的方式加快生成。
这套组合在 iPhone 18 Pro Max 上达到 20.51 tok/s，相比 3.38 tok/s 的 baseline——作为比较起点的基础方案——快 6.07 倍。混合精度量化让专家权重缩小 26.7%，转述称五项 benchmark（标准化测试）的综合结果只下降 0.16 point。低内存配置下，峰值内存约为 3 GB。专家调度和 DSpark 集成据称已在 llama.cpp-omni 开源。
真正值得关注的，不只是“手机跑 35B”这句醒目的标题，而是它把突破点放在整条数据通路上：模型每步实际计算量已经不高时，下一步性能来自怎样摆放权重、何时搬运，以及先执行谁。这是一项内存与调度工程，而不是单纯压小模型。
局限与未知
- 20.51 tok/s 究竟统计预填充、逐 Token 解码还是端到端速度，材料没有说明；3.38 tok/s baseline 的量化、上下文长度、提示词、采样和缓存条件也缺失，因此 6.07 倍不能视作已复现的通用结果。
- “不跳专家、不改变路由”是否覆盖全部运行模式、全部 Token 和高内存压力场景，现有材料无法确认。LES 能否推广到其他 MoE，也只是转述者提出的可能性。
- 编辑部的调查材料另称正式成绩对应 iPhone 17 Pro Max，而本次唯一供稿写的是 iPhone 18 Pro Max，两者存在冲突。本文按供稿采用后者，但设备型号仍待 OpenBMB 原始材料核实；约 3 GB 也只适用于所谓低内存配置，不能外推到所有 iPhone。