Méthodologie appliquée aux IA génératives

Résumé

Cette note méthodologique propose un cadre de calcul pour évaluer l’empreinte environnementale des modèles d’IA générative, en intégrant l’entraînement, le fine-tuning et l’inférence. La démarche repose sur l’estimation de la charge de calcul (FLOPs) requise par chaque usage, sa conversion en temps d’utilisation des GPU, puis en consommation énergétique et en émissions de gaz à effet de serre (GES). Elle inclut également la part d’impact liée à la fabrication et au cycle de vie des équipements. Cette approche vise à fournir une méthode reproductible, transparente et adaptée à différents modèles et contextes d’usage, en cohérence avec les recommandations de la recherche sur la Green AI¹.

Principe

La méthodologie repose sur une philosophie simple : relier directement les usages réels d’un modèle d’IA (entraînement, fine-tuning, inférence) à l’empreinte matérielle nécessaire pour les réaliser.

Plutôt que de partir de mesures globales de consommation électrique au niveau des centres de données, souvent inaccessibles ou propriétaires (Google, 2025²³), elle évalue en premier lieu la quantité de calcul exigée par le modèle selon :

• ses caractéristiques propres (taille, nombre de paramètres, proportion de paramètres activés, architecture),
• le volume de jetons consommés ou générés (texte, images, etc.).

Cette charge de calcul est exprimée en FLOPs, puis convertie en temps d’utilisation effectif du matériel (GPUh) en tenant compte de l’efficacité réelle (Model FLOP Utilization, MFU).

L’étape suivante traduit ce temps d’utilisation en consommation énergétique et en émissions de GES, à partir des caractéristiques physiques des GPU/serveurs et des conditions d’exploitation (PUE, facteur d’émission électrique).

Enfin, une part de l’impact lié à la fabrication et au cycle de vie des équipements est ajoutée proportionnellement au temps d’usage, suivant une logique inspirée de l’Analyse de Cycle de Vie (ACV) (ISO 14040 et 14044).

Pourquoi utiliser les FLOPs comme métrique ?

D'après l'étude Green AI¹, les FLOPs sont une métrique pertinente pour mesurer l’impact des IA génératives, car ils expriment la charge de calcul réellement effectuée, directement corrélée à la consommation d’énergie et fournissent une base indépendante du matériel pour comparer équitablement différents modèles.

Evaluation des impacts

Qu’est-ce qu’un token ?

Un jeton ou token est l’unité discrète manipulée par le modèle pour représenter une entrée ou une sortie. Selon la modalité, ce token peut être un fragment de mot, une position spatiale, ou une unité temporelle codée.

Le tableau ci‑dessous donne un repère rapide pour chaque modalité et une façon simple d’estimer les variables utilisées dans les formules.

Modalité	Ce qu’est un token	Formule (tokens / activations)	Exemple / estimation
Texte	Fragment de mot (souvent 3–4 caractères en moyenne)	$T_\text{text} = \text{nombre de mots} \times \text{tokens par mot}$	100 mots → $T_\text{text} \approx 130$–160 tokens selon le tokenizer.
Image	Token spatial / latent (patch)	$T_\text{image} = (\text{largeur}/\text{patch}) \times (\text{hauteur}/\text{patch})$	Image 512×512, patches 16×16 → 512/16 = 32 tokens par axe → 32×32 = 1 024 tokens.
Audio	Token temporel issu d’un codec (ex. EnCodec)	$T_\text{audio} = \text{durée (s)} \times \text{sample rate} \div \text{downscale} \times \text{canaux latents}$	Clip audio 10 s, sample rate 24 kHz, downscale 320, 8 canaux → $T_\text{audio} \approx 6\,000$ tokens.
Vidéo	Token spatial par frame + nombre de frames	$T_\text{frame} = (\text{largeur}/\text{patch}) \times (\text{hauteur}/\text{patch})$	Vidéo 4 s à 24 fps → $F=96$ frames. Frame 512×512, patches 16×16 → $T_\text{frame} \approx 32\times32=1\,024$ tokens par frame et $T_\text{video} = 96 \times 1\,024 = 98\,304$ tokens.

