Skip to content

Energy and carbon methodology

This page is the reference specification for how Venturi derives the energy and carbon figures it attributes to each AI invocation it can resolve. It expands the customer-facing overview in Energy & carbon with the exact formulas, constants, and provenance behind each number.

Venturi’s scope is operational inference energy: the energy a model burns answering a request. Training energy and embodied (manufacturing) energy are out of scope and appear here only as labeled historical context, never folded into a per-request figure.

Two principles govern everything below:

  • Null, never zero. Any unknown term yields a null result, never a fabricated 0. A zero would falsely imply no energy was consumed.
  • Energy is never restated as cost. Energy and carbon are sustainability context. Cost comes from the billing and pricing path and is reported separately. The two are never multiplied into one another.

The derivation tier ladder (T0 to T4)

Venturi runs a tiered derivation engine. Every output row records a derivation_method, a confidence level, and a provenance string, so you can always tell how a number was produced and how much to trust it. The engine walks the ladder highest-trust first and stops at the first tier it can satisfy.

Each tier has a descriptive name and a machine-readable derivation_method value, mapped below. T1 uses an AI Energy Score coefficient; T2 and T3 are estimates.

Tier and name Output Used when
T0 · Instrumented GPU, CPU and RAM energy from CodeCarbon, with measured or estimated provenance for each component Self-hosted inference with CodeCarbon hardware instrumentation
T1 · AI Energy Score Task-specific GPU Wh/query, retaining the benchmark’s source unit and evaluated checkpoint Matching AI Energy Score result available
T2 · Infra-aware Wh/query for a stated prompt fixture: latency + throughput × utilization × PUE Published model performance data; no AI Energy Score result
T3 · Class analogue Nearest coefficient borrowed for the same class and task New model: parameter count known; no performance data
T4 · Unestimated null No data available

Exact machine-readable methods for those same tiers:

Tier derivation_method
T0 measured_full_system
T1 aes_measured
T2 howhungry_infra_aware
T3 class_analogue
T4 unestimated

Measured coefficients take precedence when a matching result is available. The current public catalog, 2026-06-13.ap2, contains two AI Energy Score coefficients, three task-specific Power-Hungry Processing measurements, and 25 How Hungry is AI? modeled coefficients; 21 rows have no energy value. Its source-specific derivation_method labels are listed in version history. T0 applies to instrumented self-hosted hardware (see deployment and licenses).

Energy

The stored primitive: watt-hours

Venturi stores an energy coefficient in watt-hours per stated native unit, alongside its measurement kind, workload, scope, and provenance. The measurement kind distinguishes source measurements from modeled estimates. The public catalog also preserves an upstream official_rating and official_rating_cohort when available. A separately calculated relative rating is a presentation over a defined comparison population, not a replacement for the coefficient or its evidence.

The public catalog’s schema 1.1.0 stores energy in energy_wh_per_unit and states its denominator in measurement_unit. Carbon and water, where available, use the same denominator in carbon_g_per_unit and water_ml_per_unit. A projection must use a count of matching workload units:

Text Only
projected_energy_wh = matching_workload_count × energy_wh_per_unit

The populated coefficients in 2026-06-13.ap2 have these source-specific bases:

Source Published basis Catalog basis and scope
AI Energy Score: two measured rows The pinned February 2025 CSV reports kWh per 1,000 task queries Numerically equal to Wh/query; GPU-only, batch 1, H100, with the exact evaluated checkpoint and task retained
How Hungry is AI?: 25 modeled rows Published Table 4 means for short (100 input / 300 output tokens), medium (1,000 / 1,000), and long (10,000 / 1,500) fixtures where available Wh/query; the medium fixture is the primary coefficient, and facility energy already includes PUE
Separate raw benchmark dataset accompanying Power-Hungry Processing: three measured rows kWh per 1,000 inferences for the stated task Numerically equal to Wh/inference; machine energy including CPU, RAM, and idle GPUs, not GPU-only or facility energy

