Why GPUs Now Sit Next to Qubits

In a facility in Poughkeepsie, New York, a 120-qubit IBM processor now sits beside racks of AMD GPUs owned by Oak Ridge National Laboratory. It reads like a procurement detail. It is really a bet on where quantum computing’s hardest problem lives: not in the qubits, but in the classical machine that has to read their mistakes in time.

The microsecond problem

Decoding became an infrastructure question because the clock is brutal. A quantum computer that corrects its own errors measures parity checks across its qubits every round, and on superconducting hardware a round takes about a microsecond. A classical decoder has to turn those measurements into corrections at the same pace. Fall behind, and errors pile up faster than they get cleared.

For most of the field’s history, that conversation happened at arm’s length. As StorageReview described it, researchers typically reach a quantum machine over the cloud, run the classical work on a separate system, and join the two through separate APIs. Every handoff adds delay.

I find it useful to think of decoding as a stack of jobs with different clocks rather than one job. The tier boundaries below are my framing, not any vendor’s.

1. Beside the qubits. FPGAs and AMD Versal adaptive SoCs, and eventually custom chips, do real-time decoding inside the control loop. They must keep pace with a round of about 1 µs.
2. Rack scale. GPUs (AMD Instinct MI355X, or NVIDIA over NVQLink) handle heavier decoding, decoder training and evaluation, and parallel syndrome streams. Link latency in NVIDIA’s NVQLink demos is under 4 µs.
3. Facility scale. HPC CPUs and GPUs (Umbra, OLCF, Lux) handle orchestration, simulation and code design. This work sits outside the real-time loop.

Distance is latency. Co-location is how you buy time back.

Relay-BP and the quiet shift in codes

The decoder at the center of this story, IBM’s Relay-BP, is a smarter version of a very old idea. Belief propagation is the message-passing method that already cleans up signals in 5G and satellite links. Applied to quantum codes, plain belief propagation tends to oscillate or stall. IBM’s researchers gave the messages memory, with a spread of strengths that includes negative values, and chained several runs together so the decoder can keep trying new answers without starting over.

The payoff, according to IBM’s June 2025 paper, is a decoder that is flexible, accurate, compact and fast all at once. Its own comparison table marks every alternative down on at least one of those four criteria. Quantum Computing Report summarised the accuracy gain as roughly tenfold over BP+OSD. Those are the authors’ claims, measured in simulation.

Why should an infrastructure leader care about an algorithm? Because IBM built its fault-tolerance roadmap on qLDPC codes such as the [[144,12,12]] gross code, and the code you pick fixes the decoding workload you inherit. Relay-BP is regular, parallel and tolerant of low precision, which is exactly the shape of work that FPGAs and GPUs like. Older approaches that lean on heavy linear algebra do not scale the same way. In my reading, the algorithm picks the hardware, not the other way around.

And it is already travelling: NVIDIA’s CUDA-Q QEC 0.6 ships a RelayBP decoder too.

24 nanoseconds

The FPGA result is the one hard number in this story. In October 2025, an IBM team described a prototype decoder for the gross code on an AMD VU19P FPGA, with a single Relay-BP iteration taking 24 nanoseconds. It matched the accuracy of a floating-point version using as little as 4-bit arithmetic for split X/Z decoding. The paper says that speed supports an average decoding time under a microsecond per cycle, provided circuit error probabilities stay below 3×10⁻³.

The low precision is the quiet headline. Four bits means tiny arithmetic units, which means you can pack a great deal of parallelism onto one chip. One headline claimed it ran ten times faster than required, and one executive told TechNewsWorld it sounded about a year ahead of IBM’s schedule. That is a lot of weight for a prototype to carry.

Here is what the result does not show. It is a memory experiment on one code. Nothing in it decodes syndromes streaming from a live quantum processor. Analysts quoted by TechNewsWorld were clear that the decisive constraints are still stable logical qubits and error rates, not decoder speed.

