High-Performance Quantum Computing

• High-Performance Quantum Computing (HPQC) is the integration of quantum processing units with classical high-performance systems, serving as specialized accelerators for select computational tasks.
• HPQC frameworks employ diverse integration models—from loose to on-node configurations—that balance latency, communication overhead, and scheduling to enable efficient hybrid workflows.
• Architectural designs in HPQC emphasize rigorous hardware-software co-design and fault-tolerant error correction, ensuring effective quantum acceleration in simulation, optimization, and scientific applications.

Searching arXiv for recent and foundational papers on HPQC, HPC–QC integration, quantum simulation/tomography, and fault-tolerant architectures. High-Performance Quantum Computing (HPQC) denotes the integration of quantum computing into high-performance computing infrastructures as a heterogeneous accelerator model rather than a replacement for classical supercomputing. In this framing, the quantum processing unit (QPU) is embedded inside a larger computational stack in which classical HPC resources remain essential for orchestration, preprocessing, postprocessing, compilation, simulation, benchmarking, optimization, error mitigation, and certification. The resulting system is hybrid at every level: architectural, algorithmic, and operational (Buchs et al., 15 Aug 2025, Elsharkawy et al., 2023, Britt et al., 2017).

1. Conceptual foundations

The central premise of HPQC is that QPUs are specialized accelerators for selected kernels, analogous in deployment logic to GPUs and co-processor cards, but governed by very different physical and algorithmic constraints. Early system papers already framed quantum computing as part of a hybrid accelerated computing platform, with the host CPU orchestrating execution and the QPU offloading only those subroutines for which efficient quantum algorithms exist (Möller et al., 2017). Later surveys and system studies sharpened this view by arguing that even fully error-corrected quantum computers will not be suited to all tasks, and that future compute infrastructures are therefore expected to employ quantum acceleration within hybrid HPC+QC systems (Buchs et al., 15 Aug 2025).

This accelerator model is motivated by several asymmetries between classical and quantum computation. Classical HPC remains the scalable engine for data movement, scheduling, optimization loops, simulation, and workflow management; QPUs contribute only where superposition, entanglement, or quantum-native search and simulation provide leverage. Reviews of quantum algorithms for scientific computing accordingly identify the most credible HPC-relevant targets as simulation of quantum systems, optimization, and machine learning or linear-algebra subroutines, while emphasizing that practical utility depends on integration into real workflows rather than isolated asymptotic complexity claims (Au-Yeung et al., 2023).

The same literature also rejects a common misconception: HPQC is not defined by replacing classical computation with a monolithic quantum machine. It is instead a systems problem in which CPUs, GPUs, FPGAs, simulators, emulators, controllers, and QPUs must be coordinated with explicit attention to latency, calibration state, communication overhead, and probabilistic output semantics (Britt et al., 2015, Rallis et al., 7 Sep 2025).

2. Integration models and architectural organization

Architectural work on HPQC distinguishes multiple integration pathways. A foundational division is between loose integration, where QPUs remain relatively isolated and are accessed through a network interface in a client-server style model, and tight integration, where QPUs are brought much closer to host CPU nodes and begin to resemble local accelerators (Britt et al., 2015). Later overviews refine this into a four-stage progression spanning standalone access, loosely coupled co-location, tightly integrated co-location, and on-node integration (Rallis et al., 7 Sep 2025, Elsharkawy et al., 2023).

Integration model	Defining characteristic	Main tradeoff
Standalone / loose	QPU accessed independently through web, cloud, or network interface	Easiest deployment; highest latency
Loose co-located	HPC and QPU are separate but coordinated hybrid resources	Practical today; communication overhead remains significant
Tight co-located	Low-latency interconnect and coordinated scheduling across classical and quantum resources	Better hybrid performance; higher facility and middleware complexity
On-node	QPU embedded as a node-level accelerator	Minimal communication overhead; hardest packaging and cryogenic co-design

The importance of coupling strength follows directly from the behavior of hybrid algorithms. Variational methods, iterative optimization, and real-time feedback can lose any quantum speedup if classical–quantum communication is slow, so the architectural objective is not merely access to a QPU but a latency regime compatible with repeated offload and return (Elsharkawy et al., 2024). This has led to proposals for tiered execution models in which CPU-only, CPU+GPU, tightly integrated CPU+GPU+QPU, and remote/cloud QPU resources are treated as distinct scheduling classes under a unified resource framework (Raj et al., 17 Apr 2026).

