Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack

arXiv:2608.14827v1 [quant-ph] 14 Aug 2026

Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack Muhammad Nufail Farooqi

Minh Chung

Burak Mete

Leibniz Supercomputing Centre (LRZ) Garching, Germany muhammad.farooqi@lrz.de

Leibniz Supercomputing Centre (LRZ) Garching, Germany minh.chung@lrz.de

Leibniz Supercomputing Centre (LRZ) Garching, Germany burak.mete@lrz.de

Eric Mansfield

Bernd Hoffmann

Teemu Mattsson

IQM Quantum Computers (IQM) Munich, Germany eric.mansfield@meetiqm.com

IQM Quantum Computers (IQM) Munich, Germany bernd.hoffmann@meetiqm.com

IQM Quantum Computers (IQM) Munich, Germany teemu.mattsson@meetiqm.com

Laura Schulz

Jorge Echavarria

Argonne National Laboratory (ANL) Lemont, Illinois, USA schulz@anl.gov

Munich Quantum Valley (MQV) Garching, Germany jorge.echavarria@munich-quantumvalley.de

Abstract

CCS Concepts

In this work, we demonstrate hybrid High Performance ComputingQuantum Computing (HPCQC) workflows on a production petascale system. The demonstration combines three components: the SuperMUC-NG supercomputer at the Leibniz Supercomputing Centre (LRZ), a 20-qubit superconducting quantum processor provided by IQM Quantum Computers (IQM), and Munich Quantum Valley (MQV)’s Munich Quantum Software Stack (MQSS). Integrating quantum processors into High Performance Computing (HPC) systems requires a heterogeneous software stack capable of orchestrating classical and quantum resources within established supercomputing workflows. MQSS treats Quantum Processing Units (QPUs) as scheduler-managed accelerators and it performs resource coordination following a two-level scheduling scheme. Slurm performs system-level allocation by exposing QPUs as Generic RESources (GRES), while the MQSS Quantum Resource Manager & Compiler Infrastructure (QRM&CI) performs just-in-time compilation and subsequent dispatch of quantum circuits. To integrate with existing HPC operations without modifying the scheduler core, MQSS introduces an open-source SLURM Plugin Suite based on Prolog/Epilog scripts and SPANK modules. Experimental results show that hybrid HPCQC workflows can be executed without significant latency overhead compared to conventional workloads. The presented architecture provides a portable integration model for quantum accelerators on large-scale HPC systems and is directly applicable to next-generation Hewlett Packard Enterprise (HPE) Cray platforms, including LRZ’s upcoming "Blue Lion" supercomputer.

• Computer systems organization → Quantum computing; Heterogeneous (hybrid) systems; • Software and its engineering → Software system structures.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. CUG’26, Nice, France © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM.

Keywords HPCQC Integration, Hybrid Workflows, Scheduling, SLURM, MQSS ACM Reference Format: Muhammad Nufail Farooqi, Minh Chung, Burak Mete, Eric Mansfield, Bernd Hoffmann, Teemu Mattsson, Laura Schulz, and Jorge Echavarria. 2026. Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack. In conditionally accepted for publication in the ACM International Conference Proceedings Series (ICPS).. ACM, New York, NY, USA, 9 pages.

1

Introduction

The emergence of quantum computing offers new opportunities to accelerate a range of scientific applications that are traditionally executed on High Performance Computing (HPC) systems. One practical way of integrating these technologies is to treat Quantum Processing Units (QPUs) as specialised accelerators within HPC infrastructures, in a similar way to Graphics Processing Units (GPUs) and other hardware accelerators. This model enables quantum devices to be incorporated into existing computing environments and leverages the well-established HPC ecosystem for resource management and scheduling. It also allows for the development of hybrid High Performance Computing-Quantum Computing (HPCQC) workflows, in which classical and quantum resources collaborate within the same application. However, integrating QPUs into established supercomputing systems presents several challenges. Quantum devices differ significantly from classical accelerators in terms of programming models and execution paradigms, and they are also scarce resources. At the same time, HPC platforms rely on stable and scalable scheduling frameworks and operational policies that cannot easily be modified. Addressing these constraints requires a heterogeneous

CUG’26, April 26–30, 2026, Nice, France

software stack that can integrate quantum hardware into existing HPC ecosystems while preserving established workflows, scheduling mechanisms and system-level abstractions. We describe the design, implementation, and deployment of a heterogeneous software and scheduling stack that enables tightly coupled hybrid HPCQC workflows. Our platform integrates the Munich Quantum Software Stack (MQSS), as first introduced in [2], with Leibniz Supercomputing Centre (LRZ)’s SuperMUC-NG petascale system, and a 20-qubit superconducting quantum processor developed and delivered by IQM Quantum Computers (IQM) as part of the Q-Exa project [9]. MQSS, developed collaboratively by the Munich Quantum Valley (MQV) initiative, LRZ, and the Technical University of Munich (TUM), provides a technology-agnostic, layered runtime that exposes quantum processors as schedulermanaged accelerators and presents a unified programming model for hybrid applications [15]. In this paper, we will focus on the system-level engineering that allows SLURM [18] to treat quantum processors as first-class resources, on the MQSS SLURM Plugin Suite [12] that implements that integration, and on practical lessons from the SuperMUC-NG + IQM deployment [11]. We report that hybrid jobs execute with no significant latency overhead relative to comparable purely classical HPC jobs, and we discuss how the same stack will operate on LRZ’s forthcoming Hewlett Packard Enterprise (HPE) Cray "Blue Lion" system [10].

