Running on Real Hardware

This is the moment where theory meets physical reality. Up to this point, you have built circuits, simulated them noiselessly, and modeled their behavior under simulated noise. Now, you will learn how to execute your quantum programs on real, physical quantum processors located in IBM's quantum computation facilities. This is the ultimate goal of quantum programming: running code on a physical device that leverages the laws of quantum mechanics to perform computations.

Executing a program on real hardware is fundamentally different from running a local simulation. It requires authenticating with a cloud service, selecting an appropriate physical backend based on its topology and error rates, and transpiling your circuit to match the physical constraints of the selected chip. This transpilation step is critical, as physical qubits are not all connected to one another, and physical chips only support a limited set of native gates.

In this topic, you will master the complete workflow for running quantum programs on real hardware using Qiskit 1.x. You will learn how to use QiskitRuntimeService to manage your cloud connection, select the least busy physical backend, transpile your circuit into an Instruction Set Architecture (ISA) circuit, and execute it using the SamplerV2 primitive. You will analyze the physical results and compare them to your noiseless simulations.

Think of running a program on real quantum hardware like booking time on a multi-million dollar scientific instrument, such as an electron microscope or a particle accelerator. You don't own this instrument, and it doesn't sit on your desk. It is located in a secure, temperature-controlled facility, managed by a team of specialized engineers.

To use it, you must first log in and authenticate your account (using QiskitRuntimeService). Next, you must prepare your sample (transpile your circuit) so that it fits perfectly into the instrument's sample holder (the physical qubit coupling map). If your sample is too large or shaped incorrectly, the instrument cannot run it.

Once your sample is prepared, you submit it to the facility's queue. Your sample waits its turn, is loaded into the instrument, and is exposed to the physical sensors (executed for physical shots). Finally, the digital data captured by the sensors is sent back to your computer. The results will contain real physical noise, representing the actual state of the universe at the moment your experiment was run.

Running on real hardware in Qiskit 1.x requires a structured workflow. First, we authenticate using QiskitRuntimeService. Second, we select a physical backend. Third, we must transpile our circuit. Physical backends only support a specific set of native gates (the basis gates, typically $R_z$, $\sqrt{X}$, $X$, and CNOT or ECR) and have a specific physical layout (the coupling map).

Transpilation translates our high-level circuit into an Instruction Set Architecture (ISA) circuit that complies with these constraints. If our circuit applies a CNOT between two qubits that are not physically connected on the chip, the transpiler must insert physical SWAP gates to route the qubits next to each other, which increases circuit depth and introduces additional gate errors.

Here is the complete, standard Qiskit 1.x program to execute a Bell state on a real physical quantum processor:

from qiskit import QuantumCircuit
from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2 as Sampler

# Step 1: Initialize the runtime service
# This loads your saved credentials from disk
try:
    service = QiskitRuntimeService()
except Exception as e:
    print("Failed to load credentials. Ensure you have run save_account() first.")
    raise e

# Step 2: Select a physical backend
# We filter for operational, physical (non-simulator) devices
backend = service.least_busy(operational=True, simulator=False)
print(f"Selected physical backend: {backend.name}")

# Step 3: Build the logical circuit
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()

# Step 4: Transpile the circuit for the specific backend (Targeting ISA)
# We use optimization level 1 for standard compilation
pm = generate_preset_pass_manager(backend=backend, optimization_level=1)
isa_circuit = pm.run(qc)
print("Circuit successfully transpiled to hardware ISA.")

# Step 5: Execute the job using the Sampler primitive
sampler = Sampler(backend)
print("Submitting job to physical hardware queue...")
job = sampler.run([isa_circuit], shots=1024)

# Retrieve the Job ID for tracking
job_id = job.job_id()
print(f"Job submitted! ID: {job_id}")
print("Waiting for results (this may take time depending on the queue)...")

# Step 6: Retrieve and print results (blocking call)
result = job.result()
pub_result = result[0]
counts = pub_result.data.meas.get_counts()
print("\nPhysical Hardware Execution Results:")
print(counts)

In this code, generate_preset_pass_manager creates a compilation pipeline tailored to the selected physical backend. The resulting isa_circuit is passed to Sampler(backend). The execution is managed by IBM's cloud runtime, which optimizes execution speed and automatically applies readout error mitigation.