From Simulator to Real Hardware

After completing the Your First Qiskit Circuit tutorial on a simulator, the natural next step is running the same code on real quantum hardware. This transition reveals a lot about the practical realities discussed more abstractly throughout this site's Hardware Database.

What stays the same

Encouragingly, your actual circuit-building code barely changes. Continuing the Bell state example from our first tutorial:

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)
qc.h(0)
qc.cx(0, 1)
qc.measure([0, 1], [0, 1])

This circuit construction code is identical whether you're targeting a simulator or real hardware — the framework deliberately abstracts this away.

What changes: the backend

Instead of using AerSimulator(), you connect to real hardware through a cloud service:

from qiskit_ibm_runtime import QiskitRuntimeService

# Requires a free IBM Quantum account and API token
service = QiskitRuntimeService()
backend = service.least_busy(operational=True, simulator=False)

print(f"Running on: {backend.name}")

This connects to a real processor like those covered in our Hardware Database — possibly an IBM Heron or Condor-generation device, depending on what's available and least busy at the time.

Change 1: Queue times

Unlike a simulator, which runs instantly on your own computer, real quantum hardware is a shared, scarce resource. Your job joins a queue alongside other users' jobs, and execution can take anywhere from seconds to minutes (or occasionally longer), depending on demand.

Change 2: Noise in your results

This is the big one. Recall our simulator results were close to a perfect 50/50 split between '00' and '11', with almost no '01' or '10' outcomes. On real hardware, you'll typically see something like:

{'00': 467, '11': 471, '01': 34, '10': 28}

Those '01' and '10' results — which shouldn't theoretically occur for a perfect Bell state — are the direct, visible signature of decoherence and gate infidelity discussed throughout this site's Hardware Database — this is what "noisy" actually looks like in practice, not just an abstract concept.

Change 3: Circuit transpilation becomes more visible

Real hardware has specific qubit connectivity constraints. The transpilation step (converting your circuit into one compatible with the specific hardware's native gate set and connectivity) can meaningfully change your circuit's actual depth and structure:

from qiskit import transpile

# optimization_level controls how hard the compiler tries
# to minimize the resulting circuit's depth and gate count
transpiled = transpile(qc, backend, optimization_level=3)

print(f"Original depth: {qc.depth()}")
print(f"Transpiled depth: {transpiled.depth()}")

You may be surprised to see the transpiled depth is higher than your original circuit — a direct, hands-on encounter with the hardware-aware compilation challenges discussed in our Research Papers section.

Should you apply error mitigation?

For circuits beyond simple examples, applying error mitigation techniques (many built directly into modern Qiskit Runtime) can meaningfully improve result accuracy — though for a first Bell state experiment, you'll likely find the raw, unmitigated noise interesting and informative to see directly.

Managing expectations

A small two-qubit circuit like this one will generally still show recognizable, mostly-correct results on real hardware, despite the added noise. Larger, deeper circuits degrade much faster — which is exactly why current practical algorithms like VQE and QAOA are deliberately designed to use shallow circuits well-suited to today's NISQ-era hardware.

Frequently Asked Questions

Is real quantum hardware access free?

IBM and several other providers offer free tiers with limited access to real hardware, sufficient for learning and small experiments. Higher-volume or priority access typically requires a paid plan — check each provider's current offerings, since pricing and free-tier availability can change.

How much worse are results on real hardware compared to simulation?

It varies significantly by circuit depth and the specific hardware's current calibration — small, shallow circuits like the Bell state example here typically still show clearly recognizable results, while larger circuits can degrade substantially, directly illustrating the practical importance of the circuit depth concept.