arXiv CSopen access

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC--Quantum Systems

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems Ricard S. Raigada-Garcíaa , Josep Jorbaa and Sergio Iserteb a Universitat Oberta de Catalunya (UOC), Barcelona, Spain

arXiv:2604.15279v1 [cs.DC] 16 Apr 2026

b Barcelona Supercomputing Center (BSC), Barcelona, Spain

ARTICLE INFO

ABSTRACT

Keywords: High-performance Computing Quantum Computing HPC–QC Convergence Circuit Cutting Resource Management

Hybrid High-performance Computing (HPC)-–quantum workloads based on circuit cutting decompose large quantum circuits into independent fragments, but existing frameworks tightly couple cutting logic to execution orchestration, preventing HPC centers from applying mature resource management policies to Noisy Intermediate-Scale Quantum (NISQ) workloads. We present DQR (Dynamic Queue Router), a runtime framework that bridges this gap by treating circuit fragments as first-class schedulable units. The framework introduces a backend-agnostic fragment descriptor to expose structural properties without requiring execution layers to parse quantum code, a wave-based coordinator that achieves pipeline concurrency via non-blocking polling, and a production-ready implementation on the CESGA Qmio supercomputer integrating both QPUs local on-premises (Qmio) and remote cloud (IBM Torino) backends. Experiments on a 32-qubit Hardware-Efficient Ansatz (HEA) circuit demonstrate not only makespan improvements over a monolithic CPU baseline but also transparent per-fragment failover recovery—specifically rerouting tasks from the local QPU to classical simulators upon encountering hardware–level incompatibilities—without pipeline restart. For deeper circuits, the coordination residual accounts for only 5% of the total execution time, highlighting the framework’s scalability. These results show that DQR enables HPC centers to integrate NISQ workloads into existing production infrastructure while preserving the flexibility to adopt improved cutting algorithms or heterogeneous backend technologies.

1. Introduction Quantum computing (QC) promises exponential speedups for certain problems in chemistry, materials science, and optimization. However, current and near-term quantum processors are constrained by noise, limited qubit counts, and shallow circuit depths, falling into the Noisy IntermediateScale Quantum (NISQ) regime [1]. In this regime, monolithic quantum circuits often cannot fit on a single device, necessitating decomposition techniques. In this regard, hybrid quantum–classical strategies have emerged to mitigate NISQ limitations: variational quantum algorithms (VQAs) use classical optimizers to sidestep qubit/depth limits [2, 3]; tensor networks classically approximate high-entanglement states [4]; Trotterization discretizes long evolutions into shallow steps [5]; circuit knitting partitions via classical correlations [6]; and circuit cutting decomposes large circuits (via gates or wires) into parallel fragments executed independently and reassembled statistically [7, 8, 9]. Circuit cutting garners special interest for its unbiased estimator of the full circuit’s exact expectation value (unlike Trotterization’s Trotter error or VQAs’ ansatz limits) and its scalability across high-performance computing (HPC) clusters [10], making it pivotal for HPC–QC convergence. However, circuit cutting alone does not solve the systemlevel (HPC–QC) problem: partitioned fragments still demand planning, routing, execution, monitoring, and dynamic scheduling across heterogeneous resources—central processing units (CPUs), graphics processing units (GPUs), [email protected] (S. Iserte)

ORCID (s): 0009-0009-9684-4745 (R.S. Raigada-García);

0000-0002-5810-4748 (J. Jorba); 0000-0003-3654-7924 (S. Iserte)

R. S. Raigada-García et al.: Preprint submitted to Elsevier

quantum processing units (QPUs)—with varying costs, capacities, latencies, and availability. Thus, efficient workloads require not just quantum compilation but also resource and runtime management. Existing hybrid HPC–QC approaches treat QPUs as coarse external accelerators, relegating classical HPC to pre/post-processing and underusing its distributed/adaptive power. Likewise, cutting frameworks emphasize partitioning/reconstruction but bind execution to static workflows, static backends, or framework-specific control paths, neglecting fine-grained orchestration. While circuit cutting has advanced algorithmically, a critical systems gap remains: existing frameworks couple cutting logic tightly to execution orchestration, preventing HPC centers from applying mature scheduling, fault tolerance, and heterogeneous routing policies to quantum workloads. Prior work has focused either on algorithmic decomposition [11] or on static frameworks for small-scale experiments [12, 13], leaving unaddressed the need for a runtime that treats fragmented quantum circuits as first-class citizens in production HPC workloads. We present a systems framework that bridges this gap by decoupling quantum circuit cutting from execution orchestration in hybrid HPC–QC environments. Our contributions are threefold: 1. Fragment abstraction: We introduce a standardized, immutable fragment descriptor tuple exposing structural properties (qubits, depth, gates, reconstruction coefficient, backend admissibility) without requiring execution layers to parse quantum circuit code. This enables backend-agnostic routing and allows cutting frameworks to evolve independently. Page 1 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

2. Wave-based dynamic orchestration: We design a coordinator-driven, wave-based dispatch algorithm that achieves pipeline concurrency via non-blocking polling, handles transient QC failures through retry/failover mechanisms, and adapts to capacity changes from the resource manager. The runtime supports iteration-aware policies that prioritize scarce QPU slots while maintaining high utilization. 3. Production-ready implementation: We present an implementation of the complete ecosystem in the supercomputer Qmio at the Galician Supercomputing Center (CESGA), integrating Qdislib for cutting, Qulacs for CPU simulation, and Qmio SDK for NISQ QPU execution. Figure 2 positions each contribution within the architecture it addresses. Our approach directly addresses gaps highlighted in recent HPC–QC surveys [14]: the lack of standardized fragment descriptors for heterogeneous routing, the absence of decoupled cutting–execution interfaces, and the need for dynamic replanning in the face of noisy, unreliable QPU backends. By treating fragmented circuits as schedulable units with explicit resource requirements, we enable HPC centers to integrate NISQ workloads into existing production workloads while preserving the flexibility to adopt improved cutting algorithms or backend technologies. The remainder of this paper is organized as follows. Section 2 establishes the technical background on circuit cutting, Qdislib, and hybrid HPC–QC execution. Section 3 discusses related work. Section 4 details our methodology: the execution model, fragment abstraction, and wave-based dispatch algorithm. Section 5 presents the implementation architecture, backend adapters, and execution flow. Section 6 describes experimental evaluation on CESGA’s HPC cluster with NISQ QPU access. Section 7 discusses key properties and limitations of the framework. Section 8 concludes.

Figure 1: Circuit cutting strategies. Both map the circuit to a DAG and split it into independent subcircuits executed in parallel. Wire cutting severs qubit paths (8𝑘 subcircuits), while gate cutting decomposes two-qubit gates into quasiprobabilistic locals (6𝑘 variants). Results are recombined via tensor reconstruction.

up to 8𝑘 subcircuits for 𝑘 cuts; gate cuts decompose multiqubit gates (e.g., CNOT/CZ) into quasi-probabilistic locals (6𝑘 variants). Post-execution, observables reconstruct via tensor methods: X ⟨𝑂⟩ = 𝑐𝑖 ⟨𝑂𝑖 ⟩, (1) 𝑖

where 𝑐𝑖 are quasi-probability coefficients from cuts/projections. Cutting scales hardware reach (fragments on CPUs/GPUs/QPUs) at exponential classical overhead—(6𝑘 ) subcircuits for gate cuts and (8𝑘 ) for wire cuts—, transforming monolithic programs into distributable workloads needing orchestration. From a systems view, fragments expose traits (qubits/depth/ops/entanglement) for heterogeneous dispatch, motivating runtime management.

2.2. Qdislib

2. Background This section establishes the technical context for the Dynamic Queue Router (DQR) framework. We first describe circuit cutting as the decomposition technique that produces the independent fragments DQR manages (Section 2.1), then introduce Qdislib as the cutting library used in this work (Section 2.2), and finally characterize the hybrid HPC–QC execution problem that arises once circuits are decomposed and must be scheduled across heterogeneous resources (Section 2.3).

2.1. Circuit cutting Circuit cutting overcomes NISQ limitations by decomposing quantum circuits into smaller fragments evaluated independently and recombined via classical post-processing. Circuits are modeled as directed acyclic graphs (DAGs): nodes are gates; edges are causal dependencies. This enables framework-agnostic cuts, illustrated in Figure 1: wire cuts sever qubit paths (edge between same-qubit gates), yielding R. S. Raigada-García et al.: Preprint submitted to Elsevier

Qdislib1 is a Python library developed by the Barcelona Supercomputing Center (BSC) for scalable quantum circuit execution using circuit cutting techniques. It decomposes large quantum circuits into smaller subcircuits for parallel execution on HPC resources, GPUs, or QPUs, overcoming hardware qubit limitations. The library supports both wire and gate cutting with quasi-probabilistic reconstruction and integrates with quantum frameworks such as Qiskit and Qibo. It leverages PyCOMPSs for task-based parallelism, enabling hybrid workflows on local simulators (e.g., Qiskit Aer, cuQuantum, Qibojit) or remote QPUs like IBM Quantum [15].

2.3. Hybrid HPC-QC execution Hybrid HPC-QC execution refers to the integration of classical HPC infrastructures with QPU to cooperatively 1 https://github.com/bsc-wdc/qdislib

Page 2 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

execute quantum-classical workloads. However, in most current systems, this integration remains coarse-grained. Quantum devices are typically exposed as external accelerators accessed via remote APIs, while classical resources handle circuit preparation, parameter optimization, and postprocessing tasks. In this model, quantum circuit execution is usually treated as a monolithic (distributed or batch) operation delegated to a dedicated backend. Therefore, the role of the classical infrastructure is limited to orchestration and auxiliary computation, rather than actively participating in the execution of the quantum workload. While this approach is sufficient for many hybrid algorithms, it does not fully leverage the distributed capabilities of modern HPC systems. Circuit cutting changes the execution model. Once a circuit is decomposed, the resulting subcircuits become independent computational fragments that can differ significantly in qubit requirements, circuit depth, and execution cost. Consequently, different fragments may be better suited to different types of computational resources. For example, fragments with few qubits can be efficiently simulated on CPUs or GPUs, while others may benefit from execution on dedicated QPUs. This transformation introduces a distributed execution problem where fragment scheduling, backend selection, and resource allocation must be performed dynamically across heterogeneous infrastructures. Therefore, efficient execution requires an orchestration layer capable of managing large sets of circuit fragments, considering both workload characteristics and system constraints, including hardware availability, execution capacity, and specific backend limitations. Despite recent advancements in circuit cutting frameworks and hybrid execution environments, most existing solutions tightly tie circuit decomposition to specific execution workflows or runtime frameworks. This commonly involves transferring fragments from the user side to a queuing system based on hardware type and delegating responsibility to the vendor’s queuing system. As a result, circuit fragment scheduling and placement are often static or frameworkdependent, limiting the ability to adapt execution strategies to heterogeneous HPC-QC infrastructures. These limitations lead us to the need for runtime-level approaches that decouple circuit decomposition from execution orchestration and allow for flexible allocation of fragments across classical and quantum resources. In this context, circuit fragments can be treated as independent computational units whose execution can be dynamically routed according to system policies and hardware capabilities.

3. Related Work The integration of quantum computing resources to HPC environments has emerged as a key research topic in the NISQ era. Preskill’s seminal work [1] on NISQ devices argues that near-term quantum advantage is most likely to be achieved via hybrid quantum-classical schemes rather than fully fault-tolerant quantum computers. This perspective R. S. Raigada-García et al.: Preprint submitted to Elsevier

