MiniCPM LES 将 35B MoE 带上手机，无需限制专家

MiniCPM 表示，其 LES 调度技术可帮助一款 350 亿参数模型在 iPhone 18 Pro Max 上实现每秒生成 20.51 个 token。MiniCPM LES 解决了一个具体障碍：在不限制模型哪些部分能够参与运行的前提下，足够快地将模型权重载入内存。

这一区别对 MoE，即混合专家架构，至关重要。该架构会激活选定的参数组，而非为每个 token 使用完整模型。MiniCPM-V 4.7 的 35B-A3B 标识表示其总参数量约为 350 亿，活跃参数量为 30 亿。较低的活跃计算量并不意味着无需存储和访问其余权重。

核心博弈在于：既保留动态专家选择，又降低加载延迟。Apple 早期关于基于闪存推理的研究提供了一个有益的参考点：存储可以扩展有限的内存，但数据移动需要谨慎管理。MiniCPM 的贡献瞄准了这一更广泛问题中的专家调度环节。其已发布结果同样需要谨慎归因：最高的手机端速度结合了多项优化，“无损”的含义也应比标题所暗示的更为有限。

MiniCPM LES 将专家加载转化为调度问题

这一变化的实际意义在于：它尝试在缩短权重等待时间的同时，保留模型原始的专家选择。

团队的 35B model card 描述了一种保留 token 级路由的部署方式，即为每个生成 token 选择专家的过程。该页面还报告了一项独立结果：在约 3 GB 内存条件下，模型在 iPhone 17 Pro Max 上的速度超过每秒 13 个 token。

这项较早的手机端结果应与较新的 iPhone 18 Pro Max 基准测试区分开来。两者涉及不同设备和已有文档记录的配置。将它们视为可互换的结果，会掩盖公开证据实际能够证明的内容。

LES 是 Lookahead Expert Scheduling 的缩写，即前瞻式专家调度系统。它会预判模型下一层将需要哪些专家，目的是将加载工作提前。该预测有助于安排计算，但不会取代模型最终的专家选择。

从应用开发者的视角看待部署问题：一个助手可能拥有足够的计算能力来生成答案，却仍然很慢，因为它的下一步操作缺少必要权重。当算术运算在等待数据时，让算术更快意义有限。

将所有专家都保留在工作内存中可以避免这一特定延迟，但会占用更多内存。将权重保存在存储设备中可减少常驻内存占用，却会引入加载工作。限制可用专家能简化访问流程，但可能改变生成答案所依赖的计算。

MiniCPM 提出的路径保留了对完整专家池的访问，并管理权重到达的时机。这形成了不同的工程目标：关键问题变成，是否能在已进行的计算期间，让足够多的必要数据及时到达。

这正是该调度公告值得关注、而不仅是模型规模标题的原因。仅凭手机上的大参数量，无法说明响应能力。加载与执行的安排决定了这种能力能否支撑交互式应用。

对用户而言，这一区别体现为连贯性。一个开始输出文本后又反复停顿的答案，与一个输出更稳定的答案，体验截然不同。平均生成速度捕捉了部分体验，但延迟出现的顺序同样重要。

因此，其实际意义取决于运行时，即负责执行模型的软件。仅靠模型权重无法证明每个兼容应用都能复现相同行为。相关部署由模型、存储安排、调度实现和数值配置共同构成。

这一组合系统才是该主张的实际对象。它为调查提供了具体基础，同时无需接受发布公告附带的所有夸张表述。

保留专家选择给移动部署捷径带来压力

直接压力落在那些通过缩小模型可用专家池来提升速度的部署策略上。

当内存和加载时间主导应用资源预算时，限制专家会显得颇具吸引力。可用权重越少，潜在加载需求也越少。难点在于，影响专家可用性的优化同样可能影响模型行为。

这形成了开发者需要明确作出的决策：他们是在优化原始模型的执行方式，还是在部署一条修改过的计算路径？两种方法都值得评估，但其质量主张需要不同的证据。

