Can a smartphone fine-tune a 3B-parameter LLM in one battery charge?

What one battery charge actually buys

The paper's headline claim is a feasibility result, not a speed record. Using an iPhone 17 Pro (model A3523, rated battery energy 55.6 kJ) running MLX through its Swift interface inside a normal iOS application, the authors fine-tune SmolLM3-3B to a typical user within one battery charge. The model is stored at 4-bit precision with a group size of 64, and only LoRA adapters of rank 8 attached to the query and value projections of every block are trained.

The workload is the per-user training stage on the LaMP dataset, specifically the rating-prediction task, where the model predicts the 1-to-5 rating of a user's product review. A training run makes three passes over the user's history at batch size 1, with examples truncated at 1024 tokens. That truncation length is the largest that fits in memory and covers 92% of the records in these histories.

So the answer to the title question is yes, but the phrase "one battery charge" describes a budget, not a guarantee. The measured runs start unplugged at 85% charge, except the 987-record run and one 550-record run, which start from a full charge.

On-device adapters match server-trained adapters

Feasibility alone would be a weak result if the adapters were worse. The paper reports that adapters trained on the phone improve personalization as much as adapters trained on a server. That comparison is the one that matters for the privacy argument: training on the device only removes the need to send user data off the phone if the resulting adapter is not degraded.

The evaluation separates two adapter types. A task adapter is trained once on many users' records to teach the model a task, and a per-user adapter is then trained on top of it from one user's history. To measure a per-user adapter, the authors follow Tan et al. and evaluate on the users with the longest histories per task, who on three of the seven tasks contribute tens to hundreds of queries each.

The paper also compares fine-tuning against retrieval as ways of serving a user. The base model with no retrieval is the baseline; retrieval places the four most relevant records in the prompt and requires no training. On the rating-prediction histories, the task adapter outperforms the base model with retrieval on six of the seven tasks, by 3 to 19 points, with prompts two to five times shorter. The largest gain is on movie tagging, where accuracy rises from 0.278 with retrieval to 0.468 with the adapter. The exception is citation identification, where the model must decide which of two options is correct.

Sustained training halves throughput and schedules do not fix it

The central performance finding is thermal. Sustained training throttles the phone to about half its initial throughput, and none of the pausing or burst schedules the authors tested recovers it. This is a measured result about sustained runs, not a single-step benchmark, and it is the reason the paper frames its contribution as characterizing complete training runs rather than individual steps.

The distinction between per-step time and throughput matters here. Throughput is training tokens processed per second. Where every step has the same length, as in several of the paper's measurement sections, steps per second and tokens per second differ by a constant factor, and the authors report ratios or step times. A reader comparing this paper to single-step measurements should not treat the two as the same quantity.

The scheduling result is also platform-specific. The authors state that their findings on scheduling and on the thermal signal are findings about iOS, which is the more restrictive platform: Android exposes a thermal headroom forecast, performance hint sessions, and foreground services that keep work running in the background.

Almost all of each step runs in the frozen base

The cost of on-device training is decided in the frozen base model, not in the adapter. Every step still runs a forward and a backward pass through the full model, and the backward pass over quantized weights takes most of the step. Nearly all of each training step is spent in the frozen base model, most of it in the backward pass.

The obstacle is software rather than arithmetic. The two contractions need different kernels, and the runtimes the authors audited either have no accelerated backward kernel or, in the case of MLX, had one that was never dispatched. Nine of the ten other runtimes audited do not accelerate the backward pass; ExecuTorch added one concurrently with this work.

What the application controls is the shape of the adapter. Rank changes the cost little, while the number of adapted projections, the adapted depth, and the number of passes over the history change it substantially. No schedule the authors tested lowers that cost.

A never-dispatched MLX kernel and its repair

The most concrete engineering result is a defect in Apple's MLX. MLX had a kernel for the backward contraction over quantized weights that was never dispatched and was incorrect. The defect went unnoticed because no training workload or test exercised that kernel.

