Practical HPCQC Integration with QDMI: A Real-Hardware Case Study with IQM Systems

Abstract: Quantum computers are moving into HPC centers, and the main challenge is now integration rather than pure hardware access. Many current software paths still depend on vendor-specific adapter chains between user SDKs, schedulers, and backend APIs. This pattern makes operations more complex than necessary and slows the transition from pilots to production workflows. We present a practical integration path centered on the Quantum Device Management Interface (QDMI). Using IQM superconducting systems as a hardware case study, we implement an IQM-backed QDMI layer and connect it to two software layers that HPC centers working with quantum computers already care about: Slurm-based job execution and Qiskit-facing user workflows. The implementation is publicly available at https://github.com/iqm-finland/QDMI-on-IQM. The key message is simple: integrating quantum hardware into HPC does not have to be a bespoke engineering effort for each backend. Once the software-hardware boundary is standardized, large parts of the stack become reusable across providers and deployment styles. Our results do not claim that standardization eliminates all HPCQC challenges. They show that this specific boundary can already be standardized today in a way that is practical for users, operators, and vendors.

• The paper demonstrates that a vendor-agnostic QDMI interface can decouple hardware-specific APIs to enable scalable HPCQC integration.
• Utilizing IQM superconducting quantum systems, the study validates optimized device management through defined session, query, and job lifecycle functions.
• It further integrates with Slurm and Qiskit, ensuring seamless workflow portability across cloud, on-premise, and scheduler-dispatched quantum executions.

Practical HPCQC Integration with QDMI: Case Study with IQM Systems

Introduction and Motivation

This paper rigorously addresses a persistent challenge in contemporary HPCQC integration: the proliferation of vendor-specific device management interfaces that create brittle, bespoke software stacks and inhibit sustainable scaling in heterogeneous quantum deployments. The authors propose the Quantum Device Management Interface (QDMI)—a stable, vendor-agnostic boundary—as a solution for decoupling upper HPC and quantum software from hardware-specific APIs. Using IQM superconducting quantum systems as a hardware target, the study presents a comprehensive implementation and operational validation of QDMI integration, extending to both Slurm-based scheduling and Qiskit-facing frontend workflows.

Figure 1: Minimal QDMI interaction pattern; device, session, and job lifecycle.

The architecture enables a standardized interface for session management, device property queries (static and dynamic), and job lifecycle control, fundamentally isolating vendor specificity and promoting reusable, maintainable software operates over heterogeneous backend environments.

Figure 2: QDMI as the standardized software-hardware boundary, facilitating interaction between various software components and diverse hardware platforms.

QDMI Abstraction and IQM Mapping

QDMI is implemented as a C interface, maximizing portability and explicit resource semantics. The interface is structured around three main function groups: session (authentication and context setup), query (static topology and dynamic calibration retrieval), and job (submission, status tracking, result extraction). This modularity supports thin wrapper implementations that preserve performance and minimize latency compared to native vendor calls.

The IQM-backed QDMI device is constructed as a shared library where authentication, endpoint configuration, and HTTP transport are cleanly separated from the core logic. Session objects encapsulate connection state, authentication, backend selection, and metadata caching; job objects hold circuit payloads, execution parameters, status, and results. The support layer—token manager, API config module, and HTTP client—is minimal, focusing only on essential system boundary operations.

Figure 3: A high level architecture diagram showing three abstraction layers for the IQM software stack. Quantum circuits are submitted from level 1 as Qiskit code to MQT Core, which converts circuits to IQM JSON, sent to QDMI-on-IQM, interfacing the IQM Server.

The mapping between QDMI function calls and IQM Server API endpoints is explicit: authentication, session management, property discovery, job submission (including calibration), and result extraction. Status and error semantics are consistently mapped, providing robust workflow portability and minimizing leakage of vendor-specific detail.

Integration with HPC Components

The standardized QDMI layer enables three critical integration columns:

• Language Interoperability: C++, Python, and other bindings are layered over QDMI. This approach yields idiomatic, RAII-managed objects and exceptions, and supports modular loading of device plugins independent of vendor. Workflow code remains unchanged regardless of backend.
• Qiskit Adapter: The adapter implements Qiskit BackendV2 over QDMI, mapping transpiler queries, circuit execution, and result aggregation to QDMI operations. Primitive abstractions (SamplerV2, EstimatorV2) are supported, enabling full frontend compatibility without bespoke provider implementations per vendor.

Figure 4: Qiskit-facing adapter skeleton over QDMI.

• Slurm Scheduler Integration: QDMI enables seamless insertion into Slurm-dispatched scripts – user code is unchanged from interactive use, while operator-side injection of endpoint URLs and credentials is streamlined either via environment variables or SPANK plugins. This confers operational control and policy enforcement without user intervention.

Figure 5: Illustrative Slurm submission pattern for QDMI-enabled execution.

Deployment Modes and Operational Flexibility

The QDMI boundary unlocks multiple deployment scenarios:

• Cloud QPU: Classical workload on local HPC, quantum circuit execution offloaded remotely. Enables rapid onboarding and iterative algorithm refinement.
• On-Premise QPU: Tight coupling between classical and quantum resources, managed through native scheduler and accounting. Supports closed-loop hybrid algorithms and optimal co-scheduling.
• SPANK Plugin Integration: Scheduler-side automation of endpoint and credentials, enforcing site policies and supporting scalable, multi-QPU orchestration.

Figure 6: Deployment scenarios enabled by the same QDMI-based integration path.

Software above QDMI remains unchanged across modes, yielding maximal workflow portability and reducing operational burden.

Demonstration: End-to-End QSCI Workflow

The operational validity is exemplified via end-to-end execution of Quantum Selected Configuration Interaction (QSCI), emblematic of near-term chemistry workloads. The workflow orchestrates classical preparation, quantum circuit sampling (via QDMI-enabled Qiskit/IQM integration), and classical diagonalization—all toggled between local, simulated, or hardware quantum execution and Slurm-dispatched runs using simple runtime flags.

Figure 7: Simplified QSCI control flow showing execution-mode toggling. Flags select between simulation, hardware access, and scheduler-dispatched execution.

Switching execution contexts requires only changes to runtime parameters; algorithm logic, device management, and result processing are invariant.

Figure 8: Schematic end-to-end workflow for QSCI execution. Numbers denote workflow stages; QDMI drives quantum circuit submission and result aggregation.

Implications and Future Directions

The study demonstrates that device-management standardization via QDMI is immediately practical, performance-preserving, and supportive of real production hardware workflows. Software stack reuse across deployment contexts becomes feasible; operator-side flexibility and policy enforcement are decoupled from user workflow.

Key implications are:

• Vendor Agnosticism: Rapid integration of new quantum devices without rewriting frontend adapters or scheduling scripts.
• Workflow Portability: Algorithm and application logic remain unchanged across simulation, on-premise hardware, or remote quantum access.
• Operational Scalability: Integration of quantum resources under classical scheduler and accounting tools is tractable, supporting future multi-QPU hybrid orchestration.
• Isolation of Vendor Specifics: Backend payload and calibration logic is confined within device plugins, minimizing system-wide code churn.

Future research should explore extension of QDMI to richer resource scheduling models, multi-partition orchestration, and integration with classical HPC resource managers for genuinely hybrid quantum-classical workflow automation.

Conclusion

This paper provides a detailed operational implementation and evaluation of QDMI as a device-management standard for HPCQC integration, using IQM superconducting systems as a real-hardware testbed. By architecting a thin, performance-preserving QDMI layer and demonstrating robust integration with Slurm and Qiskit workflows, the study validates the technical claim that vendor-agnostic device boundaries eliminate custom integration code, foster software reuse, and enable flexible deployment modes. The operational demonstration in QSCI highlights the practical benefits: workflow invariance across simulation, on-premise hardware, and scheduler-dispatched execution. These findings establish device-management standardization as a tractable foundation for scalable hybrid quantum-classical computing in HPC centers.