Pith. sign in

REVIEW 3 major objections 4 minor 32 references

Evaluating MFU as a Proxy for GPU Power for Energy-Aware Simulation of LLM Training

T0 review · 3 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

Pith's one-line read Linear MFU model tracks GPU power in LLM training within ~1% error

desk verdict Solid, careful empirical study showing a per-(GPU, dtype, batch) linear MFU-power fit reaches the noise floor on NVIDIA GPUs; the main weakness is unvalidated telemetry on four of six devices. read the letter →

arxiv 2608.03880 v1 pith:ORMLQLYZ submitted 2026-08-04 cs.PF cs.DC

classification cs.PFcs.DC
keywords ModelFLOPsUtilizationGPUpowermodelingLLMtrainingsimulationenergy-awarecomputingNVMLROCmcompute-boundworkloadstelemetry
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

This paper tries to establish that Model FLOPs Utilization (MFU)—a software-calculable ratio of achieved throughput to a GPU's theoretical peak FLOPs—can stand in for hardware power telemetry when simulating LLM training. Across nearly 3,000 single-GPU training runs on six NVIDIA and AMD accelerators, a simple linear fit of MFU to vendor-reported power holds in compute-bound workloads, provided each (GPU, numerical precision, batch size) combination gets its own slope and intercept. That conditioning drops mean absolute percentage error from roughly 10% to about 1%, statistically indistinguishable from the noise between repeated runs on NVIDIA devices. The practical payoff would be that energy-aware simulators can predict power from an analytic metric they already compute, without reading vendor-specific counters.

What carries the argument

MFU, defined as (tokens per second × required FLOPs per token) divided by the hardware's per-precision peak FLOPS, is the central object: it is software-calculable, architecture-relative, and already produced by training and inference simulators. The argument's workhorse is ordinary least-squares regression of GPU-reported power on empirical MFU, with the key design choice being a separate slope and intercept per (GPU, numerical precision, batch size) cell. That conditioning, rather than any nonlinear model, is what takes error from roughly 10% to about 1% and down to the repeat-measurement noise floor.

What would settle it

Take one of the unvalidated GPUs (A100, L4, RTX 4070 Ti, or MI210), run the same (dtype, batch size) sweep while logging both vendor-reported power and an external wall-power meter, and check whether the per-cell linear MFU fit still lands within about 1% MAPE of the external measurement. A systematic offset or nonlinearity between internal and external readings would show up as a slope error or a residual floor well above the repeat-noise level, falsifying the portability claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that MFU—the ratio of achieved tokens-per-second times required FLOPs per token to a GPU's theoretical peak FLOPs—predicts GPU power draw linearly across compute-bound LLM training workloads on every accelerator tested. Nearly 3,000 controlled single-GPU runs spanning six devices (NVIDIA A100, L40, L4, Quadro RTX 5000, RTX 4070 Ti, AMD MI210), three model families, three precisions, seven batch sizes, and two context lengths support this. A single per-GPU linear fit yields roughly 10% mean absolute percentage error; conditioning the fit on (GPU, dtype, batch size) cuts error to about 1%, statistically indistinguishable from the cross-repeat measurement-noise floo

Load-bearing premise

The entire calibration chain trusts that the GPU's own reported power reading (NVML or ROCm) is an accurate measure of true power draw; the paper verifies this against an external meter on only two of the six GPUs, so a biased or nonlinear sensor on any other device would silently corrupt every fitted line.

Editorial extensions

If this is right

  • Simulators that already compute MFU (e.g., Vidur) can add per-GPU-calibrated power estimates without any hardware counters.
  • Supporting a new accelerator requires only a one-shot calibration sweep per (GPU, dtype, batch size) cell, after which power follows from MFU alone.
  • Energy-aware what-if comparisons for cluster scheduling and parallelization strategies become possible at roughly 1% per-cell accuracy in compute-bound training.
  • The model class transfers across vendors and precision modes, but slopes do not: each device needs its own fit because MFU is normalized by peak FLOPs.
  • Low-arithmetic-intensity workloads (batch 1, decode-style inference) fall outside the model's validity and need a complementary memory-bandwidth signal.