2

System overview and primary contributions

MQSS is a modular software stack that bridges high-level hybrid applications and device-specific control. As shown in Fig. 1, MQSS includes (1) high-level front-ends and adapters for common quantum programming frameworks [1, 5, 7, 8], (2) a just-in-time compilation layer inside the Quantum Resource Manager & Compiler Infrastructure (QRM&CI) [2], and (3) an interface to the hardware, namely the Quantum Device Management Interface (QDMI) [17]. The front-end layer provides adapters to widely used quantum programming frameworks and exposes a unified client interface that enables users to submit quantum kernels from different programming environments while remaining agnostic to the underlying hardware. These adapters translate framework-specific representations into MQSS-compatible intermediate formats and forward them to the runtime system for execution. The core runtime component of MQSS is the QRM&CI, which combines dynamic compilation, scheduling, and resource management to orchestrate the execution of quantum kernels. It receives circuits in high-level Intermediate Representations (IRs) and progressively lowers them through a sequence of compilation passes into hardware-specific instructions ready for execution. The compilation pipeline relies on a family of IRs and leverages the Multi-Level Intermediate Representation (MLIR) framework to enable modular and extensible compiler pipelines that support both classical and quantum abstractions. This design allows the compiler to perform hardware-aware optimizations, select appropriate devices, and transpile circuits into native gate sets supported by the target hardware. At the hardware interface layer, QDMI provides a standardized communication interface between MQSS and connected quantum

Farooqi et al.

devices. Through this interface, the stack can query real-time device properties such as topology, gate fidelities, calibration status, and system availability, allowing the runtime and compiler infrastructure to adapt execution strategies to the current state of the hardware. QDMI also manages job submission, result retrieval, and session management for quantum devices, enabling seamless integration of heterogeneous quantum platforms within the same software stack and facilitating their deployment in HPC environments. The primary contributions of this work are: (1) a practical architecture and two-level scheduling model that integrates SLURM and MQSS, enabling quantum processors, such as the Q-Exa demonstrator, to be treated as scheduler-managed Generic RESource (GRES) accelerators. This model allows HPC jobs to request quantum resources alongside classical nodes, while MQSS handles the devicespecific compilation, dispatch, and runtime management of quantum circuits, ensuring seamless execution within existing HPC workflows. (2) The MQSS SLURM Plugin Suite, a production-grade implementation using SLURM Prolog/Epilog hooks and SPANK modules [12], a collection of plugins to interface directly with MQSS to query real-time device status, manage job submission, and synchronize the allocation of QPUs with SLURM’s global scheduler, all without requiring intrusive modifications to the core scheduler. (3) An operational case study of the integrated system deployed at LRZ, linking SuperMUC-NG and IQM’s Q-Exa system, which demonstrates the feasibility of running hybrid HPCQC workflows on a production-scale supercomputer with minimal latency overhead and practical orchestration of both classical and quantum resources.

3

Two-level scheduling model

Hybrid HPCQC workflows require careful coordination between classical and quantum tasks to ensure efficient execution across heterogeneous resources. To achieve this, we adopt a two-level scheduling model that separates global resource allocation from device-level quantum execution. At the first level, SLURM continues to act as the authoritative scheduler for the HPC environment, handling the allocation of classical resources, such as compute nodes and traditional accelerators like GPUs. Similar to Viviani et al. [16], QPUs are incorporated into this framework as GRES, allowing them to be requested in job scripts using parameters such as --gres=qpu:1. Each compute node may host a single QPU by default, but this value can be adjusted to enable sharing of the QPU among multiple jobs and achieve the desired level of quantum resource occupancy. When a hybrid job is submitted, SLURM ensures that both classical and quantum resources are reserved according to user specifications and cluster policies, providing a unified interface for resource management and enforcing global scheduling constraints while maintaining fairness and efficient utilization of the HPC system. At the second level, the QRM&CI component takes over when quantum tasks are offloaded to the QPU during execution of the hybrid applications. QRM&CI handles queuing, just-in-time compilation, hardware-aware optimization, and the dispatch of quantum kernels to the device, ensuring that execution is aligned with the current state and calibration of the processor. This design separates

Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack

CUG’26, April 26–30, 2026, Nice, France

Figure 1: MQSS architecture showing Front-end adapters, QRM&CI, and QDMI-connected quantum devices. responsibilities cleanly: SLURM focuses on cluster-level allocation and scheduling policies, while QRM&CI manages device-level sequencing, vendor-specific instructions, and runtime optimizations. QDMI serves as the critical link between these two levels, providing SLURM and the workflow system with real-time information on QPU availability, calibration status, and error rates. By exposing these hardware metrics, QDMI enables intelligent scheduling decisions and allows hybrid workflows to execute efficiently across both classical and quantum resources, maintaining high utilization without introducing significant latency overhead.

3.1

Scheduling policies and predictable execution

