一部手机一次充电能微调30亿参数大模型吗？

一次充电究竟能换来什么

论文的核心结论是一项可行性结果，而非速度纪录。作者在 iPhone 17 Pro（型号 A3523，额定电池能量 55.6 kJ）上，通过 MLX 的 Swift 接口在普通 iOS 应用内运行，将 SmolLM3-3B 微调到典型用户。模型以 4 比特精度存储，分组大小为 64，只训练挂在每个块查询和值投影上的秩为 8 的 LoRA 适配器。

工作负载是 LaMP 数据集上的逐用户训练阶段，具体是评分预测任务，模型预测用户商品评论的 1 至 5 分评分。一次训练运行以批大小 1 对用户历史做三遍遍历，样本截断在 1024 个 token。该截断长度是能放进内存的最大长度，覆盖这些历史中 92% 的记录。

所以标题问题的答案是肯定的，但“一次充电”描述的是预算，不是保证。实测运行在 85% 电量下不插电开始，例外是 987 条记录那次运行和一次 550 条记录运行，它们从满电开始。

端侧适配器与服务器端训练相当

如果适配器质量更差，仅凭可行性就是弱结果。论文报告，在手机上训练的适配器对个性化的提升与在服务器上训练的适配器相当。这一比较对隐私论证至关重要：只有当所得适配器没有退化时，端侧训练才真正免除了把用户数据送出手机的需要。

评估区分两类适配器。任务适配器先在众多用户记录上训练一次，教会模型一项任务；随后在其之上，用单个用户的历史训练逐用户适配器。为测量逐用户适配器，作者沿用 Tan 等人的做法，在每个任务上评估历史最长的用户，其中三个任务上这些用户各自贡献数十到数百条查询。

论文还比较了微调与检索这两种服务用户的方式。无检索的基座模型是基线；检索把最相关的四条记录放进提示，不需要训练。在评分预测历史上，任务适配器在七个任务中的六个上优于带检索的基座模型，提升 3 到 19 分，且提示长度缩短到二至五分之一。提升最大的是电影标注，准确率从带检索的 0.278 升到用适配器的 0.468。例外是引文识别，模型必须判断两个选项中哪个正确。

持续训练吞吐减半，调度无法挽回

核心性能发现与温度有关。持续训练会把手机限速到初始吞吐量的一半左右，作者测试的暂停或突发调度都无法恢复。这是关于持续运行的实测结果，不是单步基准，也是论文把贡献定位为刻画完整训练运行而非单步的原因。

这里必须区分单步时间与吞吐量。吞吐量是每秒处理的训练 token 数。当每一步长度相同时，如论文若干测量章节中的情形，每秒步数与每秒 token 数只差一个常数因子，作者报告的是比值或步时间。把这篇论文与单步测量相比的读者，不应把两者当作同一量。

调度结论也与平台相关。作者明确表示，关于调度和温度信号的发现是针对 iOS 的，而 iOS 是限制更严的平台：Android 提供热余量预测、性能提示会话，以及让工作在后台继续运行的前台服务。

每一步几乎都花在冻结的基座模型上

端侧训练的成本由冻结的基座模型决定，而非适配器。每一步仍要对完整模型做一次前向和一次反向传播，而对量化权重的反向传播占去这一步的大部分。每个训练步骤几乎全部花在冻结的基座模型上，其中大部分在反向传播。

障碍在软件而非算术。两次收缩需要不同的内核，而作者审计的运行时要么没有加速的反向内核，要么像 MLX 那样有一个从未被派发的内核。审计的另外十个运行时中有九个不加速反向传播；ExecuTorch 与这项工作同期加入了一个。

应用能控制的是适配器的形状。秩对成本影响很小，而适配投影的数量、适配深度以及对历史遍历的遍数会显著改变成本。作者测试的任何调度都没有降低这一成本。

一个从未派发的 MLX 内核及其修复

最具体的工程结果是 Apple MLX 中的一个缺陷。MLX 有一个用于量化权重反向收缩的内核，它从未被派发，而且是错误的。该缺陷未被发现，是因为没有任何训练工作负载或测试触发过那个内核。