The legacy energy_wh_per_1k_output_tokens field is null on every row. Do not read it as a populated Wh/query coefficient, multiply these native-unit values by token counts, or rename an image or task inference into a text-query unit. The 21 unavailable rows retain a legacy per_1k_output_tokens unit label but have no numeric coefficient. Label results scaled from these coefficients as projections under the published workload and accounting scope.

Render-time star bands (20% quintiles)

A derived 1-to-5 quintile rating ranks a comparable population in five equal 20% bands: the highest-energy band receives one star and the lowest receives five. Such a rating must identify its task, size class where applicable, hardware, measurement scope, protocol, and population version.

Keep derived bands distinct from upstream ratings. In 2026-06-13.ap2, the two AI Energy Score rows preserve official_rating = 5 and official_rating_cohort = "AES February 2025"; all other official ratings and all legacy energy_score_rating fields are null. Do not recompute an official source rating from this two-row subset or treat a catalog date as its issue date. Compare ratings only within their stated source or derived cohort.

T1: AI Energy Score coefficient (primary)

The AI Energy Score is a standardized, multi-organization benchmark led by Hugging Face. Its documentation credits contributors from Hugging Face, Salesforce, Neuralwatt, Cohere, Meta, and Carnegie Mellon University. It measures model inference energy on NVIDIA H100 GPUs and publishes a GPU energy value and a 1-to-5 rating per model and task. The public catalog contains two measurements from the pinned February 2025 leaderboard at commit c37e01add3d7f295f4bd2a8af0293edc6bf25fb2. The later AI Energy Score v2 release is background about the benchmark, not the cohort of these two rows.

The pinned CSV’s energy unit is kWh per 1,000 task queries, which is numerically equal to Wh per query. The catalog preserves GPU-only scope, the exact benchmark_model_id, task, protocol, source citation, and source cohort. Read each source’s unit before converting; a Wh-per-1,000 presentation would require a different numerical conversion.

The following benchmark run-configuration reference describes the published AES protocol; the public catalog stores its aggregate result and protocol reference rather than a verbatim copy of every run-configuration field:

Run-config field Value
Batch size 1
Dataset size 1,000 queries per task
Runs averaged 10
Hardware NVIDIA H100 80 GB; one GPU for Class A and Class B models, several H100 GPUs for Class C models
Numeric precision FP16 for text generation; FP32 for every other task

Batch-1 coefficients are not throughput-representative

Benchmark coefficients are measured at batch size 1. Production serving batches and caches aggressively, so per-invocation estimates derived from these coefficients are comparable rankings and estimates, never forecasts of your production serving efficiency.

Public schema 1.1.0 stores the published aggregate coefficient, not separate preprocess, prefill, and decode measurements. Use the pinned source and protocol to interpret the aggregate; upstream phase-level schemas are a different data representation.

The ingestion contract accepts both preprocess/prefill/decode records and legacy forward/per_token records; these upstream representations remain distinct from the public aggregate schema.

Hardware comparability

Coefficients measured on non-H100 hardware (for example A100 or TPU) are flagged as not AI Energy Score comparable and are segregated in the catalog, because the rating’s relative bands are only meaningful within the same measurement hardware.

The reasoning premium

Reasoning (“thinking”) modes consume far more energy than standard generation for the same model, because they emit far more output tokens. AI Energy Score v2 (published December 4, 2025) reports:

  • Reasoning models use, on average, about 30× the energy of models without reasoning (or with reasoning turned off).
  • Turning reasoning on versus off for the same model spans 150× to 700×.

Venturi treats reasoning as a first-class engine factor so that reasoning invocations are not silently under-counted. This is also why an energy multiplier must never be read as a cost multiplier: see Energy is not cost.

T2: Infra-aware estimate

The current public catalog’s 25 T2 coefficients are modeled means published in Table 4 of How Hungry is AI?, v6 (November 24, 2025). The catalog preserves each named model, prompt workload, source citation, and available source standard deviation. Its primary coefficient uses the medium fixture. The study’s Equations 1 to 3 explain the modeled energy:

Text Only
base_time_h = (latency_s + output_tokens / throughput_tps) / 3600
energy_wh   = base_time_h × (P_gpu × util_gpu + P_nongpu × util_nongpu) × PUE