Reading between the lines

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

  • The same per-(dtype, batch) conditioning trick might transfer to LLM prefill phases, which are more compute-bound than decode, giving inference simulators a cheap power proxy beyond the training regime the paper measured.
  • Because the paper disabled fused attention kernels, the fitted slopes reflect eager attention; production kernels may shift slopes, but since calibration absorbs implementation variance, the linear model class likely survives—a testable prediction.
  • The ~1% error sitting at the measurement-noise floor implies that further model refinements inside a calibrated cell cannot help; gains must come from expanding coverage (more cells, a memory-bound signal) rather than more complex regressors.
  • Extending external wall-power validation to all six devices would test the weakest link: any hidden nonlinearity in A100, L4, RTX 4070 Ti, or MI210 vendor telemetry would change fitted slopes and could undermine the portability claim.
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.

Referee Report

3 major / 4 minor

Summary. The paper evaluates whether Model FLOPs Utilization (MFU), a software-defined analytical metric, can serve as a portable predictor of GPU power for LLM training simulation. The authors benchmark nearly 3000 single-device training runs across six GPUs (A100, L40, L4, Quadro RTX 5000, RTX 4070 Ti, MI210), three model families, three precisions, seven batch sizes, and two context lengths, with four repetitions per configuration. They report that per-GPU linear MFU-power fits achieve MAPE 3.5--13.7% and R² 0.37--0.84, and that conditioning on (GPU, dtype, batch size) reduces MAPE to about 1%, which they argue is at the cross-repeat measurement-noise floor on NVIDIA devices. They also document a memory-bound batch-1 regime where MFU under-predicts power, and they provide public code/data and an appendix validating internal telemetry against external wall power for two devices.

Significance. If the central claims hold, this is a useful result: MFU-based power modeling is directly integrable into simulators such as Vidur without vendor-specific hardware counters. The strengths of the paper are its controlled experimental protocol, the large number of runs, repeated measures, bootstrap confidence intervals, comparison against a noise floor, and public release of the benchmarking pipeline. The cross-vendor comparison (including the MI210 case where GPU Utilization is binary) is valuable. The paper is honest about several limitations: inference and decode are out of scope, distributed-training communication power is not modeled, and fused attention kernels are disabled. However, the central 'fits every GPU' and 'at the data limit' claims are currently supported only by on-board telemetry that is externally validated for two of the six GPUs, and the noise-floor comparison lacks uncertainty quantification. These issues are load-bearing and need to be addressed before the strong claims can be accepted.

major comments (3)
  1. [§II-C, Appendix A, Table III] The manuscript uses NVML/ROCm-reported power as the ground-truth signal for all six devices, but Appendix A validates this signal against external wall power only for the L40 and Quadro RTX 5000. The remaining four devices (A100, L4, RTX 4070 Ti, MI210) are never checked. This is not a minor omission: every fitted slope, MAPE, and the noise-floor comparison in Table III are built on this unvalidated signal. The MI210's cross-repeat SD of 0.20% (versus ≥0.35% on all NVIDIA devices) suggests possible sensor smoothing or quantization; if so, the 'residual matches the measurement noise' conclusion could be an artifact of an overly smooth sensor. Please either validate the telemetry on the remaining GPUs or substantially soften the claims to state that the noise-floor comparison applies only to the two externally validated devices.
  2. [Abstract, §IV-A, Table II] The abstract and takeaway claim that a linear MFU-based power model 'fits every tested GPU.' Table II reports R²=0.37 for the L4, which the text explains by the device's narrow power range (64 W idle floor, 72 W TDP, Section IV-A(c)). The low R² is then offset by the L4's low MAPE (3.5%), because there is little power variation to explain. This means 'fit' is being assessed by absolute error, not explained variance, and the L4 is at best a qualified exception. The manuscript should either state a single criterion for what constitutes a 'fit' (e.g., MAPE below a threshold) or explicitly present the L4 as an exception to the blanket claim.
  3. [§III-C, §IV-B(c), Table III] The claim that the conditioned model is 'statistically indistinguishable' from the cross-repeat noise floor on the RTX 4070 Ti and L4 is not supported by inferential statistics. Table III reports point estimates of the per-cell residual SD and the repeat-noise SD, but no confidence intervals, significance tests, or agreement metrics are given. With only four repeats per configuration and six observations per (GPU, dtype, batch) cell, these SD estimates are themselves noisy, and the bootstrap used for MAPE is not applied to the residual SD comparison. Please provide bootstrap CIs or an equivalent uncertainty analysis for the SD ratio, or replace 'statistically indistinguishable' with the weaker statement that the residual is of the same order of magnitude as the repeat noise.
