HybridQC: Hardware-Grounded Simulation of Tightly Integrated Hybrid Quantum-Classical Systems

arXiv:2607.13352 · cs.PF, quant-ph · Submitted 2026-07-15 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Quantum Radio. Generated commentary on the latest quantum physics and condensed matter papers.

Kai: We're looking at the paper: "HybridQC: Hardware-Grounded Simulation of Tightly Integrated Hybrid Quantum-Classical Systems".

Mira: The gist The end-to-end performance of hybrid quantum-classical applications is increasingly determined by classical control, host-to-QPU communication,

Kai: First, who's behind it and why it matters.

Title and authors: Kai: So we're looking at "HybridQC: Hardware-Grounded Simulation of Tightly Integrated Hybrid Quantum-Classical Systems" and the authors are Panayiotis Christou, Shuwen Kan, and Ying Mao from Fordham University. They’ve created a simulator for what they call tightly coupled hybrid compute units or HCUs.

Mira: What I see is that this isn't just simulating one piece of quantum hardware in isolation; they are modeling the whole system architecture, which means every decision you make about setting up a compute unit has to be considered with this in mind. It’s about the complete setup.

Lev: This implies we need tools that can answer questions like how many controllers do I actually need before the QPU stops being the bottleneck? Or when does adding more quantum capacity stop improving total time? We’re talking about real hardware constraints here.

The paper's summary: Kai: So to summarize what HybridQC does, it models every submitted job as a typed directed acyclic graph of stages. It’s not just one quantum step; it’s the whole pipeline that matters for performance, from input preparation all the way to classical postprocessing.

Mira: I think they emphasize that end-to-end behavior is shaped by these stages around that kernel, not just the kernel itself, which means we have to look at how input construction and result reconstruction affect things too. It’s about the whole pipeline flow.

Lev: They calibrate their backend service-time models using live measurements from D-Wave Advantage one and Advantage two systems, plus IBM Kingston processors on campaigns like Marrakesh and Fez <ref:2607.13352#pg1>. That hardware grounding is key to making the simulation meaningful for real deployment.

Kai: They also mention that they separate physical QPU occupancy from cloud provider overhead at the modeling level, which allows them to use the same data for both today’s validation and forecasting future integrated units.

Mira: So essentially HybridQC takes a job and simulates how it flows through this resource graph, letting you see exactly when controllers get overloaded or where contention shifts between QA and DQC devices as the job runs. It shows the system behavior in action.

The paper's improvements: Lev: One of the big things they found is that balanced ten times hardware scaling doesn't give you a ten times speedup; it only gives you about two point one nine to three point four two times improvement because the classical stages, controllers, and transfers stay on the critical path.

Kai: That’s a tough result to hear when people expect linear scaling, but it shows that even with more quantum hardware, if the classical parts are slow or overloaded they just bottleneck again. The system is limited by the slowest link.

Mira: They show pair sweeps demonstrating this: QA-controller replication can raise average throughput from two point eight five jobs per second up to nine point seven five jobs per second, which is a three point four three times gain in throughput, but the p95 completion time barely moves >

Lev: And they also found that scheduling policies matter a lot; queue management policy changes mixed-workload makespan by up to one point eight zero times, showing that you have to design your scheduler based on the topology and what kind of workload you’re running.

Kai: They tested several policies like FIFO, HOBA, Greedy Max Pressure, and Adaptive Batch-Optimal, and each one showed different bottleneck behaviors because they handle queue state or batching in a distinct way. The scheduling choice really matters for performance.

Conclusion: Mira: So to wrap up the HybridQC paper, the authors show that hardware-grounded profiles can accurately model system occupancy by calibrating backend metrics like D-Wave QPU access time and IBM quantum seconds. It's a way to get realistic numbers for performance modeling.

Kai: They prove that balanced resource scaling is better than just scaling the quantum processing units in isolation because it keeps the critical path moving through all those stages. The system needs balanced growth.

Lev: And they show that future workload scaling needs to be described by specific axes, like data, shots, and depth, because joint growth in circuit count and depth by one hundred times pushes runtime to about four point eight zero six times on the unchanged HCU. That’s a serious saturation point for DQC resources.

Mira: It suggests that you need to separate cloud wall time from physical resource occupancy when forecasting whether a proposed local accelerator design is viable versus just reducing the orchestration latency. It helps distinguish between building better hardware and just optimizing how you run it in the cloud.

Kai: This paper, "HybridQC: Hardware-Grounded Simulation of Tightly Integrated Hybrid Quantum-Classical Systems," gives us a practical way to validate today’s hybrid workloads while also forecasting where the next set of architectural bottlenecks are likely to appear.

Lev: It moves us from just simulating the quantum kernel to understanding the entire physical system, which is what we need for real hardware development.

