# Evaluating and Reporting the Carbon Footprint of Shared Computing Platforms: Choices and Limits

Gaël Guennebaud, Anne-Laure Ligozat, Anne-Cécile Orgerie, Matthieu Simonin

► To cite this version:

Gaël Guennebaud, Anne-Laure Ligozat, Anne-Cécile Orgerie, Matthieu Simonin. Evaluating and Reporting the Carbon Footprint of Shared Computing Platforms: Choices and Limits. ISPDC 2025 - 24th IEEE International Symposium on Parallel and Distributed Computing, Jul 2025, Rennes, France. pp.1-7. [hal-05195576](https://hal.science/hal-05195576v1)

HAL Id: hal-05195576

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

Submitted on 1 Aug 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
# Evaluating and Reporting the Carbon Footprint of Shared Computing Platforms: Choices and Limits

Gaël Guennebaud¹, Anne-Laure Ligozat², Anne-Cécile Orgerie³, Matthieu Simonin³

¹ Inria, Univ. Bordeaux, Talence, France, Email: gael.guennebaud@inria.fr

² Université Paris-Saclay, CNRS, LISN, ENSIIE, Orsay, France, Email: anne-laure.ligozat@lisn.upsaclay.fr

³ Univ. Rennes, Inria, CNRS, IRISA, Rennes, France, Email: {anne-cecile.orgerie, matthieu.simonin} @irisa.fr

***Abstract***—Attributing the carbon costs of shared ICT infrastructures to its end-users is frequently promoted as a way to encourage awareness of environmental impacts and advocate for more sustainable practices. This paper explores the intricacies of this approach by focusing on shared ICT infrastructures specifically dedicated to academic research, several of which having recently introduced carbon intensity values for their users. This scenario serves as a practical case study for examining the methodologies and challenges associated with evaluating the carbon intensity of shared ICT infrastructures. We explore the choices with their limitations, discuss the objectives behind their implementation of this type of environmental indicator and offer actionable insights. This analysis aims to contribute to the broader discussion on sustainable computing practices and the role of environmental indicators in driving meaningful change.

***Index Terms***—Life cycle assessment, carbon footprint, ICT infrastructures, research platforms, computing servers

## I. INTRODUCTION

Climate change, biodiversity loss, air pollution, ozone layer depletion, freshwater withdrawals, land conversion, ocean acidification, chemical pollution, nitrogen and phosphorus loading, all these real-life processes recall the role of human activities in environmental change [31]. A growing part of climate science works on quantifying environmental indicators and defining planetary boundaries that are spreading across the other scientific disciplines [30]. Yet, to avoid a catastrophic scenario, major changes are required now, for all human activities, including the ones related to all industrial sectors. Among the environmental indicators, the global warming potential, expressed in terms of greenhouse gas (GHG) emissions or carbon footprint is the most studied one and thus, the one with the most estimated data in all sectors.

In 2021, the Information and Communication Technology sector (ICT) was estimated to account for 2.1% to 3.9% of global GHG emissions [11]. In order to comply with the objectives set by the Paris Agreement, the International Telecommunication Union (ITU) committed in 2020 to reduce GHG emissions by 45% by 2030 [15]. Achieving such an objective requires, among other things, a multitude of models to quantify carbon footprint at each step of the life cycle of each ICT device, infrastructure and service. This implies an important investment from all the stakeholders. Indeed, having precise data quantifying carbon footprint of ICT devices is arduous. For device manufacturers, it requires consequent monitoring and accounting processes at each step of the production and

supply chains, interactions with potentially numerous subcontractors, and a proficiency in specialized life cycle assessment (LCA) methodologies and software (e.g. PAIA, SimaPro). Therefore, for a given ICT device, utilized by one person (i.e. the user), estimating its carbon footprint is already quite challenging. Yet, most of current ICT devices are connected to the Internet and often interact with services hosted by data centers. Consequently, the user indirectly employs shared ICT infrastructures through her device: communication networks and data centers.

Attributing carbon costs of shared ICT infrastructures to its end-users (either direct users or services deployed on Cloud infrastructures for instance) is often presented as a way to incentivize users to their environmental impacts. Several methods exist to estimate such carbon costs or carbon intensities [12], [18], [36]. The idea is to attribute a quantity of GHG emissions (in kilograms of CO₂ equivalent) per functional unit. For instance, the functional unit can concern data transport over a given network, data storage in a given data center, or computing hours in a given data center.

In this paper, we consider shared “bare metal” ICT infrastructures dedicated to intensive computation, while ignoring virtualized cloud services. Several academic research facilities recently proposed carbon intensity values to their users [6], hence providing a concrete use case for detailing the methodologies and issues related to carbon intensity evaluation of shared ICT infrastructures. The general issues are twofold: 1) providing an environmental indicator that is precise, and 2) expressing the goals of such an indicator. As a main contribution of this paper, we provide a literature review of the existing methods for estimating carbon intensity of research ICT platforms, detailing their advantages and drawbacks, and we question the purpose of such indicators and their accuracy.

The paper is organized as follows. After a literature review in Sec. II, we detail the general method for providing carbon intensity for this type of computing platform in Sec. III while discussing some methodological choices. Sec. IV provides a concrete use case while presenting a methodology variant to avoid false competition between services. Finally, we discuss more general limits with respect to the purposes of this type of environmental indicator in Sec. V, while proposing some possible mitigation strategies.
## II. RELATED WORK

### A. Life-cycle methods and the GHG protocol

Environmental assessment of digital services usually falls under a Life Cycle Assessment (LCA) methodology. LCA is a standardized methodology, ISO 14040 and ISO 14044, providing general guidelines for environmental assessment.

The GHG protocol Product Accounting and Reporting Standard builds on the framework and requirements established in the ISO LCA standards. A specific document [8] provides guidance for assessment of ICT products and services. The International Telecommunication Union (ITU) created a methodological document [16] to "complement ISO 14040 and ISO 14044 for the assessment of the life cycle impact of ICT goods, networks and services". Finally, building on the previous documents, the French Agency for Ecological Transition (ADEME) has also produced its own methodological standard [2] explaining how to assess the environmental impacts of IT hosting in data centers and in the cloud.

More recently, the ISO/IEC specification 21031 entitled "Software Carbon Intensity", proposed by the Green Software Foundation, defines a methodology for attributing a carbon intensity to a software system per functional unit (e.g. per job or per API-call) [14]. The methodology relies on the energy consumed by the software system and location-based marginal carbon emissions for the use phase, and an estimation of the embodied emissions for taking into account the whole life cycle. It is expressed in kgCO2e. But, unlike cumulative values, it is expressed as a score since it depends on the chosen functional unit [28]. Such a metric can be useful for cloud services' users. Yet, in the case of shared infrastructures for computing, each user deploys her own software.

### B. Embodied emissions for the manufacturing phase

Early work attempting to provide energy value [19] and carbon footprint [22] for a given virtual machine deployed on a cloud infrastructure considered only the use phase (i.e., the electricity consumption using an allocation method to account for the electricity consumption of the whole infrastructure). But the manufacturing and transport phases of ICT devices can represent an important part of the carbon footprint over the whole life cycle.

Some ICT hardware vendors provide Product Carbon Footprint (PCF) sheets, which detail the carbon emissions for the entire life cycle of their products. For servers, Dell<fnref n="1" /> and HPE<fnref n="2" /> are among the most active on this topic. The carbon footprint of the use phase highly depends on electricity carbon intensity and on the specific usage of the device. Therefore, the figures provided in PCF sheets are not reliable on this part, and would thus benefit from actual measurements taken on the real devices throughout their lifetime. The manufacturing phase data in PCF sheets provide useful rough estimates, upon which some tools have been built such as EcoDiag [25]. Some other

tools aim to enable the assessment of manufacturing emissions for any server, using a unified methodology and fine grained configuration options. Those include db.resilio [29], BoaviztAPI [34], and MLCA [26] which is an extension of the latter with GPU support.

Concerning other parts of data centers, like routers, air conditioners, or Uninterruptible Power Supplies (UPS), the carbon footprint of their manufacturing phase is difficult to estimate due to lack of recent data for a wide range of devices.

### C. Other approaches

A variety of factors contributes to the variability of carbon footprint attribution in the ICT sector. These include: the perimeter and scope definitions, the complexity of infrastructures and processes, the lack of accurate and up-to-date data, the intricacy of numerous stakeholders (having business relations or being in competition), etc. [12], [36]. The employed methodology often relies on a bottom-up approach using LCA, thus involving a functional unit that may be time-based (e.g., for 1 hour) or service-based (e.g., for a given number of users), and a detailed material and energy inventory of the system [32]. Other methods can be found in the literature, like the Environmentally Extended Input Output (EEIO), which is a top-down approach based on econometrics and an evaluation of the economic activity generated by the studied system [32]. Such an approach does not apply to public research ICT infrastructures, such as the one considered in our example.

## III. ESTIMATING THE CARBON FOOTPRINT OF COMPUTING

The general context of this work is to provide GHG emissions for users of a shared computing infrastructure. The idea is to give an average value of the GHG emissions for running a program on this kind of infrastructure, so that researchers or labs can estimate their share of the infrastructure's carbon footprint, in the form of an emission factor in kgCO2e equivalent for one core hour of computation. This section presents the general methodology to achieve such a goal and discusses the direct consequences of some methodological choices. In Section IV, we will provide a variant on a concrete example. More general issues will be discussed in Sec. V.

### A. Functional unit definition

The underlying methodology is based on attributional Life Cycle Assessment and the aforementioned standards and guidance documents applying LCA for digital services. For this analysis, we focus solely on the carbon footprint, but the questions addressed are valid for other environmental impact indicators as well.

We first need to define what we want to measure. In order to give practical information that the user of a computing platform may use in her research paper for example, we will report the environmental impacts associated to one hour of computation on the platform. We thus need to know what the environmental responsibility of an hour of computation on a given hardware is. As the service provided by a platform is traditionally expressed in core hours, the basic functional unit

<footnote n="1">¹Dell PCF: https://www.dell.com/en-us/dt/corporate/social-impact/advancing-sustainability/climate-action/product-carbon-footprints.htm</footnote>

<footnote n="2">²Example of HPE PCF https://www.hpe.com/psnow/doc/a50002430enw</footnote>
(i.e. the service that we wish to evaluate) will thus be “use 1 computing core for 1 hour”. In section IV, we will discuss an adaptation of this functional unit.

Boundary setting defines what is included and excluded from the assessment of the service. The methodology includes the following attributable processes, with P.1 and P.2 being – at least partly – included is most existing studies:

P.1 IT equipment: computing, storage, access and administration servers, spare parts (e.g., replaced hard drives)

P.2 Cooling: air conditioning, potential refrigerant leaks

P.3 Power supply: transformers, UPS, batteries, generators

P.4 Buildings: construction and maintenance of facilities

P.5 Staff activity: travel, staff equipment

Note that P.1, P.2 and P.3 are required in the GHG protocol ICT Sector Guidance [8], which also includes part of P.5, i.e. emissions associated with “the transport of people, where they are required to deliver or support the ICT product (e.g., maintenance and support engineers)”.

Adopting a life cycle approach means that we should take into account all life cycle phases of the equipment considered: material acquisition, manufacturing, distribution, use and end of life. The term “embodied emissions” in the following will refer to material acquisition, manufacturing, and distribution; end of life is not taken into account due to lack of reliable data and its presumably low impact in terms of GHG emissions. The GHG protocol ICT Sector Guidance recommends including the embodied emissions for ICT equipment only, but when possible we try to include embodied emissions for cooling and power supply equipment too.

Building construction (P.4) is considered as a non-attributable process in the GHG protocol ICT Sector Guidance, but we decide to include it since some buildings are constructed solely to house data centers.