调度系统承诺提供一种有用的分离方式。开发者可以在保持模型选择机制不变的前提下研究执行效率。这使得识别一项变化究竟影响速度、答案质量，还是两者都受影响，变得更容易。

它也改变了与小型模型的比较方式。一个能够常驻内存的紧凑模型可以提供更简单的部署路径。一个以流式方式加载的较大模型，则需要通过相关任务上更好的结果，来证明其额外的存储与运行时复杂性具有合理性。

两条路径都不会仅凭参数量取胜。一个从熟悉文档中提取简短字段的应用，相比更广泛的推理能力，或许更受益于可预测的延迟。一个解读陌生图表的系统，则可能更重视答案质量。

这些是部署场景，并非 MiniCPM 已验证的客户成果。它们说明了为什么同一基准测试可能支持不同的产品决策。其价值取决于用户提出什么问题，以及应用能够容忍哪些失败。

历史比较同样具有启示意义。Apple 的 flash-based inference research 探讨了如何通过选择性加载和更高效的存储访问，在超出可用工作内存的条件下运行模型。其方法与 LES 不同，但共享的限制条件都是数据移动。

这一先例恰当地限定了新颖性主张。利用闪存存储来支持更大模型已有成熟的研究历史。当前所考察的具体贡献，在于预判专家需求并协调其执行。

对于移动硬件团队，这一框架将注意力重新引向完整的内存与存储路径。计算能力依然重要，但部署可能在达到算术运算极限之前就发生停滞。孤立评估处理器会忽略这种可能性。

对于应用团队，这提出了一个采购问题。具备吸引力计算规格的设备，仍需针对预期运行时和工作负载进行测试。存储行为、可用内存和运行条件都会成为应用性能特征的一部分。

因此，竞争层面的含义是一项工程要求，而非已宣告的市场胜利。替代方案需要展示，在可比条件下它们如何平衡质量、响应能力与资源使用。MiniCPM 也需要达到同样标准。

如果该调度方法能够稳定复现，那么将专家限制视为自动且必要的做法就更难成立。它仍是一种设计选择，其质量代价和性能收益应当清晰可见。

MiniCPM LES 如何在隐藏加载延迟的同时保留路由

LES 使用预测来准备计算，而实际路由器仍负责选择要运行的专家。

官方 expert scheduling documentation 描述了跨层预测和后续预取：在执行到达之前，先加载可能需要的权重。被正确预判的专家会优先运行，其他所需专家则与该计算并行加载。

因此，预测失误会带来额外等待，而不是允许跳过必要专家。这一区别解释了团队关于无损调度的主张：它关乎保留专家参与，而非假定预测总能匹配最终选择。

该文档还描述了连续排列权重、减少分散读取，以及采用按层混合精度。量化，即以降低后的数值精度表示权重，可降低存储和传输需求。这些变化针对加载问题的不同部分。

这一机制暗示了若干有用影响，尽管它们仍需在实际部署中测量。仅凭预测准确率无法确定总体收益。即使预测正确，若权重到达得太晚，也可能只节省很少的等待时间。

同样，提前加载正确的权重只有在设备能够重叠进行有效工作时才有帮助。如果另一种资源成为限制因素，同一调度器可能带来不同增益。性能属于完整的执行环境。

错误预测同样值得关注。即便专家选择保持不变，预取不必要内容仍会消耗资源。有价值的问题是，在具有代表性的请求中，所避免的延迟是否超过了这些额外工作。

这使工作负载选择成为评估的核心。基准测试应当揭示调度表现良好的情形，以及其遇到困难的情形。缺少这种分布信息的平均值，可能掩盖影响应用可靠性的模式。

例如，文档助手可能在一次会话中遇到熟悉版式，在另一次会话中则面对不寻常的视觉结构。评估者应研究这些变化是否会改变响应能力。该机制给了他们提出问题的理由，但并未确立答案。

该方法还区分了读者容易混淆的两种预测。专家预取预测即将到来的计算会需要哪些权重。推测解码则会起草候选输出 token，供后续验证，关注的是生成过程本身。