Mira: That’s what this paper does, showing that understanding how everything connects is crucial for moving past just looking at individual components in a quantum computer.

Panayiotis Christou, Shuwen Kan, Ying Mao

Fordham University

cs.PF, quant-ph

Submitted: 2026-07-15

Updated: 2026-10-17

Code: https://github.com/quantumlib/Cirq

Project page: https://qiskit.github.io/qiskitaer

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 90/100

The gist: The gist The end-to-end performance of hybrid quantum-classical applications is increasingly determined by classical control, host-to-QPU communication, and resource scheduling rather than by quantum

Key concepts

HCU Abstraction: A model of a tightly coupled unit combining classical processors, memory, controllers, and both quantum computing types (QA/DQC). It treats all components as finite resources with explicit communication links to understand how they interact when running a job.
Hardware-Grounded Runtime Profiles: The simulator calibrates its service time models using live measurements from actual hardware like D-Wave and IBM processors. This allows it to accurately separate physical quantum processor occupancy from the overhead imposed by cloud providers.
Axis-Dependent Scaling Cliffs: This concept describes how performance scales differently depending on which workload parameter is increased (e.g., data vs. circuit count). It shows that while scaling data mildly has manageable effects, joint growth in circuits and depth can cause runtime to explode by orders of magnitude.
Scheduling Policies as Architectural Parameters: The simulator treats different queue management policies (like HOBA or GMP) not as settings, but as fundamental architectural choices. Changing these policies can significantly alter the makespan for mixed workloads, highlighting the need to co-design schedulers with the hardware topology.

Terminology

Hybrid Architecture — 1× in this paper · explained in 2 episodes
Hybrid Architectures — 1× in this paper · explained in 3 episodes
Quantum Annealing — 1× in this paper · explained in 2 episodes
Quantum Annealing (QA) — 1× in this paper · explained in 3 episodes

Summary

The gist The end-to-end performance of hybrid quantum-classical applications is increasingly determined by classical control, host-to-QPU communication, and resource scheduling rather than by quantum execution alone HybridQC introduces a topology-aware discrete-event simulator for tightly coupled hybrid compute units (HCUs) to address the gaps in existing tools that cannot determine when controllers become performance bottlenecks or how heterogeneous workloads redistribute contention across shared resources.

How it works

HybridQC models an HCU as a configurable graph containing classical processors, memory systems, controllers, quantum annealing (QA) and digital quantum computing (DQC) devices, and explicit communication links. Each submitted job is decomposed into a typed directed-acyclic graph of stages including input preparation, embedding or transpilation, controller programming and readout, QA or DQC execution, data transfer, result reconstruction, and classical postprocessing. The simulator calibrates its backend service-time models using live measurements from D-Wave Advantage 1 and Advantage 2 systems and IBM Kingston processors.

The HCU abstraction is built around three design decisions to enable topology-level reasoning. First, an HCU is represented as a directed resource graph where CPUs, GPUs, QA devices, DQC devices, controllers, memories, and interconnects are all modeled as finite-capacity first-class resources. Second, hybrid workloads are lowered into typed stage directed acyclic graphs (DAGs) that make every pipeline dependency explicit. Third, physical QPU occupancy is separated from cloud provider overhead at the modeling level.

Key Contributions

The paper makes 4 key contributions based on validation against today’s IBM and D-Wave hardware.

** Hardware-grounded runtime separation. HybridQC calibrates backend-specific profiles with 3.92%–8.04% MAPE for D-Wave QPU access time and 5.26%–19.01% error for IBM quantum seconds, using D-Wave SampleSets and IBM Kingston, Marrakesh, and Fez campaigns. It separates physical QPU occupancy from cloud provider overhead so the same data can support both present-day validation and future integrated-HCU forecasting. 4.4 Hardware-Grounded Runtime Profiles**

** Non-linear topology scaling and persistent bottlenecks. Balanced 10× hardware scaling improves makespan by only 2.19×–3.42× rather than 10×, because controllers, transfers, and classical stages remain on the critical path. Pair sweeps show why: QA-controller replication raises average throughput from 2.85 to 9.75 jobs/s, while DQC-controller replication reduces p95 completion time from 7601 s to 6348 s. **

** Scheduling policies as first-class architectural parameters. Queue management policy changes mixed-workload makespan by up to 1.80×, showing that scheduler selection must be co-designed with topology and workload composition. FIFO, Hybrid Overhead-Balanced Adaptive (HOBA), Greedy Max Pressure (GMP), Adaptive Batch-Optimal (ABO), and Max-Pressure expose different bottleneck behavior because they use queue state, batching, feed urgency, and pressure differently. **

