Practical guide to running quantum circuits online: from local simulators to cloud QPUs

Practical guide to running quantum circuits online: from local simulators to cloud QPUs

This step-by-step walkthrough helps developers choose between quantum simulators and cloud QPUs, submit jobs, interpret results, and integrate outputs into real applications. It includes reproducible examples using common quantum developer tools such as Qiskit and Cirq, and practical notes on noise mitigation techniques.

Why choose local simulators or cloud QPUs?

Decision factors for where to run circuits:

• Scale: local simulators are best for small systems (up to ~30 qubits with statevector simulators, or more with specialized methods).
• Fidelity: cloud QPUs expose real hardware noise; use them to validate noise-aware algorithms or benchmark.
• Latency and cost: simulators are often faster and free; cloud QPUs incur queue time and usage costs.
• Reproducibility: simulators give deterministic behavior given seeds; cloud QPUs require calibration data to interpret variability.

Quick decision checklist

1. Prototype algorithm? Start with a local simulator.
2. Need to measure hardware noise or run experiments under real constraints? Move to a cloud QPU.
3. Require many independent randomized trials? Use simulators to iterate, then sample on hardware for final validation.

Example 1 — Qiskit: local simulator then IBM cloud QPU

This example shows a simple Bell state run locally using Qiskit Aer simulator and then how to submit to an IBM cloud backend. Install qiskit and ibm_provider before running.

from qiskit import QuantumCircuit, transpile
from qiskit.providers.aer import AerSimulator
from qiskit_ibm_provider import IBMProvider

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

# Run locally on Aer
sim = AerSimulator()
qc_sim = transpile(qc, sim)
job_sim = sim.run(qc_sim, shots=1024)
result_sim = job_sim.result()
counts_sim = result_sim.get_counts()
print('Local counts:', counts_sim)

# Run on IBM cloud provider (authenticate first with IBM account token)
provider = IBMProvider()  # assumes prior login with ibm_token
backend = provider.get_backend('ibmq_qasm_simulator')
qc_qc = transpile(qc, backend)
job_cloud = backend.run(qc_qc, shots=8192)
result_cloud = job_cloud.result()
counts_cloud = result_cloud.get_counts()
print('Cloud counts:', counts_cloud)

Notes: replace provider instantiation with your credential method. For real QPUs choose an actual hardware backend; expect additional noise and queue time.

Example 2 — Cirq: local simulator and cloud guidance

Run the same Bell circuit in Cirq locally. Cirq can also target cloud engines such as Google Quantum Engine; authentication and API setup vary by provider.

import cirq

# Build circuit
q0, q1 = cirq.LineQubit.range(2)
circuit = cirq.Circuit(cirq.H(q0), cirq.CX(q0, q1), cirq.measure(q0, q1))

# Local simulator
sim = cirq.Simulator()
result = sim.run(circuit, repetitions=1000)
print(result.histogram(key='q0,q1'))

To run on a cloud service, consult the target provider's Cirq integration and ensure proper credentials. For example, Google Quantum Engine requires a Cloud project, billing, and the quantum API enabled.

Interpreting results and handling noise

When you get results from simulators versus hardware, treat them differently:

• Simulators: counts reflect the ideal circuit (modulo pseudo-random seeds for shot noise).
• Hardware: counts reflect device errors—readout errors, gate errors, decoherence, and cross-talk.

Practical noise mitigation techniques:

• Measurement error mitigation: calibrate a readout matrix and invert it to correct observed counts.
• Zero-noise extrapolation: run circuits with artificially amplified noise (repeat gates) and extrapolate back to zero noise.
• Symmetry verification: use conserved quantities to post-select valid measurement outcomes.
• Repeat experiments across calibration windows and average results to reduce run-to-run variance.

Integrating results into applications

Common pattern: submit job -> wait or poll -> fetch results -> post-process -> store/serve. Example JSON packaging:

# Pseudocode for packaging
payload = {
  'job_id': job_cloud.job_id,
  'backend': backend.name,
  'counts': counts_cloud,
  'calibration': calibration_info
}
# store payload in database or send to REST API

Tips for production integration:

• Use asynchronous job management: don't block threads while waiting for hardware queues.
• Record backend calibration metadata (T1, T2, readout error) alongside results for reproducibility.
• Cache simulator results to speed development and save cloud credits.

Reproducibility and testing

To make experiments reproducible:

• Version-control your circuits and transpilation configuration.
• Record random seeds used by simulators.
• Store backend calibration snapshots and the exact backend name and date.

Further reading and related topics

Explore our related pieces on how quantum computing fits into broader tech trends, like Next-Gen Networking and Quantum Computing and how AI intersects with quantum tooling in The Quantum Shift in AI Development. For deep dives on talent and market dynamics see Talent Wars in Quantum Tech.

Running quantum circuits online is a practical blend of choosing the right platform for the problem, validating with simulators, and confirming behavior on hardware with good calibration and mitigation. Use the examples above as templates and adapt them to your cloud provider, CI pipeline, and application stack.