A further architectural issue is whether multiple QPUs are only classically aggregated or are quantum-mechanically interconnected. For $q$ QPUs with $n$-qubit registers, the capacity contrast is explicit: separate QPUs correspond to a Hilbert-space dimension $q 2^n$, whereas interconnected QPUs linked by a quantum interconnect correspond to $2^{n q}$ (Britt et al., 2015). This does not itself guarantee speedup, but it shows why the quantum interconnect is treated as part of the computational substrate rather than a mere network peripheral.

3. Software stacks, programming models, and runtime systems

The software problem in HPQC is as central as the hardware problem. Reviews of quantum programming tools from an HPC perspective organize the relevant criteria into host language, execution model, toolchain support, software scalability, cross-technology execution, data management, resource management, and legacy-code modernization, and conclude that no current tool satisfies all criteria for full HPQC integration (Elsharkawy et al., 2023). As integration becomes tighter, the required software properties become more HPC-like: compiled-language support, backend retargetability, coherent runtime coordination, and explicit interaction with resource managers.

Execution-model taxonomy reflects this evolution. The abstract QRAM model remains useful conceptually, but most realistic systems are closer to restricted or refined heterogeneous quantum-classical computing models, in which a classical host interacts with a quantum co-processor through a control layer rather than directly at qubit granularity (Elsharkawy et al., 2023). This has pushed several projects toward intermediate representations and runtime abstractions that separate frontend languages from backend control hardware.

A prominent example is the Unified Quantum Platform (UQP), which is defined by three components: a runtime library, an instruction set architecture, and a quantum control processor microarchitecture. The runtime accepts a QIR-based quantum kernel, extracts metadata such as quantum register size and number of shots, translates the program into unified 32-bit binary instructions, and forwards these to a technology-agnostic control backend. The workflow is reported as verified step-by-step, including a Bell-state example showing correspondence from a Qiskit circuit to QIR to executable binary (Elsharkawy et al., 2024).

Full-stack HPC-QC frameworks extend this idea upward into mainstream supercomputing environments. One such framework exposes portable invocation of quantum kernels from C/C++, Fortran, and Python, consumes LLVM IR and QIR, and adds an adaptive circuit knitting hypervisor to partition circuits across smaller QPUs or simulators (Zhan et al., 23 Oct 2025). Another proposal, NVQLink, extends CUDA-Q with cudaq::device_call and cudaq::device_ptr<T> so that quantum kernels can invoke real-time callbacks and marshal data across CPU, GPU, FPGA, and quantum-system-controller resources within a single C++ program, avoiding an HTTP-based interface (Caldwell et al., 29 Oct 2025). Collectively, these efforts define HPQC software as a layered environment of high-level language bindings, intermediate representations, compilation passes, controller interfaces, and hybrid runtimes rather than a single quantum SDK.

4. Classical HPC as simulator, emulator, and characterization engine

A distinctive feature of HPQC is that classical HPC remains indispensable even when direct like-for-like simulation of the target quantum device becomes impossible. Two roles are especially important: large-scale simulation or emulation of quantum programs, and large-scale characterization or certification of quantum hardware.

The simulation role is illustrated by qHiPSTER, a distributed high-performance simulator of pure-state quantum circuits. It stores a dense state vector of $2^n$ complex amplitudes, with memory cost

$$2^n \text{ complex amplitudes} = 2^{n+4}\ \text{bytes},$$

and supports general single-qubit gates and two-qubit controlled gates (Smelyanskiy et al., 2016). On the TACC Stampede supercomputer, qHiPSTER simulated up to 40 qubits, including a 40-qubit quantum Fourier transform run in 997 seconds using 1024-node distributed simulation. Its implementation combined vectorization, OpenMP multithreading, cache blocking through gate fusion, distributed-memory decomposition, and overlap of computation with communication; performance analysis showed that runtime was limited either by sustainable memory bandwidth or by network bandwidth (Smelyanskiy et al., 2016).

The characterization role is exemplified by scalable detector tomography. In that setting, HPC is not used to simulate the quantum device itself, but to reconstruct its quantum-mechanical description from tomographically complete probe data. For detector tomography, the measurement probabilities satisfy

$p_{\rho,n}=\mathrm{Tr}\!\left[\rho \,\pi_n\right],$