minor comments (4)
  1. [§II-B] The formula for C_req uses notation like 'L_num', 'H_num', 'Q_dim', 'T_seq' that is not fully defined in the text. Please define each symbol or point to the referenced source more explicitly. A typo check is also needed: 'N_um' appears to be a leftover fragment.
  2. [§IV-A(a)] The slope values (1.21 W/% on MI210 to 4.49 W/% on A100) are useful, but could be presented in a small table or annotated figure for easier cross-device comparison.
  3. [Appendix A] The validation figure shows a linear relationship between GPU-reported power and external node-level power, but the text does not state whether the external measurement is node-level or GPU-only, nor the sampling alignment between the two signals. Please clarify the measurement setup and the meaning of the constant offset.
  4. [Abstract] The paper says 'almost 3000 runs.' Given the exclusions (Quadro RTX 5000 lacks bf16, L4 has one excluded cell), it would be more precise to state the exact number of completed runs or the number of configurations, so readers can verify the denominator in the error statistics.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: MFU and power are independently measured, and the fits are calibrated regressions with explicit in-sample noise-floor comparison.

full rationale

The paper's central claim is empirical and self-contained. MFU is computed from measured throughput and model FLOP counts (CalFLOPS), while the power signal comes from independent NVML/ROCm telemetry. The linear fits are ordinary least squares of GPU-reported power on MFU (Section III-C: 'All linear fits in Section IV are ordinary least squares of GPU-reported power on the empirical (CalFLOPS-based) MFU'), so the target quantity never appears in the predictor. The paper explicitly labels the ~1% MAPE as an in-sample number and compares residuals to the cross-repeat measurement-noise floor (Section IV-B-c), which is the honest statistical treatment of a calibrated model rather than a disguised prediction. The two self-citations ([13], Özcan/Wiesner et al. on MFU-based power in Vidur; [32], Vessim) are contextual and not load-bearing: the paper explicitly notes that [13] is not validated against hardware power, which is the gap this paper fills, not a circular support. The limitation that external wall-power validation was performed only on two of six GPUs (Appendix A) is a measurement-validity and correctness concern about sensor ground truth, not a circularity: it does not make any derivation reduce to its own inputs. No equation, fitted parameter, or uniqueness claim is imported from the authors' prior work, and no ansatz is smuggled in via citation. The derivation chain is therefore independent and non-circular.

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

The paper's central contribution is empirical: the model is a set of linear regressions. The free parameters are the fitted slopes and intercepts per GPU and per (GPU, dtype, batch) cell. No new physical entities are introduced. The main axioms are the domain assumptions about compute-boundedness, the FLOP-count approximation, and the accuracy of vendor power telemetry.

free parameters (3)
  • Per-(GPU, dtype, batch) linear slope a_{g,d,b} = OLS fit, not listed individually
    Section IV-B: a separate slope is fitted per (GPU, dtype, batch) cell to predict power from MFU. These are empirical fit parameters.
  • Per-(GPU, dtype, batch) intercept b_{g,d,b} = OLS fit, not listed individually
    Section IV-B: each cell also gets its own intercept. The intercept absorbs idle power and per-cell offsets.
  • Per-GPU linear slope and intercept = Range 1.21 to 4.49 W per percent MFU across GPUs
    Section IV-A: a single per-GPU linear fit is reported in Table II and used for the MAPE comparison and the batch-1 analysis.
