调研数据报告：移动端侧微调

汇总移动端侧微调的公开实验数据，洞察出一些结论。
research
Published

August 17, 2026

本文是一份关于移动端侧微调的调研数据报告，汇总截至 2026 年 8 月可获得的公开实验数据，不重复展开移动端侧微调的概念、价值和技术原理。相关术语与背景见我写的知识条目。

移动端侧微调是端侧微调的一个子类，特指在手机、平板等移动终端上，利用设备本地数据在设备上更新模型。严格意义上，移动端侧微调的实验应在真实移动终端上完成，才能直接反映手机可行性、内存、时间和能耗等指标。由于移动终端的资源受限，有些研究使用端云协同，即在本地数据参与训练的同时，部分计算、模型资产或中间结果依赖云端；还有些研究选择在边缘开发板、MCU 或服务器上模拟移动环境，这类实验只能用于判断方法是否具有迁移潜力，不能直接代表手机表现。以下报告将真实移动终端、端云协同，以及边缘板、MCU 与服务器模拟三类实验结果分开呈现，目前只完成了真实移动终端的量化结果整理。

1 真实移动终端量化结果

工作 方法 设备与运行环境 模型与训练配置 峰值内存 时间/能耗 微调效果
PocketLLM (Peng, Fu, and Wang 2024) MeZO（零阶优化）；
无模型量化；
无 LoRA		 OPPO Reno 6（12 GB）；
Android；
Termux Linux 环境；
PyTorch		 RoBERTa-large（0.355B）；
SST-2 情感分类；
Batch size 8 / 64		 约 4.0–4.8 GB 约 83–123 s/step loss 会下降，但收敛速度显著慢于一阶优化
OPT-1.3B；
SuperGLUE 任务		 约 6.5 GB 约 1,800 s/step；
（注：RTX 3090 为 1.99 s/step，手机耗时约为其 905×）
MobiZO (EMNLP Gao et al. 2025) 并行 ZO（该论文提出）；
MP-LoRA（该论文提出）；
无权重量化（但使用 FP16 精度）；
ExecuTorch 集成		 OnePlus 12（12 GB）；
Android；
Hexagon NPU；
ExecuTorch 0.6；
高通 AI Engine Direct 2.28		 TinyLlama-1.1B；
FP16；
LoRA rank 16；
Effective batch size 16；
序列长度 128；
微调任务未报告		 4.49 GB 5.76 s/step 未报告
MeBP (EMNLP Industry Song and Tang 2025) MeBP 内存优化方法（该论文提出）；
精确 BP（一阶优化）；
LoRA；
梯度检查点；
mmap 权重与激活		 iPhone 15 Pro Max（8 GB）；
A17 Pro；
iOS；
Swift 原生实现；
编译子图运行时		 Qwen2.5-0.5B；
冻结基座 INT4；
LoRA rank 16；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 320.17 MB（phys_footprint） 3.85 s/gradient step 未报告
Qwen2.5-1.5B；
冻结基座 INT4；
LoRA rank 16；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 460.24 MB（phys_footprint） 9.09 s/gradient step
Qwen2.5-3B；
冻结基座 INT4；
LoRA rank 16；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 661.78 MB（phys_footprint） 17.96 s/gradient step
Gemma 3-1B；
冻结基座 INT4；
LoRA rank 16；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 569.00 MB（phys_footprint） 9.48 s/gradient step
Gemma 3-4B；
冻结基座 INT4；
LoRA rank 16；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 1,029.49 MB（phys_footprint） 28.58 s/gradient step
MeSP (ACL Industry Park et al. 2026) 结构化 BP（该论文提出），即针对网络结构推导特殊的精确 BP；
LoRA；
梯度检查点		 iPhone 17 Pro（8 GB）；
A19 Pro；
iOS；
MLX		 Qwen2.5-0.5B；
冻结基座 INT4；
LoRA rank 8（Q/K/V/O、gate/up/down）；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 136.2 MB（phys_footprint） 0.86 s/gradient step 未报告
Qwen2.5-1.5B；
冻结基座 INT4；
LoRA rank 8；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 262.6 MB（phys_footprint） 2.17 s/gradient step
Qwen2.5-3B；
冻结基座 INT4；
LoRA rank 8；
Batch size 1；
序列长度 256；
WikiText-2 语言建模		 368.4 MB（phys_footprint） 4.09 s/gradient step
MobileFineTuner (Geng et al. 2026) 原生 C++ Full-FT/LoRA 训练框架（该论文提出）；
无模型量化；
ZeRO 式参数分片与磁盘卸载；
梯度累积；
梯度检查点；
Memory-efficient attention；
能耗感知调度		 华为 P50 Pro（8 GB）；
麒麟 9000；
Android 11；

