Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions docs/blog/posts/2026_09_impactia_integration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
---
title: Integrating Impact'IA into EcoLogits
date: 2026-09-20
authors:
- samuelrince
slug: impactia-integration
description: >
EcoLogits integrates the work of the Impact'IA calculator from SNCF, Wavestone and Resilio: input tokens, data center network and building impacts, and an experimental estimation of training impacts.
categories:
- Methodology
---

# Integrating Impact'IA into EcoLogits

[Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA) is an LLM environmental footprint calculator and a detailed methodology guide developed by **SNCF**, with **Wavestone** and **Resilio**, to help companies assess the environmental impacts of their generative AI projects. It builds on the EcoLogits methodology for the inference phase and extends it to a broader scope of the model life cycle. Its authors explicitly chose not to industrialize it and suggested integrating their work into open source tools such as EcoLogits. This is what this release does.

<!-- more -->

## What changes for the inference phase

Three improvements from Impact'IA are now part of the core [LLM inference methodology](../../methodology/llm_inference.md) and apply to every request:

* **Input tokens are taken into account.** The pre-fill latency (time-to-first-token) is now modeled as a linear function of the number of input tokens, scaled to each model with its median time-to-first-token measured on OpenRouter. Long prompts (large contexts, retrieval-augmented generation, agents) now increase the estimated latency, thus the server and embodied impacts of the request. All the tracers pass the number of input tokens reported by the providers.
* **Data center network equipment is included.** The firewalls, routers and switches attached to each server are accounted for both in the electricity consumption and in the embodied impacts (GWP) of the request.
* **Data center building embodied impacts are included.** The construction of the building and of the technical environment (electrical and cooling equipment) is allocated per kWh of IT electricity consumption (GWP).

These additions are modest in magnitude (a few percent of the impacts of a request) but they widen the scope of what EcoLogits accounts for, in line with life cycle assessment practices.

## An experimental training phase

The most discussed addition of Impact'IA is the **allocation of the training impacts** of a model to each request. Training impacts (final run, research and development experiments, dataset storage) are estimated top-down from the model size, its release date and the compute capacity of the provider, then shared between all the tokens the model is expected to generate over its lifetime.

EcoLogits now reports this estimation in a new `training` phase of the impacts, see the [LLM training methodology](../../methodology/llm_training.md).

```python
response = client.chat.completions.create(model="gpt-4.1-mini", messages=[...])

print(response.impacts.gwp.value) # inference impacts (usage + embodied)
print(response.impacts.training.gwp.value) # training impacts allocated to the request
```

We chose to report the training phase **separately** and to **not include it in the total impacts** of a request for two reasons. First, the estimation of the number of tokens a model generates during its lifetime is very uncertain (at least one order of magnitude), as providers do not publish these figures. Second, the training phase can only be estimated for models with a known release date and for providers with public compute capacity announcements, so including it in the totals would make models and providers harder to compare.

While reproducing the calculator, we also found a unit inconsistency in the Impact'IA spreadsheet that divides the estimated number of generated tokens by 1000, which explains most of the training share reported by the calculator (13% of the inference impacts in median). With consistent units, the training share estimated by EcoLogits is typically below 1% for the large providers. We reported it to the Impact'IA team and the methodology will keep evolving with better data on token volumes, such as the ones some providers started publishing.

## What we did not integrate

Impact'IA also models the impacts of the **retrieval-augmented generation embeddings** and of the **application platform** (the servers hosting the application around the model) of a project. The former is on our roadmap as an embeddings methodology. The latter depends on each application architecture and is out of the scope of an API-level library, it is better assessed with tools such as [e-footprint](https://e-footprint.boavizta.org/). Finally, Impact'IA reports an AWARE-weighted water use indicator (m³ eq) that differs from the water consumption footprint (L) reported by EcoLogits, so the embodied water values were not merged.

## Thanks