which, after collecting probe states, becomes

$P = F\Pi.$

For the phase-insensitive detectors studied experimentally, each POVM is diagonal in the number basis,

$$\pi_n=\sum_{k=0}^{M-1}\theta_k^{(n)}|k\rangle\langle k|,$$

so reconstruction reduces to estimating the diagonal response coefficients $\theta_k^{(n)}$ (Schapeler et al., 2024).

The reported scale is unusual even by HPC standards. The experimental reconstruction covered a Hilbert space

$n$0

with $n$1 detector outcomes and $n$2 probe states, corresponding to about $n$3 POVM matrix elements reconstructed in minutes of computation time. The solver was designed around a two-stage, two-metric projected Newton method rather than generic CVXPY/MOSEK convex optimization, and the implementation combined MPI and OpenMP with row-block distribution of $n$4, sparse and banded handling of $n$5, and an efficient butterfly communication pattern (Schapeler et al., 2024). The same work reports feasibility up to $n$6 free parameters, roughly 27 TB of POVM storage, and reconstruction fidelities above 99% for all occupied outcomes, with long-range-smoothed average fidelity 99.69% up to $n$7 (Schapeler et al., 2024).

Taken together, these two strands clarify a central HPQC distinction. Simulation confronts the exponential state-space wall directly; characterization and certification exploit experimentally accessible structure and remain classically meaningful beyond the reach of direct simulation. This is why HPC remains essential even when the target quantum system has already surpassed workstation-scale emulation (Schapeler et al., 2024, Smelyanskiy et al., 2016).

5. Hybrid workloads and scientific application domains

HPQC is ultimately justified by workloads. Much of the current literature therefore focuses on hybrid algorithms in which the classical HPC layer handles decomposition, orchestration, and aggregation while the quantum layer evaluates smaller kernels.

A representative example is Distributed Quantum Approximate Optimization Algorithm (DQAOA) for large QUBO problems. The method decomposes a size-$n$8 QUBO into sub-QUBOs of size $n$9, solves them in parallel using QAOA, and iteratively aggregates sub-solutions into a global binary vector. The underlying objective is written as

$q 2^n$0

and global updates are accepted when a sub-solution bit lowers the QUBO cost (Kim et al., 2024). The reported implementation used MPI via mpi4py on the Frontier supercomputer with 64-core AMD EPYC CPUs per node, 512 GB memory per node, and 50 cores per node employed in the study. For 150-bit problems, DQAOA achieved about 95% accuracy in about 13 s with only 30 iterations; for 1000-bit problems, it achieved about 99% accuracy in about 276 s. It is reported as >160× faster than QAOA and >7× faster than dq-QAOA (Kim et al., 2024).

The same paper extends this idea into an active-learning loop, AL-DQAOA, combining a factorization machine surrogate, DQAOA optimization, and transfer-matrix simulation for multilayer photonic spectral filters. Reported optimization cycles ranged from 13 s for a 12-bit system to 35 s for a 100-bit system, and the final design was evaluated as giving up to 34.3% cooling energy savings versus conventional windows (Kim et al., 2024).

Full-stack HPC-QC framework papers broaden the workload picture. Demonstrations include an HHL workflow for linear systems $q 2^n$1, with less than 2% deviation from BLAS on a $q 2^n$2 matrix and scaling tests up to $q 2^n$3 on a two-node HPE Cray EX system; distributed QAOA and QAOA$q 2^n$4 benchmarks up to 2500 nodes and live execution on a 20-qubit IQM device accessed from LUMI; and strongly disordered spin-chain simulations up to 40 qubits on 256 nodes of Perlmutter with 4 A100 GPUs each (Zhan et al., 23 Oct 2025). The adaptive circuit knitting hypervisor used in that framework reported 10–100× improvement in sampling overhead for 40-qubit spin-chain simulations, and in some cases over 1000× improvement, relative to baseline load-balanced cuts (Zhan et al., 23 Oct 2025).

Application reviews situate these results within a broader scientific agenda. The domains most often cited are simulation of quantum systems, optimization, and machine learning; more specific examples include quantum chemistry, materials discovery, combinatorial optimization, climate and fluid dynamics, and many-body dynamics (Au-Yeung et al., 2023, Rallis et al., 7 Sep 2025). At the same time, the literature is explicit that asymptotic algorithmic speedups do not automatically translate into HPQC gains: data loading, compilation, communication latency, and classical outer-loop costs can erase an otherwise promising quantum kernel (Au-Yeung et al., 2023).

