Quantum Executor: Middleware for Quantum Systems

• Quantum Executor is a system layer that bridges quantum programs and heterogeneous hardware by handling IR lowering, experiment specification, and resource management.
• It encompasses diverse designs including middleware orchestration, QIR-based runtimes, and task-based schedulers that optimize quantum execution across platforms.
• Executor architectures balance fidelity and utilization while addressing challenges in error mitigation, circuit cutting, and efficient scheduling for hybrid quantum-classical systems.

Searching arXiv for the cited Quantum Executor and closely related execution/runtime papers. Quantum Executor is a term used in recent quantum-systems literature for execution-layer mechanisms that sit between quantum programs and heterogeneous backends. Depending on the work, it denotes a backend-agnostic orchestration engine, a QIR-based runtime, a task-based classical–quantum scheduler, a compiler/hardware co-design for distributed instruction execution, or an operating-system style substrate for multi-programming and fidelity-aware scheduling. Across these variants, the executor is responsible for some combination of experiment specification, IR lowering, split/merge policy selection, device virtualization, dispatch to simulators or QPUs, result collection, and resource management across space and time (Bisicchia et al., 10 Jul 2025, Miniskar et al., 12 May 2026, Ronde et al., 18 Nov 2025).

1. Named usages and conceptual scope

Several papers use “Quantum Executor” as either a proper system name or a descriptive label for a broader execution substrate. In "Quantum Executor: A Unified Interface for Quantum Computing" (Bisicchia et al., 10 Jul 2025), it is a middleware-style orchestration engine on top of Qiskit, Cirq, PennyLane, Amazon Braket, and related SDKs. In "Parallelizing Program Execution on Distributed Quantum Systems via Compiler/Hardware Co-Design" (Ronde et al., 18 Nov 2025), the term refers to a co-designed compiler and hardware execution model for distributed quantum systems. In "Classic and Quantum Task-Based Intelligent Runtime for QIRs Running on Multiple QPUs" (Miniskar et al., 12 May 2026), it denotes the combined IRIS + QIR-EE runtime. In "A Cross-Platform Execution Engine for the Quantum Intermediate Representation" (Wong et al., 2024), QIR-EE itself is presented as a quantum executor. The Quantum Brilliance SDK paper describes an executor framework with asynchronous and MPI-based modes (Nguyen et al., 2022). CONQURE, Pilot-Quantum, QOS, HALO, QuMC, DYNAMO, and Q-IRIS all implement closely related executor functions, although they are framed respectively as a co-execution environment, middleware, operating system, quantum operating system, multi-programming compiler, multi-programming optimizer, and task-based runtime (Mahesh et al., 4 May 2025, Mantha et al., 2024, Giortamis et al., 2024, Ye et al., 6 Feb 2026, Niu et al., 2021, Sun et al., 7 Jul 2025, Miniskar et al., 15 Dec 2025).

System or usage	Primary scope	Distinctive mechanism
Quantum Executor	Backend-agnostic orchestration	SplitPolicy, MergePolicy, VirtualProvider, ResultCollector
IRIS + QIR-EE	Hybrid runtime across multiple QPUs	DAG scheduling of classical and quantum tasks
Compiler/hardware co-design executor	Distributed quantum systems	Two-level hierarchical instruction decode and compiler reordering
QIR-EE	Cross-platform QIR execution	LLVM JIT plus XACC-based hardware dispatch
QB SDK executor framework	Many-QPU parallel execution	AsynchronousSharedExecutor and MPIVirtualExecutor
CONQURE	Quantum/classical co-execution	REST API, MariaDB, SLURM-based scheduler
HALO / QOS / QuMC / DYNAMO	OS-style execution and multi-programming	Fine-grained sharing, compatibility-aware scheduling, partitioning, runtime reallocation

The common denominator is execution control rather than algorithm design. The executor layer absorbs provider heterogeneity, mediates between logical workloads and concrete devices, and often expands to include scheduling, compilation, and error-aware policies. This suggests that, in current literature, “executor” is broader than a mere job launcher.

2. Architectural patterns

A recurring pattern is hierarchical decomposition. The distributed-system co-design uses a system-in-three-layers: a Central Controller for high-level flow control, Node Controllers managing small groups of physical qubits via dedicated signal generators, and a Quantum-Classical Interface plus quantum chip. Its instruction path includes subnet decoders and second-level NC selection, with configurable subnet count $M$, NCs per subnet $K$, and total $N=M\cdot K$ (Ronde et al., 18 Nov 2025).

