A Beginner's Guide to Power and Energy Measurement and Estimation for Computing and Machine Learning

Akshaya Jagannadharao; Charles Tripp; Dawn Nafus; Giuseppe Raffa; Hilary Egan; Jamil Gafur; Nicole Beckage; Sovan Biswas; Thijs Metsch

REVIEW 2 major objections 6 minor 18 references

A Beginner's Guide to Power and Energy Measurement and Estimation for Computing and Machine Learning

T0 review · 2 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read This paper argues that energy measurement for computing and machine learning is a series of scoped decisions, not a single physical reading, and provides a beginner's workflow for making those decisions soundly.

desk verdict A genuinely useful beginner's guide to ML energy measurement that collects known pitfalls well, with a soft spot in its proxy-estimation recommendations and the unverified Code Carbon conversion factor. read the letter →

arxiv 2412.17830 v1 pith:3IVI7LXU submitted 2024-12-11 eess.SP cs.LG

Akshaya Jagannadharao , Nicole Beckage , Sovan Biswas , Hilary Egan , Jamil Gafur , Thijs Metsch , Dawn Nafus , Giuseppe Raffa

show 1 more author

Charles Tripp

This is my paper · ORCID

classification eess.SPcs.LG

keywords energymeasurementpowerestimationmachinelearningsustainabilityperformance-to-powerratiothermaldesignat-the-wallsamplingstrategiescarbonfootprintreporting

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

The paper argues that although energy is a physical property, turning it into a useful number for a computing or ML workload requires a chain of judgment calls: where to measure, how often, what to include, and how to fill gaps with estimates. It organizes these choices into three measurement levels — system, job/application, and code — and walks through common pitfalls at each level, such as idle power draw, cooling overhead, shared resources, sampling-rate effects, and component interactions. The paper's core practical claim is that a beginner can make sound energy estimates if they decide absolute-versus-marginal scope, match the measurement method to the question, and treat proxy estimates like performance-to-power ratios and thermal design power as fallbacks that carry real error. A sympathetic reader would come away with a checklist for planning, running, and reporting energy measurements, plus a call for better standards.

What carries the argument

The central mechanism is the measurement-scoping hierarchy, which separates questions into system, job/application, and code levels and maps them to a physical hierarchy from data center or facility down to component or device. The load-bearing analytical tools are the absolute-versus-marginal energy distinction, the in-band versus at-the-wall measurement distinction, and the performance-to-power ratio curve — a benchmark-derived mapping from CPU utilization to power draw — used as a proxy when direct measurement is unavailable.

What would settle it

Run a representative ML training job on two servers with the same CPU architecture and TDP but different workload characteristics (for example, memory-bound versus compute-bound), estimate energy using a SPECPower- or SERT-style performance-to-power ratio, and compare against a calibrated wall meter. If the proxy estimate deviates from the wall-meter measurement by more than the paper's implied tolerance — or the deviation differs sharply between workloads — the matching-by-architecture rule is falsified for that class of workloads.

Watch

Extended reading notes

Core claim

The paper's central claim is that sound energy measurement for ML and general computing is achievable for non-specialists, provided they understand that every measurement is a scoped estimate, not a raw physical readout. The paper establishes a workflow: define the question; identify relevant resources and measurement scope; choose between at-the-wall and on-device/in-band methods; select sampling rates that match the time scale of the workload; repeat measurements to characterize noise; and report hardware, software, methodology, and sources of error. It further claims that when direct measurement is impossible, proxy estimation using benchmarked performance-to-power ratios or published thermal design power (TDP) is a reasonable starting point, but with a higher error margin because the benchmark workload (often server-side Java) may not resemble the target workload. The paper supports these claims with three worked scenarios — system-level scheduler effects, job-level neural-network comparisons, and code-level optimization — and with a practical FAQ, tool list, and reporting guidance.

Load-bearing premise

The weakest link is the paper's own fallback advice in Section 2.5: when direct measurement is unavailable, it recommends matching a benchmark scenario by CPU architecture and TDP, yet the paper itself notes the benchmark workload (server-side Java) may not resemble the target ML workload.

