How we calculate.
Status — v0, open beta
The dataset is a curated-in-progress seed; the footer shows the version it is on. If you find an error or a better source, that is the single most useful thing you can send us.
What this is — and is not
- It is a conditional estimator: if this were generated with model X, on hardware Y, on grid Z, the footprint would be roughly this range.
- It is not an AI-detection tool. We never claim a given file was made by AI, or by a particular model. The framing is always hypothetical.
- It estimates inference only — the cost of generating the content — not the cost of training the model or building the hardware.
Why ranges, never points
Published measurements disagree by large factors. Bertazzini et al. (2025) found up to a 46× spread between image models, and step count, precision and resolution move each model’s own figure again. Reporting a single number would be false precision. So every metric is published as low / mid / high:
- Single named model. The band is the spread reported in the source measurements across realistic production settings.
midis the representative setting;lowandhighare the ends of that plausible operating range. - “Not sure — show me the class range.” When the model is unknown we span every model of that modality in the dataset:
lowis the minimum,highthe maximum, andmidthe median of the per-model central values. A class range is never labelled better than modeled.
System boundary
✓ Counted
- GPU inference energy to generate the content, from the cited measurement or scaling-law estimate.
- Grid carbon — that energy converted to CO₂e at a regional grid intensity (gCO₂e/kWh).
- Water — that energy converted to litres via a water-per-kWh factor, on-site cooling plus off-site generation.
✕ Not counted
- Data-centre overhead (PUE). Figures are accelerator energy as measured; no PUE multiplier is added. Real facility energy is typically ~1.1–1.3× higher.
- Model training and fine-tuning, amortised across inferences.
- Embodied carbon of the GPUs and the building.
- Network delivery and end-user device energy.
Which way this biases the number
Everything in the right-hand column would push the total up. Our figures therefore sit at the conservative end of true deployed cost — when this tool is wrong, it is more likely to be wrong low than high.
Hardware and batch-size assumptions
Per-model assumptions live in the dataset, on each entry's hardwareAssumption field. The default reference is an A100-80GB, batch 1, at the precision the source reports (typically fp16/fp8).
Batch 1 is the conservative choice for a per-item estimate: batched serving amortises fixed per-step overhead and generally lowers per-image energy, so production systems running large batches may sit below our mid. The band is wide enough that typical batched serving still falls inside it.
Confidence tiers
Every estimate carries one of three tiers, and the tier decides how the bar is drawn — so a measurement and an estimate can never look alike at a glance.
- Measured
A public benchmark on known hardware — the Hugging Face AI Energy Score leaderboard, ML.ENERGY, or a peer-reviewed measurement such as Iyengar et al. (2026) for open MMDiT diffusion models.
- Modeled
Derived from published measurements of a comparable system — FLUX.2 anchored to its measured FLUX.1 sibling, for instance — or any unknown-model class range.
- Speculative
Closed or proprietary models: Midjourney, GPT-Image, Kling, Runway, Seedance and similar. These cannot be measured — the weights and the serving stack are not public. Their bands are FLOPs→energy scaling-law estimates transferred from open models, plus third-party analyses. They are always drawn and labelled as estimates, never with the visual weight of a measurement.
By a dataset rule enforced in CI, a closed-weight model can never be tagged measured. That is a build failure, not a guideline.
Resolution and duration scaling
Energy is not scaled by a single global multiplier. It scales per model.
- Resolution. Energy scales with the linear resolution ratio raised to a per-model
resolutionExponent, where the linear ratio is √(pixel ratio) so square image presets and video presets share one convention. Exponents come from Bertazzini et al. (2025), Table 2 — 512²→1024²: SD3 ×1.92, FLUX ×1.50, SDXL ×2.88. - Video duration. Video energy scales with output seconds and, above a linear baseline, super-linearly with clip length via a per-model
durationExponent(video defaults to quadratic), calibrated so a clip at the model's reference duration matches its per-second rate. Sources: Delavande, Pierrard & Luccioni (2025); Jegham, Gamazaychikov & Luccioni (2026).
Grid carbon intensity
Carbon = energy (kWh) × regional grid intensity (gCO₂e/kWh). Intensities come from the Ember yearly electricity dataset as regional averages, with the world average as the default. A live Electricity Maps feed is the planned v2 upgrade.
Changing region moves the carbon number, not the energy.
Water
The weakest data in the product
The water bands are intentionally the widest thing here, because we genuinely cannot pin this down yet.
Water = energy (kWh) × water-per-kWh, based on Li et al. (2023), Making AI Less Thirsty, covering on-site data-centre cooling plus off-site water used to generate the electricity.
Two honest limitations today:
- We apply a single global water-per-kWh band (roughly 0.2 / 1.8 / 4.0 L per kWh). It does not vary by region — so changing the grid region moves carbon but not water.
- Real water intensity varies enormously by location, cooling design and season. Regionalised water intensity is a priority for a future version.
Dataset versioning
The dataset version is shown in the footer. Every model entry carries sources (at least one, enforced in CI), hardwareAssumption, confidence and lastReviewed. Ranges are validated (low ≤ mid ≤ high) and closed models are blocked from a measured tag. Entries are re-checked as sources improve.
Found a problem?
This is an open beta and the numbers will move. If you have a better measurement, a source we missed, or a hardware assumption you would challenge, send it over — corrections with a citation are exactly what moves the dataset out of seed status.
aicontentfootprint [at] origo dot ec
For why this exists at all, read why we built it.