本文以问答形式，从概念、工程和原理三个层次解释移动端侧微调。若需要查阅真实移动终端及边缘设备上的模型规模、峰值内存、时间、能耗与微调效果，可进一步阅读《调研数据报告：移动端侧微调》。
适合希望了解它是什么、有什么价值、与 RAG 或云端微调有何不同的读者。
适合希望在真实手机上实现、测试或产品化端侧微调的读者。
适合希望理解 LoRA、梯度、量化、checkpoint、MeBP 和零阶优化原理的读者。
移动端侧微调（mobile on-device fine-tuning）是指在手机、平板等移动终端上，使用设备本地数据继续训练（即微调）预训练模型，使模型适应某个用户、任务或环境。它是端侧微调（on-device fine-tuning）的一个子类。
当前是大模型时代，所以这里的“模型”通常指大语言模型（LLM），但移动端侧微调也可以应用于前大模型时代的小模型。我们在本文中主要讨论大语言模型的移动端侧微调。
智能手表、智能家居设备、车机、边缘开发板和个人电脑上的训练都可以归入更广义的端侧微调，但本文不把它们直接等同于移动端侧微调。尤其是 Jetson、Raspberry Pi、MCU 或服务器模拟结果，只能为移动终端方案提供方法参考，不能直接代表手机上的内存、速度、能耗和系统表现。
如果本地数据参与训练，但部分计算、模型资产或中间结果仍依赖云端，本文称为端云协同微调。它与纯本地微调是两种不同的系统形态：前者可以降低移动终端负担，但仍有网络、服务成本和中间表示隐私等约束；后者的数据、计算与参数更新均在设备上完成。本文会讨论两者，但在比较实验结果时保持区分。
- 云端微调：模型参数都存储在云端服务器上，数据在云端进行训练，使用的是云端算力和存储资源。
- 纯本地移动端侧微调：训练数据、模型资产、计算和参数更新均留在移动终端，使用设备本地的算力与存储资源。
- 端云协同微调：移动终端承担部分训练流程，但仍依赖云端计算、模型资产或中间结果传输。
目前，大模型微调仍以云端为主，因为云端算力、内存、存储和训练软件栈更成熟，能够支撑更大的模型、数据集和训练任务。移动端侧微调已经有多项真实手机研究证明可以执行模型更新，但公开证据仍以论文原型和 demo 为主，距离大规模、长期稳定的产品化能力还有明显差距。
虽然微调看起来比预训练简单，但它也属于在训练大模型，仍然需要大量的计算资源和时间。在移动端进行微调面临的主要挑战就是资源限制，具体包括：
- 内存限制：手机的内存空间有限，难以存储和处理大规模模型和数据。这个是移动端侧微调最核心的挑战，影响到了可行性，因为内存如果不够，训练就无法进行，训练程序会直接崩溃。
- 计算资源限制：手机的 CPU、GPU 等计算资源有限，难以支持大规模模型的训练。
- 功耗和散热：手机在进行微调时会产生较高的功耗和热量，可能影响设备的正常使用和寿命。
- 电池续航：微调过程会消耗大量电能，可能缩短手机的电池续航时间。
- 用户体验：手机的主要用途是服务用户日常使用，微调过程可能会占用手机的后台资源，影响用户的正常使用体验。
移动端侧微调的主要价值，不是把云端训练原样搬到手机，而是利用只在设备本地出现的数据完成个性化适配。手机首先是用户日常使用的终端，算力、内存、电量和散热预算都很有限；如果训练数据本来就在云端，通常没有必要再把数据和训练任务下发到手机。因此，移动端侧微调是否成立，首先取决于本地数据是否带来明确且可评测的业务价值。
存储在移动设备上的数据通常是用户的个人数据，可能包含偏好、习惯和历史记录等信息。模型可以通过这些数据进行适配，从而提供更个性化的服务。如果把这些数据上传到云端完成训练，通常需要额外考虑以下问题：
- 数据隐私问题：用户的个人数据需要上传到云端，这可能会涉及到隐私泄露的问题。即使是匿名化的数据，模型也是在云端被多人使用的，他人也可能通过模型的输出被反推回原始数据。
- 网络依赖问题：数据上传、模型更新或云端个性化服务依赖网络，在弱网或离线环境下可能不可用。
- 服务成本与延迟问题：持续在云端维护个性化训练和推理链路会产生通信、计算与存储成本，也可能增加交互延迟。
纯本地移动端侧微调可以缩小上述问题的暴露面：
- 降低数据暴露风险：原始训练数据可以留在本地，但 adapter、checkpoint、日志和评测样本仍需加密、隔离并支持删除；“数据不出端”不等于自动满足隐私要求。
- 降低网络依赖：完成更新后，本地模型或 adapter 可以在弱网、离线环境中继续使用。
- 缩短个性化闭环：用户纠错和稳定偏好可以在设备上形成小规模增量数据并更新模型；是否真正降低端到端延迟，仍取决于推理是否也在本地执行。
在实际应用中，有多种技术可以实现移动设备对用户的个性化，包括：
- 规则：通过代码、配置项或决策树来定义明确的条件—动作关系，为不同的用户存储不同的规则，实现个性化行为。用户可以自己主动设置，属于计算机系统中最基础的个性化手段。
- 缓存/记忆：通过本地数据库、会话记录或摘要来记住用户说过的事实、近期状态或历史选择，通过一些机制（例如检索匹配、输入到大模型提示词等）实现个性化的回答。
- 用户画像：在算法里通过结构化标签、统计特征或偏好分数来描述用户的个性化信息，实现个性化推荐和排序。早期推荐系统常用这个概念。
- 提示词：大模型时代到来后，用户也可以自己在每次请求中附带指令或上下文（即提示词），指定模型的语气、格式、角色或任务约束，实现个性化的输出。但这个个性化方法是临时的，且需要用户主动参与。
- RAG：大模型时代的新技术，通过给大模型外挂文档库、向量索引和检索结果来注入个人资料、私有文档或可更新知识，实现个性化的回答。
这些方案相对于微调的差异如下：
| 技术 | 何时应优先于微调 | 相比微调的优势 | 相比微调的不足 |
|---|---|---|---|
| 规则 | 需求能明确写成条件—动作关系 例如“会议时静音”“夜间不推送” |
不需要样本和训练 执行结果确定 容易解释和审计 |
规则增多后容易冲突或遗漏 每种新情况都需要人工补充处理逻辑 |
| 缓存/记忆 （不用于训练） |
需要准确记住用户明确说过的事实、近期状态或历史选择 | 信息可以直接写入、修改和逐条删除 不必把事实训练进参数 |
只有成功检索并加入上下文才会影响回答 检索错误会带入无关或过期信息 |
| 用户画像 | 偏好可以归纳为明确的标签、统计特征或分数 | 成本低且可控 同一份画像可以供推荐、排序等多个系统使用 |
必须提前设计字段和计算方法 字段之外的信息会被丢失 |
| 提示词 | 要求是临时的、单次的，或者需要立即生效和撤销 | 修改后下一次请求即可生效 无训练和参数管理成本 |
每次请求都要重复携带并占用上下文 效果容易受长对话和提示注入影响 |
| RAG | 需要补充个人资料、私有文档或经常变化的事实知识 | 文档可以独立更新和删除 回答可以保留信息来源 |
效果受召回、排序和上下文长度限制 取回知识不等于改变模型的行为习惯 |
| 微调 （对照项） |
偏好长期稳定、反复出现且难以显式描述 其他方案在同一评测集上仍有明显缺口 |
能把高维行为差异写入参数或 adapter 无需每次携带全部历史 可改变模型处理一类输入时的默认行为 |
需要训练数据、计算资源和可靠评测 更新与删除不如外部信息直接 可能记忆敏感信息或造成能力回归 |
从技术上看，微调和其他个性化手段的最主要的差异是，微调直接改变模型参数，其他手段主要改变模型外部的输入、上下文或决策逻辑。
总之，微调属于个性化技术中表达能力较强但成本较高的一层，并不是所有问题的默认答案。微调可能更适合那些需要长期稳定、反复出现且难以用规则完全表达的个性化需求；对于一些明确、临时或低风险的个性化需求，规则、缓存、画像、提示词和 RAG 可能更适合。实际应用中，应该根据具体的业务场景和需求来选择合适的个性化技术，而不是一味追求微调。
移动端侧微调不能只比较“能否跑通”或单步速度，而应在相同模型、数据、序列长度和训练配置下，同时比较以下指标：
- 微调效果：相对基座模型与规则、画像、提示词、RAG 等强基线，任务指标提升多少，是否出现通用能力回退；
- 峰值内存：应注明统计口径，例如进程 RSS 或运行时工作集；不同口径不能直接横向比较；
- 单步时间与总时间：
step、gradient step和一次参数更新可能不是同一口径。产品判断更应关注达到目标质量所需的总时长； - 能耗：既要记录单步能耗，也要记录完成一次有效更新的总能耗，常用单位为 kJ 或 Wh；
- 温升与降频：持续训练是否导致设备升温、芯片降频或任务中断；
- 系统影响：对前台流畅度、电池续航、存储写入、暂停恢复和失败回滚的影响。
这些指标在公开论文中的报告口径并不统一，具体数值与证据边界见《调研数据报告：移动端侧微调》。
注：作者本人为华为员工，但以下内容仅代表个人观点，站在外部视角的观察，不代表公司立场。以下内容来源全部为公开资料，不涉及内部信息；涉及内部信息、决策的讨论放于内部文档中。
华为公司在移动端侧微调研究上有以下优势：
- 主场优势：华为本身就是手机厂商，拥有丰富的移动端产品线、用户基础，有大量的手机设备和数据可用；
- 差异化应用：移动端侧微调的效果最终要落实到手机应用场景上。华为与一般互联网公司相比，可以同时利用移动终端产品、鸿蒙系统入口和多设备生态，把微调能力接入更多系统级场景，打出差异化。一个案例是字节的豆包手机，因为系统权限受限，遇到了商业上的困难；
- 软硬件协同优势：对移动端训练这种资源极度敏感的环境，华为拥有自主研发的芯片、操作系统、编译器和 AI 运行时，有更大的空间在硬件和软件层面进行协同优化，做出更好的成果。
当然劣势也很明显，主要是公司的大模型能力相对云端大厂仍有差距，搞出绝对意义效果好的端侧微调模型更加困难。
注：作者本人为华为员工，但以下内容仅代表个人观点，站在外部视角的观察，不代表公司立场。以下内容来源全部为公开资料，不涉及内部信息；涉及内部信息、决策的讨论放于内部文档中。
- 直接意义：从业务上看，移动设备（手机、平板等）是华为核心产品线之一，华为公司在移动端背靠大模型的业务主要是小艺，现在不仅是语音助手，已逐渐发展为系统级的 AI agent，和鸿蒙系统深度集成。移动端侧微调最直接可以提升它和鸿蒙系统的个性化服务和体验，从而提升用户满意度和市场竞争力；
- 合规意义：端侧的一个很重要的意义是保护用户隐私保护和数据安全。这一是能满足国内的法律法规要求，二是也能满足国外（如欧盟、美国等）的更严格的合规要求，契合了公司近年来强烈的出海战略需要；
- 技术意义：移动端侧微调的研究可以牵引公司在大模型、移动端 AI、软硬件协同优化等方面的技术积累和创新，形成差异化的技术优势。
注：作者本人为华为员工，但以下内容仅代表个人观点，站在外部视角的观察，不代表公司立场。以下内容来源全部为公开资料，不涉及内部信息；涉及内部信息、决策的讨论放于内部文档中。
个人认为，华为公司要想在移动端侧微调研究上取得可见成果，打法不能像大模型厂商一样死磕打榜，而是得发挥出自身的优势，扬长避短，形成差异化打法。具体来说：
- 和华为特有的场景结合好，先做出可落地的场景，尤其是和鸿蒙系统的 AI 能力这一块结合，而不是浮在理论层面追求通用的效果；
- 把更多精力关注到性能上的优化这一块，利用好公司各部门的软硬件协同优势。
截至 2026 年 8 月，移动端侧微调仍处于从可行性验证走向系统化优化的阶段。多数公开实现仍是论文原型或 demo，尚未形成大规模、可复现的商业化能力。现有真机研究已经证明：
在旗舰手机上采用量化基座、LoRA 或零阶优化、短序列和小 batch 等配置，可以对约 0.5B–4B 规模的模型执行端侧更新。不过，论文报告的“工作集”和“RSS”并非同一内存口径，不能把数百 MB 的运行时工作集与数 GB 的进程 RSS 直接比较；单步跑通也不能证明模型已经收敛或系统可以长期在后台稳定运行。
因此，现阶段更合理的判断是：真实手机上的模型更新已经可行，内存与单步速度也在持续改善；但完整收敛时间、总能耗、温升、后台调度、失败恢复和稳定质量收益仍缺少充分公开证据。具体研究、设备与数据见调研数据报告。
目前支撑移动端侧微调的主要技术包括：
- 模型压缩与优化技术：包括模型量化、剪枝、蒸馏等方法，用于减少模型的存储和计算需求。这些技术早在大模型出现以前就已被广泛研究和应用；
- 参数高效微调（PEFT）：减少微调参数的数量，从而降低内存和计算开销。此系列方法兴起于 2021 年提出的原始 LoRA，后续方法包括 QLoRA、BitFit、Adapter、小任务头等；
- 零阶优化（Zeroth-Order Optimization）：模型训练很大一部分开销来源于反向传播。使用零阶优化方法，即用差商直接估计梯度，可以只进行前向传播而不需要反向传播，从而降低内存和计算需求。这在数学上是非常基础的方法，但在大模型、移动端时代又重新火了起来，代表工作包括 MeZO、MobiZO 等；
- 梯度检查点（Gradient Checkpointing）：模型训练占用的内存大部分来自前向传播每层的激活值需要被存下来用于反向传播。梯度检查点只存每隔几层的激活值，中间层可以在需要时重新计算，来减少内存占用，用时间换空间。此方法背后的思想是来自计算机领域，在大模型前的深度学习时代也常作为技巧被使用；
- 内存映射与延迟加载（mmap / lazy loading）：让权重或模块文件按需映射到内存，避免所有模型资产同时进入运行时工作集。它可能增加缺页和 I/O 开销，而且使用 mmap 后的“工作集”不一定包含所有映射权重页；
- 结构化反向传播（Structured Backward Propagation）：针对 LoRA 和 Transformer 等特定结构推导更精简的反向过程，减少通用自动微分产生的不必要中间量，从而降低内存与计算开销，代表工作是 MeSP；
- 其他优化方法：如 warm-start（从相近的模型状态开始训练）、selective BP（选择性反向传播）等，用于减少总训练工作量。
移动端侧微调不仅是算法和数学问题，还涉及到系统、工程和产品问题。移动端在工程上有一个大问题是，深度学习训练框架（如 PyTorch、TensorFlow、Megatron-LM 等）大部分是为PC、服务器端设计的，在移动端的生态不完善，缺少完整的训练链。为此，业界也出现了移动端侧训练框架、运行时，提供完整的训练链，包括数据管道、模型资产、训练运行时、资源调度、评测与发布、安全治理等，背后的技术主要是开发侧的工程。
移动端侧微调的发展是随着移动设备算力的提升、模型压缩和优化技术的发展而逐步推进的。以 2024 年为分界点，之前学术界和工业界都是提出技术铺路，包括各种模型量化、压缩、蒸馏等技术以及著名的参数高效微调（PEFT）方法，包括 LoRA、QLoRA、BitFit、Adapter 等；当然也会在移动端侧作微调实验，但是都是小模型，对于大模型，大量方法只在服务器 GPU、Jetson 等边缘开发板或仿真环境中验证过可行性，但没有真正落地到手机端。从 2024 年开始，才开始有工作真正在手机端做大模型微调。一开始，研究者主要关注“能否在移动设备上运行微调”，即可行性，主要关注内存占用是否在可接受范围内，因为内存占用超过设备会直接导致程序崩溃。后来在验证可行后，研究者开始关注如何降低微调的内存、时间和能耗，以便在移动设备上实现更高效的微调。以下是具体时间节点：
- 2024 年，Oppo 的研究者开发了 PocketLLM，它在真实 Android 手机 （Oppo）上成功运行了 1.3B 的模型更新，占用内存 6.5 GB，证明了移动端侧微调的可行性。它使用的是 MeZO 的零阶优化方法；
- 2025 年进一步出现了多个工作。MeBP 继续采用精确一阶优化，通过 LoRA、内存映射/延迟加载和梯度检查点等方法降低运行时工作集；XPerT、MobiZO、MobiLLM 则分别探索 warm-start、forward-only NPU 和端云 side-tuning。需要注意，MeBP 报告的工作集不等同于完整进程 RSS，MobiLLM 的主要证据也来自边缘板与端云环境；
- 2026 年，Apple 进一步提出了 MeSP，在这里提出结构化反向传播，达到了比 MeBP 还好的性能水平。其他工作包括 LCSB（使用 selective BP）、FBLayout（优化移动 GPU 的正反向数据布局）等，框架 MobileFineTuner（v2）也在今年提出。今年可以看到有一个小趋势是开始关注系统的优化，而不是单纯的算法优化。
移动端侧训练框架和运行时，是先从移动端侧推理框架和运行时演化而来的。最早的移动端侧推理框架和运行时是 2017 年左右出现的，包括 Google 的 TensorFlow Lite 和 Apple 的 Core ML，主要是为了在移动设备上运行预训练好的模型，解决“能不能在手机上跑大模型”的问题。同时期国内有百度的 Paddle Lite（2019年）、阿里的 MNN（Mobile Neural Network，2019年）华为的 MindSpore Lite（2020年）、腾讯的 ncnn（2017年）、TNN（2020年）等，其中很多都是对应主产品的移动轻量版。后来在这些推理框架和运行时的基础上，大厂纷纷推出了移动端侧训练框架和运行时：Apple 于 2019 年推出了 Core ML 3，支持在 iOS 设备上进行模型训练；TensorFlow Lite、Mindspore Lite 等也在后续版本中加入了训练功能。
这些框架最初面向今天看来规模较小的深度学习模型，训练能力也不能直接外推到移动端大语言模型。进入大模型时代后，MeBP、MeSP、MobileFineTuner 等研究开始围绕大模型的权重加载、反向传播、低比特表示和训练生命周期设计专用运行时；目前这些系统大多仍处于实验或研究阶段。