iPhone 15 Pro Max微调大模型：苹果新逆向传输方案解析

最近，苹果公司亲自下场，通过一篇研究论文展示了在智能手机上微调大语言模型的可实现性。该团队提出了一种创新的内存高效型反向传播机制（MeBP），使得在 iPhone 等移动设备上高效处理模型成为可能。

虽然用 iPhone 本地运行大模型已不算新鲜事，但能否直接在手机上完成模型的精细调优呢？

苹果研究团队的论文详细阐述了一种内存高效型反向传播算法的具体实现。这种名为 MeBP 的方法能在内存占用与计算时间之间实现优于零阶优化器的平衡，同时收敛速度更快、性能更优。他们甚至在 iPhone 15 Pro Max 上实际验证了 MeBP 的有效性。

该论文团队（宋凯仑与 Xinyu Tang）表示将公开发布 MeBP 的实现代码，但目前其提供的 GitHub 链接仍为空，尚未开放访问。

论文标题：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-bit 对称模式的 INT4 量化处理。

梯度检查点编译

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

其中 E 表示最终需要优化的损失函数。随后，可以生成一个具体的反向图，该图通过哈达玛积的方式，结合了由反向图 B_{i+1} 的输出。

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

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

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

运行时实现

算法 1 概括了 MeBP 在运行时的具体执行流程。

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

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

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

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

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

实验表现如何？

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

效用比较

在配置方面，该苹果团队使用了 Gemma-3 与 Qwen-2.5，在 WikiText-2 数据集上进行语言建模任务的实验，以此比较一阶优化器与零阶优化器的实际效用。该团队重点关注参数量不超过 4B 的模型，因为移动设备的计算资源有限。该团队的评估指标是验证集上的损失值和下一 token 预测准确度。其他配置详见原论文，下面重点分析实验结果。

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

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

尽管这些优化过的 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 内存内高效完成微调，使其适合在手机上执行后台训练任务。

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

免责声明

游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

同类文章