Where should a quantum circuit run? A load-aware scheduler can estimate the best fit for each job before expensive compilation

Why one quantum circuit fits some processors better than others

A quantum circuit looks like a recipe written in an abstract language. It lists gates, qubits, and the order in which operations must happen. In a real quantum cloud, it becomes several objects because each processor has its own physical body. One machine may have more qubits, or place them so that only certain neighbors can talk directly. Its native instructions may include some rotations but not others. Its noise profile can make one error type common and keep another rare.

When a circuit is sent to a specific QPU, a compiler rewrites it into that machine’s native language. This step chooses which physical qubits carry the logical roles. It also inserts extra gates to move information where needed, and it adapts operations to local constraints. Those choices can change the expected fidelity of the final run. Quantum devices are noisy, and small mistakes can accumulate as the compiled sequence grows longer. The same circuit can therefore have very different expected fidelities, since each QPU compiles it differently.

A simple way to find the best machine would be to compile every circuit on every available QPU. For a batch of k circuits and D devices, that means k times D compilations even though only k programs are actually run. The cost is real because compilation can be slow, especially for large circuits. Its hardest parts involve placing qubits and routing information through a limited layout. The same input can therefore be a good fit for one QPU and a poor fit for another before any execution begins. That makes device choice a practical problem, since compiling for every device would waste time and cloud capacity.

How a graph model reads a circuit before compilation

Before any compilation begins, the circuit is turned into a graph that a machine-learning system can inspect. Each gate becomes a node, and arrows between nodes record which operations must happen before others. This layout preserves the order of computation without asking a compiler to solve it again on every device. After that, each operation node receives a numerical description built from forty carefully chosen values. Twenty-eight of those numbers identify the gate type, so the model can tell a rotation apart from a measurement. Six more encode rotation angles using sine and cosine, which keeps repeating angle values smooth rather than abrupt. The final six record structural facts, such as how many qubits the gate uses and whether it lies on a long dependency path. They also note how many operations precede that gate and how many follow, giving the model a sense of position. The graph encoder then lets each node gather information from its immediate neighbors in this dependency network. In each layer, a gate combines information from the operations directly before and after it in the circuit. Deeper layers widen that view, so later features can reflect longer chains of dependencies rather than only local gate types. The encoder uses two groups of such layers, and the second group carries earlier information forward through residual connections. That design helps complex circuits keep useful signal while passing through many successive transformations inside the network. After each aggregation step, normalization rescales the values so that later layers can train more stably. A nonlinear activation then lets the model represent patterns beyond simple averages of neighboring gates. Dropout randomly suppresses some learned features during training, which reduces overfitting to a particular set of examples. The model may also process the circuit graph in both directions during a single pass through the encoder. One direction follows the natural order from inputs toward outputs, while the reversed direction lets each operation learn about what happens after it. This optional mode is treated as a design choice, not a fixed requirement of the method. At the end, all node descriptions are combined by averaging them, taking their element-wise maximum, and summing them. The average captures typical structure, the maximum preserves unusually strong features, and the sum keeps information about overall circuit size. These three summaries are concatenated, giving a compact numerical portrait of the whole circuit before any device-specific compilation starts.

A dial that trades fidelity against balanced use of machines

The scheduler keeps one knob, called the fidelity weight, and it changes what the system values most when a batch of circuits is waiting. At zero, the knob ignores predicted quality and spreads work evenly across available processors, much like round-robin scheduling. At one, it sends each circuit to the processor that looks best for that circuit, even if one machine receives far more jobs than another. Between those ends, the scheduler accepts a small loss in expected success probability so that several machines can run at once and the whole batch finishes sooner.

For every pending circuit, the scheduler scores each device with two terms. The first term is the fidelity weight multiplied by the predicted fidelity for that device. The second term subtracts one minus the fidelity weight times the device’s current load share. Load share means the fraction of circuits already assigned to that machine in the current dispatch round. A device that has received many jobs becomes less attractive, while a quiet device gains an advantage. Because the score uses raw predicted fidelities rather than normalized ranks, a tiny quality edge does not easily overcome a heavy load penalty. A large quality edge can dominate it.

