iPhone跑35B MoE达20.5 tok/s：不跳专家的调度魔法

在手机上本地运行大模型早已不是新闻，但通常伴随着模型压缩、专家裁剪或精度大幅下降的代价。OpenBMB 最新公开的工程实践给出了另一种思路：让 35B-A3B 的 MoE 模型在 iPhone 上以 20.5 tok/s 的速度运行，且完全不跳过任何专家。

据 Reddit 社区讨论及 OpenBMB 工程博客披露，MiniCPM-V 4.7 借助一项名为 Lookahead Expert Scheduling（LES）的技术，在保持模型实际路由逻辑不变的前提下，将专家权重从闪存搬运到计算的瓶颈隐藏了起来。

核心思路：把内存搬运藏在计算背后

传统端侧 MoE 推理的瓶颈往往不在算力，而在存储带宽——专家权重体积庞大，无法全部常驻内存，每次路由到新专家都需要从闪存加载。常见做法是缩小模型或直接跳过部分专家，但这会改变模型行为、影响输出质量。

LES 的做法是“预测”——提前判断下一层可能需要的专家，在当前层计算进行的同时，把这些专家的权重从闪存预加载到内存，并优先执行已经就绪的专家。这样，闪存读取的延迟被计算时间掩盖，模型实际执行的专家集合与原始路由完全一致。

配合优化的权重布局、混合精度量化和 DSpark 推测解码，这套方案在 iPhone 18 Pro Max 上实现了 20.51 tok/s 的吞吐，相比 3.38 tok/s 的基线提速 6.07 倍。

MoE（混合专家）架构是理解本文的前提。与稠密模型每个 token 都激活全部参数不同，MoE 模型由多个“专家”子网络加一个路由网络组成，每个 token 只被路由到少数几个专家计算。文中的“35B-A3B”即总参数约 35B、每个 token 仅激活约 3B 参数。这使得模型总容量很大而单次计算量较小，非常适合算力有限的端侧设备。但代价是：专家权重总量依然庞大，无法全部驻留手机内存，路由又动态变化，导致推理时频繁从闪存调取不同专家，形成存储带宽瓶颈。这正是 LES 要解决的核心矛盾。

**存储带宽瓶颈（memory wall）**指计算单元的处理速度远快于数据从内存/闪存搬运的速度，使系统实际性能受限于数据搬运而非算力。端侧设备尤其明显：闪存随机读取延迟远高于内存，而 MoE 每次路由到新专家都可能触发一次闪存加载。若串行执行“加载—计算”，GPU/CPU 就会长时间空等。预取（prefetch）和调度（scheduling）正是缓解这一瓶颈的经典手段：在等待当前计算时提前搬运后续所需数据，让搬运与计算重叠，从而把带宽瓶颈“藏”在计算时间背后。

性能数据：快 6 倍，精度只掉 0.16 分

从公开数据看，LES 带来的收益相当可观：

• 吞吐提升：iPhone 18 Pro Max 上达到 20.51 tok/s，是基线 3.38 tok/s 的 6.07 倍。
• 体积缩减：专家权重缩小 26.7%，而五项基准测试平均仅下降 0.16 分。
• 内存占用：低内存配置下峰值内存约 3 GB。

这组数字的意义在于，它证明了端侧运行大 MoE 模型不必以牺牲路由完整性为代价。0.16 分的精度损失在多数应用场景中几乎不可感知，而 6 倍的吞吐提升则直接决定了交互体验是否可用。

**推测解码（speculative decoding）**是一种在不改变输出分布的前提下加速自回归生成的技术。它先用一个廉价的小模型（草稿模型）快速生成若干候选 token，再由大模型一次性并行验证这些候选；被接受的 token 直接采纳，被拒绝的则回退重算。由于大模型一次前向可验证多个 token，等效于减少了昂贵模型的前向次数，从而提升吞吐。DSpark 即文中集成到方案中的推测解码实现，它与 LES 的专家预加载协同，进一步放大了端侧吞吐收益。

混合精度量化指对模型不同部分采用不同数值精度（如权重用 4-bit、激活用 8-bit 或 16-bit），以在压缩体积和保持精度之间取得平衡。文中“专家权重缩小 26.7%、基准平均仅降 0.16 分”正是量化与权重布局优化共同作用的结果：专家权重占据模型体积主体，对其量化能显著降低闪存占用和搬运量，而精度损失被控制在可接受范围。

开源落地与可迁移性

据 OpenBMB 的说明，包括专家调度和 DSpark 集成在内的实现已在 llama.cpp-omni 中开源。这意味着其他开发者可以直接复用这套调度逻辑。

更值得关注的是该方法的通用性。LES 的核心是“预测下一层专家需求并预加载”，这一机制并不绑定特定模型架构。理论上，只要 MoE 模型的路由模式具有一定可预测性，类似调度策略就可以迁移到其他 MoE 模型上，为端侧部署提供一条不牺牲模型完整性的优化路径。

llama.cpp 是一个以 C/C++ 实现、面向消费级硬件和端侧设备的高效大模型推理框架，支持多种量化格式与跨平台部署，是手机、笔记本本地运行模型的主流选择之一。llama.cpp-omni 可理解为在其基础上扩展、集成多模态与专家调度等能力的工程分支。将 LES 与 DSpark 集成进此类开源框架，意味着调度逻辑以可复用的工程代码形式公开，其他开发者无需从零实现预测与预取机制，即可在自己的 MoE 部署中试验类似优化，这也是该方案具备可迁移性的现实基础。

对端侧 AI 的启示

过去端侧大模型的优化重心多在量化与剪枝，而 LES 提醒我们：系统层的调度与预取同样能释放巨大空间。当模型权重无法全部装入内存时，如何高效地在存储与计算之间搬运数据，可能比单纯压缩模型更有价值。

对于希望在手机、平板等设备上部署 MoE 模型的团队来说，这套“不跳专家”的调度思路提供了一个值得参考的新方向。

（本文基于 Reddit 社区讨论及 OpenBMB 公开工程资料整理。）