Measuring the Energy & Carbon of AI (the A/E Metric)

TL;DR — To measure what one AI task costs the planet, you need two multiplications. First, energy = power × time, scaled up by the data center's PUE overhead → kWh. Second, carbon = energy × CI, where CI is the grid's carbon intensity when the job runs → gCO₂. The A/E metric — accuracy (or task value) per unit energy — lets you compare models fairly, because a model that's 1% more accurate but uses 3× the energy is often the worse engineering choice. Critical distinction: this measures the JOB's own footprint (like MPG of a car), which is different from the grid's hourly cleanliness (the other article). They're complementary — multiply them to get real carbon, then schedule the job into a clean hour.

---

1. Simple explanation

Every AI task — training a model, running inference, generating an image — burns electricity. The chip (GPU/CPU) draws power (watts) while it works for some time (hours). Power times time is energy (kWh). That's the physics.

But the chip isn't the whole story. It lives in a data center that also spends energy on cooling, power conversion, and lighting. We capture that overhead with a single multiplier called PUE (Power Usage Effectiveness). A PUE of 1.5 means: for every 1 kWh the chip uses, the facility spends 1.5 kWh total.

Once you know the energy, you get carbon by multiplying by the grid's carbon intensity CI (from the Why Grid Carbon Intensity Varies Hour to Hour article). Energy tells you how much; CI tells you how dirty.

Finally, the A/E metric ("A over E") divides what the task achieved (accuracy, or any value measure) by the energy it cost. It answers: how much useful work per joule? A model with higher A/E gives you more brains per watt.

Analogy — a car's fuel economy. Measuring an AI task's energy/carbon is exactly like measuring a car's miles per gallon. power × time is how much fuel the engine burns on a trip. PUE is like counting the fuel wasted on idling and the AC, not just moving the wheels. And A/E is the MPG itself — distance achieved per fuel burned. A sports car (huge model) might arrive 1 minute sooner but guzzle 3× the gas. That's the trade A/E makes visible.

Keep this analogy — the next article contrasts it with the grid's cleanliness, which is a completely different thing.

---

2. Diagram

   MEASURING ONE AI TASK'S FOOTPRINT

   ┌──────────────┐   power(W)      ┌──────────────┐
   │ GPU / CPU    │  ────×────►      │  IT ENERGY   │   E_it (kWh)
   │ draws watts  │   time(h)        │ = P × t /1000│
   └──────────────┘                  └──────┬───────┘
                                            │  × PUE   (cooling, power loss)
                                            ▼
                                     ┌──────────────┐
                                     │ FACILITY kWh │   E = E_it × PUE
                                     └──────┬───────┘
                    × CI(t) (gCO2/kWh)      │              ┌─ A/E METRIC ─┐
                    from GRID article       │              │  value (acc) │
                                            ▼              │  ──────────  │
                                     ┌──────────────┐      │   E (kWh)    │
                                     │   CARBON     │      └──────────────┘
                                     │ = E × CI     │   gCO2   "brains per watt"
                                     └──────────────┘

   TWO DIFFERENT OBJECTS (do not confuse):
     THIS ARTICLE:  the JOB's footprint  (how much fuel the trip burned)   ── CCI / A-E
     GRID  ARTICLE: the electricity's cleanliness each hour (when to drive) ── CI(t)
     They MULTIPLY together (E × CI) and COMPOSE (schedule the job into a clean hour).

---

3. How it works

3.1 Energy = power × time

The base measurement:

   E_it (kWh) = P (kW) × t (hours)

• P = the chip's power draw in kilowatts. A data-center GPU like an NVIDIA A100 draws roughly 400 W = 0.4 kW under load; an H100 more. Measure it, don't guess.
• t = wall-clock runtime in hours.

You can measure P directly: nvidia-smi reports GPU watts, Intel RAPL reports CPU/DRAM energy, and tools like CodeCarbon or Zeus wrap both.

3.2 PUE — the data-center overhead

The chip isn't alone. PUE (Power Usage Effectiveness) multiplies IT energy up to facility energy:

   PUE = total facility energy / IT equipment energy
   E (facility kWh) = E_it × PUE

A PUE of 1.5 means one third of the electricity never touches a chip — it's cooling and conversion loss.

3.3 Carbon = energy × CI

Now convert energy to carbon using the grid's intensity at run time:

   carbon (gCO2) = E (kWh) × CI(t) (gCO2/kWh)

This is the bridge to the other article. The same job (same E) emits wildly different carbon depending on when it runs — because CI(t) swings ~6×. So the job's footprint has two knobs: make E smaller (efficiency) and make CI smaller (timing).

3.4 The A/E metric — fair model comparison

Raw accuracy hides cost. The A/E metric exposes it:

   A/E = task value / energy       e.g. accuracy(%) per kWh,  or  tokens per kWh,
                                    or  (queries answered) per kWh

Higher A/E = more useful work per unit energy. It reframes the question from "which model is most accurate?" to "which model gives the best accuracy for the energy?" — the actual engineering question. A tiny accuracy gain that triples energy usually loses on A/E. This "useful-work-per-joule" framing is the object of the published "Carbon Cost of Intelligence" (CCI) work (DOI 10.3390/en19030642), which this module draws on as lab context.

3.5 The critical distinction (read this twice)

   ┌───────────────────────────── DIFFERENT OBJECTS ─────────────────────────────┐
   │                                                                              │
   │  THIS article  →  the AI TASK's OWN energy & carbon  (CCI / A-E metric)      │
   │                   "how much fuel does THIS job burn?"   — a property of the  │
   │                    model + hardware + runtime.                               │
   │                                                                              │
   │  GRID article  →  the GRID's carbon INTENSITY each hour  (CI(t))             │
   │                   "how dirty is the electricity RIGHT NOW?" — a property of  │
   │                    the grid's fuel mix, nothing to do with your job.         │
   │                                                                              │
   │  Analogy:  CCI/A-E = a car's fuel-per-trip (the car).                        │
   │            grid CI = knowing WHEN the electricity is cleanest (the world).   │
   └──────────────────────────────────────────────────────────────────────────────┘

They are complementary, not the same:

1. Multiply them to get the job's actual carbon: carbon = E_job × CI(t_run).
2. Compose them: once you know a job's E, you can schedule it into a clean-CI window — that's Carbon-Aware Scheduling of Flexible Loads. Reducing E (this article) and reducing CI (timing) are two independent wins that stack.

Confusing the two is the single most common mistake in green-AI discussions: "our model is low-carbon" could mean low energy (an A/E claim) or ran on clean electricity (a CI claim). They're different claims with different evidence.

---

4. The math

4.1 The equations

   E_it  (kWh)   = P (kW) × t (h)                         # chip energy
   E     (kWh)   = E_it × PUE                             # facility energy
   carbon(gCO2)  = E × CI(t)                              # energy → carbon via grid
   A/E           = accuracy (or value) / E                # useful work per kWh

4.2 Worked example — one training job, two grid hours

A model trains on one A100 (P = 0.4 kW) for t = 2 h, in a data center with PUE = 1.5.

Energy:

   E_it = 0.4 kW × 2 h            = 0.8 kWh   (chip only)
   E    = 0.8 kWh × 1.5 (PUE)     = 1.2 kWh   (facility total)

Carbon — same job, run in a clean vs a dirty hour (using the CI values from the grid article):

   clean night  CI = 59.4  →  carbon = 1.2 × 59.4  =  71.3 gCO2
   evening peak CI = 350.4 →  carbon = 1.2 × 350.4 = 420.5 gCO2

   Same 1.2 kWh job. ~5.9× more carbon just from WHEN it ran.

A/E — comparing two models fairly:

   Model B buys +1 accuracy point for 3× the energy (1.2 → 3.6 kWh).
   On A/E, Model A wins 76.7 vs 25.8 — about 3× more accuracy per kWh.
   Unless that last +1 point is mission-critical, A is the better engineering choice.

This is the whole point of A/E: raw accuracy said "B wins by 1 point"; A/E said "A delivers ~3× the value per joule." The trade was invisible until you divided by energy.

---

5. Real code

Measure/estimate a task's energy, convert to carbon via CI, and compute an A/E score. Uses a measured GPU wattage if available, else a sane estimate.

"""Measure one AI task's energy -> carbon -> A/E score.

Energy = power x time x PUE.  Carbon = energy x grid CI(t).  A/E = value / energy.
This measures the JOB's footprint. The grid CI comes from the grid-intensity article;
they are DIFFERENT objects that we MULTIPLY together here.
"""
from dataclasses import dataclass
import time


@dataclass
class TaskFootprint:
    energy_kwh: float
    carbon_gco2: float
    ae_score: float          # task value (e.g. accuracy points) per kWh
    ci_used: float           # the grid CI(t) applied
    basis: str = "job-footprint (CCI / A-E); grid CI is a separate object"


def measure_energy_kwh(power_watts: float, runtime_hours: float, pue: float = 1.5) -> float:
    """E = P x t x PUE. power_watts = measured chip draw (nvidia-smi / RAPL)."""
    e_it = (power_watts / 1000.0) * runtime_hours     # kW x h = kWh (chip only)
    return e_it * pue                                  # scale up by facility overhead


def footprint(power_watts: float,
              runtime_hours: float,
              task_value: float,        # e.g. accuracy in %, or tokens served
              ci_gco2_per_kwh: float,   # grid CI(t) AT RUN TIME (from grid article)
              pue: float = 1.5) -> TaskFootprint:
    energy = measure_energy_kwh(power_watts, runtime_hours, pue)
    carbon = energy * ci_gco2_per_kwh                 # THE bridge: energy x CI
    ae = task_value / energy if energy else float("nan")
    return TaskFootprint(energy, carbon, ae, ci_gco2_per_kwh)


if __name__ == "__main__":
    CLEAN_CI, DIRTY_CI = 59.4, 350.4                  # from the grid-intensity article

    # One A100 (400 W) training 2 h, PUE 1.5 -> 1.2 kWh. Same job, two grid hours.
    clean = footprint(400, 2.0, task_value=92, ci_gco2_per_kwh=CLEAN_CI)
    dirty = footprint(400, 2.0, task_value=92, ci_gco2_per_kwh=DIRTY_CI)
    print(f"energy={clean.energy_kwh:.2f} kWh")                 # 1.20 kWh
    print(f"clean-hour carbon={clean.carbon_gco2:.1f} gCO2")    # 71.3
    print(f"dirty-hour carbon={dirty.carbon_gco2:.1f} gCO2")    # 420.5  (~5.9x)

    # Fair model comparison on A/E (accuracy points per kWh).
    model_a = footprint(400, 2.0,  task_value=92, ci_gco2_per_kwh=CLEAN_CI)          # 1.2 kWh
    model_b = footprint(400, 6.0,  task_value=93, ci_gco2_per_kwh=CLEAN_CI)          # 3.6 kWh
    print(f"A/E  model A = {model_a.ae_score:.1f} acc/kWh")     # 76.7
    print(f"A/E  model B = {model_b.ae_score:.1f} acc/kWh")     # 25.8  -> A wins per joule

    # In production, replace the fixed 400 with a real reading, e.g. via CodeCarbon /
    # nvidia-smi, and pass the LIVE grid CI(t) for the hour the job actually runs.

The load-bearing line is carbon = energy * ci_gco2_per_kwh: it is the only place the job's footprint meets the grid's cleanliness. Everything left of it is the job; the ci argument comes from the other article.

---

6. Real-world example

Scenario: an ML team picks between two candidate models for a daily inference service.

The service answers ~1M queries/day. Two models pass accuracy review. Finance and sustainability both weigh in.

   Decision math:
     Model B buys +1.0 accuracy point at +2.4 kWh/day  (3x the energy).
     A/E ranks A ~3x more efficient per accuracy point.

   TWO INDEPENDENT LEVERS the team can pull, and they STACK:
     1) EFFICIENCY (this article): pick Model A -> energy 3.6 -> 1.2 kWh  (-67%)
     2) TIMING (grid article): schedule the run in the clean window
                               CI 350.4 -> 59.4  (-83% on the carbon side)

   Combined: Model B in the dirty hour = 1,261.4 gCO2/day
             Model A in the clean hour =    71.3 gCO2/day   -> ~18x less carbon
   Over a year: (1,261.4 - 71.3) g x 365 = ~434 kgCO2 saved on ONE service.

The lesson interviewers want: efficiency and timing are separate wins that multiply. A/E tells you to pick the lean model (smaller E); the grid CI tells you to run it in a clean hour (smaller CI). Do both.

---

7. Interview questions companies actually ask

Q1 [easy] (Hugging Face, Google) "How do you compute the energy of a compute task?"
  A E = power x time, then x PUE for facility overhead. Measure chip watts (nvidia-smi for GPU,
    RAPL for CPU) x runtime in hours -> chip kWh; multiply by PUE (~1.5 typical) for total kWh.

Q2 [easy] (Microsoft, Meta) "What is PUE and why does it matter?"
  A Power Usage Effectiveness = total facility energy / IT energy. It captures cooling and
    conversion overhead. PUE 1.5 means a third of the power never reaches a chip. It scales
    your carbon accordingly, so you can't ignore it.

Q3 [medium] (Hugging Face, research labs) "What is the A/E metric and why not just report
   accuracy?"
  A A/E = task value (e.g. accuracy) per unit energy. Raw accuracy hides cost: a model +1%
    more accurate but 3x the energy is usually worse engineering. A/E makes 'accuracy per
    joule' explicit so you compare models fairly. (Cf. the CCI work, DOI 10.3390/en19030642.)

