機器之心報道

編輯：Panda

用 iPhone 本地跑大模型已經(jīng)不是新鮮事了，但能不能在 iPhone 上微調(diào)模型呢？

最近，蘋果親自上場，用一篇論文展示了其可行性。在這篇論文中，蘋果提出了一種內(nèi)存高效型反向傳播（MeBP）。該方法可在內(nèi)存使用量和計算時間之間提供比零階優(yōu)化（ZO/zeroth-order optimization）更好的權(quán)衡，同時還比 ZO 基線收斂更快、性能更優(yōu)。他們還在 iPhone 15 Pro Max 上驗證了 MeBP 的有效性。

這個蘋果團隊（宋叢崢與 Xinyu Tang）也在論文中表示會發(fā)布一個 MeBP 實現(xiàn)，但其公開的鏈接目前還空無一碼。

• 論文標題：Memory-Efficient Backpropagation for Fine-Tuning LLMs on Resource-Constrained Mobile Devices
• 論文地址：https://arxiv.org/abs/2510.03425
• 倉庫地址：https://github.com/apple/ml-mebp

內(nèi)存高效型反向傳播（MeBP）

在這篇論文中，蘋果團隊的研究重點是使用 LoRA 微調(diào) LLM。因此，主要的內(nèi)存瓶頸在于模型參數(shù)和中間激活值。該團隊的目標是將微調(diào)的內(nèi)存使用量保持在現(xiàn)代移動設備可接受的范圍內(nèi)，例如 PocketLLM 所建議的「低于 1GB」。

使用 MeBP 在設備上微調(diào) LLM 包含三個步驟：

• 壓縮模型基礎權(quán)重（凍結(jié)的參數(shù)）以減少磁盤空間占用
• 編譯包含反向傳播和梯度檢查點的訓練圖（training graph）以優(yōu)化內(nèi)存
• 實現(xiàn)一個內(nèi)存高效的運行時（runtime）來執(zhí)行編譯后的訓練圖。

下面將詳細描述每個步驟。

基礎模型權(quán)重壓縮

在設備上部署 LLM 時，壓縮基礎模型權(quán)重以減少磁盤空間使用是一種常見做法。

在該團隊的實現(xiàn)中，他們對包括嵌入在內(nèi)的非 LoRA 參數(shù)使用了 4-bit 對稱模式 INT4 量化。

梯度檢查點編譯

也就是說，反向圖的輸入是：已被檢查點的激活值、來自前一個檢查點的梯度、以及相應的可訓練權(quán)重；其輸出則是這些輸入的梯度。

隨后，所有塊的前向圖和反向圖被序列化為設備運行時兼容的格式，例如模型中間語言（MIL）表示或 MLX 導出的函數(shù)。

在運行時，這些序列化后的圖將被反序列化并編譯以進行計算。

運行時實現(xiàn)

算法 1 概述了 MeBP 的運行時實現(xiàn)。

模型首先使用 InitializeModel 函數(shù)進行初始化，之后訓練循環(huán)中的每個數(shù)據(jù)點都會調(diào)用 Backpropagation 函數(shù)。在 InitializeModel 期間，壓縮后的基礎模型權(quán)重被內(nèi)存映射（memory-mapped）。為最小化內(nèi)存占用，基礎模型權(quán)重在訓練循環(huán)開始前不會被解壓。相反，它們會在計算需要時才被按需（on demand）延遲解壓和加載。注意，對于支持使用量化權(quán)重進行計算的設備運行時框架，解壓步驟可以被跳過，屆時只需按需加載壓縮后的權(quán)重。

在 Backpropagation 函數(shù)中，系統(tǒng)首先執(zhí)行已編譯的前向子圖（subgraphs）以存儲所有必要的檢查點；隨后，按相反順序執(zhí)行已編譯的反向子圖，使用存儲的檢查點來計算梯度。在前向傳播過程中，這些檢查點被內(nèi)存映射，而不是保留在內(nèi)存中。

在每次前向和反向傳播之前，只有必需的基礎模型權(quán)重會被解壓和加載。如此一來，總內(nèi)存使用量被限制為：所需基礎模型權(quán)重的大小，加上每個子圖中操作的峰值內(nèi)存使用量。這個總和遠小于基礎模型權(quán)重的完整大小。該函數(shù)描述的是單個數(shù)據(jù)點的梯度計算。對于批量輸入，可以使用梯度累積來計算梯度，而不會增加內(nèi)存占用。