Explications des termes techniques

• Patch : découpage de l’image ou de la frame en blocs carrés traités comme un token par le modèle.
• Downscale / downsampling : réduction de la résolution spatiale (images/vidéo) ou temporelle (audio) pour passer dans un espace latent plus petit, utilisé pour le calcul des activations. Exemple : downscale 8 → largeur et hauteur divisées par 8.
• Canaux latents : nombre de dimensions dans l’espace latent (profondeur des features) pour image, vidéo ou audio.

Estimation de la charge de calcul

Cas d'usage	Formule de calcul	Variables	Explication
Entraînement	$FLOP \approx 6 \times P_\text{total} \times T_\text{training}$	$P_{total}$ : nombre total de paramètres du modèle $T_{training}$: nombre de tokens traités pendant l'entraînement (tokens × batch × steps)	Pour chaque jeton et paramètre il faut 6 FLOPs : 2 FLOPs pour la passe forward et 4 pour le calcul de gradient et la propagation (Source : Scaling Law4, Transformers FLOPs56, Transformers Inference Arithmetic7)
Fine tuning	$FLOP \approx (2 \times P_\text{total} + 4 \times P_\text{tunable}) \times T_\text{training}$	$P_{total}$ : nombre total de paramètres du modèle $P_{tunable}$ : nombre de paramètres entrainables (dépend de l'optimisation : LoRA, ...) $T_{training}$: nombre de tokens traités pendant l'entraînement (tokens × batch × steps)	Idem que pour l'entrainement complet, néanmoins le nombre de paramètres mis à jour est moindre (Source : Scaling Law4, Transformers FLOPs56, Transformers Inference Arithmetic7)
Traitement du prompt (texte)	$FLOP \approx 1 \times P_{active} \times T_{input}$	$P_{active}$ : nombre de paramètres actifs $T_{input}$: nombre de tokens du prompt	Le prompt est encodé une première fois par le modèle. Lors de la génération auto-régressive, les états intermédiaires déjà calculés sont ensuite réutilisés pour éviter de recalculer l’ensemble du contexte à chaque nouveau jeton généré. (Source : Scaling Law4, Transformers FLOPs56, Transformers Inference Arithmetic7)
Traitement du prompt (image)	$FLOP \approx 1 \times P_{active} \times N_\text{activation}$	$P_{active}$ : nombre de paramètres actifs $N_\text{activation}$ : nombre d’activations de l’image = largeur × hauteur × nombre de canaux	Chaque image du prompt est encodée une fois par le modèle. $N_\text{activation}$ correspond au nombre de tokens latents ou pixels encodés.
Traitement du prompt (audio)	$FLOP \approx 1 \times P_{active} \times N_\text{audio}$	$P_{active}$ : nombre de paramètres actifs $N_\text{audio}$ : nombre de tokens audio = durée × sample rate ÷ downscale × canaux latents	Chaque clip audio du prompt est encodé une fois par le modèle. $N_\text{audio}$ correspond aux tokens latents utilisés pour représenter le signal audio.
Génération de texte	$FLOP \approx 2 \times P_\text{active} \times T_\text{output}$	$P_{active}$ : nombre de paramètres actifs $T_{output}$: nombre de tokens générés	Pour chaque jeton et paramètre il faut 2 FLOPs pour la passe forward. Le nombre de paramètres actifs lors de l'inférence dépend de l'architecture du modèle (en particulier pour les MoE). (Source : Scaling Law4, Transformers FLOPs56, Transformers Inference Arithmetic7)
Génération d'image	$FLOP \approx 2 \times P_\text{active} \times N_\text{activation}$	$N_{activation}$: nombre d'activations = largeur x hauteur x nombre de canaux	Pour chaque activation et paramètre il faut 2 FLOPs pour la passe forward (Source : Clockwork Diffusion8, Transformers Inference Arithmetic)
Génération de vidéo (image par image)	$FLOP \approx S \times \big( 2 \times P_\text{active} \times N_\text{activation} \times F \big)$	$N_{activation}$: nombre d'activations = largeur x hauteur x nombre de canaux $F$: nombre d'images à générer $S$ : nombre d'étapes de débruitage	La génération traite chaque frame indépendamment (Source : Clockwork Diffusion8, Transformers Inference Arithmetic)
Génération de vidéo (spatio-temporelle)	$FLOP \approx S \times \big( 2 \times P_\text{active} \times N_\text{activation} \times F + 2 \times (F \times T)^2 \times d \big)$	$N_{activation}$: nombre d'activations = largeur x hauteur x nombre de canaux $F$: nombre d'images à générer $S$ : nombre d'étapes de débruitage $T$ : nombre de tokens spatiaux = largeur x hauteur $D$ : dimension latente = nombre de canaux $d$ : dimension cachée	Le premier terme correspond au coût linéaire de génération des frames. Le second modélise le coût quadratique dominant de l’auto-attention spatio-temporelle sur l’ensemble des tokens vidéo. (Source : Video Killed the Energy Budget9)
Génération d'audio (temporelle)	$FLOP \approx S \times \big( 2 \times P_\text{active} \times N_\text{audio} + 2 \times T^2 \times d \big)$	$N_{audio}$ : nombre d'activations audio latentes par étape $T$ : nombre de tokens audio temporels $d$ : dimension cachée $S$ : nombre d'étapes de débruitage	L’audio est généré par diffusion sur une séquence 1D. Le coût est linéaire pour le traitement latent et quadratique pour l’auto-attention temporelle, à chaque étape de débruitage. (Sources : AudioLM10, MusicLM11, Stable Audio Open12)

Conversion en usage GPU

Si l'on connait la capacité de traitement en FLOP d'un GPU, il est alors trivial de calculer la durée théorique de son usage afin de satisfaire un des cas d'usage précédent :

$D_{gpu} = \frac{FLOP}{(C_{gpu}\times MFU)}$

Avec $D_{gpu}$ la durée d'utilisation en heures du GPU, $C_{gpu}$ la capacité de calcul théorique en FLOP/h du GPU.

La capacité de calcul réellement utilisable par un GPU, en tenant compte de la typologie de modèle, du type de GPU/TPU, du fort parallélisme, des échanges réseaux, etc... représenterait seulement 25 à 50% de la capacité théorique (cf. Benchmarks NVidia¹³).

Ce taux d'utilisation est appelé $MFU$ (Model Flop Utilization).

Conversion en consommation d'énergie

Si l'on considère que pendant la durée d'utilisation du GPU sa consommation énergétique est maximale, le calcul de sa consommation d'énergie est simple :

$E_{gpu} = D_{gpu} \times P_{gpu}$

Avec $P_{gpu}$ la puissance en Watts du GPU

Dans un contexte de centre de données, il est pertinent de multiplier ce chiffre par son $PUE$ (Power Usage Efficiency) afin de tenir compte de son efficacité énergétique.

Impact environnemental de la consommation d'énergie

Afin d'obtenir l'impact environnemental (par exemple, émissions GES) de l'énergie, il suffit d'appliquer des facteurs d'émissions électriques comme ceux disponibles dans le référentiel Open Data D4B :

$I_{operational} = E_{gpu} \times F_{energy}$

Impact environnemental de la fabrication du GPU

L'impact lié à la fabrication du GPU est calculé proportionnellement à la durée d'usage rapportée à la durée de vie estimée du GPU :

$I_{embodied} = I_{manufacturing} \times \frac{D_{usage}}{D_{lifespan}}$

Prise en compte des impacts serveur

L’impact des autres composants (CPU, RAM, stockage, châssis) est également pris en compte. Les durées étant exprimées en GPUh, l’impact de ces composants est réparti au prorata du nombre de GPU par serveur. Par exemple, dans un serveur de 8 GPU, un huitième des impacts opérationnels et intrinsèques des composants non-GPU est imputé à chaque GPUh calculée.

$I_{total} = I_{gpu} + \frac{I_{server}}{N_{gpu/server}}$

Prise en compte des caches

Deux mécanismes de cache peuvent réduire le coût effectif de l’inférence.

Le premier est un cache d’inférence, utilisé au sein d’une même requête. Lorsqu’un prompt a été traité une première fois, les états intermédiaires associés aux jetons déjà vus peuvent être réutilisés pendant la génération des jetons suivants. Ce mécanisme explique que le coût de génération ne nécessite pas de recalculer l’ensemble du contexte à chaque étape.

Le second est un cache de préfixe, utilisé entre plusieurs requêtes distinctes partageant un même début strictement identique. Dans ce cas, une partie du prompt peut parfois être réutilisée d’une requête à l’autre, ce qui réduit le coût de traitement des jetons d’entrée.

La méthodologie de base calcule un impact brut du traitement du prompt, sans réutilisation inter-requêtes.

Lorsque plusieurs requêtes réutilisent un même préfixe, le taux de réutilisation peut être noté $r_{cache}$ :

$r_{cache} = \frac{T_{cached}}{T_{input}}$

avec :

• $T_{input}$ le nombre total de jetons d’entrée
• $T_{cached}$ le nombre de jetons d’entrée réutilisés depuis le cache
• $r_{cache} \in [0;1]$
• $r_{cache} = 0$ : aucune réutilisation du prompt
• $r_{cache} = 1$ : prompt entièrement réutilisé

Les jetons réutilisés depuis un cache ne sont toutefois pas supposés sans impact. Un coefficient résiduel $\alpha$ est introduit pour représenter l’impact d’un jeton servi depuis un cache relativement à un jeton recalculé :

• $\alpha \in [0;1]$
• $\alpha = 0$ : les jetons servis depuis un cache sont supposés négligeables devant l’impact évité
• $\alpha = 1$ : un jeton servi depuis un cache est supposé avoir le même impact qu’un jeton recalculé

L’impact effectif du prompt peut alors être approximé par :

$I_{prompt,effectif} = I_{prompt,brut} \times \big((1-r_{cache}) + \alpha \times r_{cache}\big)$

Cette correction peut être appliquée de manière identique à l’impact opérationnel et à l’impact intrinsèque du prompt. Le coût de génération des jetons de sortie reste inchangé.

remarque

Lorsque des données d’exploitation distinguent les jetons d’entrée effectivement recalculés des jetons d’entrée réutilisés depuis un cache, elles peuvent être utilisées pour estimer empiriquement $r_{cache}$. Le coefficient $\alpha$ reste quant à lui une hypothèse de modélisation : il vise à représenter l’impact résiduel associé à la mémoire, au stockage rapide et aux services nécessaires pour conserver et restituer les états en cache. Cette estimation reflète donc un contexte réel d’usage et de déploiement, et non une propriété générale du modèle.

Hypothèses & limites

Hypothèses

• Lors de la génération auto-régressive, un cache d’inférence est généralement utilisé pour réemployer les états intermédiaires déjà calculés.
• La réutilisation inter-requêtes d’un préfixe de prompt n’est pas systématique. Elle dépend du contexte de déploiement et de la stabilité effective des prompts.
• En l’absence de mesure directe, le taux de réutilisation $r_{cache}$ est une hypothèse d’usage.
• En première approximation, trois usages peuvent être retenus : un mode simple avec $\alpha = 0$, un mode prudent avec $\alpha = 0{,}1$, et un mode exploratoire sous forme de fourchette entre $0$ et $0{,}25$.

Limitations

• Incertitudes sur les données d'entrée : données d’entraînement réelles, caractéristiques des modèles souvent confidentiels, MFU, ...
• Pas de prise en compte du fait que les modèles tiennent ou non en mémoire sur le matériel sélectionné
• Pas de prise en charge des spécificités éventuelles des TPU, FPGA, Asics, ...
• Pas d'ACV fiable sur les équipements.
• La méthode ne modélise pas finement les conditions d’activation, de conservation et d’éviction des caches.
• Les jetons servis depuis un cache ne sont pas sans impact : la méthode suppose simplement que le calcul évité domine l’overhead mémoire et service associé au cache.
• Le taux réel de réutilisation d’un prompt dépend fortement de la structure des usages, de la répétitivité des préfixes et du contexte technique de déploiement.
• La valeur de $\alpha$ reste incertaine en l’absence de mesure directe de l’overhead mémoire et service associé au cache.
• Les données de facturation ou d’exploitation distinguant jetons recalculés et jetons réutilisés peuvent servir de proxy opérationnel, mais ne constituent pas une mesure physique directe de l’impact environnemental.

Perspectives

• Prendre en compte des métriques publiques comme tokens/s en plus des FLOPs.
• Prendre en compte la précision (FP32, FP16, ...)
• Intégrer un overhead pour prendre en compte l'impact du parallélisme (réseau, réplication, queuing, ...).
• Intégrer la mémoire GPU comme goulet d'étranglement.
• Intégrer à la méthodologie l'amortissement de l’entraînement sur l’inférence.
• Adapter le MFU en fonction des caractéristiques du serveur (nombre de GPU par serveur, ...).
• Intégrer des facteurs d’impact multi-critères (énergie primaire, eau, métaux rares).
• Intégrer l'entrainement des versions de développement imputables à la version actuelle d'un modèle

Application

Cette section a pour but d'évaluer le modèle en utilisant les données publiques du modèle LLM Open source Llama 3.1 (405B paramètres).

Hypothèses matérielles

Le NVIDIA DGX H100 est une configuration "classique" sur laquelle sont exécutés les traitements.

Caractéristiques	Composant	Puissance	Impact cycle de vie (approximatif)
CPU	2 x Intel Xeon Platinum 8480C processors (112 cores total)	2 x 350 = 700 W	2 x 25 = 50 kgCO2e
RAM	2TB	2 x 1024 x 0.392 = 803 W	2 x 1024 x 533 / 384 = 2843 kgCO2e
Storage	30 TB SSD	30 x 1024 x 0.0012 = 37 W	30 x 1024 x 0.16 = 4915 kgCO2e
GPU	8 x H100 80 GB(989 TFLOP/s par GPU)	8 x 700 W	8 x 250 kgCO2e
Chassis		-	250 kgCO2e
Total (hors GPU)		1540 W	10058 kgCO2e
Total (hors GPU) / h		1540 W	10058 / (5 x 24 x 365, 25) = 0,230 kgCO2e / h

Impact de l'entrainement

Llama 3.1 (405B paramètres) a été entrainé avec environ 15 trillions (15e12) jetons. D'après Huggingface, il a été entrainé avec 24576 GPU H100 : Training Time (GPU hours) Power Consumption (W) Emissions (tons CO2eq) Llama 3.1 8B 1.46M 700 420 Llama 3.1 70B 7.0M 700 2 040 Llama 3.1 405B 30.84M 700 8 930

D'après les formules du modèle et en prenant pour hypothèse un MFU de 40% (à affiner d'après les benchmarks NVIDIA¹³ il pourrait être plus proche de 35%) pour l'entrainement, un PUE de 1,2 et un facteur d'émission GES de 0,420 kgCO2e / kWh :