Why an FPGA for the tightest loop, and not a GPU? My reading is determinism. A fixed circuit answers in the same number of nanoseconds every time. A GPU adds launch overhead and jitter that you can tolerate at rack scale but not right beside the fridge.

Poughkeepsie, November 5

On November 5, IBM, Oak Ridge’s Quantum Science Center and AMD announced a shared platform for error correction research, and its first deployment is the co-location itself. IBM’s 120-qubit Nighthawk processor now sits with Umbra, an ORNL system built from AMD Instinct MI355X GPUs and 5th Gen EPYC CPUs, at IBM’s quantum site in Poughkeepsie. StorageReview describes Umbra as liquid-cooled racks. The GPUs train and evaluate decoders, and the EPYC CPUs orchestrate.

On the quantum side, Nighthawk offers square-lattice connectivity, high circuit throughput and real-time pulse control through IBM’s Quantum System API. Researchers can measure qubits mid-circuit and act on the result immediately. That is what makes conditional execution possible, and it is why latency matters at all.

The target comes from the Department of Energy. Its Quantum Genesis Mission, through the Q Competition, wants 100 logical qubits running 100,000 hard operations by late 2028. IBM’s current experiments reach 70 logical qubits and 438 hard operations, which leaves a gap of roughly 230 times in operation count. The platform will test concatenated codes, space-time codes, algorithm-aware decoders and orchestration in one stack, including hierarchical schemes that wrap an inner code in an outer one and decode at each layer.

What I would underline is AMD’s role. AMD’s own account splits the work across a portfolio: EPYC for orchestration, Instinct GPUs for parallel computation, Versal adaptive SoCs for control, readout and decoding near the processor, and ROCm to tie the software together. But as StorageReview points out, the announcement does not place those adaptive SoCs and FPGAs inside Umbra. The GPUs are in the room. The nanosecond-class silicon is a separate story.

Plans call for linking the platform to the Oak Ridge Leadership Computing Facility, which also houses Lux, ORNL’s new AMD-based AI and HPC supercomputer.

What nobody has published yet

The announcement is long on intent and short on numbers. StorageReview put it plainly: neither IBM nor AMD has published node counts, GPU or CPU quantities, decoding latency figures or benchmarks for the deployment. The link to OLCF and Lux is described as planned, with no completion date, external access schedule or general availability milestone.

So the questions that matter are still open:

• Where does Relay-BP run in this setup: on the FPGA, the GPUs, or both?
• Is the GPU tier inside the real-time loop, or one step behind it?
• What is the measured latency between Nighthawk’s readout and a correction coming back?
• Who gets access, and when?

My advice to anyone briefing a board on this is to call it a research testbed, not a product. A testbed is valuable. It is also a long way from a decoding service you can plan capacity around. Analysts quoted by TechNewsWorld made the same point from the other direction: a useful fault-tolerant machine by 2029 is possible, but it leans more on hardware physics than on classical results.

NVIDIA is playing the same game

The idea of a GPU beside the qubit did not start in Poughkeepsie. At GTC 2026, NVIDIA introduced cudaq-realtime, a library built on NVQLink that gives microsecond-latency callbacks between GPUs and quantum controllers. CUDA-Q QEC 0.6 plugs decoders into it. It ships two pipelines: RelayBP for qLDPC codes, and a neural-network pre-decoder paired with PyMatching for the surface code.

Partners have started to show up. IQM and Zurich Instruments are building a real-time demonstrator around a 20-qubit processor, with NVQLink running RDMA over Ethernet to reach under 4 µs end to end. Alice & Bob decoded its LDPC-cat codes on NVIDIA GPUs over NVQLink, though the October demo used synthetic measurement data rather than live qubits. Earlier in the year, the same company reported a 9.25× speedup on a GH200 against a CPU, cutting 100,000 shots from 18 hours to under two. That is simulation speed, not real-time decoding, and the difference matters.

