Quantum Broker: QoS-Aware Distribution of Quantum Computations

AI summary

Overview

Research area: Quantum software engineering and hybrid quantum–cloud computing, specifically execution management and Quality-of-Service (QoS) provisioning across heterogeneous Quantum Processing Units (QPUs).

Technical level: Intermediate. Readers should be comfortable with quantum circuits, shots, and NISQ noise, plus basic optimisation concepts (mixed-integer linear programming, annealing); the paper supplies background on all of these.

Scope: The paper presents the Quantum Broker, an open-source, provider-agnostic framework that lets users declare QoS requirements in a dedicated language and automatically computes and executes a plan that distributes the measurement shots of a single quantum circuit across multiple heterogeneous backends.

What This Paper Is About

Cloud quantum platforms expose devices that differ in qubit technology, calibration, queueing, pricing, access policy, and metadata, so choosing where to run a circuit — and how to split its shots — materially changes cost, latency, fidelity, and reproducibility. Existing workflows leave these non-functional requirements buried in ad hoc scripts and manual backend choices. The paper's goal is to turn quantum execution into an explicit engineering problem: specify QoS requirements portably, profile available backends, optimise a dispatch plan, and execute it across providers.

Key Contributions

1. QQSpec (Quantum QoS Specification Language): a declarative domain-specific language for expressing hard constraints and optimisation objectives over cost, execution time, waiting time, fidelity, backend usage, and shot allocation.

2. A modular, provider-agnostic architecture: a Profiler–Reasoner–Executor decomposition that separates requirement specification, backend profiling, decision making, and execution, with pluggable providers, solvers, and profiling strategies.

3. QoS-aware shot-wise dispatch as constrained optimisation: the statistical independence of measurement shots is operationalised into an optimisation problem where shots of one circuit are allocated across multiple heterogeneous QPUs, solved by either a MILP solver (integer shot variables, binary backend-use variables, linearised QoS) or a nonlinear dual-annealing solver (profile-driven, more complex QoS models).

4. Empirical and end-to-end validation plus open-source release: evaluation on benchmark circuits and noisy simulator backends against exhaustive single-backend and naive multi-backend baselines, complemented by an end-to-end experiment using the (F_{\mathrm{E2E}}) metric (aggregated output distribution compared with an ideal noise-free reference), with the framework released at github.com/di-unipi-socc/TheQuantumBroker.

The paper explicitly states that shot-wise distribution itself is not claimed as new; the split/merge methodology, calibration concepts, incremental execution, and an initial strategy-oriented DSL came from the authors' prior work.

Main Findings

• Feasibility under heterogeneity: The Quantum Broker can produce feasible QoS-aware dispatch plans under heterogeneous backend conditions, as reported in the abstract and derived from experiments on benchmark quantum circuits and noisy simulator backends with fixed QoS profiles.

• Improvement over baselines: QoS satisfaction improves relative to both exhaustive single-backend baselines and a naive multi-backend baseline. Specific numeric magnitudes are not present in the provided text.

• Planning-time versus dispatch-quality trade-off: The nonlinear dual-annealing solver produces higher-quality allocations at increased computational cost, while the MILP solver plans efficiently under linearised QoS assumptions. The MILP's optimality certificate applies only to the linearised model, not to the original nonlinear Profiler functions.

• End-to-end aggregation quality: For selected dispatches, each backend executed exactly the number of shots assigned, counts were merged, and the resulting application-visible distribution was compared with an independently generated ideal noise-free reference via (F_{\mathrm{E2E}}) — validating execution and aggregation independently of the synthetic QoS estimates used during planning.

• Bias depends on the merge policy, not just on shot independence: If QPU (m) samples distribution (p_m) with (n_m) of (N=\sum_m n_m) shots, raw count pooling estimates the mixture (p_{\mathrm{pool}} = \sum_m (n_m/N)p_m), which need not equal the ideal distribution. Aggregation is therefore treated as a configurable policy (the prior framework studies uniform, Hellinger-based, and MISE-based merges) rather than assuming heterogeneous outputs are interchangeable.

• Not reported: Concrete speedups, cost savings, fidelity values, circuit names, shot totals, and planning times are absent from the truncated content supplied, so no such figures are quoted here.

Methodology in Plain English

The authors build a mediation layer that sits between a user and a pool of quantum backends. A user submits a circuit, a shot count, and a QQSpec document stating what matters — for example a budget cap, a minimum fidelity, or avoidance of certain providers. The Profiler gathers static and dynamic device information from multiple providers and normalises it into a common view. The Reasoner takes the workload plus those profiles and solves an optimisation problem to decide how many shots go to which backend, using either a mixed-integer linear solver for fast planning on linearised metrics or a nonlinear dual-annealing solver for richer, profile-driven models. The resulting plan is an explicit, hierarchical "dispatch" structure mapping providers to backends to lists of (circuit, shots) tasks. The Executor then submits those tasks, which may use different circuit formats such as Qiskit, Cirq, PennyLane, or OpenQASM, monitors them asynchronously, and merges returned counts into a single output distribution.