QIR-centric executors are built around IR interpretation and backend dispatch. QIR-EE comprises a QIR Loader/Parser, an LLVM-Based Interpreter using LLVM’s ExecutionEngine, Runtime Extension Points, and a Hardware Dispatch Module. The formal execution mapping is expressed as $\phi:Q\to L$, $\psi:L\times Backend\to H$, and $\omega=\psi\circ\phi$, with

$$\omega(q)=B.\mathrm{nativeGate}(q)\quad \forall q\in Q.$$

This structure makes backend substitution an explicit runtime concern rather than a source-level rewrite problem (Wong et al., 2024).

Task-based hybrid runtimes embed the quantum executor as a device type. In the IRIS + QIR-EE design, the bridge is a QIR-EE Device Driver inside IRIS. A submitted QIR module is placed in an MMAP region, a helper process is spawned because QIR-EE is not yet thread-safe, and measured expectation values are marshaled back into IRIS’s heterogeneous-memory model. The scheduler then treats quantum subroutines like any other task, enforcing dependencies, selecting devices, and overlapping classical and quantum work (Miniskar et al., 12 May 2026).

HPC-oriented systems adopt layered software stacks. The QB SDK exposes a frontend, middleware, and backend stack, with executors sitting above it in two interchangeable modes: AsynchronousSharedExecutor and MPIVirtualExecutor (Nguyen et al., 2022). CONQURE uses a five-layer stack comprising a User Interface Layer, Translation Layer, Workload Manager, Database Layer, and Quantum Control Layer, with a REST API server, MariaDB, and a SLURM-based scheduler (Mahesh et al., 4 May 2025). These designs emphasize that quantum execution is increasingly treated as a systems problem with conventional runtime components: parsers, schedulers, databases, process managers, and resource plugins.

3. Scheduling, partitioning, and multi-programming

Resource management is the most technically diverse part of the executor literature. HALO is explicitly a fine-grained resource-sharing quantum operating system. Its three-stage pipeline consists of a shot-aware batch scheduler, a data-qubit space manager, and a helper-qubit and instruction scheduler. For a QPU graph $G=(V,E)$ and layout $L$, HALO defines

$$\mathrm{Cost}(L,G)=\alpha\cdot \mathrm{Intro}(L,G)-\beta\cdot \mathrm{Inter}(L,G)+\gamma\cdot \mathrm{HRCost}(L,G),$$

with $K$0, $K$1, and $K$2, and seeks

$K$3

Its temporal scheduler uses $K$4, $K$5, a data-qubit occupancy ratio $K$6, and space-time efficiency

$K$7

The design jointly optimizes routing overhead, inter-process separation, helper access, and shot allocation (Ye et al., 6 Feb 2026).

QOS casts scheduling as a multi-objective optimization over job ordering $K$8 and resource assignment $K$9:

$N=M\cdot K$0

Its runtime also defines a compatibility score for bundled jobs,

$N=M\cdot K$1

with $N=M\cdot K$2 and threshold $N=M\cdot K$3 for bundling (Giortamis et al., 2024). This makes fidelity, waiting time, and utilization first-class optimization variables rather than post hoc measurements.

QuMC and DYNAMO specialize multi-programming to specific hardware and compilation models. QuMC introduces a Parallelism Manager, Qubit-Partitioning Module, Crosstalk Characterization, and Mapping-Transition Optimizer. Its Greedy Subgraph Partition and Heuristic Subgraph Partition use crosstalk-adjusted reliability scores and a Simultaneous Randomized Benchmarking protocol to avoid harmful concurrent layouts (Niu et al., 2021). DYNAMO, by contrast, targets neutral-atom QPUs with a Global Parallel Compiler, Per-QPU Multi-Programming Compiler, and Runtime Resource Manager. It formalizes assignment variables $N=M\cdot K$4, start cycles $N=M\cdot K$5, execution indicators $N=M\cdot K$6, width constraints, blockade constraints, and AOD movement ordering, then combines a greedy global placement phase with SMT-based per-QPU schedule merging (Sun et al., 7 Jul 2025).

Pilot-Quantum uses a pilot abstraction with pilots $N=M\cdot K$7, tasks $N=M\cdot K$8, and workloads $N=M\cdot K$9, and allocation constraints

$\phi:Q\to L$0

