Skip to main content
Every completion served through the LLM Gateway is scored for its environmental impact: the energy it consumed (kWh) and the greenhouse-gas emissions it produced (kg CO₂eq). The estimate is attached to each call and aggregated in Observability (the Carbon headline card). The method is inspired by the EcoLogits methodology: a per-token energy model, scaled by datacenter efficiency (PUE) and converted to CO₂ with a region-specific grid emission factor, reported with an uncertainty range. It is a parametric estimate, not a measurement — its accuracy depends entirely on the metrics declared on each model.

Where the inputs come from

The estimate is driven by three fields you declare per model, in the Metrics section of the model declaration form (Governe → Models → Add/Edit model → Advanced):
Model declaration — Metrics section (Energy/Token, PUE Profile, Eco Score)
Prisme.ai publishes recommended values for these fields per model in its reference catalogue, and can apply them to your models in bulk.
Unit matters. Energy/Token is expressed in kWh per token (e.g. 0.0000103 kWh/token ≈ 10.3 mWh/token). Entering a value in Wh/token would make the reported footprint 1000× too high. The field is not unit-suffixed in the UI, so declare it in kWh/token.

Calculation

For a call with in input tokens and out output tokens, and a model whose declared energy per token is ept:

1. GPU energy

Input tokens (encoding) are counted at ~33% of an output token’s energy:

2. Server overhead

A fixed server draw of 0.1 kW over an estimated 0.02 s of processing per token:

3. Datacenter efficiency (PUE)

The raw energy is scaled by the Power Usage Effectiveness of the datacenter:

4. CO₂eq emissions

The energy is converted with the grid emission factor of the region the model runs in:

Setting the region

The region only sets the emission factor above; it has no effect on routing. By default a model takes it from the provider entry that serves it, resolved at every call, so moving a model to another provider entry or region updates its footprint immediately:
  • a provider entry can declare its region in Govern → Providers (carbon_region) — set it for providers without a region of their own (OpenAI, Azure OpenAI, Anthropic, OpenAI-compatible);
  • otherwise, for AWS Bedrock:
    • a cross-region inference profile (model id starting with global., eu., us., us-gov., apac., jp., au.) can run in any region of its geography, whatever the entry’s region: global. → world, eu. → eu-west, us. and us-gov. → us-east, apac., jp. and au. → asia. The prefix is read on the id actually sent to AWS, so a model declared under an alias (model_aliases) follows its target;
    • any other model id uses the entry’s AWS region: eu-north-* → eu-north; any other eu-* → eu-west; us-east-* and ca-* → us-east; us-west-* → us-west; ap-* → asia; anything else → world;
  • for Vertex AI, the location of the entry’s host (europe-west9-aiplatform.googleapis.com → europe-west9; no prefix means global): europe-north1 / europe-north2 → eu-north; any other europe-* → eu-west; us-west* → us-west; us-central1, us-east*, us-south1 and northamerica-* → us-east; asia-* and australia-* → asia; global and anything else → world;
  • with nothing from the provider, the region is world.
The Region field of a model shows this as From the provider (…), its default. Pick a region there only for a model that runs elsewhere: it then overrides the provider for that model. When a region is selected, the form tells whether it differs from the provider or is the same (and can then be removed with Use the provider). A region set on a model by an earlier version keeps working as an override; a value that is not one of the six regions is ignored. Run Update from catalogue (⋮ menu of Govern → Models) to clear, in one go, the stored regions that are identical to the provider’s (dry run first). Through the API, region on POST /v1/models and PATCH /v1/models/{model_id} is optional: null or absent means “from the provider”, one of the six ids is an override, and any other value is refused with 400 INVALID_REGION. GET /v1/models/regions?model_id=… returns the six regions, the default (world) and what the provider gives that model (suggested, source).

5. Uncertainty range

Both energy and emissions are reported with a ±20% band (min = value × 0.8, max = value × 1.2).

Condensed formula

Worked example

A short call of 51 input + 18 output tokens on a model declared at ept = 0.0000103 kWh/token, average PUE, us-west:
  • gpu_energy = (51 × 0.0000103 × 0.33) + (18 × 0.0000103) ≈ 0.000359 kWh
  • server_energy = 0.1 × (69 × 0.02) / 3600 ≈ 0.0000038 kWh
  • total_energy = (0.000359 + 0.0000038) × 1.58 ≈ 0.000573 kWh
  • gwp = 0.000573 × 0.352 ≈ 0.0002 kg CO₂eq (~0.2 g CO₂eq)

Result shape

Each call returns:
The constants (0.33 input factor, 0.1 kW server draw, 0.02 s/token, PUE multipliers and regional emission factors, ±20% band) are fixed in the gateway. Only energy_per_token and pue_profile are per-model, plus the optional region override; the region otherwise comes from the provider entry. A model with no energy_per_token reports pricing only and no footprint.
details.region_source tells which rule picked the region: model (the model’s override), provider (the provider entry’s carbon region), bedrock-profile:<prefix> (a Bedrock cross-region profile such as eu.), bedrock:<AWS region>, vertex:<location>, or default (world). The same object is returned in usage.carbon of the chat completion and sent with the analytics.llm.completion event (carbon), so you can check which region each call was counted in.