assumptions (4)
  • domain assumption Power is approximately linear in MFU within compute-bound training regimes.
    Section IV-A states this as the central empirical hypothesis being tested. It is not derived from physics; the paper fits it to data.
  • domain assumption CalFLOPS with a 3x forward multiplier accurately estimates training FLOPs.
    Section III-B: training FLOPs are approximated as 3x forward FLOPs, following the standard 1:2 forward-to-backward ratio. An error in this multiplier shifts MFU values and slopes but may preserve linearity.
  • domain assumption Vendor-reported power (NVML/ROCm) is an accurate ground-truth signal.
    Section II-C and Appendix A: validated against external wall power for only the L40 and Quadro RTX 5000. The other four devices are unvalidated.
  • domain assumption Batch-1 configurations can be treated as outside the compute-bound regime and are handled by the per-cell fit.
    Section IV-C: batch-1 is described as memory-bound and breaks the single-slope fit. The choice to condition on batch size separates this regime instead of modeling it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Evaluating MFU as a Proxy for GPU Power for Energy-Aware Simulation of LLM Training." pith.science (2026). https://pith.science/paper/ORMLQLYZ

@misc{pith2026260803880,
  author       = {Pith},
  title        = {Pith review of: Evaluating MFU as a Proxy for GPU Power for Energy-Aware Simulation of LLM Training},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ORMLQLYZ}},
  note         = {Machine review of arXiv:2608.03880}
}
read the original abstract

High-fidelity performance simulators are essential for designing and configuring efficient AI systems, yet today's tools lack the ability to predict power consumption. Established GPU power models rely on hardware utilization counters, which do not exist until the workload has actually run. This work evaluates whether Model FLOPs Utilization (MFU)-an analytical, software-defined metric relating achieved throughput to peak hardware capability-can serve as a portable, software-defined predictor of GPU power for LLMs. We benchmark almost 3000 single-device training runs across six GPUs, covering different model families, numerical precisions, batch sizes, and context-window lengths. We find that a linear MFU-based power model fits every tested GPU as long as the workload is compute-bound, as in production LLM training. Fitting per-(GPU, dtype, batch size) instead of per-GPU drops the within-cell mean error from around 10% to around 1%, matching the cross-repeat measurement-noise floor.

Figures

Figures reproduced from arXiv: 2608.03880 by the authors.