MiniCPM 将 DSpark 集成为其推测组件。这带来了另一项提升吞吐量的机会，但也使归因更加重要。被笼统归因于 LES 的加速，可能包含调度、存储访问、数值表示和 token 起草等方面的贡献。

对开发者而言，其概念优势已经足够明确，可以进行测试：保留必要工作，然后重新安排准备与执行，以减少空闲时间。实际挑战在于，如何让这种重新安排在设备的真实约束下产生收益。

这比宣称大模型能够直接装进小规模内存分配更有力也更具体。它指出了实现所针对的等待时间，以及其声称保留的模型行为。

每秒 20.51 个 Token 的结果结合了多项优化

已发布的手机端结果属于完整的优化栈，而非仅归功于前瞻式调度。

OpenBMB 的端侧基准测试列出 iPhone 18 Pro Max 配备 12 GB 设备内存。详细结果显示，基线速度为每秒 3.38 个 token。前瞻调度可达 6.57；进一步的调度与加载改动则提升至 11.34。

混合精度量化将报告结果提高到每秒 17.16 个 token。加入 DSpark 后达到 20.51，是基线的 6.07 倍。相应的完全优化 iPad Pro M4 结果为每秒 17.39 个 token。

这些数据支持一种明确解读：最终结果由多个阶段共同促成。它们并不支持将全部加速归因于专家预测这一单一因素。试图复现这一亮眼数据的开发者，需要掌握每个阶段的相关配置。

基线同样值得严格审视。与未采用这些优化的实现相比，能够证明相对该实现有所提升。但这并不能自动证明其优于所有其他运行时或部署方式。

这是系统基准测试中常见的解读问题。较大的相对增幅可以与并不高的起点并存。读者既需要绝对结果，也需要清楚了解具体改变了什么。

手机的总内存回答的问题，也不同于模型所报告的工作内存占用。设备容量描述的是硬件环境；应用内存描述的是在该环境中消耗的资源，且取决于测量方法。

持久化存储还增加了另一维度。官方的量化模型文件将 Q4_K_M 变体列为 21.2 GB。这一列表说明，较低的常驻内存占用不应被解读为同样小的下载体积。

文件列表并不能证明每项已发布基准测试都使用了这一确切制品。仍需将基准测试与其精确的权重文件进行匹配。否则，开发者可能会在同一模型名称下比较不同的数值表示。

这一区别会直接影响产品决策。移动应用必须兼顾安装、模型更新、可用存储空间和启动表现。某个配置即使在准备完成后生成效率很高，在开始生成前也仍需提供可接受的体验。

解码速度衡量的是解码开始后输出的生成速度。它不应被视为从提交图像到收到有用回答之间的完整时间间隔。输入处理和准备过程需要单独测量。

同样，token 是模型使用的单位，并不等同于固定数量的英文单词。吞吐量数据是在既定条件下提供的技术比较。它不能直接转化为普遍适用的阅读或语音体验。

因此，报告的结果具有意义，但也有边界。它表明该团队称其组合实现可在指定硬件上达到的水平。独立测试应确定这一结果如何迁移到真实的应用会话中。

“无损”需要明确的参照点

保留专家路由支持一项狭义的技术主张；它并不能证明在所有精度设置、任务和设备上都具有完全一致的行为。

对调度描述最有力的解读关乎选择。所需专家仍具备参与资格，预测失误也不会将它们排除在计算之外。这一特性针对的是限制可用专家池所引入的一项特定质量风险。

完整的移动端部署还带来更多问题。量化会改变权重表示。因此，恰当的质量比较需要明确哪一种参考模型和数值配置构成基线。

关于保留路由的主张，不应悄然演变为与更高精度模型的每项输出都一致的主张。这两种表述涉及不同属性。评估者需要分别针对各自属性提供适当证据。

同样，保留某一生成过程并不能证明其回答正确。模型可以按预期执行，却仍可能误读图表、误解请求或虚构细节。运行时保真度和任务准确性需要分别评估。

通过为本分析审阅的来源，尚未确认有人独立复现这一手机基准测试的亮眼数据。该限制并不否定所报告的结果，但会影响读者应以何种信心将其推广。

