Battery Benchmark Method for Local AI

Direct answer

A battery benchmark for local AI begins with a precise workload and a declared measurement source, not a percentage drop copied from a status bar. Freeze the artifact, runtime, backend evidence, input fixture, task sequence, app build, and run duration. Record device model, OS, battery and charging state, screen conditions, network state, thermal context, and other conditions relevant to repeatability. Run a baseline or idle interval using the same setup, then repeat the fixed AI workload; preserve every run, including failed or interrupted attempts. Without raw records, publish only the method—not a battery-life number, device ranking, or “hours per charge” promise. Android Studio’s Power Profiler can display power consumption for profileable rails through device instrumentation such as ODPM, and its documentation emphasizes correlating system traces with app actions. Crucially, ODPM readings are device-level, not app-specific, and available rails vary by hardware. The profiler documentation identifies particular device availability conditions; do not assume every Android phone exposes the same sensor or interpret a missing rail as zero power. Battery capacity percentage and current are also different quantities from energy attributable to one app task. Thermal behavior changes the workload the device can sustain. Android’s Thermal API documentation explains that temperature state and thermal throttling can affect performance over time, and provides signals for apps to react to system conditions. A measurement protocol should therefore log available thermal state or headroom with timestamps alongside task progress. Do not force an unsupported sensor or poll beyond documented guidance. Separate short-run measurement from sustained repeated workload: one successful inference cannot establish long-term battery impact, thermal stability, or performance consistency. Control confounders before comparing runs: use a consistent task and wait interval, document display brightness and foreground state, keep charging policy constant, and record network settings even when the model task is local. Avoid comparing different artifacts, prompt lengths, image sizes, or speech durations as if they were the same workload. If system-level power includes other apps and radios, label the observation accordingly and avoid attributing the full trace to inference. Where appropriate, repeat trials in a controlled environment and report all trials plus spread, rather than selecting the most favorable one. The project’s evidence policy requires device, chipset, OS, artifact, runtime, backend, input, timing, memory, thermal state, and failure outcome before result claims. This article offers an experimental design, not evidence of Cove’s current battery consumption. The useful result is a reproducible trace that identifies what was measured, what the profiler could not attribute, and how results varied—not a universal percentage or battery-life promise.

A team wants to compare two inference changes by battery impact

A development build shows a different battery percentage after a long AI session, but the device was also charging earlier and background applications were active. The team needs to compare two versions without mistaking a system-level power trace for per-app energy.

Decision

Freeze one workload, define the profiler and attribution limits, standardize device state, and collect repeated raw traces with thermal and failure context.

Expected outcome

The report describes the observed measurement source and variability, and avoids attributing unrelated radio or background load to model inference.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Power-state setup
• Fixed workload sequence
• Thermal and completion records

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Pin workload and build identity. Record app build, model artifact and quantization, runtime revision, backend request/observation, prompt or input fixture, task sequence, and exact measurement interval. Keep model, runtime, and workload identical across compared variants unless one is the deliberate variable.
2. Stabilize device conditions. Document device and OS, battery state, charging or unplugged condition, screen/brightness policy, network state, test environment, and a pre-run wait rule. Record other active foreground/background tasks that can affect system power.
3. Select and name instrumentation. Choose the available profiler or meter and record what it measures: device rail, charge counter, current, or another quantity. Check whether the device exposes the relevant rail. Label device-level traces as device-level and do not assign the full consumption to the app.
4. Pair power with thermal and task traces. Capture timestamps for task start, completion, pauses, errors, and available thermal signals. Repeat the same workload and keep every trial. Do not infer sustainable operation or battery life from one short run or a single battery-percentage delta.
5. Analyze variability and disclose limits. Compare matched runs, include idle/baseline intervals where appropriate, report measurement source and all exclusions, and state what the instrumentation cannot attribute. If raw values are missing or conditions differ, publish the protocol and limitation rather than a result number.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Every compared run uses a pinned artifact/runtime/workload identity and reports the actual measurement interval and source.
• Device conditions and thermal context are recorded; missing sensors or unsupported rails are marked unavailable, not zero.
• The report separates device-level measurement from app-specific energy attribution and does not treat battery percentage as direct task energy.
• All repeated trials and failures are retained; no universal battery-life, percentage, or device-ranking claim is made without raw evidence.

Decision table

Failure patterns to prevent

• Inventing universal battery percentages
• Comparing different workloads

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove benchmark method
• Android Studio Power Profiler documentation
• Android Dynamic Performance Framework Thermal API

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions