⚛️ quantum physics

Benchmarking Zero-Setup Quantum Circuit Simulators

This paper presents a systematic benchmarking study demonstrating that GPU-accelerated approximate quantum simulators, particularly those utilizing Pauli path simulation on hosted platforms like BlueQubit, achieve significant sub-quadratic scaling and up to 1,400-fold speedups over CPU-based implementations, enabling the simulation of 127-qubit circuits with accuracy regimes previously inaccessible to commodity hardware.

Original authors: Arul Rhik Mazumder, Mohammed Zuhair Mullath, Hayk Tepanyan

Published 2026-07-14

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Arul Rhik Mazumder, Mohammed Zuhair Mullath, Hayk Tepanyan

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you're trying to solve a massive, impossible puzzle. In the world of quantum computing, this puzzle is simulating how a quantum computer thinks. For a long time, the only way to do this was to build a giant, custom engine in your own garage (installing drivers, coding libraries, managing hardware). But recently, a new trend has exploded: "Zero-Setup" simulators. These are like renting a fully furnished, super-powered workshop in the cloud. You just send your puzzle instructions, and they hand you the answer without you ever touching a screwdriver.

The paper you're asking about is a massive, systematic race to see which of these cloud workshops is actually the fastest. The researchers didn't just look at one type of puzzle; they tested two very different ways of solving them: Matrix Product States (MPS) and Pauli Path Simulation (PPS). They compared a cloud service called BlueQubit against other big names like AWS Braket and some self-contained software packages.

Here is the story of what they found, told through the lens of a high-speed race.

The Big Discovery: The GPU Rocket vs. The CPU Bicycle

The main finding is that when the puzzles get really big and complicated, the GPU (Graphics Processing Unit) backends act like a rocket ship, while the CPU (Central Processing Unit) backends are more like a reliable but slow bicycle.

For the MPS method (which is great for puzzles with a specific kind of "entanglement" or connection between pieces), the researchers found something surprising. They expected the rocket to get faster as the puzzle got bigger, but they didn't expect how much faster.

The Finding: As the "bond dimension" (a fancy way of saying how tangled the puzzle pieces are) got larger, the GPU didn't just get a little faster; it got exponentially more efficient. The paper measured this scaling as roughly $T \propto \chi^{1.49}$ for the GPU, compared to $T \propto \chi^{2.03}$ for the CPU.
The Analogy: Imagine the CPU is a team of workers stacking bricks one by one. As the wall gets higher, they get tired and slower. The GPU is like a giant crane that gets more efficient the bigger the wall gets. The researchers calculated that for a very large bond dimension of 5,000, the GPU might finish in about 11.7 hours, while the CPU would take a whopping 119.2 hours.
The Catch (The "Low-Entanglement" Trap): Here is the twist. The rocket isn't always faster. If the puzzle is simple and the pieces aren't tangled much (like a Quantum Fourier Transform circuit), the GPU actually slows down. Why? Because the "engine start-up" time (kernel-launch overhead) is too high for such a small job. In these simple cases, the CPU bicycle is actually 7.5 times faster than the GPU rocket. The paper explicitly rules out the idea that "bigger is always better for GPUs"; instead, the complexity of the connections (entanglement) is the deciding factor. If the bond dimension is below 128, use the CPU. If it's above 256, use the GPU.

The 1,400x Speedup: Breaking the Wall

The second part of the race involved Pauli Path Simulation (PPS), which is used for a specific 127-qubit benchmark called the "Kicked Ising" model. This is where the results get wild.

The researchers tested how fast different systems could solve this puzzle when they demanded extreme precision (a "truncation threshold" of $\delta = 2.5 \times 10^{-5}$ , which means keeping 27.6 million Pauli terms).

The Result: The BlueQubit GPU backend finished this task in just 3.9 seconds.
The Comparison: The CPU versions took thousands of seconds. The BlueQubit CPU took 5,471 seconds. The PPS-Qiskit took 5,456 seconds. The PauliPropagation.jl took 55,430 seconds (about 15 hours!).
The Speedup: This means the GPU was up to 1,400 times faster than the CPU versions.
The "Unreachable" Zone: The paper points out a critical limit. The CPU systems literally could not go any further. They hit a wall. The local laptop versions ran out of memory (hitting a 16 GB ceiling), and the cloud CPU version was blocked by software limits at $\delta = 10^{-5}$ . Only the GPU could go deeper, reaching $\delta = 2.89 \times 10^{-6}$ .

