💻 computer science

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

This paper introduces a model-based approach implemented as an nginx extension that estimates per-request resource consumption and carbon emissions for HTTP services by deriving offline energy models from observable request features, thereby enabling practical sustainability disclosures without requiring fine-grained production power telemetry.

Original authors: Geerd-Dietger Hoffmann, Verena Majuntke

Published 2026-07-03

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Geerd-Dietger Hoffmann, Verena Majuntke

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you walk into a restaurant. You order a meal, and the waiter brings you a bill. Usually, that bill tells you the price and maybe the calories. But what if it also told you exactly how much electricity and carbon pollution were created just to cook your specific dish?

That's the problem this paper tries to solve for the internet.

The Problem: The "Invisible Menu"

Right now, when you click a button on a website (like "Log In" or "Send a Message"), the server behind the scenes does some work. It uses electricity to think, store data, and send a reply. But the person clicking the button has no idea how much energy that specific click cost.

It's like ordering a meal and being told, "We use a lot of electricity to run this kitchen," but never knowing if your salad cost less energy than your steak. Because we can't see the cost, we can't make better choices to save the planet.

The Solution: "Measure Once, Model Everywhere"

The authors realized that trying to measure the electricity of every single click in real-time is too hard and too expensive (like trying to weigh every grain of rice in a bucket as you pour it).

Instead, they came up with a clever two-step recipe:

