Dissecting the Impact of Mobile DVFS Governors on LLM Inference Performance and Energy Efficiency

Haibing Guan; Jian Li; Pranab Dash; Qiang Xu; Y. Charlie Hu; Zongpu Zhang

REVIEW 4 major objections 6 minor 2 cited by

Dissecting the Impact of Mobile DVFS Governors on LLM Inference Performance and Energy Efficiency

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Android's uncoordinated chip governors can add up to 40.4% latency to on-device LLM inference, and a unified governor recovers most of the gap.

desk verdict A careful measurement study showing mobile DVFS governors fail on LLM inference, with a plausible but under-validated fix. read the letter →

arxiv 2507.02135 v1 pith:K5GZEHYN submitted 2025-07-02 cs.OS cs.CL

Zongpu Zhang , Pranab Dash , Y. Charlie Hu , Qiang Xu , Jian Li , Haibing Guan This is my paper

classification cs.OScs.CL

keywords mobileLLMinferenceDVFSgovernorsenergyefficiencyCPU-GPUcoordinationfrequencypinningAndroidpowermanagementdownwardspiralFUSE

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

On-device large language model inference uses the phone's CPU, GPU, and memory even when the model is mostly running on the GPU, and Android's DVFS governors (the OS routines that scale each chip's voltage and frequency) tune those components independently. This paper claims that this uncoordinated tuning is far from optimal for LLM workloads: across thousands of pinned frequency combinations on Pixel 7-series phones, the default governors produce up to 40.4% longer prefill and decode latency than some CPU/GPU/memory frequency combination that consumes the same energy, and up to 16.6% more energy at the same latency. The paper traces the inefficiency to a downward spiral in which the CPU and GPU governors each lower their frequency to chase a utilization target, starving the other component and triggering further reductions. It then builds FUSE, a unified governor that profiles each model offline and pins the components to the best frequency pair at runtime. On six models serving a real chat trace, FUSE cuts time-to-first-token by 7.0-16.9% and time-per-output-token by 25.4-36.8% on average while consuming the same energy per token.

What carries the argument

The object that carries the argument is the frequency-pinning testbed and the two-step search that FUSE uses. The testbed writes a chosen frequency into both the minimum and maximum frequency limits of each component's governor, letting the authors enumerate all 2,808 combinations and compare them against governor behavior. The explanatory mechanism is the utilization-threshold feedback loop: EAS and the GPU governor each raise or lower frequency to keep hardware utilization in a vendor-defined range, but during LLM decode the utilization of each component depends on the other component's frequency, so lowering either frequency drops the other's utilization and forces another downward step. FUSE's machinery is the same testbed converted into a runtime: for each model it searches GPU frequency first because GPU frequency dominates latency and energy, keeps at most two candidate GPU frequencies, then fine-tunes CPU frequency while leaving the memory governor untouched because it is already near-optimal.

What would settle it

Re-run the full 2,808-combination frequency sweep for a fixed model and prefill length while varying only the prompt text, the battery or thermal condition, or a concurrent background app; if the best frequency combination moves with any of these, then FUSE's offline lookup table is incomplete. A lighter check: take FUSE's chosen configuration on a warm phone and compare it against the best configuration found on a cool phone for the same prompt; if the configurations differ or the latency/energy ordering reverses under one condition, the paper's claim that the optimal configuration is primarily a function of prefill length fails.

Watch

Extended reading notes

Core claim

The central discovery is that the default triplet of mobile governors—the EAS CPU governor, the Quickstep GPU governor, and the interactive memory governor—is jointly inefficient for LLM inference even though each component is locally sensible. The paper argues this in three steps: a full sweep of 2,808 CPU/GPU/memory frequency combinations shows that many pinned combinations dominate the default governors on both latency and energy; controlled isolation experiments show the GPU governor runs too slow in decode and EAS runs too slow in both stages, while the memory governor is near-optimal; and when EAS and the GPU governor run together, each governor's utilization-target scaling lowers the other's utilization, driving both frequencies down in a cascade to their minimums. FUSE is the constructive consequence: an offline profiling search, which starts from the highest GPU frequency and then fine-tunes CPU frequency, yields a configuration table keyed by prefill length, and runtime lookup pins those frequencies to avoid the spiral. The paper claims this delivers the measured latency and energy gains on Pixel 7 and Pixel 7 Pro devices.

Load-bearing premise

The whole design rests on the assumption that the frequency combination found once on an open phone without its battery remains the best choice for all later requests: the paper relies on the optimal settings depending mainly on the model and the prompt length, not on what the prompt says, how hot the chip is, or what else the phone is doing.

Editorial extensions

If this is right

Stock Android DVFS governors can waste up to 40.4% of prefill/decode latency at equal energy, so OS vendors have large headroom to reclaim without changing models or hardware.
The downward-spiral mechanism means fixing one governor in isolation may not help; coordinated frequency decisions across CPU and GPU are required.
A per-model offline frequency search of about 15-31 inference runs can reduce time-to-first-token by 7.0-16.9% and time-per-output-token by 25.4-36.8% on average across six models at equal energy-per-token.
With a fixed latency target, the same approach cuts energy-per-token by 6.9-10.3% on average across models, and total energy on a 200-request trace by up to 14.3%.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The downward spiral likely generalizes beyond LLMs to any interactive mobile workload that alternates bursty GPU phases with a CPU-bound driver or runtime layer, such as image generation, augmented reality, or camera ML; the paper's measurements only cover LLM inference.
The results imply that an OS-level coordinator which shares utilization signals across CPU, GPU, and memory could approximate FUSE's offline optimum without per-model profiling.
A direct testable extension is to profile FUSE's optimal-frequency table under thermal throttling and concurrent background tasks; if the table shifts, the runtime lookup should incorporate thermal or workload features rather than only prefill length.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

Here is the short version: this is a solid measurement paper that quantifies a real problem with default DVFS governors on mobile LLM inference. The 40% latency gap at equal energy is convincing, and the downward-spiral mechanism between EAS and the GPU governor is well supported by traces. FUSE, the proposed fix, is simple and works in their tests, but its headline gains rest on an untested assumption about decode length.

What is new: this is the first study I know of that looks at the interaction of CPU, GPU, and memory governors during on-device LLM inference. The measurement setup is careful: 2808 frequency combinations, two Pixel devices, six models, battery bypass, fine-grained power. Section 5's isolation experiments are the core contribution—they show each governor's utilization targeting goes wrong on this workload, and the coordinated downward spiral explains why default behavior is so bad. That is a genuinely useful insight for anyone working on mobile systems.

Where it is soft: FUSE assumes the optimal CPU/GPU frequency for a model depends only on prefill length, not on prompt content or decode position. The offline search profiles decode at 32 tokens and then pins those frequencies for entire requests, some with decode lengths up to 256. Attention traffic grows with KV-cache size, so the compute/memory balance shifts during generation; the optimal frequency likely moves with it. They never test whether that matters. So the 25-37% TPOT improvement is real relative to default governors, but it is not the achievable optimum, and it could degrade on longer generations. They also evaluate on the same platform used for profiling, with no held-out device or prompt set, and no variance reported. These are addressable weaknesses, not fatal ones.

The basic governor-inefficiency claim, Sections 4-5, stands on its own. The FUSE part is a reasonable engineering follow-up, not a breakthrough.

Who should read this: mobile systems people, anyone building on-device LLM runtimes, and OS folks thinking about coordinated DVFS. It deserves a serious referee—the measurements are reproducible in spirit and the mechanism is worth checking. I would recommend accepting it with a request for stronger external validation of FUSE, specifically a decode-length sweep.

Recommendation: send to peer review. The core empirical findings are solid; FUSE needs more scrutiny.

Referee Report

4 major / 6 minor

Summary. This paper measures energy and latency of on-device LLM inference (llama.cpp, OpenCL) under Android's default CPU/GPU/memory DVFS governors on Pixel 7 and Pixel 7 Pro, and compares with pinning all 2808 frequency combinations. It reports that the default governors are far from optimal: for the same energy, the optimal pin reduces prefill TTFT by up to 40.4% and decode TPOT by up to 31.8% for TinyLlama, with consistent gains for other models. Controlled experiments show both the GPU governor and EAS independently select overly low frequencies, and that they can trigger a 'downward spiral' where each governor's frequency reduction lowers the other's utilization, cascading both to their minima. The authors then design FUSE, an offline-profiled unified governor that pins a small set of CPU/GPU frequencies (memory governor left at default) based on prefill length. On a 200-request ShareGPT trace, FUSE reduces TTFT by 7.0-16.9% and TPOT by 25.4-36.8% on average with the same energy-per-token across six models.

Significance. The paper's strengths are the unusually thorough measurement campaign (2808 frequency combinations, two phones, six models, two optimization goals, controlled pinning experiments), the concrete and well-documented downward-spiral mechanism, and the release of FUSE as an extension to llama.cpp. If the results generalize, this is an important contribution: it exposes a coordination failure in commodity mobile governors for LLM workloads and demonstrates a practical, low-cost fix with substantial energy/latency gains. The main reservation is that the FUSE evaluation is built on an unvalidated assumption that optimal frequencies are input-content-agnostic and primarily affected by prefill length; because the offline profiling and online evaluation share the same devices, models, and traces, the evaluation does not yet separate the benefit of the search strategy from a simple static pin. With additional sensitivity and generalization experiments, the contribution would be solid.

major comments (4)

[Section 6 (Design overview) and Section 6.2] The assumption that the optimal frequency configuration for a given model is 'input-content-agnostic and primarily affected by the prefill length' is stated but never validated. FUSE profiles decode at a single length of 32 tokens and five prefill lengths, then applies these static configurations to every request in the ShareGPT trace, whose decode lengths reach 256 tokens. During decode, attention reads the full KV-cache at each step, so the balance of CPU-side OpenCL feeding, GPU compute, and memory traffic changes with sequence position; if the optimal frequencies shift with decode length, the static decode setting is suboptimal on longer requests and the reported 25.4-36.8% TPOT reductions are not the achievable optimum. The paper should report whether the optimal CPU/GPU frequencies found in Section 4 vary with decode length (e.g., by repeating the sweep at decode lengths 32, 64, 128, and 256) or evaluate a decode-length-aware variant of FUSE.
[Section 6.1] The frequency search relies on the observed U-shape energy-per-token curves (Figs. 4 and 8) and stops at the first frequency that meets the energy budget. This unimodality assumption is only validated on the same platform and models used by the subsequent evaluation, which makes the 'effectiveness of frequency search' results in Section 6.2 partly circular: the search is tuned to a property measured on the exact devices being evaluated. To strengthen the claim, the authors should validate the U-shape on a held-out model or device, or compare FUSE's found configurations against the exhaustive 2808-combination optimum for at least one model and report the gap to the true Pareto frontier.
[Section 4 vs Section 6.2] The paper's headline 40.4% latency improvement comes from the exhaustive pinning search, while FUSE achieves up to 36.8% TPOT and 16.9% TTFT improvements over the default governors. It is not reported how close FUSE's selected configurations come to the exhaustive-search optimum (Pin-Opt) on the same models and settings, so it is unclear whether the 374x search reduction sacrifices a significant portion of the available gain. Adding such a comparison would help readers separate the value of the unified-governor concept from the specific search heuristic.
[Section 3 (Methodology)] The testbed pins frequencies on battery-bypassed phones, but the paper does not report whether the pinned frequencies actually held for the entire duration of each run, nor does it report device temperature or run ordering. Thermal throttling is a known confound on mobile devices and can be asymmetric between long high-frequency runs (e.g., the 115.15 s Gov run in Fig. 3) and shorter pinned runs. The authors should report thermal/clock-holder monitoring and describe how they controlled for thermal drift (e.g., randomization or cool-down periods).

minor comments (6)

[Various] Typos: 'bevahior' (Section 5.4), 'explaiend' (Section 5.3), 'caculating' (Section 2.3), and 'Specicially' (Section 3).
[Section 5.2] The first sentence says 'by pinning CPU and memory frequencies', but the experiments in Fig. 6 pin CPU and GPU frequencies (GPU at 471 MHz and CPU at 1826 MHz). Please correct the text.
[References] References [46] and [47] are identical (Mobile Foundation Model as Firmware); the duplicate should be removed or replaced with the original citation.
[Section 5.1] The statement that results for other prefill/decode length combinations are 'similar' is unsupported; either include an appendix figure or qualify the claim.
[Section 6.2] The 200-request ShareGPT sample is a single random draw; the paper should report variance across multiple seeds or bootstrap confidence intervals for the TTFT/TPOT reductions.
[Abstract and Section 4] The abstract's 'up to 40.4% longer prefilling and decoding latency' could be misread as applying to both stages; Section 4 reports 40.4% for prefill TTFT and 31.8% for decode TPOT on TinyLlama. Please attribute the numbers per stage.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's measurements are direct empirical comparisons, and FUSE's main evaluation on the ShareGPT trace is an out-of-sample measurement rather than a construction from its inputs.

full rationale

The central claims in Sections 4 and 5 are direct measurements: the paper pins CPU/GPU/memory frequencies to all 2808 combinations and compares latency and energy against the default governors. The '40.4% longer latency' and 'downward spiral' results are empirical observations of measured runs, not quantities derived from an assumed model or from fitted parameters, so they cannot reduce to their inputs by construction. FUSE's offline search in Section 6.1 is an explicitly stated optimization procedure that uses the measured U-shape energy curves (from Fig. 4 and Fig. 8) to prune the search; it does not fit a parameter to the target result and then rename that fit as a prediction. The evaluation in Section 6.2 applies the offline-profiled frequency configurations to 200 unseen ShareGPT requests, so the reported TTFT/TPOT/energy numbers are genuine measurements on requests not used in the search; the fact that the same devices and models are used is normal benchmarking practice and does not made the result definitional. The strongest validity concern is that FUSE assumes optimal frequency configurations are 'input-content-agnostic and primarily affected by the prefill length' and therefore profiles only one decode length (32 tokens) while the ShareGPT trace contains decode lengths up to 256 tokens. This is a real extrapolation and a correctness/generalization risk, but it is not circularity: the trace measurements could have failed to show improvements if the 32-token configuration were poor at longer decode lengths. No load-bearing self-citation chain or imported uniqueness theorem appears; the U-shape and governor-behavior premises are supported by the paper's own controlled measurements rather than by citations to the authors' prior work. The duplicate reference [46]/[47] is a citation-hygiene issue, not a circularity issue. Accordingly, the derivation chain is self-contained with respect to the claimed empirical results, and the appropriate circularity score is 0.

Assumptions & free parameters 3 free parameters · 3 assumptions · 1 invented entities

FUSE's design free parameters are the prefill length bins, the energy/latency budget (equal to default governors), and the 'input-content-agnostic' assumption; the platform and framework choices are domain assumptions. There are no fitted physics constants or invented physical entities.

free parameters (3)

energy budget / latency target = energy and latency of default governors
FUSE's G1/G2 goals use the default governors' energy/latency as the budget/target, which is user/model-dependent but not a mathematical free parameter.
prefill length bins = 5 bins: 32, 64, 128, 256, 512 tokens
FUSE categorizes prefill lengths into five ranges, chosen by the authors with representative lengths; the choice of bins affects the search.
U-shape energy curve assumption = not a number, but a shape assumption
The search assumes energy-per-token is U-shaped in GPU and CPU frequency; verified empirically on the measurement platform but used as a search prior.

assumptions (3)

domain assumption The optimal frequency configuration is input-content-agnostic for a given model and prefill length.
Stated in Section 6 'Design overview'; enables offline profiling but is not validated across diverse prompts.
domain assumption The measured platform (Pixel 7/7 Pro, Mali G710, llama.cpp with OpenCL/CLBlast) is representative of mobile LLM inference.
The paper's measurements and FUSE evaluation are all on these two phones and this one framework; the mechanism (shallow GPU queue, low utilization in decode) may differ on other GPUs or with NPU inference.
domain assumption Pinning CPU/GPU/memory frequencies during inference is a valid probe of governor behavior and a safe runtime action.
The Pin methodology (Section 3) and FUSE runtime both pin frequencies; this assumes the frequency tables are stable and pinning does not introduce thermal or other side effects.

invented entities (1)

FUSE
purpose: A unified energy-aware governor that pins CPU/GPU frequencies according to an offline search.
FUSE is a software system, not a physical entity; it has no independent falsifiable handle beyond the measured performance on the authors' testbed.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Dissecting the Impact of Mobile DVFS Governors on LLM Inference Performance and Energy Efficiency." pith.science (2026). https://pith.science/paper/K5GZEHYN

@misc{pith2026250702135,
  author       = {Pith},
  title        = {Pith review of: Dissecting the Impact of Mobile DVFS Governors on LLM Inference Performance and Energy Efficiency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K5GZEHYN}},
  note         = {Machine review of arXiv:2507.02135}
}