$$\begin{aligned} &FLOP_{training} = 6 \times P_{total} \times T_{training} = 6 \times 405e9 \times 15e12 = 3,65e25 FLOP \\ &D_{training} = \frac{FLOP_{training}}{FLOP_{gpu} \times MFU} = \frac{FLOP_{training}}{989e12 * 3600 \times 0,40} = 25,6e6 GPU.h \\ &E_{training} = 0,700 \times D_{training} \times PUE = 21,5e6 kWh \\ &I^{gpu}_{training_{ope}} = 0,420 \times E_{training} = 9 030 tCO2e \\ \end{aligned}$$

remarque

L'écart entre les données fournies sur Huggingface et le calcul est < 2% ce qui reste très raisonnable.

Pour l'impact intrinsèque, on prend pour hypothèse une durée de vie des équipements de 5 ans :

$I^{gpu}_{training_{emb}} = \frac{D_{training}}{D_{lifespan}} \times I_{total_{emb}} = \frac{25,6e6}{(5 \times 24 \times 365,25)} \times 250 = 146 tCO2e$

remarque

On constate que l'impact intrinsèque est considérablement plus faible que l'impact opérationnel.

A l'impact du GPU il convient d'ajouter l'impact opérationnel et intrinsèque du serveur. Il y a 8 GPUs par serveur, donc on ajoute 1 / 8 des composants autres que GPU.

