A Reference Architecture for Hybrid Quantum-HPC Workflows
A whitepaper-style blueprint for running variational and sample-based quantum algorithms inside GPU-accelerated HPC pipelines — layers, scheduling, data paths and the metrics that matter.
Prakash Gore · · 3 min read
Executive summary
Quantum processors will reach users first as accelerators inside high-performance computing, not as standalone computers. This paper proposes a five-layer reference architecture for hybrid quantum-HPC workflows, identifies latency and cost as the dominant engineering constraints, and defines metrics teams should report to make results comparable.
1. The problem
A typical variational loop — VQE, QAOA, or a quantum generative model — alternates between a QPU (evaluate a circuit thousands of times) and a classical optimiser (update parameters). In practice:
- QPU access is queued and shared; wait times can dwarf execution time.
- Parameter updates are cheap, but round-trips between cloud QPU and on-prem GPUs add latency per iteration.
- Teams run GPU simulators for development and baselines, but manage them separately from QPU credits.
The result is wall-clock times dominated by orchestration, not physics.
2. Five-layer architecture
| Layer | Responsibility | Example technologies |
|---|---|---|
| L5 · Workflow | Experiment definition, versioning, reproducibility | Python, notebooks, MLflow / W&B |
| L4 · Orchestration | Decompose problems, route sub-tasks, co-schedule | Ray, Slurm, Kubernetes |
| L3 · Hybrid runtime | Kernels spanning CPU, GPU and QPU | CUDA-Q, Qiskit Runtime, PennyLane |
| L2 · Execution back-ends | GPU statevector / tensor-network simulators, cloud QPUs | cuQuantum, Aer, Braket, IBM Quantum |
| L1 · Telemetry & cost | Shots, queue time, fidelity, spend | Prometheus, OpenTelemetry |
3. Routing decisions
The orchestration layer decides, per circuit, where to run it. A simple cost model works surprisingly well:
route(circuit) =
if qubits ≤ SIM_LIMIT and depth·shots small → GPU statevector
elif circuit is low-entanglement → tensor-network simulator
elif budget allows and fidelity sufficient → QPU (batch with peers)
else → circuit cutting → smaller QPU jobs + classical reconstruction
Batching is the most under-used optimisation: grouping parameter sweeps into a single session amortises queue time across many circuit evaluations.
4. Sample-based loops
A promising pattern is the sample-and-refine loop: the QPU generates candidate configurations (for example, important electronic configurations in a chemistry problem), and the GPU cluster performs a classical diagonalisation in the subspace they span. The quantum device does what it's best at — sampling — while the HPC system does what it is best at — dense linear algebra.
5. Metrics to report
To make hybrid results comparable, we recommend every study report:
- Time-to-solution end-to-end, broken down into queue, transfer, QPU and classical time.
- Cost-to-solution in shots and currency.
- Quality vs. classical baseline at matched compute budget.
- Variance across seeds and calibration windows.
6. Outlook
As error-corrected logical qubits arrive over the next few years, layers L3–L5 should not need to change — only L2. Teams that build clean abstractions now will absorb hardware progress as a configuration change, not a rewrite.