“Allocation refers to the partitioning of emissions among products where more than one product shares a common process” [8]. Allocation of embodied emissions is usually time-based, i.e., based on the time the service is used in relation to the equipment’ lifetime. For the use phase, allocation rules define the share allocated to each user of a shared IT resource.

## B. Estimating embodied emissions

Basically, the embodied emissions for ICT equipment for a given year are computed as follows:

$$GHG_{emb} = \sum_{e \in E} \text{share}(e) \times \frac{GHG_{emb}(e)}{\text{lifetime}(e)},$$

with e an equipment piece of the set of equipment E, GHG<sub>emb</sub> the embodied GHG emissions, share the share of the equipment for the service considered and lifetime the lifetime duration of equipment e in years. These emissions are then divided by the number of annual hours of computation to get an estimation for one hour of computation.

This estimation raises several issues already. First, it is based on the embodied carbon footprint of equipment. This information can be provided by manufacturers, but is not

always available for non-standard equipment, which is often used in large computational infrastructures. Additionally, it is often based on methodologies that are not open. Furthermore, the actual lifetime of equipment can only be derived when it gets discarded, which means that it needs to be estimated based on past practices, even though the policies may vary over time. Equipment might be written off owing to multiple reasons, e.g: defectiveness, performance obsolescence, maintenance issues, end of hardware or software support or warranty.

## C. Estimating emissions from use phase

Estimating use phase emissions is done in two steps: measuring the energy and then converting it into a carbon footprint.

a) Energy use: In order to measure energy use, top-down or bottom-up approaches can be employed. Top-down approaches consist in computing the total energy use – from electrical panels for instance – and divide it by the number of computation hours. This is useful to estimate, a posteriori, the average energy consumption for one hour of computation.

To get a more precise measurement of a given job, bottom-up approaches can be used, based on devices or libraries that log the specific energy use of the program. These approaches yet have a limited perimeter since they only log part of the servers consumption, thus omitting other IT and non-IT equipment, and part of the server consumption.

Some studies [17], [35] have for example compared the energy use reported by an external power meter, a baseboard management controller (BMC) – an intra-node device placed between a computing node’s power supply and the main board – and several software programs such as CodeCarbon (https://codecarbon.io/) or Carbontracker (https://carbontracker.info/), based on RAPL for CPUs and Nvidia-SMI for GPUs. In these studies, the authors experimented with a server featuring 2 Broadwell CPUs with 20 cores each and 8 Nvidia Tesla V100 GPUs. Comparing power values, they show that idle power represents around 44% of the maximum power measured and that summing the results returned by RAPL and Nvidia-SMI gives only 61% of the power displayed by the wattmeter.

Additionally, when using software to estimate energy use of computation servers, energy use of other IT and non-IT equipment are not considered, such as storage servers, network equipment, or cooling system. Some models use PUE (Power Usage Effectiveness) to estimate the “overhead” energy consumption of a given use, i.e., consumption that takes into account the use of the infrastructure. PUE is the ratio of the center’s total consumption (IT part + rest) to the IT part. The CodeCarbon library for example, sums up the consumption obtained by RAPL (via the Intel Power Gadget interface) and by Nvidia-SMI (via the pynvml interface) and multiplies this sum by the PUE. Yet, this method may not provide a correct estimation of the actual energy consumption due to the program. As previously mentioned, RAPL and Nvidia-SMI only account for a portion of the server’s energy consumption and an even smaller fraction of the overall IT equipment usage. Therefore, using these measurements alone results in an inaccurate denominator for calculating total energy use.
Multiplying by PUE thus only captures part of the infrastructure's consumption. Indeed, if each user employs this method and all these "energy costs" per user are summed up over a given period, this sum does not correspond to the total energy consumption of the data center. This discrepancy arises because this method does not account for infrastructure servers (such as frontend, NFS, monitoring, etc.), other IT equipment (such as routers, etc.) or periods of inactivity on the center's servers. As a result, it cannot be used to attribute all energy costs to platform users. Bottom-up energy estimation methods should therefore be used with caution, as they consider only part of the consumption of IT resources and part of the consumption of the infrastructure.

In order to account for all the energy consumption, one could mix a bottom-up method to precisely estimate the marginal consumption of a given job, and complement it with a top-down method to allocate the constant, non-proportional energy consumption of the servers idle time and of all the rest of the infrastructure [19], [26].

b) From energy use to carbon footprint: To obtain GHG emissions, the energy consumption is multiplied by an emission factor (in kgCO₂e/kWh) linked to the energy mix used by the computing center. The choice of the emission factor should be carefully considered.

First, these conversion factors are highly specific to the energy consumption location, especially in the case of electricity. For instance, on Feb. 28th, 2025, the average carbon intensity values in gCO₂e/kWh was 356 in Ireland, 11 in Albania, and 840 in Poland [10]. These figures are a snapshot since electricity carbon intensity also varies over time.

While grid mixes fluctuate widely from region to region, major cloud providers have, for several years, relied on purchasing energy from renewable sources to power data centers. For instance, according to its 2023 sustainability report, Amazon is the "largest corporate purchaser of renewable energy in the world for the fourth year in a row" [3]. This technique of purchasing Renewable Energy Certificates (RECs) is permitted by the GHG Protocol. So called market-based emission factors are often exploited by cloud providers when offering carbon footprint tools to their customers [4], [13], [24]. They are, however, highly controversial [27] and we rather recommend to rely on location-based factors that represent the "average emissions intensity of grids on which energy consumption occurs" according to the GHG Protocol's definition.

Second, some energy providers enable the average emission factor to be tracked in real time. This is for example the case for RTE in France<fnref n="3" />. Whereas it might be tempting to exploit those real-time factors in a quest for more "accuracy", in most use cases we rather recommend to stick with monthly or yearly averages. This is especially the case when accounting for the emissions at the scale of a job or user because, just like the market-based vs location-based issue, such a strategy might just hide the true global emissions, artificially favoring some users at the detriment of others. Moreover, real-time

