Cost Engineering and Capacity Planning

Quantum cost engineering is not only about vendor price. It is about scarce calibrated time, queue priority, failed jobs, simulator usage, storage, human review, and the opportunity cost of running the wrong experiment.

The cost model should be visible to users before they submit work. Otherwise they will optimize for convenience and accidentally burn the platform budget.

16.1 Cost stack

flowchart TB
    Cost[Total cost] --> QPU[QPU access]
    Cost --> Simulator[Simulation compute]
    Cost --> Classical[Classical optimizer compute]
    Cost --> Compilation[Compilation and validation]
    Cost --> Storage[Artifact and shot storage]
    Cost --> Human[Review and operations]
    Cost --> Failure[Failed and invalidated runs]

For planning, distinguish direct charges from operational costs.

The cheapest QPU job may be expensive if it produces unusable evidence.

16.2 Capacity units

Classical capacity is often measured in cores, memory, or GPU-hours. Quantum capacity needs more dimensions.

flowchart LR
    Capacity[Quantum capacity] --> Time[Available device time]
    Capacity --> Quality[Quality window]
    Capacity --> Qubits[Usable qubit subsets]
    Capacity --> Shots[Shot throughput]
    Capacity --> Calibration[Calibration cadence]
    Capacity --> Queue[Queue policy]

A device with 95% nominal uptime but unstable two-qubit performance may have lower useful capacity than a device with less uptime and more predictable quality.

Define capacity in quality-adjusted terms:

useful_capacity = available_time × eligible_qubit_fraction × useful_result_rate

This is not a universal formula. It is a forcing function. It prevents teams from reporting only raw access time.

16.3 Demand forecasting

Demand comes from people, algorithms, experiments, and deadlines.

flowchart TD
    Roadmap[Research roadmap] --> Demand[Demand forecast]
    Papers[Publication deadlines] --> Demand
    Product[Product milestones] --> Demand
    Education[Training usage] --> Demand
    Regression[Benchmark suites] --> Demand
    Demand --> CapacityPlan[Capacity plan]

Forecast categories:

Do not let demos consume the same priority class as critical validation.

16.4 Admission control as cost control

Every rejected job can save money. Every accepted job should have a reason.

flowchart TD
    Job[Job request] --> Estimate[Estimate cost and quality]
    Estimate --> Policy[Apply budget policy]
    Policy --> Value[Estimate expected value]
    Value --> Decision{Admit?}
    Decision -- yes --> Execute[Execute]
    Decision -- no --> Alternative[Suggest simulator, smaller shots, or later window]

Admission should return alternatives:

A platform that only says “quota exceeded” teaches users nothing.

16.5 Adaptive shots

Shot count is one of the largest levers in cost and uncertainty.

flowchart LR
    Pilot[Pilot shots] --> Interval[Update sequentially valid interval]
    Interval --> Need{Precision met?}
    Need -- yes --> Stop[Stop]
    Need -- no --> Budget{Budget remains?}
    Budget -- yes --> More[Allocate and acquire more shots]
    Budget -- no --> Report[Report unmet precision]
    More --> Interval

Adaptive shot policy:

1. Declare a sequentially valid precision rule and a shot cap before execution.
2. Acquire pilot shots and update the chosen interval.
3. Acquire additional shots only while the rule and budget permit.
4. Report whether precision was met or the budget was exhausted.

See chapter 145 for the distinction between fixed-sample intervals and intervals valid under adaptive stopping.

A precision contract can guide shot allocation. A fixed shot count remains appropriate when required by the experiment design or chosen inference method.

16.6 Portfolio allocation

A platform must balance safe incremental work against high-risk research.

quadrantChart
    title Quantum workload portfolio
    x-axis Low expected value --> High expected value
    y-axis Low uncertainty --> High uncertainty
    quadrant-1 Strategic bets
    quadrant-2 Avoid or redesign
    quadrant-3 Routine validation
    quadrant-4 Production candidates
    Benchmark suite: [0.35, 0.20]
    Demo workload: [0.20, 0.65]
    New algorithm trial: [0.70, 0.80]
    Validated estimator: [0.82, 0.25]

Portfolio policy is governance. It should be explicit:

• reserve a fixed share for benchmarks and validation,
• reserve strategic windows for high-value experiments,
• cap low-value exploratory work,
• move repeatable workflows to batch mode,
• require simulator evidence for expensive QPU runs.

16.7 Reservation economics

Reservations can improve continuity for hybrid loops and time-sensitive experiments, but they can waste capacity if underused.

flowchart TD
    Need[Need continuity?] --> Reserve{Reserve window?}
    Reserve -- no --> Shared[Use shared queue]
    Reserve -- yes --> Prepare[Pre-stage workloads]
    Prepare --> Execute[Execute during window]
    Execute --> Util[Measure utilization]
    Util --> Learn[Update reservation policy]

Reservation readiness checklist:

A reservation should be treated like a launch window.

16.8 FinOps dashboard

Cost dashboards should combine money, quality, and outcomes.

flowchart LR
    Spend[Spend] --> Dashboard[FinOps dashboard]
    Usage[QPU and simulator usage] --> Dashboard
    Quality[Useful-result rate] --> Dashboard
    Waste[Failed and invalidated runs] --> Dashboard
    Forecast[Demand forecast] --> Dashboard
    Dashboard --> Decisions[Budget and capacity decisions]

Useful dashboard panels:

• spend by project,
• shots by target,
• queue time by priority class,
• failed jobs by cause,
• invalidated results by root cause,
• useful-result rate by workload class,
• simulator-to-QPU conversion rate,
• reservation utilization,
• cost per promoted result.

The last metric is often more honest than cost per shot.

16.9 Capacity planning loop

flowchart LR
    Observe[Observe demand and quality] --> Forecast[Forecast demand]
    Forecast --> Allocate[Allocate capacity]
    Allocate --> Enforce[Enforce quotas and priorities]
    Enforce --> Review[Review outcomes]
    Review --> Observe

Capacity planning should produce decisions:

The best cost optimization is often algorithmic: fewer gates, fewer shots, fewer failed runs.

16.10 Cost review checklist

flowchart TD
    CostReview[Cost review] --> Waste[Find waste]
    Waste --> RootCause[Classify root cause]
    RootCause --> Fix[Apply technical or policy fix]
    Fix --> Measure[Measure change]
    Measure --> CostReview

Cost engineering is not austerity. It is the discipline of spending scarce quantum capacity where it creates the most reliable evidence.

Additional technical sources: [R278].