Editorial extensions

If this is right

A developer who follows the paper's checklist can produce energy numbers that are comparable across runs on the same system, and can state clearly what the numbers do and do not include.
Energy reported in model cards or papers should include runtime on hardware, measurement methodology, and sources of error; otherwise the number is not interpretable.
At-the-wall measurements capture the full system including conversion and cooling inefficiencies, while on-device measurements map cleanly to a workload but miss system overhead; the choice changes the conclusion.
Proxy estimates from benchmark ratios or TDP are acceptable fallbacks, but their error is workload-dependent, so they should not be treated as equivalent to direct measurement.
Because no universal standard exists, comparisons across different hardware and software environments require the same measurement methodology and scope.

Reading between the lines

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

Beyond the paper: a natural testable extension is to validate proxy estimates against a few wall-meter spot checks on the actual deployment hardware; a small validation set would bound the proxy error and make the fallback recommendation trustworthy.
Beyond the paper: the paper's emphasis on active-idle power and processing stalls suggests that energy optimization of ML workloads may be dominated by data-movement and memory-hierarchy costs rather than raw compute, which would push optimization efforts toward batching and prefetching.
Beyond the paper: if proxy-based tools remain the default in ML sustainability reporting, the field could adopt a standardized reporting template that separates measured, estimated, and assumed components of an energy figure, reducing the risk of comparing apples to oranges.

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

Quick take: this is a solid, genuinely useful beginner's guide to ML energy measurement, not a research contribution. It collects known pitfalls and organizes them well; the workflow framing and the scenario walkthroughs are the best parts. The proxy-estimation section (§2.5) is the weakest link, and the stress-test note is right: recommending architecture/TDP-matched SPECPower/SERT curves as a 'solid starting point' goes a bit beyond what the paper or the benchmarks can support. The guide itself lists the right caveats—benchmark workload mismatch, bare-metal lab conditions, ignored temperature/clock state—but then undercuts them by endorsing the transfer anyway. That is a moderate flaw, not a fatal one, because the guide frames proxies as fallbacks and tells readers to prefer direct measurement when possible. A beginner could still be misled into treating the estimate as accurate; the authors should either soften the claim or add a validation example.

The other soft spot is the unverified Code Carbon conversion factor in Appendix 3 (E = 1.059 × codecarbon kWh), which appears without error bars, citation, or hardware context. For a guide whose whole point is measurement accuracy, that one-liner is sloppy.

What the paper does well: it distinguishes measurement goals (system/job/code), explains at-the-wall vs on-device, discusses sampling frequency, idle power, shared resources, and reporting transparency. The FAQ and scenario walkthroughs are concrete and practical. The self-citation to Tripp et al. and Bugbee et al. is appropriate—they are real example studies, and the guide's advice does not depend on them circularly.

Recommendation: send to peer review. It's a tutorial, so reviewers should check for accuracy and completeness rather than novelty. The proxy-estimation wording and the Code Carbon conversion need fixing, but the core guidance is sound. Worth reading for anyone entering this subfield.

Referee Report

2 major / 6 minor

Summary. This paper presents a practical guide for measuring and estimating the energy consumption of computing and machine learning workloads. It introduces a measurement workflow, distinguishes system-, job-, and code-level goals, describes at-the-wall versus on-device measurement, discusses sampling, error sources, and power-management effects, and covers proxy estimation via benchmark-derived performance-to-power ratios and TDP. It also discusses converting energy to carbon emissions and offers reporting recommendations, three scenario walkthroughs, and an appendix of tools. The paper's central claim is that a beginner, after reading it, will be able to make sound measurement and interpretation choices when assessing the energy use of computing and ML workloads.

Significance. If the guidance is reliable, the paper fills an important practical gap: most ML researchers and developers do not currently incorporate energy measurement into their work, and existing guidance is scattered. The paper's strengths include a clear conceptual framework, explicit reporting checklists (Section 2.6.4), a balanced treatment of absolute versus marginal energy, and a useful catalogue of tools in Appendix 3. The authors are also appropriately modest about the limits of proxy estimates and about the lack of standardized protocols. Because the paper is pedagogical rather than a new measurement study, its value lies in whether its recommendations are clear and not misleading; the main risk is that some recommendations are stated more firmly than the evidence presented in the paper supports.

