Research-backed calculator guide

On-Device LLM Battery Cost per Task: Energy, Thermal Throttling and API Fallback

Learn how to estimate on-device LLM battery cost per inference from measured power, runtime, thermal slowdown, battery wear assumptions, and API fallback probability.

What “battery cost” should include

There are three different quantities that teams often call battery cost. They answer different questions.

Energy draw is the physical quantity: watt-hours (Wh) or milliwatt-hours (mWh) removed from the device's battery during the task. If the measurement is taken at the wall while charging, it includes charger and conversion losses and should not be presented as direct battery drain without a stated efficiency adjustment.

Battery fraction is the share of usable pack energy consumed. A 50 mWh task on a device with 15 Wh of usable battery energy consumes about 0.33% of the pack under a simple proportional model. Actual battery percentage displays are smoothed, temperature-sensitive, and not precision instruments, so use an electrical measurement for benchmarking.

Money cost can mean electricity, battery wear, or the opportunity cost of not using a remote API. Electricity is energy in kWh × tariff. Battery wear is a proxy rather than a utility bill: it allocates part of a replacement cost to the energy throughput assumed for the pack. An API fallback cost is a provider charge, if one exists, and belongs in a separate branch.

This separation matters because on-device inference has no per-token cloud invoice by default. It still consumes compute, memory bandwidth, thermal headroom, and battery energy. Google describes LiteRT as an on-device runtime that can deploy models across mobile, desktop, and IoT platforms, with CPU, GPU, and NPU acceleration; for LLMs, LiteRT-LM manages the execution loop, KV cache, and streaming output.^[1] That architecture makes local execution feasible, but it does not make energy a fixed property of the model name.

The measurement model

Use a task boundary that a user can recognize: “summarize this 1,200-word note,” “classify this image and return JSON,” or “draft a 100-token reply.” Record prompt size, requested output cap, actual output tokens, model revision, quantization, runtime, accelerator, device temperature, and whether the run was the first after launch.

Measure a baseline first. Close unrelated workloads, let the device settle, and record foreground power for a fixed interval. Then run the task and measure the same power channel. The simple calculation is:

E_task = (P_active − P_baseline) × t / 3,600

where P is in watts, t is in seconds, and E_task is in watt-hours. If your tool reports joules, use Wh = joules ÷ 3,600. If it reports mWh, divide by 1,000 before applying a tariff.

The subtraction is important. A phone that consumes 2 W while the screen, radio, and foreground app are already active did not spend the full 6 W of an inference run on the LLM. The incremental model-related estimate is the active reading above the comparable baseline. Do not subtract a baseline captured in a different screen, network, brightness, or thermal state and then imply laboratory precision.

For a repeatable test, use at least three to five runs per condition and report the median plus a range or percentile. Separate cold-start load from steady-state generation. The first run may include model loading, memory mapping, cache creation, or accelerator initialization. Those costs are real for a user who opens the feature, but they are not the same as the marginal cost of the tenth task in a warm session.

NVIDIA's power guidance illustrates the instrumentation pattern on Jetson: power modes bound the available resources, while its Power GUI and Tegrastats expose processor use, temperature, power, and logs.^[2] A phone will use different tools, but the principle transfers: log power, temperature, duration, and workload together so a slower warm run is not mistaken for a model-quality change.

From energy to battery percentage and money

Battery percentage is a useful communication output, not the primary meter. Let B_usable be the usable battery energy in Wh. Then:

battery percentage = 100 × E_task ÷ B_usable

For a money model, let r be the electricity tariff in dollars per kWh:

electricity cost = (E_task ÷ 1,000) × r

If you also want a battery-wear proxy, define three assumptions explicitly:

wear proxy = replacement cost × E_task ÷ (B_usable × equivalent full cycles)

This treats one equivalent full cycle as one pass through the assumed usable energy. It is not a manufacturer warranty calculation. Cycle life depends on chemistry, depth of discharge, temperature, charging behavior, age, and the definition used by the test. Use the proxy for scenario comparison and label it as such.

A device-only task cost can therefore be written as:

device cost per task = electricity cost + wear proxy

For a hybrid design:

expected total cost = device cost + fallback probability × API task cost

If the fallback request also has a measurable radio or network energy increment, add that energy to the fallback branch. Do not add a cloud provider's token price to every local task unless a fallback actually occurs or your routing policy deliberately sends both local and remote requests.