$$\begin{aligned} &I_{training_{ope}} = I^{gpu}_{training_{ope}} + \frac{I^{server}_{training_{ope}}}{8} = 9030 + \frac{25,6e6 \times 1,540 \times 0,420 \times 1,2 }{8} = 11513 tCO2e \\ &I_{training_{emb}} = I^{gpu}_{training_{emb}} + \frac{I^{server}_{training_{emb}}}{8} = 146 + \frac{25,6e6 \times 0,000230}{8} = 899tCO2e \end{aligned}$$

Impact de la génération d'1 million de jetons

Dans un usage de type complétion, le coût d’inférence se décompose en deux parties : le traitement initial du prompt, puis la génération des jetons de sortie. Lors de la génération, les états intermédiaires déjà calculés pour le contexte sont réutilisés, ce qui évite de recalculer l’ensemble du prompt à chaque nouveau jeton. Lorsque plusieurs requêtes partagent en plus un même préfixe, le coût de traitement des jetons d’entrée peut être encore réduit si cette réutilisation est effectivement exploitée. Les calculs ci-dessous correspondent toutefois à un cas de base sans correction explicite par $r_{cache}$.

$$\begin{aligned} &I^{gpu}_{output_{ope}} = \frac{2 \times 405e9 \times 1e6}{989e12 \times 3600 \times 0,40} \times (0,700 + \frac{1,540}{8}) \times 1,2 \times 0,420 = 256gCO2e \\ &I^{gpu}_{output_{emb}} = \frac{2 \times 405e9 \times 1e6}{989e12 \times 3600 \times 0,40} \times \frac{250 + \frac{10058}{8}}{5\times24\times365,25} = 20gCO2e \end{aligned}$$