major comments (2)

[§2.5.1] The recommendation that 'selecting a curve with the same architecture and TDP should be a solid starting point' is not validated for arbitrary ML workloads. The paper itself acknowledges in the bullet list in §2.5.1 that SPECPower and SERT use server-side Java workloads and that proxy measurements ignore temperature and clock state, but it does not present any evidence that architecture/TDP matching yields estimates within an acceptable error bound, nor does it quantify the error. This is load-bearing because this is the primary quantitative fallback for a beginner without a power meter. The guide should either provide a validation case (for example, comparing the SPECPower-based CPU estimate against wall-power measurement in Scenario 3, which is currently absent) or explicitly frame the recommendation as a rough order-of-magnitude estimate with guidance on how to report it as such. As written, the phrase 'solid starting point' may lead a beginner to treat proxy-derived numbers as more reliable than they are.
[Appendix 3, item 5] The empirical calibration statement 'One publication did both physical measurement and Code Carbon measurement and estimated that the difference between the two on the hardware used is E (kWh) = 1.059 · codecarbon kWh' is given without a citation. Given the paper's own emphasis on transparent reporting (Section 2.6.4), this factor should cite the publication and specify the hardware, workload, and measurement conditions under which it was derived. As written, a reader could mistake it for a universal conversion factor, which would compound the very error sources the paper warns about.

minor comments (6)

[§2.4.9] The statement that memory modules 'do not require significant power to maintain stored data' is an oversimplification; DRAM refresh power is non-negligible and depends on access patterns. The sentence should be rephrased to avoid implying that memory power is always insignificant.
[§2.5.2] TDP is described as 'the maximum amount of heat generated by the hardware component.' TDP is more accurately a design point for thermal dissipation, not a measured maximum power draw. The definition should be corrected to avoid reinforcing a common misconception.
[§2.4.5] The suggestion to sample at intervals greater than 0.1 seconds is attributed to psutil without a citation; please add a reference to the psutil documentation or the relevant source.
[References] Greenwade (1993), which is about CTAN, appears to be a LaTeX template artifact and is unrelated to the paper's content; it should be removed.
[Throughout] There are several typos, including 'dissaggregated' (§2.2.1), 'refering' (§2.5), 'alterntive' (§2.4.9), 'gird' (§3), and 'standarized' (§4). A careful copyedit would improve readability.
[§2.6.4] In the Reporting subsection, the sentence 'listing the tools and devices used for measurements, .' contains an extra comma; it should read 'listing the tools and devices used for measurements.'

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the guide's advice is self-contained, and its self-citations are illustrative rather than load-bearing.

full rationale

This paper is a tutorial and survey rather than a derivation chain; it does not claim to predict an outcome from fitted parameters or to derive a result from a self-cited uniqueness theorem. Its recommendations about at-the-wall versus on-device measurement, sampling, error sources, and proxy estimation are presented as practical guidance based on cited literature and domain practice. The only potentially load-bearing quantitative input, the SPECPower/SERT performance-to-power curves in Sections 2.5 and 2.5.1, is an external industry benchmark, and the paper explicitly lists caveats that the benchmark workload may not match the target workload. That is an unvalidated transfer assumption, which would be a correctness or validity risk, not a circularity: the guide does not define the target estimate in terms of the benchmark curve, nor does it fit the curve to the data it then 'predicts.' Self-citations to Tripp et al. 2024 and Bugbee et al. 2017 appear only as illustrative real-world examples and adapted tables in the scenario walkthroughs; the advice does not depend on those papers for its truth. The Code Carbon conversion factor in Appendix 3 is reported as an external calibration from another study, not as an input that is then presented as a prediction. No step reduces by construction to its own inputs, so the appropriate finding is no significant circularity.

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