emission factors will yield to significantly different estimate for similar workloads, hence introducing confusion to end-users and preventing algorithm comparisons. A legitimate use case would be the tracking of emissions at the scale of a whole computing service prior to allocating the whole emission to end users or jobs, hence reflecting the collective responsibility. This is especially relevant if carbon intensity forecasts are exploited to schedule jobs. It should be noted that such a scheduling strategy is only possible if the use rate is not too high, i.e., if the computing capacity is slightly oversized in order to provide the necessary flexibility, which raises a trade-off issue between use-phase and embodied impacts.

As we just discussed, electricity carbon intensity is a significant source of variability when assessing the carbon footprint of the use phase of ICT infrastructures. Yet, the variability can also come from the energy estimations, as shown in previous work estimating the energy intensity of Internet [9]. The authors conducted a literature review on the subject, highlighting that estimates varied by a factor of more than 20,000 (between 136 kWh/GB and 0.0064 kWh/GB) [9].

## D. Uncertainty calculation

Throughout the calculation process, numerous approximations and uncertainties accumulate. It is important to communicate this level of imprecision to users. In our context of compute facilities, uncertainties are ignored by the literature. In other contexts, however, uncertainty level is classically apprehended by modeling each quantity as a random variable with a relative standard deviation, which we will denote $\sigma$. For their propagation we also need to determine the cross-correlation between the different quantities. Without a thorough LCI model of all involved equipment, such correlations are hardly available. As a workaround, we propose the following simplified two-stage strategy.

Firstly, equipment that is expected to have mostly correlated uncertainties is grouped together. If the emission factor for one piece of equipment in a given group is found to be significantly underestimated (resp. overestimated), then the factors for the other pieces of equipment in the group are also expected to be underestimated (resp. overestimated). Here, the errors committed for equipment in the same group do not compensate for each other, and we will assume a perfect correlation. On the contrary, the uncertainty in-between these groups is assumed to be perfectly uncorrelated and can be modeled by so-called independent random variables. In other words, an overestimation of one group is assumed here to be likely partially offset by the underestimation of another. To highlight those groups, we first rewrite the embodied emissions formula per group $g \in G$ with respective set of equipment $E(g)$:

$$GHG_{\text{emb}} = \sum_{g \in G} \sum_{e \in E(g)} \widehat{GHG}_{e}(e)$$

with $\widehat{GHG}_{e}(e) = \frac{\text{share}(e) \times GHG_{\text{emb}}(e)}{\text{lifetime}(e)}$. The relative uncer-

<footnote n="3">³RTE &CO2mix https://www.rte-france.com/eco2mix</footnote>
tainty of embodied emissions can then be calculated by:

$$ \sigma_{\text{emb}} = \frac{\sqrt{\sum_{g \in G} \left( \sum_{e \in E(g)} \widehat{GHG}_e(e) \sqrt{\sigma_e(e)^2 + \sigma_a(e)^2 + \sigma_l(e)^2} \right)^2}}{GHG_{\text{emb}}}, $$

where, for each piece of equipment *e*, $\sigma_e(e)$, $\sigma_a(e)$ and $\sigma_l(e)$ denote the relative standard deviation uncertainty of its embodied emission $GHG_{emb}(e)$, allocation factor and lifetime respectively. The latter threes are assumed to be independent. This formula also assumes there is no uncertainty on the quantity of equipment. Assuming embodied and use-phase emissions are independent, we end up with the following formula for the total relative uncertainty:

$$ \sigma_{\text{total}} = \frac{\sqrt{GHG_{\text{emb}}^2 \sigma_{\text{emb}}^2 + GHG_{\text{use}}^2 (\sigma_F^2 + \sigma_{\text{elec}}^2)}}{GHG_{\text{total}}}, $$

with $GHG_{use}$ the use-phase emissions, and $\sigma_F$, $\sigma_{elec}$ the independent relative uncertainties of the electricity mix factor and power consumption respectively. If the power consumption is estimated as the sum of individual estimations and measurements with their own uncertainty, then the same two stage procedure than for the embodied uncertainty can be used to estimate $\sigma_{elec}$. Finally, since we are manipulating positive quantities, we recommend interpreting the $GHG_{total}$, $\sigma_{total}$ pair as the mean value and relative standard deviation of a log-normal distribution from which we can derive a lower/upper bound pair for a user-defined confidence interval. An application example will be given in Sec. IV.

## IV. IMPLEMENTATION EXAMPLE: GES 1POINT5

GES 1point5 is an open source software [23], developed by the Labos 1point5 research group [20] to help research units estimate the carbon footprint of their activities. Support for accounting computing hours performed on the French Tier 1 facilities has been added in 2024 [6]. For this work, the sole objective was to make such external computing emissions visible to research units such that units making an extensive use of them can integrate them in their mitigation plan.

a) Reporting unified emission factors: As outlined in Sec. V, reporting individual intensity indicators per-facility may encourage end-users to always use most recent facilities, thereby creating a counterproductive accelerated obsolescence effect. In order to circumvent this potential issue, two complementary countermeasures have been adopted.

Firstly, all Tier 1 facilities, as supervised by the GENCI agency<fnref n="4" />, are regarded as a unified service. Instead of striving to allocate the impact of a given facility to the users of this precise facility, the goal now is to allocate the entire footprint among all users. Secondly, since different facilities are expected to deliver different computing powers, it is no longer sound to directly allocate the emissions based on the number of core hours. Instead, the allocation should be done based on a common unit of computing quantity.