motivates viewing QPUs as accelerators that complement, rather than replace, classical supercomputers. One of the first systematic architectural studies of HPCQC is due to Britt and Humble, who analyze how QPUs can be integrated into current and future HPC system architectures [16]. They distinguish between tight integration, in which QPUs are attached to compute nodes as accelerators, and loose integration, in which QPUs are hosted as remote services accessed over a network. Their work highlights the role of a quantum interconnect in entangling multiple QPUs and argues that conventional performance metrics are insufficient, calling instead for metrics that capture the interplay between system architecture and quantum parallelism [16]. Building on these ideas, subsequent work at large-scale facilities has focused on end-to-end ecosystems rather than isolated devices. Beck et al. [12] propose a hardwareagnostic framework for integrating quantum computing resources—both physical devices and simulators—into scientific HPC workflows, treating quantum resources as accelerators within production environments and demonstrating this in DOE mission applications. Complementing this, Shehata et al. [13] define a detailed integration framework and requirements specification (Quantum Framework, QFw) that decomposes an HPC-QC system into resource managers, quantum task managers, platform managers, and runtime controllers, and enumerates usage patterns and integration models relevant to batch-scheduled, MPI-based HPC systems. Recent frameworks have also explored orchestration of hybrid quantum–classical workflows at higher abstraction levels. The Kubernetes-native framework of Tejedor et al. [17] demonstrates unified management of CPUs, GPUs, and QPUs via Argo Workflows and Kueue, including a proof-of-concept distributed circuit-cutting workflow. Their work bridges the gap between cloud-native orchestration and hybrid quantum pipelines, providing reproducibility, monitoring, and resource-aware scheduling across heterogeneous nodes. However, it operates at the workflow stage level rather than exposing individual fragments as schedulable units, lacking the fine-grained fragment-level routing, dynamic backend failover, and policy-driven dispatch that our perspective enables for circuit cutting. As prototypes and frameworks have proliferated, several surveys have systematized the emerging literature. Döbler and Jattana [14] present a comprehensive survey of works that integrate quantum computers into HPC systems, classifying more than one hundred publications by hardware architecture, software stack, workflow integration, and application domain. They identify a fragmented ecosystem with many point solutions and argue for standardized interfaces and methods to enable interoperability and reuse. From a software and programming-tools perspective, Elsharkawy et al. [11] review quantum programming tools with a specific focus on their suitability for HPC integration. They introduce a taxonomy based on criteria such as host-language support, execution model, compilation and

Page 3 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

optimization capabilities, scalability, and support for heterogeneous back-ends. Moreover, they relate tools to different hardware-integration scenarios (standalone quantum systems, co-located accelerators, and on-node integration), thereby providing guidance on selecting or toolchains for HPC–QC deployments. On the algorithmic side, the state of the art in hybrid quantum-classical algorithms directly shapes the workloads targeted by HPC-QC systems. Endo et al. [18] survey hybrid algorithms such as the variational quantum eigensolver (VQE), the quantum approximate optimization algorithm (QAOA), and related variational schemes, and they review quantum error-mitigation techniques appropriate for NISQ devices. Their work clarifies the computational structure and classical-quantum interaction patterns (optimization loops, sampling requirements) that HPC architectures must support, while also underscoring that error mitigation can dramatically increase sampling cost and thus classical resource demand. More broadly, the optimization landscape of hybrid algorithms has been scrutinized in terms of trainability and barren plateaus. Ge et al. [19] analyze the optimization landscapes arising in hybrid quantum-classical algorithms, connecting insights from quantum control to NISQ applications and identifying conditions under which gradients vanish or remain robust. These results have important implications for system-level design because they influence the number of circuit evaluations and classical iterations required, and therefore the load imposed on both QPUs and classical HPC resources. A significant fraction of proposed near-term HPC-QC applications fall into the broad category of quantum-enhanced machine learning. De Luca [20] surveys hybrid quantumclassical machine learning approaches in the NISQ era, including variational quantum circuits, quantum kernels, and quantum-assisted feature maps. While most demonstrations are still small-scale, the survey highlights the architectural patterns—tight classical–quantum feedback loops and dataintensive pre- and post-processing—that make HPC resources particularly relevant for scaling such workloads. Dynamic resource allocation has also been explored in recent HPC-QC work. Rocco et al. [21] propose both a workflow-based strategy and a malleability-based approach to release classical resources during quantum execution and reallocate them afterward, showing improved resource utilization and time-to-solution over a statically allocated baseline. A persistent gap in the above ecosystem is the absence of fine-grained, runtime-level orchestration for heterogeneous QPU workloads. McCaskey et al. [22] introduce XACC, a service-oriented middleware that exposes QPUs as coprocessors to HPC nodes and underpins many subsequent integration stacks. At the language level, QCOR [23] and its compiler implementation [24] extend C++ with quantum kernels compiled against XACC backends, establishing an MPI-compatible programming model for extremescale systems. More recently, Mantha et al. [25] propose R. S. Raigada-García et al.: Preprint submitted to Elsevier

Pilot-Quantum, a middleware that applies the Pilot Abstraction from distributed HPC to manage quantum resources and task queues across Slurm-scheduled clusters and cloud QPUs. On the scheduling front, Giortamis et al. [26] demonstrate with Qonductor that jointly optimizing fidelity and job-completion time yields substantial reductions in QPU wait times in cloud settings, while the analyses of Viviani et al. [27] argue that scheduling is the primary bottleneck in HPC-QC integration and identify QPU scarcity, technology heterogeneity, and software ecosystem mismatch as root causes. Despite these advances, none of the above systems exposes individual circuit fragments as first-class schedulable units: they target whole-circuit jobs or coarse workflow stages, and none provides the combination of a backend-agnostic fragment descriptor, dynamic wave-based dispatch, and policy-driven failover that production circuitcutting workloads require [16, 12, 13]. Combining these strands, the state of the art in HPC– QC can be considered a convergence of (i) system architectures that treat QPUs as accelerators within heterogeneous supercomputers, (ii) integration frameworks and surveys that articulate requirements and classify available tools, and (iii) a growing body of hybrid algorithms and applications whose computational structure is well-matched to classical– quantum co-processing in HPC environments.

4. Methodology This section describes the rationale behind the presented system framework that decouples quantum circuit cutting from HPC execution orchestration, enabling scalable hybrid HPC-QC execution of NISQ workloads. The system introduces a standardized fragment abstraction, dynamic wavebased scheduling, and fault-tolerant routing policies that address gaps in prior work [16, 12, 11, 14]: lack of cuttingexecution decoupling, standardized descriptors for heterogeneous routing, and dynamic re-planning for unreliable NISQ backends. Figure 2 showcases the layered approach proposed in this paper. The execution model assumes a pre-cut quantum circuit decomposed into independent fragments via any cutting framework. The core principle is decoupling of cutting from orchestration: the cutting layer produces lightweight fragment descriptors exposing only structural properties (qubits, depth, gates, reconstruction coefficient, backend admissibility); the execution layer consumes these descriptors without knowledge of the quantum algorithm, Pauli strings, or cutting method. This separation transforms a quantum decomposition problem into a classical heterogeneous scheduling problem amenable to HPC techniques: resource allocation, backend routing, fault tolerance, and tensor reconstruction. In the NISQ context—where circuits exceed single-device qubit/depth limits—it enables modularity: cutting frameworks evolve independently while execution scales with HPC resources.

Page 4 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

Figure 2: Runtime-oriented execution model for circuit-cut workloads. The circuit cutting layer is decoupled from the orchestration layer via fragment descriptors, enabling hardware-aware, policy-driven scheduling across heterogeneous HPC-QC backends. The three contributions of this work (right) are positioned within the layer they address; see Section 1.