在 MeBP 中，內(nèi)存中僅為優(yōu)化器保留一份 LoRA 權(quán)重及其梯度的副本。

對于參數(shù)量從 0.5B 到 4B 的 LLM，LoRA 權(quán)重的大小通常在幾十 MB 的范圍內(nèi)，這在內(nèi)存中存儲是合理的。優(yōu)化器狀態(tài)（例如動量）可以像基礎模型權(quán)重一樣，被內(nèi)存映射并延遲加載。

實驗表現(xiàn)如何？

MeBP 表現(xiàn)如何，還得看實踐，而作為對比的基線，他們選擇了 MeZO，因為它是目前已知的唯一應用于移動設備 LLM 微調(diào)的優(yōu)化方法。該團隊通過服務器端的模擬來評估 MeZO 和 MeBP 的效用（utility），并在移動設備上比較它們的性能。

效用（Utility）比較

配置上，這個蘋果團隊使用了 Gemma-3 和 Qwen-2.5，在 WikiText-2 數(shù)據(jù)集上進行語言建模任務實驗，以此比較一階（FO）優(yōu)化（即通過反向傳播獲得梯度）和零階（ZO）優(yōu)化的效用。該團隊專注于參數(shù)量不超過 4B 的模型，因為移動設備的計算資源有限。該團隊的評估指標是評估集上的損失（loss）和下一 token 準確度。其它配置見原論文，下面重點關(guān)注結(jié)果。

如圖 1 所示，盡管 ZO 的損失和下一 token 準確度呈現(xiàn)收斂趨勢，但 ZO 的收斂速度明顯慢于 FO。FO 方法在最初的 100 步內(nèi)就顯著改善了這兩項指標，而 ZO 在 1,000 步后僅顯示出輕微的改善。即使在 100,000 步之后（即比 FO 多 100 倍的優(yōu)化步數(shù)），對于同一模型，ZO 的測試損失仍然高于 FO，測試準確度也低于 FO。

目前 AI 社區(qū)已經(jīng)提出了幾種方法，可以改善 ZO 方法的收斂速度。該團隊也在 Qwen2.5-0.5B 上使用了這些改進版 ZO 方法進行實驗，結(jié)果見下圖。

盡管這些方法比「純」 ZO 收斂得更快，但其損失和下一 token 準確度仍然劣于使用 FO 微調(diào)的模型。此外，這些方法通常每次迭代需要更多的計算時間，因為它們需要額外的前向傳播來更準確地估計梯度。

效用結(jié)果表明，在語言建模任務的 LLM 微調(diào)上，按「每一步」（per-step）來看，反向傳播的收斂速度明顯快于 ZO 方法。這使得它在計算時間方面更適合移動部署 —— 前提是每個 FO 優(yōu)化步驟都能被高效地實現(xiàn)。

性能比較

蘋果使用 Swift 在 iOS 中實現(xiàn)了 MeBP，并在配備 8GB RAM 的 iPhone 15 Pro Max 上評估了其性能。對于 MeZO 基線實現(xiàn)，其前向圖被拆分為多個子圖，并應用了延遲解壓來減少基礎模型權(quán)重的總內(nèi)存使用。每個 MeZO 優(yōu)化步驟涉及兩次前向傳播。其它設置見原論文。

結(jié)果見下表。

總體而言，與 MeZO 相比，MeBP 每個梯度步驟的計算時間要多 43% 到 94%。但是，正如前面的效用對比所示，MeZO 所需的步數(shù)是一階優(yōu)化的 10 倍到 100 倍以上，因此在時間方面，MeBP 的收斂速度要快得多。在最壞情況下，MeBP 的內(nèi)存使用量比 MeZO 多出 20%，但其總訓練內(nèi)存使用量比以往的移動設備實現(xiàn)大約小 10 倍。所有測試的 LLM 均可在 1GB 內(nèi)存內(nèi)高效微調(diào)，使其適合在手機上進行后臺訓練。

此外，該團隊還測試了解壓開銷與序列長度的影響，并還分析了每一層的性能；詳見原論文。