---
title: High-Performance Quantum Computing
url: https://www.emergentmind.com/topics/high-performance-quantum-computing-hpqc
type: topic
---

# High-Performance Quantum Computing

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 [2508.11765] [2309.06167] [1712.01423].

## 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 [1705.07413]. 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 [2508.11765].

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 [2312.14904].

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 [1511.04386] [2509.06205].

## 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 [1511.04386]. Later overviews refine this into a four-stage progression spanning standalone access, loosely coupled co-location, tightly integrated co-location, and on-node integration [2509.06205] [2309.06167].

| 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 [2407.18527]. 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 [2604.19814].

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}\) [1511.04386]. 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 [2309.06167]. 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 [2309.06167]. 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 [2407.18527].

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 [2510.20128]. 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 [2510.25213]. 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 [1601.07195]. 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 [1601.07195].

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)}\) [2404.02844].

The reported scale is unusual even by HPC standards. The experimental reconstruction covered a Hilbert space
\[
M = 1{,}210{,}581 \approx 1.2\times 10^6,
\]
with **\(N=151\)** detector outcomes and **\(D=1076\)** probe states, corresponding to about **\(1.8\times10^8\)** 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 \(\Pi\), sparse and banded handling of \(F\), and an efficient **butterfly communication pattern** [2404.02844]. The same work reports feasibility up to **\(3.4\times10^{12}\)** 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=50\) [2404.02844].

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 [2404.02844] [1601.07195].

## 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\) QUBO into sub-QUBOs of size \(k\), solves them in parallel using QAOA, and iteratively aggregates sub-solutions into a global binary vector. The underlying objective is written as
\[
\bar{y} = \sum_{x_{i} \in \{0,1\}^n} x^T \mathbf{Q} x,
\]
and global updates are accepted when a sub-solution bit lowers the QUBO cost [2407.20212]. 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** [2407.20212].

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 [2407.20212].

Full-stack HPC-QC framework papers broaden the workload picture. Demonstrations include an HHL workflow for linear systems \(A\vec{x}=\vec{b}\), with less than **2% deviation** from BLAS on a **\(4\times4\)** matrix and scaling tests up to **\(64\times64\)** on a two-node HPE Cray EX system; distributed QAOA and **QAOA\(^2\)** 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** [2510.20128]. 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 [2510.20128].

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 [2312.14904] [2509.06205]. 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 [2312.14904].

## 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 \([\![6,4,2]\!]\) error-detecting code and concatenating \(L-1\) times gives
\[
[\![N^{(L)}, K^{(L)}, D^{(L)}]\!] = [\![6^L, 4^L, 2^L]\!].
\]
A highlighted finite-size example is the level-3 code with **64 logical qubits encoded into 216 physical qubits**, corresponding to about **30%** rate [2403.16054]. 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 [2403.16054].

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 [2510.25213]. 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** [2510.25213].

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 [2505.19267]. 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 [2505.19267]. 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 [2505.19267].

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 **\(-0.330(9)\)**, and hole-spin coherence extended to **\(1.94(17)\,\mu\text{s}\)** under dynamical decoupling [2606.27787]. 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 [2606.27787]. 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 [2508.11765] [2408.16159] [2509.06205]. 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.

Source: https://www.emergentmind.com/topics/high-performance-quantum-computing-hpqc