Worked cost example

Assume a measured mobile workload with a 42-second task and 140 generated tokens. These are illustrative inputs, not a vendor quote or a claim about a particular phone. The device draws 6.5 W during generation and 1.8 W at the comparable foreground baseline. Assume 15 Wh of usable battery energy, a US electricity tariff of $0.18/kWh, a $100 replacement cost, 800 equivalent full cycles, a 25% fallback probability, and a $0.0004 API price for a fallback task.

At these assumptions, the task uses roughly 0.37% of usable battery energy. The electricity line is less than one-thousandth of a cent, while the wear proxy is about 0.046 cents. That difference is not evidence that battery wear has a universal monetary value. It shows why the model must expose assumptions instead of presenting a single “battery price” as fact.

If the task is repeated 100 times, the proportional battery model yields about 36.5% of the assumed 15 Wh usable energy, before accounting for the device's charge-control behavior and any thermal change. The simple wear allocation is $0.0457 for those 100 tasks. If the device warms and the task takes 55 seconds at the same 4.7 W incremental power, task energy rises to 0.0718 Wh, or 31% above the 42-second case. If warming also raises incremental power to 5.3 W, the energy becomes 0.0809 Wh, nearly 48% above the original case. That is the practical value of measuring thermal states instead of extrapolating from one short run.

How thermal throttling changes the estimate

Thermal throttling is a performance state, not a separate invoice item. It changes the time and power used to complete the same user task. A device may generate the first tokens quickly, then reduce clocks or shift accelerator behavior as temperature or power limits are reached. A longer task can therefore consume more energy even when its token count is unchanged.

Design a thermal test with at least three labels: cold, after the device has been idle; warm, after a defined number of preceding tasks; and sustained, after enough repeated work to reach a stable plateau. Keep the prompt, output cap, runtime, and screen/network condition constant. Report tokens per second, time to first token, total seconds, average incremental watts, temperature, and task energy for each label.

Use the measured warm or sustained value in a production budget when the feature is likely to be used repeatedly. If the app normally performs one short summary every few minutes, a sustained benchmark may overstate the typical case. If it streams long answers continuously, a cold-only result will understate it. That distinction between a brief burst and a continuous session is why the session pattern belongs in the benchmark definition rather than being hidden in an average.

A model-size reduction or quantization change should be evaluated on this full curve. Smaller weights may reduce memory traffic and duration, but a lower bit width is not a guarantee of lower energy on every accelerator. The 2026 mobile study indexed for this query measured energy per generated token across 18 configurations and reported both a non-monotonic relationship between quantization bit-width and energy and an average advantage for batched server inference in its tested setup.^[5] Treat that as evidence to benchmark your target devices, not as a universal phone-versus-cloud ratio.

API fallback and routing policy

Fallback is often introduced for quality, context length, unavailable accelerators, thermal pressure, or an offline-to-online transition. Model it as a policy with observable reasons:

1. Try the local model when the task fits its context, quality, latency, and thermal budget.
2. Stop or switch when a defined condition is reached, such as an insufficient quality score, a temperature threshold supplied by the platform, a timeout, or a missing local capability.
3. Record whether the request completed locally, retried locally, or was sent to the API. Attribute provider charges to the actual branch.
4. Include duplicate-request behavior in the cost ledger. A local attempt followed by a cloud retry can cost both energy and API spend.

AWS describes on-device inference as processing at the data source without dependence on cloud servers, while also describing hybrid patterns in which local processing and cloud integration coexist.^[3] AWS IoT Greengrass provides a comparable edge deployment pattern: cloud-trained models can be deployed to edge devices for local inference, while cloud compute remains available for training or complex processing.^[4] The economic implication is not “local is always cheaper.” It is that the routing policy determines which energy, connectivity, and provider-cost branches occur.

Use an expected-value model only when the fallback probability is measured over a representative workload. If 25% is an early product assumption, call it an assumption. Track it by device class, model version, thermal state, and task type. A single blended fallback rate can hide the fact that older phones fail locally much more often than newer ones.

What to log in a production benchmark

Create one record per completed task. Useful fields include device model, operating-system version, battery state, charger state, ambient temperature if available, model identifier, quantization, runtime and accelerator, prompt and output token counts, start and end timestamps, baseline watts, active watts, temperature samples, completion status, fallback reason, API usage units, and energy measurement method.

