💻 computer science

Measure Once, Model Everywhere: Model-Based Per-Request Resource Consumption for HTTP

Cet article présente une approche basée sur un modèle, implémentée sous la forme d'une extension nginx, qui estime la consommation de ressources et les émissions de carbone par requête pour les services HTTP en dérivant des modèles énergétiques hors ligne à partir de caractéristiques de requête observables, permettant ainsi des divulgations de durabilité pratiques sans nécessiter de télémétrie de puissance de production de précision.

Auteurs originaux : Geerd-Dietger Hoffmann, Verena Majuntke

Publié 2026-07-03

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Geerd-Dietger Hoffmann, Verena Majuntke

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous entriez dans un restaurant. Vous commandez un plat, et le serveur vous apporte l'addition. Habituellement, cette addition indique le prix et peut-être les calories. Mais et si elle vous indiquait aussi exactement quelle quantité d'électricité et de pollution carbone a été générée juste pour cuisiner votre plat spécifique ?

C'est le problème que ce document tente de résoudre pour l'internet.

Le Problème : Le « Menu Invisible »

Actuellement, lorsque vous cliquez sur un bouton sur un site web (comme « Se connecter » ou « Envoyer un message »), le serveur en coulisses effectue un travail. Il utilise de l'électricité pour réfléchir, stocker des données et envoyer une réponse. Mais la personne qui clique sur le bouton n'a aucune idée de l'énergie que ce clic spécifique a coûté.

C'est comme commander un repas et s'entendre dire : « Nous utilisons beaucoup d'électricité pour faire fonctionner cette cuisine », sans jamais savoir si votre salade a coûté moins d'énergie que votre steak. Parce que nous ne pouvons pas voir le coût, nous ne pouvons pas prendre de meilleures décisions pour sauver la planète.

La Solution : « Mesurer une fois, modéliser partout »

Les auteurs ont réalisé que tenter de mesurer l'électricité de chaque clic individuel en temps réel est trop difficile et trop coûteux (c'est comme essayer de peser chaque grain de riz dans un seau pendant que vous le versez).

Au lieu de cela, ils ont conçu une recette intelligente en deux étapes :

La « Cuisine de Test » (Mesure hors ligne) :
D'abord, ils prennent une fonctionnalité spécifique d'un site web (comme « Se connecter ») et la testent dans un laboratoire contrôlé. Ils exécutent le bouton « Se connecter » 100 fois avec différentes entrées (mots de passe courts, mots de passe longs, gros fichiers) et mesurent exactement l'énergie qu'il consomme.

Analogie : C'est comme un chef qui teste une recette dans une cuisine calme pour voir exactement quelle quantité de gaz est nécessaire pour faire bouillir une casserole d'eau.

La « Fiche Recette » (Le Modèle) :
À partir de ces tests, ils écrivent une « fiche recette » simple (un modèle mathématique) pour cette fonctionnalité.

Fonctionnalités simples : « Se déconnecter » consomme toujours la même petite quantité d'énergie. La fiche indique simplement : Coût fixe : 0,006 mWh.
Fonctionnalités variables : « Télécharger un fichier » coûte plus cher si le fichier est plus gros. La fiche indique : Coût de base + (Taille du fichier × Énergie par octet).
Fonctionnalités d'IA : Pour le chat IA, le coût dépend du nombre de mots (tokens) que vous tapez et du nombre de mots que l'IA génère en retour. La fiche indique : Coût = (Vos mots × Petit frais) + (Mots de l'IA × Gros frais).

Comment cela fonctionne en situation réelle

Une fois qu'ils ont ces « fiches recettes », ils les placent dans un registre numérique (un fichier JSON). Ils installent un plugin spécial sur le serveur web (comme un agent de circulation intelligent à l'entrée).

Chaque fois que vous faites une requête :

Le serveur examine votre requête (ex : « Vous téléchargez un fichier de 5 Mo »).
Il vérifie la « fiche recette » pour cette action spécifique.
Il effectue un calcul mathématique rapide basé sur la taille de votre fichier.
Il calcule instantanément le coût énergétique et l'empreinte carbone.
Il vous renvoie cette information dans les en-têtes de la réponse (comme un reçu numérique), disant : « Cette requête a utilisé 0,989 mWh d'énergie et a généré 0,633 mg de CO2. »

Ce qu'ils ont découvert

Les auteurs ont testé cela sur une application simple de « Liste de tâches » et un chatbot d'IA.

