Compute Carbon Intensity (CCI) Metrics

• Compute Carbon Intensity (CCI) is a metric that quantifies greenhouse gas emissions per useful floating-point operation, combining both embodied and operational emissions.
• It employs a detailed life-cycle assessment methodology, integrating manufacturing, energy use, and disposal to quantify complete carbon cost.
• CCI is used to benchmark AI accelerators and guide hardware and data center improvements towards lower carbon footprints.

Compute Carbon Intensity (CCI) is a quantitative metric expressing the greenhouse gas (GHG) emissions per unit of useful computation, most commonly per floating-point operation (FLOP). It provides an end-to-end, hardware- and workload-agnostic quantification of the carbon dioxide-equivalent (CO₂e) impact incurred throughout the computation lifecycle, including both embodied (manufacturing) and operational (runtime) emissions. The explicit unit is grams of CO₂e per FLOP (gCO₂e/FLOP), with lower CCI values indicating higher carbon efficiency per unit of compute performed (Schneider et al., 1 Feb 2025).

1. Formal Definition of Compute Carbon Intensity

Compute Carbon Intensity (CCI) is rigorously defined as the sum of all carbon emissions—both embodied in hardware and generated during computation—divided by the total number of useful floating-point operations executed over the hardware’s operational lifetime:

$$\mathrm{CCI}_{\mathrm{total}} = \frac{E_{\mathrm{emb}} + E_{\mathrm{op}}}{F_{\mathrm{total}}} \quad \left[\frac{\mathrm{gCO}_2\mathrm{e}}{\mathrm{FLOP}}\right]$$

where:

• $E_{\mathrm{emb}}$: Total embodied emissions (kgCO₂e), encompassing all life-cycle stages from material extraction through manufacturing, transport, datacenter construction, and end-of-life.
• $E_{\mathrm{op}}$: Total operational emissions (kgCO₂e), primarily from energy consumption during compute workloads, adjusted by site, hardware, and grid mix.
• $F_{\mathrm{total}}$: Cumulative useful floating-point operations executed over the hardware’s life.

Supplementary metrics include the embodied CCI (emissions per FLOP, manufacturing only) and operational CCI (emissions per FLOP, runtime only):

$$\mathrm{CCI}_{\mathrm{emb}} = \frac{E_{\mathrm{emb}}}{F_{\mathrm{total}}} \quad;\quad \mathrm{CCI}_{\mathrm{op}} = \frac{E_{\mathrm{op}}}{F_{\mathrm{total}}}$$

The denominator is strictly a scalar count of operations, not a rate. CCI offers a physically interpretable, cross-platform, and cross-generation metric for evaluating carbon efficiency (Schneider et al., 1 Feb 2025).

2. Step-by-Step Calculation Procedure

Calculation of CCI involves a comprehensive life-cycle assessment (LCA) paired with high-fidelity workload metering. The methodology, as implemented in detailed studies of AI accelerator fleets (e.g., Google TPUs), proceeds via:

1. Defining scope and boundaries:
   • Includes all emissions from cradle (raw materials, wafer fab, assembly, packaging, shipping, DC construction) to grave (end-of-life/disposal).
   • Operational energy encompasses both development (training/fine-tuning) and inference, including all datacenter overheads (PUE, cooling).
2. Quantifying embodied emissions ($E_{\mathrm{emb}}$):
   • Bill-of-materials and supply chain LCA using standardized tools (e.g., IMEC.netzero, Sphera/ecoinvent).
   • Regional adjustments for grid mix, abatement, yield, and scrap rates.
3. Measuring operational emissions ($E_{\mathrm{op}}$):
   • Granular telemetry (e.g., 5 min PSU readings) aggregated over system lifetime; adjust for partial utilization.
   • Convert total kWh consumed over $T_{\text{lifetime}}$ to kgCO₂e by multiplying by site- and time-specific emissions factors ($\mathrm{EF_{elec}}$), with distinction between location-based and market-based accounting.

$$E_{\mathrm{op}} = \sum_{\text{intervals}} \left( \text{Power}_{\text{avg}} \times \Delta t \right) \times \mathrm{EF}_{\mathrm{elec}}(t)$$

1. Measuring cumulative useful FLOPs ($E_{\mathrm{emb}}$0):
   • Summing hardware-instrumented FLOP counts over all chips and intervals across the deployment.
2. Calculating CCI:
   • Simple division as in the formal definition above.
   • Optionally, implement bias correction (e.g., duty-cycle matching, propensity-score weighting) when comparing hardware generations (Schneider et al., 1 Feb 2025).

Example: For TPU v4i over 6 years (market-based emissions):

• Embodied CCI: 114 gCO₂e/10¹⁸ FLOPs
• Operational CCI: 346 gCO₂e/10¹⁸ FLOPs
• Total CCI: 460 gCO₂e/10¹⁸ FLOPs TPU v6e achieves 156 gCO₂e/10¹⁸ FLOPs, representing a 2.95× improvement (Schneider et al., 1 Feb 2025).

3. Application to Workload-Level Emissions