同样的谨慎也适用于该公司的“首个”表述。要确立优先性，需要明确比较范围并保持定义一致。诸如流畅、实时和无损等术语，在能够支撑普遍性排名之前，需要可测量的边界。

实时性尤其取决于应用场景。流式输出的书面回答可以容忍会打断实时互动的延迟。单一技术吞吐量阈值无法证明其适合每一种界面。

更长时间的会话带来另一项重要测试。评估者应测量重复请求、不断变化的设备条件以及其他应用的竞争活动。这些是关于运行耐久性的问题，而非证明所报告实现必然会发生性能劣化的证据。

回答质量测试应包括用户能够识别的失败情形。以假设的费用处理流程为例，这意味着检查提取出的条目是否与收据一致。在文档分析中，则意味着检查解释是否始终基于所提供的页面。

更广泛的知识工作流还涉及检索，即为回答选择相关存储材料的过程。比较个人知识库的读者，应将这一层与模型生成速度分开评估。更快的输出无法弥补选错源文档的问题。

本地执行同样需要谨慎解读。它提供了一种在设备上处理输入的部署选项，但并未说明成品应用中的每一条数据流。哪些内容保留在本地，取决于应用架构。

这些区别通过使主张可测试而强化了分析。问题不再是“无损移动 AI”听起来是否可信，而是哪些行为保持不变、系统消耗哪些资源，以及哪些测量能够证明这一结果。

MiniCPM LES 为开发者提供了一项可供研究的具体调度主张。是否接受，应以可复现的结果和应用层面的质量检查为依据，并使每项结论与实际测量的属性相对应。

三个信号将表明该方法能否迁移至产品

后续证据应依次关联可复现性、持续使用表现与实现可用性。

第一个信号是拥有可识别制品和设置的独立复现。在接下来的几个月中，有价值的结果应包括精确的模型文件、运行时版本、提示词和测量边界。这些细节将使其他开发者能够检验同一项主张。

复现不应只报告最佳一次运行结果。当团队规划交互式服务时，请求之间的波动同样重要。一致的结果将增强人们对已发布速度代表可用配置的信心。

较低的结果需要解读，而非立即否定。不同的权重文件或设置或许能够解释差距。在匹配条件下可复现的不一致，则会更直接地削弱原始性能主张。

第二个信号是在具有代表性的工作负载上进行持续测试。评估者应跟踪完整请求，从输入提交直至回答完成。他们还应在响应速度之外检查质量，因为更快但错误的输出几乎无法创造产品价值。

移动端 MoE 推理正是在这里从技术演示走向应用决策。一项有价值的评估应展示，在反复的文档或图像请求中，收益是否能够持续。它还应识别在哪些条件下，较小的常驻模型仍然更可取。

跨设备结果将明确其适用范围。在更多硬件上表现出类似行为，将支持其具有更广泛的适用性。结果若集中于狭窄配置，则表明这是更专门化的部署机会。

第三个信号是所需优化栈是否易于集成。开发者需要一条从已发布权重到基准测试背后实现的清晰路径。文档应使必要的运行时和制品选择毫无歧义。

这种可用性很重要，因为兼容性与等效性能是两项不同的成就。加载受支持的模型，并不保证应用启用了每一项调度和存储优化。复现完整配置才是相关的里程碑。

清晰的集成路径将强化这样一种判断：这是一套可复用的移动应用基础设施。即使底层技术仍然可靠，零散的说明或依赖配置的结果也会使采用变得困难。

对于考虑开展试点的团队，恰当的下一步是使用接近真实用户请求的材料进行有边界的评估。应纳入那些能够揭示额外模型容量是否改善回答质量的困难文档和棘手图像。除资源消耗和正确性外，还应测量用户实际经历的等待时间。在评估每项优化时保持参考配置固定，以确保改进仍可归因。MiniCPM LES 值得关注，因为它提供了一种在减少加载延迟的同时保留专家选择的具体方法。在围绕这一亮眼速度构建产品之前，应先确认相同配置能否在目标移动工作流中持续提供可靠回答。