** Axis-dependent scaling cliffs. We scale data, shots, circuit count, depth, and all workload fields separately across QA-only, DQC-only, and QA+DQC workloads. 100× data-only scaling produces manageable transfer pressure at a median of 306 s, whereas 100× joint growth in circuit count, shots, and depth reaches about 4.806 × 107 s on the unchanged HCU. **

Workload and Scaling Semantics

HybridQC represents a hybrid workload as a system-level multi-stage DAG whose nodes carry a resource type, runtime model, memory requirement, payload size, routing metadata, and predecessor dependencies. The second design choice is to keep workload parameters visible rather than collapsing them into one service-time multiplier. The third design choice is to scale workloads along explicit axes: data, shots, depth, circuit count, circuit-shot product, circuit-shot-depth product, and all fields.

Evaluation Methodology

The evaluation separates validation from forecasting. Validation asks whether the multi-stage runtime models used by HybridQC are compatible with live hardware measurements while forecasting asks what those grounded models imply for full hybrid workloads running on proposed tightly integrated topologies. The evaluation is organized around questions V1 through S1, including Hardware grounding, Topology balance, Scheduling policies as first-class architectural parameters, and Workload scaling.

Results on Scaling and Bottlenecks

The results show that balanced 10× hardware scaling improves makespan by only 2.19×–3.42× rather than 10×, because controllers, transfers, and classical stages remain on the critical path. The pair-sweep data sharpen this result without needing another main-text matrix. QA-controller replication gives the strongest throughput improvement: average throughput increases from 2.85 to 9.75 jobs/s, a 3.43× gain, while p95 completion time changes little. The best topology extension depends on the objective.

Conclusion

HybridQC provides a hardware-grounded simulator for tightly integrated hybrid quantum-classical systems. It shows that backend-specific profiles can ground system-level QA and DQC occupancy, that balanced resource scaling is more effective than isolated QPU scaling, and that scheduling policy changes mixed-workload throughput. It also shows that cloud wall time should be separated from physical resource occupancy. It also shows that future workload scaling must be described by axes, where data-only scaling is mild, while joint growth in circuit count, shots, and depth can saturate DQC resources by orders of magnitude. It offers a practical path for validating today’s hybrid workloads and forecasting tomorrow’s architecture bottlenecks.

Discussion and Limitations

HybridQC is designed for topology-level reasoning, not quantum-state simulation. It consumes circuit/QUBO properties, backend measurements, topology definitions, and stage graphs. The main limitations are scope and extrapolation; HybridQC is not a circuit-state simulator or provider Runtime replacement.

Final Summary

HybridQC provides a hardware-grounded simulator for tightly integrated hybrid quantum-classical systems. By validating service models on live IBM and D-Wave measurements and applying them through a topology-aware discrete-event engine, it lets researchers evaluate full hybrid workloads and forecast bottlenecks in machines that do not yet exist. The evaluation shows that backend-specific profiles can ground system-level QA and DQC occupancy, that balanced resource scaling is more effective than isolated QPU scaling, that scheduling policy changes mixed-workload throughput, and that cloud wall time should be separated from physical resource occupancy. It also shows that future workload scaling must be described by axes, where data-only scaling is mild, while joint growth in circuit count, shots, and depth can saturate DQC resources by orders of magnitude. It offers a practical path for validating today’s hybrid workloads and forecasting tomorrow’s architecture bottlenecks.

Improvements for AI systems

Bold HCU Topology Reasoning: The system can evaluate how every pipeline stage contends for finite resources across the entire hardware topology by modeling an HCU as a directed resource graph where CPUs, GPUs, QA devices, DQC devices, controllers, memories, and interconnects are all modeled as finite-capacity first-class resources.
Non-linear Scaling Analysis: The system can forecast architectural saturation by analyzing Axis-dependent scaling cliffs, specifically identifying that joint growth in circuit count, shot count, and depth by 100× increases runtime to 4.806 × 107 s on the unchanged HCU.
Policy-Driven Bottleneck Migration: The AI can dynamically select scheduling policies based on workload composition, as policy changes the makespan by up to 1.80×, specifically using policies like HOBA, GMP, and Max-Pressure to prioritize stages that relieve downstream queues or pressure points.
Hardware-Grounded Service Modeling: The system can ground service time models using live measurements, ensuring that physical QPU occupancy is separated from cloud provider overhead at the modeling level by calibrating profiles based on metrics like D-Wave QPU access time or IBM quantum seconds.
Cloud-Integrated vs. Local Deployment Forecasting: The system can perform dual execution semantics, using physical resource occupancy for tightly integrated HCU forecasts while retaining provider wall time as an optional cloud-execution mode, allowing it to determine if a proposed local accelerator design is viable versus simply reducing orchestration latency.