read the original abstract

Large Language Models (LLMs) are increasingly being integrated into various applications and services running on billions of mobile devices. However, deploying LLMs on resource-limited mobile devices faces a significant challenge due to their high demand for computation, memory, and ultimately energy. While current LLM frameworks for mobile use three power-hungry components-CPU, GPU, and Memory-even when running primarily-GPU LLM models, optimized DVFS governors for CPU, GPU, and memory featured in modern mobile devices operate independently and are oblivious of each other. Motivated by the above observation, in this work, we first measure the energy-efficiency of a SOTA LLM framework consisting of various LLM models on mobile phones which showed the triplet mobile governors result in up to 40.4% longer prefilling and decoding latency compared to optimal combinations of CPU, GPU, and memory frequencies with the same energy consumption for sampled prefill and decode lengths. Second, we conduct an in-depth measurement study to uncover how the intricate interplay (or lack of) among the mobile governors cause the above inefficiency in LLM inference. Finally, based on these insights, we design FUSE - a unified energy-aware governor for optimizing the energy efficiency of LLM inference on mobile devices. Our evaluation using a ShareGPT dataset shows FUSE reduces the time-to-first-token and time-per-output-token latencies by 7.0%-16.9% and 25.4%-36.8% on average with the same energy-per-token for various mobile LLM models.

