Quantum resources in resource management systems

I. INTRODUCTION

• Production HPC centers typically use one workload manager to avoid the overhead of multiple scheduling layers, queues, and inconsistent management.Hybrid quantum-classical applications such as SQD are already being executed on large-scale HPC systems [5].Source: §I · p. 1
• QRMI provides a standardized, vendor-agnostic abstraction for heterogeneous quantum interfaces, including on-premises and cloud resources.The architecture is loosely coupled so it can be adopted across resource managers and quantum providers.Source: §I · p. 1
• A Slurm plugin registers quantum resources as schedulable entities so users can submit and manage hybrid jobs within the same environment.The architecture’s concepts can also be generalized to other workload managers.Source: §I · p. 1

A. Resource Management Systems and the SPANK Framework

• SPANK supports dynamically loadable plugins that can modify behavior at job-lifecycle points without changing Slurm’s core source.Its callbacks span allocation, prologue, task execution, and epilogue; this work uses the framework for quantum resource management.Source: A. Resource Management Systems and the… · p. 2

B. Quantum Computing Providers and Architectures

• The reference implementation uses hardware and software from IBM Quantum and Pasqal.The supplied passage identifies the two providers but does not describe their architectures here.Source: B. Quantum Computing Providers and… · p. 2

1. IBM Quantum

• IBM offers superconducting processors through cloud IQP APIs and an on-premises Direct Access API with parallel execution lanes.IQP exposes backends via Qiskit and REST APIs.Source: §1 · p. 2

2. Pasqal

• Pasqal provides neutral-atom processors through PCS cloud access and an on-premises environment supporting hybrid workflows and concurrent users.Its native programming library is Pulser; PCS also provides access to emulators.Source: §2 · p. 2

C. Personas

• HPC users submit hybrid jobs through familiar scheduler tools, administrators configure and map resources, and providers supply QPU execution facilities.The system abstracts backend complexity from users.Source: C. Personas · p. 2

III. DESIGN

• The design emphasizes simplicity, loose coupling, and modularity so components can be updated or extended without extensive system-wide changes.New backends or communication models can be added without altering core scheduler or interface components.Source: §III · pp. 2–3

A. Quantum Resource Abstraction Model

• The quantum resource abstraction represents physical devices together with concurrency features such as execution lanes or partitions.A resource may represent one lane, a chip, a group of chips, or a device partition; the model hides vendor-specific constructs while preserving deployment flexibility.Source: A. Quantum Resource Abstraction Model · p. 3

B. Quantum Resource Access Model

• On-premises devices are managed directly and acquired or released in lockstep with job execution, while cloud devices are allocated dynamically at runtime.The on-premises model minimizes latency within existing security and provisioning frameworks; cloud bursting offers flexibility and elasticity.Source: B. Quantum Resource Access Model · pp. 3–4
• Quantum resources may be tied to a job’s compute node or shared at cluster level independently of classical resources.The shared model permits quantum-resource sharing even where classical-node sharing is unavailable.Source: B. Quantum Resource Access Model · p. 4

C. Quantum Resource Management Interface (QRMI) - Design and Motivation

• QRMI isolates quantum-specific complexity from workload managers and abstracts differing vendor access models behind a consistent interface.It is designed for reuse across orchestration systems such as Slurm and Kubernetes.Source: C. Quantum Resource Management… · p. 4
• QRMI adapters allow new quantum platforms to be integrated without modifying job schedulers or user interfaces.The middleware exposes resource acquisition, task running, and metrics; its typical flow acquires a resource, monitors execution, and releases it.Source: C. Quantum Resource Management… · p. 4, Figure 3 · p. 4

D. Full System Architecture