华为 nova 9 Pro（8 GB）；
骁龙 778G 4G；
鸿蒙 2.0；

原生 C++ 运行时		 GPT-2（0.124B / 0.355B）；
Gemma 3-0.27B；
Qwen2.5-0.5B；
LoRA rank 8；
Batch size 8；
序列长度 256；
WikiText-2；
（可执行性实验）		 未报告（但不会 OOM） 未报告 未报告
iQOO 15（16 GB + 16 GB）；
骁龙 8 Elite Gen 5；
Android 16；
原生 C++ 运行时		 GPT-2（0.124B）；
Full-FT；
Batch size 8；
序列长度 128；
WikiText-2；
（可执行性实验）		 未报告（但不会 OOM） 未报告 loss 与 PPL 稳定下降；
轨迹接近服务器 PyTorch
Qwen2.5-0.5B；
LoRA rank 8；
Batch size 8；
序列长度 128；
MMLU		 约 2,887 MB RSS MMLU；
总时间：25.94 h；
能耗：75.88 kJ		 MMLU accuracy；
微调前 44.25% → 微调后最佳 47.35%；
提升 3.10 个百分点
Gemma 3-1B；
LoRA rank 8；
Batch size 8；
序列长度 128；
MMLU		 约 8,209 MB RSS MMLU；
总时间：142.76 h；
能耗：437.98 kJ		 MMLU accuracy；
微调前 24.60% → 微调后最佳 27.51%；
提升 2.91 个百分点
FBLayout (MobiSys Tam et al. 2026) FBLayout 移动 GPU 布局优化（该论文提出）；
R-Tile（统一前向/反向归约访问的张量布局）；
无模型量化；
移动 GPU 精确 BP		 OnePlus Ace5 Pro（16 GB）；
骁龙 8 Elite / Adreno 830；

OnePlus Ace10 Pro（12 GB）；
骁龙 8 Gen 1 / Adreno 730；

OnePlus Ace5 Ultra（16 GB）；
Dimensity 9400+ / Mali G925；

Android；
MNN + C++/OpenCL		 Llama 3.2-1B；
Batch size 1；
序列长度 512；
微调任务未报告		 未报告 比 MNN 快 3.9–4.1×；
比 TFLite 快 4.3–4.9×；
比 TVM 快 5.4–5.7×；
5 轮能耗低 3.5–6.3×		 与基线一致；
方法不改变模型参数、精度或训练目标
Qwen2.5-1.5B；
Batch size 1；
序列长度 512；
微调任务未报告
Gemma 2-2B；
Batch size 1；
序列长度 512；
微调任务未报告
Note表中术语
  • phys_footprint 与 RSS：MeBP/MeSP 报告的是 iOS/macOS task_info API 的 phys_footprint，MobileFineTuner 报告的是 Android dumpsys procstats 统计的 RSS；两者口径不同，不能直接横向比较。
  • step 与 gradient step：gradient step 表示完成一次梯度计算和参数更新；ZO 论文使用的 step 可能包含多次前向查询，因此不同方法的单步时间不等价。
  • Batch size、Effective batch size 与序列长度：Batch size 是一次处理的样本数；Effective batch size 计入并行查询或梯度累积后的等效样本数；序列长度是每个样本的 token 数。
  • INT4、FP16、LoRA 与 rank：INT4/FP16 表示权重或计算精度；LoRA 只训练插入基座模型的低秩矩阵；rank 是其低秩维度。表中的量化范围以各论文实现为准。

