面壁智能前瞻专家调度（LES）：让 35B MoE 在手机上实时无损运行的推理技术

2026-10-20

图1 MiniCPM-V4.7 系列在推理速度和评测分数综合领先

面壁智能前瞻专家调度（Lookahead Expert Scheduling，LES）是支撑 MiniCPM-V 4.7 在端侧高效运行的核心技术。它首次实现了 35B-A3B 规模的 MoE 模型在端侧实时无损运行，在 iPhone 18 Pro Max 上实测解码速度超过 20 token/s，将端侧实时运行的模型规模提升了一个量级。本文将介绍 LES 推理系统的核心设计，以及它在调度、存储和计算三个层面的优化。

目标与难点

我们的目标是让模型在端侧实时无损运行。实时指解码速度高于 8 token/s；无损指完整保留原始模型的网络结构与推理机制，不减少专家数量、激活专家数量或网络层数，不通过 Prompt 固定专家选择或将 MoE 模型退化为 Dense 模型。

围绕这一目标，系统设计需要满足三个约束：一是完整执行真实 Router 选中的所有专家，不通过替换专家或减少激活专家数量来减少权重读取；二是不额外训练专家预测模块，避免引入额外的训练成本；三是将运行时内存占用控制在主流端侧设备可承载的范围内。

在这些约束下，我们需要解决三个核心问题。

权重装不下：模型规模超过可用内存

MiniCPM-V 4.7 35B-A3B 的总参数约 350 亿，每个 token 激活约 30 亿参数。按每个参数 4 bit 计算，仅权重就需要约 17.5 GB，还不包括量化元数据、KV Cache 和运行时缓冲区。以 iPhone 18 Pro Max 为例，12 GB 统一内存由系统、CPU、GPU 和应用共享，无法让全部模型权重常驻内存。

MoE 的稀疏激活特性提供了另一种思路：每层只需要执行少量专家，因此可以将专家权重保留在闪存中，在需要时加载到内存，计算完成后再释放。这样，运行模型所需的内存就不必与模型的全部参数规模成正比。

但权重卸载并没有消除成本，而是将原本发生在内存中的访问变成了闪存读取。

读取阻塞计算：专家加载落在关键路径上

每个 MoE 层都需要先由 Router 选择专家，再加载对应权重，最后执行计算。如果这三个步骤串行进行，计算就必须等待权重到位。

以 1 GB/s 的有效读取带宽估算，读取 1.29 MB 专家权重约需 1.29 ms。每个 token 都要经过多层网络，每层又需要加载多个专家，读取的等待会逐层累积。

预取可以让权重加载与当前计算重叠，但这里存在一个关键难点：下一层 Router 的真实输入依赖当前层尚未完成的计算，因此无法直接提前获得下一层的真实专家选择。

系统需要在真实路由结果产生之前预测可能使用的专家，并合理安排权重读取与计算的执行顺序。前者决定哪些权重值得提前加载，后者决定如何尽可能隐藏读取延迟。

单 token 计算密度低：每轮执行的有效产出有限

常规自回归解码每步只处理一个新 token，计算规模相对有限，难以充分掩盖闪存读取开销。

即使通过预取减少了等待，模型仍然需要逐层推进，每生成一个 token 都要承担一轮解码的计算和权重访问成本。

因此，系统还需要提高每轮执行的有效产出，借助投机解码让一次目标模型执行有机会接受多个候选 token，并在验证成功时一次生成多个输出 token，从而降低每个输出 token 分摊的执行成本。

LES 总览

LES 是面壁智能为 MiniCPM-V 4.7 35B-A3B 端侧部署设计的推理优化方案，支持 iOS、Android 和 HarmonyOS 等端侧平台。

LES 从三个层面解决上述问题：

调度层：提前预测下一层可能使用的专家，让权重读取与计算重叠，并优先执行权重已经就绪的专家。

存储层：通过连续专家布局减少分散读取，通过混合精度量化降低权重体积和传输量。

计算层：通过 DSpark 批量验证候选 token，提高每轮目标模型执行的有效输出。

三层优化相互配合：调度层尽可能隐藏剩余的读取延迟；存储层减少读取量、提高读取效率，让更多权重能够在计算窗口内到达；计算层则进一步降低每个输出 token 分摊的成本。

调度

用上一层的输入预测下一层的专家

图2 前瞻专家调度策略

现有的专家预取方案中，一类方法根据离线统计的专家选择规律建立查找表，在线查询后提前加载权重。这类方法依赖统计数据与实际推理分布的一致性，模型或任务分布发生变化时，可能需要重新校准。