Its multi-level scheduling separates pilot-level workload placement from within-pilot task scheduling (Mantha et al., 2024). Across these systems, executor design increasingly converges on explicit scheduling formalisms, rather than ad hoc batch submission.

4. Intermediate representations, task graphs, and user-facing APIs

QIR is a central IR for several executor designs. QIR-EE parses LLVM assembly containing QIR, extracts module flags such as num_required_qubits and entry_point, binds QIR intrinsics to runtime stubs through addGlobalMapping(), and invokes the parsed main entry point. Backends implement an abstract ExecutionBackend with initialize, applyGate, measure, and finalize methods, and are registered through a factory interface (Wong et al., 2024).

Task-graph runtimes make these IRs schedulable units. In IRIS, a program is lowered to a DAG $\phi:Q\to L$1 with classical kernels $\phi:Q\to L$2, quantum kernels $\phi:Q\to L$3, and a final merge task $\phi:Q\to L$4. For QIR tasks, the device-dependent cost is modeled as

$\phi:Q\to L$5

and a scheduling policy may pick

$\phi:Q\to L$6

This design treats compilation, transmission, execution, and result return as runtime-visible components (Miniskar et al., 12 May 2026).

Q-IRIS exposes quantum tasks as QIR kernels inside IRIS. A task is created with task.kernel("filename.ll", ...), can be submitted asynchronously, queried through .status() -> {PENDING, RUNNING, COMPLETE}, and extended with .on_complete(callback_fn). Its scheduler keeps distinct ready queues $\phi:Q\to L$7 and $\phi:Q\to L$8 and alternates quantum and classical work to ensure fairness (Miniskar et al., 15 Dec 2025).

The middleware-style Quantum Executor defines four public classes: QuantumExecutor, Dispatch, ResultCollector, and VirtualProvider. It separates experiment definition from execution policy through SplitPolicy and MergePolicy, supports run_experiment(...), allows wait=False for asynchronous execution, and can use multiprocess=True for distributed dispatch. The same system formalizes equal-shot splitting and uses Total Variation Distance,

$\phi:Q\to L$9

for hybrid validation workflows (Bisicchia et al., 10 Jul 2025). CONQURE exposes a more queue-oriented API—create_work, get_status, wait_until_done, get_results, and cancel_work—with status values {PENDING | RUNNING | DONE | ERROR} (Mahesh et al., 4 May 2025). Together, these APIs show two dominant styles: declarative orchestration over heterogeneous providers, and task or job interfaces aligned with HPC runtimes and cloud queues.

5. Representative workloads and reported performance

Empirical evaluation spans instruction-level parallelism, circuit-level multiplexing, task decomposition, and hybrid HPC execution.

The distributed compiler/hardware co-design was evaluated on 18 programs drawn from QASMBench and MQTBench, ranging from 130 to 433 logical qubits. In the semi-distributed mode it reported compiler-only speedups of 1.03×–13.6× with average 6.11×, hardware-only 0.55×–6.0× with peak average approximately 1.96×, and combined 0.70×–56.2× with peak average 16.5×. In the fully-distributed mode the combined result was 0.50×–30.4× with peak average 12.5× (Ronde et al., 18 Nov 2025).

HALO was evaluated on IBM Torino, a 133-qubit superconducting device, under Poisson(0.6 jobs/sec) arrivals over 40 sec and four benchmark suites. With $\psi:L\times Backend\to H$0 on the mixed benchmark, it reported space utilization 0.805 versus HyperQ 0.330, processes per batch 10.17 versus HyperQ 2.29, and fidelity 0.327 versus HyperQ 0.487. The paper states up to 2.44× higher hardware utilization, 4.44× higher throughput, fidelity loss within 33%, average utilization raised by 2.99×, and more than 10× higher PPB versus exclusive-use IBM Quantum, effectively cutting end-to-end queue+execution latency by approximately 90% (Ye et al., 6 Feb 2026).

The IRIS + QIR-EE executor used circuit cutting on 4-qubit and 20-qubit GHZ circuits. For the 20-qubit case on QIR-QSIM, the reported times were 1.06 s for the cut case and 82.7 s for no cut, yielding a raw speedup of approximately 82×. For the 4-qubit simulator study, the fastest end-to-end time was QIR-QSIM at 3.7 s versus 4.2 s for XACC/AER (Miniskar et al., 12 May 2026). Q-IRIS reported that monolithic 4-qubit simulation had average live time 200 ms and throughput approximately 5 tasks/s, whereas 64 subcircuits of size 2 had average live time 30 ms and throughput approximately 33.3 tasks/s, with a net speed-up of about 6× higher simulator throughput and a reduction in maximum queue length from 16 to 5 (Miniskar et al., 15 Dec 2025).

