# Alumet: a Modular Framework to Standardize the Measurement of Energy Consumption

Guillaume Raffin, Denis Trystram, Olivier Richard

► To cite this version:

Guillaume Raffin, Denis Trystram, Olivier Richard. Alumet: a Modular Framework to Standardize the Measurement of Energy Consumption. PECS 2025 - Workshop on Performance and Energy Efficiency in Concurrent and Distributed Systems, TÜD Dresden University of Technology, Aug 2025, Dresden, Germany. pp.1-12. [hal-05246933](https://hal.science/hal-05246933v1)

HAL Id: hal-05246933

https://hal.science/hal-05246933v1

Submitted on 9 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Alumet: a Modular Framework to Standardize the Measurement of Energy Consumption

Guillaume Raffin¹,²[0009-0009-9156-121X], Denis Trystram¹[0000-0002-2623-6922], and Olivier Richard¹[0009-0005-8679-2874]

¹ Univ. Grenoble Alpes, CNRS, Inria, Grenoble INP, LIG, 38000 Grenoble, France
{name.surname}@univ-grenoble-alpes.fr

² Bull SAS, 78340 Les Clayes-sous-Bois, France
{name.surname}@eviden.com

**Abstract.** The increasing energy consumption of ICT (Information and Communication Technology) has become an important concern driven by the growing demand for computational resources.

Measuring the energy consumption is becoming essential to make users aware of their impact, comply with new regulations, compare different solutions and optimize systems. This need has led to the development of various software tools that aim to measure or estimate the energy consumed by a piece of hardware or software. However, existing tools are often very limited in scope, offer too few options to the users, can consume too many resources, may return erroneous data, and have architectures that hinder their progress over time.

This paper introduces Alumet, a novel framework designed to offer an extensible standard for energy measurement in a wide range of scenarios. With Alumet, it becomes possible to build made-to-measure measurement tools without the need to redevelop everything from scratch. A generic pipeline enables the gathering, transformation and export of any type of measurement. A plugin system allows to support new environments and new models without modifying the framework, thus making it ready for future innovations.

With multiple experiments, we show that Alumet can be deployed in varying contexts, on different hardware and software stacks. The benchmarks reveal that our new tool can facilitate the development of estimation models while reducing the overhead of energy monitoring and supporting higher acquisition frequencies.

**Keywords:** Energy consumption · Energy measurement · Distributed computing · HPC · Cloud computing · Kubernetes · Rust · Software architecture · Performance evaluation

# 1 Introduction

## 1.1 Context

Information and communication technologies (ICT) consume more and more resources. In particular, the energy required to build and use digital devices is
growing exponentially [1, 2, 3, 4]. The digitization of our societies has led to a
continuous acceleration, currently boosted by the development of generative AI.
In 2020, the ICT sector accounted for around 4-5% of the global primary energy
consumption and for 3-4% of the global greenhouse gases (GHG) emissions [5].

In this context, we have seen the community work on energy efficiency, in an
attempt to accomplish the same tasks with less resources. Beyond efficiency, one
can also question the means with regards to the results: is it worth it to spend
these resources in this way? Are the users aware of the impact of the services
they use? Answering these questions require to measure the energy consumed
by digital systems. Not only do we need to measure the energy consumed by the
hardware, but also to measure how the hardware is used by the software.

## 1.2 Motivation

This need to rely on quantitative data has led to the multiplication of tools that measure the energy consumption. A first possibility to obtain that information is to query a dedicated device, often from outside of the node. Such devices include external wattmeters, PDUs (Power Distribution Units) and BMCs (Baseboard Management Controllers). While they provide valuable data, they cannot see through the hardware and have no information about the software. Furthermore, external devices require an additional financial investment. BMCs are shipped with servers, but their power measurement capabilities are limited. They offer a low acquisition frequency (typically 0.1 Hz) and are not user friendly.

A second possibility is to use embedded sensors that are accessible from the operating system. By querying kernel interfaces or calling a vendor-provided library, a software that runs on the node can obtain the energy consumption of some hardware components. A well-known in-band measurement technology is RAPL (Running Average Power Limit), which allows to obtain the consumption of the CPU sockets, among others [6]. Similar techniques are available on NVIDIA and AMD GPUs [7, 8]. Because they provide better granularity and easier access, in-band techniques have been used to create multiple software tools, which are sometimes called "software powermeters" (see Section 2). Unfortunately, recent work points out that the current landscape of software powermeters is not entirely satisfying [9, 10].

First, important choices are too often hidden from the users, who lack control over the tool. For instance, the formulas that are applied to compute indicators, such as GHG emissions, are rarely explicit. Another example is the acquisition frequency, whose choice is restricted to a narrow range or even a hard-coded constant [9]. This kind of issue is listed as one of the key limitations of software powermeters in the recent AFNOR Specification on frugal AI [11]. Second, existing tools are limited to a specific combination of hardware and software. Some will only read RAPL counters, or only perform an estimation on some edge devices, or only work on clusters that use a particular software stack such as Kubernetes. Despite this specialization, some of the most popular tools exhibit a non-negligible overhead and have subtle bugs that skew the measurements [10]. Third, it is difficult or impossible to change some key components of the tools,
such as the models that attribute the energy consumed by the hardware to the software, or the format that is used to save the data. This forces researchers to develop new tools when they have new hypotheses to test.

## 1.3 Contributions

In order to overcome the limitations and pitfalls of the existing tools, we developed a new measurement framework with an emphasis on modularity. We call it Alumet, for *Adaptive, Lightweight, Unified METrics*. Instead of building one tool for each combination of hardware and software, or assembling a cumbersome monolith with every combination, we provide a generic and modular solution. Thanks to a plugin system, it can be easily adapted to many different environments. It also makes it easier to experiment with new measurement techniques and attribution or estimation models, since plugins can be added or removed independently. Alumet is a free and open-source project, available on GitHub 3. It is written in Rust and involves academic and industrial contributors.

In this paper, we first present the base measurement framework. Then, we experimentally demonstrate that the software powermeters built on this framework can be easily deployed on a variety of hardware devices and software stacks. We show how it is possible to build a flexible measurement system without sacrificing performance. Our experiments on single nodes and multi-region clusters show that Alumet is more efficient than the well-known high-level measurement tools, in spite of its broader scope and greater flexibility.

# 2 Related works

## 2.1 Exploration of the low-level interfaces

With RAPL, Intel and AMD processors provide reliable measurements of the energy consumed by the CPU socket and other parts [12, 13, 14] (depending on the CPU and motherboard). There are multiple mechanisms that can be implemented to read the values provided by RAPL. We followed the recommendations of prior work [10] in our choice and implementation of the mechanisms. On the GPU side, the energy consumption reported some models of NVIDIA GPUs is less accurate than the 5% claimed by the documentation [7], but a correction can be applied [15, 16]. These studies evaluated the workings of the low-level in-band interfaces. They did not aim to offer a software architecture for a generic software powermeter.

## 2.2 Existing software powermeters

The following tools already provide means to obtain the energy consumption of some hardware components, and to couple it with information about the software than run on top of the hardware.

<footnote n="3">3 https://github.com/alumet-dev/alumet (EUPL-1.2 license)</footnote>
Scaphandre [17] is a well-known energy monitoring tool that only supports RAPL power readings. We met Scaphandre's author and tried to implement GPU support. Unfortunately, we found that it was actually impossible without rewriting most of the code, because Scaphandre's internals are not generic.

PowerJoular [18], MojitO/S [19], EA2P [20] and NVML-sensor [21] support both RAPL and NVML, but are fundamentally monolithic. Adding new metrics, models or outputs require to tweak the main source code of the tools. PowerJoular and EA2P call high-level tools like **nvidia-smi** and parse their text output, which is less stable and less efficient than using the NVML API.

CodeCarbon [22] provides a Python API to instrument the code. It also uses RAPL and NVML, but allows to tie the duration of the measurement operation to specific lines of code. It is limited to per-component energy measurements.

PowerAPI [23] aims to be more modular and clearly separates sources from models through an intermediate database. It enabled the creation of a statistical model that provides good estimates of the energy consumed by a device without RAPL access [24]. The authors focused on the modeling part and did not provide a generic API for the reading or writing operations: if you need to implement a new sensor or exporter, you have to do it from scratch. Moreover, the toolkit uses several serialization/deserialization steps, which has a performance cost.

A previous project by the same team, WattsKit [25], offered an API in Scala to build a software powermeter by choosing its components. This idea seems closer to what we offer with Alumet. However, all the components were defined in a monolithic tool, and the project appears to have been abandoned.

Kepler [26] is a measurement tool for Kubernetes clusters. It uses in-band measurement if possible, or a statistical estimation model otherwise. Its architecture is quite complex, and only the models are easily replaceable.

## 2.3 Reviews of powermeters

Heguerte et al. [27] reviewed some of the aforementioned tools in the context of assessing the energy consumption and environmental footprint of AI models. Jay et al. [9] compared multiple software powermeters on CPUs and GPUs, in a broader context. In general, while they can be used to obtain valuable information, they suffer from a lack of controllability and extensibility. This makes them harder to use for rigorous experiments and difficult to adapt to the evolution of software and hardware.

# 3 Generic measurement framework

## 3.1 Objectives

To overcome the limitations of the existing tools and unlock new academic and industrial uses, we have designed a new measurement framework. Here, we use the term "framework" to refer to two complementary ideas: first, a scientific framework that unifies different measurement scenarios under a common model;
second, a software framework in the form of a library on top of which new
measurement tools can be developed. The framework we offer aims to achieve
the following goals:

- **Genericity**: we want the framework to be hardware-agnostic and software-agnostic, which means that it should work on Edge devices and HPC blades alike, whether the applications are deployed with Kubernetes, a traditional HPC scheduler, or a bare-metal Linux.

- **Modularity**: the risk of supporting many different hardware and software components is to end up with a bloated, unmaintainable monolith. To avoid that, we propose a modular framework based on plugins. We want to enable the independent development of plugins outside of the core of the project.

- **Rigor**: in light of the pitfalls detected by previous studies in existing tools [9] [10], we want to provide incentives for good practices. First, we want to enforce a proper definition of the measurement perimeter: what are we measuring? At which level? (hardware/OS/container/process?) Second, we aim to provide reusable code bricks to handle common problems. Third, we want to catch common mistakes at compile time.

- **Efficiency**: the overhead of the tool must be sufficiently small, even at high frequencies. There is a double goal here: to avoid wasting compute power and electricity, and to limit the influence of the tool on the energy measurements.

To reach these goals, we have built Alumet around three key features: a unified data model that standardize the measurements, a generic pipeline that efficiently implements the model, and a plugin system that enables extensibility.

## 3.2 Unified data model

To gather measurements from different sources, we need a model that accom-
modates different measurement mechanisms, types and perimeters. To do that,
we propose two basic bricks: generic measurement points, and generic metrics.

A measurement point represents the result of one measurement operation. It contains: a **timestamp**; a **value**; a **metric**, which indicates what kind of information has been measured; a **resource**, which is the component that has been measured (usually a piece of hardware, such as a CPU core); and a **consumer**, which is the software component that used the resource. Together, the *metric*, *resource* and *consumer* clearly communicate the perimeter of the measurement. They enable the creation of generic attribution formulas, as presented in Section 4.1. The model remains open by accepting an arbitrary number of **attributes** (key-value pairs). A metric is defined by a **name**, a **value type**, a **measurement unit** and other metadata. When possible, we check at compile time that the measured values have the same type as their metric. To avoid duplicating information, each metric is stored in a global registry and associated with a unique integer id. Instead of storing the definition in each measurement point, we store the id. This model is simple but not simplistic. It is similar to the OpenTelemetry<fnref n="4" /> model but with an emphasis on the measurement perimeter.

<footnote n="4">⁴ A collection of telemetry APIs, SDKs, and tools - https://opentelemetry.io</footnote>
## 3.3 Generic asynchronous measurement pipeline

On top of the unified data model, let us build a generic measurement pipeline with three steps: gather the measured values from the *sources*, process the data with *transform functions* (which we simply call *transforms*), and write it to the *outputs*. A naive approach would be to perform these steps one after another, in a single loop with a *sleep* at the end. This would be far from ideal for several reasons. First, it would impose a single acquisition frequency on all the sources. Second, a slowdown of a single element would impact the whole pipeline. The most expensive ones (e.g. an output that writes to a database) would become a bottleneck. Third, *sleep* is unreliable for small durations [10].

To overcome these limitations, we designed a concurrent pipeline based on Rust asynchronous facilities. Its architecture is depicted on Figure 1. Each source and output is encapsulated in an asynchronous task, which is scheduled to run on a pool of threads. The tasks are connected by queues. If a task fails or slows down, it does not affect the others. On top of a better resilience, this design offers more configuration freedom, since each source can use a different timer. Alumet timers are backed by *timerfd*, and the thread priority is automatically adjusted to increase their accuracy. We tested that the sources were triggered at the right frequency up to 10 kHz, with a per-call error of just a few microseconds. This is a clear improvement over existing tools, whose frequency is often limited.

Unlike sources and outputs, transforms are consolidated in a single task and share the same buffer. This facilitates chaining by allowing each transform to read and modify the result of the previous one. Transforms and outputs often need the full definition of the metrics. Therefore, we give them access to a shared context that allows to use the metric registry presented in Section 3.2.

Interestingly, this architecture does not decrease performance in simple scenarios. With one RAPL source and one CSV output flushed every 10 seconds, the overhead of Alumet is negligible. We ran the CPU version of the HPCG benchmark on all available cores, and measured its slowdown depending on the source configuration. At 1 kHz, the average slowdown was 1.2% on an AMD EPYC 9354 CPU and 2.6% on an Intel Xeon 6448Y CPU. Under 1 kHz, it was below the error margin. By comparison, we ran a modified version of Scaphandre with equivalent features and got a significant slowdown at only 50 or 100 Hz.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Architecture of the asynchronous measurement pipeline (elements in orange are provided by plugins, see Section 3.4)</figcaption></figure>
## 3.4 Plugin system

The last piece of the puzzle is the plugin system, which makes Alumet extensible. By design, it is the plugins that perform the "useful work". As illustrated by Figure 1, the framework, by itself, contains no source, no transform, and no output. It only provides what is necessary to build them (the plugin API) and to run them together in a coherent way (the pipeline).

On startup, each plugin adds new elements to the pipeline, and Alumet connects them together. This is radically different from the usual software pow-ermeters, where one of the operations (often the measurement, sometimes the models) is at the core of the tool and the rest is hard-coded alongside of it. As far as we know, none of the existing tools we mentioned in Section 2 allows every part of the measurement pipeline to be developed independently on top of a standard framework. Not only does the plugin API specify how measurements and metrics must be defined, it also provides generic interfaces (in the form of Rust traits) to implement sources, transforms and outputs, and generic tools for common situations. The plugin API is deliberately very open. For instance, plugins are not restricted to a specific "type". This allows external tools to be integrated with Alumet, which then acts as an abstraction layer.

The actual software that you can use is produced by compiling the core library (the framework), the plugins (each plugin is its own library) and the main code in a single standalone binary. We call it the Alumet "agent". At the time of submission of this paper, we provide a standard agent with 12 plugins, resulting in a binary of about 16 MB. Tailor-made agents can be created to customize it. Alumet agents work out of the box, because the core demands that each plugin declare default configuration values. Plugins can be individually enabled or disabled, and the configuration can be tweaked by editing a TOML file or passing command-line arguments. Users hence stay in control of the tool.

# 4 Experiments

## 4.1 Energy attribution as a customizable transform function

Because the hardware is shared, obtaining the energy consumption of individ-ual processes or containers requires a model that attributes the consumption of the hardware to the software. On the CPU, a basic attribution model consists in dividing the total energy consumed by the CPU sockets among the running processes, in proportion of their CPU usage. A similar model can be designed for GPUs, but its implementation in existing tools requires a separate code. Sometimes, it is even necessary to write a new measurement tool. With Alumet, it becomes possible to implement a generic model for CPU and GPU alike, by writing a transform function that computes Equation (1). We leverage the *re-source* and *consumer* fields of the measurement points, presented in Section 3.2, to abstract over the hardware and software components.

$$ \hat{e}(C, R, \Delta t) = e_R(\Delta t) \times \frac{u_R(C, \Delta t)}{\Delta t} \qquad (1) $$
The estimated energy consumption of a consumer *C* on a resource *R*, during a period of time *Δt*, is given by the energy consumed by this resource *e*<sub>*R*</sub>(*Δt*) multiplied by the percentage of use of *R* by *C*. If the measurements that are used come from different unsynchronized sources, the implementation buffers the data and applies a linear interpolation before computing the formula.

<caption>**Listing 1.1.** Configuration for attributing the CPU consumption to the processes</caption>

1. `attribution_formula` = "e_r * u_r / dt"
2. `res` = { `metric` = "process_energy", `unit` = "J", `type` = "f64" }
3. `resource` = { `kind` = "CpuPackage", `aggregate` = "sum" } # R
4. `e_rmetric` = "rapl_consumed_energy" # where to find e_R
5. `u_rmetric` = "procfs_process_cpu_time" # where to find u_R(C)

As shown in Listing 1.1, the formula is defined in a configuration file. It is read by a dedicated Alumet plugin, which creates a transform to compute the formula for each relevant resource and consumer. This allows researchers to tweak the formula without changing the code. For instance, one pitfall of Equation (1) is that it ignores the idle consumption of *R*. Fixing this issue is not difficult: after a calibration phase, we edit the configuration to subtract an additional term from $\hat{e}(C, R, \Delta t)$. One could even automate the calibration by writing an additional plugin. This reveals the potential of our proposal for experimenting with new models. Models also become easy to share and easy to inspect.

## 4.2 Comparison to a Kubernetes-oriented measurement solution

We installed Alumet on a 4-nodes Kubernetes cluster. The nodes were servers equipped with an Intel Xeon D-2183IT CPU and a Tesla 4 GPU. In a single command (thanks to a Helm chart), we deployed one agent per node, plus an InfluxDB database on the master node. On the worker nodes, we used the *relay* client plugin, which adds an output that sends every measurement to the server, using a binary protocol built on TCP. On the master node, we used the *relay* server plugin, which adds a source that reads the measurements sent by the clients and passes them to the rest of the pipeline.

On the same cluster, we deployed Kepler [26] (chart version 0.5.11), a software powermeter dedicated to Kubernetes. Kepler agents exposed their measurements to a local Prometheus exporter, which was scraped periodically by the Prometheus server. Prometheus is fundamentally pull-based, whereas our *relay* approach is push-based. We found that Kepler offered few options. In particular, the measurement interval was restricted to either 3 seconds or 30 seconds. We set Kepler's interval to 30 seconds and Alumet's interval to 1 second.

To compare the values of the measurements, we deployed both tools at the same time and ran the CPU-bound version of the HPCG benchmark [28] for two minutes, on all available cores. Figure 2 shows the energy consumed by HPCG, Alumet and Kepler, as estimated by both tools. Because RAPL was available, Kepler used a power ratio model similar to Equation (1). As expected, the values
reported by both tools for the HPCG benchmark are close (green curves). We observe that Kepler suffers from a delay and a lack of granularity, probably caused by its low acquisition frequency. Both Alumet and Kepler attribute more energy consumption to Kepler (blue curves) than to Alumet (red curves). Furthermore, while the Alumet agent is a standalone binary, Kepler relies on Prometheus and injects programs into the kernel, which is not taken into account in Figure 2.

To further evaluate the overhead of each tool, we measured the performance degradation that they induced on the HPCG benchmark, first on the CPU, then on the GPU. On the CPU, the benchmark used all available cores. On the GPU, it used a single CPU core that scheduled the work on the GPU. We first executed the benchmark alone for 30 minutes: only the mandatory pods were running on the nodes alongside the benchmark. Then, we deployed Alumet with a frequency of 1 Hz and repeated the experiment. Finally, we removed Alumet, installed Kepler (with a frequency of 0.033 Hz), and repeated the experiment. Each run was repeated 20 times. Outliers were removed to produce the figures, but we checked that they did not significantly change the results. On the GPU side, neither Alumet nor Kepler affected the GPU version of HPCG. This is probably because both tools perform all their work on the CPU, and probe the GPU at a relatively low frequency, which doesn't interfere with its work. On the CPU side, the difference is significative. As shown in Figure 3, Alumet has a smaller impact on the CPU-bound benchmark than Kepler, despite its higher frequency. On the first two workers, the benchmark runs, on average, 0.32% slower when Alumet is deployed, and 1.46% when Kepler is deployed. The impact is bigger on the third worker, where Alumet's overhead is 0.66% and Kepler's 7.38%. This can be explained by three factors. First, the third worker is located on a different site, which increases the cost of communicating with the orchestrator and the Alumet/Prometheus server. Second, this node was more prone to network errors, which forced the measurements to be sent multiple times. Third, Kepler automatically installed some additional services that were assigned to this worker, such as the Prometheus alert manager. Regardless of the differences between the nodes, the results indicate that Alumet is more lightweight than Kepler.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Energy consumption of some pods, as estimated by Alumet and Kepler</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** HPCG benchmark performance (CPU-bound) depending on the measurement tool and worker node.</figcaption></figure>
## 4.3 Measurement validation and limit testing on bare-metal nodes

To validate the source plugins, we installed Alumet on HPC nodes with CPUs (Intel and AMD) and GPUs (NVIDIA and AMD), laptops (with Intel CPUs), and NVIDIA Jetson Xavier edge devices. The utilization and energy metrics were coherent with the official tools perf, nvidia-smi, amd-smi and tegrastats.

We stress-tested the relay server presented in Section 4.2. On a first node, we deployed the server with the InfluxDB output. On a second node, we deployed multiple clients with 4 plugins and 20 metrics, running at 1 Hz. With 250 clients, the server used 67 MB of RAM (about 268 kB per client), mainly due to the buffering of the data. It only used a few percent of CPU.

In Section 3.3, we evaluated Alumet in a minimalistic setting where only one source was enabled. Let us now evaluate a more extreme configuration with two HPC nodes: one with two AMD EPYC 9354 32-Core processors, the other with two Intel Xeon Gold 6448Y 32-Core processors. We ran the CPU-bound version of the HPCG benchmark, on all cores, for 30 minutes. We instructed the procfs plugin to monitor each process in a separate source, and a bash script continuously spawned and killed sleep processes so that the number of processes running on the node was always 5000. The pipeline thus contained more than 5000 sources. It used one thread per virtual core. As expected, using 5000 procfs sources with an acquisition frequency of 10 Hz (or more) increased the overhead of the agent, to as much as 14% on both nodes. On the contrary, keeping their frequency at 0.1 Hz or less made their overhead negligible, in spite of their large number. These results show that creating many sources does not, in itself, increase the overhead of the agent in a significant way. In other words, Alumet efficiently supports a large number of concurrent inputs.

# 5 Conclusion

Software powermeters are a fundamental pillar for controlling the energy consumption and carbon footprint of software applications. To disseminate these practices widely on a large variety of systems, we have proposed a new tool: Alumet. Unlike existing tools, Alumet is built on a unified data model, a generic measurement pipeline and a plugin system. These three pieces make Alumet more versatile and more extensible, as they allow to build tailor-made measurement tools without the need to redevelop everything from scratch when new hardware components, software platforms or models are created. In a few lines of code, plugins can create new metrics, sources, transform steps and outputs without modifying the core of the tool. Alumet is thus ready for future innovations. As shown in Sections 3 and 4, it is a clear improvement over existing software powermeters, in terms of flexibility and performance.

Through extensive experiments, we showed that it allowed to produce operational tools that are efficient, customizable and give control to users. Alumet agents were able to achieve a low overhead at high measurement frequencies. When deployed in a Kubernetes cluster, they obtained competitive results against
a specialized solution, namely Kepler. Despite its genericity and versatility, Alumet remains easy to use and to deploy. We believe that Alumet has the potential to become a standard framework for energy measurement.

In the future, we aim to deploy Alumet in large-scale production contexts, such as corporate datacenters and public testbeds. We will continue to develop new plugins in order to support more hardware and software components. We also intend to work on estimation and attribution models, based on the existing literature. Doing so will help us to improve the utilities that are built into the framework to help the authors of plugins. Finally, there is nothing in Alumet that is very specific to energy or power. In fact, it could also be used to produce monitoring tools. We intend to explore this perspective in a future work.

## References

1. Malmodin, J., Lundén, D.: The Energy and Carbon Footprint of the Global ICT and E&M Sectors 2010-2015. Sustainability **10**(9) (2018). https://doi.org/10.3390/su10093027

2. Andrae, A.: Prediction Studies of Electricity Use of Global Computing in 2030. **8**, 27–33 (2019)

3. Belkhir, L., Elmeligi, A.: Assessing ICT global emissions footprint: Trends to 2040 & recommendations. Journal of Cleaner Production **177**, 448–463 (2018). https://doi.org/10.1016/j.jclepro.2017.12.239

4. Bol, D., Pirson, T., Dekimpe, R.: Moore's Law and ICT Innovation in the Anthropocene. In: 2021 Design, Automation & Test in Europe Conference & Exhibition, pp. 19–24 (2021). https://doi.org/10.23919/DATE51398.2021.9474110

5. Freitag, C., Berners-Lee, M., Widdicks, K., Knowles, B., Blair, G.S., Friday, A.: The real climate and transformative impact of ICT: A critique of estimates, trends, and regulations. Patterns **2**(9), 100340 (2021). https://doi.org/10.1016/j.patter.2021.100340

6. Corporation, I.: *Intel 64 and IA-32 Architectures Software Developer's Manuals, Volume 3B*. 2023.

7. Corporation., N.: Nvidia management library (nvml), (2019). https://developer.nvidia.com/nvidia-management-library-nvml.

8. Advanced Micro Devices, I.: *AMD ROCm - SMI documentation*. 2024. https://rocm/docs.amd.com/projects/amdsmi.

9. Jay, M., Ostapenco, V., Lefevre, L., Trystram, D., Orgerie, A.-C., Fichel, B.: An experimental comparison of software-based power meters: focus on CPU and GPU. In: 2023 IEEE/ACM 23rd International Symposium on Cluster, Cloud and Internet Computing (CCGrid), pp. 106–118 (2023). https://doi.org/10.1109/CCGrid57682.2023.00020

10. Raffin, G., Trystram, D.: Dissecting the Software-Based Measurement of CPU Energy Consumption: A Comparative Analysis. IEEE Transactions on Parallel and Distributed Systems **36**(1), 96–107 (2025). https://doi.org/10.1109/TPDS.2024.3492336

11. AFNOR, AFNOR SPEC 2314 - General framework for frugal AI (2024)

12. Khan, K.N., Hirki, M., Niemi, T., Nurminen, J.K., Ou, Z.: RAPL in Action: Experiences in Using RAPL for Power Measurements. ACM Trans. Model. Perform. Eval. Comput. Syst. **3**(2) (2018). https://doi.org/10.1145/3177754
13. Desrochers, S., Paradis, C., Weaver, V.M.: A validation of DRAM RAPL power measurements. In: Proceedings of the Second International Symposium on Memory Systems, pp. 455–470. ACM (2016). https://doi.org/10.1145/2989081.2989088

14. Schöne, R., Ilsche, T., Bielert, M., Velten, M., Schmidl, M., Hackenberg, D.: Energy efficiency aspects of the AMD Zen 2 architecture. 2021 IEEE International Conference on Cluster Computing (CLUSTER) (2021). https://doi.org/10.1109/Cluster48925.2021.00087

15. Burtscher, M., Zecena, I., Zong, Z.: Measuring GPU Power with the K20 Built-in Sensor. In: Proceedings of Workshop on General Purpose Processing Using GPUs. GPGPU-7, pp. 28–36. Association for Computing Machinery (2014). https://doi.org/10.1145/2588768.2576783

16. Yang, Z., Adamek, K., Armour, W.: Accurate and Convenient Energy Measurements for GPUs: A Detailed Study of NVIDIA GPU’s Built-In Power Sensor. In: 2024 SC24: International Conference for High Performance Computing, Networking, Storage and Analysis SC, pp. 307–323. IEEE Computer Society (2024). https://doi.org/10.1109/SC41406.2024.00028

17. Petit, B.: Scaphandre, (2020). https://hubblo-org.github.io/scaphandre-documentation/.

18. Noureddine, A.: PowerJoular and JoularJX: Multi-Platform Software Power Monitoring Tools. In: 18th International Conference on Intelligent Environments (2022). https://doi.org/10.1109/IE54923.2022.9826760

19. da Costa, G.: *MojitO/S*, version 1.0 (2021). https://hal.science/hal-03453537.

20. Tchakoute, R.N., Tadonki, C., Dokladal, P., Mesri, Y.: A Flexible Operational Framework for Energy Profiling of Programs. In: 2024 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW), pp. 12–22 (2024). https://doi.org/10.1109/SBAC-PADW64858.2024.00014