In this regard, a fragment 𝑓𝑖 is represented as an immutable tuple: ) ( (2) 𝑓𝑖 = 𝑆𝐶 𝑖 , 𝑞𝑖 , 𝑑𝑖 , 𝑔𝑖 , 𝑐𝑖 , 𝑖 , where: • 𝑆𝐶 𝑖 : subcircuit payload (OpenQASM string + metadata), • 𝑞𝑖 : qubit count, • 𝑑𝑖 : circuit depth, • 𝑔𝑖 : two-qubit gate count, • 𝑐𝑖 : quasi-probability coefficient for tensor reconstruction, • 𝑖 ⊆ {HPC, QC}: execution backends. While structural metrics (𝑞𝑖 , 𝑑𝑖 , 𝑔𝑖 ) are computed once by cutting, the backend (𝑖 ) where the fragment will be executed is determined during the labeling stage. When labeling, soft hints (HPC, QC, and Undecided) with the most appropriate backend are assigned to each fragment following a labeling policy that determines where the fragment will be firstly executed. In this regard, this presented methodology enables backend-agnostic routing without circuit inspection, since the scheduler does not need to parse or analyze the actual quantum circuit code to decide where to send each fragment. Execution proceeds in discrete dispatch waves via a fragment state machine (PENDING → DISPATCHED → SUCCESS∕FAILED) (see Figure 3). While the coordinator process non-blocking polls completions from the backends, in each wave it: 1. Handles failures: • transient → retry (up to max) R. S. Raigada-García et al.: Preprint submitted to Elsevier

Figure 3: DQR Fragment lifecycle state machine. A fragment is created in the PENDING state and transitions to DISPATCHED upon assignment to a backend. A transient failure returns the fragment to PENDING for retry; once the retry counter exceeds the configured maximum, the fragment reaches the terminal PERMANENT_FAILED state. Successful execution transitions the fragment to the terminal SUCCESS state, at which point its expectation value is stored for tensor reconstruction.

• permanent → failover • QC → HPC if enabled 2. Refreshes capacity (HPC and QC processing slots). 3. Plans dispatch Π respecting labels/policies. 4. Submits HPC to free workers, QC to backend session. 5. Commits Π, incrementing wave counter. Algorithm 1 presents the wave-based dispatch loop. Each iteration processes three phases: completion handling, capacity refresh, and dispatch planning. First, the coordinator non-blocking polls fragment completions from HPC and QC backends. For each completion 𝑐, the algorithm distinguishes between successful execution and failures. TRANSIENT_FAILED fragments are requeued as PENDING if retries remain, with optional QC→HPC relabeling via the failover flag; exhausted retries trigger PERMANENT_FAILED terminal state. Successful fragments transition to SUCCESS, storing their expectation values for tensor reconstruction. Page 5 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

Algorithm 1: Wave-based coordination Input: Fragments 𝐹 , capacity 𝐶 1 repeat 2 Non-blocking poll completions 3 foreach completion 𝑐 do 4 if TRANSIENT_FAILED(𝑐.𝑖𝑑) then 5 if retries < max then 6 if failover then 7 Re-label QC → HPC 8 PENDING(𝑐.𝑖𝑑) 9 else 10 PERMANENT_FAILED(𝑐.𝑖𝑑) 11 end 12 else 13 SUCCESS(𝑐.𝑖𝑑) 14 end 15 end 16 Refresh 𝐶 (HPC and QC slots) 17 Π ← plan(𝐹PENDING , 𝐶) 18 Submit ΠHPC and ΠQC , respectively 19 Commit: selected PENDING → DISPATCHED 20 Wave counter ++ 21 until |PENDING| = |DISPATCHED| = 0 Second, capacity 𝐶 is refreshed from current HPC allocation and QC status (available QPU session slots). Third, the planner plan(𝐹PENDING , 𝐶) generates a dispatch plan Π respecting fragment labels, routing policies, and available slots. HPC fragments ΠHPC are assigned to HPC processing units, while QC fragments ΠQC are submitted to QPUs. Selected fragments commit PENDING → DISPATCHED in the state machine. Non-blocking polling enables wave overlap: new fragments dispatch while prior fragments execute, achieving pipeline concurrency bounded by total MPI ranks and QC slots. The wave counter supports iteration-aware policies (wave 0 favors labels; later waves prioritize scarce QC slots).

5. Implementation The implementation follows the architecture introduced in Section 4 which comprises the three loosely coupled layers and communicates via files on the General Parallel File System (GPFS) and the Message Passing Interface (MPI) paradigm. Particularly, Figure 4 showcases how the different modules, components, and tools are interconnected. This section describes in detail the pieces that constitute this system architecture and how they are related.

5.1. Circuit Cutting Layer The cutting layer is implemented as a gRPC microservice that encapsulates Qdislib. It receives an OpenQASM circuit along with hardware constraints (maximum qubits per subcircuit and max cuts) and returns the complete set R. S. Raigada-García et al.: Preprint submitted to Elsevier

Figure 4: System architecture of the DQR framework. The three loosely coupled layers communicate via GPFS (filebased fragment descriptors and results) and MPI (coordinator– worker messages). The Circuit Cutting Layer decomposes the input OpenQASM circuit and emits fragment descriptors. The Runtime Orchestration Layer comprises the RMS, which manages HPC allocation and reconfiguration policies, and the DQR, which performs fragment classification, policy-based wave dispatch, capacity-aware backend routing, and failure handling. The Execution Backends layer abstracts classical CPU simulators, local on-premises QPUs, and remote cloud QPUs, routing HPC and QC fragments to the corresponding physical infrastructure.

of shard descriptors. It is designed so that the Qdislib microservice can be replaced by another cutter as long as the descriptors are respected. Before entering the dispatch pipeline, each fragment is assigned a placement label by the qcut_label_job routine. The labeller reads four structural metrics from each .meta.json file: qubit count 𝑞𝑖 , circuit depth 𝑑𝑖 , two-qubit gate count 𝑔𝑖 , and total operation count 𝑧𝑖 . These metrics are mapped to one of three placement labels—QC, HPC, or Undecided—by one of four configurable classification policies. The choice of policy and its thresholds is a jobpreparation decision made by the operator based on knowledge of the target hardware; the DQR coordinator is entirely label-agnostic and behaves identically regardless of how labels are assigned. What changes with labeling is the prior routing hint, not the correctness or the coordination logic of the system. • Budget. A fragment is labeled QC if and only if all available metrics fall within a set of operator-defined upper bounds (the QC envelope): max max max 𝑞𝑖 ≤ 𝑞QC ∧ 𝑑𝑖 ≤ 𝑑QC ∧ 𝑔𝑖 ≤ 𝑔QC ∧ 𝑧𝑖 ≤ 𝑧max . (3) QC

Page 6 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

A fragment is labeled HPC through a voting mechanism: each metric that exceeds its corresponding HPC min , 𝑑 ≥ 𝑑 min , etc.) contributes lower bound (𝑞𝑖 ≥ 𝑞HPC 𝑖 HPC one vote, and the fragment is labeled HPC when the total vote count reaches the operator-defined quorum 𝑣min . Requiring a quorum rather than a single trigger makes the HPC decision robust to noisy or partially available metrics: a fragment is only forced to classical execution when multiple structural dimensions independently signal that it exceeds QPU capacity. If neither the QC envelope nor the HPC quorum is satisfied, the label is Undecided, and the router resolves it at dispatch time. All thresholds and 𝑣min are set by the operator to reflect the QPU’s qubit capacity, connectivity constraints, and depth tolerance. • Score. Each metric is normalized against the operatordefined QC upper bound and combined into a weighted QC pressure score: 𝑆𝑖 = 𝑤𝑞

𝑑𝑖 𝑔𝑖 𝑧𝑖 𝑞𝑖 max +𝑤𝑑 𝑑 max +𝑤𝑔 𝑔 max +𝑤𝑧 𝑧max , (4) 𝑞QC QC QC QC

where the weights 𝑤𝑞 , 𝑤𝑑 , 𝑤𝑔 , 𝑤𝑧 ≥ 0 sum to 1 and reflect the operator’s assessment of which structural dimension most constrains the target QPU. Lower scores indicate stronger QC affinity. The label is then assigned by comparing 𝑆𝑖 against two operatordefined thresholds 𝜏QC and 𝜏HPC separated by a deadband gap 𝛿 ≥ 0: ⎧QC if 𝑆𝑖 ≤ 𝜏QC − 𝛿, ⎪ 𝓁𝑖 = ⎨HPC if 𝑆𝑖 ≥ 𝜏HPC + 𝛿, ⎪Undecided otherwise. ⎩

(5)

The dead band [𝜏QC −𝛿, 𝜏HPC +𝛿] absorbs fragments whose metrics are ambiguous, deferring their placement to the DQR capacity-aware resolver at dispatch time. • Hybrid. Budget rules (3) are applied first; if they yield a decisive QC or HPC label, that label is used. Fragments that remain Undecided under the budget pass are then re-evaluated by the score function (4)–(5), which may resolve them or leave them Undecided if 𝑆𝑖 falls within the dead band. This two-pass structure lets operators encode hard hardware constraints in the budget layer while using a continuous score to resolve borderline cases. • Autobudget. When all fragments in a batch share nearly identical structural metrics, threshold policies tend to assign every fragment to the same class. Autobudget addresses this by enforcing a globally specified fraction triplet (𝛼QC , 𝛼HPC , 𝛼U ), normalised to sum to 1, which the operator sets to reflect the desired HPC-QC workload split. Given 𝑛 fragments,

R. S. Raigada-García et al.: Preprint submitted to Elsevier

the target counts are: ⌋ ⌊ 𝑇QC = 𝛼QC 𝑛 + 21 , ⌊ ⌋ 𝑇HPC = 𝛼HPC 𝑛 + 21 ,

(6)

𝑇U = 𝑛 − 𝑇QC − 𝑇HPC . The assignment proceeds in two passes. First, every fragment receives a baseline label from the budget rule (3) and a pressure score 𝑆𝑖 from (4). Second, the pressure scores are used to rank fragments by QC affinity: those within the QC envelope are sorted by ascending 𝑆𝑖 and the top 𝑇QC are assigned QC; the remaining fragments are sorted by descending 𝑆𝑖 and the top 𝑇HPC are assigned HPC; all others become Undecided. This global reassignment guarantees quota compliance regardless of the threshold configuration, making it the appropriate choice when the fragment set is homogeneous —or the hardware-based physical suitability is unknown— and the operator wants explicit control over the QC-to-HPC dispatch ratio. These labels serve as routing hints to the orchestration layer but are not binding: the router may override them based on capacity constraints, policies, and failure history. The labeling stage therefore decouples domain knowledge about hardware capabilities from the scheduling mechanism, allowing either to evolve independently.

5.2. Runtime Orchestration Layer The Dynamic Queue Router (DQR) is the core scheduling component developed for the orchestration layer. It maintains an in-memory context that tracks the state of every fragment across its execution lifecycle (see Figure 3 described in Section 4). The DQR context is owned exclusively by the execution coordinator process (MPI rank #0). Worker MPI ranks #(1..n-1) execute fragment simulations and communicate results back to rank #0 via MPI tags (‘TAG_DONE‘, ‘TAG_FAILED‘). The coordinator-worker protocol is built on a minimal two-message exchange: rank 0 issues a WORK message carrying the fragment identifier and routing metadata, and the receiving worker replies with D ONE or FAILED upon completion. Result data is never transmitted over MPI; workers write expectation values directly to the GPFS, keeping message size bounded and independent of fragment complexity. Worker selection follows a ring traversal over ranks 1 through 𝑛 − 1: the sender advances a circular pointer across the worker set, skipping occupied ranks, and assigns each fragment to the next free slot. This round-robin baseline avoids centralized queue contention and distributes load evenly under uniform fragment durations while remaining (𝑛) per wave —negligible relative to execution latency. DQR operates in discrete dispatch waves. In each wave, the router applies its selection policy to the current set of PENDING fragments, produces a dispatch plan listing the indices of fragments selected for HPC and QC backends, commits this plan to the fragment state machine (transitioning selected fragments from PENDING to DISPATCHED), and submits Page 7 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

the corresponding simulation tasks to the backend sender. This mechanism ensures that QPU unavailability does not The wave counter is incremented on every commit, even for stall the reconstruction pipeline. empty plans, so that iteration-dependent routing rules are The fundamental property that makes this topology vievaluated consistently. At each tick, the coordinator reads the able without checkpoints is the independence of fragments. live backlog (hpc_pending, qc_pending, undecided_pending, Because no worker communicates with any other worker hpc_dispatched, qc_dispatched) alongside the current capacand no fragment depends on the output of a peer, rank 0 is ity snapshot and produces a routing plan that differs from the never required to drain a wave before planning the next one. previous wave: HPC completions free slots that Undecided Completions from wave 𝑘 are harvested opportunistically fragments can claim, QC tails hold slots that would otherduring the planning phase of wave 𝑘 + 1 or later, meaning wise go to HPC, and a permanent QC failure triggers an that at any given moment, in-flight fragments may belong to immediate re-label —based on policy configuration— and different logical waves. The wave counter therefore serves re-enqueue as HPC without stalling the pipeline. as a routing-policy index, not a global barrier: utilization In this layer, we can also find the resource manager remains bounded by aggregate worker capacity rather than system responsible for orchestrating HPC resources. by the latency of the slowest fragment in any cohort. In the current implementation, HPC resources are man5.3. Execution Backends aged by Slurm [28], while the QC capacity is read from The backend layer is encapsulated in QCore, a C++ environment variables (‘DQR_QC_SLOTS_TOTAL‘). library with a C API (qcore_run_meta_file_ex), developed The wave-based dispatch mechanism is the mechanism for this purpose, which abstracts the execution targets. The through which the DQR achieves both parallelism and adaptarget is selected by the backend_target field injected into the tivity following Algorithm 1 described in the previous secfragment metadata by the DQR coordinator before dispatch. tion. The HPC backend uses Qulacs for state vector simRank #0 non-blocking polls completions with MPI_Iprobe ulation via a direct circuit construction from the Opento collect those that have arrived since the previous wave QASM 2.0. It supports the gate set {𝐻, 𝑋, 𝑍, CX, CZ, without busily waiting. This means that a new dispatch 𝑅 (𝜃), 𝑅 (𝜃), 𝑅 (𝜃), 𝑈 (𝜃, 𝜙, 𝜆)}, and computes expectawave is planned and committed even while earlier fragments 𝑥 𝑦 𝑧 tion values by sampling the final state vector with a configare still executing, achieving pipeline-level concurrency: the urable shot count ( QCORE_SHOTS , by default 1024). system maintains multiple in-flight fragments at all times, The QPU backend invokes a Python bridge via popen. limited only by the available computational units (capacity). The bridge is implemented in backend_qpu_qulacs.py, and The capacity is refreshed at each wave from the Slurm alsubmits the OpenQASM circuit to the CESGA Qmio QPU location environment variables (SLURM_NTASKS, SLURM_NNODES) and from DQR-specific environment variables (DQR_QC_DEGRADED through the qmio SDK, polls for completion, and returns counts in the same JSON schema as the CPU backend. When and DQR_QC_SLOTS_TOTAL). The number of available HPC slots the environment variable Qmio_DRY_RUN=1 is set, the bridge is computed as the total number of MPI ranks minus one (the substitutes a local Qulacs simulation, enabling end-to-end coordinator). When the QPU backend is degraded or offline, testing of the QPU execution path without access to physical the qc_degraded flag suppresses all QC routing until the flag hardware. is cleared. The backends return responses conforming to the JSON The routing policy within a wave is self-aware and labelschema qcore.result.v1 , which includes the fragment exsensitive. In this regard, at wave 0, the router processes pected value, shot count, Pauli string, backend identity, and labeled fragments (HPC and QC) first and defers Undecided fragper-phase timing information. The DQR coordinator parses ments to a second pass, where they are filled into remaining HPC or QC slots according to the DQR_PREFER_ITER0_UNDECIDED the expected_value field from each completion and passes it to the tensor reconstruction stage; no other field is required preference. From wave 1 onward, the router prioritizes for correctness, ensuring that future adapters can be added QC-labeled fragments first to preserve QPU scheduling without changes to the coordination or reconstruction logic. invariants, then routes HPC-labeled and Undecided fragments in an order controlled by DQR_PREFER_ITERN_UNDECIDED. This asymmetry reflects the fact that QPU sessions are the scarce, 6. Performance Evaluation long-latency resource: QC fragments should be submitted We evaluate the DQR framework along two primary early to minimize total makespan. axes: execution time and resource utilization. Correctness The failure handling is integrated directly into the wave of the reconstruction pipeline is assessed separately in Secloop. A transient failure —e.g., a QCore timeout or a tion 6.3. Starting from a monolithic CPU baseline, we comsimulator error— requeues the fragment as PENDING with pare hybrid configurations that vary the labeling policy, the its failure counter incremented; once the counter exceeds QC slot count, and the MPI process count, isolating the DQR_MAX_TRANSIENT_RETRIES, the failure is promoted to percontribution of each degree of freedom on completion time manent. A permanent failure on a QC-routed fragment can and efficiency. The evaluation covers two complementary trigger a failover to HPC if the DQR_ALLOW_FAILOVER_QC_TO_HPC QPU regimes: local on-premises execution on the CESGA flag is set in the policy, in which case the fragment is reQmio processor and remote execution via the IBM Torino labeled at the routing level and re-enqueued as an HPC task. cloud service. R. S. Raigada-García et al.: Preprint submitted to Elsevier

Page 8 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

Along the experiments, we are going to use the following nomenclature to refer to timings: • QPU-time: time billed by the QPU backend for the actual execution of the logic gate, excluding queue waiting time in the remote QPU scenario. • DQR-time: execution time of the fragments in the HPC and QC resources, covering fragment dispatch across HPC and QPU-time plus the tensor reconstruction. • Makespan: elapsed time between job initialization and completion, excluding Qmio queue waiting time. Depending on the type of job, the makespan represents the times for: – QPU-only: 𝑡setup𝑞 + 𝑡round-trip + 𝑡QPU-time + 𝑡post-process – Hybrid: 𝑡setupℎ + max(𝑡round-trip , 𝑡DQR-time ) where 𝑡setup𝑞 covers circuit loading, circuit mapping, transpilation, and expectation value for QPU-only jobs; while 𝑡setupℎ environment setup, gRPC server startup, circuit cutting, circuit labeling, MPI host resolution, and artifact submission for hybrid jobs. When using an off-premises QPU, 𝑡round-trip corresponds to the QPU provider overhead—QPU queue wait, data network exchange, and job scheduling. For on-premises, this overhead corresponds only to the QPU queue waiting time. In hybrid executions, since QPU and HPC fragments run concurrently, the maximum between 𝑡round-trip (QPU-related) and DQRtime (HPC-related) determines the fragment’s total execution time. Finally, 𝑡post-process covers result retrieval and expected value reconstruction—the hybrid reconstruction remains within DQR-time. Table 1 summarizes these and the rest of the metrics leveraged along the performance evaluation of this paper.

6.1. Experimental setup configuration The experiments are executed on the CESGA Qmio cluster 2 , where each compute node is equipped with 64 cores and 1 TB of RAM. This cluster integrates an on-premises Oxford Quantum Circuit’s superconducting QPU. The QPU consists of 32 coaxmon qubits, and it is handled by microwave pulses crafted by QAT Software 3 . Furthermore, Qmio provides the Qmio-Qulacs quantum emulation on CESGA infrastructure, supported by hardware and software based on a distributed version of Qulacs [29] running on Fujitsu FX700 machines. Additionally, we have connected the cluster to the remote QPU IBM Torino, via the IBM Quantum Cloud service 4 . IBM Torino is powered by the Heron r1 processor [30]. A 133-qubit superconducting chip 2 https://cesga-docs.gitlab.io/qmio-user-guide 3 https://github.com/oqc-community/qat

arranged in a heavy-hexagonal lattice. QCore Backends for both QPUs are implemented and integrated into DQR as described in Section 5.3. Regarding the software stack, Table 2 summarizes what we have utilized to perform the experiments. We evaluate the proposed framework on a 32-qubit circuit. Particularly, a Hardware-Efficient Ansatz (HEA) with one layer (𝐿=1) is chosen as the benchmark circuit for three main reasons: its regular CZ entanglement pattern produces predictable cut locations, making it a standard HPC–QC benchmark [15]; its 𝑍 ⊗𝑛 expectation value concentrates near zero for randomly-parametrized instances, providing an analytically grounded correctness check; and the accuracy of the reconstructed observable is not the primary concern of this evaluation—it is determined by the cutting framework and reconstruction method, both external to DQR. The HEA circuit is therefore used exclusively as a controlled vehicle to exercise the orchestration layer—scheduling behavior, resource utilization, failure handling, and dispatch latency— under realistic HPC–QC conditions. The circuit comprises 96 gates—32 two-qubit CZ and 64 single-qubit 𝑅𝑌 /𝑅𝑍 —at depth 34. Parameters 𝜽 are drawn uniformly from [−𝜋, 𝜋] via qibochem.ansatz.he_circuit 5 . With 𝑘=2 CZ gate cuts, Qdislib produces 62 =36 reconstruction terms across two circuit components, for a total of 72 subcircuit evaluations per run. To probe behavior at greater circuit depth, Table 6 repeats the evaluation at 𝐿=2 (192 gates, depth 68, 𝑘=4, 2, 592 evaluations). The cutting layer uses Qdislib with gate cutting enabled. In all configurations, the cutter identifies 𝑘=2 CZ cuts (see Section 2.1), producing 62 =36 reconstruction terms distributed across two circuit components, for a total of 72 subcircuit evaluations per run. In this regard, to make efficient use of the system resources, the experiments are designed to balance the load fairly among the requested computational units. The experiments are designed to operate in a mixedlatency regime: HPC fragments complete in under a second, while QC fragments take several seconds each, so the MPI coordinator must continuously reschedule—dispatching Undecided fragments, absorbing failures, and rerouting through failover—until the last fragment completes. This is precisely the regime where the wave-based dispatch demonstrates its value: multi-wave replanning, QC slot contention, and the failover path are all exercised under realistic contention. A configuration with one MPI rank per fragment would collapse the workload into a single wave, eliminating these dynamics entirely. HPC and QC resources are provisioned to maintain load balance and minimize resource idle time. The ratio of HPC ranks to QC slots is tuned so that HPC and QC paths remain simultaneously active across multiple waves: neither backend exhausts its queue before the other, keeping the coordinator continuously replanning. A configuration with, say, 72 workers and 72 QC slots would collapse the entire 5 https://qibo.science/qibochem/stable/api-reference/ansatz.html

4 https://quantum.cloud.ibm.com

R. S. Raigada-García et al.: Preprint submitted to Elsevier

Page 9 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems Table 1 Evaluation metrics and derived quantities. Symbol

Definition

Description

Per-fragment timings 𝑡setup𝑞 𝑡load + 𝑡map + 𝑡transpile + 𝑡ev 𝑡setupℎ 𝑛QC 𝑛HPC 𝑡round-trip

𝑡̄QPU 𝑡̄HPC

Pipeline overhead for QPU-only jobs: circuit loading, qubit mapping, transpilation, and observable. 𝑡env_setup + 𝑡gRPC + 𝑡cut + 𝑡sub + 𝑡label + Pipeline overhead for hybrid jobs: environment setup, gRPC server startup, circuit cutting, circuit labeling, MPI host resolution, and artifact submission for hybrid 𝑡MPI_host_res jobs. — Number of fragments labeled QC in a given run. — Number of fragments labeled HPC in a given run. Corresponds to the QPU provider overhead—QPU queue wait, data network 𝑡communication + 𝑡QPU_queue_waiting + exchange, and job scheduling. For on-premises, this overhead corresponds only to 𝑡job scheduling the QPU queue waiting time. 𝑛QC 1 X

𝑡 𝑛QC 𝑖=1 round-trip 𝑛HPC 1 X 𝑡 𝑛HPC 𝑖=1 exec

Critical-path times ( ) 𝑇QC max𝑖∈QC 𝑡done − 𝑡start 𝑇HPC

( ) max𝑖∈HPC 𝑡done − 𝑡start

Aggregate times MakespanCPU 𝑡CPU_sim + 𝑡sampling ( ) MakespanDQR 𝑡setupℎ + max 𝑡round-trip , DQR-time DQR-time

max(𝑇QC , 𝑇HPC ) + 𝐶fixed

𝐶fixed

𝑡DQR-time − max(𝑇QC , 𝑇HPC )

Speedup

MakespanCPU ∕MakespanDQR

ReconstructionX observable ⟨𝑂⟩ 𝑐𝑖 ⟨𝑂𝑖 ⟩ 𝑖

Balance and overlap metrics Φ 𝑇QC ∕𝑇HPC 𝜎= 𝜎

Mean round-trip time over all 𝑛QC QC-labeled fragments in a run. Mean execution time over all 𝑛HPC HPC-labeled fragments in a run.

Elapsed time from first dispatch to last QC fragment completion; equals ⌈𝑛QC ∕𝑠⌉ × 𝑡̄QPU under uniform round-trips, where 𝑠 is the QC slot count. Elapsed time from first dispatch to last HPC fragment completion.

Elapsed time between job initialization and completion for the CPU-only baseline. Comprises the Qulacs statevector simulation and shot sampling with expectation-value computation. Elapsed time between job initialization and completion for a hybrid DQR job, excluding Qmio queue waiting time. For QPU-only jobs, the analogous decomposition is 𝑡setup𝑞 + 𝑡round-trip + 𝑡QPU-time + 𝑡post-process . Elapsed time from MPI initialization to last reconstruction within DQR; includes fragment dispatch, QPU round-trips, and tensor reconstruction. Fixed coordination residual: MPI communication, rank-zero polling, and collective overhead not on the QC or HPC critical path. Ratio of CPU-baseline makespan to DQR makespan; values >1 indicate improvement.

Reconstructed expectation value of the observable; 𝑐𝑖 are the quasi-probability coefficients from the gate-cut decomposition [8], and ⟨𝑂𝑖 ⟩ is the expectation value estimated from fragment 𝑖.

DQR balance number: Φ > 1 is QC-bound, Φ < 1 is HPC-bound, Φ = 1 is balanced.

𝑇QC + 𝑇HPC

max(𝑇QC , 𝑇HPC ) min(𝑇QC , 𝑇HPC ) =1+ max(𝑇QC , 𝑇HPC )

Overlap speedup: ratio of sequential to concurrent dispatch time; 𝜎 ∈ (1, 2], with 𝜎 = 2 iff Φ = 1.

workload into a single wave, eliminating multi-wave replanning, Undecided arbitration, and failover events from the observable trace entirely. The chosen allocation is therefore the minimal one that keeps all three routing paths—HPC, QC, and Undecided-to-either—simultaneously active across multiple waves, making the load-balancing and adaptivedispatch behavior of the DQR fully observable and measurable throughout the experiment. Specific allocations per configuration are detailed in Table 5.

R. S. Raigada-García et al.: Preprint submitted to Elsevier

6.2. On/Off-premise QPUs Following, the presented infrastructure is evaluated twofold, with the Qmio local QPU and the remote QPU hosted in the cloud.

Page 10 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems Table 2 Software summary. The Stack column indicates if the component is exclusive for the DQR framework or it is also used in the QPU-only scenario (Both). Component

Version Role

Compiler & Build Tools GCC 12.3.0 LLVM 16.0.0 Python 3.9.9

C/C++ compiler (QCore, RMS) Compiler infrastructure (Qulacs) Interpreter (QPU bridge, QCut)

HPC SLURM 23.11.4 Resource manager Open MPI/PRRTE 6.1.0a1 MPI runtime UCX 1.11.2 MPI transport layer (TCP) QC qmio-run 0.5.1 qmio-tools 0.2.1 Qiskit 2.2.3 qiskit-qasm3-import 0.6.0 qiskit-ibm-runtime 0.46.1 Qdislib 1.0.0 Qulacs 0.6.13

Stack Both Both Both Both DQR DQR

CESGA Qmio runtime module Both QmioBackend / QPU SDK Both Quantum circuit compilation Both QASM 3.0 parser for Qiskit Both IBM Quantum Cloud job submission Both Circuit cutting (find_cut) DQR CPU state vector simulator (QCore) DQR

6.2.1. Local QPU Under fully on-premises conditions, firstly we run the baseline, which is the full uncut 32-qubit HEA circuit executed directly on the QPU. Then, we evaluate the DQRenabled scenario to study how the circuit fragments are routed between the QPU and the HPC resources. In the baseline, the Qiskit transpilation expands the circuit from depth 35 to depth 374 and from 128 to 795 gates to conform to the native gate set and connectivity. The Qmio QPU completes the execution in 9.14 seconds, for a total makespan of 9.75 seconds, which adds the transpilation time. This result serves as the local hardware reference: the local QPU executes the full 32-qubit circuit in under 10 seconds, a timing that the state vector simulation on a single HPC node cannot match at this qubit count. The hybrid execution applies the DQR pipeline with DQR_QC_BACKEND=local, routing QC-labeled fragments to the Qmio QPU. Of the 72 subcircuits produced by Qdislib (𝑘=2 gate cuts), the autobudget labeller assigns seven fragments to the QC backend, 58 to the HPC, and the remaining 7 Undecided. The DQR dispatcher serializes local QPU dispatch, submitting one fragment at a time, as the Qmio backend does not expose a parallel slot count through the environment interface used by the capacity model. In the experiment, five out of the seven QC-labeled fragments, completed successfully on the Qmio QPU, confirming that the hardware can execute gate-cut subcircuits. The remaining two fragments fail at runtime with error QCORE_ERUNTIME: “The controlflow construct ‘if_else’ is not supported by the backend.” This failure arises because Qdislib’s gate-cut decomposition injects mid-circuit classical if–else branches that the Qmio native stack cannot compile. Both fragments exhaust the single allowed retry, transition to PERMANENT_FAIL, and are immediately relabeled and reenqueued as HPC tasks via the DQR_ALLOW_FAILOVER_QC_TO_HPC policy. The failover is fully transparent: the pipeline completes all 72 fragments and R. S. Raigada-García et al.: Preprint submitted to Elsevier

Table 3 Local QPU evaluation on the CESGA Qmio cluster. Metric

QPU-only

Hybrid

Configuration Circuit (𝑛, gates, depth) 32 q, 128, 35 QC|HPC|U (%) — QC slots — MPI ranks (np) — HPC Nodes 1

32 q, 96, 34 10% | 80% | 10% 1 12+1 2

Quantum circuits # Completed # Failed: QC → HPC

5 of 7 fragments 2 of 7 fragments

1 —

Performance QPU-time Fragments (65+2) DQR-time Makespan

9.136 s — — 6.6 ± 4.7 s/4.5 s/3.8–16 s — 27.2 s 9.8 s 44.6 s

Results ⟨𝑂⟩

+0.023

−6.6×10−3

performs tensor reconstruction without user intervention, yielding a makespan of 44.6 s, from which 27.2 s of DQRtime. Table 3 compiles the configuration of the experiments and their results. The Configuration defines for each environment, respectively, the circuit features; the percentages of fragments labeled QC, HPC, and Undecided for DQR; MPI ranks for the HPC backend of DQR, which always needs an additional rank for the orchestration; and the number of HPC nodes (at least one for communicating with the QPU) to spread uniformly the MPI ranks. The Quantum circuits area accounts for the number of circuits (or fragments in DQR) completed. There are two fragments that, after failing in the QC environments, were re-routed to the HPC to be executed. Performance presents the timings for the different metrics as defined in Section 6. More details are provided for the execution fragment to present the variability they present in terms of Mean/Median/Range. Finally, in Results, reports the reconstructed expectation value ⟨𝑂⟩; its interpretation against the CPU baseline and the exact state vector reference is discussed in Section 6.3. In conclusion, the hybrid run is slower than the QPUonly baseline for two reasons that are independent from the DQR architecture. First, the pipeline processes 72 fragments with 12 MPI ranks, so even the purely classical portion requires multiple dispatch rounds. Second, the two re-routed QC → HPC fragments each add approximately 7–9 seconds to the critical path, serialized because the capacity model receives no slot count from the local QPU backend interface. Despite these constraints, the hybrid run demonstrates that the failover mechanism functions correctly under a real QPU rejection condition: the DQR state machine recovers from hardware-level errors at the fragment granularity and preserves pipeline integrity without global restart.

Page 11 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

Enabling local QPU execution of cut circuits would require either a control-flow-aware native compiler for Qmio or an alternative cutting strategy that avoids mid-circuit classical branches, a direction out of the scope of this work.

6.2.2. Remote QPU The local evaluation has exposed a fundamental constraint that prevents using the Qmio QPU for the full cutting pipeline: the hardware does not support the classical control-flow inserted by Qdislib’s gate-cut decomposition. This limitation is architectural rather than a deficiency of the DQR framework, and for this reason, an additional QPU could be used. Particularly, in this section we target the IBM Quantum Cloud service, which compiles and executes the required control-flow constructs, natively. To start with, as in the local QPU scenario, the baseline is determined by executing the full uncut 32-qubit HEA circuit on the IBM Torino QPU. Then, in the hybrid approach, the same circuit decomposed into 72 fragments via the DQR pipeline is executed, routing seven QC-labeled fragments to IBM Torino across three cloud slots and the remaining 65 fragments to CESGA HPC nodes due to system state and pending queue. Results are reported in Table 4. The QPU-only run transpiles the 32-qubit logical circuit to 133 physical qubits on the IBM Torino 133-qubit heavyhex topology, expanding from depth 35 to depth 37 and from 128 to 192 native gates. Table 4 summarizes the configuration and showcases the experimental results. The same seven QC-labeled fragments are successfully completed with IBM Torino. In this scenario, 𝑡̄QPU is substantially larger than in the local scenario: for off-premises execution 𝑡round-trip includes not only QPU-time but also QPU queue wait, data network exchange, and job scheduling— overhead that is virtually null for on-premises QPUs. The higher 𝑡̄QPU increases 𝑇QC and therefore DQR-time and makespan relative to the local QPU setup. The ⟨𝑂⟩ values (+3.4 × 10−3 QPU-only, −2.7 × 10−5 hybrid) are both consistent with zero within the sampling noise floor at 1024 shots (𝜎 ≈ 0.031 for ⟨𝑍 ⊗32 ⟩ on a randomly-parametrized HEA), so neither result carries statistical significance, and no systematic bias attributable to the cutting or reconstruction procedure can be identified from this comparison.

6.3. Results We evaluate DQR on the same 32-qubit HEA circuit introduced in Section 6.1, comprising 96 gates and depth 34, under a CPU-only baseline and four DQR dispatch policies (A–D). The labeling policy is specified as a QC/HPC/Undecided percentage triplet, which determines how the 72 fragments are classified before entering the dispatch loop. QClabeled fragments are submitted to the remote IBM Torino QPU, while HPC-labeled fragments run on the Qulacs simulator on the Qmio cluster. Undecided fragments are dynamically assigned by DQR at dispatch time, based on resource availability, filling QC and HPC slots according to the backend preference configured in the policy—independently for wave 0 and subsequent waves (see Section 5.2). R. S. Raigada-García et al.: Preprint submitted to Elsevier

Table 4 Remote QPU evaluation on the CESGA Qmio cluster. Metric

QPU-only

Hybrid

Configuration Circuit (𝑛, gates, depth) 32 q, 128, 35 QC|HPC|U (%) — QC slots — MPI ranks (np) 1 HPC Nodes 1

32 q, 96, 34 10% | 80% | 10% 3 12+1 2

Quantum circuits # Completed # Failed: QC → HPC

7 of 7 fragments —

Performance QPU-time Fragments DQR-time Makespan Results ⟨𝑂⟩

1 —

19 — — 12.9 ± 1.4 s/ 13.1 s/ 11.4–14.7 s — 41.7 s 34.1 s 50.7 s +3.4×10−3

−2.7×10−5

Table 5 summarizes the five studied configurations: a monolithic CPU reference and four DQR runs under policies A–D. In all cases, the observable ⟨𝑍 ⊗32 ⟩ is estimated via finite-shot sampling with 1024 shots. The appropriate reference is therefore the CPU shot estimate −0.014 with sampling uncertainty 𝜎CPU ≈ 0.031, rather than the exact state vector value. Comparing against the exact reference ⟨𝑍 ⊗32 ⟩exact = 1.82 × 10−10 would conflate sampling noise with systematic error. The exact value simply confirms that the observable is essentially zero for this instance, so all deviations across configurations are sampling fluctuations. The CPU baseline itself lies only 0.44 𝜎 from the exact value. All DQR runs produce estimates consistent with the CPU reference (Table 5, Results section): the four IBM-remote policies (A–D) range from −7.2 × 10−4 to +1.8 × 10−3 (all < 0.06 𝜎), and the local Qmio hybrid yields −6.6 × 10−3 (0.21 𝜎). The reconstruction metadata is identical across all four DQR configurations in Table 5: 72 evaluations, 36 terms, 2 components, and a global factor of 0.25, matching the 62 = 36 gate-cut terms at 𝑘 = 2. This agreement shows that cutting, backend execution, and reconstruction are carried out consistently and that the DQR-time layer introduces no detectable systematic bias. Observable accuracy is governed by the underlying cutting framework and reconstruction method [8], which are external to DQR itself.

6.3.1. CPU baseline and fragmentization. The baseline executes the full 32-qubit HEA circuit as a single Qulacs state vector simulation using 64 OpenMP threads on a node. This requires allocating a 232 –entry complex state vector (64 GB of RAM). The simulation phase alone takes 40.3 s, and with sampling (1024 shots over the full 32-qubit 𝑍 ⊗32 observable), a further 15.5 s (Table 5); the makespan of 56.2 s includes environment initialization overhead. In contrast, all DQR configurations decompose the circuit into 72 fragments of 16 qubits each, reducing Page 12 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems Table 5 Summary comparison of CPU-only simulation (Qulacs) versus the DQR pipeline under four dispatch policies. Metric

CPU

Pol. A

Pol. B

Pol. C

Pol. D

Configuration QC/HPC/U (%) QC slots MPI ranks (np) HPC Nodes

— 10/80/10 20/60/20 20/60/20 30/50/20 — 3 3 20 72 — 13 13 13 73 1 2 2 2 4

Performance CPU simulation (s) Sampling + EV (s) Makespan (s) DQR-time (s) 𝑇QC (s) 𝑇HPC (s) 𝑡̄QPU (s) 𝑡̄HPC (s)

40.3 — — — — 15.5 — — — — 56.2 50.7 91.0 59.6 54.9 — 41.7 76.7 51.7 45.6 — 37.2 72.4 47.0 39.8 — 17.9 14.8 49.2 3.5 — 13.0±1.2 15.0±3.1 24.6±6.0 26.2±8.4 — 3.57±0.13 3.48±0.14 3.60±0.12 3.22±0.11

Results ⟨𝑂⟩ Speedup

−0.014 −2.7×10−5 +1.8×10−3 −2.7×10−4 −7.2×10−4 — +1.11× −0.62× −0.94× +1.02×

per-fragment memory from 64 GB to under 2 MB per MPI worker rank. This drastic reduction enables execution on commodity nodes without special memory provisioning.

Policy A, the optimal approach. Policy A achieves the

best absolute makespan among the DQR runs at 50.7 s, a 1.11× improvement over the baseline. Its 10/80/10 labeling policy routes 58 of the 72 fragments to HPC and 7 to IBM Torino, served by 3 concurrent QC slots across 12 worker ranks plus the coordinator. The 7 QC fragments therefore span ⌈7∕3⌉ = 3 effective QPU rounds; at 𝑡̄QPU = 13.0 s per fragment (QPU-time ≈ 2 s), 𝑇QC = 37.2 s. Policy A is QC-bound (Φ = 𝑇QC ∕𝑇HPC = 2.08 > 1): 𝑇HPC = 17.9 s completes within the QC critical path, so HPC execution is fully overlapped with in-flight QC fragments and does not extend DQR-time = 41.7 s beyond the makespan.

Policy B and slot-induced serialization. Policy B de-

livers the worst performance, with a makespan of 91.0 s. Doubling the QC-labeled fraction relative to Policy A sends 14 fragments to IBM Torino, still over only 3 QC slots; these 14 fragments serialize into ⌈14∕3⌉ = 5 QPU rounds of roughly 15 s each. Wave-level synchronization amplifies this cost: MPI ranks quickly exhaust their local shard batches, and subsequent waves carry an 𝑇QC -induced backlog that leaves HPC capacity idle while QC slots drain. Increasing the fraction of QC labels without proportionally scaling the slot count thus degrades performance via a staircase serialization effect.

Policy C and the effect of QC slots. Policy C retains

the same labeling policy as Policy B (20/60/20, 13 MPI ranks) but increases the QC slot count from 3 to 20. With 20 concurrent slots, all 14 QC-labeled fragments fit within a single effective QPU round (⌈14∕20⌉ = 1), eliminating the staircase serialization that dominated Policy B. In addition, R. S. Raigada-García et al.: Preprint submitted to Elsevier

the available slots allow DQR to resolve 15 Undecided fragments to QC at runtime (raising 𝑛QC = 29; 𝑡̄QPU = 24.6 ± 6.0 s per fragment; ⌈29∕20⌉ = 2 effective rounds; 𝑇QC = 47.0 s). Despite twice as many QC fragments, 𝑇QC drops from 72.4 s to 47.0 s because the slot count collapses five serialized rounds into two concurrent ones. The makespan drops from 91.0 s to 59.6 s, a 34.5% reduction, confirming that the bottleneck in Policy B was slotinduced QPU serialization rather than per-fragment 𝑡̄QPU . The Policy B-versus-C comparison isolates QC slot count as the decisive variable for both makespan and HPC utilization under a fixed labeling policy. Figure 5 illustrates this mechanism on a simplified scenario (10 fragments: 6 HPC, 4 QC; 2 MPI ranks). With 3 QC slots (Policy B analoge), the fourth QC fragment must wait for a slot to free, causing MPI workers to idle once their HPC queues empty. With 6 slots (Policy C analoge), all QC fragments are dispatched in a single wave, halving makespan and eliminating slot-induced queueing. In both cases, it is the slot count—not the rank count—that determines whether the QPU path is serialized into multiple rounds or clears in one.

Policy D and diminishing returns. Policy D (30/50/20,

73 MPI ranks, 72 QC slots, 4 nodes) is the most aggressively provisioned configuration. With 73 MPI ranks homogeneously spread across 4 nodes (72 workers plus one coordinator) and 72 QC slots, the planner can commit all 72 fragments in a single dispatch wave. The 22 QC-labeled fragments fit within one QPU round, while the remaining 50 HPC and Undecided fragments are distributed across the pool of workers. The DQR-time of 45.6 s is the shortest among the DQR runs, and the total makespan of 54.9 s improves on the baseline by 2.4% because almost every rank receives at least one fragment per wave. Despite this favorable scenario, Policy D’s DQR-time is 3.9 s longer than Policy A’s (45.6 vs. 41.7 s), even though Policy D allocates six times as many workers and dispatches all 22 QC fragments in a single wave. The cause is not coordination overhead—𝐶fixed is comparable across policies (4.4 s for Policy A, 5.8 s for Policy D)—but the variance of 𝑡round-trip on IBM Cloud. Under DQR’s nonblocking dispatch, each slot is refilled immediately when a fragment completes; there are no synchronization barriers between logical rounds. 𝑇QC is therefore determined by the slowest fragment in the entire job, not by the mean round duration. With 22 fragments dispatched concurrently, the standard deviation of 𝑡round-trip rises to 8.4 s (𝑡̄QPU = 26.2 s), against 1.2 s (𝑡̄QPU = 13.0 s) for Policy A’s 7 fragments; the slowest fragment sets 𝑇QC = 39.8 s, exceeding Policy A’s 𝑇QC = 37.2 s. This is a property of the variance of 𝑡round-trip on IBM Cloud, not of the DQR dispatch architecture. Figure 6 summarizes makespan for all five configurations. The DQR-time reduction from Policy B to Policy D (76.7 s → 45.6 s) is explained by two independent levers: increasing QC slots from 3 to 72 removes slot-induced QC serialization, and scaling MPI processes from 13 to 73 (one worker per fragment plus the coordinator) eliminates Page 13 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

Figure 5: Fragment dispatch comparison between policies B and C.

together consume under 3.5 s in every run. This overhead is independent from DQR, but it has to be accounted for in the makespan of the job.

Figure 6: Makespan (s) for the CPU baseline and DQR Policies A–D on the 32-qubit HEA circuit. Hatching marks the DQR-time portion of each bar, and the dashed line marks the CPU baseline reference (56.2 s).

rank contention. With only 3 QC slots, fragments queue sequentially for QPU access; with 72 slots, all QC fragments can be concurrently in flight. Likewise, with 12 MPI rank workers managing 72 fragments, ranks must serialize fragment processing; with 72 workers, this bottleneck disappears and only coordination overhead remains. Across all DQR configurations, 𝑡setupℎ ranges from 7.8 s (Policy C) to 14.3 s (Policy B), corresponding to 13–18% of the makespan (Table 5). Although ideally, 𝑡setupℎ should be constant, in production we have experienced time oscillations, in which the dominant contributor is gRPC server startup (3.1–8.3 s), which includes Python environment activation and Qdislib initialization and varies across runs due to node-local caching and filesystem load. Cutting and labeling R. S. Raigada-García et al.: Preprint submitted to Elsevier

6.3.2. Scaling to deeper circuits. To probe the framework’s behavior at higher depth, we repeat the experiment on a 32-qubit HEA circuit with two layers (𝐿=2), totaling 192 gates and depth 68. Doubling the number of layers doubles the number of CZ gates from 32 to 64, increasing the number of cuts from 𝑘=2 to 𝑘=4. Under gate cutting with base 6, this yields 64 = 1296 reconstruction terms and 2 × 64 = 2, 592 subcircuit evaluations, a 36× increase in pipeline volume relative to the 𝐿=1 case. The global reconstruction factor becomes 1∕24 = 0.0625, consistent with four independent CZ cuts. Subcircuit generation dominates QCut worker time at 65.8 s out of 76.3 s total, reflecting the ≈ 70× increase in serialization work compared to 𝐿=1. Results for the CPU-only baseline and the DQR run appear in Tables 6 and 7. The CPU-only baseline completes in 96.4 s, spending 79.8 s on Qulacs state vector simulation and 15.8 s on sampling. The DQR configuration uses a 5/80/15 labeling policy. The 5% QC budget is a deliberate resource cap that limits QPU consumption to the 130 fragments most suited for quantum execution, given the high 𝑡̄QPU expected from the cloud backend at this fragment volume. The pipeline uses 15 QC slots and 193 MPI ranks (192 workers plus one coordinator) across 3 nodes. Of the 2, 592 fragments, 130 are labeled QC, 2, 074 HPC, and 388 Undecided. The total makespan is 316.7 s, a 3.3× slowdown relative to the CPU Page 14 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems Table 6 CPU-only versus DQR pipeline for the 32-qubit HEA at 𝐿=2 (192 gates, depth 68, 1024 shots). Metric Configuration Circuit (𝑛, gates, depth) QC/HPC/U (%) QC slots MPI ranks (np) HPC Nodes Performance CPU simulation (s) Sampling + EV (s) Makespan (s) DQR-time (s) 𝑇QC (s) 𝑇HPC (s) 𝑡̄QPU (s) 𝑡̄HPC (s) Results ⟨𝑂⟩ vs CPU-only

CPU baseline (L2)

DQR (L2)

32 q, 192, 68 32 q, 192, 68 — 5/80/15 — 15 — 192+1 1 3 79.8 15.8 96.4 — — — — —

— — 316.7 190.4 181.3 76.7 18.5±3.0 4.6±2.3

+0.031 —

+0.002 −3.29×

Figure 8: Makespan sensitivity to 𝑡̄QPU for the 𝐿=2 run. Pipeline (𝑡setupℎ ) and 𝑇HPC remain constant; substituting 𝑡̄QPU = 18.5 s (IBM Cloud) with 𝑡̄QPU = 4.5 or 6.6 s (Qmio) reduces makespan by 104.6 s (33 %).

Table 7 𝑡̄QPU sensitivity for the 𝐿=2 DQR run. IBM row: observed statistics (mean ± std / median / range) from the coordinator log. Qmio rows: sensitivity projections using single 𝑡̄QPU values from on-premises measurements (Section 6.2.1, Table 3). 𝐶fixed = 9.1 s (from the IBM run) is held constant across all Qmio rows. Configuration

𝑡̄QPU (s) 𝑇QC (s) DQR-time (s) Makespan (s)

Observed (IBM Cloud, 𝑛QC = 130) IBM Torino 18.5±3.0 / 18.0 / 12.6–28.0 Qmio on-premises — sensitivity 𝑡̄QPU = 16.0 s (max) 𝑡̄QPU = 6.6 s (mean) 𝑡̄QPU = 4.5 s (median) Saving vs. IBM Reference CPU-only (Qulacs)

Figure 7: DQR-time decomposition for the 𝐿=2 run: 𝑇HPC = 76.7 s (40 %) runs in parallel with the 130 QC fragments; the remaining 55 % corresponds to 𝑇QC − 𝑇HPC = 104.6 s, with 𝐶fixed = 9.1 s (5 %) for MPI coordination and tensor reconstruction.

baseline, with a DQR-time of 190.4 s and 𝑡setupℎ = 126.3 s dominated by QCut server startup and subcircuit generation. The 3.3× slowdown is primarily due to high 𝑡̄QPU on IBM Quantum Cloud, not to the DQR dispatch logic. With 15 QC slots and 𝑛QC = 130 fragments, the asynchronous dispatcher requires ⌈130∕15⌉ = 9 effective dispatch rounds. Each round completes when the slowest in-flight fragment returns; with 𝑡̄QPU = 18.5 s, 𝑇QC = 181.3 s constitutes 95% of DQR-time = 190.4 s, with 𝐶fixed = 9.1 s (5%) covering MPI coordination and tensor reconstruction. Figure 7 decomposes the observed DQR-time into 𝑇HPC , 𝑇QC , and 𝐶fixed .

Sensitivity to 𝑡̄QPU . To assess sensitivity to 𝑡̄QPU , we replace the 𝑡̄QPU (IBM Cloud) with the per-fragment times measured on the on-premises CESGA Qmio QPU (Table 7) 𝑡̄QPU = 6.6 s (mean) and 4.5 s (median) per fragment, obtained in the local QPU experiment (Section 6.2.1, Table 3). R. S. Raigada-García et al.: Preprint submitted to Elsevier

Φ vs CPU

181.3

190.4

316.7 2.36

16.0 6.6 4.5

138.7 57.2 39.0

147.8 85.8 85.8

274.1 1.81 ×2.84 212.1 0.75 ×2.20 212.1 0.51 ×2.20 −104.6 s (33 %) for 𝑡̄QPU ≤ 6.6 s

—

—

—

96.4

—

×3.29

ref.

All other parameters (slot count, MPI allocation, subcircuit volume) remain unchanged. Under the Qmio median 𝑡̄QPU = 4.5 s, the QC critical path reduces to 9 × 4.5 = 40.5 s, and under the mean (6.6 s) to 59.4 s. In both cases 𝑇QC < 𝑇HPC = 76.7 s (HPC-bound), so DQR-time = 𝑇HPC + 𝐶fixed = 76.7 + 9.1 = 85.8 s and the total makespan drops to 𝑡setupℎ + 85.8 = 212.1 s. This corresponds to a saving of 104.6 s (33% of the IBM − 𝑇 observed makespan) [= 𝑇QC HPC ] and a 2.20× factor of the CPU baseline. Figure 8 compares the observed IBM Cloud makespan with the Qmio-local projections and the CPU reference. Provisioning additional QC slots beyond 15 brings no measurable improvement in this regime: 𝑇QC (40.5 or 59.4 s) already completes well before 𝑇HPC = 76.7 s. The system is therefore HPC-bound for any practical slot count, and extra QC concurrency lies off the critical path. Using experimentally observed values, this demonstrates that the DQR dispatch architecture introduces no fundamental latency penalty: the bottlenecks are high 𝑡̄QPU (IBM Cloud) and HPC throughput, not the orchestration layer.

Mixed-latency behavior. The five configurations reported

above, taken together, expose three recurring patterns that govern DQR-time in the mixed-latency regime (𝑡̄QPU ≫ Page 15 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

𝑡̄HPC ). We characterize each pattern using the DQR balance number Φ = 𝑇QC ∕𝑇HPC , computable directly from the coordinator log as the ratio of the last QC and last HPC fragment completion timestamps, and the overlap speedup which satisfies 𝜎 ∈ (1, 2]: the lower bound is strict because both paths take non-zero time, and 𝜎 = 2 is attained only at Φ = 1, when both paths complete simultaneously. 𝜎 measures the makespan gain of concurrent versus hypothetical sequential dispatch. The QC slot count 𝑠 is the primary tuning lever, not the rank count. When Φ > 1 (QC-bound configurations: Policies A, B, D and the observed 𝐿=2 run), DQR-time is dominated by 𝑇QC : 𝑇HPC has already completed, so adding MPI ranks cannot reduce 𝑇QC . Policy D illustrates the cost of ignoring this: with 72 workers (a 6× increase over Policy A) and 4× the node-hours, its DQR-time is still 3.9 s longer because MPI coordination overhead outweighs any residual HPC parallelism. The decisive lever is 𝑠: halving the number of effective QC rounds by doubling 𝑠 (Policy B → C) recovers 31.4 s of makespan at identical rank count and node allocation. Policy C (Φ = 0.96, 𝜎 = 1.96) is the only 𝐿=1 configuration that is HPC-bound and achieves the best overlap among all four policies—𝜎 is closest to 2, and 𝐶fixed = 2.57 s is the smallest of the four, reflecting that both critical paths nearly clear simultaneously with minimal coordination residual. Despite this, Policy C produces a longer DQR-time (51.7 s) than Policy A (41.7 s). The reason is not coordination overhead but the absolute magnitude of 𝑇QC : Policy C dispatches 𝑛QC = 29 fragments at 𝑡̄QPU = 24.6 ± 6.0 s per fragment, requiring ⌈29∕20⌉ = 2 effective QPU rounds and yielding 𝑇QC = 47.0 s—longer than Policy A’s 𝑇QC = 37.2 s (7 fragments, 𝑡̄QPU = 13.0 s, 3 rounds). Maximizing 𝜎 (targeting Φ ≈ 1) is therefore not equivalent to minimizing makespan: perfect overlap is achievable while the parallel paths themselves are long. The best-makespan configurations (Policy A, 𝜎 = 1.48; 𝐿=2 observed, 𝜎 = 1.42) operate at Φ ≈ 2–2.4, safely QC-bound, with 𝐶fixed < 5 s and 𝑇QC kept short through a small, low-𝑡̄QPU QC fragment set. Finally, the operative bottleneck depends on the 𝑡̄QPU regime, not only on the labeling policy. The 𝐿=2 sensitivity analysis (Table 7) shows that the same DQR configuration (15 slots, 193 ranks) transitions from QC-bound (Φ = 2.36, IBM Cloud) to HPC-bound (Φ < 1, Qmio on-premises) solely due to a change in 𝑡̄QPU from 18.5 s to 4.5–6.6 s. Under high 𝑡̄QPU (IBM Cloud), reducing 𝑡̄QPU is the dominant lever, and additional QC concurrency is largely irrelevant; under low 𝑡̄QPU (Qmio), the bottleneck shifts to HPC throughput, and extra MPI ranks would reduce DQR-time. Provisioning decisions—how many slots and ranks to allocate—must therefore be calibrated to the actual 𝑡̄QPU of the target backend, not merely to circuit size or fragment count.

R. S. Raigada-García et al.: Preprint submitted to Elsevier

7. Discussion The experiments confirm five key properties of the DQR architecture, demonstrating its viability for production HPCQC workloads under realistic NISQ constraints. First, the non-blocking wave-based dispatcher effectively overlaps 𝑇HPC with 𝑇QC . Policy A achieves a 1.11× makespan speedup over the monolithic CPU baseline while co-executing fragments on the high-latency IBM Torino (𝑡̄QPU ≈ 13.0 s per fragment). As Policy A is QC-bound (Φ = 2.08), 𝑇HPC = 17.9 s completes within the QC critical path—a direct consequence of the pipelined wave model, where new dispatches overlap prior executions without global barriers. Second, the Policy B-vs. C comparison (20∕60∕20 labeling fixed; QC slots 3 → 20) isolates slot capacity as the primary tuning lever, slashing makespan by 34.5% (91.0 → 59.6 s) by collapsing 14 QC fragments from five serialized rounds into two concurrent ones (29 total QC-dispatched fragments). This tunability—independent control of labeling fraction and slot count—enables precise load balancing, absent in static frameworks like Qdislib or early XACC integrations. Third, the Undecided label serves as an emergent load balancer. Deferred until labeled fragments clear, Undecided fragments opportunistically fill freed HPC/QC slots based on live capacity, mitigating imbalances from variance in 𝑡round-trip or transient degradations (𝐶fixed = 2.57 s for Policy C, the smallest of the four policies). Fourth, per-fragment fault isolation ensures resilience. In the local Qmio run, two gate-cut fragments fail with “if-else not supported” errors, exhaust retries, failover to HPC via policy, and complete transparently—preserving the full 72fragment pipeline without restart or user intervention. This granularity exploits fragment independence, scaling fault tolerance beyond whole-job checkpoints. Fifth, overhead scales favorably: at 𝐿 = 2 (2, 592 fragments, 193 ranks), 𝐶fixed = 9.1 s accounts for only 5% of DQR-time; the remaining 95% is 𝑇QC driven by 𝑡̄QPU on IBM Cloud (Figure 7). The sensitivity analysis confirms backend swapability: substituting 𝑡̄QPU = 4.5–6.6 s (Qmio) reduces makespan to 212.1 s (2.20× the CPU baseline), transitioning from QC-bound (Φ = 2.36) to HPC-bound (Φ < 1) without architectural changes. Two concrete limitations emerge from the evaluation. First, a Qmio Cluster compiler gap: Qdislib’s gate-cut decomposition injects mid-circuit classical if–else branches that the current Qmio native stack does not support, preventing fully local hybrid execution and forcing all QC-labeled fragments in the on-premises scenario to fail over to HPC. Resolving this requires either a control-flow-aware native compiler for Qmio, a library update that enables simultaneous compatibility between Qiskit Runtime and Qmio, or a cutting strategy that avoids mid-circuit branches. Second, a provisioning gap: slot count and MPI ranks are fixed at job submission, preventing runtime adaptation to observed 𝑡̄QPU variance; Policy D demonstrates that over-provisioning Page 16 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems

ranks increases 𝐶fixed without reducing 𝑇QC when the system is QC-bound. The integration of a malleable resource manager such as DMR [31, 32] as the next implementation step would address the provisioning gap directly, enabling dynamic adjustment of rank and slot allocations as the workload evolves. The multi-backend QPU path is already implemented in DQR— supporting simultaneous dispatch to both local and remote QPU backends.

8. Conclusions We presented DQR, a runtime framework that decouples quantum circuit cutting from HPC execution orchestration by treating cut fragments as independent schedulable units described by backend-agnostic descriptors. This transforms quantum execution into a classical heterogeneous scheduling problem addressable with mature HPC techniques. Experiments on the CESGA Qmio cluster confirm three quantitative properties. First, the non-blocking wave-based dispatcher overlaps 𝑇HPC with 𝑇QC : Policy A achieves a 1.11× makespan improvement over a monolithic CPU baseline while co-executing fragments on IBM Torino (𝑡̄QPU ≈ 13.0 s, Φ = 2.08). Second, per-fragment fault recovery is transparent: two QPU rejections due to unsupported controlflow are detected, failed over to HPC, and resolved without pipeline restart, demonstrating correct fragment-level isolation. Third, coordination overhead remains bounded: at 2, 592 fragments and 193 MPI ranks (𝐿=2), 𝐶fixed = 9.1 s accounts for only 5% of DQR-time; the remaining 95% is 𝑇QC driven by 𝑡̄QPU on IBM Cloud—an infrastructure constraint external to the framework. These results directly address HPC-QC gaps: (i) cuttingexecution decoupling via agnostic descriptors, enabling Qdislib evolution without re-orchestration; (ii) dynamic replanning for unreliable QPUs, beyond static DAGs; (iii) production primitives (Slurm integration, MPI scalability) absent in research prototypes.

Acknowledgements The authors thank the Accelcom Research Group at the Barcelona Supercomputing Center (BSC) for their support. Language polishing was performed using an AI language model, with subsequent thorough review and editing by the authors. The authors take full responsibility for the final manuscript content.

CRediT authorship contribution statement • Ricard S. Raigada-García: Formal analysis, Methodology, Software, Investigation, Writing - Original Draft. • Josep Jorba: Writing - Review & Editing, Project Administration. • Sergio Iserte: Conceptualization, Investigation, Resources, Writing - Review & Editing, Supervision. R. S. Raigada-García et al.: Preprint submitted to Elsevier

Funding sources The BSC researcher has been financially supported by: "Barcelona Zettascale Laboratory (BZL)" and "QUANTUM ENIA project call - Quantum Spain project" backed by the Ministry of Economic Affairs and Digital Transformation of the Spanish Government and by the European Union through the Recovery, Transformation and Resilience Plan - NextGenerationEU within the framework of the Digital Spain 2026 Agenda. This research project was made possible through the access granted by the Galician Supercomputing Center (CESGA) to its Qmio quantum computing infrastructure with funding from the European Union, through the Operational Programme Galicia 2014-2020 of ERDF_REACT EU, as part of the European Union’s response to the COVID19 pandemic.

Data availability The framework developed for this work, DQR, is available https://github.com/ToroData/Dynamic-Queue-Router

References [1] J. Preskill, Quantum computing in the NISQ era and beyond, Quantum 2 (2018) 79. doi:10.22331/q-2018-08-06-79. [2] S. Wang, E. Fontana, M. Cerezo, K. Sharma, A. Sone, L. Cincio, P. J. Coles, Noise-induced barren plateaus in variational quantum algorithms, Nature Communications 12 (1) (2021) 6961. doi:10.1038/ s41467-021-27045-6. [3] S. Endo, Z. Cai, S. C. Benjamin, X. Yuan, Hybrid Quantum-Classical Algorithms and Quantum Error Mitigation, Journal of the Physical Society of Japan 90 (3) (2021) 032001. doi:10.7566/JPSJ.90.032001. [4] A. Berezutskii, M. Liu, A. Acharya, R. Ellerbrock, J. Gray, R. Haghshenas, Z. He, A. Khan, V. Kuzmin, D. Lyakh, D. Lykov, S. Mandrà, C. Mansell, A. Melnikov, A. Melnikov, V. Mironov, D. Morozov, F. Neukart, A. Nocera, M. A. Perlin, M. Perelshtein, M. Steinberg, R. Shaydulin, B. Villalonga, M. Pflitsch, M. Pistoia, V. Vinokur, Y. Alexeev, Tensor networks for quantum computing, Nature Reviews Physics 7 (10) (2025) 581–593. doi:10.1038/ s42254-025-00853-1. [5] K. R. Fratus, K. Bark, N. Vogt, J. Leppäkangas, S. Zanker, M. Marthaler, J.-M. Reiner, Describing Trotterized Time Evolutions on Noisy Quantum Computers via Static Effective Lindbladians, Quantum 9 (2025) 1854, arXiv:2210.11371 [quant-ph]. doi:10.22331/ q-2025-09-11-1854. [6] C. Piveteau, D. Sutter, Circuit knitting with classical communication, IEEE Transactions on Information Theory 70 (4) (2024) 2734–2745, arXiv:2205.00016 [quant-ph]. doi:10.1109/TIT.2023.3310797. [7] W. Tang, T. Tomesh, M. Suchara, J. Larson, M. Martonosi, CutQC: using small Quantum computers for large Quantum circuit evaluations, in: Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ACM, Virtual USA, 2021, pp. 473–486. doi:10.1145/ 3445814.3446758. [8] K. Mitarai, K. Fujii, Constructing a virtual two-qubit gate by sampling single-qubit operations, New Journal of Physics 23 (2) (2021) 023021. doi:10.1088/1367-2630/abd7bc. [9] T. Peng, A. W. Harrow, M. Ozols, X. Wu, Simulating Large Quantum Circuits on a Small Quantum Computer, Physical Review Letters 125 (15) (2020) 150504. doi:10.1103/PhysRevLett.125.150504. [10] M. Tejedor Ninou, Towards scalable quantum simulation: Distributed circuit cutting for hybrid quantum-hpc systems (2025). URL https://hdl.handle.net/2445/222573

Page 17 of 18

Wave-Based Dispatch for Circuit Cutting in Hybrid HPC–Quantum Systems [11] A. Elsharkawy, X.-T. M. To, P. Seitz, Y. Chen, Y. Stade, M. Geiger, Q. Huang, X. Guo, M. A. Ansari, C. B. Mendl, D. Kranzlmüller, M. Schulz, Integration of quantum accelerators with high performance computing – a review of quantum programming tools, arXiv preprint arXiv:2309.06167 (2023). doi:10.48550/arXiv.2309.06167. [12] T. Beck, A. Baroni, R. Bennink, G. Buchs, E. A. Coello Perez, M. Eisenbach, R. Ferreira da Silva, M. Gopalakrishnan Meena, K. Gottiparthi, P. Groszkowski, T. S. Humble, R. Landfield, K. Maheshwari, S. Oral, M. A. Sandoval, A. Shehata, I.-S. Suh, C. Zimmer, Integrating quantum computing resources into scientific hpc ecosystems, arXiv preprint arXiv:2408.16159Related journal version in Future Generation Computer Systems, doi:10.1016/j.future.2024.06.058 (2024). doi:10.48550/arXiv.2408.16159. [13] A. Shehata, T. Naughton, I.-S. Suh, High performance computing and quantum computing integration framework architecture and requirements document, Tech. Rep. ORNL/TM-2024/3388, Oak Ridge National Laboratory, Oak Ridge, TN, USA (2024). [14] P. Döbler, M. S. Jattana, A survey on integrating quantum computers into high performance computing systems, arXiv preprint arXiv:2507.03540 (2025). doi:10.48550/arXiv.2507.03540. [15] M. Tejedor, B. Casas, J. Conejero, A. Cervera-Lierta, R. M. Badia, Orchestrating quantum-hpc workflows with distributed quantum circuit cutting, 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, 2025, p. 1898–1906. doi:10.1145/ 3731599.3767547. [16] K. A. Britt, T. S. Humble, High-performance computing with quantum processing units, arXiv preprint arXiv:1511.04386 (2015). doi: 10.48550/arXiv.1511.04386. [17] M. Tejedor, M. Grossi, C. Tüysüz, R. Rocha, S. Vallecorsa, Kubernetes-orchestrated hybrid quantum-classical workflows (2026). arXiv:2603.24206. [18] S. Endo, Z. Cai, S. C. Benjamin, X. Yuan, Hybrid quantum-classical algorithms and quantum error mitigation, Journal of the Physical Society of Japan 90 (3) (2021) 032001. doi:10.7566/JPSJ.90.032001. [19] X. Ge, R.-B. Wu, H. Rabitz, The optimization landscape of hybrid quantum-classical algorithms: From quantum control to nisq applications, arXiv preprint arXiv:2201.07448 (2022). doi:10.48550/arXiv. 2201.07448. [20] G. De Luca, A survey of nisq era hybrid quantum-classical machine learning research, Journal of Artificial Intelligence and Technology 2 (1) (2021) 9–15. doi:10.37965/jait.2021.12002. [21] R. Rocco, S. Rizzo, M. Barbieri, G. Bettonte, E. Boella, F. Ganz, S. Iserte, A. J. Peña, P. Sandås, A. Scionti, O. Terzo, C. Vercellino, G. Vitali, P. Viviani, J. Frassineti, S. Marzella, D. Ottaviani, I. Colonnelli, D. Gregori, Dynamic Solutions for Hybrid QuantumHPC Resource Allocation, in: 2025 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 02, 2025, pp. 34–40. doi:10.1109/QCE65121.2025.10289. [22] A. J. McCaskey, D. I. Lyakh, E. F. Dumitrescu, S. S. Powers, T. S. Humble, XACC: A system-level software infrastructure for heterogeneous quantum–classical computing, Quantum Science and Technology 5 (2) (2020) 024002. doi:10.1088/2058-9565/ab6bf6. [23] T. M. Mintz, A. J. McCaskey, E. F. Dumitrescu, S. S. Powers, S. Moore, P. Lougovski, QCOR: A language extension specification for the heterogeneous quantum-classical model of computation, ACM Journal on Emerging Technologies in Computing Systems 16 (2) (2020) Article 24. doi:10.1145/3380964. [24] T. Nguyen, A. Santana, T. Kharazi, D. Claudino, H. Finkel, A. McCaskey, Extending C++ for heterogeneous quantum-classical computing, ACM Transactions on Quantum Computing 3 (2) (2022) Article 10. doi:10.1145/3462670. [25] P. Mantha, F. J. Kiwit, N. Saurabh, S. Jha, A. Luckow, Pilot-quantum: A middleware for quantum-HPC resource, workload and task management, in: Proc. 25th IEEE Int. Symp. on Cluster, Cloud and Internet Computing (CCGrid), 2025, pp. 164–173. doi:10.1109/ CCGRID64434.2025.00070.

R. S. Raigada-García et al.: Preprint submitted to Elsevier

[26] E. Giortamis, F. Romao, N. Tornow, D. Lugovoy, P. Bhatotia, Qonductor: A cloud orchestrator for quantum computing, in: Proc. SC ’25, ACM, 2025, pp. 728–745. doi:10.1145/3712285.3759785. [27] P. Viviani, et al., Demystifying HPC-Quantum integration: It’s all about scheduling, in: Proc. Workshop on High Performance and Quantum Computing Integration (HPQCI), SC ’24, ACM, 2024. doi: 10.1145/3659996.3673223. [28] A. B. Yoo, M. A. Jette, M. Grondona, Slurm: Simple linux utility for resource management, in: D. Feitelson, L. Rudolph, U. Schwiegelshohn (Eds.), Job Scheduling Strategies for Parallel Processing, Springer Berlin Heidelberg, Berlin, Heidelberg, 2003, pp. 44–60. [29] Y. Suzuki, Y. Kawase, Y. Masumura, Y. Hiraga, M. Nakadai, J. Chen, K. M. Nakanishi, K. Mitarai, R. Imai, S. Tamiya, T. Yamamoto, T. Yan, T. Kawakubo, Y. O. Nakagawa, Y. Ibe, Y. Zhang, H. Yamashita, H. Yoshimura, A. Hayashi, K. Fujii, Qulacs: a fast and versatile quantum circuit simulator for research purpose, Quantum 5 (2020) 559. URL https://api.semanticscholar.org/CorpusID:227210407 [30] M. AbuGhanem, Ibm quantum computers: evolution, performance, and future directions, The Journal of Supercomputing 81 (5) (2025) 687. doi:10.1007/s11227-025-07047-7. [31] S. Iserte, M. Madon, G. Da Costa, J.-M. Pierson, A. J. Peña, MPI Malleability Validation under Replayed Real-World HPC Conditions, Future Generation Computer Systems (2025) 108305doi:10.1016/j. future.2025.108305. [32] S. Iserte, I. Martín-Álvarez, K. Rojek, J. I. Aliaga, M. Castillo, W. Folwarska, A. J. Peña, Resource optimization with MPI process malleability for dynamic workloads in HPC clusters, Future Generation Computer Systems (2025) 107949doi:10.1016/j.future.2025.107949.

Page 18 of 18