Les modèles de raisonnement détruisent silencieusement votre budget carbone

Les modèles de raisonnement comme o3, DeepSeek-R1 et Gemini Thinking produisent des résultats sensiblement meilleurs sur les tâches complexes. Ils émettent également 30 à 50 fois plus de CO₂ par appel qu'une requête GPT-4o standard. La plupart des équipes d'ingénierie le découvrent seulement lorsqu'un questionnaire CSRD arrive — ou ne le découvrent jamais.

Ce que dit la recherche

Une étude de juin 2025 publiée dans arXiv:2507.11417 a quantifié les émissions d'inférence entre différentes familles de modèles. Le constat qui a retenu le plus l'attention : les modèles avec raisonnement ont généré en moyenne 543 tokens de « réflexion » par requête, contre 37 pour les modèles concis. La consommation d'énergie évoluant de manière approximativement linéaire avec les tokens traités, l'écart carbone est large et prévisible.

Un benchmark complémentaire (arXiv:2505.09598) a mis des chiffres en Wh sur ce constat :

Source : arXiv:2505.09598 (Jegham et al., 2025). Les chiffres sont des estimations basées sur l'inférence de benchmark ; la consommation réelle varie selon la configuration matérielle et la longueur du prompt.

Pourquoi les équipes passent cela à côté

Les comptages de tokens des modèles de raisonnement incluent les tokens de « réflexion » générés en interne — des tokens que vos utilisateurs ne voient jamais, mais que le modèle facture et que l'infrastructure traite. La plupart des outils d'observabilité LLM exposent la latence et les coûts ; peu exposent le CO₂ par appel, et presque aucun ne le décompose par famille de modèles d'une manière qui déclenche une alerte lorsque vous changez silencieusement un endpoint.

Un parcours de migration typique ressemble à ceci : une fonctionnalité utilise GPT-4o pendant six mois. Quelqu'un évalue o3 et obtient de meilleures évaluations. L'endpoint est remplacé en une seule ligne de configuration. Le carbone mensuel de cette fonctionnalité augmente de 40 à 70×. Personne ne s'en aperçoit jusqu'au prochain export CSRD — ou jusqu'à la prochaine question ESG d'un investisseur.

Comment simuler avant de migrer

Avant de basculer une fonctionnalité en production vers un modèle de raisonnement, vous pouvez estimer l'impact carbone en trois étapes :

1. Obtenez votre référence actuelle. À partir de vos données /track existantes, extrayez le volume mensuel de tokens et le total en gCO₂e pour la fonctionnalité (filtrez par modèle + tenant_id si nécessaire).
2. Appliquez le multiplicateur. Utilisez l'endpoint /api/v1/estimate (public, sans authentification) avec le nouvel identifiant de modèle et vos comptages moyens de tokens prompt + completion. Les gCO₂e retournés refléteront le nouveau coefficient — comparez-les à votre référence.
3. Projetez à l'échelle. Multipliez par votre volume mensuel d'appels. Si le CO₂ annuel résultant dépasse un seuil de matérialité pour votre inventaire CSRD, vous disposez des données pour justifier un déploiement sélectif (par ex. raisonnement uniquement pour les requêtes à forte valeur, modèle standard ailleurs).

Que faire avec les modèles de raisonnement

La réponse n'est pas d'éviter les modèles de raisonnement — c'est de les utiliser délibérément. Quelques approches utiles :

• Routez selon la complexité de la tâche. Réservez les endpoints de raisonnement aux requêtes qui en bénéficient de manière démontrée (rédaction juridique, revue de code) et utilisez un modèle standard pour tout le reste. Un simple classificateur d'intention au niveau de la passerelle peut automatiser cela.
• Définissez un budget carbone par fonctionnalité. Suivez les gCO₂e par fonctionnalité via tenant_id et le modèle dans votre dashboard. Lorsqu'un changement de modèle double le poste budgétaire, le dashboard le détecte avant l'export CSRD.
• Documentez le compromis. Pour les déclarations CSRD, être en mesure de montrer que vous avez évalué l'impact carbone d'un choix de modèle — et que vous avez sélectionné en conséquence — est matériellement plus solide que de n'avoir aucune donnée du tout.