Evaluation is deliberately controlled rather than run on live hardware: device-specific noisy simulators with fixed QoS profiles stand in for real QPUs so that dispatch strategies and solver behaviour can be compared reproducibly. Two experiments are run — a planning-level comparison against single-backend and naive multi-backend baselines, and an end-to-end execution where the Reasoner's chosen split is actually executed and the aggregated distribution is scored against an ideal reference.

Why This Matters

Impact on research. The work reframes backend selection from "pick the best QPU for a job" to "solve a constrained allocation problem over shots," and gives the quantum software engineering community a concrete, open, and reproducible artefact for studying non-functional requirements. It also makes explicit a subtlety often glossed over: independence of shots justifies splitting sampling work but does not by itself guarantee an unbiased estimate of the ideal output.

Real-world applications:

• Running variational or sampling-based workloads on cloud quantum services under a monetary budget and deadline, where no single device satisfies both.
• Load-spreading across providers when one vendor's queue is congested, so a single backend bottleneck cannot compromise the whole run.
• Resilience engineering: if one device fails, only its assigned shots are affected, preserving the rest of the computation.
• Reproducible benchmarking pipelines where an explicit dispatch plan documents exactly which device produced which counts for later comparison.
• Federated execution of large workloads, where shot-wise scheduling composes with circuit cutting by applying the method independently to each subcircuit.

Industry relevance. The framework abstracts over IBM, IonQ, Rigetti, and OQC-style providers and over SDKs including IBM Qiskit, AWS Braket, and Azure Quantum, which is the kind of portability layer enterprises need before committing hybrid quantum–classical workloads to a multi-vendor strategy. Its explicit cost, latency, and fidelity knobs map directly onto service-level objectives that platform operators already reason about.

Future Directions

• Live-hardware validation and profile calibration: the authors treat real-QPU deployment and calibration of QoS profile parameters as supported paths and future validation steps, leaving open how synthetic profiles track real device drift.
• Congestion from many small jobs: splitting shots multiplies the number of cloud interactions and can add scheduling complexity, a problem the authors say they are currently investigating.
• Noise-aware and reliability-aware allocation and merging: extending beyond raw count pooling toward calibrated, reliability-weighted or statistically corrected merges, building on the uniform, Hellinger-based, and MISE-based strategies studied earlier.
• Composition with circuit cutting: applying shot-wise scheduling to each subcircuit so that workloads exceeding single-device qubit counts can be decomposed and distributed across a federation of QPUs.

Target Audience

Quantum software engineers and architects building applications on cloud QPUs; researchers in quantum software engineering and hybrid quantum–cloud orchestration who study scheduling, QoS, and portability; platform engineers designing multi-provider execution layers; and graduate students who want a concrete, open-source system illustrating how declarative requirements, backend profiling, and optimisation fit together in a quantum execution stack. Readers seeking hard performance numbers should consult the full experimental section, since the quantitative results are not included in the content summarised here.

Authors’ abstract

Cloud-accessible quantum computing has made heterogeneous Quantum Processing Units (QPUs) available through provider platforms that differ in qubit technology, calibration state, queueing behavior, and pricing model. This heterogeneity makes execution management a quantum-engineering concern: a quantum circuit may be executable on several backends, but the resulting cost, latency, fidelity, and reproducibility depend on backend selection and on how measurement shots are allocated. This paper presents the Quantum Broker, an open-source and provider-agnostic framework for Quality-of-Service-aware quantum execution management. The framework operationalizes shot-wise distribution by exploiting the statistical independence of quantum measurement shots to dispatch a single circuit across multiple heterogeneous QPUs according to user-defined constraints and optimization objectives. It combines a modular execution architecture, interchangeable backend-profiling strategies, and the Quantum QoS Specification Language (QQSpec), a declarative language for expressing QoS requirements. Dispatch planning is supported by two solver backends: a mixed-integer linear-programming (MILP) solver, and a nonlinear dual-annealing solver. Experiments on benchmark quantum circuits and noisy simulator backends show that the Quantum Broker can produce feasible QoS-aware dispatch plans under heterogeneous backend conditions and can improve QoS satisfaction with respect to single-backend and naive multi-backend baselines. The results also expose a practical trade-off between planning time and dispatch quality, with the nonlinear solver producing higher-quality allocations at increased computational cost. Overall, the Quantum Broker provides an extensible execution-management layer for engineering portable, reproducible, and QoS-aware quantum software over fragmented quantum cloud infrastructures.