MQSS implements the concept of quantum availability, a metric that captures current QPU load and scheduled calibration overhead. Quantum availability is supplied to the scheduler logic so that SLURM can avoid starting a job that will immediately stall waiting for the QPU. We exploit SLURM’s backfilling capabilities to maintain overall system utilization: while a quantum-accelerated job is pending due to QPU unavailability, SLURM may run other work that does not require the QPU. When the QPU becomes available, pending quantum jobs are dispatched. This policy yields predictable quantum execution times for users while minimizing idle time for the QPU.

4

MQSS SLURM Plugin Suite

To facilitate HPCQC job submission, we developed the MQSS SLURM Plugin Suite, which was integrated into the production system during the initial deployment phase. While the suite remains under active development, it currently leverages standard SLURM extension mechanisms, specifically Prolog/Epilog scripts and the SLURM Plug-in Architecture for Node and job Control (SPANK) plugins[14]. As shown in Figure 2, (A) illustrates the login, compute nodes, and components on the HPC side, while (B) shows the quantum side with the quantum server deploying QRM&CI. QRM&CI interfaces with real quantum backends through QDMI. It establishes direct

connections to specific backends via their respective QDMI Device implementations provided by the hardware vendors. The MQSS SLURM Plugin Suite is designed with two primary objectives: to minimize modifications to the core SLURM codebase and to provide a flexible interface for coordinating between classical HPC schedulers and quantum-specific schedulers. By decoupling these environments, the suite allows for high-level synchronization between HPC and quantum computing. Technically, Prolog/Epilog scripts or SPANK plugins are SLURM’s native extensibility. These mechanisms allow the plugin suite to be deployed, updated, or removed as an external layer, requiring no changes to the SLURM source code. SLURM deployed on production systems launches slurmctl (known as the SLURM controller) and slurmd (SLURM daemon). In the first demonstration of our deployment on the HPC system at LRZ, we integrated the plugins with the SLURM controller and daemon using the following concrete steps: • QPUs are defined and configured as GRES (–gres) in SLURM. For example, we put the specification in slurm.conf and gres.conf: # In slurm . conf G r e s T y p e s =gpu , qpu NodeName= node [01 −N] G r e s =gpu : 1 , qpu : 1

...

# In gres . conf Name=gpu F i l e = / dev / gpudev0 Name=qpu Type= g e n e r a l Count =1 Depending on the number of QPUs and how we allocate them, –gres can be set to specify a different number of available shared resources. This configuration enables SLURM to control QPU allocation and identify which nodes support QPU-required jobs. • In the background, slurmctld and slurmd operate as eventbased models, in which jobs are queued, allocated resources, executed, and terminated in different phases. Thereby, to trigger the connection and offload quantum tasks to the

Farooqi et al.

HPC Compute Nodes node01 slurmd

(A) HPC Side

node02 slurmd node03 slurmd node04 slurmd

HPC Login Nodes login01

slurmctld

node... slurmd

login0...

slurmctld

slurmd

gres= qpu:1 gres= qpu:1 gres= qpu:1 gres= qpu:1

Quantum Daemon gres=

Classical Quantum Server QC Task Offloading Latency

Quantum Resource Manager (QRM&CI)

interconnection network

Quantum Device Management Interface (QDMI)

qpu:1 gres= qpu:1

Quantum DB

Storage

Storage

$HOME

$SCRATCH

QDMI Device Superconducting

se n re d c al irc de ui vi t to ce

CUG’26, April 26–30, 2026, Nice, France

IQM Device QExa20 (20 qubits)

QDMI Device Superconducting

IQM Device Q20 (20 qubits)

QDMI Device Superconducting

IQM Device Q5 (5 qubits)

QDMI Device Ion Trap

AQT Ion-Trapped Device 20-qubit

QDMI Device Future Backend

Future Device ...

Storage

(B) Quantum Side

$ARCHIVE

Figure 2: An illustration of HPCQC integration with MQSS, in which (A) shows the HPC side, and (B) shows the quantum side. Table 1: SLURM events for Prologs and Epilogs are available to control Job Allocation, Execution, and Termination, and can also be implemented as SPANK plugins [6]. Parameter

Location

Invoked by

User

When executed

Prolog (specified in slurm.conf)

Compute Nodes

slurmd

SlurmdUser (normally root user)

First job or job step initiation on that node (by default); PrologFlags=Alloc will force the script to be executed at job allocation

PrologSlurmctld (specified in slurm.conf)

Head Nodes or Master Nodes (where slurmctld runs)

slurmctld

SlurmctldUser

At job allocation

Epilog (specified in slurm.conf)

Compute Nodes

slurmd

SlurmdUser (normally root user)

At job termination

EpilogSlurmctld (specified in slurm.conf)

Head Nodes or Master Nodes (where slurmctld runs)

slurmctld

SlurmctldUser

At job termination

quantum server, we leverage this mechanism to facilitate quantum task offloading from the HPC side. SLURM’s workflow can be intercepted at the predefined phases shown in Table 1. Our plugins leverage the phases of job allocation and termination to enable and disable quantum task offloading. For instance, we set the plugin triggered by PrologFlags=Alloc. At this stage, the quantum daemon (qdaemon) is initialized, the QPU is set to “occupied”, and one of the components in MQSS, the MQSS Client, establishes the connection between HPC and the rest of the stack via qdaemon. This authenticates the access to the corresponding/requested quantum devices. At the termination phase, upon job completion or cancellation, the plugin is triggered to stop the connection. This stage ensures a “clean” exit by stopping the qdaemon, the connection between two sides, and releasing the allocated quantum resources for the next user.