另一类方法复用模型自身的 Router 预测相邻层的专家，相关思路也曾用于 GPU 显存与主机内存之间的专家搬运。但手机闪存卸载面临不同的系统约束：内存与显存之间的传输带宽通常远高于手机闪存的有效读取带宽，而端侧统一内存的余量也更加有限。一次错误预取带来的额外读取，或者一次未命中造成的等待，都可能直接影响解码速度。因此，端侧 MoE 不仅需要预测专家，还需要围绕预测结果设计完整的读取与计算调度机制。

LES 复用模型自身的 Router 进行预测，不需要额外训练预测器。其依据来自残差网络的结构：对于相邻两层，后续层的输入包含前一层的输入以及前一层的计算更新，因此相邻层的表示具有相关性。LES 利用这一性质，将当前层 Router 的输入提前送入下一层 Router，在当前层专家仍在计算时，获得下一层的候选专家，并立即发起闪存读取。

需要强调的是，预测结果只用于决定提前加载哪些权重。下一层的真实 Router 输出产生后，仍由真实路由决定最终执行的专家。预测错误不会改变实际参与计算的专家集合，也不会改变真实路由权重的使用方式。

LES 以此将专家预测与实际路由分离：预测负责争取加载时间，真实 Router 负责保证计算正确性。同时，复用已有的 Router 权重，也避免了为每个模型单独训练预测模块。

实测中，候选专家的召回率约为 80%。将候选集合从 top-k 扩大到 top-2k，召回率可提高约 15%，但读取量和缓冲区占用也会相应增加。我们采用 top-k 作为默认配置，在预测覆盖率与额外读取开销之间进行权衡。

就绪的专家先算

预测只能提高提前加载到正确权重的概率，不能保证真实 Router 选中的所有专家都已就绪。因此，即使采用前瞻预取，部分专家仍可能需要等待闪存读取。

例如，预取了专家 A、B、C，而真实 Router 最终选中了 A、C、D。此时 A、C 已经在内存中，D 仍在闪存中读取。如果系统必须等到 D 到达后才开始计算，A、C 明明可以先算，却只能空等。

LES 采用就绪优先的执行策略：先计算已经就绪的 A、C，同时继续读取 D；待 D 到达后，再完成剩余计算。B 虽然被提前读取，但不会参与本轮实际计算。

最终执行的仍然是 A、C、D，专家选择、路由权重和输出合并均遵循真实 Router 的结果。LES 改变的只是权重准备时机和就绪任务的执行顺序，让原本可能被读取阻塞的计算尽可能提前开始。

缓存窗口：在内存与吞吐之间取舍

除了预取和就绪优先执行，专家缓存也会显著影响性能。

已经加载过的专家可以保留在内存中，供后续 token 重复使用。缓存窗口 c 表示可用于缓存专家的槽位数量，c = 0 时，专家使用后即释放，仅保留正在使用和加载中的缓冲区。c 越小，内存占用越低，但重复读取的概率可能越高；c 越大，缓存命中机会越多，代价则是更高的内存占用。

在 M4 iPad 上，c = 0 的低内存配置下，推理峰值内存约为 3 GB（包含 KV Cache）解码速度为 9.6–10.7 token/s；当 c = 128 时，峰值内存升至 7.8 GB，解码速度达到 18 token/s。全部专家常驻内存时的吞吐估算值为 21.7 token/s。

可以通过合理分配缓存空间，在内存预算内获得接近更大缓存配置的推理性能，具体窗口大小可以根据设备可用内存进行调整。

存储

调度决定何时读取权重，但读取本身的效率同样重要。LES 从存储布局和量化两个方向优化专家权重访问。

连续专家布局

图3 存储布局优化

推理引擎采用 GGUF 权重格式。我们发现，原生权重布局并不适合以单个专家为单位进行闪存卸载：同一专家的 gate、up、down 三个矩阵位于不同的张量区域，读取一个专家需要进行多次分散访问。

为此，我们按层重新组织专家权重的存储布局，将每个专家的 gate、up、down 三个矩阵连续排列，同时让不同专家的权重也尽可能连续存储。这样，一个专家对应一段连续的文件区域。对于文件位置相邻的多个目标专家，系统可以合并读取请求，以更充分地利用闪存的顺序读取能力，减少分散访问带来的开销。

这一优化不改变专家的计算方式，只改变权重在文件中的组织方式，使存储布局更符合按需加载的执行模式。

混合精度量化

图4 混合精度量化

连续布局提高了读取效率，而量化进一步减少了需要读取的数据量。在闪存卸载场景中，量化的收益不仅是缩小模型文件，还在于降低每次专家加载所需传输的字节数。读取量越小，权重越有可能在当前计算窗口结束之前到达，从而提高前瞻预取的有效性。