Futurum’s read is that NVIDIA’s lead is sturdiest at the GPU tier, while AMD’s breadth maps onto the whole latency hierarchy. I would put it more carefully. Each camp has proof where the other has promises. NVIDIA has a published link latency and a shipping software release. IBM and AMD have a published FPGA iteration time and a federal testbed, but no platform numbers yet. And because RelayBP runs in both worlds, the algorithm is portable even if the interconnect is not.

When AI agents design the decoder

The strangest recent twist is that IBM let AI agents loose on the decoder’s hardware design. According to a PostQuantum analysis of an IBM Research preprint from October 13, coding agents rewrote the C++ kernel of the gross-code Relay-BP decoder, and each candidate was synthesized for the same AMD VU19P. An open-weight model, GLM-5.3, found a design with 52× lower estimated latency for about $26 in inference. Anthropic’s Claude Opus 5 in every role found one 204× better for about $299. A hybrid, with Opus directing GLM-5.3 workers, reached 126× for about $105.

Read the fine print before repeating those numbers. The speedups are high-level-synthesis estimates, not measurements on a chip, and they come from a reduced two-round version of the problem. Each configuration ran once. The costs cover model inference only. The best agent design is still far slower than IBM’s hand-written decoder, which the PostQuantum author puts at more than 40 times on the paper’s test cases. IBM’s authors themselves cautioned against reading the runs as a model ranking.

The more interesting part sits in an appendix. Handed IBM’s published architecture, an agent wrote the circuit-level code and matched the hand-written design’s cycle count, using about 80% more logic and a clock roughly 10% slower. Humans chose the architecture. The agent built it.

My take is that the story is not machines replacing decoder engineers. It is the price of iteration. A decoder has to be reworked whenever the code, the measurement circuit or the noise model changes, and IBM has several such changes between its 2026 Kookaburra module and the 2029 Starling system. If a redesign cycle gets cheaper, the roadmap gets less fragile.

There is a governance wrinkle too. Per PostQuantum, the cheapest run used a model from Z.ai, a developer on the US Entity List, served from downloaded weights on IBM’s own GPUs. Agencies that fund quantum hardware will have to decide which models are allowed to write its code.

What infrastructure leaders should do with this

Treat quantum decoding as a latency-tiered architecture decision, not a GPU purchase. In practice, that means five things.

• Ask for end-to-end numbers. An iteration time of 24 ns is not a correction delivered in time. Ask for readout-to-correction latency under realistic noise, with live hardware in the loop.
• Plan the building, not just the boards. Liquid-cooled GPU racks sharing a facility with quantum hardware is a power, cooling and floor-space conversation.
• Stay portable. Relay-BP runs on FPGAs and on NVIDIA GPUs, and ROCm and CUDA-Q are rival software stacks. Avoid locking in an interconnect before the standards settle.
• Budget classical cost per logical operation. This one is my speculation. As codes improve, decoding compute, not qubit count, may become the line item that surprises people.
• Hire at the seams. The scarce people understand HPC, FPGAs and quantum control together. AI-assisted hardware design may lower the bar, but IBM’s own results show it is not yet a substitute.

What to watch next

Seven signals will tell you whether this is a turning point or a press release.

1. Published decoding latency from the Poughkeepsie platform. This turns an announcement into evidence.
2. Relay-BP closing the loop on live Nighthawk syndromes. It is the step every result so far lacks.
3. IBM decoder tests on Kookaburra hardware, which IBM said could start as early as 2026. This would be the first module-level test of the qLDPC memory story.
4. A date for the OLCF and Lux connection. It shows whether this scales beyond a testbed.
5. NVQLink demos moving from synthetic to live data. It tells you whether GPU-in-the-loop holds up.
6. Hard operations climbing from 438 toward the 100,000 target. This is the DOE yardstick, and it is about 230× away.
7. Agent-designed decoders at full problem size, run on hardware. It shows whether the cheap-iteration story is real.

Qubit counts get the headlines. The decoder decides whether those qubits are worth anything. The GPUs now parked beside them are the industry admitting as much.