7. Assessment and Calculation
The calculation components and their outputs.
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-source LLMs selected per Section 6 are run on GPU hardware through an inference engine, using standardised prompts that cover enterprise use cases such as instruction following, reasoning, general and expert knowledge, coding, classification, summarisation, text generation, and reading comprehension. Prompts of up to 4,096 tokens are tested, with parallelism ranging from 8 to 2,048 simultaneous requests.
GPU-board power is sampled via timestamped NVML readings and integrated over each phase to derive the GPU energy consumed. Non-GPU server energy is not measured directly; it is estimated from the inference-phase wall time using standard server-power assumptions. The timestamps differentiate the prefill and decode phases, isolating the token counts and energy for each. For every combination of batch size, model, and GPU configuration, the kWh-per-token value is averaged across all batches and requests to produce a representative energy profile. The result is a set of empirical kWh-per-token measurements spanning models, quantisation levels, hardware configurations, workload types, and parallelism levels.
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 segmented by workload characteristics, with defined thresholds on dimensions such as parallelism level, prompt length, and response length partitioning it into subsets that reflect distinct energy consumption profiles. This segmentation accounts for the non-linear relationship between workload conditions and energy consumption.
A regression model is trained on each subset to predict kWh per token from model and infrastructure characteristics, including active parameter count, GPU memory footprint, inference phase, prompt length, response length, and parallelism level. The specific regression technique, feature selection, and segmentation thresholds are proprietary. The output is a predicted kWh-per-token value for each model and billing configuration.
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, drawing on provider pricing structures, the distinctions between input, output, and cached tokens, prompt-length tier boundaries, and batch versus real-time processing. Where a provider distinguishes prompt-length tiers, separate energy values are assigned, and where prefix caching applies, a scaling factor derived from the observed price ratio between cached and non-cached tokens is used. 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
The final component converts energy values into carbon estimates and accounts for the embodied emissions of inference hardware. Operational carbon is calculated by multiplying energy consumption by the applicable regional carbon intensity factor. Embodied emissions for the server hardware are calculated using formulae adapted from Boavizta and amortised over the hardware's assumed operational lifespan, using the wall-time measurements from benchmarking.
An uplift factor is applied to the amortised embodied emissions to account for the energy consumed during model training. This uplift is derived from published estimates of the ratio of training to inference energy over a model's operational lifetime, referenced in Section 12. The methodology does not model usage-phase emissions per training token; training energy is included as a proportional addition to the embodied emissions allocation.
The result is a per-token carbon value, expressed in gCO₂e for each model and billing configuration, comprising operational emissions, amortised embodied emissions, and the training energy uplift.
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 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. Both components are calculated on a location-based basis and reported separately. The water factors and their sources 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.