The Accuracy Surprise: The "Valley" of Error

There was a second, hidden discovery in the PPS race. Usually, you think that if you make your simulation more precise (lowering the threshold $\delta$ ), the answer gets better and better.

The Reality: The paper measured the error and found it was non-monotonic. This means the answer actually got worse before it got better.
The Journey: As they lowered the threshold, the error dipped, then rose to a peak of $\approx 0.14$ near $\delta = 5 \times 10^{-5}$ , and then finally started dropping again to $\approx 0.016$ at the finest level.
Why it matters: If you were only using a CPU, you would have stopped at the peak of the error (around $\delta = 10^{-5}$ ) because it was taking too long or running out of memory. You would have concluded the method was broken. But the GPU, being so fast, allowed the researchers to push past that peak and find the correct answer. The GPU didn't just make it faster; it unlocked a region of accuracy that was previously invisible to the CPU.

What the Paper Explicitly Rules Out

It is important to know what this paper says is not the answer:

"Bigger is always better for GPUs": The paper explicitly argues against this. For low-entanglement circuits (like QFT with a bond dimension of 64), the GPU is slower. The "rocket" is too heavy for a "bicycle" race.
"All cloud simulators are equal": The paper shows massive differences. At 34 qubits, the BlueQubit GPU was 1–2 orders of magnitude (10 to 100 times) faster than AWS Braket SV1 and Quantum Rings.
"CPU is sufficient for high precision": The paper demonstrates that for the 127-qubit benchmark, the CPU implementations evaluated here literally could not reach the necessary precision levels due to memory limits or software caps.

How Sure Are We?

The authors are very confident in these numbers because they ran the exact same circuits on every platform.

Measured, not guessed: They didn't just simulate the speed; they ran the code. They measured the time in milliseconds and seconds.
Reproducible: They provided all their code and circuit definitions on GitHub so anyone can run the race again.
Specific limits: They are careful to say these results apply to the specific hardware they used (like the NVIDIA A100 GPUs and the 16 GB laptop for the local tests). They note that if you had a super-computer with hundreds of gigabytes of RAM, the CPU might do better, but on the "commodity" hardware they tested, the GPU wins big.

The Bottom Line

This paper is a guidebook for anyone trying to simulate quantum computers without building their own supercomputer. It tells us:

If your puzzle is simple and lightly connected, stick to the CPU.
If your puzzle is complex and highly tangled (high bond dimension), the GPU is a game-changer, getting faster the harder the problem gets.
For the hardest, most precise simulations (like the 127-qubit Ising model), the GPU is currently the only tool that can reach the finish line in a reasonable amount of time, revealing accuracy peaks that the CPU simply cannot see.

The authors conclude that while the CPU has its place, the GPU-accelerated "zero-setup" simulators are pushing the boundaries of what is possible, making previously impossible calculations routine.

Technical Summary: Benchmarking Zero-Setup Quantum Circuit Simulators

Problem Statement
As quantum processors scale to hundreds of qubits (e.g., IBM's 127-qubit Eagle, Google's 105-qubit Willow), exact state-vector simulation becomes computationally intractable ( $O(2^n)$ ), necessitating a transition to approximate methods like Matrix Product States (MPS) and Pauli Path Simulation (PPS). Concurrently, the ecosystem for running these simulations has shifted toward "zero-setup" environments—hosted cloud platforms and self-contained SDKs that abstract away local infrastructure management. However, the performance characteristics of these zero-setup simulators remain poorly documented. Existing benchmarks often focus on exact state-vector simulation or isolated operations, lacking systematic, end-to-end comparisons across dominant approximate methods under controlled conditions. This gap leaves practitioners without the data needed to select the appropriate backend for specific tasks.

Methodology
The authors present a systematic, reproducible benchmarking study comparing zero-setup simulators across three simulation paradigms: state-vector, MPS, and PPS. The study evaluates the following backends:

BlueQubit: Cloud-hosted backends for State-Vector (SV), MPS, and PPS on both CPU and GPU (NVIDIA A100).
AWS Braket SV1: Cloud-hosted state-vector simulator.
Quantum Rings: Self-contained SDK for state-vector simulation.
PPS-Qiskit & PauliPropagation.jl: Self-contained, locally installed SDKs for PPS, running on a commodity laptop (Intel Core i7, 16GB RAM).

