PaperlayerView exact revision on arXiv

Source-linked AI summary

GreenPassport: Request-Level Carbon Accounting for Cross-Border AI Inference

Rui Lu

arXiv:2609.06784v3cs.CYcs.SYeess.SY

TL;DR

Cross-border inference can pair users with distant serving sites whose hardware, electricity mixes, and carbon intensities differ, while request-level energy and routing data are less often disclosed. GPCA records per-request inputs and sets reporting levels by source quality and comparison stability; its calibrated proxy achieved the lowest median APE in the measured-energy evaluation.

  • Problem

    Cross-border inference spans regions with differing serving infrastructure and electricity, while per-request energy, routing, fleet, and site data are less often disclosed.

    Source: §1 · p. 1

  • Method

    GPCA combines request-level carbon estimation with source-aware reporting, connecting serving, electricity, route, uncertainty, and comparator inputs and mapping provenance and stability to reporting levels.

    Source: §1 · pp. 1–2

  • Results

    23.0% median APE and 0.0169 Wh per response median MAE: the calibrated GPCA proxy achieved the lowest median APE and median MAE; GPCA had zero rule overstatement in deterministic tests.

    Source: §5.3 · p. 6

  • Takeaways & Limitations

    The evaluation connects request-carbon estimates to service comparisons under explicit workload, deployment, and electricity conditions.

    Source: §7 · p. 7

    Carbon comparisons require compatible workloads and output lengths, while feasibility depends on local model availability, memory, transfer policy, and latency or SLA class.

    Source: §2.2 · p. 2

Abstract

from arXiv · show

AI inference often crosses regional boundaries as prompts travel to remote data centers and generated tokens return to users. Regional averages cannot represent the resulting differences in serving hardware, electricity, and network delivery. Request-level accounting needs a common boundary for the service, serving site, route, local comparator, uncertainty, and data provenance. GreenPassport Carbon Accounting (GPCA) associates these inputs with each request. It estimates serving and route carbon, then selects a reporting level from the available documentation. Our public-data implementation covers data-center instances, accelerators, model families, electricity mixes, routes, and cloud-region carbon intensity. Against six accounting baselines and four energy-prediction baselines, GPCA reduced median absolute percentage error by 56.3% and median absolute error by 15.5% relative to EcoLogits under the aligned accelerator-energy boundary. It produced zero rule overstatement in the deterministic conformance tests. In the buyer case, the clean-electricity CN-West scenario produced 0.0148 gCO2e per request, 88% below the local service at 0.1220 gCO2e per request.

1 Introduction

Inference may be consumed in one region and served in another, where electricity mixes and accelerator infrastructures differ. GPCA frames request-level accounting around serving, electricity, route, uncertainty, comparison, and documented inputs.

1 Introduction

  • Per-request energy, production routing, fleet composition, and serving sites are less often disclosed, so GPCA labels inputs as measured, disclosed, estimated, or missing.Source: §1 · p. 1
  • GPCA computes request and token carbon from IT energy, facility overhead, serving-site carbon intensity, route bytes, and network energy.Source: §1 · pp. 1–2
  • GPCA formulates cross-border carbon accounting at request level, connecting serving, electricity, route, uncertainty, and comparator inputs in one passport.Source: §1 · p. 2
  • Its accounting model separates measurement from fitted estimation and maps source quality and comparison stability to reporting levels.Source: §1 · p. 2
  • Evaluation on measured-energy data and public scenarios quantifies prediction error, configuration screening, regional sensitivity, and delivery effects.Source: §1 · p. 2

2 Background and Problem Setting

Cross-border request carbon combines serving energy and its electricity basis with delivery along the route. GPCA organizes the request context and checks whether local services are comparable before reporting differences.

2.1 Cross-Border Inference and Carbon Accounting

  • A request’s operational footprint combines its serving environment, local power supply, and bidirectional delivery route; route energy can become material for cross-region delivery or large payloads.Source: §2.1 · p. 2