The weight therefore acts like an exchange rate between quality and balance. It sets how much extra workload a processor may absorb for each unit of predicted fidelity advantage. When the weight is low, the system favors spreading jobs; when it rises toward one, strongly preferred circuits are moved to their best devices early, while less-preferred circuits stay on busier machines longer. Assignment happens one circuit at a time, and after each choice the chosen device’s load counter increases immediately. Later circuits see that updated penalty, so a run of compatible circuits cannot pile onto one processor by accident.

What happened when 5,117 circuits met three processor profiles

When the batch of 5,117 circuits was tested against three processor profiles, EQE1 Top, EQE1 Bottom, and QExa20, the results showed a clear trade between quality and even use. The test set had a strong preference pattern: 55.6% of circuits ran best on EQE1 Bottom, 35.1% on QExa20, and only 9.3% on EQE1 Top. A strategy that always chose the highest true fidelity would therefore send most work to one machine. In a real system with limited execution capacity, that imbalance could create queues while other processors sat idle.

Round robin ignored fidelity and spread the work evenly, but its mean ground-truth fidelity was only 0.3436. The ideal quality choice, which knew each circuit’s true best device and ignored load, reached 0.3759. That gap of 0.032 on a scale from zero to one is the amount of quality that any scheduler can trade against balance.

The prediction based scheduler moved smoothly between those extremes as its fidelity weight rose. At a moderate weight of 0.5, it reached a mean ground-truth fidelity of 0.3675, which is a 7.0% improvement over round robin. The load stayed well spread, with a coefficient of variation across devices of only 0.069. At weight 0.7, the quality rose to 0.3703, a 7.8% gain, while imbalance remained modest at 0.149.

The last step toward pure quality selection brought little extra benefit. Raising the weight to its maximum increased fidelity from 0.3703 to 0.3737, about 0.9 percentage points more, but load imbalance jumped sharply to a coefficient of variation of 0.884. Most circuits then concentrated on EQE1 Bottom. The practical sweet spot was therefore well before the scheduler became quality only.

The prediction based policy also stayed close to the best possible version that used exact fidelities. Across the whole sweep, it remained within 0.0034 of that upper bound. At full fidelity weight, the two policies chose the same device for about 80% of circuits. The remaining disagreements tended to occur when the quality difference between devices was small, so choosing the wrong one cost little. The median per-circuit fidelity loss from prediction error stayed at zero throughout the sweep.

Choosing the right quantum machine before compilation starts

What emerges is a scheduling layer that moves the hardest decision earlier, from after compilation to before it. Instead of compiling every circuit on every processor, the system reads the uncompiled circuit as a graph and estimates how faithfully each device would run it. The gain includes both accuracy and time, because compilation can be slow when circuits grow. A single dial then decides how much of that predicted advantage should be spent on keeping all devices busy. When the dial is low, work spreads evenly; when it rises, circuits move toward the machines where they are expected to run best. On a batch of 5,117 circuits and three different processors, that balance paid off. The scheduler that used predicted fidelities reached a mean ground-truth fidelity of 0.3737 at the most accuracy seeking setting, while the ideal known fidelity upper bound was 0.3759. It stayed within 0.0034 of that upper bound at every tested weight. Round robin assignment managed only 0.3436, so the improvement is not a small rounding effect. The predictor itself was close enough to be useful, with an average miss of about one percentage point and a root mean square error near two. Its hardest cases were circuits whose true fidelity fell between roughly ten and forty percent, yet even there the grouped error stayed below four percentage points. The broader lesson is that quantum clouds may need to treat device choice as a live resource decision rather than a single match. The opportunity is a scheduling layer that learns from circuit structure, respects current load, and can trade fidelity against balanced use of machines. The obstacle is that predictions must stay reliable as devices change, circuits grow, and calibration data drifts. Another obstacle is fairness: if most circuits prefer one backend, a purely fidelity driven policy can starve the others. The next step is to test this kind of scheduling across larger fleets, noisier devices, and workloads that arrive in real time. If the prediction stays close enough to truth, the quiet win will be fewer wasted compilations and more useful quantum minutes. Will the next generation of quantum clouds choose machines by instinct, or by a learned sense of where each circuit belongs?