C'est assez précis : Lorsqu'ils ont comparé leurs estimations calculées aux mesures réelles, les chiffres étaient très proches (à environ 2-3 % près). Ce n'est pas une mesure de laboratoire de physique parfaite, mais c'est suffisant pour faire la différence entre une requête « légère » et une requête « lourde ».
C'est rapide : L'ajout de ce calcul au serveur n'a presque rien ralenti (moins de 0,5 % de surcharge). C'est comme ajouter un petit autocollant sur un colis ; le camion de livraison ne remarque même pas la différence.
Cela gère la complexité : Ils ont montré que même pour l'IA, où le coût dépend de choses invisibles (comme le nombre de tokens que l'IA génère), ils peuvent faire en sorte que l'application transmette les chiffres au serveur pour que le serveur puisse faire le calcul.

Pourquoi cela importe

Les auteurs soutiennent qu'il ne s'agit pas de forcer les gens à arrêter d'utiliser internet. Il s'agit de rendre l'invisible visible.

Pour les utilisateurs : Si vous pouviez voir qu'une requête d'IA spécifique coûte 100 fois plus d'énergie qu'une recherche simple, vous pourriez choisir d'être plus efficace.
Pour les entreprises : Cela les aide à voir quelles parties de leur logiciel sont des « gouffres énergétiques » afin qu'elles puissent les corriger.
Pour les concepteurs : Cela permet une « conception sous contrainte ». Tout comme un site web alimenté par l'énergie solaire pourrait baisser la luminosité de ses lumières quand le soleil se couche, un site web pourrait vous montrer le « prix énergétique » de vos actions, vous laissant décider si cela en vaut la peine.

Le revers de la médaille (Limites)

Les auteurs sont honnêtes quant aux limites :

C'est une estimation : Elle est basée sur des modèles, pas sur une balance directe pour chaque requête.
Cela nécessite des mises à jour : Si le matériel du serveur change ou si le réseau électrique devient plus sale ou plus propre, les « fiches recettes » doivent être mises à jour.
Ce n'est pas une baguette magique : Connaître le coût carbone ne suffit pas à arrêter automatiquement la pollution. C'est un outil pour aider les gens à prendre de meilleures décisions, pas une solution en soi.

En bref : Ce document construit une « étiquette nutritionnelle » pour chaque clic sur le web, afin que nous sachions enfin le véritable coût environnemental de nos interactions numériques.

Résumé technique : Mesurer une fois, modéliser partout

Énoncé du problème
Les propositions actuelles concernant la divulgation de la durabilité basée sur HTTP se concentrent principalement sur le quoi (quelles informations environnementales doivent être transmises, par exemple via des en-têtes de réponse), mais laissent ouverte la question pratique du comment générer des valeurs crédibles par requête dans des déploiements réalistes. Dans les environnements cloud-native, les ressources sont abstraites comme étant élastiques et à la demande, dissimulant les coûts physiques et écologiques de l'infrastructure sous-jacente. Bien que les fournisseurs puissent souhaiter une divulgation, l'exécution d'une requête peut s'étendre sur plusieurs systèmes, et la télémétrie de puissance fine est généralement indisponible au niveau de la frontière du protocole. Par conséquent, les clients et les opérateurs ne peuvent pas distinguer les interactions à coût élevé des interactions à faible coût, ce qui empêche de prendre en compte les coûts écologiques dans les décisions de conception telles que le comportement de réessai, le regroupement (batching) ou la conception de prompts.

Méthodologie
Le document propose une approche basée sur la modélisation pour estimer la consommation de ressources et le $CO_2e$ par requête HTTP sans nécessiter de télémétrie de puissance de production de haute précision. La méthode sépare la mesure hors ligne de l'estimation en ligne :

