7. Assessment and Calculation

7.1 Physical Benchmarking

Physical benchmarking obtains empirical server-level energy measurements during AI inference across a representative range of models and workload conditions. The open-weights LLMs selected per Section 6 are run on GPU hardware through a production-standard continuous-batching inference engine, using standardised prompts drawn from 14 public benchmark datasets that cover enterprise use cases such as instruction following, reasoning, general and expert knowledge, coding, classification, summarisation, text generation, and reading comprehension. Luccioni et al. document that inference energy varies with task type and modalities. Greenpixie's benchmarking covers text tasks, and the benchmark set spans the categories above. Prompts of up to approximately 14,000 tokens are tested, responses are permitted up to 8,192 tokens, and the number of parallel requests ranges from 16 to 2,048.

GPU-board power is sampled via timestamped NVML readings and integrated over each phase to derive the GPU energy consumed. Non-GPU server energy, covering processors, memory, network interfaces, fans, and power supply, is not measured directly; it is estimated from the inference-phase wall time and the power specification of the host server, using published hyperscaler AI instance specifications as the reference configuration. The timestamps differentiate three phases, being prefill only, the overlap in which one request's prefill runs in the same forward passes as another request's decode, and decode only, isolating the token counts and energy for each. For every combination of parallel requests, model, quantisation, and GPU configuration, the kWh-per-token value is derived from the phase energy summed across all batches divided by the tokens processed in that phase. The result is a set of empirical kWh-per-token measurements spanning models, quantisation levels, hardware configurations, workload types, and levels of request parallelism.

Energy is attributed on a request-scoped basis. A request accounts for the server runtime it causes, and not for idle power drawn between requests. Where several requests share a batched forward pass, the runtime of that pass is divided between the participating requests in proportion to the lifetime of each. Idle power consumed by an underutilised inference server is not attributed to any customer.

7.2 Predictive Modelling

Predictive modelling generalises the benchmark findings to models that cannot be measured directly, including proprietary models. The benchmark data is first partitioned by deployment configuration, being hardware, quantisation level, and parallelism regime, into subsets that reflect distinct energy consumption profiles. This partitioning accounts for the non-linear relationship between workload conditions and energy consumption, which is documented by Fernandez et al. for the decay of energy per token with batch size and by Stojkovic et al. and Samsi et al. for the effect of prompt and response length. Parallelism regimes are separated for output tokens, where energy per token falls as requests are batched together. They are not separated for input tokens, where the benchmark data to date shows no consistent relationship between parallel requests and energy per input token. Whether a relationship exists below the precision the current benchmarks resolve is open, and the treatment will be revisited if later data shows one.

Repeated measurements of the same model are not independent observations, as they share an architecture, a quantisation level, a KV cache layout, and a tokenizer. Measurements are therefore aggregated per model before fitting, so that each model contributes as a single observation and the resulting confidence intervals are represented correctly.

A regression model is trained on each subset to predict kWh per token and inference wall time from a deliberately minimal set of model characteristics, being the number of parameters active per request and the VRAM footprint occupied by the model weights. Further characteristics are not included, as any additional characteristic would itself have to be approximated for a proprietary model, adding uncertainty to the prediction. The regression is constrained so that a larger or more memory-intensive model cannot be predicted to consume less energy than a smaller one. The specific regression technique, feature specification, partitioning thresholds, and outlier criteria are proprietary. The output is a predicted kWh-per-token value and inference wall time for each model and billing configuration, each carrying a quantified uncertainty.

7.3 Billing Configuration Mapping

Predicted energy values are aligned with the billing structures used by each cloud provider. Each model's values are mapped to the applicable usage types by normalising the model name in the billing line and matching it against a per-provider reference table. The mapping is made on three dimensions, being the token type, covering input, output, and embedding tokens, the processing tier, covering real-time, batched, priority, and flexible, and whether prefix caching applies to the request.

Batched and real-time tiers are assigned different energy values, as they are served at materially different levels of request parallelism. Where prefix caching applies, a scaling factor is applied on the basis that the prefill computation for the cached prefix is not repeated. Where a provider introduces a billing configuration that is not yet mapped, the most closely analogous existing configuration is applied until a specific mapping is established. The result is a lookup of kWh-per-token values indexed by cloud provider, model, token type, and billing configuration.

7.4 Carbon and Embodied Emissions Calculation

This component converts energy values into carbon estimates and accounts for the embodied emissions of inference hardware.

An uplift is applied to the operational energy of inference to account for the energy consumed in training the model, amortising that training cost across the tokens the model serves. A single uplift value is not used. The methodology samples a realistic range of possible training energy values, informed by commonly reported estimates of the split between inference and training compute over a model's operational lifetime, referenced in Section 12. A heavily served model carries a smaller uplift per token than a lightly served one, so the sampled range spans both cases, and it is carried through into the reported uncertainty.

Operational carbon is then calculated by multiplying the uplifted energy consumption, including facility overhead, by the applicable Grid Carbon Intensity (GCI) factor for the region and hour of the request.

Embodied emissions are calculated separately. Cradle-to-gate manufacturing emissions for the inference server hardware are calculated using formulae adapted from Boavizta, amortised over the hardware's assumed operational lifespan, and scaled by the inference wall time attributable to each request. The wall time predictions described in Section 7.2 provide that attribution.

The result is a per-token carbon value, expressed in gCO₂e for each model and billing configuration, comprising operational emissions including the training energy uplift, and amortised cradle-to-gate embodied emissions.

7.5 Water Consumption Calculation

Water consumption for cloud AI inference is estimated from the inference energy values, in two components. The first is IT cooling water consumption, the water consumed on site in cooling the inference hardware, estimated as the cloud provider's published Water Usage Effectiveness (WUE) multiplied by the IT electricity consumed by inference. The second is electricity generation water consumption, the water consumed during the generation of that electricity, estimated as a regional water intensity factor multiplied by Total Facility Energy (TFE). Both components are calculated on a location-based basis and reported separately.

The WUE values are published by the cloud providers, and the regional water intensity factors are adapted from World Resources Institute guidance. The factors applied and their full derivation are set out in the Greenpixie Methodology for Cloud Emission Measurement.

The result is a per-token water value, expressed in litres for each model and billing configuration, comprising IT cooling and electricity generation water consumption.

7.6 Uncertainty Quantification

The characteristics of the deployment serving a cloud AI billing line are not observable from that line. The hardware in use, the deployed quantisation level, the level of request parallelism, and the proportion of parameters active per request are not disclosed by the provider and are not present in cloud usage data.

Where these characteristics cannot be observed, the methodology treats each as a range and samples across those ranges, producing a distribution of possible per-token values from which a median and an interquartile range (IQR) are taken. The forms of the input ranges are themselves treated as assumptions and are varied across the sampling, so that the reported IQR reflects the movement of the result across differing reasonable assumptions. Samples describing a physically or commercially implausible deployment are rejected. The specifications of the input ranges and the sampling process are proprietary. The movement of the result across those ranges is the systematic uncertainty.

The reported statistical uncertainty comprises two components:

• Aleatoric uncertainty. The inherent variation between comparable workloads. This component does not reduce as the predictive models improve, but it averages out as values are aggregated across billing line items.
• Epistemic uncertainty. The uncertainty in the predictive models themselves, arising from the density of benchmark coverage in the region being predicted. This component reduces as further models are benchmarked, and is largest for the largest models, where measured reference points are sparsest.

Where a customer provides information about a deployment, such as confirmation that a workload runs on a batched processing tier, the corresponding input range narrows and the reported IQR reduces accordingly.