Figures

Figures reproduced from arXiv: 2507.02135 by the authors.

**Figure 3.** End-to-end inference latency of TinyLlama on mo [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

**Figure 2.** Comparison of inference latency and energy drain [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

Figures from the paper (12 more)

**Figure 4.** Figure 4: Decode latency and energy-per-token of the GPU governor ( [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

**Figure 5.** Figure 5: Prefill TTFT and energy-per-token of the GPU governor ( [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: Decode latency and energy drain of the memory governor ( [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

**Figure 7.** Figure 7: GPU utilization with pinning CPU at each available [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

**Figure 8.** Figure 8: Decode latency and energy drain of EAS ( [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]

**Figure 9.** Figure 9: CDF of the amount of time that GPU (left) or CPU (right) runs at a certain frequency under GPU governor or EAS, [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]

**Figure 10.** Figure 10: Runtime trace of CPU and GPU frequencies show [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]

**Figure 11.** Figure 11: Selected GPU frequencies ( solid points) in Step 1. Design overview. We observe that in LLM-powered personal services on mobile devices, the same LLM model (e.g., embedded in an APP or the OS [47]) is typically used over an extended period of time. This motivates a s…

**Figure 12.** Figure 12: Performance comparison of FUSE with Gov (the default governors), for goal G1. Energy-per-token budget is the energy draw under the default governors. frequencies will lead to higher inference latency even if they can meet the energy budget, as shown in Fig. 11a. For a…

**Figure 13.** Figure 13: Energy-per-token comparison of FUSE with [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]

**Figure 15.** Figure 15: Prefill latency and energy drain of EAS ( [PITH_FULL_IMAGE:figures/full_fig_p015_15.png]

**Figure 16.** Figure 16: Runtime trace of CPU and GPU frequencies show [PITH_FULL_IMAGE:figures/full_fig_p015_16.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Is Your NPU Ready for LLMs? Dissecting the Hidden Efficiency Bottlenecks in Mobile LLM Inference
cs.AR 2026-07 conditional novelty 7.0 of 10

Cross-layer measurements of five mobile LLM frameworks on CPU/GPU/NPU reveal amplified NPU framework gaps, a prefill–decode backend phase split, and up to ~55% NPU energy savings from scheduling fixes.
Mitigating Compiler Fusion-Induced Power Bursts in Mobile NPU Inference as the Battery Depletes
cs.AR 2026-07 conditional novelty 6.0 of 10

Compiler fusion in a mobile NPU creates current bursts that raise the DVFS-onset voltage; measurement-guided Q-DQ barrier insertion cuts peak current from 3.12 A to 1.94 A (38%) with 3.76% latency overhead.

Reference graph

Works this paper leans on

50 extracted references · 35 canonical work pages · cited by 2 Pith papers

[1]

AOSP. 2022. AOSP Kernel governor_simpleinteractive.c. https://android.googlesource.com/kernel/gs/+/refs/heads/android- gs-pantah-5.10-android13-qpr3/drivers/devfreq/google/governor_ simpleinteractive.c. Last accessed 18 Oct 2024

work page 2022
[2]

AOSP. 2022. AOSP Kernel gs201-gpu.dtsi. https://android. googlesource.com/kernel/gs/+/refs/heads/android-gs-pantah-5.10- android13-qpr3/arch/arm64/boot/dts/google/gs201-gpu.dtsi. Last accessed 18 Oct 2024

work page 2022
[3]

ARM. 2012. AMBA ® AXI and ACE Protocol Specifica- tion. https://developer.arm.com/-/media/Arm%20Developer% 20Community/PDF/IHI0022H_amba_axi_protocol_spec.pdf? revision=71bd7c57-2ed7-487b-bc3e-68c4ab56fa5f&la=en&hash= 6325311012DDADF238C35A6C0FD734E520754F82 Last accessed 5 Oct 2024

work page 2012
[4]

ARM. 2015. Memory interface. https://developer.arm.com/ documentation/100095/0003/Functional-Description/Interfaces/ Memory-interface?lang=en Last accessed 5 Oct 2024

work page 2015
[5]

Sarbartha Banerjee. 2018. Characterization of smartphone governor strategies and making of a workload aware governor. Ph. D. Dissertation

work page 2018
[6]

Sarbartha Banerjee and Lizy Kurian John. 2018. Characterization of Smartphone Governor Strategies. In Euro-Par. 120–134

work page 2018
[7]

Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin...

arXiv 2020
[8]

Mike Chan. 2012. cpufreq: New ’interactive’ governor. https://lkml. org/lkml/2012/2/7/483 Last accessed 5 Oct 2024

work page 2012

Show all 50 references

[9]

Tom Conway. 2013. Why do I need an AMBA 5 CHI Mem- ory Controller? https://community.arm.com/arm-community- blogs/b/architectures-and-processors-blog/posts/why-do-i-need- an-amba-5-chi-memory-controller Last accessed 5 Oct 2024

2013
[10]

Jonathan Corbet. 2013. Per-entity load tracking . https://lwn.net/ Articles/531853/

2013
[11]

DeepSeek-AI. 2025. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 [cs.CL] https: //arxiv.org/abs/2501.12948

2025 arXiv
[12]

developer.android.com. 2015. Android Debug Bridge (adb). https: //developer.android.com/tools/adb Last accessed 5 Oct 2024

2015
[13]

Georgi Gerganov. 2024. llama.cpp. https://github.com/ggerganov/ llama.cpp

2024
[14]

Liwei Guo, Wonkyo Choe, and Felix Xiaozhu Lin. 2023. STI: Tur- bocharge NLP Inference at the Edge via Elastic Pipelining. In ASPLOS. ACM, 791–803

2023
[15]

Xue-Xin He and Ya-Shu Chen. 2018. Deadline-aware Memory Sched- uler and Governor for Heterogeneous Processors. In 2018 IEEE 16th International Conference on Industrial Informatics (INDIN) . IEEE, 239– 244

2018
[16]

Chen-Ying Hsieh, Jurn-Gyu Park, Nikil Dutt, and Sung-Soo Lim. 2015. Memory-aware cooperative CPU-GPU DVFS governor for mobile games. In 2015 13th IEEE Symposium on Embedded Systems For Real- time Multimedia (ESTIMedia). IEEE, 1–8

2015
[17]

Xiaotang Jiang, Huan Wang, Yiliu Chen, Ziqi Wu, Lichuan Wang, Bin Zou, Yafeng Yang, Zongyang Cui, Yu Cai, Tianhang Yu, Chengfei Lv, and Zhihua Wu. 2020. MNN: A Universal and Efficient Inference Engine. In MLSys

2020
[18]

Meruyert Karzhaubayeva, Aidar Amangeldi, and Jurn-Gyu Park. 2023. CNN Workloads Characterization and Integrated CPU–GPU DVFS Governors on Embedded Systems. IEEE Embedded Systems Letters 15, 4 (2023), 202–205. doi:10.1109/LES.2023.3299335

2023
[19]

kernel.org. 2015. Energy Aware Scheduling. https://www.kernel. org/doc/html/latest/scheduler/sched-energy.html Last accessed 5 Oct 2024

2015
[20]

Seyeon Kim, Kyungmin Bin, Sangtae Ha, Kyunghan Lee, and Song Chong. 2021. zTT: learning-based DVFS with zero thermal throttling for mobile devices. In MobiSys. ACM, 41–53

2021
[21]

Stefanos Laskaridis, Kleomenis Katevas, Lorenzo Minto, and Hamed Haddadi. 2024. MELTing point: Mobile Evaluation of Language Trans- formers. In MobiCom

2024
[22]

Xiang Li, Zhenyan Lu, Dongqi Cai, Xiao Ma, and Mengwei Xu. 2024. Large Language Models on Mobile Devices: Measurements, Analysis, and Insights. In EdgeFM@MobiSys. ACM, 1–6

2024
[23]

Chengdong Lin, Kun Wang, Zhenjiang Li, and Yu Pu. 2023. A Workload- Aware DVFS Robust to Concurrent Tasks for Mobile Devices. In Mobi- Com. ACM, 19:1–19:16

2023
[24]

Di Liu, Shi-Gui Yang, Zhenli He, Mingxiong Zhao, and Weichen Liu. 2022. CARTAD: Compiler-Assisted Reinforcement Learning for Thermal-Aware Task Scheduling and DVFS on Multicores. IEEE Trans. Comput. Aided Des. Integr. Circuits Syst. 41, 6 (2022), 1813–1826

2022
[25]

Iandola, Chen Lai, Yuan- dong Tian, Igor Fedorov, Yunyang Xiong, Ernie Chang, Yangyang Shi, 13 Raghuraman Krishnamoorthi, Liangzhen Lai, and Vikas Chandra

Zechun Liu, Changsheng Zhao, Forrest N. Iandola, Chen Lai, Yuan- dong Tian, Igor Fedorov, Yunyang Xiong, Ernie Chang, Yangyang Shi, 13 Raghuraman Krishnamoorthi, Liangzhen Lai, and Vikas Chandra. 2024. MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device U...

2024
[26]

msoon.com. 2015. Monsoon Power Monitor. https://www.msoon. com/high-voltage-power-monitor Last accessed 5 Oct 2024

2015
[27]

Cedric Nugteren. 2018. CLBlast: A Tuned OpenCL BLAS Library. In IWOCL. 5:1–5:10

2018
[28]

Saroj Kumar Panda, Man Lin, and Ti Zhou. 2023. Energy-Efficient Com- putation Offloading With DVFS Using Deep Reinforcement Learning for Time-Critical IoT Applications in Edge Computing. IEEE Internet Things J. 10, 8, April 15 (2023), 6611–6621

2023
[29]

Heejin Park and Felix Xiaozhu Lin. 2022. GPUReplay: a 50-KB GPU stack for client ML. In ASPLOS. 157–170

2022
[30]

Jurn-Gyu Park, Nikil Dutt, and Sung-Soo Lim. 2017. ML-Gov: A ma- chine learning enhanced integrated CPU-GPU DVFS governor for mobile gaming. In Proceedings of the 15th IEEE/ACM Symposium on Embedded Systems for Real-Time Multimedia . 12–21

2017
[31]

Jurn-Gyu Park, Chen-Ying Hsieh, Nikil Dutt, and Sung-Soo Lim. 2015. Cooperative CPU-GPU frequency capping (Co-Cap) for energy effi- cient mobile gaming. UCI Center for Embedded and Cyber-physical Systems TR (2015)

2015
[32]

Pratyush Patel, Esha Choukse, Chaojie Zhang, Aashaka Shah, Íñigo Goiri, Saeed Maleki, and Ricardo Bianchini. 2024. Splitwise: Efficient Generative LLM Inference Using Phase Splitting. In ISCA. 118–132

2024
[33]

Saber. 2015. [REF][GUIDE]Saber’s guide on CPU governors, I/O sched- ulers and more! https://xdaforums.com/t/ref-guide-sabers-guide-on- cpu-governors-i-o-schedulers-and-more.3048957/ Last accessed 5 Oct 2024

2015
[34]

Onur Sahin, Lothar Thiele, and Ayse K. Coskun. 2019. Maestro: Au- tonomous QoS Management for Mobile Applications Under Thermal Constraints. IEEE Trans. Comput. Aided Des. Integr. Circuits Syst. 38, 8 (2019), 1557–1570

2019
[35]

Fuwen Tan, Royson Lee, Łukasz Dudziak, Shell Xu Hu, Sourav Bhat- tacharya, Timothy Hospedales, Georgios Tzimiropoulos, and Brais Martinez. 2024. MobileQuant: Mobile-friendly Quantization for On- device Language Models. arXiv:2408.13933 [cs.CL] https://arxiv.org/ abs/2408.13933

2024 arXiv
[36]

MLC team. 2023. MLC-LLM. https://github.com/mlc-ai/mlc-llm

2023
[37]

Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie- Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guillaume Lample. 2023. LLaMA: Open and Efficient Foundation L...

2023 arXiv
[38]

Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Alma- hairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, Dan Bikel, Lukas Blecher, Cristian Canton Ferrer, Moya Chen, Guillem Cucurull, David Esiobu, Jude Fernandes, Jeremy Fu,...

2023 arXiv
[39]

Gomez, Lukasz Kaiser, and Illia Polosukhin

Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. 2017. Attention is All you Need. In NIPS. 5998–6008

2017
[40]

Jie Xiao, Qianyi Huang, Xu Chen, and Chen Tian. 2024. Large Language Model Performance Benchmarking on Mobile Platforms: A Thorough Evaluation. arXiv:2410.03613 [cs.LG] https://arxiv.org/abs/2410.03613

2024
[41]

Daliang Xu, Wangsong Yin, Xin Jin, Ying Zhang, Shiyun Wei, Mengwei Xu, and Xuanzhe Liu. 2023. LLMCad: Fast and Scalable On-device Large Language Model Inference. arXiv:2309.04255 [cs.NI] https: //arxiv.org/abs/2309.04255

2023 arXiv
[42]

Daliang Xu, Hao Zhang, Liming Yang, Ruiqi Liu, Gang Huang, Meng- wei Xu, and Xuanzhe Liu. 2024. Empowering 1000 tokens/second on-device LLM prefilling with mllm-NPU. arXiv:2407.05858 [cs.AI] https://arxiv.org/abs/2407.05858

2024 arXiv
[43]

Zhenliang Xue, Yixin Song, Zeyu Mi, Le Chen, Yubin Xia, and Haibo Chen. 2024. PowerInfer-2: Fast Large Language Model Inference on a Smartphone. arXiv:2406.06282 [cs.LG] https://arxiv.org/abs/2406. 06282

2024 arXiv
[44]

Yuan Yao, Tianyu Yu, Ao Zhang, Chongyi Wang, Junbo Cui, Hongji Zhu, Tianchi Cai, Haoyu Li, Weilin Zhao, Zhihui He, Qianyu Chen, Huarong Zhou, Zhensheng Zou, Haoye Zhang, Shengding Hu, Zhi Zheng, Jie Zhou, Jie Cai, Xu Han, Guoyang Zeng, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2...

2024 arXiv
[45]

Rongjie Yi, Liwei Guo, Shiyun Wei, Ao Zhou, Shangguang Wang, and Mengwei Xu. 2023. EdgeMoE: Fast On-Device Inference of MoE-based Large Language Models. arXiv:2308.14352 [cs.LG] https://arxiv.org/ abs/2308.14352

2023 arXiv
[47]

Jinliang Yuan, Chen Yang, Dongqi Cai, Shihe Wang, Xin Yuan, Zeling Zhang, Xiang Li, Dingge Zhang, Hanzi Mei, Xianqing Jia, Shangguang Wang, and Mengwei Xu. 2024. Mobile Foundation Model as Firmware. In MobiCom. ACM, 279–295

2024
[48]

Peiyuan Zhang, Guangtao Zeng, Tianduo Wang, and Wei Lu
[49]

Ziyang Zhang, Yang Zhao, Huan Li, Changyao Lin, and Jie Liu. 2024. DVFO: Learning-Based DVFS for Energy-Efficient Edge-Cloud Collab- orative Inference. IEEE Trans. Mob. Comput. 23, 10 (2024), 9042–9059

2024
[50]

Yinmin Zhong, Shengyu Liu, Junda Chen, Jianbo Hu, Yibo Zhu, Xu- anzhe Liu, Xin Jin, and Hao Zhang. 2024. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving. In OSDI. 193–210. Appendix A: Additional EAS Governor Results In §5.3, we...

2024
[2024]

arXiv:2401.02385 [cs.CL]

TinyLlama: An Open-Source Small Language Model. arXiv:2401.02385 [cs.CL]

arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

AOSP. 2022. AOSP Kernel governor_simpleinteractive.c. https://android.googlesource.com/kernel/gs/+/refs/heads/android- gs-pantah-5.10-android13-qpr3/drivers/devfreq/google/governor_ simpleinteractive.c. Last accessed 18 Oct 2024

work page 2022

[2] [2]

AOSP. 2022. AOSP Kernel gs201-gpu.dtsi. https://android. googlesource.com/kernel/gs/+/refs/heads/android-gs-pantah-5.10- android13-qpr3/arch/arm64/boot/dts/google/gs201-gpu.dtsi. Last accessed 18 Oct 2024

work page 2022

[3] [3]

ARM. 2012. AMBA ® AXI and ACE Protocol Specifica- tion. https://developer.arm.com/-/media/Arm%20Developer% 20Community/PDF/IHI0022H_amba_axi_protocol_spec.pdf? revision=71bd7c57-2ed7-487b-bc3e-68c4ab56fa5f&la=en&hash= 6325311012DDADF238C35A6C0FD734E520754F82 Last accessed 5 Oct 2024

work page 2012

[4] [4]

ARM. 2015. Memory interface. https://developer.arm.com/ documentation/100095/0003/Functional-Description/Interfaces/ Memory-interface?lang=en Last accessed 5 Oct 2024

work page 2015

[5] [5]

Sarbartha Banerjee. 2018. Characterization of smartphone governor strategies and making of a workload aware governor. Ph. D. Dissertation

work page 2018

[6] [6]

Sarbartha Banerjee and Lizy Kurian John. 2018. Characterization of Smartphone Governor Strategies. In Euro-Par. 120–134

work page 2018

[7] [7]

Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin...

arXiv 2020

[8] [8]

Mike Chan. 2012. cpufreq: New ’interactive’ governor. https://lkml. org/lkml/2012/2/7/483 Last accessed 5 Oct 2024

work page 2012