<table><caption>TABLE I
GHG AND UNCERTAINTY BREAKDOWN FOR CPU-BASED SERVERS</caption><thead><tr><th></th><th></th><th>Uncertainty inputs<br>(σ<sub>e</sub> or σ<sub>elec</sub>, σ<sub>F</sub>)</th><th>Combined<br>Uncertainty</th><th>GHG<br>share</th></tr></thead><tbody><tr><td rowspan="6">Embodied<br>groups</td><td>IT (P.1)</td><td>30%</td><td>39%</td><td>48%</td></tr><tr><td>UPS</td><td>50%</td><td>56%</td><td>2.3%</td></tr><tr><td>Batteries</td><td>40%</td><td>47%</td><td>1%</td></tr><tr><td>Generators</td><td>50%</td><td>56%</td><td>1%</td></tr><tr><td>Cooling (P.2)</td><td>50%</td><td>56%</td><td>4%</td></tr><tr><td>Other</td><td>80%</td><td>84%</td><td>1%</td></tr><tr><td colspan="2">Embodied sub total</td><td></td><td>33%</td><td>57%</td></tr><tr><td colspan="2">Use phase</td><td>5%, 10%</td><td>11%</td><td>43%</td></tr><tr><td colspan="2"><strong>Total (embodied+use)</strong></td><td></td><td><strong>20%</strong></td><td>(100%)</td></tr></tbody></table>

To this end, the notion of core hour-equivalent has been utilized, which equals to one real core hour of computation on a given reference architecture. Since CPU and GPU-based facilities do not provide interchangeable services, GPU-based ones are accounted separately using a similar GPU hour-equivalent allocation key for the allocation. Let $\alpha_i$ be the conversion factor from real-world hour and hour-equivalent units for the facility *i*, then the allocation of the facility impacts to a given user *u* is carried out as:

$$ GHG_u = \frac{\sum_i GHG_i}{\sum_i \alpha_i N_i} \sum_i \alpha_i N_{u,i}, \quad (1) $$

with, for each facility *i*, the total footprint $GHG_i$, the total consumed hours $N_i$, and the number of consumed hours $N_{u,i}$ for the given user. The list of considered partitions is provided in Appendix A. In this work, the facility footprints $GHG_i$ include all three required processes P.1, P.2 and P.3, with the exception of spare parts that were considered negligible and difficult to inventory. The other two processes had to be ignored owing to the difficulty to gather data. Yearly power consumption mostly relies on actual top-down measurements. Embodied emissions of IT equipment has been estimated using a mix of the average EcoDiag [25] values and the parametric model of BoaviztAPI [34] to account for configuration options. Embodied emissions of non-IT equipment have been extrapolated from similar equipment data based on either weights or power ratios. Equipment shared between multiple IT services have been allocated based on the respective IT power consumption.

b) Results and uncertainty: For the year 2023, with a 0.058 kgCO₂e/kWh factor of the electricity mix [1], we end up with factors of 1.38 gCO₂e/core hour-equivalent and 38.3 gCO₂e/GPU hour-equivalent for the CPU- and GPU-based architectures respectively. Table I presents the breakdown of the CPU-based factor with related uncertainties.

In order to estimate the global uncertainty level, the previous two-stage strategy is applied on the whole facilities. This simplified example ignores allocation uncertainty (i.e., $\sigma_a(e) = 0, \forall e$), uses the same lifetime uncertainty $\sigma_l = 25\%$ for all equipment, and further assumes all equipment within a group is given the same embodied uncertainty ($\sigma_e(e) = \sigma_e(g)$, $\forall e \in g$). The latter ranges from 30% to 80%. The “Combined uncertainty” column reports the combination of the different sources of uncertainty (e.g., embodied factor and lifetime for the embodied groups). Combining the last two columns leads to a sub-total relative embodied uncertainty of 33%. Finally,

<footnote n="4">⁴https://www.genci.fr/en/services/means-calculation</footnote>
assuming an uncertainty of 5% on electricity consumption (due
to some extrapolations) and 10% on the carbon intensity of the
electricity mix [1], we obtain a total uncertainty on the order
of ±20%. This value would rise to ±23% if the uncertainty
associated to the IT equipment increased from 30% to 40%.
In contrast, with a more carbon-intensive electricity mix of
0.3 gCO₂e/kWh, the total uncertainty would drop to ±11%.
These examples show that even in a case where the embodied
emissions represent a large share of emissions and despite
significant uncertainties in the embodied emissions factors, the
final uncertainty remains rather contained.

c) Discussion: By design, a job scaling as expected by the αᵢ factors will be attributed the same carbon footprint regardless of the actual running facility. If a job under-exploits the capabilities of the most recent and efficient architectures, then these accounting rules will penalize running such a job on them. This is a welcome property to counter accelerated obsolescence. This strategy also comes with its own drawbacks. For example, there is no clear way to measure the relative computing performance of a given architecture. In practice, two architectures might exhibit significantly different performance ratios when used for FP64 physics simulations or FP16 neural network training, for instance. These rules are intended for *a-posteriori* reporting, but they do not directly help in choosing the most suitable facility. In the short term, in order to optimize global energy consumption, it may be advantageous to prioritize jobs on the available facilities that have the most energy efficient architecture for that job. However, we argue that such an optimization goal can hardly be addressed at the sole user level, as it requires a global overview of all job requests and facilities' overall loads. In this context, these unconventional accounting rules are still helpful as they enable offloading user jobs to less efficient facilities without penalizing them in terms of footprint allocation.

V. DISCUSSION

A. *Data availability should not limit such assessments*

As mentioned before, the availability of relevant data is one
of the limitations of most methodologies for assessing the
environmental impacts of ICT services. Some data are only
available a *posteriori* such as the lifetime of equipment or
the actual use rate. Hypotheses must thus be made, with most
probable values, and sensitivity analysis can help ensure that
these hypotheses do not hinder the results.

The GENCI Tier 1 service suffered from such lifetime
reduction issues. In 2022, the KNL partition was prematurely
shutdown because of a low use rate, for this architecture
rapidly became obsolete. This allowed to save idle energy
consumption, but another strategy would have been to im-
plement a mechanism automatically turning on and off nodes
on demand, as it is done in the Grid'5000 platform. In 2024,
808 (among 1528) Cascade-Lake nodes and 216 (among 612)
quad-V100 nodes where decommissioned after about 5 and 4
years respectively – instead of the assumption of a 6 year life-
time used to compute the emission factors – to release space
and resources for newer H100-based nodes. Actual lifetime