Instead of simply implementing this HPCQC job submission concept using Prolog/Epilog, we can use SPANK to provide more granular control in C. Prolog/Epilog is effective for high-level orchestration, while SPANK can be developed as shared libraries in C, allowing for in-depth environment customization. The MQSS SLURM Plugin Suite also demonstrates SPANK implementation to be a more transparent interaction with SLURM job steps. Our dual approach ensures that the suite remains both lightweight and capable of handling the unique demands of quantum-classical hybrid workloads.

5

Deployment on SuperMUC-NG with IQM Q-Exa

We deployed MQSS on an LRZ testbed system (named BEAST) and in production on SuperMUC-NG, integrating IQM’s 20-qubit superconducting processor, Q-Exa, as an external accelerator. The

er -e nv lo ad qo m fflo qs ad s-

lo a

d

us

HPCQC Job Queue

CUG’26, April 26–30, 2026, Nice, France

["s tim ubm es itt ta ed m "] p ["s tim che es du ta led m "] p

Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack

dispatching QC circuits to QPU

job complete and sending back results [counts]

backend.run()

#!/bin/sh #SBATCH -J example #SBATCH -p partition #SBATCH -o ./%x_%j.out #SBATCH -e ./%x_%j.err #SBATCH --ntasks=1 #SBATCH --gres=qpu:1 #SBATCH --time=00:15:00

User HPC-QC Jobscript HPC tasks allocated on Compute Nodes

Quantum Job/Task Queue

Classical Quantum Server

Quantum

##-------------------./hpc_tasks ./quantum_tasks ##--------------------

Daemon node01 slurmd

node02 slurmd

QC Task Offloading

node03 slurmd

HPC Login Nodes

QPU execution time

Quantum Resource Manager (QRM&CI)

Dispatch QC Task to QPU

Quantum Device Management Interface (QDMI)

QDMI Device Superconducting

IQM Device QExa20 (20 qubits)

HPC Compute Nodes

login01 slurmctld

Figure 3: An illustration of a hybrid HPCQC job and the working pipeline between HPC and QC with MQSS. QPU, along with its dedicated control stack and secure operational domain, is provided and maintained by IQM, ensuring reliable operation and compliance with vendor-specific requirements. MQSS operates across multiple network and security zones to maintain both performance and security: MQSS Clients run on the allocated compute nodes within the HPC environment, QRM&CI executes in a secured orchestration zone, and QDMI communicates with the vendor’s control stack to obtain real-time device status, including topology, fidelity metrics, calibration windows, and availability. From the end-user perspective, hybrid jobs are submitted as a single SLURM job that seamlessly combines classical and quantum computation. Classical pre-processing and post-processing tasks are executed on SuperMUC-NG, while quantum kernels are offloaded to Q-Exa through MQSS. The stack handles just-in-time compilation, device-aware optimization, and kernel dispatch transparently, so users interact with the system much like they would with conventional accelerators such as GPUs. In operational use, we observed that the combined workflow behaves predictably: the SLURM controller allocating resources simultaneously covers both the requested compute nodes and the QPU, while MQSS ensures that quantum execution proceeds without stalling or manual intervention. This integration demonstrates the feasibility of treating a remote superconducting quantum processor as a schedulermanaged accelerator, enabling researchers to run complex hybrid HPCQC workflows in a production environment with minimal overhead and maximal usability. Figure 3 shows an illustration of HPCQC job submission on our system. The illustration highlights a jobscript example and the pipeline of SLURM plugins on HPC nodes that make a connection to the quantum resource manager and related components to reach the requested QPU. Given a hybrid application, users can explicitly specify HPC and quantum tasks in the job script. Alternatively, users can implement both tasks in a single code. With the SLURM

utility commands, we can submit the job, e.g., via sbatch or salloc for interactive jobs. • When a job is allocated and starts, our SLURM plugin is triggered. It checks if the job requires quantum resources, then initializes the quantum daemons to establish the QDMI connection. • At the execution phase, classical tasks are run on the HPC and quantum tasks are offloaded to the quantum server. After processing the task at QRM&CI, it dispatches the quantum circuits for execution on the QPU via QDMI. The interaction between the two sides can be tightly integrated. Once the quantum computation has finished, the results are sent back to the application via the same route. Since QPU is not a native resource and it is shared among users, this approach is practical for a hybrid HPCQC workload. • After the job is complete, the SLURM plugin ensures to stop the connection, quantum daemon, and we can release the QPU resource. There are two queues of jobs, as we can see in Figure 3, one on HPC and one on Quantum Computing (QC). In the current deployment, jobs are received from the HPC side, where the classical resource is prioritized. Then, QPU is checked to let SLURM decide job allocation. This approach comes with shortcomings, such as long blocking of a resource slot on one or both sides. For example, HPC waits for QC execution or vice versa. Therefore, this opens challenges for studying coordinated scheduling between two-sided schedulers or multilevel scheduling algorithms. In the following section, we present experiments and results from our practical deployment as lessons learned. We present the hybrid execution pipeline as highlighted in the yellow block that we also can see in Figure 3. The pipeline shown details the steps involved when a quantum task or quantum circuit is submitted from the HPC. This

CUG’26, April 26–30, 2026, Nice, France