作者的修复现已合并到上游，训练适配器快 1.47 倍，能耗少三分之一。一旦被派发，反向传播就按其算术所预测的成本运行。这是修复与未修复运行时之间的实测比较，也是论文最清楚的例证：端侧训练性能有多大程度是软件问题，而非硬件极限。

这些数字背后的测量方法值得注意。一个训练步骤包括准备批次、构建计算图、前向传播、反向传播、优化器步和回读。作者在每个阶段边界请求结果以强制求值来计时，同时也在没有这些求值的情况下对每步计时，因为求值会阻止运行时重叠工作。在六种序列长度和两种内核下，六个阶段之和是融合步骤的 1.02 到 1.08 倍。内核级分解来自 GPU 捕获，在 Xcode 的 Metal 调试器中分析；由于调试器限制捕获可重放的资源，一次反向传播捕获只采样 36 个块中的 12 个。

能耗数字来自粗糙的电量计

能耗由电池电量计推导，它以 5% 为增量报告电量，并扣除 0.26 W 的空闲基线，即屏幕开启且无训练时手机的功耗。5% 的粒度是真实约束，决定了任何单个能耗数字应被读得多精确，尽管 1.47 倍速度和能耗少三分之一背后的相对比较是论文自身的。

峰值内存从每个测量窗口结束时的运行时分配器读取。让运行放得下的配置很具体：4 比特仿射量化、分组大小 64、在 36 个适配块上对查询和值投影使用秩 8 的 LoRA、AdamW 学习率 10^-5 与权重衰减 0.01、批大小 1、逐块梯度检查点，以及最大序列长度 1024 个 token。步数等于对历史的三遍遍历，即其记录数的三倍。

评估的五个用户分别有 405、448、500、550 和 987 条记录，覆盖 100 个最长历史用户的范围。论文另有一项评估使用更短的电影标注历史，中位数为 36 条记录，训练中位时间为 3 分钟。这两种设置不应混为一谈：一个是长历史评分预测工作负载，另一个是短历史质量检查。

结论在哪里不再适用

测量只针对一台设备和一个平台。作者直接说明了这一限制，它界定了温度与调度发现的适用范围：这些是关于 iPhone 17 Pro 上 iOS 的发现，而非关于移动训练的普遍结论。选择 iOS 是有意的，因为 A19 Pro 是首批在 GPU 核心中带有矩阵单元的移动 SoC 之一，而 MLX 在同一代码库中提供量化内核、自动微分和惰性求值，使训练循环与推理运行在同一运行时中。

论文的前瞻性建议是提议，不是实测结果。作者主张，支持训练的运行时需要把量化权重上的反向收缩作为内核；由于基座是冻结的，其布局可以在加载时针对两个收缩方向选择，而不必继承推理格式。他们还建议操作系统可以让训练在设备充电且熄屏时运行，这会消除电池成本，代价是其插电运行中观察到的 5% 到 10% 减速。适配器可以无截止时间地运行数小时，并能在每一步保存其几兆字节的状态，然而 iOS 给这类工作的预算只有几分钟且不给 GPU。

优化重点在反向传播而非适配器

如果只带走一个判断，那就是优化努力该放在哪里。适配器不是瓶颈：秩对成本影响很小，而适配投影、适配深度和对历史的遍历遍数会显著改变成本，且没有测试的调度能挽回被限速的吞吐量。冻结基座模型对量化权重的反向传播占去每一步的几乎全部，也正是修复一个内核就带来 1.47 倍加速和能耗少三分之一的地方。

这重新界定了任何评估端侧微调者的实际问题。可行性门槛在当前手机上、在一次充电内已经达到，端侧适配器在个性化上与服务器端训练的相当。剩下的差距是运行时和操作系统的差距：反向收缩是否作为加速内核被派发，以及训练是否被当作一等工作负载、可以推迟到充电和熄屏时段，而不是与电池竞争的前台任务。

本文引用的文献