The "Test Kitchen" (Offline Measurement):
First, they take a specific website feature (like "Log In") and test it in a controlled lab. They run the "Log In" button 100 times with different inputs (short passwords, long passwords, big files) and measure exactly how much energy it uses.
- Analogy: It's like a chef testing a recipe in a quiet kitchen to see exactly how much gas is needed to boil a pot of water.
The "Recipe Card" (The Model):
From those tests, they write a simple "recipe card" (a mathematical model) for that feature.
- Simple features: "Logging out" always takes the same tiny amount of energy. The card just says: Fixed Cost: 0.006 mWh.
- Variable features: "Uploading a file" costs more if the file is bigger. The card says: Base cost + (Size of file × Energy per byte).
- AI features: For AI chat, the cost depends on how many words (tokens) you type and how many the AI writes back. The card says: Cost = (Your words × Small fee) + (AI's words × Big fee).

How It Works in Real Life

Once they have these "recipe cards," they put them into a digital registry (a JSON file). They install a special plugin on the web server (like a smart traffic cop at the entrance).

Every time you make a request:

The server looks at your request (e.g., "You are uploading a 5MB file").
It checks the "recipe card" for that specific action.
It does a quick math calculation based on your file size.
It instantly calculates the energy cost and the carbon footprint.
It sends this info back to you in the response headers (like a digital receipt), saying: "This request used 0.989 mWh of energy and created 0.633 mg of CO2."

What They Found

The authors tested this on a simple "To-Do List" app and an AI chatbot.

It's Accurate Enough: When they compared their calculated estimates against real-world measurements, the numbers were very close (within about 2-3%). It's not a perfect physics lab measurement, but it's good enough to tell the difference between a "light" request and a "heavy" one.
It's Fast: Adding this calculation to the server barely slowed anything down (less than 0.5% overhead). It's like adding a tiny sticker to a package; the delivery truck doesn't even notice.
It Handles Complexity: They showed that even for AI, where the cost depends on invisible things (like how many tokens the AI generates), they can get the app to tell the server the numbers so the server can do the math.

Why This Matters

The paper argues that this isn't about forcing people to stop using the internet. It's about making the invisible visible.

For Users: If you could see that a specific AI prompt costs 100x more energy than a simple search, you might choose to be more efficient.
For Companies: It helps them see which parts of their software are "energy hogs" so they can fix them.
For Designers: It allows for "constraint-led design." Just as a solar-powered website might dim its lights when the sun goes down, a website could show you the "energy price" of your actions, letting you decide if it's worth it.

The Catch (Limitations)

The authors are honest about the limits:

It's an Estimate: It's based on models, not a direct scale on every single request.
It Needs Updates: If the server hardware changes or the electricity grid gets dirtier/cleaner, the "recipe cards" need to be updated.
It's Not a Magic Wand: Just knowing the carbon cost doesn't automatically stop pollution. It's a tool to help people make better decisions, not a solution in itself.

In short: This paper builds a "nutrition label" for every single click on the web, so we finally know the true environmental cost of our digital interactions.

Technical Summary: Measure Once, Model Everywhere

Problem Statement
Current proposals for HTTP-based sustainability disclosure focus primarily on what environmental information should be transmitted (e.g., via response headers) but leave open the practical question of how to generate credible per-request values in realistic deployments. In cloud-native environments, resources are abstracted as elastic and on-demand, concealing the physical and ecological costs of underlying infrastructure. While providers may desire disclosure, request execution often spans multiple systems, and fine-grained power telemetry is typically unavailable at the protocol boundary. Consequently, clients and operators cannot distinguish high-cost from low-cost interactions, preventing ecological costs from being factored into design decisions such as retry behavior, batching, or prompt design.

Methodology
The paper proposes a model-based approach to estimate resource consumption and $CO_2e$ per HTTP request without requiring fine-grained production power telemetry. The method separates offline measurement from online estimation:

Offline Benchmarking: Endpoints are characterized under controlled conditions using the Green Metrics Tool (GMT) on a dedicated machine. Workload parameters (e.g., payload size, token counts) are varied systematically to isolate energy signals from noise.
Model Derivation: From these measurements, compact, endpoint-specific energy models are derived. The approach utilizes three model families to balance expressiveness and interpretability:
- Constant Models: For endpoints where energy does not vary appreciably with input (e.g., authentication).
- Linear Models: For endpoints where energy scales proportionally with an observable feature (e.g., token counts in AI inference).
- Curve (Piecewise) Models: For endpoints exhibiting distinct scaling regimes (e.g., file uploads), represented by measured support points with linear interpolation.
Feature Selection: Models rely on features observable at the HTTP server boundary (e.g., request duration, transferred bytes, HTTP method, response status) or application-supplied metadata exposed via internal headers (e.g., token counts for inference).
Emission Calculation: Predicted energy is converted to emissions by distinguishing between:
- Operational Emissions: Calculated by multiplying predicted energy by grid carbon intensity ( $I$ ), which can be static or dynamic.
- Embodied Emissions: Calculated by amortizing the hardware's manufacturing impact over its operational lifetime and allocating a share based on request processing time.
Runtime Implementation: The mechanism is implemented as an nginx extension (using ngx_http_js_module). At runtime, the server loads a JSON registry containing the models and parameters. For each request, the extension extracts relevant features, evaluates the appropriate model, and emits per-request metadata via response headers.

Key Contributions

Gap Identification: The paper separates the protocol-level question of what to disclose from the systems question of how to generate request-level values, identifying the latter as a critical gap in current sustainability discussions.
Measurement-to-Model Pipeline: It proposes a pipeline that derives compact, interpretable, and executable energy models from controlled offline benchmarks, suitable for heterogeneous endpoints including those requiring application-layer features.
Server-Side Evaluation: It demonstrates how these models can be evaluated at the HTTP server boundary and exposed as sustainability metadata while keeping underlying assumptions (e.g., grid intensity, allocation methods) explicit.
Feasibility Evaluation: The approach is evaluated across conventional web services and an AI inference endpoint, showing operational feasibility and low runtime overhead.

Results

Model Accuracy: The fitted models successfully capture workload-dependent behavior. For CRUD endpoints, constant models sufficed for authentication, while curve models captured payload-dependent scaling for file uploads and data retrieval. For the AI endpoint, a linear model using prompt and generated token counts explained nearly all observed variation, correcting for non-monotonic behavior seen when using only coarse prompt labels.
Validation: A click-path validation run (simulating a realistic user journey) showed that the model-based estimate (611.1 mWh) deviated by only 2.33% from the measured machine-level energy (597.2 mWh), preserving the correct order of magnitude.
Overhead: Enabling the nginx module introduced a runtime overhead of approximately 0.46% in total machine energy, with per-route variations dominated by run-to-run noise rather than the plugin itself.
Disclosure: The prototype successfully emits distinct headers for Request-Energy, Grid-Intensity, Request-Embodied-CO2e, and Request-SCI, allowing downstream consumers to reconstruct the calculation.

Significance and Claims
The paper positions this work not as a solution that inherently reduces demand, but as a necessary substrate for constraint-led design traditions (sufficiency, sobriety, degrowth, and low-impact server design). The authors argue that for these strategies to function, the marginal environmental cost of an interaction must be legible at the interface where the request is issued.

The significance lies in providing a reproducible, inspectable method to make environmental implications visible where decisions are made, addressing the structural exclusion of ecological costs from current software design. The authors explicitly caution against overclaiming:

The values are interface-level abstractions, not ground-truth physical attributions.
The method does not solve greenwashing or shift responsibility asymmetrically; rather, it provides the visibility layer required for such critiques to be effective.
The approach is limited by its dependence on the calibration environment (hardware, grid, co-tenancy) and requires periodic recalibration.

In summary, the paper offers a practical implementation path for per-request sustainability disclosure, transforming the abstract goal of "measuring once" into a deployable system that "models everywhere."