以下是一些可观察的结论，依据上表和论文中提供的其他实验结果整理而来：

  1. 目前手机端侧微调已经可行，内存占用和能耗降到了可接受范围内，但是模型规模仍然受限，训练时间仍然较长。
  • 证据可纵向对比表格中同一工作不同模型的峰值内存、时间和能耗，基本都是较小的模型（0.5B–1B）在手机上可行，而较大的模型（3B 及以上）在手机上仍然需要较长时间和较高能耗，甚至可能 OOM；内存占用普遍在几百 MB 到几 GB 之间；训练速度按照论文汇报的单步时间计算，通常需要数小时到数天才能完成一个完整的训练任务。
  1. 当前公开研究中，“真机能够执行训练”的证据多于“真机完整收敛并稳定提升质量”的证据。
  • 证据1：PocketLLM (Peng, Fu, and Wang 2024) 的手机实验只运行 10 step，以 loss 下降证明可行性；MobiZO (Gao et al. 2025) 的手机实验只做单步 loss sanity check，并报告单步时间和内存，没有报告真机完整训练后的质量；
  • 证据2：MeBP 的 1,000-step/100,000-step 一阶—零阶效用对照在服务器上完成，MeSP 的 100,000-step 收敛实验在 Apple M4 上完成；两篇论文的手机实验主要测量单步时间和峰值内存；
  • 证据3：MobileFineTuner (Geng et al. 2026) 是较完整的例外。它在 iQOO 15 上报告 Qwen2.5-0.5B 的 MMLU accuracy 从 44.25% 提升至最佳 47.35%，总训练时间 25.94 h、能耗 75.88 kJ；Gemma 3-1B 从 24.60% 提升至最佳 27.51%，总训练时间 142.76 h、能耗 437.98 kJ。这既证明真机完整训练可以产生质量收益，也显示当前时间和能耗成本仍然很高。
  1. 模型规模增大后，单步计算时间的增长通常快于经过优化后的内存增长，计算会逐渐成为更突出的瓶颈。
  • 证据1：MeBP (Song and Tang 2025) 在相同 batch size 1、序列长度 256、LoRA rank 16 下，Qwen2.5 从 0.5B 增至 3B 时，峰值内存从 320.17 MB 增至 661.78 MB，约为 2.07×；单步时间从 3.85 s 增至 17.96 s，约为 4.66×；
  • 证据2：MeSP (Park et al. 2026) 在相同 batch size 1、序列长度 256、LoRA rank 8 下，Qwen2.5 从 0.5B 增至 3B 时，峰值内存从 136.2 MB 增至 368.4 MB，约为 2.70×；单步时间从 0.86 s 增至 4.09 s，约为 4.76×。
  1. 一阶优化相对零阶优化内存占用相对较高，受 batch size 影响较大；
  • 证据1：PocketLLM (Peng, Fu, and Wang 2024) 在 OPPO Reno 6 上微调 RoBERTa-large。Batch size 为 8 时，MeZO 占用约 4.6–4.8 GB，Adam 占用约 6.5–6.7 GB；batch size 增至 64 后，MeZO 仍约为 4.0–4.5 GB，而 Adam 直接 OOM。该结果说明，标准一阶训练需要保存反向传播激活值，内存对 batch size 更敏感；
  • 证据2：MobiZO (Gao et al. 2025) 在 A100 上对 TinyLlama-1.1B 做同配置比较。序列长度为 128、batch size 为 1 时，FO Full、FO LoRA-FA、MeZO LoRA-FA、MobiZO 的峰值内存分别为 11.44、4.27、2.10、2.14 GB；batch size 增至 16 后，分别变为 14.76、7.81、2.56、3.05 GB。这个实验不是手机实验，但在统一运行环境下显示，一阶方法的绝对内存和 batch 增长量都更高；
  • 证据边界：该结论不适用于所有经过专门内存优化的一阶实现。MeSP (Park et al. 2026) 在 iPhone 17 Pro 上以 Qwen2.5-0.5B、序列长度 256、LoRA rank 8 测得 MeSP 为 136.2 MB，反而低于 MeZO 的 243.0 MB。也就是说，较高内存是标准 BP 的算法特征，不是优化后一阶方法必然高于零阶方法的定律。
  1. 一阶优化相对零阶优化可能单步计算时间稍长（因为零阶优化没有反向传播），但收敛要快得多，最终质量也更好。
  • 证据1：MeBP (Song and Tang 2025) 在 iPhone 15 Pro Max 上的五组模型实验中，MeBP 每个 gradient step 比 MeZO 慢 43%–94%。例如，Qwen2.5-0.5B 为 3.85 s 对 2.68 s，Gemma 3-4B 为 28.58 s 对 16.86 s；
  • 证据2：同一篇 MeBP 论文在服务器上进行效用对照：一阶优化在约 100 step 内已经明显改善 loss 和 next-token accuracy；零阶优化在 1,000 step 后只略有改善，即使运行 100,000 step，最终 loss 仍更高、accuracy 仍更低。该质量实验不是手机实验；
  • 证据3：MeSP (Park et al. 2026) 在 Apple M4 上训练 Qwen2.5-0.5B 100,000 step 后，MeBP 与 MeSP 的最终 loss 均约为 2.6，MeZO 约为 3.18，即高约 22%。该质量实验不是手机实验。
  1. LoRA rank 决定微调参数数量，从而影响内存占用。
  • 证据1：MeSP (Park et al. 2026) 在 iPhone 17 Pro 上固定 Qwen2.5-0.5B 和序列长度 256，只改变 LoRA rank。Rank 为 4、8、16、32 时，MeBP 峰值内存依次为 355.2、360.8、372.4、395.8 MB；MeSP 依次为 132.8、136.2、143.5、158.2 MB；MeZO 依次为 215.0、243.0、299.0、411.0 MB；
  • 证据2：从 rank 4 增至 32，MeBP、MeSP、MeZO 的峰值内存分别增加约 11.4%、19.1% 和 91.2%。MeZO 增幅最大，是因为更大的 LoRA 参数同时扩大了扰动向量；这也说明“零阶一定更省内存”在较高 rank 下并不成立；
  • 证据边界：该消融实验只报告内存，没有同时报告不同 rank 的最终任务质量，因此只能证明 rank 会增加资源开销，不能据此判断哪个 rank 的质量最优。
  1. 序列长度对内存占用的影响也很明显。
  • 证据1：MeBP (Song and Tang 2025) 在 iPhone 15 Pro Max 上测试 Qwen2.5-1.5B。序列长度从 128、256、512 增至 1,024 时，MeBP 峰值内存依次为 405.14、460.24、624.62、994.09 MB，单步时间依次为 6.92、9.09、17.14、34.40 s；序列长度从 128 增至 1,024 后，内存约增至 2.45×，单步时间约增至 4.97×；
  • 证据2：MeSP (Park et al. 2026) 在 iPhone 17 Pro 上测试 Qwen2.5-0.5B。序列长度从 128、256、512 增至 1,024 时，MeSP 峰值内存依次为 110.7、136.2、245.8、513.6 MB；作为对照，MeBP 为 252.7、360.8、582.4、1,050.3 MB，MeZO 为 199.0、243.0、336.0、524.0 MB。三种方法都随序列变长而增加，内存优化只能降低增长后的绝对值，不能消除序列长度的影响。
  1. 训练框架的原生性对性能也有影响。
  • 证据1：MobileFineTuner (Geng et al. 2026) 在同一台 iQOO 手机上，以 Qwen2.5-0.5B、batch size 8、序列长度 128、LoRA rank 8、α=16 对比原生 C++ 运行时与 Termux + PyTorch。原生运行时的平均 step time 为 107.36 s，Termux 为 489.16 s，即原生实现约快 4.56×；峰值 RSS 分别为 2,395.76 MB 和 3,313.69 MB，原生实现低约 27.7%；
  • 证据2：PocketLLM (Peng, Fu, and Wang 2024) 自身也把 Termux 称为临时方案，并指出它不能充分利用手机硬件、可能存在库兼容问题，也不符合普通移动应用的集成方式。

