CPU vs GPU vs TPU vs QPU: Choosing a Quantum Backend

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.cpu   5.9 s       converged (dev 0.0)
Layered ansatz             80   mps.quimb.cpu   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.

TPU: the one that does not belong here

Any comparison of processor types written for a general audience lists four: CPU, GPU, TPU, QPU. Three of them belong together and one does not, and it is worth saying which, because the grouping is a habit of vocabulary rather than a technical fact.

A Tensor Processing Unit is an application-specific chip Google designed for neural networks, available by the hour on their cloud and not sold. Where a GPU is a general parallel processor that turned out to suit machine learning, a TPU is built for the one operation that dominates it: large matrix multiplication, executed on a systolic array that streams operands through a grid of multiply-accumulate units rather than round-tripping them to memory between steps. That single specialisation is where the efficiency comes from, and it is also the whole limitation.

The decisive detail for our purposes is precision. TPUs are optimised for reduced-precision formats, bfloat16 and int8, because a neural network's accuracy survives a truncated mantissa: the network was fitted to noisy data and its output is a probability, so a fractionally wrong weight changes nothing that matters. Statevector simulation is the opposite case. It carries 2^n complex amplitudes whose relative phases are the entire content of the calculation, accumulating error over every gate, and the quantity we ultimately publish is a bound on how far the answer sits from the truth. A chip engineered to be approximately right is a poor instrument for work whose product is a measured error.

              Built for                     Arithmetic         Fit for statevector
CPU           anything                      fp32/fp64 complex  yes, the reference
GPU           dense parallel linear algebra fp32/fp64 complex  yes, 10-50x faster
TPU           neural network matmul         bfloat16/int8 real poor: wrong precision
QPU           nothing classical can do      not applicable     a different question

None of this makes the TPU a lesser chip. It is extremely good at the thing it exists for, and a comparison that treats all four as interchangeable options for the same job is still answering a question nobody has.

What changed: we now run a TPU engine, and the argument above is why

When this post was written it ended by saying this service offers CPU and GPU engines and no TPU engine. That is no longer true, and the reason is more interesting than a simple reversal: nothing above turned out to be wrong. A TPU is still a poor statevector machine for exactly the reasons given, and we do not run statevector simulation on one. What we found was a different method that wants precisely what a TPU is good at.

A neural network quantum state represents the wavefunction as a neural network and optimises it by variational Monte Carlo. The inner loop is not a complex statevector being contracted; it is dense matrix multiplication against batches of sampled spin configurations, which is the workload a TPU was built for. It also reaches somewhere the other classical engines cannot: tensor networks assume entanglement follows an area law, and a state that breaks that assumption is where an MPS gives up and a neural ansatz keeps going.

The precision point in this post was not academic, either. We hit it directly, as a hard refusal from the hardware: `Element type C128 is not supported on TPU`. The engine narrows to complex64 there and records on the certificate that it did, because reduced precision moves the variance floor, and a variance sitting at the arithmetic floor must not be read as a converged ground state. The chip's reduced-precision bias is real; it is survivable for this method and would not be for a 30-qubit statevector.

A measured run, so the claim is checkable. An 8-spin transverse-field Ising ring on one Cloud TPU v5e chip: 60.4 seconds of variational Monte Carlo, three independent restarts agreeing to 1.1e-3, Gelman-Rubin R-hat of 1.0014. It returned a ceiling of -10.2499758 on the true ground-state energy, and the exact answer for that Hamiltonian is -10.2516623, so the ceiling holds. The point estimate itself landed 0.00063 BELOW the exact value, which is 1.4 standard errors of ordinary Monte Carlo noise and is why the certified claim is the ceiling rather than the estimate.

So the four-way comparison resolves differently than it first appears. CPU, GPU and TPU are classical processors differing in how they parallelise arithmetic, and the QPU is not a processor in that sense at all. But which classical chip suits you is decided by the METHOD, not by the chip: a statevector wants a GPU, a stabilizer circuit wants a CPU, and a neural wavefunction wants a TPU. Asking which chip is fastest, without naming the method, remains the wrong question.

The useful way to read the four is that the first three are classical processors differing in how they parallelise identical arithmetic, and the fourth is not a processor in that sense at all.

Click to enlarge

Close

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

Once the tier is settled, the per shot cost calculator turns it into a number for your own workload.

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.

Common questions

Is a QPU faster than a CPU?

Not in the sense the question implies, and for most work the CPU wins outright. A QPU is not a faster classical processor, it is a different kind of device. For a circuit under about 30 qubits a CPU returns an exact, noise-free answer in seconds for $0.001, while a hardware run costs a $0.30 task fee before a single shot and comes back with counts shaped by gate and readout error. The QPU is faster at nothing a simulator can already do; it is the only option when the question is about the device itself rather than about the algorithm.

What is the difference between a CPU, a GPU and a QPU?

A CPU and a GPU are both classical processors running the same arithmetic, and a GPU simply runs more of it in parallel. A QPU is different in kind: it holds physical qubits and returns measured samples rather than computed numbers. In practice that means a CPU simulates exactly to about 30 qubits, a GPU to 32 on a 96 GB card, and a QPU offers 12 to 256 physical qubits depending on the machine, with noise on every one of them.

Does a GPU let you simulate more qubits than a CPU?

Barely, and this is the most common misconception about GPU quantum simulation. An exact statevector needs 16 x 2^n bytes no matter which processor holds it, so the ceiling is set by memory rather than by the chip. A well-provisioned CPU machine reaches about 30 qubits and a 96 GB GPU reaches 32. That is two extra qubits for roughly eight times the memory. What the GPU actually buys is throughput: many circuits at once, which is why it is the right backend for parameter sweeps and optimizer loops rather than for one large circuit.