The authors' repair, now merged upstream, trains an adapter 1.47x faster on a third less energy. Once dispatched, the backward pass runs at the cost its arithmetic predicts. This is a measured comparison between the repaired and unrepaired runtime, and it is the paper's clearest example of how much of on-device training performance is a software question rather than a hardware limit.

The measurement method behind these numbers is worth noting for interpretation. One training step consists of preparing the batch, constructing the graph, the forward pass, the backward pass, the optimizer step, and readback. The authors time each phase by requesting a result at its boundary, forcing an evaluation, and also time each step without those evaluations because evaluations prevent the runtime from overlapping work. Across the six sequence lengths and both kernels, the six phases sum to 1.02 to 1.08 times the fused step. Kernel-level breakdowns come from GPU captures analyzed in Xcode's Metal debugger, and because the debugger bounds replay resources, a capture of the backward pass samples 12 of the 36 blocks.

Energy numbers come with a coarse gauge

Energy usage is derived from the battery gauge, which reports charge in 5% increments, and is reported net of an idle baseline of 0.26 W, the power the phone draws with the screen on and no training. That 5% granularity is a real constraint on how precisely any single energy figure should be read, even though the relative comparison behind the 1.47x speed and one-third energy result is the paper's own.

Peak memory is read from the runtime allocator at the end of each measurement window. The configuration that makes the run fit is specific: 4-bit affine quantization with group size 64, LoRA rank 8 on query and value projections across 36 adapted blocks, AdamW with learning rate 10^-5 and weight decay 0.01, batch size 1, gradient checkpointing per block, and a maximum sequence length of 1024 tokens. Steps equal three passes over the history, that is, three times its record count.

The five evaluated users hold 405, 448, 500, 550 and 987 records, spanning the range of the 100 longest-history users. A separate evaluation in the paper uses shorter movie-tagging histories with a median of 36 records, which train in a median of 3 minutes. Those two settings should not be conflated: one is the long-history rating-prediction workload, the other is a shorter-history quality check.

Where the conclusion stops transferring

The measurements are of one device and one platform. The authors state this limitation directly, and it bounds how far the thermal and scheduling findings travel: they are findings about iOS on an iPhone 17 Pro, not about mobile training in general. The choice of iOS is deliberate, because the A19 Pro is among the first phone SoCs with matrix units in the GPU cores and MLX offers quantized kernels, automatic differentiation, and lazy evaluation in one code base, so the training loop runs in the same runtime as inference.

The paper's forward-looking suggestions are proposals, not measured outcomes. The authors argue that a runtime supporting training needs the backward contraction over quantized weights as a kernel, and that because the base is frozen, its layout can be chosen at load time for both contraction directions rather than inherited from the inference format. They also suggest an operating system could let training run while the device is charging and off screen, which would remove the battery cost at the price of the 5 to 10% slowdown observed in their plugged-in runs. An adapter runs for hours without a deadline and can save its few megabytes of state at every step, yet iOS grants such work budgets of minutes and no GPU.

The priority is the backward pass, not the adapter

If there is one judgment to carry away from this paper, it is where the optimization effort belongs. The adapter is not the bottleneck: rank changes cost little, while adapted projections, adapted depth, and passes over the history change it substantially, and no schedule tested recovers the throttled throughput. The frozen base model's backward pass over quantized weights is where nearly all of each step goes, and it is where a single repaired kernel produced a 1.47x speedup on a third less energy.

That reframes the practical question for anyone evaluating on-device fine-tuning. The feasibility threshold is already met on current phones within one battery charge, and on-device adapters match server-trained ones on personalization. The remaining gap is a runtime and operating-system gap: whether the backward contraction is dispatched as an accelerated kernel, and whether training is treated as a first-class workload that can be deferred to charging and off-screen periods rather than as a foreground task competing with the battery.

Sources used in this answer