Skip to content

Energy and carbon attribution

Availability: roadmap extension. This guide specifies the target tenant calculation workflow. The public factor catalog remains reference material; its publication does not establish enabled tenant accounting. Confirm your implementation scope and verification evidence before using tenant estimates. See Sustainability.

The attribution engine does more than tell you who and how much; it also estimates how much energy each AI invocation consumed and how much carbon it emitted. Energy and carbon are attributed across the same attribution graph as cost, so you can see per-team, per-model, and per-cost-center energy and emissions alongside spend.

Methodology and scope

Energy and carbon estimates provide sustainability context; they are not carbon-accounting or compliance outputs. Unknown terms return null, never zero, and energy is never restated as cost. See the energy methodology for every formula and constant.

This page explains how those estimates are produced, where they come from, and how Venturi discloses what it does not know.

What Venturi estimates

For each AI request the engine observes, it attaches an energy and carbon block to the invocation:

Estimate What it is
Estimated energy (kWh) A workload estimate using a compatible coefficient and its stated scope. Preserve GPU-only, machine, and facility boundaries; any modeled facility overhead must be explicit and PUE applied once.
Model Energy Rating (1 to 5 stars) An available rating interpreted within its stated source or derived comparison cohort, task, hardware, and protocol.
Estimated carbon (gCO2e) An available source carbon coefficient or a separately modeled value using compatible energy and an explicit grid-intensity assumption. Known energy alone does not establish carbon.

These flow into your dashboards, your FOCUS exports, and the optimization recommendations Venturi makes.

How energy is estimated

An energy estimate requires a compatible workload count, exact model identity, and source coefficient. Public schema 1.1.0 stores energy_wh_per_unit with measurement_unit; the legacy energy_wh_per_1k_output_tokens field is null on every row. Do not multiply a Wh/query or Wh/inference coefficient by output-token counts.

The active public catalog, 2026-06-13.ap2, contains three populated source families:

  • 25 modeled How-Hungry coefficients: published Table 4 means for the stated prompt fixtures, with the medium fixture as the primary Wh/query coefficient. They already include facility PUE. Hardware and hosting describe the study’s modeling assumptions.
  • Two measured AI Energy Score coefficients: pinned February 2025 leaderboard aggregates for the exact evaluated checkpoints and tasks. The source CSV reports kWh per 1,000 queries, numerically equal to Wh/query. These values are GPU-only, measured under the H100 batch-one protocol.
  • Three measured Power-Hungry raw-dataset coefficients: Wh/inference for the exact stated tasks, measured on an eight-GPU A100 node. They include machine energy, CPU, RAM, and idle GPUs, and are not GPU-only AES or facility measurements.

Each row records its measurement_kind, energy_scope, workload, protocol, benchmark_model_id, source date, citations, and provenance. A stable catalog route can be an alias; use the exact benchmark identity for interpretation. These coefficients support projections under their source assumptions, not claims about a customer’s measured production efficiency. In particular, batch-one AES results do not represent production batching and caching. See methodology for the source protocol and limits.

How carbon is estimated

Carbon remains null unless the selected source supplies a compatible carbon coefficient or a separate calculation has the required energy boundary and grid intensity. For a modeled calculation:

Text Only
estimated_carbon_gco2e = estimated_energy_kwh × grid_carbon_intensity

Grid intensity is in gCO2e/kWh. The 25 How-Hungry rows already include PUE in their facility-energy values, so it must not be applied again. The three Power-Hungry rows retain separately source-reported CodeCarbon carbon rather than recomputing it from a replacement grid factor. Both GPU-only AES rows have energy but null carbon and water. The grid-factor chain below describes a modeled calculation, not the provenance of every public source row.

Venturi resolves the grid carbon intensity in a fixed 5-step order of precedence, the same chain the energy methodology defines, so the most specific value available is always used:

  1. An explicit override supplied for the calculation.
  2. A live grid-intensity feed, through the optional Electricity Maps integration that uses a feed you license.
  3. The cloud provider and region (a bundled, versioned table of per-region intensities).
  4. The country ISO code, via the generation-mix derivation.
  5. The world-average fallback of 475 gCO2e/kWh, the value the CodeCarbon methodology (version 3.2) takes from the International Energy Agency’s Global Energy & CO2 Status Report 2019, which reports the 2018 global average carbon intensity of electricity generation. This fallback is always flagged as estimated, never a silent value.

Set your region for accurate carbon

A value you configure resolves higher up the chain. Configuring your actual deployment region, or supplying a region-specific intensity, makes carbon estimates materially more accurate; configuration changes take effect without a restart.

The null-not-zero rule

A catalog lookup must resolve a usable coefficient with the required native unit, workload, scope, and inputs. Catalog membership alone is insufficient: in the current public catalog, 21 of 51 rows have no energy coefficient, and the two AES rows have energy but no carbon or water.

Null is not zero

If the required coefficient or input is unavailable, preserve null, never zero, whether the model is absent from the catalog or present without a usable value. A known energy coefficient does not imply a known carbon coefficient. The same principle governs attribution confidence: unknown evidence must not be turned into a fabricated number.

Dashboards and exports must keep unavailable estimates and ratings visibly unknown or unrated, not count them as emission-free.

Where you see energy and carbon

Surface What it shows
Dashboards Per-team total energy, per-model efficiency with the catalog’s native workload unit and source scope, and per-cost-center allocation alongside cost.
FOCUS export Energy and carbon columns: estimated energy (kWh), an available Model Energy Rating, and carbon (gCO2e), added to the standard FOCUS export. Each value remains null when its required coefficient, evidence, or input is unavailable, including for models present in the catalog.
Energy budgets Per-team and per-cost-center energy caps (kWh per period), evaluated like cost budgets: Advisory (Shape) alerts by default; under Active (Gate), a signed deny recommendation that your enforcement point applies.
Optimization recommendations Comparisons for the attributed Chargeback-ready (coper >= 0.80) workload retain compatible native units, tasks, workloads, scopes, and protocols. Include source or derived ratings only where available within a comparable cohort, and energy or carbon differentials only where the required evidence exists. Keep modeled projections labeled and preserve the batch-one caveat for AES-based estimates.

Energy is not cost

Never read an energy multiplier as a cost multiplier

Energy efficiency varies enormously between models and modes: the same model can vary by a large factor depending on configuration, and reasoning-enabled operation is far more energy-intensive than standard operation. These figures are energy-transparency context only. Energy is not cost. Never restate an energy multiplier as a cost range: cost comes from the billing and pricing path, energy comes from this engine, and the two are reported separately.

Where to go next

For the full formulas, constants, and provenance behind the numbers above:

And the surrounding engine docs:

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Energy and carbon attribution
Page: https://docs.venturi.systems/engine/energy-and-carbon/