SerpApi.Org
A team from Amazon Web Services, NVIDIA, Lawrence Berkeley National Laboratory, and NASA published a paper this week that settles one of the most expensive open questions in quantum computing infrastructure: when does a quantum processor actually need to be physically next door to a supercomputer, and when is a cloud connection perfectly fine?
The answer, for most algorithms running today, is that it doesn't. And that finding has direct implications for national laboratories and government agencies deciding right now whether to commit tens to hundreds of millions of dollars to physical quantum-HPC co-location infrastructure, according to quantum infrastructure cost analysis.
The paper, published July 20 on arXiv and simultaneously highlighted on the AWS Quantum Technologies Blog, introduces a quantitative metric called the communication-to-computation ratio — Rcc — that gives infrastructure planners a computable answer rather than an educated guess. As described in arXiv 2607.15426, the metric's central finding is that the majority of hybrid quantum-classical algorithms running on today's noisy intermediate-scale quantum (NISQ) hardware are so heavily dominated by classical computation that the latency of a cloud connection is essentially irrelevant. Only quantum error correction — the enabling technology for large-scale fault-tolerant quantum computing — represents a hard, non-negotiable co-location requirement.
Two Problems That Have Been Confused for Years
Understanding why the paper matters requires separating two things the quantum computing community has routinely conflated: the real-time control requirements of quantum hardware and the application-level communication requirements of hybrid quantum algorithms. They operate on entirely different timescales, and mixing them up leads to infrastructure decisions built on the wrong constraint.
At the real-time level, quantum processors require classical systems to keep pace with the physical operation of the device itself. Quantum error correction decoding is the primary example: for superconducting qubits — the dominant technology in today's largest systems — syndrome extraction cycles run every one to ten microseconds, and the classical decoder must complete its correction within that window, as established by Google's Willow surface code research. If the decoder falls behind, errors accumulate faster than they can be corrected, and the logical computation collapses. This is a feasibility constraint, not a performance preference. No amount of clever algorithm design removes it.
At the application level, hybrid algorithms like variational quantum solvers and quantum-enhanced sampling routines exchange data between a quantum processor and a classical host repeatedly — but between circuit executions, not during them. The classical computer has time to do substantial work before the quantum device needs its next set of instructions. For this tier, the relevant question is not "can the classical system keep up with the qubit?" but "how much of the total workflow runtime is consumed by waiting for data to travel over a network?" That question is exactly what the Rcc metric answers, as detailed in the full paper.
A Roofline Model for Quantum-Classical Systems
The Rcc metric works by decomposing the total cycle time of a hybrid quantum-classical workflow into three components: quantum compute time (TQ), classical compute time (TC), and communication overhead (Tcomm). From these, the ratio is:
Rcc = Tcomm / (TC + TQ)
When Rcc is much less than one, communication overhead is negligible relative to actual computation. Co-location would shave almost nothing off the total runtime. When Rcc is much greater than one, the workflow spends most of its time waiting for data to travel — and low-latency physical coupling materially accelerates it.
The researchers explicitly drew the analogy to the roofline model, a foundational tool in classical HPC planning that separates applications into compute-bound (limited by processor throughput) and memory-bound (limited by data movement bandwidth). The Rcc metric creates the same two regimes for quantum-classical systems. For any HPC professional who has ever used roofline analysis, the framework is immediately interpretable without new vocabulary.
What the Numbers Say About Algorithms Running Today
The paper's most concrete contribution is applying the Rcc formula to specific, published NISQ algorithm demonstrations on real hardware — replacing intuition with numbers.
Sample-based quantum diagonalization (SQD), IBM's leading near-term approach to quantum chemistry, combines shallow quantum circuits with substantial classical post-processing to estimate the ground-state energies of molecular systems. The algorithm samples electronic configurations from the quantum processor, then uses a classical computer to project and diagonalize the molecular Hamiltonian within the subspace those samples define. That classical diagonalization step is computationally expensive — and that expense is exactly why SQD's Rcc comes in at approximately 10⁻⁴ on 77 qubits of IBM's Heron processor, according to the paper. Four orders of magnitude below the communication-bound threshold. Even a wide-area network connection introduces negligible overhead relative to the time the classical system spends on the problem.
The generative quantum eigensolver (GQE), which trains an AI model using quantum energy feedback, produces Rcc values in the range of 10⁻³ to 10⁻¹ under a variety of compute-scaling assumptions. Still firmly cloud-adequate.
Quantum-enhanced Markov chain Monte Carlo (QE-MCMC), which accelerates sampling from complex probability distributions, sits on the opposite end of the spectrum at Rcc approximately 10³ under remote-access assumptions on a ten-qubit IBM device, as quantified in the paper. Each algorithmic step requires a rapid round-trip between the quantum processor and the classical host, with very little computation on either side. But the paper adds an important nuance that the headline Rcc figure obscures: the classical step in QE-MCMC is estimated to take roughly ten nanoseconds per iteration. That workload does not require a supercomputer. A low-latency classical node suffices. Co-location with a multi-petaflop HPC system would be overcapacity by a wide margin.
Quantum error correction is the starkest case for co-location and the one case where no amount of Rcc optimization changes the answer. As quantum processors scale toward fault-tolerant operation, QEC becomes unavoidable — and its microsecond latency requirement makes physical proximity to the classical decoder non-negotiable, as demonstrated by real-time QEC work on Rigetti's Ankaa-2 processor. The paper confirms this as a hard feasibility constraint that the Rcc framework categorizes separately from application-level analysis.
Why Co-Location May Be Premature for Most Labs Today
The capital implications of the Rcc findings are the part the paper handles carefully but that deserves sharper framing for infrastructure decision-makers.
Several of the highest-profile quantum-HPC co-location projects in the world are currently under way or recently completed. Japan's RIKEN demonstrated a co-located IBM Quantum Heron processor coupled to all 152,064 nodes of the Fugaku supercomputer in a closed-loop quantum chemistry simulation — the largest quantum-HPC co-execution by node count to date, as documented in a 2026 survey of quantum-integrated HPC. Oak Ridge National Laboratory deployed IQM's Pathfinder processor on the Frontier campus and is developing an NVIDIA GB200 NVL72 system alongside both IQM and Quantum Brilliance processors for hybrid benchmarking. The Center for Strategic and International Studies identified integrating quantum computers into U.S. supercomputers as a strategic national priority as recently as March 2026, according to the same survey.
What the Rcc framework now adds to that landscape: a concrete, quantitative basis for determining which workloads justify those investments and which do not. For most of today's NISQ algorithms — the ones that actually exist and run today — the Rcc analysis shows that the co-location infrastructure would offer negligible runtime benefit. The capital case for expensive co-location exists primarily in the fault-tolerant era that is still approaching, not in the NISQ era that is here now. Infrastructure planners who treat those two eras as continuous risk committing large capital budgets based on requirements that arrive after the relevant hardware generation has already passed.
The paper is careful to note this distinction: once tight quantum-classical integrations become standard infrastructure, algorithm designers will develop new approaches that exploit low-latency coupling at the application level in ways that today's NISQ algorithms cannot. The Rcc metric is not a verdict against co-location. It is a tool for knowing when, precisely, the time has come — and the tool currently says "not yet" for most compute-heavy workflows, as the HPCwire coverage of the framework details.
How the Framework Stays Current as Hardware Evolves
One of the paper's more practically significant contributions is its built-in mechanism for updating infrastructure decisions as technology changes. The Rcc metric is not a static verdict — it identifies specific crossover conditions that would shift specific algorithms from cloud-adequate to co-location-required.
Two named examples from the paper: dramatic reductions in the number of circuit shots required, achievable through amplitude estimation techniques, would shrink TQ while leaving Tcomm constant, pushing Rcc upward; the emergence of practical quantum memory would change the data-exchange architecture of many hybrid workflows in ways that might demand tighter coupling. Tracking these developments using the Rcc formula allows infrastructure planners to update their analysis as hardware capabilities change, rather than making a single irreversible bet on the current state of the technology, as arXiv 2607.15426 explains.
That adaptability addresses a genuine risk in the quantum infrastructure landscape: the technology is evolving fast enough that a co-location decision made today purely on the basis of current algorithm behavior might be wrong for the hardware generation that is actually installed when the construction is complete.
Behind the Paper
The research was published July 20, 2026, on arXiv as "Performance Model for Hybrid Quantum-Classical Workflows." Lead authors are Dimitar Trenev and Elica Kyoseva of AWS; co-authors Pooja Rao of NVIDIA and Tyler Takeshita, Cedric Lin, Peter Komar, Jerome Gonthier, and Sebastian Stern are affiliated with AWS, LBNL, and NASA. The paper is open access at arxiv.org/abs/2607.15426. AWS's concurrent post on the AWS Quantum Technologies Blog provides an accessible summary of the framework.
Frequently Asked Questions
When does a quantum computer actually need to be physically next to a supercomputer?
For most algorithms running on today's quantum hardware, it doesn't. The new Rcc metric introduced by researchers at AWS, NVIDIA, Lawrence Berkeley National Laboratory, and NASA shows that compute-intensive hybrid algorithms — particularly quantum chemistry applications like sample-based quantum diagonalization — spend such a large fraction of their total runtime on classical post-processing that network communication overhead is negligible. The one confirmed exception is quantum error correction (QEC): the classical decoder for a fault-tolerant quantum system must respond to error syndromes within one to ten microseconds, a timing requirement that makes physical co-location mandatory regardless of the algorithm's Rcc value.
What is the Rcc metric and how do you use it?
Rcc is the communication-to-computation ratio: the total communication overhead of a hybrid quantum-classical workflow divided by the sum of its quantum and classical compute times (Tcomm / (TC + TQ)). If Rcc is much less than one, the workflow is compute-bound and cloud connectivity is adequate. If Rcc is much greater than one, the workflow is communication-bound and low-latency co-location will materially reduce runtime. The metric is a direct analogue to the roofline model used in classical HPC to separate memory-bound from compute-bound applications. Infrastructure planners can compute Rcc for their specific workloads using published or measured values of TC, TQ, and Tcomm.
Should national labs stop investing in quantum-HPC co-location?
Not necessarily, but they should be precise about which workloads justify the investment. For current NISQ algorithms, the Rcc analysis shows that co-location typically offers negligible runtime benefit — the money is being spent ahead of the requirement. The capital case for extensive physical integration grows stronger as quantum processors scale toward fault-tolerant operation and QEC becomes unavoidable. Facilities like ORNL (with IQM Pathfinder) and RIKEN (with IBM Heron coupled to Fugaku) are making co-location investments now, in part to develop the software tools and operational experience that fault-tolerant hardware will require. The Rcc framework is a tool for distinguishing between that forward-investment logic and infrastructure spending that has no clear technical justification given today's algorithm landscape.
Can Rcc predict when specific algorithms will need co-location in the future?
Yes — that is one of the paper's explicit contributions. The Rcc metric identifies named crossover conditions that would shift an algorithm from cloud-adequate to co-location-required. Two examples from the paper: if amplitude estimation techniques dramatically reduce the number of circuit shots needed for quantum chemistry calculations, the quantum compute fraction of the workflow shrinks and Rcc rises; if practical quantum memory becomes available, the data-exchange architecture of many hybrid workflows changes in ways that could require tighter coupling. Infrastructure planners can re-run the Rcc analysis as hardware capabilities change, rather than committing to a fixed infrastructure posture based on the current technology snapshot.
Related Articles