The evaluation utilizes a unified set of circuit families and statistical protocols:

Quantum Volume (QV): Random SU(4) circuits used for state-vector and MPS scaling analysis.
Quantum Fourier Transform (QFT): Low-entanglement circuits to test GPU kernel-launch overhead.
Kicked Ising (127 qubits): A utility-scale benchmark for PPS accuracy and runtime across varying truncation thresholds ( $\delta$ ).
Peaked Circuits (46 qubits): Used to assess MPS reconstruction quality against a target distribution.

The study distinguishes between two types of comparisons:

Infrastructure comparisons: Isolating hardware effects (CPU vs. GPU) on the same implementation (BlueQubit).
Cross-platform comparisons: Evaluating end-to-end performance across different vendors and implementations (e.g., BlueQubit vs. AWS Braket vs. local SDKs).

Key Results

State-Vector Simulation:
- BlueQubit's GPU backend outperforms AWS Braket SV1 and Quantum Rings by 1–2 orders of magnitude at 30+ qubits.
- Both CPU and GPU exhibit exponential scaling, but GPU runtimes remain significantly lower (approaching $10^5$ ms vs. $10^6$ ms at 34 qubits).
- AWS Braket SV1 becomes prohibitively slow (> $10^7$ ms) and costly beyond 30 qubits, leading to the discontinuation of benchmarking at 31 qubits.
Matrix Product State (MPS) Simulation:
- Scaling: The GPU backend demonstrates sub-quadratic scaling with bond dimension ( $\chi$ ), with $T \propto \chi^{1.49 \pm 0.06}$ , compared to near-quadratic CPU scaling ( $T \propto \chi^{2.03 \pm 0.11}$ ). This results in a growing speedup $S(\chi) \propto \chi^{0.55}$ as the simulation becomes more expensive.
- Phase Decomposition: The speedup is driven entirely by the "build phase" (tensor contraction and SVD), which is efficiently parallelized on GPUs. Sampling time is negligible for single-shot runs but grows on GPU for high-shot workloads, slightly eroding the end-to-end speedup.
- Entanglement Dependence: The GPU advantage is contingent on circuit entanglement. For low-entanglement circuits like QFT (where $\chi$ remains small, e.g., $\le 64$ ), GPU kernel-launch overhead causes a slowdown of up to 7.5× compared to CPU. Thus, bond dimension, not qubit count, is the correct metric for backend selection.
Pauli Path Simulation (PPS):
- Speedup: On the 127-qubit Kicked Ising benchmark, the BlueQubit GPU backend delivers up to a 1,400× speedup over CPU implementations at fine truncation thresholds ( $\delta = 2.5 \times 10^{-5}$ , ~27.6M Pauli terms).
- Accessibility: The GPU backend is the only tested system capable of reaching accuracy regimes below $\delta = 10^{-5}$ . Local CPU implementations hit memory limits (16GB RAM), and the BlueQubit CPU API imposes a software limit at $\delta = 10^{-5}$ .
- Accuracy Convergence: The study reveals a non-monotonic convergence regime where accuracy error initially increases as $\delta$ decreases (peaking near $\delta = 5 \times 10^{-5}$ ) before recovering. Only the GPU backend can traverse this peak and reach the high-accuracy regime within practical wall-clock times (minutes vs. days).

Significance and Claims
The paper claims to provide the first standardized, cross-platform benchmarking study of zero-setup quantum simulators covering both MPS and PPS methods. Its primary contributions are:

Performance Characterization: Establishing that GPU acceleration offers sub-quadratic scaling for MPS and massive speedups for PPS, but only when problem parameters (bond dimension or Pauli term count) are sufficiently large to amortize overhead.
Backend Selection Criteria: Defining a practical rule for practitioners: use CPU for low-entanglement circuits ( $\chi \lesssim 128$ ) and coarse PPS thresholds, but switch to GPU for high-entanglement or fine-threshold simulations.
Methodological Transparency: Providing a reproducible framework and public repository that exposes tradeoffs invisible to isolated evaluations, such as the non-monotonic error peaks in PPS and the specific crossover points between CPU and GPU efficiency.

The authors conclude that these GPU-enabled capabilities strengthen the classical simulation baseline, shifting the boundary of what is classically tractable and making previously inaccessible accuracy regimes routine for iterative experimentation. The study explicitly notes limitations, including the specific hardware configurations used (which may affect absolute speedup values) and the exclusion of hybrid variational workloads.