Quantum Framework (QFw): Hybrid Quantum-HPC Orchestration

• Quantum Framework (QFw) is a portable orchestration layer that bridges quantum software stacks and HPC systems for hybrid workloads.
• It unifies multiple local simulators and cloud services (e.g. Qiskit Aer, TN-QVM, IonQ) under a single interface to ensure portability and reproducibility.
• By decoupling frontend and backend executions, QFw enables fair benchmarking and scalable, asynchronous operations over distributed HPC resources using MPI/PRTE.

Quantum Framework (QFw) is a portable, HPC-aware orchestration layer for hybrid quantum-HPC applications whose central purpose is to let quantum workloads run across multiple simulators and hardware backends without rewriting the application code, while preserving reproducibility, fair benchmarking, and scalable execution on leadership-class systems (Chundury et al., 17 Sep 2025). In its 2025 formulation, QFw unifies multiple local backends—Qiskit Aer, NWQ-Sim, QTensor, and TN-QVM—and a cloud-based quantum backend, IonQ, under a single interface, and uses that integration to execute both non-variational and variational workloads (Chundury et al., 17 Sep 2025). The framework is motivated by the observation that no single quantum simulator is best for all circuit types: performance depends strongly on circuit structure, entanglement, depth, and whether the workload is variational or not (Chundury et al., 17 Sep 2025).

1. Definition, scope, and motivating problem

QFw addresses a concrete systems problem in hybrid quantum-classical computing: scientific applications must coordinate quantum circuit execution with HPC resources, batch schedulers, and distributed communication, while also remaining portable across simulators and cloud services (Chundury et al., 17 Sep 2025). The framework therefore provides a backend-agnostic execution layer for quantum circuits, a mechanism to integrate local simulators and cloud quantum services under one interface, distributed execution on HPC nodes via MPI/PRTE, asynchronous orchestration for iterative hybrid algorithms, and a framework for portable, reproducible benchmarking (Chundury et al., 17 Sep 2025).

The central premise is explicitly workload-sensitive. The paper states that simulation efficiency depends strongly on circuit structure, entanglement, and depth, making a flexible and backend-agnostic execution model essential for fair benchmarking, informed platform selection, and the identification of quantum advantage opportunities (Chundury et al., 17 Sep 2025). QFw is accordingly positioned not as a simulator, but as the layer that bridges quantum software stacks and HPC runtime systems (Chundury et al., 17 Sep 2025).

This framing distinguishes QFw from single-backend execution environments. The same application code is intended to run unchanged across heterogeneous execution targets, so that backend comparisons are less confounded by software-stack changes and can instead reflect workload-backend interactions more directly (Chundury et al., 17 Sep 2025).

2. Architectural organization and orchestration model

QFw’s architecture is organized around three main services: the Quantum Platform Manager (QPM), the Quantum Resource Controller (QRC), and the Distributed Execution Framework (DEFw) (Chundury et al., 17 Sep 2025). The QPM is the central dispatcher; it selects execution backends, manages task configuration, and coordinates circuit submission and retrieval. The QRC schedules and launches quantum tasks across MPI ranks and helps ensure efficient use of allocated resources. DEFw is a lightweight RPC layer that handles communication between frontend and backend components (Chundury et al., 17 Sep 2025).

The runtime substrate is built on PMIx PRTE in DVM mode to enable rapid process spawning and low-latency coordination across nodes (Chundury et al., 17 Sep 2025). Within this model, the application submits jobs through a frontend API, the QFwBackend translates those requests into QFw calls, the QPM dispatches tasks to the selected backend, worker processes execute circuits locally via MPI/PRTE or remotely via REST, and results are returned in a standardized format (Chundury et al., 17 Sep 2025).

A defining property of this design is the clean decoupling of frontend and backend. New backends are added by implementing a backend QPM that conforms to the QPM API and must: accept a standardized circuit/problem description, configure backend-specific runtime parameters, launch execution via MPI/PRTE or REST, and marshal results into QFw’s unified format (Chundury et al., 17 Sep 2025). QFw also centralizes logging, error handling, and timing instrumentation so that backends can be compared more fairly (Chundury et al., 17 Sep 2025).

This architecture makes QFw simultaneously an execution abstraction and an experimental control surface. By normalizing submission, result handling, and instrumentation, it creates a controlled environment for comparative studies across simulators and cloud services without requiring per-backend application rewrites (Chundury et al., 17 Sep 2025).

3. Backend integration, frontend interoperability, and execution modes

QFw integrates five backends spanning both simulation and cloud execution (Chundury et al., 17 Sep 2025).