Si l'on considère une taille de "prompt moyen" d'environ 400 jetons, alors l'impact d'une requête est d'environ 0,1 gCO2e.

Simulateur

Paramètres

Cas d'usage

Modèle

Matériel

PUE

Région

Corpus (milliard de jetons)

Résultats

Charge de calcul : --

Latence : --

Durée de traitement : --

Débit : --

Énergie : --

GPU

CPU

RAM

Stockage

Chassis

Émissions GES : --

GPU

CPU

RAM

Stockage

Chassis

Operational

Embodied

Comparaison

Cette section propose une comparaison de méthodologies disponibles pour l’évaluation des impacts environnementaux des modèles d’IA générative. Elle met en évidence leurs périmètres, leurs forces et leurs limites, afin de situer la méthodologie D4B par rapport aux approches existantes.

Caractéristique	Full ACV (Google, 2025)23	Ecologits14	Méthodologie D4B
Type d’approche	Mesure full-stack : CPU/DRAM, machines idle, datacenter overhead, eau, ACV partielle du hardware	Evaluation bottom-up appliqué à l’inférence uniquement (usage + fabrication)	Modélisation FLOPs → GPUh → Impacts
Périmètre	Fabrication (partielle), usage (tous composants serveur), infrastructure datacenter, eau, émissions Scope 2/3	Usage infra + fabrication, inférence seulement	Usage entraînement, fine tuning, inférence + fabrication GPU et serveur
Granularité & mesure	Très fine : mesures réelles sur production Gemini, énergie, eau, émissions	Moyenne haute, open data multi-critères (GWP, PE, ADPe) agrégés par appel API	Moyenne modérée : dépend des données disponibles (FLOPs, TDP, ...)
Accessibilité	Faible : données internes Google peu explicitées	Elevée : code open-source, API ouverte	Elevée : méthodes et hypothèses documentées publiquement
Reproductibilité	Faible : instrumentation propriétaire et données internes	Forte : outil public, calculs transparents et reproductibles	Moyenne à élevée : si les données d’entrée sont estimables
Transparence	Moyenne : publication méthode mais accès aux données limité	Forte : codes, hypothèses et modèle open source	Forte : toutes les formules et sources sont explicitées
Précision (sur inférence)	Très élevée : vrai déploiement mesuré, inclut spectre complet d’énergie	Moyenne : repose sur modèles simplifiés et hypothèses généralisées	Moyenne à élevée selon la précision des paramètres choisis
Applicabilité	Limitée : spécifique à l’infrastructure Google et inférence	Moyenne : inférence sur divers fournisseurs, mais pas entraînement	Très large : entraînement, fine tuning, inférence sur base publique
Usages visés	Analyse interne, reporting fin, communication	Évaluation publique, sensibilisation, comparateur multi-fournisseurs	Recherche, évaluation interne, FinOps, Green AI
Résultats chiffrés (Prompt moyen, environ 400 jetons)	~0,03 gCO2e ~0,24 Wh Gemini	~40 gCO2e ~95 Wh LLama 3.1 405b	~0,12 gCO2e ~0,27 Wh LLama 3.1 405b (cf. Application)
Limites clés	Données propriétaires, ne couvre pas l’entraînement, se concentre sur l'inférence, biais sur le “prompt median”	Périmètre limité (inférence seule), possible surestimation du fait de l'extrapolation	Dépend fortement des hypothèses (MFU, durée de vie)

