苹果新突破：iPhone上实现大模型高效微调，MeBP技术深度解析

在iPhone上本地运行大型语言模型已逐渐普及，但能否在iPhone上对模型进行微调呢？近期，苹果公司通过一篇学术论文给出了肯定答案。论文中，苹果提出了一种内存高效型反向传播（MeBP）方法。该方法在内存使用和计算时间之间实现了比零阶优化（ZO）更优的平衡，同时收敛速度更快、性能更佳。苹果还在iPhone 15 Pro Max上验证了MeBP的有效性。

苹果团队（宋丛峥与Xinyu Tang）在论文中表示将发布MeBP的实现代码，但目前公开的仓库链接尚未包含任何代码。

论文标题：Memory-Efficient Backpropagation for Fine-Tuning LLMs on Resource-Constrained Mobile Devices

论文地址：https://arxiv.org/abs/2510.03425

仓库地址：https://github.com/apple/ml-mebp

内存高效型反向传播（MeBP）

在这篇论文中，苹果团队专注于使用LoRA技术微调LLM。因此，主要的内存瓶颈在于模型参数和中间激活值。团队的目标是将微调的内存使用控制在现代移动设备可接受的范围内，例如PocketLLM建议的“低于1GB”。

使用MeBP在设备上微调LLM包含三个步骤：

压缩模型基础权重（冻结的参数）以减少磁盘空间占用

编译包含反向传播和梯度检查点的训练图以优化内存使用

实现一个内存高效的运行时间来执行编译后的训练图。

下面将详细描述每个步骤。

基础模型权重压缩

在设备上部署LLM时，压缩基础模型权重以减少磁盘空间使用是一种常见做法。

在该团队的实现中，他们对包括嵌入在内的非LoRA参数使用了4位对称模式INT4量化。

梯度检查点编译

为在MeBP中实现梯度检查点，团队首先将LLM拆分为多个块，确保对单个块（例如一个transformer层）执行反向传播的内存消耗在设备内存限制之内。对于每个产生待检查点激活值的块F，通过对F输出应用自动微分来生成反向图。例如，假设 y = F_i (x, w) 是块F_i的前向图，则在标量s上执行自动微分：

其中E表示最终要优化的损失。接着，可以生成一个反向图

，其中 ⊙ 表示哈达玛积（Hardmard product），而

由反向图 B_{i+1} 输出。

也就是说，反向图的输入是：已被检查点的激活值、来自前一个检查点的梯度、以及相应的可训练权重；其输出则是这些输入的梯度。

随后，所有块的前向图和反向图被序列化为设备运行时兼容的格式，例如模型中间语言（MIL）表示或MLX导出的函数。

在运行时，这些序列化后的图将被反序列化并编译以进行计算。

运行时实现

算法1概述了MeBP的运行时实现。

模型首先使用 InitializeModel 函数进行初始化，之后训练循环中的每个数据点都会调用 Backpropagation 函数。在 InitializeModel 期间，压缩后的基础模型权重被内存映射。为最小化内存占用，基础模型权重在训练循环开始前不会被解压。相反，它们会在计算需要时才被按需延迟解压和加载。注意，对于支持使用量化权重进行计算的设备运行时框架，解压步骤可以被跳过，届时只需按需加载压缩后的权重。

在 Backpropagation 函数中，系统首先执行已编译的前向子图以存储所有必要的检查点；随后，按相反顺序执行已编译的反向子图，使用存储的检查点来计算梯度。在前向传播过程中，这些检查点被内存映射，而不是保留在内存中。

在每次前向和反向传播之前，只有必需的基础模型权重会被解压和加载。如此一来，总内存使用量被限制为：所需基础模型权重的大小，加上每个子图中操作的峰值内存使用量。这个总和远小于基础模型权重的完整大小。该函数描述的是单个数据点的梯度计算。对于批量输入，可以使用梯度累积来计算梯度，而不会增加内存占用。

在 MeBP 中，内存中仅为优化器保留一份 LoRA 权重及其梯度的副本。

对于参数量从 0.5B 到 4B 的 LLM，LoRA 权重的大小通常在几十 MB 的范围内，这在内存中存储是合理的。优化器状态（例如动量）可以像基础模型权重一样，被内存映射并延迟加载。

实验表现如何？

MeBP 的实际表现需要实践检验，作为对比基线，他们选择了 MeZO，因为它是目前已知的唯一应用于移动设备 LLM 微调的优化方法。团队通过服务器端模拟评估了 MeZO 和 MeBP 的效用，并在移动设备上比较它们的性能。

效用（Utility）比较

配置上，苹果团队使用了 Gemma-3 和 Qwen-2.5，在 WikiText-2 数据集上进行语言建模任务实验，以此比较一阶（FO）优化（即通过反向传播获得梯度）和零阶（ZO）优化的效用。团队专注于参数量不超过 4B 的模型，因为移动设备的计算资源有限。评估指标是评估集上的损失和下一 token 准确度。其它配置见原论文，下面重点关注结果。

如图 1 所示，尽管 ZO 的损失和下一 token 准确度呈现收敛趋势，但 ZO 的收敛速度明显慢于 FO。FO 方法在最初的 100 步内就显著改善了这两项指标，而 ZO 在 1,000 步后仅显示出轻微的改善。即使在 100,000 步之后（即比 FO 多 100 倍的优化步数），对于同一模型，ZO 的测试损失仍然高于 FO，测试准确度也低于 FO。

目前 AI 社区已经提出了几种方法，可以改善 ZO 方法的收敛速度。该团队也在 Qwen2.5-0.5B 上使用了这些改进版 ZO 方法进行实验，结果见下图。

尽管这些方法比“纯” ZO 收敛得更快，但其损失和下一 token 准确度仍然劣于使用 FO 微调的模型。此外，这些方法通常每次迭代需要更多的计算时间，因为它们需要额外的前向传播来更准确地估计梯度。

效用结果表明，在语言建模任务的 LLM 微调上，按“每一步”来看，反向传播的收敛速度明显快于 ZO 方法。这使得它在计算时间方面更适合移动部署——前提是每个 FO 优化步骤都能被高效地实现。

性能比较

苹果使用 Swift 在 iOS 中实现了 MeBP，并在配备 8GB RAM 的 iPhone 15 Pro Max 上评估了其性能。对于 MeZO 基线实现，其前向图被拆分为多个子图，并应用了延迟解压来减少基础模型权重的总内存使用。每个 MeZO 优化步骤涉及两次前向传播。其它设置见原论文。

结果见下表。

总体而言，与 MeZO 相比，MeBP 每个梯度步骤的计算时间要多 43% 到 94%。但是，正如前面的效用对比所示，MeZO 所需的步数是一阶优化的 10 倍到 100 倍以上，因此在时间方面，MeBP 的收敛速度要快得多。在最坏情况下，MeBP 的内存使用量比 MeZO 多出 20%，但其总训练内存使用量比以往的移动设备实现大约小 10 倍。所有测试的 LLM 均可在 1GB 内存内高效微调，使其适合在手机上进行后台训练。

此外，该团队还测试了解压开销与序列长度的影响，并还分析了每一层的性能；详见原论文。