AWS Quantum Technologies Blog

A framework for quantum-classical integration decisions

This post was contributed by Dimitar Trenev, Sebastian Stern, Tyler Takeshita, Cedric Lin, Peter Komar, Pooja Rao, Jerome Gonthier, and Elica Kyoseva.

As quantum computing matures toward fault tolerance, a pressing question faces the high-performance computing (HPC) community: why is tightly integrating quantum processors to classical supercomputing infrastructure important?

Today, algorithm researchers from Amazon Web Services (AWS), Lawrence Berkeley National Laboratory (LBNL), National Aeronautics and Space Administration (NASA), and NVIDIA published a performance model for hybrid quantum-classical workflows that evaluates whether a given hybrid workload is accelerated by low-latency integration of quantum and classical resources, or if standard network connectivity is sufficient.

Two levels, two different answers

Discussions about quantum-classical connectivity often conflate two fundamentally different concerns: the need for low-level real-time control of quantum hardware, and the need for communication requirements at the application level. Our paper separates them explicitly into two levels.

The real-time level primarily refers to the control and calibration tasks as well as quantum error correction (QEC), where classical decoders process error syndromes and apply corrections and calibration tasks needed to keep quantum processors performing correctly. The decoder and control stack must keep pace with the syndrome-extraction cycle and react fast enough that the correction latency does not exceed the logical gate cycle (microseconds for superconducting devices); low-latency coupling here is non-negotiable.

The application level is where hybrid algorithms, such as variational solvers and quantum-enhanced sampling, perform the computation by repeatedly exchanging data between a classical host and a quantum processing unit (QPU). Current approaches to hybrid algorithms do not generally rely on classical processing completing within a device-imposed timescale — either the workflow exchanges data only between circuit executions (today’s noisy intermediate-scale quantum, or NISQ, algorithms), or a fault-tolerant logical QPU hides the real-time QEC loop.

Figure 1 illustrates these two levels in a single compute cycle.

Figure 1: Compute cycle, a round trip between classical and quantum resources. The compute cycle (a full round trip between classical and quantum computer) decomposes into classical compute time (TC), quantum compute time (TQ), and communication overhead (Tcomm). At the real-time level, the QPU and the real-time host must exchange data and complete classical processing (e.g., calibration, QEC decoding) within a device-imposed timescale (τphys), otherwise execution fails. At the application level, how much communication overhead degrades runtime performance depends on the ratio between computation (TC + TQ) and communication times (Tcomm).

Figure 1: Compute cycle, a round trip between classical and quantum resources. The compute cycle (a full round trip between classical and quantum computer) decomposes into classical compute time (TC), quantum compute time (TQ), and communication overhead (Tcomm). At the real-time level, the QPU and the real-time host must exchange data and complete classical processing (e.g., calibration, QEC decoding) within a device-imposed timescale (τphys), otherwise execution fails. At the application level, how much communication overhead degrades runtime performance depends on the ratio between computation (TC + TQ) and communication times (Tcomm).

A diagnostic for integration decisions

One can decompose the total cycle time of a hybrid workflow into three components: classical compute time (TC), quantum compute time (TQ), and communication overhead (Tcomm). From this, we derive the communication-to-computation ratio, Rcc = Tcomm / (TC + TQ), which indicates whether a workflow is compute-bound or communication-bound:

·       If Rcc 1, communication overhead is negligible relative to computation, and co-location offers little benefit to speeding up hybrid algorithm execution.

·       If Rcc 1, the workflow is communication-dominated, and low-latency integration materially improves performance.

These two cases are analogous to the two sides of classical HPC’s roofline model, where attainable performance is bounded by peak performance on one side and by peak bandwidth on the other.

Case-by-case analysis

Though utility-scale applications will fundamentally and unavoidably rely on low-latency quantum-classical integrations, due to the need to maintain logical qubits, for workflows analyzed at the application level (such as today’s NISQ algorithms) the case is not so clear-cut.

We applied the model to specific, published NISQ algorithm demonstrations, putting concrete numbers on intuitions the community holds with varying confidence. This led to the following conclusions.

Compute-intensive workflows lose only a negligible fraction of runtime to communication, so remote access suffices. Sample-based quantum diagonalization (SQD), a leading near-term approach for quantum chemistry, combines shallow quantum circuits with heavy classical diagonalization. Its Rcc is approximately 10⁻⁴ (measured on 77 qubits of IBM’s Heron device), meaning communication overhead is negligible even over wide-area networks. The generative quantum eigensolver (GQE), which trains an AI model using quantum energy feedback, also shows low Rcc values (10⁻³ – 10⁻¹) even under extensive compute scaling assumptions.

Today, communication-dominated workflows need low latency, but not supercomputers. Quantum-enhanced Markov chain Monte Carlo (QE-MCMC), which accelerates sampling from complex probability distributions, has an Rcc of ~ 10³ assuming remote access (on a 10-qubit IBM device); this is because each step of the algorithm requires a rapid round-trip with minimal computation on either side. It is important to consider that while this workflow needs low-latency connectivity, it does not require heavyweight compute resources for the classical step, which is estimated to take ~10 nanoseconds per iteration.

Error correction requires low latency. As QPU systems scale up and applications begin drawing on logical qubits, quantum error correction becomes indispensable. Co-location of QPUs with HPC will be increasingly important once QEC requires low-latency and high-performance compute.

Looking ahead

Though the importance of quantum-classical integration in building the logical qubits needed for large-scale quantum computing is not in doubt, our paper helps clarify precisely where this integration remains important.

Our assessment on its relevance at the application level is a product of our knowledge of today’s hybrid algorithms; once tight quantum-classical integrations exist, future approaches to quantum algorithms may well be developed that take advantage of them at the application level. Furthermore, our paper identifies specific crossover conditions, e.g. dramatic shot-budget reductions via amplitude estimation, and the emergence of practical quantum memory, under which the integration requirements of even today’s algorithms will shift. The model provides a quantitative method to track these developments and update infrastructure plans accordingly.

As AWS deepens its commitment to fault-tolerant quantum computing — including our strategic collaboration with QuEra to bring fault-tolerant quantum computing to Amazon Braket — resource estimation frameworks like this help the community make informed, evidence-based decisions about how to prepare.

To learn more about how AWS is building toward a fault-tolerant quantum future, visit Amazon Braket or reach out to our team at amazon-braket-customers@amazon.com.

The full paper is available on arXiv: https://arxiv.org/abs/2607.15426