• The scheduler can represent quantum hardware as QPU resources, including full devices, partitions, or execution lanes.Source: D. Full System Architecture · p. 4
• Applications run as Slurm jobs; a plugin prepares backend access information, and application primitives trigger circuit execution through QRMI.Source: D. Full System Architecture · p. 4
• QRMI abstracts different backend-service interfaces and mechanisms, while a generalized scheduler orchestrates the integration.Source: D. Full System Architecture · p. 4
• QRMI's lifecycle reserves a QPU before execution, supports task start, status, and result calls, then releases the resource after completion.Source: D. Full System Architecture · p. 5
• Scheduler behavior remains unchanged as vendors and infrastructure change; QRMI adapters independently support new resource managers and quantum providers.Source: D. Full System Architecture · p. 5
• Classical and quantum tasks are managed by the same scheduler through unified submission, co-scheduling, and resource governance.Source: D. Full System Architecture · p. 5

E. Limitations and Advanced Capabilities

• Whether and how jobs execute concurrently depends on QRMI's acquisition mechanism; users could be given the choice to allow concurrency with other jobs.Source: E. Limitations and Advanced Capabilities · p. 5
• Attribute-based backend selection, such as by qubit count or minimum quality metrics, is not implemented but could extend the SPANK plugin.Source: E. Limitations and Advanced Capabilities · p. 5
• For services without authentication, cluster access to the service entry point must be restricted and governed through an API gateway.Source: E. Limitations and Advanced Capabilities · p. 5

F. Alternative Implementations

• Additional and alternative implementations for other scenarios are described in an appendix and fall outside this paper's scope.Source: F. Alternative Implementations · p. 5

A. QRMI Implementation

• QRMI is implemented in Rust, with C APIs for low-level integration and Python APIs for scripting and compatibility with tools such as Qiskit and Pulser.Source: A. QRMI Implementation · p. 6
• The monorepo combines a central QRMI interface with vendor-specific and software-stack adapters.Source: A. QRMI Implementation · p. 6
• QRMI implements the design's standardized API and isolates vendor-specific details in modules to support modularity, reuse, and maintainability.Source: A. QRMI Implementation · p. 6

B. Reference Integration Architecture: Slurm via SPANK Plugin and GRES

• GRES entries represent quantum backends as scheduler resources, while SPANK callbacks integrate their management without modifying Slurm internals.A GRES entry can represent a chip, execution lane, or partition; QRMI actions run at key stages of the job.Source: B. Reference Integration Architecture:… · p. 6
• Slurm’s SPANK hooks coordinate QRMI resource acquisition, task setup, and release across the job lifecycle, enabling unified hybrid-job scheduling.The job prologue acquires the resource and provides credentials or device identifiers, task initialization sets the SDK context, and the epilogue releases the resource.Source: B. Reference Integration Architecture:… · p. 6
• SPANK does not make QPU availability part of Slurm’s scheduling algorithm, though license management or a dedicated queue can be used as alternatives.The passage also describes GRES plugin integration as a future option that would account for availability when scheduling.Source: B. Reference Integration Architecture:… · p. 6

A. Hybrid Quantum–Classical Workflows

• A hybrid workflow requests quantum access in Slurm, acquires the resource before execution, sets device context, runs classical and quantum operations, and releases the resource afterward.The examples include a Slurm submission script requesting two quantum resources and Python workflows for Qiskit and Pulser backends.Source: A. Hybrid Quantum–Classical Workflows · p. 6
• The workflow abstracts backend-allocation logistics so users can focus on hybrid computational logic.Figure 6 is identified as a sequence diagram of the hybrid workflow within the integrated environment.Source: A. Hybrid Quantum–Classical Workflows · p. 6, Figure 6 · p. 8
• The examples show QRMI middleware implemented in Rust with C and Python bindings, alongside scripts for Qiskit and Pulser backends.The section introduces code examples for both backend workflows and describes them as using the QRMI abstraction.Source: Figure 5 · p. 7, A. Hybrid Quantum–Classical Workflows · pp. 7–8

• The section presents examples of Slurm installations that connect quantum resources with HPC.Source: §VI · p. 9

