以下是用通俗易懂的语言和日常类比对论文《Lever：智能手机上的推测式大语言模型推理》的解释。
核心难题：自行车上的“沉重行李箱”
想象一下，你想骑着一辆自行车（你的智能手机）穿越一个国家。你有一个非常沉重且高品质的行李箱（一个功能强大的大语言模型，即 LLM），里面装有你所需的所有知识。
- 问题所在： 自行车的篮子很小（手机的快速内存，即 DRAM），无法装下整个行李箱。
- 目前的权宜之计： 你不得不把行李箱放在后备箱里（手机的慢速闪存）。每次你需要迈进一步（生成一个词）时，都必须停下来，打开后备箱，取出你需要的那一页，阅读后，再把它放回去。这种“走走停停”的方式极其缓慢。这就像试图在不停地停下来翻找后备箱的情况下骑自行车。
核心思路：通过“猜测”来节省时间
这篇论文介绍了一个名为 Lever 的系统。它使用了一种称为 推测解码 的技巧。
把它想象成一个 猜谜游戏：
- 小助手（草稿模型）： 你有一个坐在自行车篮子里（位于快速内存中）的小而快的助手。这位助手擅长猜测接下来会发生什么。
- 大老板（目标模型）： 放在后备箱里的那个沉重行李箱就是“大老板”。它非常聪明，但访问速度很慢。
- 策略： 不再每次只向大老板索要 一个 词，而是让小助手快速猜出一整句话（或一棵可能的句子树）。然后，你只打开后备箱 一次，问大老板：“我猜的这些对吗？”
如果大老板说：“是的，前三个词猜对了”，那么你就用一次去后备箱的行程换来了三个词。这节省了巨大的时间。
三大障碍（以及 Lever 如何解决它们）
作者们意识到，虽然这种“猜测”的想法在强大的服务器上效果很好，但在手机上却因三个具体原因而失效。以下是 Lever 解决这些问题的方法：
1. “树的大小”困境（草稿生成）
- 问题： 如果小助手猜的词太少，你仍然不得不过于频繁地打开后备箱。如果猜得太多，手机的“大脑”在尝试检查所有这些猜测时会不堪重负，导致速度变慢。
- Lever 的解决方案： Lever 就像一个 聪明的园丁。它不会随意生长出一丛猜测的灌木。它会仔细计算：“这一枝猜测值得花费精力吗？”它只生长那些可能被接受且检查成本不会过高的分支。它构建了一棵“大小完美”的猜测树，在速度和准确性之间取得平衡。
2. “徒劳无功”的问题（验证）
- 问题： 即使有一棵不错的树，大老板也可能不得不检查一条最终被证明是错误的分支。在手机上，检查错误的分支是对宝贵电池和时间的浪费。
- Lever 的解决方案： Lever 在大老板的思考过程中半路安装了一个 交通指挥员（一个轻量级预测器）。在大老板读完整句话之前，交通指挥员会观察线索并说：“嘿，这一枝看起来不对；停止检查它！”这避免了手机做不必要的工作，但它足够谨慎，绝不会丢弃正确的答案。
3. “工具不匹配”的问题（执行）
- 问题： 智能手机拥有不同类型的“大脑”（CPU 和 NPU）。NPU 擅长同时为许多事物进行数学运算，但它讨厌处理奇怪、不规则的任务。猜谜游戏往往是不规则的。
- Lever 的解决方案： Lever 就像一个 聪明的项目经理。它知道何时使用快速的 NPU，何时使用灵活的 CPU。
- 它将相似的猜测分组，以便 NPU 能高效地处理它们（就像工厂的流水线）。
- 它将最终的“决策”（确定实际选择哪个词）留给 CPU，这样 NPU 就不会浪费能量去计算那些永远不会被使用的路径的答案。
结果
该论文在真实的智能手机（如一加 12）上对各种 AI 模型测试了 Lever。
- 与旧方法相比（为每个词都打开一次后备箱）：Lever 的速度快了 2.93 倍。
- 与其他专为服务器设计的猜测方法相比：Lever 的速度快了 1.50 倍。
总结
Lever 是一个能让你的手机运行巨大、智能的 AI 模型而不会卡死的系统。它通过利用一个小型、快速的“猜测”模型来承担繁重的工作，同时精心管理那个缓慢、沉重的“检查”模型，使其不浪费时间和电池，从而实现这一目标。它将一个缓慢、走走停停的过程转变为了平稳、高效的骑行。
技术摘要：Lever——智能手机上的推测性大语言模型推理
问题陈述
在智能手机上部署高质量大语言模型（LLM）的根本制约因素是 DRAM 容量有限。尽管最先进的模型包含数十亿个参数，但商用智能手机通常仅提供约 10 GB 的 DRAM，其中很大一部分需与操作系统及其他应用程序共享。虽然将模型权重卸载到闪存可以支持更大的模型，但这引入了严重的性能瓶颈：自回归解码需要反复调用模型，而为每个生成的 token 从闪存加载权重会导致不可接受的 I/O 延迟。
现有的推测性解码方法（使用小型草稿模型提出 token，并使用大型目标模型进行验证）并不适合这种环境。这些方法是为服务器级硬件设计的，在该环境中两个模型均驻留在高带宽内存中，且验证过程可利用充足的并行性。而在移动设备上，这些方法之所以失效，是因为：
- 受限于闪存的通信：验证过程需要从闪存加载目标权重，使得 I/O 延迟成为主导成本，而非计算成本。
- 受限于并行性的计算：移动 NPU 提供的并行性远少于服务器 GPU，使得大型 token 树的验证在计算上代价高昂。
- 不规则的执行：Token 树推测引入了不规则的分支和动态结构，这与专为移动 NPU 优化的固定、规则的张量操作并不契合。
方法论：Lever 系统
作者提出了 Lever，这是一个端到端系统，专门针对 DRAM-闪存异构内存层级以及移动 CPU-NPU 硬件，联合优化推测性解码的三个阶段（草稿生成、验证和执行）。
1. 移动设备优化的草稿构建
Lever 重新定义了 token 树的构建目标。与服务器端方法最大化草稿 token 的接受率不同，Lever 优化的是单位推测周期延迟内的预期输出 token 数量。
- 增益 - 成本建模：Lever 估算每个潜在树扩展的边际增益（token 被接受的可能性）和边际成本（草稿生成延迟 + 目标验证延迟）。
- 贪婪扩展：利用贪婪算法，Lever 通过选择具有最高增益 - 成本比的前沿线节点来扩展 token 树。这确保了树的大小保持平衡：足够大以分摊昂贵的闪存 I/O 成本，又足够小以避免因过度的验证开销而压垮移动计算资源。
- 自适应停止：当下一个最佳候选的边际增益低于当前树的平均增益率时，扩展即停止，从而避免了固定的预算限制。
2. 基于预测器的验证剪枝
为了缓解在移动 SoC 上验证大型 token 树时的计算瓶颈，Lever 引入了一种早退机制。
- 中间预测器：一个轻量级神经网络预测器被附加到目标模型的中间层。它根据隐藏状态对草稿分支进行评分，以预测哪些分支可能通过最终验证。
- 影子候选与归一化：为了确保即使父节点子节点较少时评分依然可靠，Lever 在归一化过程中包含了“影子候选”（不在树中的草稿 token）。这防止了单子节点获得 trivial 的高分。
- 保守剪枝：预测得分较低的分支在遍历剩余目标层之前被剪除。保留一条“主干路径”以确保树保持深度，并设置安全机制防止过度激进的剪枝导致丢弃有效序列。这减少了验证计算量，同时保持了输出正确性，因为最终 token 的接受仍由完整的目标模型决定。
3. 硬件混合执行加速
Lever 重构了执行流程，以最大化 CPU 和 NPU 的利用率。
- 感知批次的草稿生成：虽然草稿生成本质上是 CPU 受限的，但 Lever 发现随着 token 树的生长，多个高价值的前沿线节点可以并行扩展。它在 NPU 上以批次方式调度这些扩展以提高吞吐量，同时在 CPU 上处理小型、动态的扩展。
- 验证中的逐层分离：Lever 将 Transformer 层与输出投影解耦。
- NPU：以批次方式执行所有保留节点的 Transformer 层。
- CPU：仅在实际接受的路径上按需执行输出投影（logits 生成）。这避免了为最终被拒绝的分支计算 logits 的冗余计算，这在具有固定批次形状的移动 NPU 上是周期浪费的主要来源。
主要贡献
- 系统级分析：该论文指出，移动设备上的推测性解码需要从算法优化转向算法与系统的协同设计，具体解决闪存 I/O 延迟、有限并行性和不规则执行模式之间的权衡问题。
- Lever 系统：一个集成了三个优化组件的新颖系统：
- 面向移动设备的 token 树构建的增益 - 成本目标。
- 基于预测器的剪枝机制以减少验证计算。
- CPU-NPU 混合执行策略，最小化冗余计算并最大化硬件利用率。
- 全面评估：广泛的实验证明了 Lever 在多种模型（Llama-3.1-8B、Qwen3 变体）、任务（代码、数学、对话）和硬件平台（Snapdragon 8 Gen 3、8 Elite）上的有效性。
结果
评估在商用智能手机（OnePlus 12、Honor 500 Pro、Honor Magic V5）上使用 Q4_0 量化模型进行。
- 延迟降低：与基线闪存卸载自回归推理（Flash-AR）相比，Lever 将推理延迟平均降低了 2.93 倍。
- 优于推测性解码：Lever 比传统推测性解码方法（Chain-SD）实现了 1.50 倍 的加速，比移动专用基线 EdgeLLM 实现了 1.27 倍 的加速。
- 效率：该系统成功缩小了基于闪存的推理与基于内存的推理之间的延迟差距。消融研究证实，所有三个组件（草稿优化、剪枝和混合执行）对于实现这些增益都是必要的。
- 鲁棒性：Lever 在不同的 DRAM 预算（DRAM 中 0% 到 100% 的层）、不同质量的草稿模型以及不同的输出长度下均保持了性能。
意义
该论文声称，Lever 证明了直接在智能手机上运行高质量、大参数 LLM 而不依赖云服务器的可行性。通过将推测性解码视为一个系统问题而不仅仅是算法问题，Lever 有效地管理了移动存储层级和异构计算单元的限制。这使得交互式、隐私保护且成本效益高的 LLM 应用（如打字辅助和交互式编辑）成为可能，而这些应用此前因内存和延迟限制而难以实现。
每周获取最佳 machine learning 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。