Running on Real Quantum Hardware

Everything so far has run on AerSimulator, an ideal simulator with no imperfections. Real quantum computers are a different world: physical qubits are extremely sensitive to their environment, and every gate and measurement introduces a small amount of error.

Submitting a job to IBM Quantum

from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2 as Sampler

service = QiskitRuntimeService(channel='ibm_quantum', token='YOUR_IBM_QUANTUM_TOKEN')
backend = service.least_busy(operational=True, simulator=False)

sampler = Sampler(backend)
job = sampler.run([qc])
result = job.result()
print(result[0].data.meas.get_counts())

This needs a free IBM Quantum account, a real API token, and network access, so it's read-only here, sign up at quantum.ibm.com to run this yourself. service.least_busy(...) picks whichever real quantum backend currently has the shortest queue, since IBM's quantum hardware is a shared resource, your job runs alongside everyone else's.

Noise changes your results

On AerSimulator, the Bell state from earlier lessons gives only 00/11. On real hardware, you'll typically see a small number of 01/10 results too, not because the physics is wrong, but because of:

• Gate errors: a gate doesn't perfectly implement its ideal mathematical operation, there's always a tiny imprecision.
• Decoherence: a qubit's quantum state slowly degrades from interacting with its environment (heat, electromagnetic noise), the longer a circuit takes to run, the more this matters.
• Measurement errors: even reading out the final result isn't perfect, occasionally a 0 is misread as 1 or vice versa.

Queueing and cost

Unlike the instant local simulator, a real backend job joins a queue, and depending on the provider and plan, may have limits on how many you can run. This is why every lesson in this course develops and debugges on AerSimulator first, real hardware is where you verify a circuit you already trust, not where you iterate on it.