Ces résultats montrent que chaque approche a un positionnement spécifique : Google privilégie la précision mais reste fermé et non reproductible, Ecologits mise sur la transparence et la simplicité mais au prix d’une surestimation possible, tandis que la méthodologie D4B propose un compromis reproductible et adaptable aux différents contextes d’usage mais dépend de la précision des données d'entrée.

Footnotes

1. Schwartz et al., 2020, Henderson et al., 2020. Green AI ↩ ↩²

2. Google, 2025. Measuring the environmental impact of delivering AI at Google Scale ↩ ↩²

3. Google, 2025. Life-Cycle Emissions of AI Hardware: A Cradle-To-Grave Approach and Generational Trends ↩ ↩²

4. J. Kaplan, S. McCandlish, ..., 2020. Scaling Laws for Neural Language Models ↩ ↩² ↩³ ↩⁴

5. A. Casson, 2023. Transformer FLOPs ↩ ↩² ↩³ ↩⁴

6. D. Bahdanau, 2022. The FLOPs Calculus of Language Model Training ↩ ↩² ↩³ ↩⁴

7. C. Chen, 2023. Transformer Inference Arithmetic ↩ ↩² ↩³ ↩⁴

8. A. Habibian, A. Ghodrati, ... 2024. Clockwork Diffusion: Efficient Generation With Model-Step Distillation ↩ ↩²

9. Julien Delavande, Regis Pierrard, 2025. Video Killed the Energy Budget: Characterizing the Latency and Power Regimes of Open Text-to-Video Models ↩

10. Zalan Borsos, Raphael Marinier, Damien Vincent, ..., 2023. AudioLM ↩

11. Andrea Agostinelli, Timo I. Denk, Zalán Borsos, ..., 2023. MusicLM ↩

12. Zach Evans, Julian D. Parker, ..., 2024. Stable Audio Open ↩

13. NVidia, 2025. Llama 3.1 70B 24.11.1 (DGXC Benchmarking) ↩ ↩²

14. GenAI Impact. EcoLogits ↩