Once CCI is known for an accelerator/system, total emissions ($E_{\mathrm{emb}}$1) associated with a particular workload are given by:

$E_{\mathrm{emb}}$2

where $E_{\mathrm{emb}}$3 is the total number of FLOPs executed for the workload.

As an illustration, training GPT-3 (3.14×10²³ FLOPs) on TPU v4i (CCI = 460 gCO₂e/10¹⁸ FLOPs) yields:

• $E_{\mathrm{emb}}$4 (Schneider et al., 1 Feb 2025).

4. Comparison to Related Carbon Intensity Metrics

CCI is related—but not identical—to:

• Location-based grid carbon intensity: Average grid emissions per energy transferred (e.g., gCO₂e/kWh), ignoring contracts/PPAs (Maji et al., 2023, Maji et al., 2024, Unnewehr et al., 2021).
• Market-based grid carbon intensity: Emissions per grid energy consumed, net of PPA/REC contracts (Maji et al., 2023, Maji et al., 2024).
• Software Carbon Intensity (SCI): Emissions per “functional unit” of computation for a specific software workload, usually taking the form $E_{\mathrm{emb}}$5 (Dodge et al., 2022).
• System-level CCI for HPC: Carbon per kWh or per compute-hour, integrating both embodied and operational emissions over full system lifetime (Li et al., 2023).

CCI differs fundamentally because its denominator is cumulative computational work (FLOPs), enabling normalization across architectures, hardware generations, datacenter energy mixes, and time.

5. Methodological Variants and Implementation Considerations

CCI can be calculated at various levels of granularity:

• Device- and fleet-level: Requires granular, machine-instrumented workload and power data, plus robust LCA for hardware (Schneider et al., 1 Feb 2025).
• Workload-level estimates (AI-specific): For cases with incomplete metadata, regression frameworks on FLOPs, parameter counts, or hardware typology can provide statistically grounded CCI estimates (Wang et al., 2 May 2026).
• Operational-only proxies: In contexts lacking embodied data, runtime-only estimates can be used, analogous to the “operational CCI,” but will underestimate true cradle-to-grave impact (Schneider et al., 1 Feb 2025).

Limitations and required assumptions:

• All FLOPs are treated equally (FP16, BF16, FP32, etc. aggregated).
• Energy emission factor is generally time-averaged; real-time CCI estimation is only possible with sufficiently granular grid tracking (“24/7 CFE” approaches).
• Embodied emissions are calculated conservatively (exclude recycling credits).
• Comparisons require control for utilization and duty-cycle structure.

6. Significance, Interpretive Context, and Future Developments

The “Compute Carbon Intensity” framework enables computable, hardware- and deployment-neutral assessments of the carbon efficiency of AI and HPC infrastructure. The deployment of CCI as a primary sustainability metric allows for:

• Rapid evaluation of environmental cost per unit of computation, fostering climate-aligned hardware and software optimization.
• Cross-generational, cross-architectural benchmarking consistent with full lifecycle carbon accounting.
• Integration with carbon-aware scheduling at workload submission, procurement, and datacenter siting.

As documented, generational improvements in hardware design and grid decarbonization can drive CCI downward. TPU v4i (total CCI = 460 gCO₂e/10¹⁸ FLOPs) versus TPU v6e (156 gCO₂e/10¹⁸ FLOPs) exemplifies a 3× reduction, realized through both more efficient hardware and increased procurement of carbon-free energy (Schneider et al., 1 Feb 2025).

Current limitations center on incomplete instrumentation of deployed compute, lack of standardized FLOP accounting for variable precision, and nonuniform LCA methodologies. Ongoing community efforts seek to extend real-time carbon tracking (e.g., 24/7 CFE), increase hardware telemetry coverage, and harmonize embodied emission databases.

7. Representative CCI Values and Benchmark Table

Below, a summary table of CCI for recent Google TPUs (market-based values) (Schneider et al., 1 Feb 2025):

Hardware	Embodied CCI (gCO₂e/10¹⁸ FLOPs)	Operational CCI (gCO₂e/10¹⁸ FLOPs)	Total CCI (gCO₂e/10¹⁸ FLOPs)
TPU v4i	114	346	460
TPU v6e	38	118	156

Operational CCI per ExaFLOP is a function of measured system kWh/ExaFLOP and grid EF. These values provide immediate scaling to any reported AI workload FLOPs, enabling rigorous, transparent estimation of compute emissions.

References:

• "Life-Cycle Emissions of AI Hardware: A Cradle-To-Grave Approach and Generational Trends" (Schneider et al., 1 Feb 2025)
• "Hugging Carbon: Quantifying the Training Carbon Emissions of AI Models at Scale" (Wang et al., 2 May 2026)
• "Toward Sustainable HPC: Carbon Footprint Estimation and Environmental Implications of HPC Systems" (Li et al., 2023)
• "Measuring the Carbon Intensity of AI in Cloud Instances" (Dodge et al., 2022)
• Additional context: (Maji et al., 2023, Maji et al., 2024)