The Signal
Quantum Broker Splits Circuit Shots Across Competing QPUs
A paper posted October 20 introduces Quantum Broker, software that allocates a quantum circuit’s measurement shots among heterogeneous QPUs according to cost, timing and other service requirements. Tests on noisy simulators found a mean out
Quantum.world Team · Written with AI · fact-checked ·
One circuit, divided among several machines
A quantum circuit’s measurement shots can be split among competing processors rather than sent as one job to one device, according to a paper posted on arXiv on October 20. The proposed Quantum Broker chooses how many shots to assign to each backend based on a user’s service requirements, which can include cost, execution time, queue delay, fidelity and preferred hardware.
Shots are repeated executions of the same circuit used to build a statistical picture of its output. Because those repetitions are independent, they can be distributed and their measurement counts combined. The paper’s authors describe the framework this way:
“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.”
Giuseppe Bisicchia, Alessandro Bocci, Jose Garcia-Alonso, Juan Manuel Murillo and Antonio Brogi
The authors distinguish the new framework from the underlying shot-splitting method, which earlier work had already introduced. Their contribution here is an integrated execution-management system that connects user requirements, processor profiles, optimization and job execution.
QQSpec turns preferences into dispatch rules
Quantum Broker’s declarative Quantum QoS Specification Language, or QQSpec, lets a user describe constraints and objectives without tying them to a particular provider’s interface. A request can set limits or preferences for spending, runtime, waiting time, expected quality, backend use and shot allocation. The system then profiles available backends, selects a distribution and sends each processor its assigned portion.
The architecture divides that work among three components: a Profiler collects backend information, a Reasoner calculates a dispatch plan, and an Executor submits jobs and combines their results. The Reasoner offers two approaches. A mixed-integer linear-programming solver plans quickly using linearized service models; a nonlinear dual-annealing solver evaluates more complex profiles at greater computational cost.
In the paper’s tests, the nonlinear solver took about 16 to 24 seconds on average across three scenarios, compared with fractions of a second for the linear solver. The faster method sometimes failed to produce a dispatch meeting all requirements: its reported failure rates reached 28.57% in one scenario and 14.29% in another. The nonlinear solver had no solver failures in those tests, though it does not guarantee a globally optimal answer.
Simulator tests return a mean score of 0.907
The team evaluated seven algorithm families, with circuits of 6, 8 and 10 qubits, using five Qiskit-based noisy simulator backends modeled on IBM devices. Each job used 4,096 shots. For a separate end-to-end test, the authors selected six Deutsch-Jozsa and quantum Fourier transform workloads that had feasible nonlinear-solver plans in all three scenarios, producing 18 executions.
After the simulated backends ran their assigned shots, the Broker merged their measurement counts and compared the resulting distributions with ideal, noise-free references. The mean squared Bhattacharyya coefficient was 0.907, ranging from 0.756 to 0.998; values closer to one indicate closer agreement. In one 10-qubit Fourier-transform case, a backend assigned just 76 shots had a distribution-similarity score of about 0.073 on its own, while the combined 4,096-shot result scored about 0.919.
That contrast shows why the paper evaluates the result delivered to the application, not each backend’s partial sample in isolation. A small allocation may be too sparse to represent a broad output distribution on its own, even when it contributes useful data to the merged result.
Pooling counts can still introduce bias
The authors caution that independent shots do not mean different processors produce identical output distributions. If their noise characteristics differ, simply pooling their raw counts estimates a shot-weighted mixture of those distributions, which can be biased relative to the ideal circuit output. The paper says recovery of a shared target without bias requires the processors to sample from the same effective distribution, or to be corrected so they do.
The results also stop short of a live quantum-cloud demonstration. Noisy device-specific simulators supplied the measurement outcomes, while cost, queue delay and execution-time estimates came from fixed synthetic profiles rather than measurements on production processors. The paper identifies repeated runs on live QPUs, measured backend profiles, and better ways to account for device-dependent bias as remaining tests for the system.