6. Fault tolerance, real-time control, and emerging hardware directions

Scalable HPQC requires more than hybrid workflows; it requires fault-tolerant coding, real-time control, and hardware platforms that can coexist with HPC operational constraints. These demands become increasingly stringent as quantum resources move from NISQ experimentation toward sustained accelerator service.

On the coding side, many-hypercube codes were proposed as a high-rate family for high-performance fault-tolerant quantum computing. Starting from the $q 2^n$5 error-detecting code and concatenating $q 2^n$6 times gives

$q 2^n$7

A highlighted finite-size example is the level-3 code with 64 logical qubits encoded into 216 physical qubits, corresponding to about 30% rate (Goto, 2024). The paper reports three decoding strategies and gives thresholds of 1.1% for hard-decision decoding, 1.5% for symbol-MAP decoding, and 5.6% for the proposed level-by-level minimum-distance decoder. Under a circuit-level noise model, it reports a 0.9% threshold for logical CNOT, while emphasizing that the code family also supports parallel logical SWAPs and CNOTs (Goto, 2024).

Real-time classical support enters through the control path. NVQLink defines a tightly coupled architecture in which a Logical QPU consists of the Physical QPU, the Quantum System Controller, and a Real-time Host made of HPC resources. The target workloads are latency-bounded tasks such as QEC decoding, online calibration, adaptive control, and QCVV (Caldwell et al., 29 Oct 2025). The proof-of-concept network uses commercially available Ethernet and reports mean and median round-trip latency: 3.839 μs, standard deviation: 35 ns, and sample maximum: 3.96 μs. For decoder provisioning, the same paper estimates that, including a factor-of-ten headroom for dynamic compilation and runtime updates, 50 PFLOP/s is a conservative estimate for roughly 100 logical qubits (Caldwell et al., 29 Oct 2025).

Operationally integrated systems already illustrate some of these issues. QMIO combines a classical HPC cluster, a 32-qubit superconducting QPU system, and a 34-qubit emulator in a shared data-center environment with SLURM, ZeroMQ, and a layered middleware stack (Cacheiro et al., 25 May 2025). Direct treatment of the Quantum Control Node as an HPC compute node produced ~1 to 3 seconds overhead per circuit submission through SLURM, which proved too slow for fine-grained hybrid use; the revised design introduced a gateway node and message bus to reduce task-submission latency (Cacheiro et al., 25 May 2025). The same paper reports a daily calibration schedule of about 2 hours, with another 1 hour reserved for manual optimization when thresholds are not met, underscoring that QPUs are calibration-dependent accelerator resources rather than static devices (Cacheiro et al., 25 May 2025).

Emerging hardware platforms may alter these tradeoffs. One notable direction is hybrid photonic quantum computing based on foundry-compatible III–V quantum dots. A 2026 report describes thousands of monolithic devices fabricated in a pilot production line, with first-lens source efficiency increasing from less than 30% to 80% by the end of 2025, successive-photon indistinguishability at 95% mean and 98% best value, record single-photon Wigner-function negativity $q 2^n$8, and hole-spin coherence extended to $q 2^n$9 under dynamical decoupling (Huet et al., 26 Jun 2026). The same work demonstrates seven genuinely entangled qubits in a spin–multi-photon cluster-state setting and discusses progress toward the 2.3% indistinguishability-error threshold and 6.4% optical-loss threshold relevant to fault tolerance (Huet et al., 26 Jun 2026). A plausible implication is that future HPQC infrastructures may not be limited to superconducting accelerator attachment, but may also encompass intrinsically networked photonic architectures with different facility and interconnect assumptions.

Across surveys and systems papers, the unresolved obstacles are consistent: immature hardware, high error rates, limited coherence times, communication overhead, lack of standards, limited interoperability, calibration drift, scheduling complexity, and the cost of integrating QPUs into existing supercomputing operations (Buchs et al., 15 Aug 2025, Beck et al., 2024, Rallis et al., 7 Sep 2025). HPQC therefore remains a systems-engineering program as much as an algorithmic one. Its mature form is not a stand-alone quantum supercomputer, but a quantum-classical computing environment in which QPUs become schedulable, programmable, and verifiable accelerator resources inside the broader HPC stack.