Adaptons cet article pour vous
Répondez à trois questions rapides et nous adapterons cet article à vos besoins.
Les organisations utilisent de plus en plus les grands modèles de langage (LLM) à travers des API facturées au jeton. Les équipes financières peuvent mesurer les dollars avec précision, mais les équipes de développement durable font face à une question plus difficile : combien de CO₂ chaque dollar dépensé en IA produit-il réellement ?
Les approches naïves supposent que les dollars correspondent directement à l’énergie, mais la tarification des API inclut la marge, la stratégie produit et les frais généraux. Les émissions physiques dépendent de l’utilisation (mise en lot), de l’efficacité du centre de données et du mix électrique au moment et à l’endroit du calcul.
Cet article propose un cadre de comptabilisation normalisé par les coûts qui estime les gCO₂e par USD de dépenses d’inférence LLM en utilisant les facteurs d’émission régionaux, des hypothèses explicites d’efficacité des centres de données (PUE), et des plages empiriques d’intensité énergétique par jeton (J/jeton).
Portée, frontières et conventions de reporting
Options de frontières opérationnelles
Nous définissons trois frontières imbriquées :
- Frontière A : Électricité opérationnelle uniquement. Inclut la consommation électrique GPU/CPU/mémoire/réseau attribuable à l’inférence, multipliée par le PUE et l’intensité du réseau.
- Frontière B : Frontière A + matériel incorporé (alloué). Ajoute les émissions de fabrication/transport/fin de vie allouées à la part de calcul de l’utilisateur.
- Frontière C : Frontière B + amortissement de l’entraînement (alloué). Ajoute une allocation par jeton des émissions d’entraînement en amont.
Le choix de frontière est une décision de reporting et doit être divulgué. Dans de nombreux contextes, la frontière A est la seule réalisable sans divulgations du fournisseur ; B et C peuvent être estimées paramétriquement.
Facteurs basés sur la localisation vs basés sur le marché
Nous recommandons les facteurs basés sur la localisation pour des estimations d’émissions physiques « sans écoblanchiment ». Les instruments basés sur le marché (certificats d’énergie renouvelable/contrats d’achat d’électricité) peuvent être divulgués séparément, mais ils ne changent pas l’électricité physiquement consommée au moment de l’inférence.
Travaux connexes et sources de données
Trois flux de données soutiennent l’estimation carbone de l’inférence :
- Facteurs d’émission du réseau (intensité carbone régionale de l’électricité), par ex., les taux de sous-région eGRID de l’EPA américaine.
- Efficacité des centres de données (PUE), généralement publiée par les hyperscalers (par ex., PUE global d’AWS).
- Intensité énergétique de l’inférence (J/jeton ou kWh/million de jetons), mesurée ou déduite du débit et de la puissance sous différentes tailles de lots et régimes de service.
Pour l’allocation du matériel incorporé, des méthodologies pratiques existent dans l’écosystème de comptabilisation carbone du cloud et dans les cadres fournisseurs/tiers pour les émissions incorporées du matériel à l’échelle de la flotte.
Le cadre : des jetons et des dollars au CO₂e
Variables fondamentales
- $T_{in}$, $T_{out}$ = jetons d’entrée et de sortie pour une charge de travail
- $P_{in}$, $P_{out}$ = prix par jeton pour l’entrée et la sortie (USD/jeton)
- $\tau$ = jetons par dollar pour une charge de travail observée (jetons/USD)
- $j$ = intensité énergétique par jeton (J/jeton)
- $\text{PUE}$ = efficacité d’utilisation de l’énergie (sans dimension)
- $CI$ = intensité carbone du réseau basée sur la localisation (kgCO₂e/kWh)
Constante de conversion :
$$1 \text{ kWh} = 3{,}6 \times 10^6 \text{ J}$$
Prix effectif par jeton
Les API LLM facturent souvent l’entrée et la sortie différemment. Définissez le prix effectif par jeton pour une charge de travail :
$$p_{\text{eff}} = \frac{T_{in} \cdot P_{in} + T_{out} \cdot P_{out}}{T_{in} + T_{out}}$$
Puis les jetons par dollar :
$$\tau = \frac{1}{p_{\text{eff}}}$$
Émissions opérationnelles par jeton (Frontière A)
Les émissions opérationnelles par jeton sont :
$$e_{\text{tok}} = \frac{j}{3{,}6 \times 10^6} \cdot \text{PUE} \cdot CI \quad [\text{kgCO}_2\text{e/jeton}]$$
Émissions opérationnelles par dollar (Frontière A)
Les émissions opérationnelles normalisées par les coûts sont :
$$e_{\text{USD}} = \tau \cdot \frac{j}{3{,}6 \times 10^6} \cdot \text{PUE} \cdot CI \quad [\text{kgCO}_2\text{e/USD}]$$
Ou en grammes par dollar :
$$\text{gCO}_2\text{e/USD} = 1000 \cdot e_{\text{USD}} \quad [\text{gCO}_2\text{e/USD}]$$
C’est le résultat central : les gCO₂e/USD dépendent linéairement des jetons par dollar, des joules par jeton, du PUE et de l’intensité du réseau — pas des dollars seuls.
Cela signifie que deux services (ou deux déploiements) avec les mêmes dépenses peuvent avoir des émissions radicalement différentes : la tarification n’encode pas l’utilisation, et l’utilisation détermine le J/jeton. Les dollars ne normalisent entre les modèles que si (i) votre prix effectif par jeton est stable et (ii) l’énergie backend par jeton est comparable — deux conditions souvent fausses en pratique.
Paramétrisation pour les régions américaines, le PUE et le J/jeton
Intensité du réseau basée sur la localisation pour les régions américaines probables
En utilisant les taux d’émission CO₂ des sous-régions eGRID 2023 de l’EPA, nous pouvons dériver des kgCO₂e/kWh représentatifs :
- ERCT (Texas/ERCOT) : ~0,333 kgCO₂e/kWh
- SRVC (région Virginie/Carolines) : ~0,269 kgCO₂e/kWh
Le choix exact de sous-région devrait correspondre à votre meilleure estimation de la région de service ; en l’absence de cette information, traitez la région comme un axe de sensibilité.
PUE (surcharge du centre de données)
Une première hypothèse raisonnable est un PUE de classe hyperscaler. AWS rapporte un PUE global de 1,15 pour 2024. Si le fournisseur ou la région diffère, traitez le PUE comme une plage (par ex., 1,10–1,30) et divulguez-le.
Intensité énergétique par jeton (J/jeton)
L’énergie par jeton varie fortement avec la mise en lot/l’utilisation. Les estimations de recherche donnent environ ~9–72 J/jeton selon les tailles de lots et les hypothèses de puissance, et ~2,7–20 kWh par million de jetons.
Étant donné la visibilité limitée des utilisateurs sur la mise en lot du fournisseur, nous recommandons d’utiliser une plage pour $j$ plutôt qu’une estimation ponctuelle.
Analyse de sensibilité : effets de la taille de lot, de la région du réseau et de la tarification
Objectif
Parce que les utilisateurs d’API ne peuvent pas observer l’utilisation interne de service (mise en lot, file d’attente, sélection du matériel), un seul J/jeton est rarement défendable. Au lieu de cela, nous quantifions comment les gCO₂e/USD varient sous des régimes de service plausibles et des régions de réseau américaines.
Conception des scénarios
Nous faisons varier :
- Le régime d’utilisation via $j$ en utilisant des plages liées à la mise en lot :
- Efficace / bien batché : $j \approx$ 9–19 J/jeton
- Modéré : $j \approx$ 14–42 J/jeton
- Mal batché : $j \approx$ 36–72 J/jeton
- La région du réseau en utilisant les sous-régions eGRID :
- SRVC (≈0,269 kg/kWh)
- ERCT (≈0,333 kg/kWh)
- Le PUE fixé à 1,15 comme hypothèse hyperscaler de référence.
- Les jetons par dollar $\tau$ : calculés à partir des grilles tarifaires officielles et du mix entrée/sortie de votre charge de travail.
Sorties de reporting
Nous recommandons de publier trois facteurs :
- Bas : ($j$ efficace, $CI$ plus bas)
- Moyen : ($j$ modéré, $CI$ moyen)
- Élevé : ($j$ médiocre, $CI$ plus élevé)
avec divulgation complète des paramètres.
Interprétation
Cette structure de sensibilité explique pourquoi deux services (ou deux déploiements) avec les mêmes dépenses peuvent avoir des émissions radicalement différentes : la tarification n’encode pas l’utilisation, et l’utilisation détermine $j$. Les gCO₂e/USD peuvent varier de >10× selon les régimes de mise en lot/utilisation plausibles, même en maintenant la région du réseau et le PUE constants.
Au-delà de l’électricité opérationnelle : matériel incorporé et entraînement
Allocation du matériel incorporé (Frontière B)
Les émissions incorporées représentent les impacts de fabrication/transport/fin de vie. Dans les environnements cloud, une approche courante consiste à allouer les émissions incorporées proportionnellement à la part d’utilisation :
$$e_{\text{emb,tok}} = \frac{E_{\text{emb,total}}}{H_{\text{life}} \cdot u \cdot r_{\text{tok/hr}}}$$
Où :
- $E_{\text{emb,total}}$ = émissions incorporées pour le système serveur/GPU concerné (kgCO₂e)
- $H_{\text{life}}$ = heures de vie (par ex., 3 ans $\approx$ 26 280 h)
- $u$ = fraction d’utilisation moyenne attribuable au service
- $r_{\text{tok/hr}}$ = jetons produits par heure à cette utilisation
Les méthodologies des fournisseurs tentent de plus en plus de mesurer le carbone incorporé à grande échelle, mais les clients d’API manquent généralement de données au niveau des actifs. Nous recommandons la frontière B comme optionnelle sauf si votre fournisseur cloud expose les allocations incorporées.
Amortissement de l’entraînement (Frontière C)
Les émissions d’entraînement peuvent être allouées sur l’ensemble de la production d’inférence de la durée de vie d’un modèle :
$$e_{\text{train,tok}} = \frac{E_{\text{train,total}}}{T_{\text{lifetime}}}$$
Où $E_{\text{train,total}}$ = émissions totales d’entraînement du modèle (kgCO₂e) et $T_{\text{lifetime}}$ = total des jetons servis sur la durée de vie commerciale du modèle.
Pour les modèles propriétaires de pointe, ces chiffres sont rarement divulgués, donc la frontière C est généralement basée sur des scénarios. Les efforts émergents vers des divulgations environnementales standardisées pour l’IA soulignent le besoin de rapports de cycle de vie comparables.
Mise en œuvre pratique
Méthode minimale viable (Frontière A)
- Mesurez $\tau$ (jetons/USD) à partir des journaux de facturation de votre charge de travail (préféré). Si non disponible, calculez $\tau$ à partir des prix officiels et de votre mix entrée/sortie observé.
- Sélectionnez la ou les régions du réseau et dérivez le $CI$ basé sur la localisation. Si la région est incertaine, utilisez une paire de régions basse/haute (par ex., SRVC vs ERCT).
- Sélectionnez le PUE (référence 1,15 ; plage si souhaité).
- Sélectionnez la plage de J/jeton à partir de sources empiriques. Utilisez au moins un $j$ bas/moyen/élevé.
- Calculez :
$$\frac{\text{gCO}_2\text{e}}{\text{USD}} = 1000 \cdot \tau \cdot \left(\frac{j}{3{,}6 \times 10^6}\right) \cdot \text{PUE} \cdot CI$$
Pipelines multi-modèles
Pour les pipelines invoquant plusieurs modèles (par ex., GPT-4.1, GPT-5.2, Claude Sonnet 4.5, Gemini 3 Pro), calculez les émissions par appel et additionnez :
$$\text{CO}_2\text{e}_{\text{pipeline}} = \sum_{m \in \mathcal{M}} \left( (T_{\text{in},m} + T_{\text{out},m}) \cdot e_{\text{tok},m} \right)$$
Si vous ne connaissez que les dollars par modèle, calculez :
$$\text{CO}_2\text{e}_{\text{pipeline}} = \sum_{m \in \mathcal{M}} \left( S_m \cdot e_{\text{USD},m} \right)$$
Où $e_{\text{USD},m}$ utilise le $\tau_m$ effectif de ce modèle (depuis les prix ou les journaux observés).
Limitations et divulgations recommandées
Incertitudes clés
- Utilisation de service / mise en lot : facteur dominant du J/jeton.
- Région exacte et réseau variable dans le temps : les facteurs basés sur la localisation peuvent varier selon la saison et l’heure ; eGRID est une moyenne annuelle.
- Choix de matériel spécifiques au modèle : différents fournisseurs peuvent utiliser différents accélérateurs et piles de service, affectant le J/jeton.
- Allocations d’entraînement et incorporées : souvent non observables pour les modèles propriétaires de pointe.
Liste de contrôle de divulgation
Lors du reporting des gCO₂e/USD, divulguez :
- La frontière (A/B/C)
- La source et la sous-région du CI
- L’hypothèse et la source du PUE
- La source et la plage du $j$
- La dérivation de $\tau$ (facturation observée vs grille tarifaire)
Conclusion
Ce cadre fournit une méthode pratique et auditable pour calculer les émissions par dollar de dépenses en jetons LLM en utilisant les facteurs de réseau basés sur la localisation. L’insight clé est que les gCO₂e/USD ne sont pas une constante : ils varient avec (i) les jetons par dollar (tarification et mix de charge de travail), (ii) les joules par jeton (utilisation/mise en lot), (iii) le PUE, et (iv) l’intensité régionale du réseau.
Parce que l’utilisation domine l’incertitude, l’approche la plus scientifiquement défendable pour les clients d’API est de publier une plage (bas/moyen/élevé) plutôt qu’une valeur unique. Des modules optionnels étendent le cadre au matériel incorporé et à l’amortissement de l’entraînement lorsque des divulgations ou des estimations crédibles existent.
Des rapports environnementaux standardisés pour l’IA amélioreraient matériellement la précision en réduisant l’incertitude sur $j$, la région et les allocations de cycle de vie.