Concept 6 of 7 · The real-world pattern

Simulator vs QPU

Nobody runs full VQE on a real QPU today. The pattern is train on a simulator, validate on the QPU — find the optimal parameters classically, then evaluate the final energy once on real hardware to see how much noise costs you.

Train on the simulator to find θ*, then spend a single QPU job validating that one point. The gap ΔE is the lumped cost of real hardware.

What it actually means

Running a full VQE on a real QPU today is almost always a bad idea. Here’s the math:

A 6-qubit VQE with 60 parameters and a reasonable optimizer needs ~2000 cost-function evaluations to converge.
Each evaluation on a real QPU is ~10 seconds (queue + transpile + run + measurement).
Total: ~5.5 hours of QPU time per VQE run.
IBM Open plan free tier: 10 minutes per month.

You can do the arithmetic. Even with paid access this is a poor use of expensive hardware. And worse, the optimizer can be confused by shot noise — making it slow to converge or settle at a wrong answer.

The pragmatic pattern that the field has converged on:

Train on the simulator. Aer gives noiseless, fast cost evaluations. Run the full VQE loop, get the optimal parameters θ*.
Submit a single QPU job at θ = θ*. “Single” here means one parameter configuration, not one measurement shot — the energy estimate at θ* is built from many shots (typically thousands per Pauli term, batched). You get back E_qpu(θ*).
Compare to E_sim(θ*). The gap ΔE = E_qpu(θ*) − E_sim(θ*) is the total impact of running on noisy hardware at that parameter setting. That ΔE is itself a composite — it includes shot noise (statistical), readout error (qubit-flip on measurement), gate errors (compounded across the circuit depth), transpilation effects (gate mapping changes the noise profile), and any backend drift between calibration and execution. Pulling those apart requires extra runs (calibration circuits, repeated submissions); the headline ΔE is just the lumped sum.

This gives you a credible “ran on real hardware” claim and a meaningful result, without burning QPU minutes on optimizer iterations that the classical simulator can do for free.

What about error mitigation?

Even a single-shot measurement on a noisy chip gives a biased energy. Error mitigation is a family of techniques to reduce that bias without needing full error correction. The main ones:

Technique	How it reduces bias
TREX	Twirled Readout Error eXtinction — corrects measurement errors by deliberately scrambling and unscrambling readouts.
ZNE	Zero-Noise Extrapolation — runs the circuit at deliberately increased noise levels, then extrapolates back to zero noise.
M3	Matrix-free Measurement Mitigation — fixes readout errors using a calibration matrix.
PEC	Probabilistic Error Cancellation — the most powerful and most expensive: samples from a quasi-probability distribution that exactly cancels noise on average.

Each technique trades extra QPU shots for less biased energies. For demonstrations a 2–5× overhead from ZNE is reasonable. The Open plan free tier doesn’t really give you room for this; a paid plan does.

qiskit-ibm-runtime’s EstimatorV2 exposes mitigation via options:

from qiskit_ibm_runtime import EstimatorV2

estimator = EstimatorV2(mode=backend)
estimator.options.resilience_level = 2   # adds TREX + ZNE
estimator.options.default_shots = 4096

That’s it. Toggling a number turns mitigation on. The added cost is shots, not code complexity.

In this repo

The WH⁻ validation wires ZNE in directly — run python scripts/wh_qpu_validation.py qpu --mitigation zne. See Concept 7 — Error mitigation for how ZNE attacks bias (the part more shots can’t fix) and what to realistically expect from it.

Why it matters for our problem

In 01_hello_quantum.ipynb we already ran a Bell state on ibm_marrakesh and saw the noise signature (2.7% of shots came out wrong). That’s measurement noise on a 1-layer circuit.

02_h2_binding.ipynb and 03_wh_binding.ipynb both follow the train-then-validate pattern, and both validations were run on real IBM Quantum hardware on 2026-05-28 (ibm_marrakesh for H₂, ibm_fez for WH⁻; details in the README).

Read this caveat first

The unmitigated WH⁻ hardware noise exceeded the well depth the simulator computed. The bare QPU energy at θ* sits well above the dissociation asymptote, which means it is physically uninformative as a binding-energy estimate. The WH⁻ run’s value is as a noise-scaling data point on a real chemistry circuit, not as a chemistry result.

With that frame: the two ΔE values quantified the lesson this primer predicted — noise at the WH⁻ circuit depth (EfficientSU2 reps=4 with full entanglement, ≈ 30-layer circuit, ~100 two-qubit gates after transpilation) is ~6.5× larger than at H₂’s shallower depth on the same generation of hardware. That is the expected NISQ-era lesson, and it’s why mitigation (and ultimately fault tolerance) matter at this scale.

of Bell-state shots came out wrong (1-layer circuit)

two-qubit gates in the WH⁻ circuit after transpilation

more hardware noise at WH⁻ depth than at H₂ (same hardware generation)

When fault-tolerant hardware arrives, this two-phase pattern collapses into a single phase: full VQE (or its FT-era successor QPE) runs on the QPU end-to-end, and classical simulators become development tools, not runtime participants.