CPU vs GPU vs Real QPU: Choosing the Right Backend for Quantum Circuits

Every quantum job faces the same three-way choice: classical CPU, classical GPU, or a real quantum processor. The choice is often presented as a matter of preference. It is better understood as an engineering decision with clear rules. The figures in this article are taken from our own test runs across all three tiers, so each tradeoff is stated in measured numbers rather than in the abstract.

CPU: the default, more capable than qubit count suggests

CPU simulation is the right choice whenever the state fits in memory, and it fits more often than raw qubit count implies.

• Exact statevector, to roughly 32 qubits: milliseconds to seconds.
• Clifford circuits (error-correction work, stabilizer states): thousands of qubits, effectively free.
• Structured circuits via tensor networks: 50 to 128 qubits in seconds, when entanglement stays modest, which covers most QAOA, VQE, and dynamics workloads.

Cost in this regime is cents at most, and latency is sub-second for small jobs on a warm service. A well-designed router defaults here automatically.

Our own benchmark suite makes the range concrete. Every row below was produced on a single consumer laptop (Intel i7-12700H, 32 GB RAM) with the GPU switched off, so it represents a floor rather than a ceiling:

Circuit                Qubits   Engine (auto)   Wall time   Accuracy
GHZ (Clifford)          5,000   clifford        0.56 s      exact
QAOA MaxCut, p=3          100   mps.quimb       5.9 s       converged (dev 0.0)
Layered ansatz            80   mps.quimb       4.3 s       converged (dev 0.0)
Exact statevector         26   exact.cpu       2.7 s       exact

The router selected each engine from the circuit's structure, and every approximate result carried a convergence check: the run was repeated at double the bond dimension, and the top outcome probabilities did not move, which indicates the compression captured the state. None of these circuits used a GPU, a cluster, or any quantum hardware.

GPU: throughput, not additional qubits

A common misconception holds that GPUs unlock substantially more qubits. They do not, by much: GPU memory caps exact statevector work around 35 to 36 qubits, only a few qubits past a well-provisioned CPU machine. What a GPU provides is speed, roughly 10 to 50 times faster on the dense linear algebra behind statevector updates and tensor contractions. That advantage matters when many circuits run in sequence: parameter sweeps, QML training loops, batched noise studies. At roughly $3 per GPU-hour with per-second billing, a 20-minute sweep costs about a dollar.

Two runs on our production GPU tier illustrate both halves of that statement. An 8-qubit GHZ state at 1,000 shots returned the expected near-even split (502 all-zeros against 498 all-ones, textbook shot noise around the ideal 500/500) in about half a second. A 32-qubit GHZ at 100 shots held a full 64 GiB statevector, larger than a 32 GB laptop can allocate, and still completed exactly in 8.2 seconds. The GPU did not change the answer. It moved the memory ceiling out by a few qubits and returned the result faster, which is precisely the role it plays.

Circuit           Qubits   Shots   Wall time   Result
GHZ (exact.gpu)        8    1,000   0.5 s       502/498, ideal 500/500
GHZ (exact.gpu)       32      100   8.2 s       52/48; full 64 GiB statevector

QPU: physics, not compute

Real hardware is not a faster simulator. At accessible sizes it is a slower, noisier, and more expensive one, roughly $0.30 per task plus per-shot fees, plus queue time. What it uniquely provides is physical reality. Hardware spend is justified in three cases: measuring how an algorithm degrades under genuine device noise, error-correction experiments that require physical qubits by definition, and frontier-scale circuits whose entanglement no classical method compresses, after that condition has been verified rather than assumed.

The same GHZ family, run on two real devices, shows what that reality looks like. On a Rigetti Cepheus superconducting processor, a 3-qubit GHZ at 50 shots returned 45 shots in the two ideal GHZ states and 5 in bit-flipped states (the physical signature of device noise), after roughly 53 minutes in the scheduled queue. On an IonQ Forte-1 trapped-ion processor, a 2-qubit GHZ at 100 shots returned 98 shots in the ideal outcomes and 2 in error, after about 5 hours queued. Neither run was faster or cheaper than the simulator, and neither was meant to be. What they provide is the measured noise behavior of two different qubit technologies, reported as raw counts against an exact reference.

Stage                     Backend            Typical size       Purpose
Develop and debug         CPU (exact)        10-25 qubits        correctness
Scale structurally        CPU/GPU (MPS)      60-100+ qubits      convergence checks
Parameter sweeps          GPU                any (batched)       throughput
Noise / hardware study    QPU                as needed           physical reality

A workflow that follows this progression treats simulation and hardware as complementary rather than competing: simulators verify what a QPU run should produce, and QPU runs ground the simulation in physical reality. For most research programs in 2026, the resulting QPU budget share is under 10 percent, which is why hardware here is passed through at cost with no incentive to route work toward it unnecessarily. The complete run logs behind every number above, including the exact circuits and their costs, are published in the SDK documentation.