以上结论给我们一些启发（个人见解）：

  1. 现在移动端侧微调的研究仍处于早期阶段，可以做的事情很多，但又很具有挑战性。可以看到当前手机端侧可训练的模型是很小的（0.5B-4B），可能无法满足实际应用的质量要求；然而模型规模增大后，训练成本上升很快（体现在模型参数量、batch size、LoRA rank 和序列长度，甚至可能因为 OOM 而无法在手机上执行。
  2. 在技术路线选择上，零阶优化可以作为最早期可行性验证和快速原型的手段，但要真正训练出可用模型，还是需要一阶优化。零阶优化的优势在于内存占用相对较低、实现简单、无需反向传播，但收敛速度慢、最终质量不如一阶优化。
  3. 可以看到，这些工作都是既有工程也有数学上的优化，它们同等重要。数学上的优化可以降低内存占用、加快收敛速度、提高最终质量；工程上的优化可以充分利用移动端硬件、降低单步时间和能耗。两者结合才能在移动端实现可行的微调。

2 参考文献

Gao, Lei, Amir Ziashahabi, Yue Niu, Salman Avestimehr, and Murali Annavaram. 2025. “MobiZO: Enabling Efficient LLM Fine-Tuning at the Edge via Inference Engines.” In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. https://arxiv.org/abs/2409.15520.
Geng, Jiaxiang, Lunyu Zhao, Yiyi Lu, and Bing Luo. 2026. “MobileFineTuner: A Mobile-Native Framework for on-Device LLM Fine-Tuning in Real-World Embedded AI Applications.” https://arxiv.org/abs/2512.08211.
Park, Juneyoung, Yuri Hong, Seongwan Kim, and Jaeho Lee. 2026. “Memory-Efficient Structured Backpropagation for on-Device LLM Fine-Tuning.” https://arxiv.org/abs/2602.13069.
Peng, Dan, Zhihui Fu, and Jun Wang. 2024. “PocketLLM: Enabling on-Device Fine-Tuning for Personalized LLMs.” https://arxiv.org/abs/2407.01031.
Song, Congzheng, and Xinyu Tang. 2025. “Memory-Efficient Backpropagation for Fine-Tuning LLMs on Resource-Constrained Mobile Devices.” In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track. https://arxiv.org/abs/2510.03425.
Tam, Kahou, Wei Niu, Yu Bao, Xiaomin Ouyang, Chengzhong Xu, and Li Li. 2026. “FBLayout: Optimizing Memory Layout for Efficient LLM Finetuning on Mobile GPUs.” In Proceedings of the 24th Annual International Conference on Mobile Systems, Applications and Services. https://doi.org/10.1145/3745756.3809214.
Back to top