Figure 1
Figure 1. MFU and GPU Utilization versus GPU-reported power. The MI210 [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 3
Figure 3. Distribution of per-sample absolute relative error for linear regressions [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Predicted versus measured GPU power, where the prediction is the [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: GPU-reported vs. external hardware-based power measurements for [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

32 extracted references · 28 canonical work pages

  1. [13]

    Quantifying the energy consumption and carbon emissions of LLM inference via simulations,

    M. ¨Ozcan, P. Wiesner, P. Weiß, and O. Kao, “Quantifying the energy consumption and carbon emissions of LLM inference via simulations,” inWorkshop on Performance and Energy Efficiency in Concurrent and Distributed Systems (PECS) at Euro-Par ’25, 2025

  2. [1]

    Double-exponential increases in inference energy: The cost of the race for accuracy,

    Z. Yang, K. Adamek, and W. Armour, “Double-exponential increases in inference energy: The cost of the race for accuracy,”arXiv preprint arXiv:2412.09731, 12 2024

  3. [2]

    GPU-NEST: Characterizing energy efficiency of multi-GPU inference servers,

    A. Jahanshahi, H. Z. Sabzi, C. Lau, and D. Wong, “GPU-NEST: Characterizing energy efficiency of multi-GPU inference servers,”IEEE Computer Architecture Letters, vol. 19, no. 2, pp. 139–142, 7 2020

  4. [3]

    Energy and AI,

    I. E. Agency, “Energy and AI,” International Energy Agency, Tech. Rep., 4 2025. [Online]. Available: https://www.iea.org/reports/energy-and-ai

  5. [4]

    Comparative study of hardware and software power measurements in video compression,

    A. Katsenou, X. Wang, D. Schien, and D. Bull, “Comparative study of hardware and software power measurements in video compression,” in 2024 Picture Coding Symposium (PCS), 2 2024

  6. [5]

    Environmental report 2024,

    Google, “Environmental report 2024,” Google, Tech. Rep., 7 2024. [Online]. Available: https://www.gstatic.com/gumdrop/sustainability/g oogle-2024-environmental-report.pdf

  7. [6]

    Vidur: A large-scale simulation frame- work for llm inference,

    A. Agrawal, N. Kedia, J. Mohan, A. Panwar, N. Kwatra, B. Gulavani, R. Ramjee, and A. Tumanov, “Vidur: A large-scale simulation frame- work for llm inference,”Proceedings of Machine Learning and Systems, vol. 6, pp. 351–366, 2024

  8. [7]

    SimuMax: A simulator for distributed LLM training,

    Moore Threads, “SimuMax: A simulator for distributed LLM training,” https://github.com/MooreThreads/SimuMax, 2025

Show all 32 references
  1. [8]

    LLM Cluster Simulator: Interactive distributed training and inference planning,

    A. Zhebrak, “LLM Cluster Simulator: Interactive distributed training and inference planning,” 2026, browser-based simulator for GPU cluster parallelism strategies, calibrated against published benchmarks from Meta, DeepSeek, and NVIDIA. [Online]. Available: https: //github.com...

  2. [9]

    The one-token model,

    Antarctica, “The one-token model,” 12 2025, whitepaper. [Online]. Available: https://antarctica.io/research/one-token-model

  3. [10]

    Understanding gpu power: A survey of profiling, modeling, and simulation methods,

    R. A. Bridges, N. Imam, and T. M. Mintz, “Understanding gpu power: A survey of profiling, modeling, and simulation methods,”ACM Com- puting Surveys, vol. 49, no. 3, pp. 41:1–41:27, 2016

  4. [11]

    PaLM: scaling language modeling with pathways,

    A. Chowdhery, S. Narang, J. Devlin, M. Bosma, G. Mishra, A. Roberts, and P. Barham, “PaLM: scaling language modeling with pathways,” Journal of Machine Learning Research, vol. 24, no. 1, pp. 11 324– 11 436, 1 2023

  5. [12]

    Vidur: A large-scale simulation frame- work for LLM inference,

    A. Agrawal, N. Kedia, J. Mohan, A. Panwar, N. Kwatra, B. S. Gulavani, R. Ramjee, and A. Tumanov, “Vidur: A large-scale simulation frame- work for LLM inference,” inProceedings of Machine Learning and Systems (MLSys), 2025

  6. [14]

    Extracting practical, actionable energy insights from supercomputer telemetry and logs,

    M. Cornelius, G. Cross, S. Shilpika, M. T. Dearing, and Z. Lan, “Extracting practical, actionable energy insights from supercomputer telemetry and logs,” inSC ’25: International Conference for High Performance Computing, Networking, Storage and Analysis, 11 2025

  7. [15]

    [Online]

    NVIDIA,nvidia-smi Documentation, NVIDIA Corporation, 2025. [Online]. Available: https://docs.nvidia.com/deploy/nvidia-smi/index.ht ml

  8. [16]

    Using model FLOPs utilization (MFU),

    J. Ray, “Using model FLOPs utilization (MFU),” 5 2025, medium article. [Online]. Available: https://medium.com/better-ml/using-model- flops-utilization-mfu-7b17de07faec

  9. [17]

    X. Ye. (2023) calflops: a flops and params calculate tool for neural networks in pytorch framework. [Online]. Available: https: //github.com/MrYxJ/calculate-flops.pytorch

  10. [18]

    Monitoring and characterizing GPU usage,

    L. M. Weakley, S. Michael, L. Huber, A. Thota, B. Fulton, and M. Kusz, “Monitoring and characterizing GPU usage,”Concurrency and Computation: Practice and Experience, vol. 37, no. 3, 1 2025

  11. [19]

    Accurate and convenient energy measurements for GPUs: A detailed study of NVIDIA GPU’s built-in power sensor,

    Z. Yang, K. Adamek, and W. Armour, “Accurate and convenient energy measurements for GPUs: A detailed study of NVIDIA GPU’s built-in power sensor,” inSC ’24: International Conference for High Performance Computing, Networking, Storage and Analysis, 11 2024, pp. 1–17

  12. [20]

    An experimental comparison of software-based power me- ters: Focus on CPU and GPU,

    M. Jay, V . Ostapenco, L. Lefevre, D. Trystram, A.-C. Orgerie, and B. Fichel, “An experimental comparison of software-based power me- ters: Focus on CPU and GPU,” inProceedings of the 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid),...

  13. [21]

    High-resolution power profiling of GPU functions using low-resolution measurement,

    J. Lang and G. R ¨unger, “High-resolution power profiling of GPU functions using low-resolution measurement,” inEuro-Par 2013 Par- allel Processing, ser. Lecture Notes in Computer Science, vol. 8097. Springer, 8 2013, pp. 801–812

  14. [22]

    Scaling laws for neural language models,

    J. Kaplan, S. McCandlish, T. Henighan, T. B. Brown, B. Chess, R. Child, S. Gray, A. Radford, J. Wu, and D. Amodei, “Scaling laws for neural language models,”arXiv preprint arXiv: 2001.08361, 2020

  15. [23]

    Pytorch: An imperative style, high-performance deep learning library,

    A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antigaet al., “Pytorch: An imperative style, high-performance deep learning library,”Advances in neural information processing systems, vol. 32, 2019

  16. [24]

    Transformers: State-of-the-art natural language processing,

    T. Wolf, L. Debut, V . Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowicz, J. Davison, S. Shleifer, P. von Platen, C. Ma, Y . Jernite, J. Plu, C. Xu, T. Le Scao, S. Gugger, M. Drame, Q. Lhoest, and A. Rush, “Transformers: State-of-the-art natura...

  17. [25]

    Hydra - a framework for elegantly configuring complex applications,

    O. Yadan, “Hydra - a framework for elegantly configuring complex applications,” Github, 2019. [Online]. Available: https://github.com/fac ebookresearch/hydra

  18. [26]

    Hardware scaling trends and diminishing returns in large-scale distributed training,

    J. Fernandez, L. Wehrstedt, L. Shamis, M. Elhoushi, K. Saladi, Y . Bisk, E. Strubell, and J. Kahn, “Hardware scaling trends and diminishing returns in large-scale distributed training,”arXiv preprint arXiv:2411.13055, 11 2024

  19. [27]

    Understanding gpu resource interference one level deeper,

    P. Elvinger, F. Strati, N. E. Jerger, and A. Klimovic, “Understanding gpu resource interference one level deeper,” inACM Symposium on Cloud Computing (SoCC), 2026

  20. [28]

    Data-driven analysis to understand GPU hardware resource usage of optimizations,

    T. Z. Islam, A. Marathe, H. Schutte, and M. Zaeed, “Data-driven analysis to understand GPU hardware resource usage of optimizations,”arXiv preprint arXiv:2408.10143, 8 2024

  21. [29]

    Accelwattch: A power modeling framework for modern gpus,

    V . Kandiah, S. Peverelle, M. Khairy, J. Pan, A. Manjunath, T. G. Rogers, T. M. Aamodt, and N. Hardavellas, “Accelwattch: A power modeling framework for modern gpus,” in54th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2021

  22. [30]

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

    R. Desislavov, F. Mart ´ınez-Plumed, and J. Hern ´andez-Orallo, “Trends in AI inference energy consumption: Beyond the performance-vs- parameter laws of deep learning,”Sustainable Computing: Informatics and Systems, vol. 38, p. 100857, 2 2023

  23. [31]

    Lumos: Efficient performance modeling and estimation for large- scale LLM training,

    M. Liang, H. T. Kassa, W. Fu, B. Coutinho, L. Feng, and C. Delimitrou, “Lumos: Efficient performance modeling and estimation for large- scale LLM training,” inProceedings of Machine Learning and Systems (MLSys), 2025

  24. [32]

    Vessim: A testbed for carbon-aware applications and systems,

    P. Wiesner, I. Behnke, P. Kilian, M. Steinke, and O. Kao, “Vessim: A testbed for carbon-aware applications and systems,”ACM SIGENERGY Energy Informatics Review, vol. 4, no. 5, 2024

Pith tools

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