2.2 Request-Level Accounting Setting

  • A GreenPassport organizes the prompt, generated output, route payload, and serving context for one inference transaction.Source: §2.2 · p. 2
  • GPCA evaluates service configurations within their serving region, while finer reporting levels require inputs such as provider telemetry, hourly carbon data, route measurements, or clean-power documents.Source: §2.2 · p. 2
  • Services are comparable only for a compatible declared workload and model availability, memory capacity, data-transfer policy, and latency or SLA class; feasibility is checked before carbon calculation.Source: §2.2 · p. 2

3 Design of GreenPassport Carbon Accounting Model (GPCA)

GPCA estimates request carbon from serving-site and route terms, then compares it with a matched local service and assigns a reporting level supported by input provenance and uncertainty.

Energy inputs

  • Measured deployments integrate request-attributed serving-stack power, while public-data deployments use a separate calibrated estimator for IT energy.The default shared-serving attribution separates prefill and decode token-time after subtracting an idle baseline; declared proxy allocation maps to a lower reporting level.Source: §3 · pp. 2–3
  • The public-data log-linear estimator represents model scale, output length, batch size, accelerator count, and MoE execution, with coefficients frozen before grouped testing.When batching or accelerator-specific effects are unavailable, GPCA uses a wider datasheet-based scenario and lists the missing variables.Source: §3 · p. 3

Uncertainty

  • GPCA distinguishes measurement, model-residual, and scenario uncertainty, combines applicable bounds, and reports the limiting category.The validation residual interval is distinct from route, PUE, and carbon-intensity bounds.Source: §3 · p. 3

Site accounting

  • Serving-site carbon multiplies IT energy by a facility multiplier and site carbon intensity; source-resolved records also store generation shares and the reporting basis.The public implementation uses independently verified annual regional carbon intensity for the carbon value and reports generation shares beside it.Source: §3 · p. 3

Route accounting

  • Route accounting uses segment energy and carbon intensities, with public route data represented as intervals and measured carrier or provider telemetry available for imported service.The route boundary is bidirectional.Source: §3 · p. 3

Request-level accounting

  • Request carbon adds serving-site and route carbon, with the request value primary because token-normalized values can hide fixed prompt, routing, and service overheads.Local service sets the cross-border route segment to zero.Source: §3 · p. 3

Comparison and reporting

  • GPCA checks model-memory feasibility and compares a request only with a matched local service; robust lower-carbon claims must satisfy the combined uncertainty condition.Rows outside that condition receive an annual-estimate or scenario label.Source: §3 · pp. 3–4

4 GreenPassport Reporting Standard

GPCA’s reporting standard combines request and token carbon, uncertainty, source basis, a local comparator, and an output level. It makes required fields and provenance explicit, then uses documentation and validity rules to determine what can be reported.

4 GreenPassport Reporting Standard

  • A service description records the request or workload, model or service, hardware, instance class, serving site, delivery route, input basis, and supporting documents.The standard also computes request carbon, token carbon, and uncertainty from the request, configuration, site, and route.Source: §4 · p. 4
  • The standard rejects incomplete entries; missing required fields or failed service constraints also trigger rejection, while an invalid comparator yields an annual estimate.A lower-carbon label additionally requires a robust inequality when public uncertainty sets are non-singletons.Source: §4 · p. 4
  • GPCA selects among candidates that satisfy required fields, memory feasibility, route boundaries, and the operational predicate, then labels the selected row as an annual estimate, lower-carbon estimate, or green-eligible.The selected record stores the model, accelerator, instance, site, route, input basis, and documents.Source: §4 · p. 4
  • The same-configuration comparator isolates location and route effects, while the best-local comparator tests against the lowest-carbon feasible local option in the declared catalog.The operational predicate is checked before either comparison; infeasible or policy-incompatible candidates do not define the reported minimum.Source: §4 · p. 4
  • Annual national or regional data support annual estimates, official accelerator and instance specifications support scenarios, and provider energy disclosures apply only to their stated service boundary.Hourly or certificate-backed green labels require timestamped workload data, deliverability, residual-mix treatment, and no double counting.Source: §4 · p. 4
  • The verifier assigns the effective reporting level from supporting documents and checks timestamps, hardware feasibility, workload boundaries, allocation rules, route inputs, and clean-electricity documents.The GreenPassport stores the selected deployment and accounting result.Source: §4 · pp. 4–5

