摘要：端侧跑大模型的瓶颈不是内存大小，是专家权重的加载策略。MiniCPM-V 4.7用LES前瞻专家调度，让35B MoE在iPhone上以3GB内存跑到13+ token/s。靠的不是模型变小，是在计算还没结束的时候，就把下一步要用的权重提前搬进了内存。
一、35B参数，3GB内存
| 设备 | 解码速度 | 内存占用 |
|---|---|---|
| iPhone 17 Pro Max | 13+ token/s | 约3GB |
| iPad Pro 11英寸M4 | 17.39 token/s | 约3GB |
35B完整权重约65.6GiB，大部分存放在SSD上，只把当前工作集加载到内存中。3GB是活跃工作集，不是模型体积。
这不是“跑个阉割版”，是跑完整版。35B-A3B版本在34项基准上领先同档的Qwen3.6-35B-A3B。
二、传统端侧MoE的两个妥协
MoE模型的专家是动态选择的，每一层有多个专家，路由网络根据输入决定激活哪几个。你没法提前知道下一步要用哪几个专家。
传统做法要么把专家数量上限压死，要么固定专家集合。这两种做法都能跑得更快，但会损伤模型能力。
LES的做法是第三种：不砍专家，不固定专家，而是提前预测下一步需要哪些专家。
三、LES的三层机制
核心观察：模型相邻两层的输入特征具有高度相似性。下一层的路由选择在很大程度上可以被预测。
| 层级 | 机制 | 作用 |
|---|---|---|
| 第一层 | 跨层路由预测 | 在当前层计算时，异步启动下一层路由器预测 |
| 第二层 | 异步预取 | 后台线程从SSD预读对应专家权重到内存 |
| 第三层 | 优先级调度 | 已在内存的专家优先计算，未加载的并行加载 |
预测只用于预取和调度，计算仍然严格遵循模型自身的token级路由。任何被预测遗漏的专家，照常加载和使用。LES永远不会让模型“算错”——它只是让计算更快。
四、效果：从2.97到17.39
| 优化阶段 | 解码速度 | 提升 |
|---|---|---|
| 基线 | 2.97 token/s | — |
| 加LES | 9.81 token/s | 3.3倍 |
| 加逐层混合精度量化 | 14.92 token/s | — |
| 加DSpark推测采样 | 17.39 token/s | 5.86倍 |
所有优化都是无损的——输出结果与不做优化的版本完全一致。大多数场景下，LES能提前准备好超过80%的所需专家。
五、一个隐藏的工程细节
LES的效果依赖于两个底层优化的配合：逐层混合精度量化和连续专家存储布局。
量化把专家权重压小，减少从SSD到内存的传输量。连续存储布局则把专家权重重新打包成连续存储，提升闪存上的顺序读取效率。
六、检验你的端侧推理系统
如果你的系统存在“加载-计算串行”问题，GPU有大量时间在等待闪存I/O。测量单次推理中GPU实际计算时间和权重加载时间的比例。如果加载时间超过总时间的30%，你就需要引入预取机制。
三个可迁移的设计原则：
- 利用层间相似性做预测
- 预取与计算并行
- 预测用于调度，不用于计算
七、核心判断
端侧推理的瓶颈不是内存容量，是权重的加载策略。
MiniCPM-V 4.7没有把35B压成3B——它保留了35B的全部能力，只是让大部分权重在大部分时间里不需要待在内存里。如果你的加载策略足够聪明——预测准确、预取及时、加载与计算重叠——你就不需要把模型做小。
查看原文
以上仅为核心速览。完整版包含：LES三层机制完整技术拆解、逐层混合精度量化与连续专家存储布局的工程实现、DSpark推测采样架构深度分析、端侧推理“加载-计算重叠”检验的完整流程、与Qwen3.6-35B-A3B的34项基准完整对比数据、五个边界条件的完整分析。
本文首发于微信公众号「阿Q的AI笔记」，点击下方链接阅读全文：