Farooqi et al.

pipeline will align with the experimental results presented in the next section as we evaluate practical hybrid applications. We focus on evaluating the execution time between the HPC and QC, as well as the latency times between steps when quantum circuits are offloaded to the quantum server. The quantum server processes the circuits, and then the QDMI, before the circuit is run on the QPU. In general, these steps are characterized above as: • load user-env: Load the necessary libraries and environment. • load mqss-qoffload: Load components of the software stack on the compute node to make a connection with the QC via MQSS to enable offloading quantum tasks. • ["submitted" timestamp]: Indicates the timestamp when the circuit on the Quantum side is submitted. • ["scheduled" timestamp]: Indicates the timestamp when the circuit is scheduled to QPU. • QPU execution time: Denotes the runtime on QPU, which is roughly measured when the circuit is dispatched on QPU and completes to give back results. In which we can check by ["complete" timestamp].

6

Performance and operational observations

In this section, we present experiments on two hybrid benchmarks, VQE [3] and QAOA [4]. VQE estimates the expectation value of a Hamiltonian, requiring multiple quantum circuit runs per iteration to measure different terms and bases, in addition to classical pre-processing steps such as Hamiltonian grouping and initialstate preparation (e.g., Hartree-Fock [13]). In contrast, the standard QAOA ansatz for MaxCut involves a diagonal Hamiltonian, allowing each iteration to be executed with a single quantum circuit and with minimal classical pre-processing. We employ a vanilla ansatz composed of interleaved, parameterized cost and mixing layers. The algorithm is applied to the MaxCut problem, a classical graph optimization task that partitions a graph into two sets to maximize the number of edges connecting them. A key hyperparameter of QAOA is the number of layers, which is the number of QAOA layers, each consisting of a cost and a mixing unitary with independent parameters. We select this depth dynamically by running the algorithm with fewer optimization iterations across different layer counts, revealing the trade-off between under-parameterization and circuit depth. For this use case, the circuits are configured to solve a four-node MaxCut instance using two QAOA layers. The key differences of the two approaches affect both the frequency of quantum runs and the computational requirements of classical computation, supporting the understanding of performance bottlenecks across hardware and software components.

6.1

Figure 4: The energy-convergence results for the VQE benchmark performed on the Q-Exa 20-qubit device. Latency breakdown MQSS-env-unload 6 avg-QPU-runtime avg-submit-latency

54.95

4068

MQSS-env-load 0

1000

2000

3000 Runtime/Latency (ms)

4000

5000

Figure 5: Latency of the hybrid VQE-execution pipeline on the HPCQC integrated system at LRZ. Figure 4 shows the results on the QExa 20-qubit device. We run the VQE benchmark with 17 iterations. Based on the initial configuration, each iteration performs 16 circuits corresponding to the 14 Pauli terms in the problem design. For instance, the initialized Pauli terms and offsets are given as follows. H = [ ( " ZIII " , ( " IZII " , ( " ZZII " , ( " YXXY " , ( " YYXX " , ( " XXYY " , ( " XYYX " , ( " IIZI " , ( " ZIZI " , ( " IIIZ " , ( " ZIIZ " , ( " IZIZ " , ( " IIZZ " , ( " ZZZZ " ,

VQE Benchmark

As mentioned, to ease benchmarking and profiling execution time, we use a precomputed Hamiltonian for the 𝐻 2 molecule at a bond length of 0.7414𝐴𝑛𝑔𝑠𝑡𝑟𝑜𝑚𝑠. This molecular Hamiltonian is then decomposed as a linear combination of initial Pauli terms and their coefficients. Following the Jordan-Wigner mapping, the VQE circuit size is set to 4 qubits, after the qubit encoding. However, the qubit scaling could also differ for different choice of bases and qubit mappings.

5571

avg-classical-runtime 465.6

0.17110545123720233) , 0.17110545123720225) , 0.16859349595532533) , 0.04533062254573469) , −0.04533062254573469) , −0.04533062254573469) , 0.04533062254573469) , −0.22250914236600539) , 0.12051027989546245) , −0.22250914236600539) , 0.16584090244119712) , 0.16584090244119712) , 0.12051027989546245) , 0.1743207725924201) ,

] The results in Figure 4 show only the execution of 17 iterations, in which this does not reach an acceptable energy convergence for this VQE task because this use case requires hundreds of iterations

Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack

CUG’26, April 26–30, 2026, Nice, France

(A) Expectation value convergence results on the Q-Exa 20-qubit device

(B) Final bitstrings for a 4-qubit QAOA run on QExa-20

Figure 6: The experimental results of QAOA showing (A) expectation value of convergence on Q-Exa and (B) the final bitstrings for the given 4-qubit QAOA run. Latency breakdown

• MQSS-env-unload: highlights the unloading time that makes sure cleaning up the environment, stops the connection, and releases the QPU resource.

MQSS-env-unload 9 avg-QPU-runtime

7707

avg-classical-runtime

319.36

avg-submit-latency 56.37 4036

MQSS-env-load 0

1000

2000

3000 4000 5000 Runtime/Latency (ms)

6000

7000

8000

Figure 7: Latency of the hybrid QAOA-execution pipeline on the HPCQC integrated system at LRZ.