5 Evaluation and Implementation

This section presents a public-data GPCA pipeline and evaluates energy prediction, regional service comparisons, and reporting behavior. Results include prediction errors, reporting-rule conformance, and a buyer-case carbon comparison.

5.1 Implementation

  • The public-data pipeline combines regional grid, cloud-region, accelerator, instance, model, route, and workload inputs into GreenPassport rows with provenance.It records calculated values and reporting decisions in the passport schema.Source: §5.1 · p. 5

5.2 Evaluation Setup

  • Evaluation used public ML.ENERGY measurements, exact-model-ID-held-out validation, regional scenarios, and deterministic reporting-rule fixtures.The energy target was accelerator energy per response, excluding PUE, network, and end-user energy; global sensitivity used 50,000 deterministic samples.Source: §5.2 · pp. 5–6

5.3 Results

  • Across sensitivity samples, CN-East was above the local comparator in 82.1% of cases and overlapped it in 17.9%; CN-West was lower in 42.5%, overlapped in 45.1%, and higher in 12.4%.In deterministic tests, field completeness ranged from 0.30 to 0.60 for baselines and was 1.00 for GPCA; rule overstatement ranged from 0.25 to 0.75 for baselines. A candidate could outperform the same local configuration while exceeding the best feasible local service.Source: §5.3 · p. 6
  • The calibrated GPCA proxy achieved 23.0% median APE and 0.0169 Wh per response median MAE; EcoLogits had the highest rank correlation at 0.964.Both methods achieved 66.7% top-1 agreement and zero median measured selection regret; the nominal 90% residual interval covered 84.0% of validation data. Testing excluded exact model identifiers used for fitting and covered represented H100 and B200 configurations.Source: Table 1 · p. 6, §5.3 · p. 6, §5.5 · p. 6

5.4 Case Study

  • At the reference point, CN-West clean was 0.0148 gCO2e/request, 88% below US-Middle local service and 35% below GCP Oregon.US-East and US-West were below the matched local service but exceeded GCP Oregon; CN-West delivery contributed 0.00038 gCO2e/request, or 2.6% of its total.Source: §5.4 · p. 6

5.3 Results

  • Route carbon was small for short text but increased with payload, reaching material shares for larger requests.The figures show request and token carbon across configurations, comparator reductions, and route contribution.Source: Figure 4 · p. 5, Figure 5 · p. 5, §5.3 · p. 6

5.5 Interpretation

  • Delivery accounted for 0.25% of short-request carbon and 66.27% for document/RAG, while memory gating changed which configurations were feasible.NoInstanceGate admitted configurations failing the memory check; NoRoute had its largest effect on requests with large payloads.Source: §5.5 · p. 7
  • Against the best feasible local service, CN-West's reduction was 35% rather than 88%; NoSourceGate labeled 85% of entries green, falling to zero when required inputs were missing.The label fraction also decreased as uncertainty widened.Source: §5.5 · p. 7

6 Related Work

Related work covers energy and carbon estimation, serving and electricity systems, delivery, and accounting documentation. GPCA applies documentation principles to request-carbon accounting and local-service comparisons.

Carbon measurement and inference energy

  • CodeCarbon measures or estimates local hardware energy, CarbonTracker predicts running training-job footprints, and EcoLogits estimates remote generative-AI API impacts.The cited inference studies report variation with model size, task length, batching, accelerator generation, memory behavior, and serving implementation.Source: §6 · p. 7