Many thanks to Xavier Verne and Thibaud Auzière (SNCF), Tatiana Fouquet, Benoit Durand and Feriel Sraieb (Wavestone), Rosendo Manas Faura and You Li (Resilio) for this work and for sharing it with the community. The Impact'IA methodology guide and calculator are published under the CC BY-NC-SA license.
3 changes: 2 additions & 1 deletion docs/methodology/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,7 @@
The following methodologies are **currently available and implemented in EcoLogits**:

- [x] [LLM Inference](llm_inference.md)
- [x] [LLM Training](llm_training.md) (experimental, adapted from [Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA))
- [x] [Video Generation](video_generation.md)

Upcoming methodologies ([join us](https://discord.gg/CAecQ2zM4n) to help speed up our progress):
Expand Down Expand Up @@ -32,7 +33,7 @@ The methodology is grounded in **transparency** and **reproducibility**, utilizi

## Scope of the methodology

Our methodology focuses on **assessing the environmental impacts of GenAI inference tasks**. That is why we exclude impacts from training, networking and end-used devices, we thoroughly evaluate the impacts associated with hosting and running the model inferences.
Our methodology focuses on **assessing the environmental impacts of GenAI inference tasks**. We thoroughly evaluate the impacts associated with hosting and running the model inferences, including the network equipment and the building of the data center. We exclude the network outside of the data center and the end-user devices. The impacts of the model training are estimated separately with an [experimental methodology](llm_training.md) and are not included in the total impacts of a request.

<figure markdown="span">
![Figure: Energy consumption per output token vs. number of active parameters ](../assets/methodology/llm/figure_boundaries.png)
Expand Down
67 changes: 62 additions & 5 deletions docs/methodology/llm_inference.md
Original file line number Diff line number Diff line change
Expand Up @@ -105,6 +105,22 @@ For a typical high-end GPU-accelerated cloud instance, we use $W_{\text{server}
}' | jq .verbose.avg_power
```

#### Modeling network equipment energy consumption

Servers are connected through network equipment inside the data center (firewalls, routers and switches) that consume electricity as well. Following the [Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA) methodology, we consider that a fixed power, $W_{\text{network}}$, of network equipment is attached to each server, and allocate it to the request the same way as the server power:

$$
E_{\text{network}}(\Delta T) = \Delta T \times W_{\text{network}} \times \frac{\text{GPU}}{\#\text{GPU}_{\text{installed}}} \times \frac{1}{B}.
$$

The network power attached to one server is the sum of the power of each equipment weighted by its effective usage ratio (share of the equipment capacity used by one server), $W_{\text{network}} = \sum_i W_i \times r_i \approx 161$ W, with the following values from [ADEME Base Empreinte®](https://base-empreinte.ademe.fr/) and the [ADEME-ARCEP-ARCOM report](https://www.arcep.fr/la-regulation/grands-dossiers-thematiques-transverses/lempreinte-environnementale-du-numerique.html):

| Equipment | Power $W_i$ | Usage ratio $r_i$ |
|-----------|-------------|-------------------|
| Firewall | 90 W | 0.0358 |
| Router | 90 W | 0.286 |
| Switch | 90 W | 1.468 |

#### Estimating the generation latency

The generation latency, $\Delta T$, is the duration of the inference measure on the server and is independent of networking latency. It is estimated based on real-world statistical metrics from [OpenRouter](https://openrouter.ai) when available and falls back to an alternative approach using the [ML.ENERGY Leaderboard](https://ml.energy/leaderboard/?__theme=light) benchmark, previously mentioned.
Expand All @@ -117,6 +133,16 @@ $$
\Delta T(\#T_{\text{out}}) = \min \left\{ \text{TTFT} + \frac{\#T_{\text{out}}}{\text{TPS}}, \Delta T_{\text{request}}\right\}.
$$

##### Pre-fill latency and input tokens

The pre-fill phase consists in processing the input tokens (the prompt) before generating the first output token, its duration thus depends on the number of input tokens, $\#T_{\text{in}}$. When the number of input tokens is known, we follow the improvement proposed by [Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA) and model the pre-fill latency as a linear function of the number of input tokens, based on the measurements of [Agrawal et al. (2024)](https://www.usenix.org/conference/osdi24/presentation/agrawal) on Mistral 7B ($\text{TTFT} = 0.062 \text{ ms} \times \#T_{\text{in}} + 17.88 \text{ ms}$). The per-token coefficient is scaled to the target model with the ratio of its median time-to-first-token on OpenRouter to the one of Mistral 7B (0.44 s):

$$
\text{TTFT}(\#T_{\text{in}}) = 0.062 \text{ ms} \times \frac{\text{TTFT}_{\text{model}}}{0.44 \text{ s}} \times \#T_{\text{in}} + 17.88 \text{ ms}.
$$

When the time-to-first-token of the model is not available on OpenRouter, the coefficient is scaled with the number of active parameters instead ($P_{\text{active}} / 7.3$). When the number of input tokens is unknown, the median time-to-first-token is used as is.


??? info "Alternative approach using ML.ENERGY benchmark data (will be deprecated)"

Expand Down Expand Up @@ -169,10 +195,10 @@ To stay consistent with previous assumptions based on [ML.ENERGY Leaderboard](ht

#### Complete server energy consumption

The total server energy consumption for the request, $E_{\text{server}}$, is computed as follows:
The total server energy consumption for the request, $E_{\text{server}}$, including the network equipment, is computed as follows:

$$
E_{\text{server}} = E_{\text{server} \backslash \text{GPU}} + \text{GPU} \times E_{\text{GPU}}.
E_{\text{server}} = E_{\text{server} \backslash \text{GPU}} + \text{GPU} \times E_{\text{GPU}} + E_{\text{network}}.
$$

### Modeling request energy consumption
Expand Down Expand Up @@ -254,17 +280,44 @@ I^{\text{e}}_{\text{server}}=\frac{\text{GPU}}{\#\text{GPU}_{\text{installed}}}
$$


### Modeling network equipment embodied impacts

Following the [Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA) methodology, we also account for the embodied impacts of the network equipment attached to each server. The embodied impacts of each equipment are weighted by its usage ratio (see [above](#modeling-network-equipment-energy-consumption)), $I^{\text{e}}_{\text{network}} = \sum_i I^{\text{e}}_i \times r_i \approx 660$ kgCO2eq, using the GWP values from the [Resilio DB](https://db.resilio.tech/) reported by Impact'IA:

| Equipment | GWP (kgCO2eq) |
|------------------------------------|---------------|
| Firewall (Fortinet FortiGate 100E) | $334$ |
| Router (Juniper PTX10002-36QDD) | $403$ |
| Switch (Arista 7050TX3-48C8) | $363$ |

The lifetime of the network equipment, $\Delta L_{\text{network}}$, is fixed at 5 years.

!!! warning "Network equipment embodied impacts are only modeled for GWP due to a lack of data for ADPe and PE."

### Modeling data center building embodied impacts

The construction of the data center building and of its technical environment (electrical and cooling equipment) also has embodied impacts. We allocate them in proportion to the IT electricity consumption of the request, with a factor $F_{\text{building}} = 0.01$ kgCO2eq per kWh of IT electricity, derived by [Hubblo](https://hubblo.org/) from the ADEME product category rules for cloud services and reported by Impact'IA.

!!! warning "Data center building embodied impacts are only modeled for GWP due to a lack of data for ADPe and PE."

### Modeling request embodied environmental impacts

To allocate the server embodied impacts to the request, we use an allocation based on the hardware utilization factor, $\frac{\Delta T}{B \times \Delta L}$. In this case, $\Delta L$ represents the lifetime of the server and GPU, which we fix at 3 years ([Ostrouchov et al. (2020)](https://www.osti.gov/servlets/purl/1771896), [tomshardware.com](https://www.tomshardware.com/pc-components/gpus/datacenter-gpu-service-life-can-be-surprisingly-short-only-one-to-three-years-is-expected-according-to-unnamed-google-architect)), and $B$ is the batch size such as above:
To allocate the server embodied impacts to the request, we use an allocation based on the hardware utilization factor, $\frac{\Delta T}{B \times \Delta L}$. In this case, $\Delta L$ represents the lifetime of the server and GPU, which we fix at 3 years ([Ostrouchov et al. (2020)](https://www.osti.gov/servlets/purl/1771896), [tomshardware.com](https://www.tomshardware.com/pc-components/gpus/datacenter-gpu-service-life-can-be-surprisingly-short-only-one-to-three-years-is-expected-according-to-unnamed-google-architect)), and $B$ is the batch size such as above. The network equipment embodied impacts are allocated the same way, with the share of the server used by the model, and the data center building embodied impacts are allocated with the IT electricity consumption of the request:

$$
I^{\text{e}}_{\text{request}}=\frac{\Delta T}{B \times \Delta L} \times I^{\text{e}}_{\text{server}}.
I^{\text{e}}_{\text{request}}=\frac{\Delta T}{B \times \Delta L} \times I^{\text{e}}_{\text{server}} + \frac{\Delta T}{B \times \Delta L_{\text{network}}} \times \frac{\text{GPU}}{\#\text{GPU}_{\text{installed}}} \times I^{\text{e}}_{\text{network}} + E_{\text{server}} \times F_{\text{building}}.
$$

The last two terms only apply to the GWP criteria.

!!! warning "Water consumption (WCF) impact is not modeled for the embodied phase due to a lack of data."


## Training impacts

The impacts of the training of the model allocated to the request are estimated separately with an experimental methodology adapted from Impact'IA, see the [LLM training methodology](llm_training.md). They are reported in a dedicated `training` phase and are **not included in the total impacts** of the request.


## Supplemental material

### Data center configuration
Expand Down Expand Up @@ -302,6 +355,7 @@ Assuming the **energy consumption** for AI models is done through benchmarking o
**Limitations:**

* We do not account for the multiple modalities of a model (only text-to-text generation).
* The energy consumption of the GPU during the pre-fill phase is not modeled explicitly, the number of input tokens only affects the generation latency (thus the server, network and embodied impacts).

### On hardware

Expand All @@ -315,8 +369,9 @@ We estimate the **required infrastructure** to run the service in terms of hardw
**Limitations:**

* We do not account for TPUs or other type of accelerators.
* We do not account for networking or storage primitives.
* We do not account for storage primitives, nor for the network outside of the data center.
* We do not account for infrastructure overheads or utilization factors.
* Network equipment and data center building embodied impacts are only accounted for GWP.

### On data centers

Expand Down Expand Up @@ -354,6 +409,8 @@ We aim at covering the largest scope possible when assessing the environmental i
- [ML.ENERGY Leaderboard](https://ml.energy/leaderboard/?__theme=light) to estimate GPU energy consumption and latency based on the model architecture and number of output tokens.
- [Lees-Perasso et al. (2026)](https://librairie.ademe.fr/economie-circulaire-et-dechets/9103-analyse-de-cycle-de-vie-de-gpu-cartes-graphiques-pour-l-intelligence-artificielle.html) and [BoaviztAPI](https://github.com/Boavizta/boaviztapi) to estimate GPU and server embodied impacts and base energy consumption.
- [Our World in Data](https://ourworldindata.org/), [ADEME Base Empreinte®](https://base-empreinte.ademe.fr/) and [World Resource Institute](https://www.wri.org/) for electricity mix impacts per country.
- [Impact'IA](https://github.com/SNCF-ImpactIA/ImpactIA) (SNCF, Wavestone, Resilio, 2026) for the pre-fill latency model based on input tokens, the network equipment and the data center building impacts.
- [Agrawal et al. (2024)](https://www.usenix.org/conference/osdi24/presentation/agrawal) for the relation between pre-fill latency and number of input tokens.

## :material-bookshelf: Citation

Expand Down
Loading
Loading