Q4 [medium] (all green-AI teams) "How do you turn a task's energy into carbon?"
  A carbon = energy(kWh) x CI(t)(gCO2/kWh), where CI is the grid's carbon intensity when the
    job runs. Same job, different hour -> up to ~6x different carbon because CI swings.

Q5 [hard] (Google, Anthropic-style infra) "A colleague says 'our model is low-carbon.' What do
   you ask?"
  A Which claim: low ENERGY (an A/E property of the model+hardware) or ran on CLEAN
    electricity (a grid-CI property of when/where)? They're different objects. Real carbon =
    energy x CI, so you need both. 'Low-carbon' is ambiguous until you separate the job's
    footprint from the grid's cleanliness.

Q6 [hard] (climate-tech, data-center teams) "How do efficiency and carbon-aware scheduling
   relate — is one enough?"
  A They're independent, multiplicative levers. Efficiency shrinks E (smaller model,
    quantization, better hardware). Scheduling shrinks CI (run in a clean hour). Neither
    alone is enough: a lean model in a dirty hour or a bloated model in a clean hour both
    leave savings on the table. Do both; the savings stack (~18x in the worked example).

Q7 [medium] (Hugging Face) "How do you actually measure GPU/CPU energy in code?"
  A GPU: nvidia-smi power draw (or NVML). CPU/DRAM: Intel RAPL counters. Wrap both with
    CodeCarbon or Zeus, which also fetch a grid CI to output gCO2 directly. Prefer measured
    watts over TDP nameplate numbers, which overstate real draw.

Q8 [medium] (research roles) "Why measure the JOB's footprint separately from grid intensity?"
  A Because they answer different questions and have different owners. The job's footprint (CCI
    / A-E) is a property of your model, hardware, and runtime — you improve it by engineering.
    Grid CI is a property of the electricity supply — you exploit it by timing. Measuring them
    separately lets you attribute savings correctly and optimize each independently.

---

8. When to use / tradeoffs

   USE energy/carbon + A/E measurement when:
     ✓ comparing models/hardware fairly (accuracy-per-joule, not just accuracy)
     ✓ reporting a task's footprint, or setting an efficiency budget
     ✓ feeding carbon = E x CI into carbon-aware scheduling

   HONEST LIMITS:
     ✗ Measuring E is noisy: shared GPUs, idle draw, and TDP-vs-actual gaps mislead.
       Prefer live meters (nvidia-smi/RAPL/CodeCarbon) over nameplate TDP.
     ✗ PUE varies by site, season, and load — a single constant is an approximation.
     ✗ A/E depends on your VALUE metric; a bad value proxy makes a bad ratio. Pick a metric
       that reflects real task usefulness, not a vanity number.
     ✗ A/E is for FIXED energy; it does NOT capture the grid's timing win — you still need CI
       to get real carbon (this is the whole 'different objects' point).
     ✗ Embodied carbon of the hardware itself (chip manufacturing) is NOT in E x CI; for full
       lifecycle you'd add it separately.

   DON'T conflate: 'efficient model' (low E, an A/E claim) is NOT 'ran clean' (low CI, a grid
   claim). Keep the two claims — and their evidence — separate.

---

9. Summary + related articles

• A task's energy: E = power × time × PUE — measure chip watts, add facility overhead.
• Its carbon: carbon = E × CI(t) — the bridge to the grid's hourly cleanliness.
• The A/E metric = value (accuracy) per kWh → compares models fairly; a +1% model at 3× energy usually loses (worked: 76.7 vs 25.8 acc/kWh).
• Critical distinction: this article measures the JOB's own footprint (CCI / A-E, like a car's fuel-per-trip); the grid article measures the electricity's cleanliness (like knowing when to drive). Different objects.
• They are complementary: multiply them for real carbon, and compose them by scheduling the job into a clean window.
• Efficiency (smaller E) and timing (smaller CI) are independent levers that stack (~20× in the example).
• Lab context: the published CCI work (DOI 10.3390/en19030642).

Related: Why Grid Carbon Intensity Varies Hour to Hour · Emission Factors & Carbon Accounting · Carbon-Aware Scheduling of Flexible Loads

Resources

• "Carbon Cost of Intelligence" (CCI) — DOI 10.3390/en19030642 — https://doi.org/10.3390/en19030642
• CodeCarbon (measure ML energy & carbon) — https://codecarbon.io/
• Zeus (GPU energy measurement) — https://ml.energy/zeus/
• NVIDIA nvidia-smi / NVML power telemetry — https://developer.nvidia.com/nvidia-management-library-nvml
• Intel RAPL (CPU/DRAM energy) — https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/running-average-power-limit-energy-reporting.html
• Uptime Institute on PUE — https://uptimeinstitute.com/