Choosing between a quantum simulator and real quantum hardware is a resource decision as much as a technical one. This guide explains what each environment can tell you, how to estimate cost and usefulness, and how to move from local validation to carefully selected hardware runs without treating noisy output as a simple pass-or-fail result.
Overview
A simulator executes a quantum circuit on classical computing infrastructure. Real hardware executes it on a quantum processing unit (QPU), where calibration conditions, connectivity, gate errors, measurement errors, and queue behavior can affect the result. Neither option is universally better. The right choice depends on the question your experiment is asking.
Use an ideal simulator when you need a clean mathematical reference, fast debugging, deterministic tests, or a way to verify that circuit construction and classical post-processing are correct. Use a noisy simulator when you want to study how an assumed error model may change the output before committing to hardware. Use real hardware when the experiment specifically requires evidence from a physical QPU, such as a hardware benchmark, an investigation of device behavior, or a comparison of mitigation and compilation strategies.
The practical pattern is usually sequential: develop and test locally, compare ideal and noisy results, reduce the circuit to a meaningful experiment, and then submit only the jobs that answer a hardware-specific question. This approach is consistent with a broader quantum development workflow. For CI and regression testing, see Quantum Workloads in CI/CD. For circuit size and runtime planning, see Quantum Circuit Resource Estimation.
| Factor | Ideal simulation | Noisy simulation | Real hardware |
|---|---|---|---|
| Accuracy target | Ideal mathematical behavior | Behavior under an assumed noise model | Observed behavior of a physical device |
| Noise | Excluded unless deliberately modeled | Specified by the model and its parameters | Device-dependent and potentially variable |
| Reproducibility | High, especially with fixed seeds and shots | High when the model and seeds are fixed | Requires careful recording of backend and run conditions |
| Cost | Usually local compute or simulator usage | Local compute or provider simulator usage | May include access, execution, queue, or shot-related costs |
| Best use | Debugging, unit tests, baselines | Robustness studies and pre-hardware screening | Hardware validation and device experiments |
How to estimate the right execution path
Start by writing down the decision the experiment must support. “Does the circuit produce the expected state in an ideal model?” is a simulator question. “How does this circuit behave after compilation to a particular QPU?” is a hardware question. A vague goal often leads to unnecessary hardware jobs.
Estimate the workload with five quantities:
- Circuit count: How many unique circuits will you run, including parameter sweeps, controls, and calibration variants?
- Shots per circuit: How many repeated measurements are required to estimate the observable or distribution with useful uncertainty?
- Iteration count: Will a classical optimizer submit a new batch after each result?
- Compilation and orchestration overhead: Will transpilation, queueing, batching, retries, or post-processing add time or usage?
- Hardware-specific value: What information cannot be obtained from an ideal or noisy simulator?
A simple planning estimate is:
Total shots = unique circuits × shots per circuit × iterations.
This is not a provider invoice. It is a workload estimate that helps you compare alternatives. A simulator may be limited by memory, processor time, or the number of qubits it can represent. A hardware run may be limited by backend availability, maximum circuit dimensions, queue behavior, execution rules, or account-specific pricing. Confirm those details in the selected provider’s current documentation before budgeting.
For a cloud comparison, separate fixed and variable elements. Fixed elements can include account, workspace, or access requirements. Variable elements can relate to simulator runtime, hardware execution, shots, or other provider-defined units. Because these models change, record the date, provider, backend, region where relevant, pricing page, and assumptions used in your estimate. The Quantum Cloud Computing Cost Guide provides a useful framework for comparing access, simulators, and hardware runs.
Inputs and assumptions
A credible simulator-versus-hardware comparison depends on more than qubit count. Capture the following inputs in a run manifest or notebook:
- Logical circuit: Number of qubits, gate types, depth, measurements, and parameter values.
- Compiled circuit: Physical qubit mapping, added routing operations, transformed gates, and final depth. Hardware cost and accuracy may depend more on this version than on the original circuit.
- Shot count: The number of samples per circuit. More shots can reduce sampling uncertainty but increase runtime or usage.
- Noise assumptions: For a noisy simulator, identify whether the model includes gate, readout, relaxation, decoherence, or connectivity effects. Treat the model as an approximation, not a prediction of every hardware result.
- Observable and success metric: Define whether you are comparing bitstring probabilities, expectation values, fidelity-like measures, classification accuracy, energy estimates, or another metric.
- Repetition and randomness: Record random seeds for simulation, optimizer settings, initialization, and any resampling procedure.
- Backend conditions: Record the provider, backend, compilation settings, queue submission time, calibration information when exposed, and job identifier.
Keep ideal, noisy, and hardware outputs separate. An ideal result is a baseline, not a target that hardware must reproduce exactly. A noisy-simulation result is useful only relative to the assumptions in its model. Hardware output includes sampling variation and device effects, so compare distributions or confidence intervals where appropriate rather than relying on one measured bitstring.
When selecting a backend, review connectivity, supported operations, available qubits, circuit-depth limits, measurement capabilities, and execution constraints. The guide on choosing a quantum computing backend can help turn those requirements into a selection checklist. Security and location requirements may also affect a cloud design; see Quantum Cloud Data Residency and Security.
Worked examples
Example 1: Circuit development
Suppose a developer is building a small variational circuit and has 40 parameter settings, 2,000 shots per setting, and 10 optimization rounds. The planning estimate is 40 × 2,000 × 10 = 800,000 shots. Sending every iteration to hardware may be expensive, slow, or difficult to reproduce. A better first stage is to test the circuit structure and optimizer on an ideal simulator, then run a noisy simulation to identify whether the objective is likely to become unstable. Only a reduced set of parameter settings or final candidates should move to hardware.
Example 2: Hardware benchmarking
Suppose the goal is to compare two compilation strategies on a selected QPU. An ideal simulator can verify that both compiled circuits represent the same logical operation. A noisy simulator can provide a controlled sensitivity study. Neither replaces the hardware experiment, because the question concerns the effect of a physical device and its compilation path. Run matched circuits with the same shot plan, record backend metadata, and repeat enough times to distinguish a meaningful change from ordinary sampling variation.
Example 3: A quantum machine learning prototype
For a small quantum machine learning workflow, begin with a classical baseline and an ideal circuit simulation. If the model cannot learn or produce a useful signal in the ideal case, hardware noise is unlikely to solve the underlying design problem. Next, use a noise model or deliberately simplified circuit to test sensitivity. Hardware becomes justified when it can answer a defined question about trainability, device execution, or a hardware-aware method—not merely because the prototype is ready to submit.
When to recalculate
Recalculate the simulator-versus-hardware plan whenever a workload input changes. The most important triggers are a new circuit depth, a larger parameter sweep, more shots, additional optimizer iterations, a different compilation target, or a change in the success metric. Also recalculate after provider pricing, access rules, backend limits, simulator capabilities, or queue behavior changes.
For repeatable projects, keep a small comparison worksheet with these columns: date, provider, simulator or backend, circuit count, compiled depth, shots, iterations, estimated usage, observed runtime, result metric, and decision. Review it before each hardware submission. If observed runtime or output quality differs materially from the estimate, update the assumptions rather than simply increasing the budget.
A practical decision checklist is:
- Can the question be answered with an ideal simulator? If yes, start there.
- Does the result depend on plausible noise? If yes, add noisy simulation with documented assumptions.
- Does the question require physical-device evidence? If no, hardware may not yet be justified.
- Have you reduced the circuit, selected a backend, and estimated total shots and iterations?
- Can you reproduce the baseline and compare outputs using a defined metric?
- Have you checked current provider documentation for pricing, limits, access, and queue conditions?
The most reliable workflow is not simulator versus hardware as a permanent choice. It is a controlled progression from ideal correctness, to modeled robustness, to targeted physical measurement. Revisit the estimate whenever the circuit, provider, or experiment goal changes, and treat every hardware job as a deliberately designed measurement rather than the default next step.