The QB SDK executor framework reported nearly linear speedup up to $\psi:L\times Backend\to H$1 on an $\psi:L\times Backend\to H$2 ground-state energy workload with 3052 Pauli-term circuits (Nguyen et al., 2022). CONQURE measured create_work latency with median approximately 12.7 ms on simulator and 12.8 ms on a real device across 1 000 trials, and reported a VQE parallel speedup of approximately 3.1× when six runs were executed in OpenMP-Q parallel (Mahesh et al., 4 May 2025). Pilot-Quantum reported task throughput figures up to 418.1 tasks/s in a Ray-based mini-app, circuit-cutting speedups of 2.1× and 3.5× for selected cases, a best 5.5× full state-vector speedup on 16 nodes, and a 15× end-to-end speedup in a QML mini-app compression stage (Mantha et al., 2024). QOS reported 2.6–456.5× higher fidelity, utilization gains up to 9.6×, and waiting-time reductions up to 5× while sacrificing only 1–3% fidelity on average (Giortamis et al., 2024).

These results indicate that “execution” is not tied to one optimization axis. Reported benefits arise from different mechanisms: identical-parameter instruction issue, helper-qubit sharing, task slicing through circuit cutting, pilot-based scheduling, OpenMP-style offload, and fidelity-aware co-scheduling.

6. Trade-offs, misconceptions, and open problems

A frequent misconception is that a quantum executor is only a provider-neutral submission wrapper. The literature does include wrapper-style interfaces, but many executors perform deeper functions: they manage shot slicing, queueing, crosstalk-aware placement, error mitigation, result knitting, or instruction scheduling. Another misconception is that quantum parallelism in executors only means sending independent circuits to different QPUs. In the cited systems it also includes fine-grained helper sharing on one QPU, instruction-level parallel issue across Node Controllers, simultaneous multi-programming on partitioned hardware, and the decomposition of one circuit into many smaller tasks (Ye et al., 6 Feb 2026, Ronde et al., 18 Nov 2025, Miniskar et al., 12 May 2026).

The dominant trade-off is between fidelity and utilization. HALO exposes $\psi:L\times Backend\to H$3 as a concurrency knob: higher occupancy improves utilization and throughput but increases crosstalk and routing noise; the system notes that for critical circuits one can choose $\psi:L\times Backend\to H$4 (Ye et al., 6 Feb 2026). QOS exposes an analogous fidelity–waiting-time balance through its scheduler parameter $\psi:L\times Backend\to H$5 and compatibility weights $\psi:L\times Backend\to H$6 (Giortamis et al., 2024). CONQURE identifies queueing and host-side overhead through $\psi:L\times Backend\to H$7 and points to adaptive scheduling and reverse offload as future extensions (Mahesh et al., 4 May 2025).

Several technical limits recur. The distributed co-design executor requires identical opcodes and parameters across targeted NCs for parallel issuance, and address overhead $\psi:L\times Backend\to H$8 grows with bitmap width (Ronde et al., 18 Nov 2025). QIR-EE-based systems inherit thread-safety and dispatch overhead concerns: the IRIS integration currently spawns a helper process because QIR-EE is not yet thread-safe, while QIR-EE itself identifies kernel fusion, JIT specialization, and dynamic qubit remapping as future optimizations (Miniskar et al., 12 May 2026, Wong et al., 2024). HALO states that placement is NP-hard, uses simulated annealing rather than provably optimal solutions, and assumes a single monolithic device, leaving multi-node or multi-chip QPUs with entanglement links as an open challenge (Ye et al., 6 Feb 2026). DYNAMO likewise separates a platform-agnostic global compiler from platform-specific per-QPU schedulers, implying that portability across qubit modalities requires replacing movement and crosstalk constraints rather than reusing the full executor unchanged (Sun et al., 7 Jul 2025).

Taken together, these works suggest that the modern quantum executor is evolving toward a full execution substrate: IR-aware, resource-aware, backend-agnostic at the API boundary, but highly hardware-conscious in its internal scheduling and dispatch logic.