Serving systems, electricity, and delivery

  • Carbon-aware datacenter systems use location- and time-varying grid intensity; network studies relate delivery energy to traffic, path, utilization, and system boundary.Electricity Maps documents consumption-based average signals, while WattTime provides marginal location- and time-based signals.Source: §6 · p. 7

Accounting boundary and documentation

  • GHG Protocol Scope 2 addresses location- and market-based accounting, residual mixes, and double-counting; GPCA applies documentation principles to request-carbon reports and local comparisons.EnergyTag specifies granular certificate schemes, while model cards, data statements, and datasheets structure model and dataset documentation.Source: §6 · p. 7

7 Conclusion

GPCA combines serving-energy estimation and route accounting for cross-border requests, then compares services with local alternatives and assigns reporting levels using provenance and uncertainty. Its evaluation reports lower absolute prediction error than EcoLogits, zero rule overstatement in deterministic tests, and buyer and workload analyses under explicit conditions.

7 Conclusion

  • GPCA connects request-carbon estimates to service comparisons under explicit workload, deployment, and electricity conditions.The conclusion also reports lower absolute prediction error than EcoLogits, zero rule overstatement in deterministic tests, and buyer and workload analyses.Source: §7 · p. 7

A.1 Model Hierarchy and Worked Request

  • The accounting hierarchy separates measured quantities, calibrated public proxies, scenario inputs, uncertainty, and label decisions.Table A.2 applies that hierarchy to the reference request and gives its scenario-level result.Source: §A.1 · p. 10

A Public Inputs and Provenance

  • The public-data inputs include annual grid intensities and generation mixes, cloud-region carbon rows, and declared route and payload settings.Route, overhead, and payload values are stress-test settings drawn from literature-informed ranges.Source: §A.2 · p. 10

A.2 Public-Scenario Defaults

  • Route defaults specify reference prompt size, output length, response-byte factor, protocol overhead, and domestic or CN-to-US route-energy intensities.Table A.3 lists the numerical defaults used by the public run.Source: §A.2 · p. 10

A.3 Global-Sensitivity Ranges

  • Global sensitivity uses declared epistemic stress bounds for model, serving, PUE, grid, and route inputs.Model and serving ranges surround fitted ML.ENERGY coefficients; PUE, grid, and route ranges are screening envelopes informed by public inputs and network-energy literature.Source: §A.3 · p. 10

A.4 Hardware and Estimate Checks

  • The hardware catalog covers seven accelerator classes and public cloud instances; workloads and accelerators outside calibration use a wider datasheet-based scenario.TPU v4 uses published mean measured chip power, while B200 uses an allocated DGX B200 system-power figure because directly comparable GPU TDP is unavailable.Source: §A.4 · p. 10, Figure A.1 · p. 10

A.5 Model and Service Data

The appendix documents model and service inputs, request-energy attribution, and the GreenPassport schema. Its reporting algorithm applies comparator, uncertainty, provenance, and operational checks to select the highest supported label or reject an entry.

A.5 Model and Service Data

  • Open model families use public model-size information, while ChatGPT and Gemini use service-level energy disclosures that omit serving fleet, route, and workload mix.The cited inputs are 0.34 Wh average per ChatGPT query and 0.24 Wh median per Gemini Apps text prompt.Source: §A.5 · p. 10

A.6 Schema, Provenance, and Generated Artifacts

  • The GreenPassport schema records request configuration, site, source mix, route, uncertainty, comparators, provenance, validity, and verification, with five output labels.The labels are reject, annual-estimate, scenario, lower-carbon-estimate, and green-eligible.Source: §A.6 · p. 10

A.7 Request-Energy Attribution

  • The default measured-energy rule allocates shared serving energy using separate prefill and decode token-time after subtracting an idle baseline.Alternative allocation policies can assign different values to the same trace; token-proportional allocation can overcharge long decodes when batching improves utilization, while marginal-energy allocation can be unstable at low load.Source: §A.7 · pp. 10–11

