Sustainability and Energy-Aware Quantum Operations

Quantum computers are physical infrastructure. Their environmental footprint includes cryogenics, dilution refrigeration, control electronics, compute for simulation and compilation, data storage, laboratory facilities, cloud orchestration, and failed experiments. The goal is not to pretend early quantum systems are efficient. The goal is to measure honestly and optimize where it matters.

The Green Software Foundation Software Carbon Intensity specification provides a general methodology for expressing software carbon emissions as a rate. Quantum platforms can adapt this thinking to unit economics such as carbon per accepted experiment, carbon per valid shot, or carbon per evidence package. [R144]

Diagram loads as you read

Sustainability and Energy-Aware Quantum Operations · Figure 1

View diagram source

flowchart LR
    Workload[Quantum workload] --> QPU[QPU and controls]
    Workload --> Classical[Classical compute]
    Workload --> Storage[Data storage]
    Workload --> Facility[Facility overhead]
    QPU --> Footprint[Operational footprint]
    Classical --> Footprint
    Storage --> Footprint
    Facility --> Footprint

Define the unit

A sustainability metric must define the unit of useful work. For quantum platforms, useful work is not simply a shot.

Diagram loads as you read

Define the unit · Figure 2

View diagram source

flowchart TB
    Unit[Unit of useful work] --> Shot[Accepted shot]
    Unit --> Job[Validated job]
    Unit --> Evidence[Evidence package]
    Unit --> Claim[Reviewed claim]
    Unit --> Learning[Actionable learning]

Possible units:

Unit	When useful
energy per submitted job	broad cost visibility
energy per accepted job	queue and failure efficiency
energy per valid shot	execution efficiency
energy per evidence package	research productivity
energy per decision	product-level impact

Footprint components

Diagram loads as you read

Footprint components · Figure 3

View diagram source

flowchart TB
    Energy[Energy model] --> Facility[Facility base load]
    Energy --> Cryo[Cryogenics]
    Energy --> Control[Control electronics]
    Energy --> Classical[Classical compute]
    Energy --> Network[Network and storage]
    Energy --> Waste[Failed or invalid runs]

The operationally actionable question is: which component is controllable by scheduling, batching, compilation, validation, or retention policy?

Avoid invalid work

The most efficient quantum job is the one that should never have been submitted.

Diagram loads as you read

Avoid invalid work · Figure 4

View diagram source

flowchart LR
    Idea[Experiment idea] --> Sim[Simulation and static validation]
    Sim --> Policy{Pass?}
    Policy -- no --> Revise[Revise locally]
    Policy -- yes --> Hardware[Run hardware]
    Hardware --> Evidence[Evidence]

Energy-aware operations reinforce existing correctness discipline:

validate on simulators first;
reject unsigned or under-specified workloads;
batch compatible experiments;
avoid obsolete backends;
cap exploratory shot budgets;
retire stale datasets.

Carbon-aware scheduling

Some workloads are latency-sensitive. Many are not. Batch workloads can be scheduled to reduce cost, carbon, or contention.

Diagram loads as you read

Carbon-aware scheduling · Figure 5

View diagram source

flowchart TB
    Queue[Workload queue] --> Classify{Latency sensitive?}
    Classify -- yes --> Immediate[Immediate scheduling]
    Classify -- no --> Optimize[Optimize window]
    Optimize --> Carbon[Carbon intensity]
    Optimize --> QueueDepth[Queue depth]
    Optimize --> Calibration[Calibration window]
    Optimize --> Reservation[Reservation economics]
    Carbon --> Dispatch[Dispatch]
    QueueDepth --> Dispatch
    Calibration --> Dispatch
    Reservation --> Dispatch

Do not sacrifice scientific validity for carbon optimization. A job that misses the relevant calibration window may waste more energy by producing unusable evidence.

Batch efficiency

Diagram loads as you read

Batch efficiency · Figure 6

View diagram source

flowchart LR
    Separate[Separate jobs] --> Overhead1[Repeated overhead]
    Grouped[Grouped compatible jobs] --> Overhead2[Shared overhead]
    Overhead2 --> Savings[Lower overhead per result]

Batching helps when jobs share:

target;
calibration tolerance;
circuit family;
shot policy;
data classification;
review workflow.

Batching hurts when it hides per-job provenance or pushes stale work into a run window.

Simulation footprint

Classical simulation can dominate early-stage research costs. Treat simulation as a managed workload.

Diagram loads as you read

Simulation footprint · Figure 7

View diagram source

flowchart TB
    SimPlan[Simulation plan] --> Method{Method}
    Method -- statevector --> GPU[GPU or HPC]
    Method -- tensor network --> HPC[HPC batch]
    Method -- stabilizer --> CPU[CPU pool]
    Method -- approximate --> Cheap[Approximate estimator]
    GPU --> Budget[Energy and cost budget]
    HPC --> Budget
    CPU --> Budget
    Cheap --> Budget

Simulation policy should match fidelity to decision value. Do not run a high-cost simulation to answer a low-stakes screening question.

Data retention footprint

Evidence preservation matters, but unlimited retention is not discipline.

Diagram loads as you read

Data retention footprint · Figure 8

View diagram source

flowchart LR
    Dataset[Dataset] --> Value{Future value?}
    Value -- high --> Preserve[Preserve full package]
    Value -- medium --> Compress[Compress and tier]
    Value -- low --> Summarize[Keep summary and delete raw]
    Value -- legal hold --> Immutable[Immutable retention]

Retention decisions should be documented and reversible where possible.

Sustainability dashboard

Diagram loads as you read

Sustainability dashboard · Figure 9

View diagram source

flowchart TB
    Metrics[Sustainability metrics] --> Energy[Energy per valid shot]
    Metrics --> Waste[Invalid run rate]
    Metrics --> Storage[Evidence storage growth]
    Metrics --> Sim[Simulation compute hours]
    Metrics --> Carbon[Carbon estimate]
    Metrics --> Trend[Trend over releases]

A practical dashboard combines engineering and scientific metrics:

Metric	Interpretation
invalid_run_rate	waste caused by weak admission control
simulator_to_qpu_ratio	local validation discipline
energy_per_valid_shot	execution efficiency proxy
evidence_storage_growth	retention pressure
reanalysis_yield	value recovered from archived evidence

Operating rule

Sustainability is not a marketing afterthought. It is an operating constraint that rewards better validation, batching, scheduling, and retention.