我们以 Q4_K_M 量化为基础，采用混合精度量化方案，将专家权重进一步降至 Q3_K，其余权重保留 Q4_K_M，并使用 imatrix 进行校准。

五项 benchmark 平均分从 FP16 的 78.28 变为 78.12，仅下降 0.16 分；权重文件从 Q4_K_M 的 19.7 GB 减少到 14.44 GB，减少 26.7%。这表明，混合精度量化能够显著降低权重存储与传输开销，同时将评测分数变化控制在较小范围内，实现“无损”的效果。

计算

DSpark 批量验证

即使调度和存储优化已经降低了专家读取的等待，常规单 token 解码的计算密度仍然有限。为了进一步提升端到端吞吐，我们适配了 DSpark 投机解码方案（来自 DeepSeek 和北京大学）。

其基本思路是由草稿模块提出多个候选 token，再由目标模型一次性验证多个 token。当候选 token 被接受时，一轮目标模型执行就有机会产生多个输出 token，从而摊薄每个输出 token 所承担的执行成本。

我们将 DSpark 适配到 llama.cpp，相关 PR 已合并至上游。结合 LES 的专家预取与存储优化，批量验证进一步提高了端侧推理的整体吞吐。

实验结果

LES 在多款端侧设备上实现了实时解码。在 iPhone 18 Pro Max 上，实测解码速度超过 20 token/s（Prefill 为 113.6–176.1 token/s，随输入长度变化）。在 M4 iPad 上，实测解码速度为 18.0 token/s（Prefill 吞吐约 110 token/s）。

为评估各项技术的贡献，我们在同一台内存 12 GB 的 iPhone 上逐步加入优化，测试解码吞吐，其中基线是完全按需从闪存读取专家权重。

图5 消融实验

如图 5 所示，基线解码吞吐为 3.38 token/s；加入前瞻专家调度后提升至 6.57 token/s，加入调度优化和存取优化之后提升至 11.34 token/s，加入混合精度量化后达 17.16 token/s，加入 DSpark 批量验证后达 20.51 token/s，完整系统为基线的 6.07 倍。这说明端侧 MoE 推理的瓶颈并不只在于模型计算量，而是内存容量、闪存访问和执行效率共同作用的结果。针对不同瓶颈进行系统级协同优化，才能将模型规模转化为实际可用的端侧性能。

在 M4 iPad 上，推理期间整机功耗为 15.60–18.31 W。扣除亮屏空闲功耗 6.55 W 后，推理带来的额外功耗约为 9.05–11.76 W。在约 25°C 的环境下持续运行 180 秒，设备温升约 1.5°C。

结语

图6 端侧可实时无损运行的开源模型能力（MMMU Val）前沿

LES 将 MoE 模型的真实路由与权重加载调度分离：真实 Router 决定必须执行的计算，调度层负责提前准备权重并优先执行就绪任务，存储层通过连续布局和混合精度量化降低读取成本，计算层则通过 DSpark 批量验证提高每轮执行的有效输出。三层优化协同工作，让 MiniCPM-V 4.7 在有限的端侧内存下实现了超过 20 token/s 的解码速度，同时保留原始模型的网络结构和真实专家路由机制。

LES 的设计并不依赖 MiniCPM-V 4.7 独有的模型结构。其核心思路建立在 MoE 的 Router 机制、相邻层表示相关性，以及专家权重可独立加载的特点之上。因此，这套方案在原理上也可以扩展到其他 MoE 模型。

我们已经开源 LES 的相关实现，包括专家调度、权重存取优化和 DSpark 适配，代码位于 GitHub: tc-mb/llama.cpp-omni，希望为更多 MoE 模型的端侧部署提供可复用的技术基础。

过去几年，MoE 已成为大模型的重要架构，但模型参数规模不断增长，端侧部署仍受到内存容量和权重访问成本的限制。LES 通过系统级优化，让模型不必将全部专家权重常驻内存，也能在需要时及时读取并完成计算，让更大规模的 MoE 模型有机会在用户手中的设备上实时运行。端侧 MoE 由此从不可能变为现实，这是端侧智能进入下一个阶段的起点。

本文作者：面壁智能多模态实验室 MiniCPM-V 团队

关于团队

MiniCPM-V 是面壁智能多模态实验室研发的高效端侧多模态大模型系列。实验室由面壁智能联席首席科学家姚远带队，专注于多模态大模型的研发与端侧落地。

自 2024 年 4 月发布以来，MiniCPM-V 系列持续迭代。最新开源的 MiniCPM-V 4.7 实现了在约 3 GB 的低内存配置下流畅运行 35B MoE 模型，并完成多芯片的 Day 0 级适配。截至目前，MiniCPM 系列累计下载量超过 6000 万次。