Quantum simulator vs real IBM hardware: what changes, what doesn't

Open any quantum SDK tutorial and the first thing you'll run is a Bell pair on a simulator. Two qubits, one Hadamard, one CNOT, measure both. You get a perfect 50/50 split between 00 and 11 — exactly the textbook answer.

Then you run the same circuit on real hardware — IBM's ibm_fez or ibm_kingston, both 156-qubit Heron processors — and the counts look like this instead:

00 → 48.6%
11 → 47.9%
01 →  1.8%
10 →  1.7%

Two new outcomes appeared. The split between 00 and 11 is no longer exactly 50/50. The first instinct is usually: "the hardware got it wrong." That instinct is wrong.

The simulator is the lie, not the hardware

A noiseless state-vector simulator is a model of a perfect quantum computer that doesn't exist. Every real qubit interacts with its environment. Every gate has a finite fidelity. Every measurement has readout error. Those interactions don't make the answer wrong — they make the answer device-characteristic. The conclusion (these two qubits are entangled, you see anti-correlated outcomes far more often than uncorrelated ones) holds. The counts just live on a different probability cloud.

That's the framing we use across every tool on Quantum Gap AI: same conclusion, device-characteristic noise. We don't claim identical raw counts across backends, because that would be a lie. We claim that the decoded answer — "the molecule's ground-state energy is −1.137 Hartree", "the optimal route visits these cities in this order", "the option is worth $4.82 ± $0.06" — comes out the same in a way you can act on.

Where the noise actually comes from

There are four sources worth understanding:

1. Single-qubit gate error — typically 10⁻⁴ per gate on Heron. Negligible per gate, accumulates over circuits with hundreds of gates.
2. Two-qubit (CNOT / ECR) gate error — typically 5×10⁻³. This is the budget item. If your circuit has 200 two-qubit gates, you have a non-trivial probability of at least one of them firing wrong.
3. Decoherence (T1, T2) — qubits forget. T1 around 150 μs, T2 around 100 μs on current Heron. If your circuit runs longer than that, fidelity falls off a cliff.
4. Readout error — typically 1–2% per qubit. A qubit that's in 1 sometimes reports as 0 and vice-versa.

The 01/10 counts in the Bell pair example above are mostly readout error — about 1.5% per qubit, which agrees with what the device reports in its daily calibration.

What this means in practice

For people running tools on the platform:

• Prototype on the simulator. It's free, instant, and tells you whether your circuit makes sense. If it doesn't work on the simulator, the hardware won't save it.
• Promote to hardware when you want the calibrated answer. "Calibrated" here means: the result reflects how a real quantum processor actually behaves on this problem, including its noise. For a research paper, a procurement decision, or a benchmark, this is the number that matters.
• Run multiple backends if you need cross-device evidence. For every paid challenge we submit, we run the canonical job on ibm_fez and then re-run on ibm_kingston. The raw counts differ; the conclusion is the same. That's the signal.

One number that matters: shots

More shots → tighter error bars on the measured probabilities. The relationship is the boring one from statistics: σ ≈ √(p(1−p)/N). At 1024 shots, a true 50/50 distribution has roughly a ±1.5% standard error on each outcome — which is exactly what you see in the Bell-pair counts above. Doubling shots cuts the error bar by √2, not 2. You can buy precision, but you pay linearly in QPU seconds for square-root improvements. That trade-off is why every tool on this site lets you set shots explicitly.

The "did it actually run?" test

Every hardware run on Quantum Gap AI returns a provider job ID. You can look it up in IBM Quantum's job dashboard, see the queue time, see the calibration data for the backend at the moment your circuit ran, and download the raw provider response. We embed those job IDs in every audit report. If anyone asks "did this actually run on hardware?" the answer is one URL click.

Try it yourself

The simulator runs are free. Sign in, pick the Bell-pair tool from the catalog, set shots to 1024, and run it once on the simulator and once on ibm_fez. The two distributions will tell the story this article tried to.