reduction is difficult to address properly without muddling the
message conveyed to end-users. In these precise two cases,
thanks to the use of average factors unifying multiple facilities,
those partial decommissioning had a small impact on the
overall factors regardless of the way they are handled.

Additionally, some data are difficult to get, such as GPU
embodied emissions but also embodied emissions for many
types of equipment, like HVAC, and end-of-life impacts of ICT
equipment are yet highly uncertain owing to lack of data and
proper tracking. This limitation has largely been pointed out in
studies assessing the environmental impacts of digital services
(see [7], [21], [26] for example), that often call for more
transparency. In addition to requiring that this kind of data
be mandatory from ICT equipment manufacturers, parametric
models can be built to estimate for example the embodied
emissions of CPUs or GPUs [26], [29], [34]. Moreover,
allocating recycling impacts in a consistent and meaningful
manner is source of endless methodological controversies [33].

B. *Shall we select infrastructure based on emission factors?*

Owing to methodological differences (perimeter, data
sources, lifetime assumption, etc.), two identical infrastruc-
tures powered by the same electric grid might exhibit signifi-
cantly different per *core hour* indicators. As a matter of fact,
even if using the exact same methodology with same lifetime
assumptions, a significant difference in the use rate will lead
to a significant *core hour* estimate. This example shows that
such indicators are neither relevant to compare infrastructures,
nor to compare reported jobs emission.

Moreover, the emissions factors are essentially efficiency
indicators. It is important to understand that these factors
are made up of the amortization of GHGs emitted during
the production of the various pieces of equipment and the
so-called idle electricity consumption of IT equipment (con-
sumption that does not depend on the presence or absence
of a job). A large body of emissions already occurred before
running the first job. Using these emissions factors by infras-
tructure could lead to false competition between the various
infrastructures, which could result in accelerated obsolescence
and thus an increase in absolute impacts, contrary to the
reduction objective. To avoid this pitfall, GES 1point5, whose
methodological choices were detailed in Sec. IV, chose not
to provide infrastructure-specific emissions factors but rather
to merge the emission factors of all computing infrastructures
into a single shared service. Instead of attributing the GHG
emissions of a specific infrastructure solely to its users, the
choice made corresponds to distributing the GHG emissions
of all infrastructures across all users collectively.

Whereas unifying facilities is an effective way to contain
competitive obsolescence effects and more general lifetime
reduction issues, this strategy does not scale beyond a few
facilities. Another strategy to mitigate these lifetime issues
would be to amortize the embodied emissions in a non
uniform manner. For instance one half would be allocated
on the first year, one quarter the second year, and so on.
This strategy more accurately reflects the fact that embodied
emissions occurs at manufacturing time and allocates more impacts to early adopters, hence mitigating the false efficiency competition effect. Emissions associated to old equipment will rapidly be limited to OPEX-like emissions (maintenance plus idle-time and dynamic energy consumption). This way, there is a reduced risk of overlooking embodied emissions if some equipment is prematurely decommissioned. Determining the right temporal distribution of the allocation to balance the different objectives remains an open question though.

### C. *Shall emission factors be used as a mitigation compass?*

Such emission factors per unit of time or workload are efficiency indicators that hide the true absolute impacts. Once a partition is deployed, there are mostly two levers to reduce such an indicator, both appearing at the denominator of the equations. One is to extend its use time to amortize the CAPEX-related impacts on a longer period. Such a strategy can positively mitigate the absolute impacts only if the partition serves a legit usage and that the dynamic impacts are not largely outweighed by the full impacts of more recent and efficient hardware. If no automatic on/off mechanisms are implemented, the idle-time energy consumption overhead must be tracked with scrutiny. The second lever is to increase the amount of computing hours, that also increases the use rate of the partition. At a first glance, this strategy looks legit as it seems to also permit to better amortize the CAPEX-related impacts. However, this yields a paradox as this also comes with an increase of the absolute impacts. This paradox is closely related to the *sunk cost fallacy* effect [5], which states that people have “greater tendency to continue an endeavor once an investment in money, effort, or time has been made”.