No new entities are introduced. The only numeric constant presented as an external empirical result, the Code Carbon factor, is unsupported by a citation. The guide's load-bearing assumptions are domain-level: that measurement hierarchies and proxy methods are transferable, and that the authors' examples generalize.

free parameters (1)

Code Carbon conversion factor alpha = 1.059 (unitless multiplier)
Presented in Appendix 3 as E(kWh) = 1.059 * codecarbon kWh, attributed to 'one publication' but without citation or derivation. It is ancillary to the guide and not load-bearing for the central claim, but it is a fitted constant stated without error bars.

assumptions (3)

domain assumption At-the-wall power measurement is the most accurate reference, and on-device or software estimates can be interpreted against it.
This underpins the discussion in Section 2.4.4 and the FAQ recommendations. If software counters were as accurate as physical meters, much of the guide's caution would be unnecessary.
domain assumption Benchmark performance-to-power ratios and TDP can serve as valid proxy estimates when direct measurement is unavailable.
Section 2.5 recommends this approach as the main fallback. The paper acknowledges the benchmark workload mismatch but still relies on the assumption that the transfer holds within similar architecture and TDP.
domain assumption The authors' real-world experiences, S1, S2, and S3, are representative enough to illustrate general measurement pitfalls.
The guide repeatedly uses these scenarios as evidence for recommendations, for example stalls dominating energy in S2 and batch size effects in S3. If these cases are atypical, some of the advice would be overgeneralized.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Beginner's Guide to Power and Energy Measurement and Estimation for Computing and Machine Learning." pith.science (2026). https://pith.science/paper/3IVI7LXU