to reach a better result that makes sense for the H2 simulation problem. However, here we are interested in the workflow and how latency breaks down into different steps. The total runtime of 17 iterations is around 35.67 minutes, in which the VQE benchmark’s energy can only reach -0.3345 as minimum. This setup highlights that each iteration of the VQE workflow will execute 16 corresponding circuits as the submitted quantum tasks to QPU. Figure 5 shows the latency of our hybrid execution pipeline, which is divided into five key intervals corresponding to the hybrid execution pipeline as follows. • MQSS-env-load: the time to load the components of the software stack to enable quantum task offloading on the HPC side. It is required only once, when the SLURM job is launched. • avg-submit-latency: indicates the average time when a circuit is offloaded from the HPC side until it is queued and scheduled on the QC side. • avg-classical-runtime: indicates the average execution time on the classical side of each iteration. • avg-QPU-runtime: indicates the average execution time of each quantum circuit run on the real QPU.

In Figure 5, we can see that the submit latency is negligible compared to the average execution time of a circuit on QPU as well as the classical runtime. In principle, the execution time of a circuit or classical computation depends on the nature of the problem and the number of computations required. However, the experimentally measured values here still objectively reflect our HPCQC integration pipeline in practice. Simultaneously, compared to large computations or real-world problems, the latency value here is still much smaller than the execution time required on QPU, CPU, or GPU. As a result in average, the avg-submit-latency is 54.95ms compared to 465.6ms of avg-classical-runtime and 4068ms of avg-QPU-runtime.

6.2

QAOA Benchmark

We have designed the QAOA benchmark to target the MaxCut problem. A small graph example is, with 4 nodes and 4 edges, to achieve reasonable accuracy. The benchmark uses a vanilla QAOA ansatz, composed of an initial-state preparation (a Hadamard layer for all qubits to prepare an equal superposition) interleaved with mixing and cost [4] unitaries. The mixing and cost unitaries are also repeated 𝐿 times, each with different parameters, where 𝐿 indicates the number of QAOA layers. Figure 6 shows the analysis of the expectation value calculation during QAOA optimization. In which its sub-figure (B) highlights the bit-strings sampled in the final iteration, with a clear peak for the two bit-strings (0101, 1010) that are the optimal solution for the MaxCut problem for the selected graph. Similar to the latency breakdown of the VQE benchmark, Figure 7 shows the average runtime and latency for a single circuit execution in an iteration of the QAOA benchmark. In practice, we run the entire execution for about 50 iterations to achieve convergence. To

CUG’26, April 26–30, 2026, Nice, France

show latency, we calculate the average runtime of circuits by measuring the time between dispatching each circuit to the QPU and receiving its probability result from the quantum server. This preliminary result highlights the execution time, including latency effects, in our quantum software stack. As we can see, the submit latency and time to load/unload the quantum software stack environment remain roughly the same (56.37ms for the avg-submit-latency, 4036ms for MQSS-env-load, and 9ms for MQSS-env-unload). Loading/unloading the MQSS software environment only needs to be done once. The QPU runtime for executing the circuits depends on how the quantum circuits are submitted.

7

Limitations and Discussion

The paper’s results demonstrate that hybrid HPCQC workflows can be executed on a production system with negligible latency. Nevertheless, our current deployment is an early integration milestone, and several aspects of its limitations warrant discussion. Hybrid workflow coverage. We used VQE and QAOA as representative workloads to evaluate the hybrid execution pipeline. The experiments highlight exchange data between QPU and HPC once per iteration over many short-lived circuits. The results show that the overhead is negligible compared to the total execution time; however, this evaluation does not cover all possible hybrid workflows, and other classes of applications may exhibit different performance characteristics. We therefore expect that investigating the overheads will show a conservative upper bound, and that a systematic study across the full spectrum of coupling granularities remains future work. QPU availability, sharing, and reconfiguration. The way a QPU is shared follows directly from GRES configuration. In our demonstrated configuration, the example shows that only a single QPU is available. It is exposed to SLURM as one GRES unit (qpu:1) and is effectively shared by all users, with SLURM serializing access to the device across hybrid jobs. When multiple QPUs are available, the GRES can be configured with the corresponding count (e.g., –gres=qpu:2,3,4), allowing SLURM to allocate distinct devices to concurrent jobs. On the quantum devices side, the quantum jobs offloaded from the allocated HPC nodes are delegated to the QRM&CI queue, which handles their queuing and dispatch to the devices. Quantum availability can be derived from periodic QDMI device-status queries, which expose topology, gate fidelities, and calibration windows. Device reconfiguration and recalibration are currently treated by the vendor control stack. Finer-grained, concurrent sharing of a single QPU across multiple SLURM jobs is an open item for future deployments. Coordination between the two schedulers. Our current HPCQC model prioritizes the classical allocation: jobs are admitted from the HPC side, and the QPU is then checked before dispatch. This keeps the integration portable, but it does not yet jointly optimize the use of classical and quantum resources. As a result, under high load, a reserved classical allocation may idle while it waits on the QPU, or vice versa. Besides, a more detailed characterization of QPU utilization at scale, beyond the per-circuit latency breakdown reported in this paper, is part of our ongoing work.

Farooqi et al.

