How Riverlane is exploring GPU-accelerated decoder calibration to help quantum error correction keep pace with changing hardware behaviour.
By Jules Gransden, Boris Varbanov, Justus Hübotter & Samarth Ganesh Kashyap
Introduction
A decoder is only as good as its picture of the noise. In quantum error correction (QEC), graph-based decoders, like the ones we develop at Riverlane, are only as accurate as their knowledge of the noise the quantum processor actually experiences . This knowledge is passed to the decoder as a set of prior probabilities, or weights, that describe the likelihood of the errors that the decoder attempts to identify and correct. Those weights can be directly calibrated from QEC experiments executed on the hardware. However, they remain accurate only while the qubits behave the same way they did when these calibration experiments were performed.
In reality, qubits drift. Frequencies wander with temperature, defects switch on and off, and gate fidelities slowly degrade. When the noise changes and the weights don't, the decoder quietly gets worse. The weights therefore need recalibrating regularly, between runs of an experiment rather than during them. The faster that calibration runs, the shorter the gap between collecting the training data and using the weights, and the more resilient it is to drift in between.
In this post, we describe a calibration loop that learns the decoder's weights directly from experimental data, and how moving its heaviest step onto a GPU makes it dramatically faster.
Main findings
The loop runs in the gap between collecting calibration data and starting the QEC experiment, so every second it takes is a second the device spends waiting and the noise spends drifting. Making it fast means tackling its biggest cost: decoding.
The loop judges each candidate set of weights by the logical error rate (LER) it produces, and the only way to measure an LER is to decode, a lot. One training epoch on a rotated patch of surface code means decoding thousands to tens of million syndromes, depending on its size and physical noise probability. On a CPU, that is where nearly all the calibration time goes.
So we moved the decoding onto a GPU. We use Riverlane's Local Clustering Decoder (LCD), which was built for real-time use, and adapted it to decode hundreds of thousands of syndromes at once on a single NVIDIA H100.
The result: a training epoch on the surface code now takes 2.8 seconds instead of three minutes on a single CPU core (Figure 1).
Compared with LCD running on a single core CPU, the NVIDIA H100 makes each training epoch of the optimizer for a surface code calibration 65x faster (Figure 1a) and 43x faster when calibrating for a repetition code experiment (Figure 1c).
The raw decoding numbers are even more striking. Because we decode in such large batches, the useful measure is throughput: how many syndromes the decoder gets through every second. On the surface code, the H100 decodes about 4.2 million syndromes per second, against roughly 59,000 on the CPU core, a 71× speedup (Figure 1b). On the repetition code, it reaches 155 million per second, a 121× speedup (Figure 1d).
Why is the epoch speedup smaller than the decoding speedup? Each epoch also does work the GPU doesn't accelerate, such as updating the policy and building each candidate's weights. On the repetition code, decoding is so cheap that this overhead tales up a bigger share of the epoch.
What about using more of the CPU? Figure 2 shows the same training epoch on 1 to 32 CPU cores. More cores help, but with diminishing returns: 32 cores make the surface-code epoch about 23× faster than a single core, not 32×, as the cost of splitting up the work and gathering the results grows. Even at 32 cores, a single H100 is still 3× faster on the surface code and 2× faster on the repetition code, while leaving the CPU free for the rest of the control stack.
The learned weights pay off. Training starts from an uninformed or decoder-agnostic prior: either a generic noise model that knows nothing about the specific device, or an estimate that knows the device but not the decoder. Each epoch, the loop tests a batch of candidate weights against experimental data and shifts towards the ones that give the lowest LER, so the prior gradually adapts to both the real hardware and the decoder using it. The result is a substantial gain in accuracy: depending on the code, the LER drops by anywhere from several percent to as much as a factor of two compared with the starting prior.
Why it matters
Calibration sits between characterising the device and running the experiment. Every minute it takes is a minute the noise can drift away from what the weights describe, and a minute the quantum processor isn't doing useful work. Faster calibration shortens that gap, so the decoder's prior matches the device it is actually decoding.
Speed also changes how often calibration can happen. A loop that takes minutes rather than hours can run before every experiment rather than once a day. Within the same time budget, it can also train for longer and produce better weights.
For QPU makers, that means less idle time and fewer silent drops in logical performance. For HPC centres and control-system companies, it is a concrete, well-defined workload for the GPUs they are already placing beside quantum hardware.
While this research shows that GPUs may be well suited to accelerating decoder weight optimisation and retraining workflows, future fault-tolerant quantum computers will require a heterogeneous classical computing stack, with specialised systems handling different error-correction tasks. As quantum error-correction workflows become increasingly complex, different responsibilities may be distributed across multiple hardware platforms. Insights from this work will help inform how these emerging workflows can integrate with Riverlane's Deltaflow technology, enabling efficient coordination between dedicated QEC hardware and high-performance computing resources.
How it works
Our method is inspired by the prior-optimisation approach introduced by Sivak, Newman and Klimov at Google Quantum AI (arXiv.org:2406.02700). Rather than fitting the prior from syndrome statistics, for example, it calibrates the prior by directly minimising the LER of the decoder that will use it.
The decoder's prior is an error hypergraph. Each detector is a node, and each possible error mechanism an hyperedge connecting the detectors it would trigger, weighted by how likely that error is.
Resolving the LER of a large-distance code directly would take an exponentially growing number of shots. Instead, we use small distance-5 codes, called sensors, as local probes of the error landscape. Each sensor shares most of its error mechanisms with the larger target code, so the weights learned on the sensors can then weight the full code's hypergraph.
The weights are learned with multi-agent reinforcement learning (RL). Each weight is described by a Gaussian distribution; together these form the policy, whose mean is the current best guess at the optimal prior. Each epoch, the loop samples a batch of candidate weight sets, decodes every sensor's training shots with candidate, and rewards each sensor's agent with −log10(LER). The policy then shifts towards the candidates that scored best.
Decoding those shots is where the GPU comes in. It accounts for nearly all of the training cost, and each shot is an independent problem, which makes the work a natural fit for a GPU. We assign one thread to each decoding instance, so tens of thousands of shots are decoded in parallel in a single run. To keep each thread lightweight, we store edge weights as 7-bit integers, which is all the precision needed for the surface code experiment we ran.
Why now
GPUs are now standard hardware across many industries, and HPC centres have already deployed them at scale. They are also moving into the quantum control stack itself. Hardware vendors and GPU makers are linking quantum processors to GPUs with low-latency interconnects, and NVIDIA has released its own GPU-based decoders, including its Ising pre-decoder and belief propagation (BP) decoders.
At the same time, QEC experiments are running at larger and larger scales, so drift of the noise that qubits experience becomes increasingly impactful. The original work identifies run time as one of the method's main limitations. Our GPU implementation tackles that directly, cutting each training epoch from minutes to seconds, so calibration can be repeated routinely between experiment runs. And because LCD was designed for real-time decoding in hardware, the weights are tuned for the same algorithm that would decode the experiment itself.
Decoder weight optimization is moving from research curiosity to standard practice. Google used these calibration methods to learn weights in its below-threshold Willow experiments (arXiv:2408.13687), and groups at NVIDIA (arXiv:2604.12841), IBM (arXiv:2110.04285) and in academia (arXiv:2511.09491, arXiv:2603.00837) are developing their own approaches to learning, and re-learning, the noise a decoder sees. As systems scale, the problem grows with them: more qubits mean thousands more weights to calibrate, and longer computations mean more time for the noise to drift. That turns calibration into a substantial classical workload, and one that GPUs are well placed to accelerate.
Conclusion
Recalibrating a decoder is a learning problem, and a GPU makes that learning fast enough to be routine. With LCD on a single NVIDIA H100, we decode over 4 million surface-code syndromes per second, cutting a training epoch from three minutes to under three seconds. That shrinks the gap between characterising the device and running the experiment, and within the same time window it leaves room for more training and better priors.
Looking ahead, decoder recalibration is likely to become one component of a broader heterogeneous classical architecture for quantum error correction. In that future, GPUs may accelerate learning and optimisation tasks, while a dedicated QEC system such as Deltaflow provides the real-time processing needed to support fault-tolerant quantum computation.
Deltaflow is designed to scale alongside quantum computers by combining specialised QEC hardware and software, recognising that future fault-tolerant systems will require a mix of GPUs, FPGAs and ASICs to meet the increasing complexity of QEC workflows.
These technologies are likely to work together, with different layers of the classical stack solving different parts of the problem. As quantum computers scale, combining high-performance computing resources with specialised QEC infrastructure will become increasingly important.