Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey

This paper analyzes nine existing quantum-HPC software stacks to identify common design patterns and unmet needs, proposing the openQSE reference architecture as a unified, interoperable framework that supports both current NISQ and future fault-tolerant quantum computing workloads.

The Gist

The Big Picture: The "Quantum-Cloud" Traffic Jam

Imagine you are a chef (a scientist) trying to cook a complex meal. You have a high-tech oven (a supercomputer) and a magical, fragile oven (a quantum computer) that can cook things no other oven can.

Right now, the problem is that every magical oven comes with its own unique set of instructions, its own specific door handle, and its own weird timer.

• If you want to use Oven A, you need a specific wrench.
• If you want to use Oven B, you need a different key.
• If you want to use Oven C, you have to drive to a different city and learn a new language just to open the door.

This paper argues that this is a mess. It's slowing down science, making it expensive to maintain, and impossible to switch ovens if one breaks.

The authors (a huge team of experts from places like Oak Ridge, IBM, Amazon, and universities) looked at nine different "Quantum Ovens" currently in use. They realized that while the ovens are different, the way we connect them to our kitchens is broken.

So, they proposed a new blueprint called openQSE. Think of it as designing a universal adapter plug and a standardized kitchen manual that works with any oven, whether it's in your basement or in a cloud data center.

---

The Four Ways We Look at the Problem

To fix this, the team sorted the problem into four categories, like sorting tools in a toolbox:

1. Where is the oven? Is it in your own kitchen (On-Premises) or rented from a giant cloud company (Cloud)? The system needs to work for both.
2. What kind of oven is it? Some ovens use trapped ions (like holding atoms with lasers), others use superconducting circuits (like tiny electrical loops). They all behave differently, so the software needs to handle these differences without the chef needing to know the physics.
3. How do you cook?
   • The "Assembly Line" approach: You do step A on the regular oven, send the result to the magical oven for step B, then bring it back. (Loose connection).
   • The "Tandem Bike" approach: You are pedaling the regular oven, and every few seconds, you tap the magical oven to help you pedal faster. They have to move in perfect sync. (Tight connection).
4. Is the oven perfect yet? Right now, our magical ovens are "noisy" (they make mistakes easily). In the future, they will be "fault-tolerant" (perfect). The new system needs to work for the noisy ovens today and the perfect ones tomorrow.

---

The Current Chaos: Nine Different Stacks

The paper looked at nine major players (like AWS, IBM, IonQ, etc.). Here is the analogy of what they found:

• The "Walled Gardens": Currently, Amazon has its own garden, IBM has its own, and IonQ has its own. You can't easily move your recipe from one garden to another.
• The "Universal Plugs": The paper noticed that two new standards are starting to appear:
  • QDMI: A standard way to ask the oven, "What can you do?" and "How are you feeling?"
  • QRMI: A standard way to ask the manager, "Can I book this oven for 10 minutes?"
• The Missing Link: Even with these plugs, the whole system is still fragmented. Some stacks are great for cloud, others for local labs. Some are great for simple tasks, others for complex ones.

---

The Solution: The openQSE Blueprint

The authors propose openQSE (Open Quantum-HPC Software Ecosystem).

Imagine building a universal kitchen where:

1. The Chef (The Application) doesn't care what oven they are using. They just say, "Cook this."
2. The Universal Adapter (The Runtime Interface) sits between the chef and the oven. It translates "Cook this" into the specific language of the oven (whether it's IBM's or IonQ's).
3. The Manager (Resource Scheduler) decides which oven is free, handles the booking, and makes sure the chef doesn't wait too long.
4. The Translator (Compiler Pipeline) takes the chef's recipe and breaks it down into tiny steps the oven understands, optimizing it along the way.

Why is this cool?

• Portability: You can write your code once and run it on any quantum computer, just like you can run a video game on a PC or a Mac if it's built right.
• Future-Proofing: When we get the "perfect" quantum computers in 10 years, you won't have to rewrite your code. The middle layers will just update to handle the new tech.
• Efficiency: Instead of every company reinventing the wheel, they can share the "Universal Adapter" and focus on making their specific ovens better.

The "Fault-Tolerant" Future

The paper also looks ahead to Fault-Tolerant Quantum Computing (FTQC).

• Today (NISQ): The ovens are shaky. If you drop a spoon, the meal is ruined. The software has to be very careful and check for errors constantly.
• Tomorrow (FTQC): The ovens have "self-correcting" mechanisms. If a spoon drops, the oven fixes it instantly.

The openQSE architecture is designed to handle both. It creates a "time zone" separation:

• The Application Time: Where the chef plans the meal (slow, flexible).
• The Hardware Time: Where the oven actually fixes the dropped spoon (fast, nanoseconds).

By separating these, the chef doesn't need to worry about the oven's internal panic button; the system handles it automatically.

Conclusion

In short, this paper says: "We have amazing new quantum ovens, but we are all using different keys to open them. Let's build a universal key and a standard kitchen so scientists can focus on cooking (solving problems) instead of fumbling with locks."

The openQSE is that universal key. It's a roadmap to make quantum computing as easy to use and integrate as your current laptop or smartphone.

Technical Summary

1. Problem Statement

The integration of quantum resources into High-Performance Computing (HPC) environments is currently fragmented. While quantum computers are increasingly used for hybrid scientific workflows (e.g., Hamiltonian simulation, optimization, quantum machine learning), the software stacks enabling this integration are isolated, often proprietary, and lack common interfaces.

Key challenges identified include:

• Fragmentation: Integration occurs through independent paths with provider-specific interfaces, assumptions, and security models.
• Architectural Asymmetry: HPC scales via modular, independently allocatable resources (nodes, cores), whereas Quantum Processing Units (QPUs) scale via scarce, tightly coupled qubits that cannot be fractionally scheduled or checkpointed due to the no-cloning theorem.
• Operational Overhead: Scientists and facilities face high maintenance costs and reduced portability because they must adapt to different runtime assumptions and deployment models (cloud vs. on-premises).
• Lack of Standardization: There is no unified blueprint for runtime abstraction, resource management, or interconnect semantics that supports both current Noisy Intermediate-Scale Quantum (NISQ) workloads and future Fault-Tolerant Quantum Computing (FTQC) systems.

2. Methodology

The authors conducted a comprehensive survey of the current "state-of-the-practice" in Quantum-HPC (QHPC) software stacks.

• Scope: The study analyzed nine representative production QHPC stacks developed by major industry players and research institutions:
  1. Amazon Web Services (AWS)
  2. IBM
  3. IonQ
  4. JHPC-Quantum (SQC scheduler)
  5. Munich Quantum Software Stack (MQSS)
  6. Pasqal
  7. Quantinuum
  8. Quantum Brilliance
  9. Xanadu
• Classification Framework: The stacks were evaluated against four distinct classification axes:
  1. Deployment Environment: Cloud, on-premises, and federated (cross-boundary) operations.
  2. Quantum Hardware Modality: Superconducting, trapped ions, neutral atoms, photonic, etc.
  3. Application Interaction Patterns:
     • Workflow-Centric: Loosely coupled stages orchestrated by a workflow engine.
     • Accelerator-Centric: Tightly coupled, low-latency offload similar to GPU acceleration.
  4. Targeted Quantum Era: Support for NISQ vs. FTQC (and the transition between them).
• Analysis Technique: The authors mapped the workflows of these stacks to a common hybrid job submission pattern, identified common design patterns, and analyzed emerging interface standards (specifically QDMI and QRMI).

3. Key Contributions

The paper makes three primary contributions to the field:

A. Quantum-HPC Stack Analysis

The authors synthesized the architectures of the nine stacks into an Interface Convergence Matrix (Table 1). This analysis reveals:

• Convergence: High agreement on deployment models (cloud/on-prem), SDK support (Qiskit, PennyLane, CUDA-Q), and the use of OpenQASM 3.
• Divergence: Significant differences in resource management interfaces, scheduling layers, and how hardware capabilities (like error correction) are exposed to upper layers.
• Emerging Standards: The survey highlights the growing adoption of the Quantum Device Management Interface (QDMI) for device interaction and the Quantum Resource Management Interface (QRMI) for resource allocation, indicating a shift toward decoupled, interoperable systems.

B. Quantum-HPC Requirements Framework

The paper introduces a structured design space that accounts for the unique scaling asymmetries of quantum resources. It defines requirements across deployment environments, hardware modalities, and computing eras, providing a structured way to evaluate current and future QHPC systems.

C. The openQSE Reference Architecture

The core contribution is the proposal of the open Quantum-HPC Software Ecosystem (openQSE). This is a vendor-neutral, layered reference architecture designed to unify the ecosystem without replacing existing SDKs.

Key Architectural Components of openQSE:

1. HPC Control Node: Provides the logical control plane and a standardized Job Submission Abstraction layer to decouple applications from specific resource managers (e.g., Slurm).
2. Quantum Access Node: The entry point for workflows, hosting hybrid scripts and acting as a cluster tier with direct QPU access.
3. Quantum Runtime Interface (QRI): An application-facing boundary (analogous to HIP for GPUs) that separates application logic from vendor-specific execution details, ensuring portability.
4. QHPC-Interconnect API: A bidirectional interface enabling not just submission, but also upstream signaling, event callbacks, and dynamic resource adaptation between classical and quantum domains.
5. Tool/Compiler Pipeline: A governed model for ordered transformation stages, allowing pipeline placement flexibility (from HPC nodes to near-device).
6. Logical Control Layer (LCL) & Fault-Tolerant Execution Engine (FTEE):
   • LCL: Operates in the Real-Time Domain (RTD), exposing device capabilities (parameter streaming, JIT compilation).
   • FTEE: Operates in the Deterministic Timing Domain (DTD), handling bounded-latency adaptive decisions and error correction (syndrome readout/correction) required for FTQC.

4. Results

• Common Patterns: All surveyed stacks utilize a layered separation between applications, runtime services, compilation, and hardware control. Telemetry and observability are established as architectural necessities rather than optional features.
• Hybrid Job Workflow: A common workflow was identified where a classical node submits a hybrid job via an abstraction layer, which then allocates quantum and classical resources in parallel.
• Gap Identification: While many stacks support NISQ workflows, few have fully matured the interfaces required for FTQC (specifically the tight timing constraints of the DTD and real-time feedback loops).
• Interoperability Potential: The survey confirms that the community is moving toward decoupling device management (QDMI) from resource management (QRMI), creating a foundation for the openQSE architecture.

5. Significance

This paper is significant because it moves the QHPC field from a collection of isolated, proprietary solutions toward a unified, community-driven ecosystem.

• Future-Proofing: The openQSE architecture is explicitly designed to support the transition from NISQ to FTQC without requiring changes to upper-layer application interfaces.
• Portability: By defining stable API contracts (QRI, Interconnect API), it allows applications to run across different hardware modalities and deployment models (cloud vs. on-prem) without rewriting code.
• Operational Efficiency: It addresses the operational overhead for HPC centers by standardizing resource management and scheduling semantics, enabling fair comparison and efficient utilization of scarce quantum resources.
• Foundation for Standards: The work serves as the blueprint for the openQSE initiative, aiming to drive community standards that will enable true interoperability between vendors, HPC centers, and researchers.

In conclusion, the paper argues that the future of Quantum-HPC relies not on better individual devices, but on a robust, standardized software stack that can intelligently orchestrate heterogeneous classical and quantum resources across diverse environments.