• CCI operates heterogeneous supercomputing systems, including the IBM Data Centric Systems supercomputer AiMOS and Intel Xeon processor-based clusters.The passage describes AiMOS as delivering just over 8 petaflops on LINPACK/HPL using more than 1,500 GPUs.Source: A. RPI CCI AiMOS setup · p. 9
• AiMOS serves as the test bed for the IBM/NYS AI Hardware Center, a $2.6 billion program involving IBM, New York State, RPI, SUNY Poly, and industry partners.Source: A. RPI CCI AiMOS setup · p. 9
• CCI has dedicated high-speed connections to its main campus, NYSERNet optical infrastructure, and Internet2.These connections provide access to national and international high-speed networks.Source: A. RPI CCI AiMOS setup · p. 9

• AiMOS comprises 252 compute nodes and 1,512 V100 GPUs, while the NSF MRI system has 14 compute nodes and 56 V100 GPUs.The passage also reports 126 TB of memory for AiMOS and 7 TB for NSF MRI.Source: Specific CCI Resources · p. 9
• AiMOSx is an HPE GPU/CPU cluster with 40 compute nodes and 320 V100 GPUs, and CCI’s parallel storage provides 11 petabytes of raw disk.The storage system is reported to reach a peak access rate of 80 GB per second.Source: Specific CCI Resources · p. 10
• CCI provides four virtual landing-pad servers for data transfer and two-factor-authentication login, plus two AiMOS front-end nodes for compilation and Slurm job submission.Source: Specific CCI Resources · p. 10
• An IBM Quantum System One with an Eagle processor connects to the HPC cluster through a dual 10Gb/s link and uses Direct Access API to avoid routing circuit inputs and outputs through the cloud.Slurm and a SPANK plugin run quantum workloads from the cluster.Source: Specific CCI Resources · p. 10

B. STFC Hartree Centre cloud quantum-classical setup

• The testing environment used 10 AWS “r5.16xlarge” compute nodes running Slurm and connected to quantum hardware through IBM Cloud.The instances had 64 vCPUs and 512 GB of memory each.Source: B. STFC Hartree Centre cloud… · p. 10

VII. CONCLUSION

• The approach treats on-premise and cloud-based quantum resources as first-class schedulable entities and decouples them from user SDKs in a vendor-agnostic way.The implementation uses SDKs from different vendors.Source: §VII · p. 10
• Slurm’s SPANK plugin and QRMI manage the quantum-resource lifecycle—acquire, execute, release—within native job execution, without modifying Slurm’s core.The paper characterizes operational disruption as minimal.Source: §VII · p. 10
• QRMI and the plugin insertion strategy can be adapted to other resource managers, including PBS and Kubernetes.The architecture uses middleware and plugins for consistent quantum-resource handling.Source: §VII · p. 10
• The authors conclude that abstracting quantum-specific complexity behind a minimal interface and integrating through scheduler hooks supports production-ready hybrid quantum-classical workflows in established scientific-computing infrastructures.Source: §VII · p. 10

Appendix A: Alternative implementations for HPC workload schedulers

• License management can serialize backend access, while backend-specific queues can limit parallel requests and preserve dependencies with ordinary jobs.The appendix also contrasts these approaches with native scheduler resource implementation, which adds functionality to Slurm’s core rather than using the paper’s incremental SPANK plugin approach.Source: Appendix A · pp. 10–11

Appendix B: Quantum Resources for Cloud and Container Management Systems

• Container management systems may serve as resource managers, making direct exposure of quantum computers as native resources potentially more effective than running Slurm or another workload manager on cloud infrastructure.Source: Appendix B · p. 11

1. Quantum Resources for Kubernetes

• A Kubernetes device plugin registers with kubelet and lets users request quantum resources in Pod specifications.The plugin handles vendor-specific setup and allocation requests.Source: §1 · p. 11
• QRMI’s multi-vendor allocation logic can be reused in a Kubernetes device plugin, as illustrated by the node-level integration example.Source: §1 · p. 11, Figure 7 · p. 12
• For shared quantum resources, Kubernetes Dynamic Resource Allocation can support requests and sharing among Pods.Source: §1 · p. 11