Backend	Class	Notable properties in QFw
TN-QVM	Local simulator	ORNL tensor-network simulator built on ExaTN; supports MPS, TTN, PEPS; paper tests ExaTN-MPS
NWQ-Sim	Local simulator	PNNL state-vector simulator; sub-backends include OpenMP, MPI, CPU, AMDGPU
QTensor	Local simulator	Tree tensor-network simulator based on qtree; used for full-state contraction
Qiskit Aer	Local simulator	Supports statevector, matrix_product_state, stabilizer, automatic
IonQ	Cloud backend	Integrated through IonQ’s Qiskit BackendV2 plugin; REST communication

Within QFw, TN-QVM is wrapped thinly to expose topology selection, though the reported evaluation uses ExaTN-MPS (Chundury et al., 17 Sep 2025). NWQ-Sim is a strong fit for multi-node HPC execution because of its native MPI distribution and support for OpenMP, MPI, CPU, and AMDGPU sub-backends (Chundury et al., 17 Sep 2025). QTensor is described as a tree tensor-network simulator based on qtree, designed mainly for QAOA-style workloads and sparse QUBO expectation estimation, but used in QFw for full-state contraction and tested with numpy and MPI via mpi4py (Chundury et al., 17 Sep 2025). Qiskit Aer is exercised through the mps, statevector, and automatic sub-backends; its MPI path uses chunking, and GPU acceleration is available with CUDA by default (Chundury et al., 17 Sep 2025). IonQ is integrated through the Qiskit BackendV2 plugin, with the paper mostly evaluating the simulator path and reserving hardware execution for future work (Chundury et al., 17 Sep 2025).

Backend selection occurs through lightweight runtime properties such as:

{"backend": "qtensor", "subbackend": "numpy"}

The same QFw backend object can be used from Qiskit or PennyLane, so the quantum program need not change when switching engines (Chundury et al., 17 Sep 2025). This frontend portability is paired with two execution modes. In local HPC execution, backend jobs are launched on nodes allocated in the HPC cluster and PRTE/MPI are used to spawn processes and distribute circuits across worker ranks. In cloud execution, QPM sends jobs to IonQ through REST, with queueing and result retrieval abstracted behind the same execution interface (Chundury et al., 17 Sep 2025).

The practical significance of this arrangement is straightforward: QFw treats simulator choice, cloud access, and distributed launch mechanics as runtime concerns rather than application-level rewrites. That design is central to its claims of portability and reproducibility (Chundury et al., 17 Sep 2025).

4. Evaluated workloads and workload-dependent backend behavior

The evaluation covers both non-variational and variational workloads (Chundury et al., 17 Sep 2025). The non-variational set comprises GHZ state preparation, Hamiltonian simulation (HAM), including Ising-type models, TFIM, and the HHL linear solver. The variational set comprises QAOA and DQAOA, with DQAOA emphasized because it decomposes a large QUBO into smaller subproblems that can run concurrently on multiple simulators or devices (Chundury et al., 17 Sep 2025).

The benchmark sizes are explicitly reported. GHZ, HAM, and TFIM span 4 to 32 qubits; HHL spans 5 to 17 qubits; QAOA uses QUBO sizes 4, 8, 10, 20, and 30; and DQAOA uses QUBO 30 and 40 with subproblem settings such as $(16,2)$, $(8,4)$, $(12,3)$ for 30 and $(16,4)$, $(12,4)$ for 40, where the pair denotes $(\text{subqsize}, \text{nsubq})$ (Chundury et al., 17 Sep 2025).

The reported results are explicitly workload-dependent. For GHZ and HAM, all backends scale to 32 qubits; NWQ-Sim and Qiskit Aer MPS are competitive; and QTensor slows down noticeably beyond 24 qubits (Chundury et al., 17 Sep 2025). The paper interprets this as an entanglement effect: these workloads are entanglement-heavy, and tensor-network methods begin to struggle as circuit structure becomes harder to compress (Chundury et al., 17 Sep 2025). For TFIM, Qiskit Aer’s MPS solver performs very well and sustains low runtimes up to 33 qubits, outperforming NWQ-Sim at larger sizes (Chundury et al., 17 Sep 2025). The paper attributes this to structure and relatively limited entanglement growth favoring MPS-based simulation (Chundury et al., 17 Sep 2025).

For HHL, increasing circuit depth hurts scalability; NWQ-Sim is best at smaller sizes, Qiskit Aer is comparable for medium sizes, and NWQ-Sim again leads at larger sizes within resource constraints (Chundury et al., 17 Sep 2025). The interpretation given is that deeper coherent subroutines and ancilla management make HHL more demanding, so state-vector methods and parallelization help (Chundury et al., 17 Sep 2025).

The variational results foreground orchestration effects as much as raw simulator speed. For QAOA, runtime grows with QUBO size, and scaling process counts beyond a single LLC domain increases runtime sharply due to MPI communication overhead (Chundury et al., 17 Sep 2025). Some runs exceed a two-hour cutoff and are marked with red Xs, while fidelity stays consistently above 95% across tested sizes (Chundury et al., 17 Sep 2025). The paper also notes that Qiskit Aer, when run via mpi4py in this setup, does not benefit as much from multi-core optimization because it is not natively designed for strong multi-node scaling in that mode (Chundury et al., 17 Sep 2025).