A.8 Reporting-Eligibility Algorithm

  • GPCA returns the highest eligible reporting level after checking feasibility, comparator validity, uncertainty, documentation, and source requirements; missing fields or contradictions can trigger rejection or review.Robust negative gaps with verified documentation support lower-carbon-estimate; green-eligible requires qualifying clean-energy data and accounting checks.Source: §A.8 · pp. 11–12

B Additional Evaluation Details

The appendix supplies fixed-workload decision matrices, tool-boundary comparisons, metric definitions, and a conditional buyer-case reference result. The metrics distinguish request and token carbon, comparator reductions, selection regret, and conformance to reporting rules.

B.1 Fixed-Workload Label Matrix

  • The fixed-workload matrix varies route intensity by column, while the joint sensitivity analysis varies all declared inputs.Its panels cover four public GCP U.S. regional carbon-intensity rows against US-Middle and the CN-West clean scenario.Source: §B.1 · p. 12

B.2 Tool Boundary Comparison

  • Appendix Table B.1 compares accounting inputs and reporting components across the tools discussed in the main evaluation.The supplied passage states the comparison's scope but no outcome.Source: §B.2 · p. 12

B.3 Evaluation Metrics

  • Request carbon is serving-site plus route carbon, and token carbon normalizes request carbon by output length.Percentage reductions use same-local and best-local comparators; selection regret measures the carbon penalty of a baseline-selected candidate.Source: §B.3 · p. 12
  • Deterministic fixtures assess label eligibility and rule overstatement against the executable reporting gate, with omitted components treated as missing inputs in ablations.The complementary conformance score tests whether outputs stay within the level supported by inputs, comparators, uncertainty, route boundary, feasibility, and attribution rule.Source: §B.3 · p. 12

B.4 Case-Study Conditional Decision Card

  • Table B.2 reports the US-Middle reference-point result and its stability across the uncertainty envelope.The supplied passage does not state the table's numerical values.Source: §B.4 · p. 12

C Ablation Study

The ablation removes GPCA mechanisms one at a time while holding workload data, candidate set, public inputs, and carbon coefficients fixed. Reported analyses cover workload-dependent route carbon, source-dependent output levels, and input sensitivities.

C Ablation Study

  • The ablation varies one GPCA mechanism at a time while retaining workload data, candidates, public inputs, and carbon coefficients.It measures changes in request carbon, candidate feasibility, comparator outcome, and admissible label.Source: C Ablation Study · p. 12
  • The fixed-workload figure covers GCP U.S. regions and the CN-West clean scenario, while the buyer decision-chain figure runs from reference point to uncertainty-envelope result.The appendix also points to comparisons of local references and component-omission regret.Source: Figure B.1 · p. 13, Figure B.2 · p. 13, C Ablation Study · p. 13
  • With the full method active, request carbon increased monotonically with output length, payload, PUE, and serving-site carbon intensity.The appendix figures also break down route carbon by workload and show carbon and memory feasibility across the accelerator catalog.Source: C Ablation Study · p. 13
  • Annual, marginal, hourly, curtailed, and certificate-backed inputs produced different estimates and output levels.The figures show label transitions as uncertainty and source requirements changed.Source: C Ablation Study · p. 13

D Serving Implementation Context

The section connects serving energy to implementation choices, then bounds the evaluation to public configurations and operational carbon from serving and delivery.

D Serving Implementation Context

Scope

  • Public ML.ENERGY aggregate configurations for represented workloads and H100- and B200-class accelerators were evaluated with annual, regional, or scenario electricity data.Higher reporting levels require provider telemetry, time-matched electricity data, route measurements, and verification documents.Source: Scope · pp. 13–14
  • The accounting boundary covers operational carbon from serving and delivery, excluding training amortization, embodied hardware emissions, water, land, price, reliability, privacy, and grid-expansion effects.Source: Scope · p. 14
  • Output length, payload, PUE, and serving-site carbon intensity move request carbon monotonically in the controlled sensitivity analysis.Source: Figure C.5 · p. 15

Related papers

Loading 2609.06784v3…