Ask how good a quantum computer is and people reach for two numbers: how many qubits it has and how clean its gates are. Both matter. Neither tells you how long you will actually wait for an answer. A machine can have flawless qubits and still crawl if it needs an hour to run a circuit you expected to take a second. Speed is the quiet third axis of quantum performance, and IBM gave it a name: CLOPS, short for Circuit Layer Operations Per Second.
Why speed is a separate problem
Most useful quantum algorithms are not a single shot. They are loops. A variational chemistry routine, for example, runs a circuit, measures it, tweaks the parameters on a classical computer, and runs again. It might do that thousands of times. Every one of those runs also has to be repeated hundreds or thousands of times to build up statistics, because a single measurement of a qubit gives you one noisy bit, not a probability. Add it up and a modest experiment can demand millions of individual circuit executions.
Now the wait time matters enormously. If each execution carries even a few milliseconds of overhead, those milliseconds multiply into hours. The qubits might be idle for most of that time, sitting cold while classical machinery decides what to send next. A fast processor that keeps the pipeline full can finish the same workload in a fraction of the wall-clock time, and for a researcher paying by the minute for cloud access, that difference is money.
What CLOPS actually measures
CLOPS tries to capture the full round trip, not just the raw gate speed. The benchmark runs a set of parameterized circuits, sized to the machine's quantum volume, and times how many layers of operations the system can push through per second when you account for everything in the loop. That includes the gate durations themselves, the time to measure and reset qubits, the delay in loading new circuits, and the back-and-forth with the classical control system that updates parameters between runs.
The result is a single throughput number. Higher is faster. The point of folding in all that overhead is honesty. It is easy to quote a two-qubit gate time of a couple hundred nanoseconds and imply the whole machine moves at that pace. In practice, the bottleneck is rarely the gate. It is the compiler turning your circuit into pulses, the network hop to the cryostat, the reset that empties the qubits before the next shot, and the data streaming back for analysis.
Where the time actually goes
Several stages fight for the clock:
- Gate execution. Superconducting gates run in tens to hundreds of nanoseconds. Trapped-ion gates are slower, often microseconds, but the atoms hold their state far longer, so the trade is not simple.
- Measurement and reset. Reading a qubit and clearing it for the next run can take longer than the computation itself, sometimes microseconds of settling.
- Classical overhead. Compiling, transpiling, and shuttling data between the quantum chip and the controller adds latency that has nothing to do with physics.
This is why CLOPS is a systems metric, not a qubit metric. It rewards companies that invest in fast control electronics, tight integration between classical and quantum hardware, and software that does not stall the pipeline. IBM has reported order-of-magnitude speedups on the same physical processors purely by streamlining the classical loop and running sequences of circuits without pausing between them.
The catch with any single number
Like quantum volume before it, CLOPS compresses a complicated machine into one figure, and that invites gaming and misreading. A processor can be fast on the benchmark's chosen circuit shape and slower on the workload you care about. Speed also means little if the answers are wrong, so CLOPS is meaningless without pairing it against error rates and qubit counts. A blazing machine that decoheres before it finishes is no bargain.
Comparing across hardware types is trickier still. Superconducting chips win on raw gate speed, while ion traps and neutral-atom arrays clock slower per operation but can run more qubits in parallel or tolerate longer circuits. A throughput number flattens those differences.
The reason the metric matters anyway is that the field is shifting from demos to workloads. As error correction kicks in and circuits grow longer, the sheer volume of operations explodes. Fault-tolerant machines will spend enormous effort brewing magic states and running decoders in real time. Throughput stops being a convenience and becomes the difference between a useful tool and an expensive science experiment. CLOPS is a first attempt to keep score.
