GPU Hardware for Quantum Computing Simulation & Control 2026 — State-Vector, Tensor-Network & Cryogenic Control

The most common question a hardware vendor hears from a quantum team is the wrong one: "what GPU do I need for a quantum computer?" A quantum processor does not replace a GPU — it depends on one, and often on a rack of them. Two distinct classical workloads sit around every qubit array, and they pull the specification in opposite directions. The first is simulation: emulating a quantum circuit on classical hardware to develop algorithms, verify designs and calibrate a machine before it exists. The second is control and readout: generating the microwave and RF pulses that drive the qubits and classifying the faint signals that come back, inside a hard real-time deadline. One is throughput- and memory-bound; the other is latency-bound and barely touches a GPU. Buying one machine for both is the mistake this guide helps you avoid.

Simulation Regimes and Their Hardware Appetite

"Quantum simulation" is not one workload. State-vector simulation stores the full 2ⁿ-amplitude wavefunction and is exact but exponentially hungry. Tensor-network methods — matrix product states (MPS) and their two-dimensional cousins (PEPS) — exploit limited entanglement to reach far more qubits at the cost of approximation and structure-dependent performance. Quantum Monte Carlo and error-corrected logical-circuit simulation each have their own profile again. The right GPU depends entirely on which regime your team spends its hours in, so the first procurement question is not "H100 or B200?" but "state-vector or tensor-network?"

The VRAM Wall Is Arithmetic, Not Marketing

A full state-vector of n qubits holds 2ⁿ complex amplitudes; in double precision that is 2ⁿ × 16 bytes. The wall arrives fast: 30 qubits needs about 16 GiB, 33 qubits about 128 GiB, and 36 qubits roughly a terabyte — which is precisely why big state-vector runs are sharded across a whole node of GPUs and stitched together over NVLink or InfiniBand. Simulators that offer a single-precision (complex64) mode double the qubit count a given card can hold, at the cost of numerical stability that some algorithms tolerate and some do not. Either way, the practical rule is that a state-vector machine is specified by aggregate VRAM, and its scaling ceiling is set by how well the shard-and-exchange step keeps up — the same interconnect problem that governs any tightly coupled HPC code.

The FP64 Question for Quantum

Because complex128 state-vector math is FP64-heavy, data-centre cards with a strong double-precision ratio — the H100 and H200, at roughly 1:2 FP64:FP32 with a dedicated FP64 tensor path — remain the natural fit for large exact simulation, exactly as they are for computational chemistry and numerical weather prediction. Tensor-network work, by contrast, is usually happy in complex64 and behaves more like a dense linear-algebra or even machine-learning workload, which brings the cheaper high-FP32 cards into play. A programme that only does MPS calibration should not buy the same silicon as one running exact 34-qubit circuits. Settle the method, and the card class follows.

The Control Plane Is a Latency Problem, Not a Throughput One

The readout and control path looks almost nothing like the simulation path. Pulse generation and qubit readout are closed-loop, deterministic workloads: a classical controller must synthesise an arbitrary-waveform pulse, measure the returned signal, classify the outcome and feed the result back into the next pulse — all inside a coherence-limited budget measured in hundreds of nanoseconds to a few microseconds. That job belongs to RFSoC and FPGA-based controllers with real-time converters, not to a data-centre GPU sitting behind a PCIe link and an OS scheduler. GPUs enter the control plane only where classification is genuinely neural — for example, a small network that discriminates qubit states from noisy readout traces, or that tunes pulse parameters — and even then it runs beside the deterministic controller, not in the feedback loop. Confusing these two planes is the most common architecture error in new quantum labs.

Interconnect, Storage and the Rest of the Node

Any quantum programme that simulates at scale inherits the standard tightly coupled HPC problem. State-vector sharding exchanges amplitudes every gate, so the fabric between GPUs — NVLink and NVSwitch inside a node, NDR InfiniBand or RoCE between nodes — caps how far a run scales before communication dominates compute. Checkpoint I/O matters too: calibration sweeps and variational optimisations generate large volumes of intermediate results that stall the run if the filesystem cannot absorb the writes. And because the same cluster typically also runs the machine-learning models that process readout data and tune parameters, the node must serve both the FP64-heavy simulator and the tensor-shaped workloads on one platform — which is an argument for a mixed deployment rather than a uniform one.

Selection Rules

• Decide the simulation method before the card — state-vector and tensor-network point at different silicon entirely.
• Size a state-vector machine by aggregate VRAM, and accept that interconnect, not FLOPS, sets its scaling ceiling.
• Keep FP64-ratio cards for exact simulation and high-FP32 cards for tensor networks and control-plane ML; do not buy one class for both.
• Put real-time pulse generation and readout on RFSoC/FPGA controllers, never on an OS-scheduled GPU in the feedback path.
• Budget NVLink/NVSwitch and NDR InfiniBand as part of the purchase — sharded simulation dies at the interconnect first.
• Plan for a mixed cluster: the same node often serves FP64 simulation and tensor-shaped readout ML, which want different platforms.