Quantum circuit resource estimation turns an abstract experiment into an execution plan. This worksheet shows how to estimate qubit requirements, circuit width and depth, measurement shots, parameterized repetitions, transpilation overhead, and approximate runtime before committing to a simulator or quantum processor.
Overview
A small quantum circuit can still require substantial classical and quantum resources. The circuit may use only a few logical qubits, yet optimization can generate hundreds of circuit executions. Conversely, a circuit with many qubits may be easy to simulate for a particular purpose but difficult to run reliably on hardware because of connectivity, noise, or queue time.
Resource estimation is therefore not a single-number calculation. It is a worksheet with several related questions:
- How many qubits are required? Count the data, ancilla, workspace, and readout qubits in the logical circuit.
- How wide is the circuit? Width usually means the number of qubits used at the same time.
- How deep is the circuit? Depth is the number of sequential layers after operations are scheduled according to their dependencies.
- How many shots are needed? A shot is one execution followed by measurement. More shots generally reduce sampling uncertainty, but increase execution work.
- How many circuit variants are required? Parameter sweeps, optimizer iterations, gradient evaluations, error mitigation, and calibration experiments can multiply the workload.
- How long will execution take? Separate circuit processing time, device execution time, transfer overhead, queue delay, and classical post-processing.
Keep logical requirements separate from physical requirements. A logical circuit describes the algorithm. A transpiled circuit reflects the target device's gate set, connectivity, routing strategy, scheduling, and compiler choices. The second version is the one that determines a realistic hardware estimate.
For algorithm selection, use this worksheet alongside the Quantum Algorithms Reference. For current hardware limitations, the NISQ guide for developers provides useful context.
How to estimate
1. Establish the logical circuit
Start with the circuit as written in your framework, before targeting a particular backend. Record the number of qubits, measured observables, parameterized gates, and classical outputs. If you are building a variational algorithm such as QAOA or VQE, record the number of parameter sets that will be evaluated rather than treating the circuit as a one-time job.
A first-pass workload estimate can be written as:
Total shots = circuit variants × shots per variant
For a hybrid workflow, expand it further:
Total shots = optimization iterations × evaluations per iteration × shots per evaluation
Add separate terms for validation, testing, gradient estimation, and error-mitigation circuits. If an optimizer evaluates a parameterized circuit at several nearby points to estimate a gradient, each point is another circuit variant even when the underlying circuit structure is unchanged.
2. Estimate width and depth
Logical width is the number of qubits in the circuit. Logical depth is the number of sequential operation layers under the scheduling rules used by your framework. A circuit with many gates can have modest depth if those gates act on independent qubits in parallel. A circuit with fewer gates can have greater depth if the operations form a long dependency chain.
Track at least three depth values:
- Logical depth: the depth of the algorithm before hardware-specific compilation.
- Transpiled depth: the depth after decomposition, routing, basis-gate conversion, and scheduling.
- Effective noisy depth: the portion of the circuit that matters for your error budget, including idle periods and operations especially sensitive to noise.
Do not assume that a lower gate count always means a lower execution cost. A design with fewer two-qubit gates may require additional routing on a device with limited connectivity. Compare the transpiled circuits on the intended target, not only the source code.
3. Convert shots into execution time
A useful planning model is:
Execution time ≈ number of submitted circuits × (shots × duration per shot + per-circuit overhead)
The duration per shot depends on scheduled gate timing, measurement, reset behavior, and the device's execution model. Per-circuit overhead can include job submission, compilation, synchronization, readout, and result transfer. Queue time is separate and should not be hidden inside the circuit runtime estimate.
When the provider exposes a shot-based execution model, begin with the scheduled duration and multiply it by the shot count. When the provider batches shots efficiently, the actual billed or wall-clock behavior may not scale exactly this way. Treat the formula as a planning estimate and replace assumptions with measured values from a small pilot job.
Inputs and assumptions
Use the following worksheet before running a new experiment. Record ranges when an exact value is not known.
| Input | What to record | Why it matters |
|---|---|---|
| Logical qubits | Data, ancilla, workspace, and measurement qubits | Defines the algorithmic width |
| Physical qubits | Qubits required after mapping and routing | May exceed logical width |
| Logical depth | Sequential layers before compilation | Shows algorithmic complexity |
| Transpiled depth | Depth after targeting the backend | Shows hardware execution burden |
| Two-qubit operations | Logical and transpiled counts | Often a major source of overhead and error |
| Shots per circuit | Initial, production, and validation shot counts | Controls sampling precision and workload |
| Circuit variants | Parameter sets, observables, gradients, and mitigation circuits | Multiplies total executions |
| Shot duration | Scheduled duration or a conservative range | Supports runtime estimation |
| Queue and service time | Measured separately from device time | Determines calendar time |
Shot selection should follow the decision you need to make. Use a smaller pilot budget to verify that the circuit compiles, measurements are sensible, and the signal is not obviously dominated by noise. Increase shots when you need tighter estimates of expectation values or probabilities. If the result changes materially between independent shot batches, more shots may improve precision; if it does not, circuit quality or model design may be the limiting factor.
For simulators, also record the simulation method, available memory, precision, batching strategy, and whether noise is enabled. State-vector simulation commonly scales poorly with qubit count because the state description grows exponentially, while alternative simulation methods can have different strengths and limitations. A simulator runtime is not a direct prediction of hardware runtime.
Framework reports should be treated as evidence, not universal constants. In Qiskit, Cirq, PennyLane, or another quantum software development kit, inspect the compiled circuit and backend-specific metadata. Save the framework version, transpiler settings, optimization level, target backend, and random seeds when applicable so that the estimate can be reproduced.
Worked examples
Example 1: A fixed circuit
Suppose a circuit uses 8 logical qubits, has a logical depth of 24, and is measured with 2,000 shots. You run one circuit variant. The first-pass shot workload is:
1 variant × 2,000 shots = 2,000 circuit executions.
After compilation, assume the target mapping produces 10 physical qubits and a depth of 41. The experiment still has an 8-qubit logical design, but its hardware requirement is now 10 qubits with a deeper schedule. If a pilot measurement shows a scheduled duration of 80 microseconds per shot, the device-active estimate is approximately:
2,000 × 80 microseconds = 160,000 microseconds, or 0.16 seconds.
This is not the end-to-end wall-clock time. Submission, queueing, readout, batching, and result processing may add time outside the scheduled circuit duration.
Example 2: A hybrid optimization loop
Consider a variational circuit with 12 trainable parameters. An optimizer runs 75 iterations. Each iteration evaluates 6 parameter sets, and each parameter set uses 1,500 shots. The estimated shot workload is:
75 × 6 × 1,500 = 675,000 shots.
Now add a validation run at the end with 4 parameter sets and 3,000 shots each:
675,000 + (4 × 3,000) = 687,000 total shots.
This estimate excludes failed jobs, retries, warm-up circuits, calibration experiments, and any additional measurements for error mitigation. It also assumes every iteration uses the same number of evaluations. In practice, retain a contingency range rather than planning against the minimum alone.
Example 3: Comparing two circuit designs
Design A has 16 logical qubits, 30 logical depth layers, and 18,000 two-qubit gates after compilation. Design B has 20 logical qubits, 38 depth layers, and 9,000 two-qubit gates after compilation. Design B is wider and deeper, but its lower two-qubit count may make it more attractive under a noise-sensitive objective. The correct choice depends on measured fidelity, connectivity, shot requirements, and the quality of the final observable—not on qubit count or depth in isolation.
Run both designs on the same simulator settings or hardware target, use the same shot budget, and compare uncertainty and useful output per unit of execution effort. This makes resource estimation part of experimental design rather than a last-minute cost check.
When to recalculate
Recalculate the worksheet whenever an input that affects execution changes. At minimum, revisit it in these situations:
- The backend changes: Connectivity, native gates, scheduling behavior, availability, and execution settings can alter the transpiled circuit.
- The compiler or SDK changes: A new transpiler release or optimization setting can change width, depth, gate counts, and circuit batching.
- The algorithm changes: Added ansatz layers, observables, ancilla qubits, gradient evaluations, or mitigation steps change the workload.
- The shot budget changes: A tighter confidence requirement can multiply total execution time.
- Pricing or provider accounting changes: Replace old assumptions with the provider's current documentation or account-level estimate before budgeting.
- Benchmarks move: Update measured shot duration, queue behavior, simulator memory use, and successful-job rates after a meaningful environment change.
Before each production run, save a compact execution plan: target backend, logical and physical qubit counts, logical and transpiled depth, two-qubit gate count, circuit variants, shots per variant, estimated active time, expected queue range, and contingency. Run a small pilot first, compare observed results with the worksheet, then revise the estimate before scaling.
This habit also makes framework comparisons more useful. Whether you are following a QAOA tutorial, testing a QML workflow, or learning how to build quantum circuits, the same questions apply: what is the compiled circuit, how many times will it run, and what evidence supports the runtime estimate? A repeatable worksheet will not eliminate uncertainty, but it will make that uncertainty visible and give you a practical basis for choosing a circuit design.