From all these observations, owing to the large share of CAPEX-like emissions (embodied emissions, idle-time consumption, etc.), it becomes clear there is no *ground truth* GHG estimation methodology that could properly reflect the physical reality. This is especially true when attempting to estimate the impacts of a subset of jobs (from a single job to a research unit's jobs). Many of the aforementioned issues could be partly addressed by reporting multiple indicators. At the very least, we suggest the following three complementary indicator levels. i) One reporting the dynamic impacts of a unit of computation. Such indicators reflect the short-term marginal impact of running or renouncing a job. ii) Attribu- tional indicators as discussed in Sec. III reporting impacts on a more thorough perimeter. This type is especially useful for *a-posteriori* assessments. iii) Global indicators reporting the absolute assessments of the whole facilities on a regular basis (e.g., quaterly or yearly). This type of indicator is the only one that truly matters in terms of mitigation of climate change and other environmental and social issues.

### D. *Environmental evaluation of shared computing platforms should go beyond GHG emissions and LCA*

As already mentioned in the introduction, most of the ex- position made in this paper generalizes to other environmental

indicators as classically used in LCA. Including other indica- tors such as the ones targeting resource depletion, pollution, or biodiversity are essential to avoid impact transfer for instance.

However, including those would still convey limited in- sights. Qualitative indicators would be useful to address the social impacts behind the materiality of data centers such as health issues, violations of human rights, geopolitical tensions, conflicts, etc. All those impacts should also be presented in re- gard to the purpose of the computations (scientific knowledge, economic issues, environmental benefits, etc.). This raises the question of indirect impacts of computation, that cannot be captured by mere environmental indicators.

### E. *Emission factors should not hide collective responsibility*

Since attributional emission factors are designed to spread the global emissions among users, they directly put the respon- sibility of the emissions to the end-users. However, CAPEX- related emissions actually occur before running the first job. To some extent, even the operational emissions are somehow decided *a priori* because when a partition is deployed its utilization is expected to be extensive for a more or less long period. This is especially the case if end-users are proactively encouraged to use the given platform to maximize its use rate (see also Sec. V-C). In other words this means that a very large share of the emissions are actually determined at the decision time to deploy a new partition. Thereby, any GHG mitigation strategy of computing hours should focus on this crucial decision-making process by including all users while providing them with adequate indicators and a complete panorama of platforms available and currently being deployed. In this context, the reporting of jobs' emissions to end-users may facilitate awareness, thereby enabling more informed collective decision-making.

## VI. CONCLUSION

In this paper, we detailed a rigorous methodology for reporting GHG emissions of computing hours to end-users through per *core hour* indicators. The design of such a method- ology raises several questions and choices for which there is no perfect solution. Moreover, we pointed out the intrinsic limitations of these indicators.

All these concerns do not imply that such indicators should be avoided. These indicators are, in fact, useful to make visible emissions that would otherwise be completely hidden. Our analysis, however, shows that such indicators and estimates should be provided to the end-users with clear warnings on what they do and do not mean to avoid misuses and other pitfalls. In particular, they should not be used to make com- parisons. Some issues could be partly addressed by reporting not only one, but multiple complementary indicators orga- nized along two orthogonal axes to 1) consider other socio- environmental impacts, and 2) report estimates at different scales covering a wider range of questions from short-term marginal impacts to global absolute ones. Finally, many of the questions raised in this study call for further experimentation and sociological studies to gain more profound comprehension of how end-users respond to such indicators.
ACKNOWLEDGMENTS

This work received funding from the France 2030 program, managed by the French National Research Agency under grant agreement No. ANR-23-PECL-0003.

REFERENCES

[1] ADEME, "Base empreinte - power system mix/metropolitan france/average," https://base-empreinte.ademe.fr/donnees/jeu-donnees, 2023.

[2] ——, "Methodological standard for the environmental assessment of Datacenter IT hosting services and cloud services," https://librairie.ademe.fr/produire-autrement/6105-methodological-standard-for-the-environmental-assessment-of-datacenter-it-hosting-services-and-cloud-services.html, 2023.

[3] Amazon AWS, "2023 Amazon Sustainability Report," https://sustainability.aboutamazon.com/2023-amazon-sustainability-report.pdf, 2024.

[4] ——, "Customer Carbon Footprint Tool," https://aws.amazon.com/aws-cost-management/aws-customer-carbon-footprint-tool/?nc1=h_ls, accessed March 2025.

[5] H. R. Arkes and C. Blumer, "The psychology of sunk cost," Organizational Behavior and Human Decision Processes, vol. 35, no. 1, p. 124-140, 1985.

[6] D. Benaben, F. Berthoud, G. Guennebaud, A.-L. Ligozat, and S. Valcke, "Estimation de l'empreinte carbone d'une heure de calcul sur un cœur CPU ou sur un GPU," Labos1point5, Tech. Rep., 2024.

[7] A. Berthelot, E. Caron, M. Jay, and L. Lefèvre, "Estimating the environmental impact of Generative-AI services using an LCA-based methodology," in Procedia CIRP, Turin, Italy, Jun. 2024, pp. 1-10.

[8] Carbon Trust and Global e-Sustainability Initiative (GeSI), "ICT Sector Guidance built on the GHG Protocol Product Life Cycle Accounting and Reporting Standard," https://ghgprotocol.org/sites/default/files/2023-03/GHGP-ICTSG-ALLChapters.pdf, 2017.

[9] V. C. Coroama and L. M. Hilty, "Assessing Internet energy intensity: A review of methods and results," Environmental Impact Assessment Review, vol. 45, pp. 63-68, 2014.

[10] Electricity Maps, "The leading electricity grid API," https://app.electricitymaps.com/map/72h/hourly/2025-02-28T20:00:00.000Z, accessed March 2025.

[11] C. Freitag, M. Berners-Lee, K. Widdicks, B. Knowles, G. S. Blair, and A. Friday, "The real climate and transformative impact of ICT: A critique of estimates, trends, and regulations," Patterns, vol. 2, no. 9, 2021.

[12] P. Garraghan, J. Hutchinson, and A. Friday, "ICT Sector Greenhouse Gas Emissions - Issues and Trends," https://arxiv.org/html/2410.17388v1, 2024.

[13] Google Cloud, "Carbon Footprint," https://cloud.google.com/carbon-footprint, accessed March 2025.

[14] ISO/IEC, "ISO/IEC 21031:2024 Information technology — Software Carbon Intensity (SCI) specification," standard, https://www.iso.org/standard/86612.html, 2024.

[15] ITU, "ICT industry to reduce greenhouse gas emissions by 45 per cent by 2030 - ITU, GeSI, GSMA & SBTi set science-based pathway in line with Paris Agreement," Press release, https://www.itu.int/en/mediacentre/re/Pages/PR04-2020-ICT-industry-to-reduce-greenhouse-gas-emissions-by-45-percent-by-2030.aspx, 2020.

[16] ——, "L.1410: Methodology for environmental life cycle assessments of information and communication technology goods, networks and services," https://www.itu.int/rec/T-REC-L.1410, 2024.

[17] M. Jay, V. Ostapenco, L. Lefèvre, D. Trystram, A.-C. Orgerie, and B. Fichel, "An experimental comparison of software-based power meters: focus on CPU and GPU," in IEEE/ACM international symposium on cluster, cloud and internet computing, May 2023, pp. 1-13.

[18] C. Josephson, N. Peill-Moelter, Z. Pan, B. Pfaff, and V. Firoiu, "The Sky is Not the Limit: Untapped Opportunities for Green Computing," ACM Energy Informatics Review, vol. 3, no. 3, p. 33-39, 2023.