The measurement layer should be consistent. A hardware power monitor, platform energy counter, or development-board telemetry can each be valid for a defined purpose, but they are not interchangeable. State whether readings represent the battery, system-on-chip, board, or wall input. Keep charger-connected and battery-only results separate. A wall meter is useful for total household energy, while a battery-side reading is better for the user's battery-fraction question.

Compare successful work, not just generated tokens. A local model that emits 100 tokens but requires a retry is not equivalent to a local model that completes the task once. Use both energy per generated token and energy per successful task, with the latter as the primary product metric. Include quality acceptance, because saving energy by returning an unusable answer shifts cost into rework or fallback.

For broader infrastructure economics, the self-hosted GPU inference cost calculator can model server-side utilization and cost per token. The model pricing comparison helps normalize API prices when the fallback branch uses multiple providers. If a local task still calls retrieval or embeddings remotely, the RAG, embedding and vector database cost calculator helps keep those services visible rather than hiding them inside “local inference.”

FAQ

Is on-device LLM inference cheaper than an API call?

It can be cheaper on a provider-invoice basis because a successful local inference does not create a token charge. That does not make it free. It consumes device energy, thermal headroom, storage, engineering effort, and possibly battery life. Compare the measured device cost proxy with the actual API price for the same successful task, including fallback and retry probability. Do not compare a local token count with an API price unless prompt, output, quality, and completion criteria match.

How do I calculate battery percentage per local LLM task?

Measure incremental energy in Wh and divide it by usable battery energy in Wh, then multiply by 100. For example, 0.0548 Wh divided by a 15 Wh usable pack is 0.365%. This is a proportional energy estimate. The phone's displayed percentage can move in larger or smaller steps because it is an estimate affected by calibration, temperature, and discharge behavior.

Should I use battery capacity in mAh or Wh?

Use watt-hours when comparing devices or tasks because mAh alone omits voltage. If only nominal capacity in mAh and voltage are available, estimate Wh = mAh × V ÷ 1,000, then document that the result uses nominal rather than measured usable energy. For a device benchmark, a battery-side energy measurement is preferable to relying on the label capacity.

How can I include thermal throttling in a battery estimate?

Run the same task in cold, warm, and sustained conditions. Record average incremental watts and elapsed time for each condition, then calculate energy separately. Use the condition that matches the expected session pattern. Do not apply a universal “throttling penalty”; it depends on device cooling, runtime, model, accelerator, ambient temperature, and workload duration.

How should API fallback affect cost per inference?

Multiply the measured probability of fallback by the price of the fallback task and add it to the device-side cost. Track local retries and cloud retries separately because a failed local attempt may consume energy before the API request occurs. If fallback probability is not yet measured, present it as a sensitivity range rather than a precise forecast.

Does quantization always reduce battery cost?

No. Quantization usually reduces weight storage and can change memory traffic, but energy depends on the runtime, hardware backend, kernel implementation, sequence length, and thermal state. Benchmark the quantized candidate on the target devices. The cited mobile study's non-monotonic energy findings are a reminder that fewer bits are a hypothesis to test, not a guaranteed energy ranking.^[5]

Assumptions, exclusions and limitations

This method assumes that the task can be repeated with a stable prompt and output boundary, that a comparable baseline can be measured, and that the energy instrumentation has known units. It estimates marginal energy and clearly labeled monetary proxies. It does not predict a phone's battery gauge, guarantee a battery replacement date, or establish a universal cost for a model family.

The worked example excludes the value of engineering time, model download, storage, device depreciation, network energy for a fallback, privacy/compliance cost, and the carbon impact of manufacturing. It also excludes server-side energy unless a fallback or remote baseline is explicitly modeled. Add those terms when the decision is a full lifecycle or total-cost-of-ownership comparison.

Electricity tariffs and API prices change. The example uses $0.18/kWh and a $0.0004 fallback price as dated scenario inputs, not vendor quotes. Replace them with the tariff and provider price that apply to the deployment, and record the date, currency, billing unit, and tax treatment. Keep source-backed product capabilities separate from your own measured power data.

The practical conclusion is narrow but useful: measure incremental energy per successful task, repeat the measurement after thermal warm-up, and price fallback as an observed routing branch. That produces a defensible estimate of on-device LLM battery cost per inference without pretending that one phone, one tariff, or one benchmark represents every deployment.