Generality of latency result. For the generality of the latency result, two-level schedulers depend on per-task overhead. This would make submit-and-dispatch latency non-negligible. Our current architecture exposes QPUs as GRES and delegating device-level sequencing to a second-level scheduler remains valid, but the quantitative latency results should be read in light of this dependency. Further work is needed to systematically study the overheads across a broader spectrum of coupling granularities.

8

Conclusions

Our work demonstrates a practical and portable approach to integrating quantum processors into SLURM-managed HPC centers without invasive scheduler changes. The MQSS architecture, including QRM&CI, QDMI, and the MQSS SLURM Plugin Suite, allows HPC centers to offer quantum accelerators with the same operational model and user experience as GPUs or Field-Programmable Gate Arrays (FPGAs). We credit IQM for the Q-Exa hardware and MQV along LRZ and TUM for the development of MQSS. The software is designed to be portable to Blue Lion (LRZ’s forthcoming HPE Cray system) and other SLURM-managed installations, enabling CUG centers to adopt hybrid HPCQC workflows with minimal disruption to existing user practices. This work provides a blueprint for scheduler-level integration of emerging quantum resources into mainstream HPC environments. We emphasize that hybrid execution on the integrated SuperMUCNG + Q-Exa platform introduces no significant latency overhead in a co-located HPCQC setup. QRM&CI’s just-in-time compilation, guided by QDMI Device metrics, is sufficiently fast and may be overlapped with other job stages so that the quantum operations do not introduce observable idle time at the scheduler level. The SLURM plugin suite ensures that the hybrid jobs begin only when the QPU is ready. Daily operational needs, such as recalibration, are integrated into the availability model to minimize disruptions.

Acknowledgments This work is supported by the German Federal Ministry of Research, Technology and Space (BMFTR) with the grants 13N16063 (Q-Exa), 13N16690 (Euro-Q-Exa), 101114305 (Millenion), 10111394-6 (OpenSuperQPlus), and the Bavarian State Ministry of Science and the Arts (StMWK) through funding, as part of MQV, Q-DESSI. The authors would also like to acknowledge the use of DeepL and ChatGPT for grammar checking and improving the clarity of language.

References [1] Ville Bergholm, Josh Izaac, Maria Schuld, Christian Gogolin, Shahnawaz Ahmed, Vishnu Ajith, M. Sohaib Alam, Guillermo Alonso-Linaje, B. AkashNarayanan, Ali Asadi, Juan Miguel Arrazola, Utkarsh Azad, Sam Banning, Carsten Blank, Thomas R Bromley, Benjamin A. Cordier, Jack Ceroni, Alain Delgado, Olivia Di Matteo, Amintor Dusko, Tanya Garg, Diego Guala, Anthony Hayes, Ryan Hill, Aroosa Ijaz, Theodor Isacsson, David Ittah, Soran Jahangiri, Prateek Jain, Edward Jiang, Ankit Khandelwal, Korbinian Kottmann, Robert A. Lang, Christina Lee, Thomas Loke, Angus Lowe, Keri McKiernan, Johannes Jakob Meyer, J. A. Montañez-Barrera, Romain Moyard, Zeyue Niu, Lee James O’Riordan, Steven Oud, Ashish Panigrahi, Chae-Yeun Park, Daniel Polatajko, Nicolás Quesada, Chase Roberts, Nahum Sá, Isidor Schoch, Borun Shi, Shuli Shu, Sukin Sim, Arshpreet Singh, Ingrid Strandberg, Jay Soni, Antal Száva, Slimane Thabet, Rodrigo A. Vargas-Hernández, Trevor Vincent, Nicola Vitucci, Maurice Weber,

Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack

David Wierichs, Roeland Wiersema, Moritz Willmann, Vincent Wong, Shaoming Zhang, and Nathan Killoran. 2022. PennyLane: Automatic differentiation of hybrid quantum-classical computations. arXiv:1811.04968 [quant-ph] https://arxiv.org/abs/1811.04968 [2] Lukas Burgholzer, Jorge Echavarria, Patrick Hopf, Yannick Stade, Damian Rovara, Ludwig Schmid, Ercüment Kaya, Burak Mete, Muhammad Nufail Farooqi, Minh Chung, Marco De Pascale, Laura Schulz, Martin Schulz, and Robert Wille. 2026. The Munich Quantum Software Stack: Connecting End Users, Integrating Diverse Quantum Technologies, Accelerating HPC. In Proceedings of the Supercomputing Asia and International Conference on High Performance Computing in Asia Pacific Region (SCA/HPCAsia ’26). Association for Computing Machinery, New York, NY, USA, 55–67. doi:10.1145/3773656.3773669 [3] Marco Cerezo, Andrew Arrasmith, Ryan Babbush, Simon C Benjamin, Suguru Endo, Keisuke Fujii, Jarrod R McClean, Kosuke Mitarai, Xiao Yuan, Lukasz Cincio, et al. 2021. Variational quantum algorithms. Nature Reviews Physics 3, 9 (2021), 625–644. doi:10.1038/s42254-021-00348-9 [4] Ramin Fakhimi and Hamidreza Validi. 2023. Quantum approximate optimization algorithm (QAOA). In Encyclopedia of Optimization. Springer, 1–7. doi:10.1007/ 978-3-030-54621-2_854-1 [5] Ali Javadi-Abhari, Matthew Treinish, Kevin Krsulich, Christopher J. Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D. Nation, Lev S. Bishop, Andrew W. Cross, Blake R. Johnson, and Jay M. Gambetta. 2024. Quantum computing with Qiskit. arXiv:2405.08810 [quant-ph] doi:10.48550/arXiv.2405.08810 [6] Morris A. Jette and Tim Wickberg. 2023. Architecture of the SLURM Workload Manager. In Workshops Program, Posters Program, Panels Program and Tutorials Program (Job Scheduling Strategies for Parallel Processing), Dalibor Klusáček, Julita Corbalán, and Gonzalo P. Rodrigo (Eds.). Springer Nature Switzerland, 3–23. doi:10.1007/978-3-031-43943-8_1 [7] Ercument Kaya, Burak Mete, Laura Schulz, {Muhammad Nufail} Farooqi, Jorge Echavarria, and Martin Schulz. 2024. QPI: A Programming Interface for Quantum Computers. In Workshops Program, Posters Program, Panels Program and Tutorials Program (Proceedings - IEEE Quantum Week 2024, QCE 2024), Candace Culhane, {Greg T.} Byrd, Hausi Muller, Yuri Alexeev, Yuri Alexeev, and Sarah Sheldon (Eds.). Institute of Electrical and Electronics Engineers Inc., 286–291. doi:10.1109/ QCE60285.2024.10293 Publisher Copyright: © 2024 IEEE.; 5th IEEE International Conference on Quantum Computing and Engineering, QCE 2024 ; Conference date: 15-09-2024 Through 20-09-2024. [8] Jin-Sung Kim, Alex McCaskey, Bettina Heim, Manish Modani, Sam Stanwyck, and Timothy Costa. 2025. CUDA Quantum: The Platform for Integrated QuantumClassical Computing. IEEE Press, 1–4. https://doi.org/10.1109/DAC56929.2023. 10247886 [9] Leibniz-Rechenzentrum. 2024. Germany launches its first hybrid quantum computer at Leibniz Supercomputing Centre. https://www.lrz.de/en/news/ detail/germany-launches-its-first-hybrid-quantum-computer-at-leibnizsupercomputing-centre [10] Leibniz-Rechenzentrum. 2024. HPE builds next-generation supercomputer at the LRZ. https://www.lrz.de/en/news/detail/2024-12-13-bluelion-en [11] Eric Mansfield, Stefan Seegerer, Panu Vesanen, Jorge Echavarria, Muhammad Nufail Farooqi, Burak Mete, and Laura Schulz. 2025. First Practical Experiences Integrating Quantum Computers with HPC Resources: A Case Study With a 20-qubit Superconducting Quantum Computer. In Proceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC Workshops ’25). Association for Computing Machinery, New York, NY, USA, 1842–1850. doi:10.1145/3731599.3767551 [12] Munich Quantum Software Stack (MQSS). 2026. MQSS SLURM Plugins Suite. https://github.com/Munich-Quantum-Software-Stack/MQSS-SLURMPlugins-Suite. GitHub repository, accessed August 18, 2026. [13] Google AI Quantum, Collaborators*†, Frank Arute, Kunal Arya, Ryan Babbush, Dave Bacon, Joseph C Bardin, Rami Barends, Sergio Boixo, Michael Broughton, Bob B Buckley, et al. 2020. Hartree-Fock on a superconducting qubit quantum computer. Science 369, 6507 (2020), 1084–1089. doi:10.1126/science.abb9811 [14] SchedMD LLC. 2022. SPANK: Slurm Plug-in Architecture for Node and Job Control. https://slurm.schedmd.com/spank.html. Accessed: August 18, 2026. [15] Munich Quantum Valley. 2025. The Munich Quantum Software Stack (MQSS). https://www.munich-quantum-valley.de/research/research-areas/mqss [16] Paolo Viviani, Roberto Rocco, Matteo Barbieri, Gabriella Bettonte, Elisabetta Boella, Marco Cipollini, Jonathan Frassineti, Fulvio Ganz, Sara Marzella, Daniele Ottaviani, Simone Rizzo, Alberto Scionti, Chiara Vercellino, Giacomo Vitali, Olivier Terzo, Bartolomeo Montrucchio, and Daniele Gregori. 2025. Assessing the Elephant in the Room in Scheduling for Current Hybrid HPC-QC Clusters. In 2025 55th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W). 184–187. doi:10.1109/DSN-W65791.2025.00059 [17] Robert Wille, Ludwig Schmid, Yannick Stade, Jorge Echavarria, Martin Schulz, Laura Schulz, and Lukas Burgholzer. 2024. QDMI – Quantum Device Management Interface: A Standardized Interface for Quantum Computing Platforms. In IEEE International Conference on Quantum Computing and Engineering (QCE) (2024).

CUG’26, April 26–30, 2026, Nice, France

[18] Andy B. Yoo, Morris A. Jette, and Mark Grondona. 2003. SLURM: Simple Linux Utility for Resource Management. In Job Scheduling Strategies for Parallel Processing, Dror Feitelson, Larry Rudolph, and Uwe Schwiegelshohn (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 44–60.

Related documents

• Enabling Hybrid HPCQC Workflows with a Heterogeneous Software Stack#609249
• PATHA: Performance Analysis Tool for HPC Applications#611942
• Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey#126493
• ORCHA: A Performance Portability System for Extreme Heterogeneity#996867
• Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems#985057