openQSE at SC26: An Open Software Stack to Connect Quantum Computers and Supercomputers

AMD powers the world's leading scientific computing, from the exascale supercomputers driving discovery in the United States and Europe to Lux, the first Genesis Mission system for AI-driven science. With leadership CPUs, GPUs, FPGAs, networking and open ROCm™ software, AMD gives nations, laboratories and enterprises a single open platform for high-performance computing, AI for science, sovereign AI, agentic AI and the path to quantum computing.

And it has become clear to us - no one company will deliver quantum computing on its own. It will take classical and quantum systems working together on open, vendor-neutral standards - and AMD is proud to be part of the openQSE community making that happen.

Open Quantum-HPC Software Ecosystem (openQSE) is developing an open, modular ecosystem for integrating HPC and quantum computing with vendor-neutral interfaces. Ecosystem members are demonstrating an initial reference implementation at Supercomputing 2026 (SC26): connecting independently developed quantum-HPC software and hardware components into a working, testable stack. 

This blog provides a high-level technical view of the target architecture and the collaborative model behind it. The goal is not to define a final standard, but to exercise real integration boundaries across workflows, scheduling, compilation, resource interfaces, and device-facing runtimes, so future openQSE specifications are grounded in implementation experience.

Architecture at a glance

The reference implementation is organized as a layered execution path that connects application workflows to quantum resources through explicitly testable interfaces. The implementation is designed to support both staged and co-scheduled hybrid workflows.

Staged workflow orchestration

In the staged model, a workflow engine owns the application definition, the order of preprocessing, quantum, and postprocessing stages, and the movement of data between them. Classical and quantum resources are reserved and released per stage rather than held for one shared execution window. 

• Classical preprocessing runs on workload-managed resources, such as Slurm today and Flux as a targeted integration path, and produces staged outputs.
• Quantum admission then evaluates whether a target quantum resource can accept the next stage.
• The quantum stage executes with reservation context and returns results for classical postprocessing.
• Postprocessing runs as a separate classical stage and records final workflow outputs.

This model is useful for workflows where classical and quantum work can be decoupled in time while preserving a consistent application-level execution plan.

Co-scheduled hybrid execution

For tighter coupling, openQSE also exercises a co-scheduled model in which classical and quantum resources are reserved for the same execution window. In this flow, the workflow engine derives a hybrid request, the classical workload manager handles the classical side, and a scheduler-specific adapter, such as qfw-slurm, connects the request to qhw-admission for quantum-side capacity evaluation.

Once granted, the runtime can execute hybrid steps inside that reserved window, compile quantum work, submit it through QFw, and continue classical work while the quantum side is dispatched through scheduler and interface layers. The staged and co-scheduled flows are both important because they test different interface boundaries: one emphasizes orchestration and data movement across stages, while the other emphasizes reservation binding and synchronized execution across classical and quantum resources.

Core technical building blocks

Workflow systems including Tierkreis, StreamFlow, and Prefect represent the application-facing orchestration layer. They are responsible for expressing workflow logic, sequencing stages, and handling data movement between classical and quantum portions of an application.

Slurm currently manages classical resources, with Flux targeted as another integration path. QFw extends this control path toward quantum resources: qfw-slurm links Slurm requests to quantum-aware reservation context, qhw-admission evaluates capacity and policy, and qhw-scheduler supports dispatch of quantum tasks once reservations are established. Separating workload-manager adapters from admission and dispatch logic supports multiple workload managers while clarifying responsibility for policy, placement, and task launch.

The compiler layer is intended to preserve portability across target resources. Tools including MQT Core, Qiskit, and PennyLane help prepare quantum programs for execution while keeping openQSE interfaces above provider-internal topology and control details. This is central to vendor neutrality: the application and compiler can express intent and constraints without hard-coding resource-specific runtime wiring.

A common Quantum Resource Interface shim sits above QDMI and QRMI, providing a shared boundary between orchestration and heterogeneous quantum resources. In the current implementation, IBM, IQM, and Pasqal resources are accessible through both interfaces, while Amazon Braket connects through QDMI. Munich Quantum Valley is developing QDMI-based access for federated setups across LRZ and AWS.

The implementation also looks ahead to fault-tolerant quantum computing and quantum error correction, where low-latency execution constraints become dominant. Backline is the open-source platform co-designed by Xanadu and AMD for real-time quantum-classical integration. Work involving Backline and SpaceRT explores how resource-side runtimes can support controller, transport, memory, and coprocessor coordination within the quantum resource itself. The timing-sensitive QEC loop remains inside the provider-side resource boundary rather than returning to an ordinary classical workflow node. This is a forward-looking part of the SC26 effort, but it is strategically important because it tests whether the same architecture can accommodate both near-term hybrid execution and more demanding future FTQC runtime models.

Collaborative implementation as a standards strategy

The SC26 milestone is intentionally multi-organizational. Contributors span national laboratories, industry, cloud providers, quantum hardware vendors, software developers, and academia. Participating organizations include ORNL, IBM, Quantinuum, the University of Turin, HPE, the Quantum Science Center, Munich Quantum Software Company, Munich Quantum Valley, Xanadu, AMD, AWS, TUM, Qblox, and Pasqal, among others.

That makes the reference implementation more than a demo. It is a structured method for validating where interfaces are clean, where ownership is ambiguous, and where standards need sharper definitions.

That validation only goes so far on paper; it has to be exercised on real systems, and that requires environments where quantum and classical hardware can be co-designed and tested together. One example is the new co-design platform for quantum error correction established by AMD, IBM, and the Quantum Science Center at Oak Ridge National Laboratory. AMD contributes the classical foundation: Umbra, an HPC system built on AMD Instinct™ MI355X GPUs and 5th Gen AMD EPYC™ CPUs, paired with IBM quantum hardware. It is a natural proving ground for co-designing, testing, and validating openQSE implementations — and a reflection of how much of a hybrid workflow is classical, where GPUs can accelerate the numerically intensive computations, from preprocessing and postprocessing stages to decoding inside the error-correction loop.

What SC26 is intended to prove

The SC26 effort is a first integration milestone, not a claim of completeness. Its technical and organizational value comes from demonstrating that:

• independently developed workflow, compiler, runtime, and resource components can interoperate in a shared execution model;
• resource reservation and execution boundaries can be exercised across both staged and co-scheduled workflows;
• vendor-neutral abstractions such as QRI can support heterogeneous backend integrations;
• the architecture can begin to extend toward low-latency FTQC and QEC paths without collapsing abstraction boundaries.

Stop by the AMD booth and the DOE booth on November 17th at 4pm and the 18th at 11am CST, respectively, to learn more!

Expected outcome. The practical lessons from this implementation will feed directly into openQSE working-group priorities, future interface refinements, and a white paper capturing challenges, solutions, and lessons learned. Learn more about AMD quantum computing technologies: contact QuantumComputing@AMD.com or visit https://www.amd.com/en/solutions/quantum-computing.html

Related material

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