When a quantum computer must sit next to a supercomputer, and when the cloud is enough

A new framework from AWS, NVIDIA, Lawrence Berkeley National Laboratory, and NASA gives quantum-classical buyers a computable answer to a question they have been answering with guesswork: when does the quantum machine need to sit in the same building as the supercomputer, and when can it just be called over the internet?

The paper, "Performance Model for Hybrid Quantum-Classical Workflows," appeared on arXiv this month as preprint 2607.15426 and was explained in a parallel AWS Quantum Technologies Blog post by the same author group. It introduces a single ratio, Rcc, that compares communication overhead to useful quantum work in a hybrid workflow. If Rcc is small, the workload is compute-bound and a remote cloud connection is enough. If Rcc is large, the workload is communication-bound and tight local integration materially changes how fast it runs.

The authors separate quantum-classical work into two tiers. The first is the real-time control level: sub-microsecond hardware tasks such as qubit calibration and quantum error correction (QEC) syndrome decoding. These have to happen at the speed of the hardware, so the classical processor that issues commands and interprets results has to be physically next to the quantum machine. Sending those signals across a network is not a question of slowness; it is not technically possible at the latencies required.

The second tier is the application level: hybrid algorithms such as variational solvers and sample-based diagonalization, where classical and quantum code exchange larger messages but at human-scale intervals. Here latency does not decide whether the work runs at all. It decides how long it runs. A slower round trip means a longer bill and a slower result, not a broken experiment.

The split has direct capex consequences. A lab can keep real-time control hardware on-site and push application-level work to the cloud, paying for co-location only where the math says it pays off. Most application-level work is compute-bound. Most real-time control work is not. The two answers point in opposite directions for infrastructure planning.

The framework also decomposes the total execution cycle of a hybrid run into three parts: classical compute time, quantum compute time, and communication overhead. Each part can be optimized on its own, and Rcc falls out of the ratio between communication time and quantum compute time. The number is not a black box. An architect can recompute it for their own workload, with their own hardware assumptions, instead of taking a vendor's word for it.

Those assumptions matter. The Rcc thresholds in the paper depend on QPU gate times, decoder speeds, and interconnect latencies that are still moving targets. The team notes that the boundaries will need re-checking as fault-tolerant hardware and quantum networks mature. A reader using the framework today should treat the thresholds as a starting point, not a permanent rule.

One conclusion in the paper deserves extra weight. The authors repeatedly find that, for most application-level workloads, remote cloud access is sufficient. AWS is a co-author of this work and a seller of quantum cloud services, so the conclusion is worth weighing on its merits rather than repeating as gospel. The math that produces it is public and reproducible. The commercial interest is also public. Readers who run the same calculation for their own use case will be in a better position than those who take the headline as advice.

The author list, housed on arXiv, spans AWS, NVIDIA, LBNL, and NASA, which is a signal of where the fault-tolerant planning conversation is happening. These four institutions are not the only labs working on hybrid integration, but they are among the ones that have to write the largest checks first. The framework gives those checks a shape.

What the paper actually changes is narrow but real. There is now a number a CIO can ask a vendor to compute before buying a co-located quantum-classical rack, and a default answer for most of the workloads that buyers care about today. The next test is whether Rcc stays sharp as gate times drop, decoder speeds rise, and quantum networks arrive, or whether the boundaries have to be redrawn.