Calculer l'empreinte carbone d'un LLM

L'empreinte carbone d'un LLM se calcule à partir d'un volume de tokens, pas d'un nombre de requêtes ni d'un montant facturé. Trois multiplications suffisent : les tokens donnent une énergie, l'énergie donne un CO₂e via l'intensité du réseau électrique et un terme de fabrication, la même énergie donne une consommation d'eau. Tout le reste, c'est-à-dire l'essentiel, tient dans le choix des facteurs et dans ce qu'on décide de compter. Deux calculs honnêtes peuvent différer d'un facteur 40 sans qu'aucun ne soit faux, et savoir pourquoi vaut mieux que chercher le bon chiffre.

L'équation, en trois lignes

Avec des énergies exprimées en Wh par million de tokens, distinguées par type de token :

energy_wh = (input + cache_write) × E_in
          + cache_read × E_in × 0,08
          + output × E_out

co2_grams = energy_wh × (PUE × CIF + EMB)
water_ml  = energy_wh × (WUE + PUE × EWIF)

Le PUE majore l'électricité informatique du refroidissement et des pertes du centre de données. Le CIF est l'intensité carbone du réseau qui l'alimente. Le terme EMB amortit la fabrication du matériel d'inférence, et il ne se néglige pas : dans nos paramètres Anthropic, il pèse 11,9 % du CO₂e total. Le détail des valeurs, leurs sources et leurs plages sont dans la méthodologie, le vocabulaire suivant celui du Software Carbon Intensity for AI (ISO/IEC 21031).

Le choix du modèle écrase tout le reste

Sur les facteurs du registre public, relevés le 8 septembre 2026, un million de tokens générés va d'une vingtaine de grammes de CO₂e sur les plus petits modèles à près de trente kilos sur les plus lourds, avec une médiane autour de 730 grammes. Trois ordres de grandeur d'écart, tous fournisseurs confondus, sur la même unité.

Aucun réglage d'usage ne rattrape cet écart. Router une tâche vers un modèle adapté pèse plus lourd que tout ce que vous ferez sur les volumes, et c'est aussi le levier le plus simple à documenter dans un rapport. Le classement complet, avec les niveaux de confiance par modèle, est sur la page chiffres de référence.

Ce qu'un facteur ne dit jamais tout seul

Trois questions à poser avant de reprendre une valeur publiée.

Quel périmètre ? Notre calcul couvre le tiers centre de données en inférence seule : électricité des serveurs majorée du PUE, fabrication du matériel d'inférence amortie, eau de refroidissement et eau incorporée dans l'électricité. Sont exclus les terminaux et les réseaux, qui pèsent respectivement environ 50 % et 4 % de l'empreinte du numérique en France quand les centres de données en font 46 % (actualisation ADEME-Arcep de janvier 2025 sur données 2022). Un chiffre d'ACV complète et un chiffre d'inférence ne sont pas comparables.

Location-based ou market-based ? Le premier prend l'intensité réelle du réseau, le second applique les instruments d'achat d'électricité renouvelable. L'écart n'est pas cosmétique : Google publie 94 gCO₂e/kWh en market-based contre 345 en location-based pour 2024, un facteur 3,7. Nous affichons le location-based par défaut, convention de l'AFNOR Spec 2314 et exigence du SCI, et publions l'autre à titre de comparaison.

Quelle qualité de source ? Un facteur peut venir d'un rapport primaire publié, d'une dérivation documentée ou d'une estimation d'ingénierie. Le registre affiche ce niveau modèle par modèle. À écrire une fois pour toutes : aucun facteur d'énergie par token publié aujourd'hui, chez nous comme ailleurs, n'est une mesure physique du modèle concerné. Ce sont des estimations, et les classer entre elles vaut mieux que les présenter comme des relevés.

L'entraînement reste dehors, et c'est déclaré

Le calcul porte sur l'inférence. L'entraînement n'y est pas alloué, faute d'une répartition publiée par les fournisseurs sur le nombre de requêtes servies. La position se défend dans les deux sens : inclure l'entraînement amorti serait cohérent avec une ACV produit, l'exclure est cohérent avec un inventaire d'usage. Ce qui n'est pas défendable, c'est de ne pas dire lequel des deux on a fait. Côté réglementaire, l'énergie du modèle est de toute façon documentée par son fournisseur au titre de l'article 53 de l'AI Act, pas par vous : voir AI Act et énergie de l'IA.

Le raccourci qui fausse tout : le facteur monétaire

Convertir la dépense IA en CO₂e avec un facteur d'émission monétaire sectoriel est tentant, puisque la facture est la seule donnée immédiatement disponible. Sur un cas d'école, un préprint de juin 2026 estime que cette approche surestime les émissions d'inférence de 10 à 40 fois (arXiv 2606.10660), parce que le prix d'un token varie d'un modèle à l'autre sans suivre l'énergie dépensée. Un modèle quatre fois moins cher n'est pas quatre fois plus sobre, et l'inverse s'observe aussi. Les trois méthodes de mesure et leurs écarts sont comparés dans mesurer la consommation IA de son entreprise.

FAQ

Comment calculer l'empreinte carbone d'un LLM ?

En multipliant un volume de tokens par un facteur d'énergie propre au modèle, puis l'énergie obtenue par l'intensité carbone du réseau électrique majorée du PUE, en ajoutant un terme de fabrication du matériel amorti. Le calculateur applique cette chaîne à un volume saisi, avec les facteurs publiés et versionnés de la méthodologie.

Pourquoi les chiffres publics varient-ils autant ?

Parce qu'ils ne comptent pas la même chose. Le périmètre (inférence seule ou cycle de vie), la convention carbone (location-based ou market-based), le modèle visé et l'unité retenue (une requête, un prompt médian, une réponse de 400 tokens) suffisent à produire des écarts d'un ou deux ordres de grandeur entre deux valeurs également honnêtes.

Peut-on estimer l'empreinte à partir de la facture ?

Mal. Un facteur monétaire surestime les émissions d'inférence de 10 à 40 fois sur un cas documenté, parce que le prix d'un token ne suit pas son énergie. La facture reste utile pour le pilotage financier ; pour le carbone, il faut redescendre au token par modèle.

Faut-il compter l'entraînement du modèle ?

Cela dépend de ce que vous produisez. Un inventaire d'usage l'exclut, une ACV produit l'inclut en l'amortissant. Les données publiques manquent pour la plupart des modèles propriétaires, et l'amortissement par requête n'est presque jamais publié. Dans les deux cas, la seule règle non négociable est d'écrire le périmètre retenu à côté du chiffre.

Sources