21. Raffin, G., Jay, M.: *NVML sensor*, (2023). https://hal.science/hal-04664358.

22. Schmidt, V., Goyal, K., Joshi, A., Feld, B., Conell, L., Laskaris, N., Blank, D., Wilson, J., Friedler, S., Luccioni, S.: CodeCarbon: estimate and track carbon emissions from machine learning computing. Zenodo (2021). https://zenodo.org/records/11171501

23. SPIRALS, I.: PowerAPI, (2019). http://powerapi.org/.

24. Fieni, G., Rouvoy, R., Seinturier, L.: SmartWatts: self-calibrating software-defined power meter for containers. In: 2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID), pp. 479–488. IEEE (2020). https://doi.org/10.1109/CCGrid49817.2020.00-45

25. Colmant, M., Felber, P., Rouvoy, R., Seinturier, L.: WattsKit: Software-Defined Power Monitoring of Distributed Systems. In: Proceedings of the 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), p. 10. IEEE (2017). https://inria.hal.science/hal-01439889

26. Amaral, M., Chen, H., Chiba, T., Nakazawa, R., Choochotkaew, S., Lee, E.K., Eilam, T.: Process-Based Efficient Power Level Exporter. In: 2024 IEEE 17th International Conference on Cloud Computing (CLOUD), pp. 456–467 (2024). https://doi.org/10.1109/CLOUD62652.2024.00058

27. Bouza Heguerte, L., Bugeau, A., Lannelongue, L.: How to estimate carbon footprint when training deep learning models? A guide and review. Environmental Research Communications (2023). https://doi.org/10.1088/2515-7620/acf81b

28. Heroux, M.A., Dongarra, J., Luszczek, P.: HPCG Benchmark Technical Specification. (2013). https://doi.org/10.2172/1113870