Le problème des 200× : pourquoi le choix du modèle est désormais une décision carbone

L'écart d'efficacité entre les LLM frontier les plus frugaux et les plus énergivores dépasse actuellement 200×. LLaMA-3.2-1B consomme environ 0,07 Wh par requête courte. DeepSeek-R1 consomme 23,8 Wh pour la même tâche. Il ne s'agit pas d'une erreur d'arrondi — c'est une décision carbone que la plupart des équipes produit prennent par défaut, et non par choix délibéré.

Le panorama des benchmarks en 2025

arXiv:2505.09598 (Jegham et al.) a publié en 2025 des benchmarks d'énergie et de carbone pour un large ensemble d'endpoints d'inférence. Le constat principal : la consommation énergétique par requête s'étend sur plus de deux ordres de grandeur à travers le paysage des modèles.

Source : arXiv:2505.09598 (Jegham et al., 2025). Les chiffres sont des estimations au niveau du modèle ; la consommation réelle varie selon la longueur du prompt, le matériel et la configuration du centre de données.

L'inadéquation tâche-modèle est là où se cache le carbone

La plupart des équipes d'ingénierie choisissent un modèle une seule fois — au moment de l'architecture — et l'utilisent pour tout. Le résultat est une inadéquation systématique : des modèles frontier effectuant des tâches de classification qu'un modèle à 1B de paramètres traiterait avec une précision équivalente ; des modèles de raisonnement effectuant de la synthèse qu'un modèle standard accomplirait à 1/50e du coût carbone.

Google a rapporté une amélioration d'efficacité de 33× pour Gemini sur une période de douze mois se terminant à mi-2025. Cela suggère que la frontière d'efficacité évolue rapidement — ce qui signifie que les équipes ayant figé leur choix de modèle en 2023 ou 2024 peuvent dépenser systématiquement trop en carbone sans reconsidérer cette décision.

Comment aborder le routage par tâche

Le routage par tâche consiste à sélectionner le modèle en fonction de ce que la tâche requiert réellement, plutôt que de recourir par défaut au meilleur modèle disponible. Un cadre pratique :

1. Classifiez vos types d'appels. Auditez vos appels LLM en production et regroupez-les : classification / détection d'intention, synthèse, génération, extraction structurée, raisonnement complexe. Chaque catégorie a un seuil de qualité différent.
2. Évaluez la qualité pour chaque catégorie. Exécutez votre suite d'évaluation (ou un échantillon représentatif) sur différents niveaux de modèles. Pour de nombreuses tâches de classification et d'extraction, un modèle 7B–13B atteint la qualité d'un modèle frontier.
3. Mesurez le delta carbone. Utilisez /api/v1/estimate (public, sans authentification) avec l'identifiant du modèle alternatif et vos comptages moyens de tokens. Comparez les gCO₂e par appel entre les modèles candidats.
4. Routez en production. Implémentez un classificateur léger ou un routeur à base de règles au niveau de la passerelle. Des outils comme LiteLLM, PortKey ou une simple fonction middleware peuvent router en fonction des métadonnées de la requête sans ajouter de latence significative.

Ce que l'écart de 200× signifie pour le reporting CSRD

Pour les entreprises soumises au CSRD / ESRS E1, le choix du modèle est un levier de réduction carbone qui peut être documenté et déclaré dans le cadre d'un plan de transition climatique. Si vous pouvez démontrer que vous avez évalué des alternatives de modèles et choisi une option à moindre intensité carbone là où la qualité était équivalente, il s'agit d'une action de réduction concrète et vérifiable — bien plus solide qu'une déclaration générique « nous travaillons sur une IA verte ».

L'exigence en données est simple : les totaux d'émissions par modèle dans le temps, ventilés par cas d'usage si possible. Un dashboard affichant gCO₂e par modèle par mois vous fournit à la fois la référence de départ et la preuve d'amélioration après un changement de routage. Découvrez comment structurer ces données pour le reporting ESRS E1.

Cloud vs on-premise : un levier infrastructure souvent négligé

Le choix du modèle n'est pas le seul levier. L'infrastructure d'hébergement peut, à elle seule, modifier substantiellement l'empreinte. Des travaux de McKinsey sur les migrations cloud documentent des réductions de consommation énergétique allant jusqu'à 80 % par rapport à un hébergement on-premise traditionnel — grâce à la mutualisation des ressources, aux serveurs récents et aux programmes d'énergie renouvelable des grands opérateurs cloud. Pour les équipes qui hébergent leurs modèles en propre sur du matériel vieillissant, la migration cloud peut avoir un impact carbone supérieur au routage par tâche à court terme.

En parallèle, l'initiative AI Energy Score (portée notamment par Salesforce et Hugging Face) vise à standardiser un score d'efficacité énergétique par modèle — sur le modèle des étiquettes énergétiques électroménager. Si elle se généralise, elle fournira un signal de comparaison directement utilisable dans les politiques d'achats responsables et les critères d'appel d'offres. Pour l'instant, en l'absence de standard adopté, les benchmarks documentés comme ceux de Jegham et al. (2025) restent la référence.

Une note sur la transparence

Tous les fournisseurs ne publient pas leur méthodologie pour leurs chiffres d'énergie et de carbone. Claude (Anthropic) et plusieurs autres modèles frontier ne disposent pas de facteurs d'émission par token publiquement divulgués au début de l'année 2026. Lorsque les données primaires sont indisponibles, des benchmarks documentés avec des labels de confiance explicites (Mesuré / Benchmarké / Estimé) constituent le recours accepté par le GHG Protocol et les directives ESRS E1. La méthodologie carbon-llm étiquette chaque coefficient en conséquence.