P_gpu and P_nongpu are in watts, so the result is Wh. The short, medium, and long fixtures use 300, 1,000, and 1,500 output tokens respectively. The study combines utilization assumptions with performance observations and reports modeled means and uncertainty. The catalog marks these rows measurement_kind = estimated and confidence = medium; its hardware and hosting descriptions record the study’s modeling assumptions. Raw latency_s, tps, and ai_index values are null in this public artifact. Source attribution remains required; see licenses.

Constant Value Source
Node power, DGX H100, H200, or H800 P_gpu = 5,600 W, P_nongpu = 4,600 W (10.20 kW node total) Node total: paper Table 1 (10.20 kW), matching the 10.2 kW maximum in the NVIDIA DGX H100/H200 user guide. P_gpu: eight GPUs at the 700 W maximum TDP of the NVIDIA H100 SXM. P_nongpu: node total minus P_gpu. The paper treats H200 and H800 nodes as having the same power draw as H100 nodes (Section 4.1)
Node power, DGX A100 P_gpu = 3,200 W, P_nongpu = 3,300 W (6.50 kW node total) Node total: paper Table 1 (6.50 kW), from the 6.5 kW maximum in the NVIDIA DGX A100 datasheet. P_gpu: eight GPUs at the 400 W maximum TDP of the NVIDIA A100 80 GB SXM. P_nongpu: node total minus P_gpu
Per-request utilization util_gpu = G × D_gpu / (N × B) and util_nongpu = G × D_nongpu / (N × B), with G GPUs assigned, N = 8 GPUs per node, B = 8 requests per batch, D_gpu the assigned GPUs’ draw as a fraction of their maximum, and D_nongpu = 0.5 Paper Section 4.3, Equation 3
Expectation weight E = 0.5 × E_max + 0.5 × E_min Paper Section 4.2, Equation 2
Monte-Carlo sampling 10,000 correlated (latency, throughput) draws; Gaussian copula with ρ = −0.30 Study Section 4.2; the public catalog preserves published source means and available standard deviations
PUE The hosting provider’s value (for example 1.12 for Azure-hosted and 1.14 for AWS-hosted models) Paper Table 1

GPU count scales with the paper’s hardware class, which is based on parameter count. These five classes set the GPU count for T2 only; they are separate from the AI Energy Score size classes A, B, and C (see T3) that group text-generation models for star bands and comparisons. The resulting per-request utilization ranges are those published in Table 2 of the paper:

Hardware class (T2) GPUs (G) util_gpu, H100 util_gpu, A100 util_nongpu
Nano (< 7B parameters) 1 0.55 to 1.00% 1.25 to 1.5% 0.87%
Micro (7B to 20B) 1 0.75 to 1.25% 1.5 to 1.6% 0.87%
Small (20B to 40B) 2 1.70 to 2.50% not used 1.6%
Medium (40B to 70B) 4 3.00 to 4.50% 6.25 to 7% 3.125%
Large (> 70B, or undisclosed flagship models) 8 5.50 to 7.50% 12.5 to 15.0% 6.25%

T3: Class-analogue estimate

For a brand-new model with a known parameter count but no performance data, Venturi uses the AI Energy Score benchmark’s published size classes and cohort heuristic:

Text Only
AES_class_heuristic_GB = (params_billions × bytes_per_param / (32 / quant_bits)) × overhead

The source sets bytes_per_param = 2, quant_bits = 16, and overhead = 1.2. Its published cohorts are Class A (24 GB reference hardware, about 20B parameters), Class B (80 GB, about 66B), and Class C (more than 80 GB). Venturi preserves these source-defined cohorts and official ratings, then borrows the nearest same-class, same-task coefficient. The derived row carries derivation_method = class_analogue and confidence = low.

The upstream heuristic includes both two bytes per parameter and a 32 / 16 divisor. Treat it only as the benchmark’s classification rule. Physical FP16 weight storage uses two bytes per parameter without that additional divisor:

Text Only
weights_GB = params_billions × 2
illustrative_memory_GB = weights_GB × 1.2

Here GB means decimal gigabytes. A 20B-parameter model has 40 GB of FP16 weights, or 48 GB with an assumed 20% overhead; the upstream cohort heuristic returns 24 GB. Actual serving memory also depends on KV cache, activations, batch size, and framework overhead. Use workload-specific sizing for deployment; retain the published cohort for benchmark comparisons.

T0: Instrumented component energy (self-hosted)

Venturi ingests CodeCarbon’s emissions.csv, BoAmps JSON, or Prometheus metrics for GPU, CPU, and RAM. The existing measured_full_system method identifier does not establish that every component was metered.

CodeCarbon’s methodology distinguishes GPU device measurements, CPU counters or fallback estimates, and RAM estimates. T0 retains each component’s measured or estimated provenance, CPU backend, RAM method, and tracking mode. Process-mode CPU and RAM allocation is estimated; GPU energy remains device-level even in process mode. Fully metered wording requires measurement evidence for every component claimed.

power_kw = Δenergy_kwh / Δhours gives average power over the interval; an estimated input remains estimated after this calculation. Device-level GPU energy cannot identify one tenant’s share on shared hardware. Retain that boundary when comparing T0 with per-request AI Energy Score coefficients.

Carbon

For a modeled carbon calculation with a compatible energy boundary and known grid intensity:

Text Only
carbon_gco2e = C × E

E is energy in kWh and C is grid intensity in gCO2e/kWh. In the 25 How Hungry is AI? rows, energy already includes facility PUE; the catalog’s CIF is in kgCO2e/kWh, so energy_wh_per_unit × cif yields grams per native unit. PUE must not be applied again.

Other source scopes remain distinct. The three Power-Hungry Processing rows retain separately source-reported CodeCarbon carbon rather than recomputing it from a replacement grid factor. The two GPU-only AES rows have carbon_g_per_unit = null. Measured energy alone does not establish carbon. The following resolution chain supplies the grid factor for modeled calculations.

The five-step C resolution chain

Venturi resolves the grid carbon intensity C in a fixed order of precedence, so the most specific value available is always used:

  1. An explicit override supplied for the calculation (force_carbon_intensity_g_co2e_kwh).
  2. A live grid-intensity feed (optional Electricity Maps integration; see licenses).
  3. The cloud provider and region (a bundled, versioned table of per-region intensities).
  4. The country ISO code (and sub-region where available), via the generation-mix derivation below.
  5. The world-average fallback of 475 gCO2e/kWh, taken from the current CodeCarbon methodology, which cites the International Energy Agency’s Global Energy & CO2 Status Report 2019 as its source. The value is always flagged as estimated, never a silent value.

A region you configure resolves higher up the chain and is materially more accurate than the fallback. Every row records which step resolved C.

Generation-mix derivation and the fuel-factor table

Where carbon is derived from a country’s generation mix:

Text Only
C = Σ (fraction_fuel × emission_factor_fuel)

The per-fuel emission factors (g/kWh, equivalently kg/MWh) are the table published in the CodeCarbon methodology, which sources the fossil-fuel factors from the open-source energy-usage project and the low-carbon factors from the World Nuclear Association’s comparison of lifecycle greenhouse-gas emissions. Venturi stores them as versioned constants; the source and table version travel with the catalog row, and a provider or customer-supplied factor always takes precedence:

Fuel Emission factor (gCO2e/kWh)
Coal 995
Petroleum / oil 816
Natural gas 743
Solar 48
Geothermal 38
Nuclear 29
Hydro 26
Wind 26

Worked example for a mix of 25% coal, 35% oil, 26% gas, 14% nuclear:

Text Only
C = 0.25×995 + 0.35×816 + 0.26×743 + 0.14×29 ≈ 731.6 gCO2e/kWh

Fuel fractions are normalized to sum to 1 before the factors are applied. A fuel whose fraction or factor is unknown is excluded and the row is flagged as partial coverage; it is never counted as 0.

PUE is applied once, in the energy term

