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 physical quantum processor. The choice is frequently presented as a matter of preference, or as a progression in which the QPU is the destination and the others are waiting rooms. Neither framing survives contact with the numbers. The three are answering different questions, and the figures below come from our own runs across all three tiers rather than from vendor literature.

The distinction that resolves most confusion

A CPU and a GPU are both classical processors executing the same arithmetic; a GPU does it with more parallel lanes. A QPU is not a faster classical processor. It is a physical apparatus whose observable behaviour is the result.

This has a consequence people find counterintuitive: at every size a classical machine can reach, the classical machine gives the *better* answer, because it gives the noise-free one. A QPU at 20 qubits does not compute anything a laptop cannot compute exactly and more quickly. What it provides is evidence about a physical device. If the question is what a quantum algorithm outputs, simulate. If the question is what a particular piece of hardware does when asked to run that algorithm, use hardware. Conflating these two questions is the most expensive error available in this field.

CPU: the default, and more capable than qubit count suggests

CPU simulation is correct whenever the representation fits in memory, and it fits more often than raw qubit count implies, because the relevant variable is circuit structure rather than width.

• Exact statevector, to roughly 32 qubits: milliseconds to seconds, exact to floating-point precision.
• Clifford circuits: thousands of qubits, exact, effectively free. Error-correction and stabilizer work lives here.
• Structured circuits via tensor networks: 50 to 128 qubits in seconds when entanglement stays modest, which covers most QAOA, VQE and Trotterised dynamics workloads.
• Shallow circuits via Pauli propagation: expectation values on hundreds of qubits.

Our benchmark suite makes the range concrete. Every row 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, indicating the compression captured the state. None of these circuits used a GPU, a cluster, or any quantum hardware.

GPU: throughput, not additional qubits

A persistent misconception holds that GPUs unlock substantially more qubits. They do not. The constraint is memory, and the requirement is 16 x 2^n bytes regardless of which processor holds it. An 80 GB datacentre GPU reaches 32 qubits; a 141 GB card reaches 33. Against a well-provisioned CPU machine that is a gain of two or three qubits, which the exponential erases immediately.

Device memory   Exact statevector ceiling
       16 GB    29 qubits
       24 GB    30 qubits
       80 GB    32 qubits
      141 GB    33 qubits

What a GPU provides is speed, roughly 10 to 50 times faster on the dense linear algebra behind statevector updates and tensor contractions. That matters when many circuits run in sequence rather than when one circuit runs large: parameter sweeps, QML training loops, batched noise studies, and above all variational optimisation, where a single 150-iteration SPSA run is 301 separate circuit evaluations. At roughly $3 per GPU-hour with per-second billing, a 20-minute sweep costs about a dollar.

Two production runs illustrate both halves of that statement. An 8-qubit GHZ 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 completed exactly in 8.2 seconds. The GPU did not change either answer. It moved the memory ceiling out by a few qubits and returned the result faster, which is precisely its role.

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

The corollary is that a GPU is the wrong purchase for a qubit-count problem and the right one for an iteration-count problem. Most people who want more qubits need a different method, not a different processor.

QPU: physics, not compute

Real hardware is not a faster simulator. At accessible sizes it is slower, noisier and more expensive: $0.30 per task plus per-shot fees, plus a queue measured in minutes to hours. What it uniquely provides is physical reality.

Hardware spend is justified in three cases, and it is worth being strict about them.

• Measuring algorithmic degradation under genuine device noise. A depolarizing model in a simulator is an approximation of a device's actual error process, which includes crosstalk, leakage, drift and correlated errors that no simple model captures. When the noise itself is the object of study, only the device will do.
• Error-correction experiments requiring physical qubits by definition. A logical qubit's performance is a claim about hardware.
• Circuits whose entanglement structure defeats every classical method, a condition that should be verified rather than assumed, since the verification is cheap and the assumption is not.

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 intended to be. What they provide is the measured noise behaviour of two qubit technologies, reported as raw counts against an exact reference. The technologies themselves are compared in Transmon or trapped ion?.

The decision procedure

Four questions settle the choice, in order.

• Is the question about an algorithm or about a device? About a device: QPU. About an algorithm: classical, and the remaining questions apply.
• What structure does the circuit have? Clifford implies stabilizer simulation at any width. Bounded entanglement implies tensor networks. Shallow with an expectation-value target implies Pauli propagation. None of the above, under 32 qubits, implies exact statevector. None of the above, over 32 qubits, is the genuine frontier and is discussed in The 34-qubit wall.
• One circuit or many? Many, particularly under an optimizer, is the GPU case. One large circuit is not.
• Does the result carry an error bound? Statevector and stabilizer results are exact. Tensor-network and Pauli-propagation results are approximate and must arrive with a computed bound, or they are not usable as evidence.

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

What this implies for a research budget

A workflow following this progression treats simulation and hardware as complementary rather than competing. Simulators establish what a QPU run should produce, which is the only way to know whether the QPU run succeeded; QPU runs ground the simulation in physical behaviour the model omits.

For most research programmes in 2026 the resulting QPU share of total spend is under 10 percent. That figure is not a recommendation to avoid hardware. It is a consequence of hardware being the right instrument for a narrow and well-defined set of questions, and the wrong one for everything else. It is also why hardware here is passed through at provider cost with no markup: a platform that profits from hardware routing has an incentive to route work there, and that incentive should not exist.

The complete run logs behind every number above, including the exact circuits and their costs, are published in the SDK documentation.