@misc{pith2026241217830,
  author       = {Pith},
  title        = {Pith review of: A Beginner's Guide to Power and Energy Measurement and Estimation for Computing and Machine Learning},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3IVI7LXU}},
  note         = {Machine review of arXiv:2412.17830}
}

read the original abstract

Concerns about the environmental footprint of machine learning are increasing. While studies of energy use and emissions of ML models are a growing subfield, most ML researchers and developers still do not incorporate energy measurement as part of their work practices. While measuring energy is a crucial step towards reducing carbon footprint, it is also not straightforward. This paper introduces the main considerations necessary for making sound use of energy measurement tools and interpreting energy estimates, including the use of at-the-wall versus on-device measurements, sampling strategies and best practices, common sources of error, and proxy measures. It also contains practical tips and real-world scenarios that illustrate how these considerations come into play. It concludes with a call to action for improving the state of the art of measurement methods and standards for facilitating robust comparisons between diverse hardware and software environments.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 13 canonical work pages

[3]

Cambium 2022 Scenario Descriptions and Documentation

“Cambium 2022 Scenario Descriptions and Documentation” [in en]. Renewable Energy. Grant, R. E., J. H. Laros, M. Levenhagen, S. L. Olivier, K. Pedretti, L. Ward, and A. J. Younge

work page 2022
[4]

Evaluating energy and power profiling techniques for HPC workloads

“Evaluating energy and power profiling techniques for HPC workloads.” In 2017 Eighth International Green and Sustainable Computing Conference (IGSC), 1–8. https://doi.org/10.1109/IGCC.2017.8323587. Greenwade, G. D

work page arXiv 2017
[6]

Global temperature change

“Global temperature change.” [Online; accessed 1-July-2024], Proceedings of the National Academy of Sciences 103 (39): 14288–14293. IEA. n.d. “Electricity 2024.” [Online; accessed 1-July-2024]. Kistowski, J. von, K.-D. Lange, J. A. Arnold, S. Sharma, J. Pais, and H. Block

work page 2024
[8]

org / 10

https : / / doi . org / 10 . 1145 / 3575813 . 3595197. https : //dl.acm.org/doi/10.1145/3575813.3595197. Luccioni, S., Y . Jernite, and E. Strubell

arXiv
[9]

Power Hungry Processing: Watts Driving the Cost of AI Deploy- ment?

“Power Hungry Processing: Watts Driving the Cost of AI Deploy- ment?” In Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency,85–99. FAccT ’24. Rio de Janeiro, Brazil: Association for Computing Machinery. ISBN : 9798400704505. https://doi.org/10.1145/ 3630106.3658542. https://doi.org/10.1145/3630106.3658542. Newsom, D. K., ...

arXiv 2024
[11]

In Threat to Climate Safety, Michigan to Woo Tech Data Centers with New Laws

Proceedings 28,372–382. Springer. Perkins, T. n.d. “In Threat to Climate Safety, Michigan to Woo Tech Data Centers with New Laws.” [Online; ac- cessed 1-July-2024]. Poess, M., R. O. Nambiar, K. Vaid, J. M. Stephens Jr, K. Huppler, and E. Haines

work page 2024
[14]

https://doi.org/10.25984/2329316

BUTTER-E - Energy Consumption Data for the BUTTER Empirical Deep Learning Dataset, December. https://doi.org/10.25984/2329316. https: //data.openei.org/submissions/5991. Tripp, C., J. Perr-Sauer, J. Gafur, A. Nag, A. Purkayastha, S. Zisman, and E. A. Bensen

work page doi:10.25984/2329316
[15]

Measuring the Energy Consumption and Efficiency of Deep Neural Networks: An Empirical Analysis and Design Recommenda- tions

“Measuring the Energy Consumption and Efficiency of Deep Neural Networks: An Empirical Analysis and Design Recommenda- tions.” Preprint, arxiv, https://arxiv.org/abs/2403.08151. Verdecchia, R., J. Sallou, and L. Cruz

arXiv

Show all 18 references

[16]

arXiv: 2301

A Systematic Review of Green AI. arXiv: 2301 . 11047[cs.AI]. https://arxiv.org/abs/2301.11047. Wang, X., C. Na, E. Strubell, S. Friedler, and S. Luccioni

arXiv
[17]

Energy and Carbon Considerations of Fine-Tuning BERT

“Energy and Carbon Considerations of Fine-Tuning BERT.” In Findings of the Association for Computational Linguistics: EMNLP 2023, edited by H. Bouamor, J. Pino, and K. Bali, 9058–9069. Singapore: Association for Computational Linguistics, December. https://doi.org/10.18653/ v1...

2023
[18]

NASA Analysis Confirms a Year of Monthly Temperature Records

Energy Efficiency Considerations for HPC Procurement Document.https://sites.google.com/lbl. gov/procurement/home. [Online; accessed 2024]. Younger, S. n.d. “NASA Analysis Confirms a Year of Monthly Temperature Records.” [Online; accessed 1-July- 2024]. 31 This report is availa...

2024
[2013]

Tue, a new energy-efficiency metric applied at ornl’s jaguar

“Tue, a new energy-efficiency metric applied at ornl’s jaguar.” In Supercomputing: 28th International Supercomput- ing Conference, ISC 2013, Leipzig, Germany, June 16-20,

2013
[2017]

Prediction and characteriza- tion of application power use in a high-performance computing environment

“Prediction and characteriza- tion of application power use in a high-performance computing environment.” Statistical Analysis and Data Mining: The ASA Data Science Journal 10 (3): 155–165. Crownhart, C. n.d. “AI is an energy hog. This is what it means for climate change.” [On...

2024
[2018]

Measuring and benchmarking power consumption and energy efficiency

“Measuring and benchmarking power consumption and energy efficiency.” In Companion of the 2018 ACM/SPEC International Conference on Performance Engineering, 57–65. Lange, K.-D

2018
[2021]

Attributional & Consequential Life Cycle Assessment: Definitions, Conceptual Characteristics and Modelling Restrictions

“Attributional & Consequential Life Cycle Assessment: Definitions, Conceptual Characteristics and Modelling Restrictions.” Sustainability 13 (13). ISSN : 2071-1050. https://doi.org/10.3390/su13137386. https://www.mdpi.com/2071- 1050/13/13/7386. Sevilla, J., L. Heim, A. Ho, T. ...

doi
[2022]

Compute trends across three eras of machine learning

“Compute trends across three eras of machine learning.” In 2022 International Joint Conference on Neural Networks (IJCNN), 1–8. IEEE. Siler-Evans, K., I. L. Azevedo, and M. G. Morgan

2022
[2023]

Trends in AI inference energy consumption: Beyond the performance-vs-parameter laws of deep learning

“Trends in AI inference energy consumption: Beyond the performance-vs-parameter laws of deep learning.” Sustainable Computing: Informatics and Systems 38:100857. ISSN : 2210-5379. https://doi.org/https://doi.org/10.1016/j.suscom.2023.100857. https://www. sciencedirect.com/scie...
[2024]

AI is Exhausting the Power Grid. Tech Firms are Seeking a Miracle Solution

www.brendangregg.com/usemethod.html. Halper, E., and C. O’Donovan. n.d. “AI is Exhausting the Power Grid. Tech Firms are Seeking a Miracle Solution.” [Online; accessed 1-July-2024]. Hansen, J., M. Sato, R. Ruedy, K. Lo, D. W. Lea, and M. Medina-Elizade

2024

Pith tools

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

[1] [3]

Cambium 2022 Scenario Descriptions and Documentation

“Cambium 2022 Scenario Descriptions and Documentation” [in en]. Renewable Energy. Grant, R. E., J. H. Laros, M. Levenhagen, S. L. Olivier, K. Pedretti, L. Ward, and A. J. Younge

work page 2022

[2] [4]

Evaluating energy and power profiling techniques for HPC workloads

“Evaluating energy and power profiling techniques for HPC workloads.” In 2017 Eighth International Green and Sustainable Computing Conference (IGSC), 1–8. https://doi.org/10.1109/IGCC.2017.8323587. Greenwade, G. D

work page arXiv 2017

[3] [6]

Global temperature change

“Global temperature change.” [Online; accessed 1-July-2024], Proceedings of the National Academy of Sciences 103 (39): 14288–14293. IEA. n.d. “Electricity 2024.” [Online; accessed 1-July-2024]. Kistowski, J. von, K.-D. Lange, J. A. Arnold, S. Sharma, J. Pais, and H. Block

work page 2024

[4] [8]

org / 10

https : / / doi . org / 10 . 1145 / 3575813 . 3595197. https : //dl.acm.org/doi/10.1145/3575813.3595197. Luccioni, S., Y . Jernite, and E. Strubell

arXiv

[5] [9]

Power Hungry Processing: Watts Driving the Cost of AI Deploy- ment?

“Power Hungry Processing: Watts Driving the Cost of AI Deploy- ment?” In Proceedings of the 2024 ACM Conference on Fairness, Accountability, and Transparency,85–99. FAccT ’24. Rio de Janeiro, Brazil: Association for Computing Machinery. ISBN : 9798400704505. https://doi.org/10.1145/ 3630106.3658542. https://doi.org/10.1145/3630106.3658542. Newsom, D. K., ...

arXiv 2024

[6] [11]

In Threat to Climate Safety, Michigan to Woo Tech Data Centers with New Laws

Proceedings 28,372–382. Springer. Perkins, T. n.d. “In Threat to Climate Safety, Michigan to Woo Tech Data Centers with New Laws.” [Online; ac- cessed 1-July-2024]. Poess, M., R. O. Nambiar, K. Vaid, J. M. Stephens Jr, K. Huppler, and E. Haines

work page 2024

[7] [14]

https://doi.org/10.25984/2329316

BUTTER-E - Energy Consumption Data for the BUTTER Empirical Deep Learning Dataset, December. https://doi.org/10.25984/2329316. https: //data.openei.org/submissions/5991. Tripp, C., J. Perr-Sauer, J. Gafur, A. Nag, A. Purkayastha, S. Zisman, and E. A. Bensen

work page doi:10.25984/2329316

[8] [15]

Measuring the Energy Consumption and Efficiency of Deep Neural Networks: An Empirical Analysis and Design Recommenda- tions

“Measuring the Energy Consumption and Efficiency of Deep Neural Networks: An Empirical Analysis and Design Recommenda- tions.” Preprint, arxiv, https://arxiv.org/abs/2403.08151. Verdecchia, R., J. Sallou, and L. Cruz

arXiv