[19] M. Kurpicz, A.-C. Orgerie, and A. Sobe, "How much does a VM cost? Energy-proportional Accounting in VM-based Environments," in PDP: Euromicro International Conference on Parallel, Distributed, and Network-Based Processing, 2016.

[20] Labos 1point5, "Labos 1point5 Research Group," https://labos1point5.org/, accessed 2025-02-26.

[21] A. S. Luccioni, S. Viguier, and A.-L. Ligozat, "Estimating the Carbon Footprint of BLOOM, a 176B Parameter Language Model," Journal of Machine Learning Research, vol. 24, no. 253, pp. 1-15, 2023.

[22] D. Margery, D. Guyon, A.-C. Orgerie, C. Morin, G. Francis, C. Palansuriya, and K. Kavoussanakis, "A CO2 emissions accounting framework with market-based incentives for Cloud infrastructures," in SMARTGREENS: International Conference on Smart Cities and Green ICT Systems, 2017.

[23] J. Mariette, O. Blanchard, O. Berné, O. Aumont, J. Carrey, A. Ligozat, E. Lellouch, P.-E. Roche, G. Guennebaud, J. Thanwerdas et al., "An open-source tool to assess the carbon footprint of research," Environmental Research: Infrastructure and Sustainability, vol. 2, no. 3, 2022.

[24] Microsoft Azure, "Emissions Impact Dashboard," https://www.microsoft.com/en-us/sustainability/emissions-impact-database, accessed 2025.

[25] B. Montbroussous, J. Schaeffer, G. P. A. Moreau, F. Berthoud, and G. Feltin, "Calculer le bilan Carbone de votre parc informatique avec EcoDiag, un service EcoInfo," in Congrès JRES : Les Journées Réseaux de l'Enseignement et de la Recherche. RENATER, 2019.

[26] C. Morand, A.-L. Ligozat, and A. Névéol, "MLCA: a tool for Machine Learning Life Cycle Assessment," in 2024 10th International Conference on ICT for Sustainability (ICT4S), 2024, pp. 227-238.

[27] I. O'Brien, "Data center emissions probably 662% higher than big tech claims. Can it keep up the ruse?" The Guardian, https://www.theguardian.com/technology/2024/sep/15/data-center-gas-emissions-tech, 2024.

[28] A. Pazienza, G. Baselli, D. Vinci, and M. V. Trussoni, "A holistic approach to environmentally sustainable computing," Innovations in Systems and Software Engineering, vol. 20, p. 347-371, 2024.

[29] Resilio and Aguaro, "Environmental impacts of IT equipment," https://resilio-solutions.com/files/news/publications/comparative-analysis/Resilio_Aguaro_Whitepaper_RDB_vs_PCF_20241025_web_en.pdf, 2024.

[30] J. Rockström, J. Donges, I. Fetzer, M. Martin, L. Wang-Erlandsson, and K. Richardson, "Planetary Boundaries guide humanity's future on Earth," Nature Reviews Earth & Environment, vol. 5, p. 773-788, 2024.

[31] J. Rockström et al., "Planetary boundaries: exploring the safe operating space for humanity," Ecology and Society, vol. 14, 2009.

[32] G. San Miguel, B. M. Bañales, D. Ruiz, S. Álvarez, J. Pérez, and M. T. Arredondo, "Carbon footprint and employment generation produced by ICT networks for Internet deployment: A multi-regional input-output analysis," Science of The Total Environment, vol. 914, 2024.

[33] D. Schrijvers, P. Loubet, and G. Sonnemann, "Critical review of guidelines against a systematic framework with regard to consistency on allocation procedures for recycling in lca," The International Journal of Life Cycle Assessment, vol. 21, 07 2016.

[34] T. Simon, D. Ekchajzer, A. Berthelot, E. Fourboul, S. Rince, and R. Rouvoy, "BoaviztAPI: a bottom-up model to assess the environmental impacts of cloud services," in Workshop on Sustainable Computer Systems (HotCarbon), 2024.

[35] M. Simonin and A.-C. Orgerie, "Méthodologies de calculs de l'empreinte carbone sur une plateforme de calcul - L'exemple du site de Rennes de Grid'5000," in JRES 2024 – Journée Réseaux de l'Enseignement Supérieur, Dec. 2024, pp. 1-13.

[36] M. T. Smith, B. Knowles, K. Widdicks, G. Blair, G. Samuel, M. Jirotka, F. Lucivero, C. T. Holter, and L. Somavilla, "Greater Than the Sum of its Parts: Exploring a systemic design inspired responsible innovation framework for addressing ICT carbon emissions," in Relating Systems Thinking and Design (RSD12), 2023.

APPENDIX

A. List of nodes of the Tier 1 French facilities in 2023

<table><thead><tr><th></th><th>Node configuration</th><th>Quantity</th></tr></thead><tbody><tr><td rowspan="4">CPU</td><td>Cascade-Lake 2.5GHz, 2 × 20 cores</td><td>1,528</td></tr><tr><td>SkyLake 2.5GHz, 40 cores</td><td>1,656</td></tr><tr><td>EPYC Rome 2.6 GHz 2 × 64 cores</td><td>2,292</td></tr><tr><td>EPYC Genoa 2.4 GHz 2 × 96 cores</td><td>544</td></tr><tr><td rowspan="5">GPU</td><td>4×V100, Cascade-Lake 2.5GHz 2 × 20 cores</td><td>612</td></tr><tr><td>4×V100, Cascade-Lake 2.1GHz 2 × 20 cores</td><td>32</td></tr><tr><td>8×V100, Cascade-Lake 2.7GHz 2 × 12 cores</td><td>31</td></tr><tr><td>8×A100, EPYC Milan 2.8GHz 2 × 32 cores</td><td>52</td></tr><tr><td>4×MI250x, EPYC Trento 2.4GHz 1 × 64 cores</td><td>356</td></tr></tbody></table>