Quantum Volume: How to Measure It Yourself, Not Recite It

Our piece on the quantum benchmarking executive order makes the case that the field's biggest unsolved problem isn't hardware, it's the lack of a trustworthy, vendor-independent way to compare hardware at all. Quantum Volume, introduced by IBM in 2019, was one of the first serious attempts to fix that: a single number that folds qubit count, connectivity, and gate fidelity together into one comparable figure, instead of letting a vendor pick whichever number flatters them most.

What the number measures

A device's Quantum Volume is 2ⁿ, where n is the size of the largest square circuit (n qubits, circuit depth also n) that the device executes correctly often enough to pass a defined statistical test. Square is deliberate. A wide, shallow circuit stresses qubit count and connectivity. A narrow, deep one stresses gate fidelity and coherence time. A square circuit stresses both at once, which is the whole point of using it as a single combined metric.

The heavy output test

The test circuit itself is built from randomness by design. For n qubits and depth n:

1. At each layer, randomly pair up the n qubits.
2. Apply a random SU(4) unitary (a general 2-qubit gate) to each pair.

That produces an output probability distribution with no special structure to exploit, which is exactly what makes it a fair stress test rather than something a device is specifically tuned to pass.

Heavy outputs are defined relative to that distribution: compute the ideal (noiseless) output probabilities classically, take the median probability, and call any outcome above the median a "heavy" output. In the ideal case, heavy outputs cover a bit more than half the probability mass (a known property of Porter-Thomas-distributed random circuit outputs, not something you have to prove yourself each time).

The pass criterion: run many random circuits of a given size on the real device, and check whether the fraction of shots landing on a heavy output exceeds 2/3, with enough statistical confidence to rule out lucky guessing. If circuits of size n pass, QV = 2ⁿ. If size n+1 fails, that's the device's Quantum Volume.

Building the circuit in Qiskit

Qiskit ships a QuantumVolume circuit class directly, which builds the randomized layer structure described above:

from qiskit.circuit.library import QuantumVolume
from qiskit.quantum_info import Statevector
import numpy as np

n = 4  # qubits, and circuit depth, for a QV = 16 test
seed = 42

qv_circuit = QuantumVolume(n, depth=n, seed=seed)
print(qv_circuit.decompose().count_ops())

Fixing a seed makes the circuit reproducible: the same seed always generates the same random layer structure, which is essential if you want to compare the same test circuit's behavior on a simulator against real hardware later.

Computing the heavy outputs classically

Before running anything on noisy hardware, compute the ideal distribution to know what "heavy" means for this specific circuit:

statevector = Statevector(qv_circuit)
probabilities = statevector.probabilities_dict()

median_prob = np.median(list(probabilities.values()))
heavy_outputs = {
    bitstring for bitstring, p in probabilities.items()
    if p > median_prob
}

print(f"{len(heavy_outputs)} heavy outputs out of {2**n} possible outcomes")

For n = 4, there are 16 possible outcomes. Because heavy outputs are, by construction, everything above the median of a 16-value list, this returns 8 heavy outputs (the top half) for any generic (non-degenerate) probability distribution, a direct consequence of how the median is defined on a list of 16 distinct values, not something that depends on which particular circuit you generated.

Checking a device against the test

The actual pass/fail check compares a device's measured shot distribution against the heavy_outputs set computed above:

def heavy_output_fraction(counts, heavy_outputs, total_shots):
    heavy_shots = sum(c for bitstring, c in counts.items() if bitstring in heavy_outputs)
    return heavy_shots / total_shots

# counts = result from running qv_circuit on AerSimulator or real hardware
# fraction = heavy_output_fraction(counts, heavy_outputs, shots)
# passes = fraction > 2/3 (with confidence interval accounting for shot noise)

Run this at increasing n (5, 6, 7...) against a real device until the pass criterion fails. Whatever the largest passing n was, that device's Quantum Volume is 2ⁿ.

Why this matters more than a qubit count

A device might have a large qubit count and a small Quantum Volume if its connectivity is poor or its two-qubit gate fidelity is weak, since either forces the transpiler to insert extra SWAP gates that eat into the circuit's effective depth budget. That's the entire reason the metric exists: to catch exactly the kind of headline that reports qubit count alone and lets a weak connectivity graph or a mediocre gate fidelity hide behind it. It has real limits too. Quantum Volume only tests up to the point where the device stops passing, so it says little about behavior far past that threshold, and its randomized-circuit structure doesn't necessarily reflect the specific circuits any particular application runs. Application-oriented benchmarks like the ones tracked on our developer tools page exist partly to fill that gap.

Try this next

• Generate QuantumVolume circuits at increasing n and watch how quickly the transpiled two-qubit gate count grows once you target a real device's connectivity graph instead of an all-to-all simulator.
• Compare heavy-output fractions between a noiseless AerSimulator and a noisy one built with a realistic device noise model, and find the n where the pass criterion starts failing.
• Read our quantum benchmarking executive order piece for why the field still doesn't agree on a single trustworthy way to compare hardware, Quantum Volume included.