DQAOA provides the clearest demonstration of QFw’s orchestration role. NWQ-Sim and the IonQ simulator are compared, with NWQ-Sim completing iterations faster and more uniformly; the zoomed plot shows NWQ-Sim effectively completing about four concurrent iterations faster than the IonQ simulator (Chundury et al., 17 Sep 2025). The IonQ path is slower because it involves internet calls and cloud queueing (Chundury et al., 17 Sep 2025). This establishes a concrete latency-sensitive distinction between local distributed simulation and cloud execution for iterative, concurrency-heavy hybrid workflows.

5. Fair benchmarking, reproducibility, portability, and scalability

QFw is explicitly designed so that backend choice can be changed at runtime via lightweight properties, and the paper identifies automated workload-driven backend selection as future work (Chundury et al., 17 Sep 2025). This points to a selection model in which entanglement, depth, sparsity, and related workload characteristics would inform runtime dispatch. The present system stops short of that automation, but the architecture is already structured around backend substitution rather than backend lock-in (Chundury et al., 17 Sep 2025).

The framework’s benchmarking claims are tightly tied to methodology. Fair comparisons are enabled because the same application code runs unchanged across backends, QFw normalizes result handling and instrumentation, and backend-specific details are hidden behind a common API (Chundury et al., 17 Sep 2025). Reproducibility is emphasized through standardized execution paths, a fixed experimental protocol, mean and standard deviation over three runs, and controlled system settings such as reserving one core per LLC domain to reduce OS noise (Chundury et al., 17 Sep 2025).

Portability is defined broadly. QFw supports Qiskit and PennyLane frontends, local and cloud backends, distributed MPI execution, and uniform backend swapping (Chundury et al., 17 Sep 2025). Scalability is achieved via PRTE/MPI distributed execution, batching of circuit tasks, asynchronous result collection, SLURM heterogeneous job groups, and separation of application nodes from QFw/backend nodes (Chundury et al., 17 Sep 2025). For DQAOA specifically, efficiency comes from overlapping communication with computation and solving subQUBOs concurrently, although very small subQUBOs suffer from fixed RPC and scheduling overheads (Chundury et al., 17 Sep 2025).

A common misconception is that QFw itself claims a demonstrated quantum advantage. The paper does not make that claim. Instead, it argues that QFw helps identify where advantage may emerge by enabling systematic, fair, large-scale benchmarking across different backend types and circuit families, and concludes that advantage opportunities are likely workload-specific (Chundury et al., 17 Sep 2025).

6. Development trajectory and significance within HPC-QC software stacks

QFw did not emerge fully formed in the 2025 paper. An earlier prototype, described as a framework for integrating quantum simulation and high performance computing, presented QFw as middleware for reducing the friction of running quantum workloads on systems such as Frontier, using SLURM heterogeneous jobs, DEFw, PRTE in DVM mode, and MPI-enabled simulators including TNQVM and NWQ-Sim (Shehata et al., 2024). That prototype already emphasized frontend agnosticism, Qiskit and PennyLane support, a common execution interface, and dynamic simulator deployment based on workload shape (Shehata et al., 2024).

A subsequent study on GPU-accelerated distributed QAOA on Frontier described QFw as the software integration layer that makes distributed QAOA/DQAOA workflows executable on HPC systems, with a layered view comprising the HPC/QC hybrid application, a quantum-aware resource manager, a Quantum Software Stack Backend, the Quantum Programming Interface (QPI), and the Quantum Platform Manager (QPM) (Xu et al., 12 Jun 2025). In that context, QFw was the execution engine for quantum subproblems, dispatching asynchronous QAOA instances across CPU/GPU resources and returning results to the classical task manager for iterative updates (Xu et al., 12 Jun 2025). The same paper reports multi-node scaling examples in which GHZ-30 improved from 352 s to 30 s and QAOA-20 improved from 47.5 s to 24.8 s as more nodes were used (Xu et al., 12 Jun 2025).

This development trajectory suggests an evolution from simulation-centric middleware to a broader orchestration layer for heterogeneous hybrid workloads. In its 2025 form, QFw’s main conclusion is not that one backend dominates, but that the best backend depends strongly on circuit structure, entanglement, and communication overheads (Chundury et al., 17 Sep 2025). The framework is therefore significant less as a numerical method than as an execution model for scalable, reproducible, backend-agnostic hybrid computing. The future directions named in the paper—real-hardware experimentation, GPU-accelerated tensor-network backends, automated backend selection, and larger hybrid HPC-cloud studies—follow directly from that role (Chundury et al., 17 Sep 2025).