Étalonnage hors ligne (Offline Benchmarking) : Les points de terminaison (endpoints) sont caractérisés dans des conditions contrôlées à l'aide de l'outil Green Metrics Tool (GMT) sur une machine dédiée. Les paramètres de la charge de travail (par exemple, taille de la charge utile, nombre de tokens) sont variés systématiquement pour isoler les signaux énergétiques du bruit.
Dérivation du modèle : À partir de ces mesures, des modèles énergétiques compacts et spécifiques à chaque point de terminaison sont dérivés. L'approche utilise trois familles de modèles pour équilibrer expressivité et interprétabilité :
- Modèles constants : Pour les points de terminaison où l'énergie ne varie pas de manière perceptible avec l'entrée (ex. : authentification).
- Modèles linéaires : Pour les points de terminaison où l'énergie évolue proportionnellement à une caractéristique observable (ex. : nombre de tokens dans l'inférence IA).
- Modèles de courbe (par morceaux) : Pour les points de terminaits présentant des régimes de mise à l'échelle distincts (ex. : téléchargement de fichiers), représentés par des points de support mesurés avec une interpolation linéaire.
Sélection de caractéristiques (Feature Selection) : Les modèles s'appuient sur des caractéristiques observables à la frontière du serveur HTTP (ex. : durée de la requête, octets transférés, méthode HTTP, statut de la réponse) ou sur des métadonnées fournies par l'application et exposées via des en-têtes internes (ex. : nombre de tokens pour l'inférence).
Calcul des émissions : L'énergie prédite est convertie en émissions en distinguant :
- Émissions opérationnelles : Calculées en multipliant l'énergie prédite par l'intensité carbone du réseau ( $I$ ), qui peut être statique ou dynamique.
- Émissions incorporées : Calculées en amortissant l'impact de fabrication du matériel sur sa durée de vie opérationnelle et en allouant une part basée sur le temps de traitement de la requête.
Implémentation au runtime : Le mécanisme est implémenté comme une extension nginx (utilisant ngx_http_js_module). Au runtime, le serveur charge un registre JSON contenant les modèles et les paramètres. Pour chaque requête, l'extension extrait les caractéristiques pertinentes, évalue le modèle approprié et émet les métadonnées de durabilité via des en-têtes de réponse.

Contributions clés

Identification de l'écart (Gap Identification) : Le document sépare la question protocolaire du quoi divulguer de la question systémique du comment générer des valeurs par requête, identifiant cette dernière comme un écart critique dans les discussions actuelles sur la durabilité.
Pipeline de la mesure au modèle : Il propose un pipeline qui dérive des modèles énergétiques compacts, interprétables et exécutables à partir de benchmarks hors ligne contrôlés, adaptés à des points de terminaison hétérogènes, y compris ceux nécessant des fonctionnalités de la couche applicative.
Évaluation côté serveur : Il démontre comment ces modèles peuvent être évalués à la frontière du serveur HTTP et exposés en tant que métadonnées de durabilité tout en rendant explicites les hypothèses sous-jacentes (ex. : intensité du réseau, méthodes d'allocation).
Évaluation de la faisabilité : L'approche est évaluée à travers des services web conventionnels et un point de terminaison d'inférence IA, montrant une faisabilité opérationnelle et un faible surcoût (overhead) de runtime.

Résultats

Précision du modèle : Les modèles ajustés capturent avec succès le comportement dépendant de la charge de travail. Pour les points de terminaison CRUD, des modèles constants ont suffi pour l'authentification, tandis que des modèles de courbe ont capturé la mise à l'échelle dépendante de la charge utile pour les téléchargements de fichiers et la récupération de données. Pour le point de terminaison IA, un modèle linéaire utilisant le nombre de tokens de prompt et de génération a expliqué la quasi-totalité de la variation observée, corrigeant le comportement non monotone constaté lors de l'utilisation de simples étiquettes de prompt.
Validation : Une exécution de validation par parcours utilisateur (simulant un trajet utilisateur réaliste) a montré que l'estimation basée sur le modèle (611,1 mWh) ne déviait que de 2,33 % de l'énergie mesurée au niveau de la machine (597,2 mWh), préservant ainsi le bon ordre de grandeur.
Surcoût (Overhead) : L'activation du module nginx a introduit un surcoût de runtime d'environ 0,46 % de l'énergie totale de la machine, les variations par route étant dominées par le bruit d'exécution plutôt que par le plugin lui-même.
Divulgation : Le prototype émet avec succès des en-têtes distincts pour Request-Energy, Grid-Intensity, Request-Embodied-CO2e et Request-SCI, permettant aux consommateurs en aval de reconstruire le calcul.

Signification et affirmations
Le document positionne ce travail non pas comme une solution visant intrinsèquement à réduire la demande, mais comme un substrat nécessaire aux traditions de conception fondées sur les contraintes (suffisance, sobriété, décroissance et conception de serveurs à faible impact). Les auteurs soutiennent que pour que ces stratégies fonctionnent, le coût environnemental marginal d'une interaction doit être intelligible à l'interface où la requête est émise.

La signification réside dans la fourniture d'une méthode reproductible et inspectable pour rendre les implications environnementales visibles là où les décisions sont prises, répondant ainsi à l'exclusion structurelle des coûts écologiques dans la conception logicielle actuelle. Les auteurs mettent explicitement en garde contre toute sur-affirmation :

Les valeurs sont des abstractions au niveau de l'interface, et non des attributions physiques de vérité terrain.
La méthode ne résout pas le problème du greenwashing ni ne déplace la responsabilité de manière asymétrique ; elle fournit plutôt la couche de visibilité nécessaire pour que de telles critiques soient efficaces.
L'approche est limitée par sa dépendance à l'environnement de calibration (matériel, réseau, co-location) et nécessite un réétalonnage périodique.

En résumé, le document offre une voie d'implémentation pratique pour la divulgation de la durabilité par requête, transformant l'objectif abstrait de « mesurer une fois » en un système déployable qui « modélise partout ».