Power Usage Effectiveness (PUE) accounts for datacenter overhead beyond the IT load. In the public catalog, How Hungry is AI? energy already includes PUE, so its carbon and water calculations must not apply PUE a second time. AES coefficients remain GPU-only, with PUE, carbon, and water null. The Power-Hungry Processing rows retain machine scope; their stored pue = 1 does not turn them into facility measurements. Any separate facility gross-up must be labeled as an estimate with its own assumptions and must preserve the original coefficient and scope.

The tenant facility-estimation contract applies PUE once when total energy is formed, never reapplies it in the carbon calculation, and requires a verification gate against double application.

Uncertainty propagation

Every figure carries its uncertainty from the tier that produced it:

  • T2 rows preserve the source’s modeled mean and available standard deviation. In 2026-06-13.ap2, 24 of 25 primary T2 coefficients have energy_std_wh. GPT-4.1’s medium source prints 3.161 ± 0515; the intended decimal is unresolved, so its standard deviation is null rather than an inferred 0.515.
  • T1 rows retain the published aggregate. A standard deviation is recorded only when available from the selected source; both public AES rows have energy_std_wh = null, never an invented zero.
  • T3 rows borrow the analogue row’s coefficient. The analogue’s spread describes the analogue model, not how far the new model can differ from it, so T3 rows are labeled confidence = low.
  • T0 rows preserve per-component measurement or estimation provenance and any available uncertainty, including allocation assumptions and device scope. Missing uncertainty remains unknown.

For the modeled rows whose carbon and water are derived using fixed factors, uncertainty propagates as σ_carbon = C × σ_E and σ_water = (WUE_site / PUE + WUE_source) × σ_E, using consistent units. These equations do not create a missing source standard deviation or replace separately source-reported carbon. Every tenant carbon export carries five uncertainty and methodology fields, carbon_method_id, confidence, factor_source, allocation_basis, and freshness, both in the API response and as columns in the CSV. The eco-efficiency score is a relative ranking with no standard deviation of its own (see eco-efficiency methodology). A missing input is never replaced with 0.

Reconciling the boundaries

The public coefficients preserve their source boundaries:

Source family Boundary Basis
AI Energy Score GPU only Measured task coefficient, batch 1, H100
Power-Hungry Processing Machine including CPU, RAM, and idle GPUs Measured task coefficient on an eight-GPU A100 node
How Hungry is AI? Facility including PUE Modeled result for the stated prompt fixture and study assumptions
Instrumented CodeCarbon (T0) The instrumented devices Measured and estimated components with their provenance and device scope retained

The current public catalog does not gross up its AES values into facility measurements. Their PUE, carbon, and water fields remain null. Any additional facility estimate must identify its added CPU/RAM and other overhead, PUE, workload, and uncertainty while retaining the original source coefficient. For example, E_full_system = (E_gpu + 0.30 × E_gpu) × PUE is a facility estimate that adds modeled CPU/RAM overhead and PUE to the measured GPU coefficient. A chosen 0.30 overhead or default PUE of 1.1 must be labeled as an assumption and must not silently change the source scope. Compatible units alone do not make GPU, machine, and facility coefficients comparable.

For instrumented self-hosted workloads, the T0 contract cross-checks modeled energy against compatible measured components, records the residual, retains component provenance and device scope, and preserves missing terms as null.

Version history of the AI Energy Score

Venturi records the AI Energy Score release history so that older coefficients stay interpretable. Each coefficient stores the release it was measured under:

  • v1 launched in February 2025 with 10 tasks and the 1-to-5 rating.
  • v2, published December 4, 2025, added reasoning as a newly benchmarked task (the 11th) and reported mixed results for newer models: of 14 newer non-reasoning models compared with similar-size models from the February 2025 cohort, 8 used as much energy or more. Efficiency must therefore be measured per release rather than assumed to improve over time.

Both dates are from the AI Energy Score v2 announcement. See version history for how coefficient updates, source corrections, and rating cohorts are distinguished, and licenses for upstream attribution.

Where to go next

Give feedback on this page

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

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