Quantum Job Scheduling and Admission Control

Quantum scheduling is not ordinary queue management. The resource changes while jobs wait. Calibration windows expire. Some jobs are sensitive to a subset of qubits. Hybrid workloads need repeated access. Maintenance jobs compete with user jobs. A fair queue can still produce bad science.

The scheduler’s job is to maximize quality-adjusted throughput under physical drift.

9.1 The scheduler’s objective

A classical batch scheduler often optimizes utilization, fairness, priority, or deadline satisfaction. A quantum scheduler must add result quality.

A practical objective function looks like:

maximize: useful_results_per_hour
subject to: calibration validity, backend health, user priority, budget, fairness, and maintenance needs

“Useful” means the result has enough statistical and physical validity for the user’s purpose.

flowchart TB
    Jobs[Submitted jobs] --> Admission[Admission control]
    Admission --> Score[Quality and cost scoring]
    Score --> Queue[Queue policy]
    Queue --> Backend[Backend assignment]
    Backend --> Execute[Execution]
    Execute --> Report[Result with metadata]
    Execute --> Telemetry[Operational telemetry]
    Telemetry --> Score
    Telemetry --> Admission

The feedback edge is essential. Scheduling policy should learn from failures and drift.

9.2 Admission control before queueing

Admission control protects the machine and the user. A job should not enter the expensive part of the queue until the platform has checked whether it is plausible.

Admission checks include:

flowchart TD
    Submit[Submit workload] --> Parse[Parse and normalize]
    Parse --> Feasible{Hardware-feasible?}
    Feasible -- no --> Reject[Reject with explanation]
    Feasible -- yes --> Estimate[Estimate quality and cost]
    Estimate --> Useful{Likely useful?}
    Useful -- no --> Warn[Warn or request rewrite]
    Useful -- yes --> Queue[Accept into queue]
    Warn --> Queue

Admission should provide actionable diagnostics: too deep, too many two-qubit gates, unsupported mid-circuit measurement, insufficient shots, or stale calibration.

9.3 Job classes

Different workloads deserve different scheduling modes.

IBM Quantum documents execution modes including job, session, and batch, where sessions support iterative work and batch mode is intended for workloads supplied together [R19, R20, R21]. Amazon Braket similarly documents hybrid jobs and reservations as distinct operational modes [R22, R23, R24].

9.4 Queueing under calibration expiry

A quantum job may be valid when admitted but invalid by the time it reaches the front of the queue. The scheduler must track calibration expiry.

sequenceDiagram
    participant U as User
    participant A as Admission
    participant S as Scheduler
    participant C as Calibration DB
    participant Q as QPU

    U->>A: submit job
    A->>C: check snapshot validity
    C-->>A: valid until 15:00
    A->>S: accept job with snapshot requirement
    S->>S: job waits
    S->>C: recheck before dispatch
    C-->>S: snapshot expired
    S->>S: recompile, defer, or recalibrate
    S->>Q: dispatch only after valid decision

A result report should state whether the job was executed under the same calibration assumptions used during compilation.

9.5 Backend scoring

Backend selection should be workload-specific. The “best” backend for one circuit may be a poor fit for another.

A scheduler can score candidate backends using:

• required qubit count,
• topology and routing overhead,
• native gate match,
• current regional health,
• calibration age,
• estimated queue time,
• dynamic-circuit support,
• expected shot throughput,
• user priority and data locality,
• cost.

flowchart LR
    Workload[Workload features] --> ScoreA[Backend A score]
    Workload --> ScoreB[Backend B score]
    Workload --> ScoreC[Backend C score]
    Cal[Calibration state] --> ScoreA
    Cal --> ScoreB
    Cal --> ScoreC
    Queue[Queue state] --> ScoreA
    Queue --> ScoreB
    Queue --> ScoreC
    ScoreA --> Choose[Choose backend or defer]
    ScoreB --> Choose
    ScoreC --> Choose

The scheduler should expose enough of the scoring explanation that users can improve their workload.

9.6 Scheduling hybrid algorithms

Hybrid algorithms are vulnerable to interruption. A VQE or QAOA loop may run many short quantum jobs, each depending on the previous result. If every iteration waits behind unrelated work, optimizer behavior and wall-clock cost degrade.

flowchart LR
    Params[Initial parameters] --> Circuit[Generate circuits]
    Circuit --> QPU[Run on QPU]
    QPU --> Estimate[Estimate objective]
    Estimate --> Optimizer[Classical optimizer]
    Optimizer --> Params

A scheduling policy for hybrid workloads should provide:

• bounded inter-iteration delay,
• stable backend assignment when useful,
• session-level priority without starving others,
• cancellation if the objective is clearly failing,
• checkpointing for optimizer state,
• reproducible metadata for each iteration.

Hybrid scheduling is one reason near-time classical compute matters. The classical optimizer should be near the quantum service, not necessarily near the end user.

9.7 Batching and packing

Batching reduces overhead when many circuits share context. But batching can also hide heterogeneity: a batch may contain some circuits that fit the backend well and others that should be rewritten.

flowchart TD
    Batch[Submitted batch] --> Normalize[Normalize circuits]
    Normalize --> Cluster[Cluster by requirements]
    Cluster --> GroupA[Group A: shallow / same layout]
    Cluster --> GroupB[Group B: dynamic circuits]
    Cluster --> GroupC[Group C: high-depth risky]
    GroupA --> RunA[Run together]
    GroupB --> RunB[Route to capable backend]
    GroupC --> Review[Warn or redesign]

Good batching groups compatible workloads. Bad batching merely puts unrelated circuits in the same envelope.

9.8 Fairness and priority

Quantum hardware scarcity creates scheduling politics. A platform needs explicit policy.

Policy dimensions include:

flowchart TB
    Policy[Scheduling policy] --> Fairness[Fairness]
    Policy --> Priority[Priority]
    Policy --> Maintenance[Maintenance]
    Policy --> Reservations[Reservations]
    Policy --> Recovery[Incident recovery]
    Fairness --> Decision[Dispatch decision]
    Priority --> Decision
    Maintenance --> Decision
    Reservations --> Decision
    Recovery --> Decision

Policy should be documented. Hidden scheduling rules destroy user trust.

9.9 Preemption

Preemption is common in classical compute. In quantum execution, preemption has different meanings.

An arbitrary unknown quantum state cannot be saved as a reusable classical checkpoint. Preemption may be possible before dispatch or between independent circuits, shot batches, or hybrid iterations when the runtime exposes those boundaries. A cloud cancellation request may be asynchronous or too late to stop execution; it is not a general pause-and-resume mechanism.

stateDiagram-v2
    [*] --> Queued
    Queued --> Dispatched
    Dispatched --> RunningCircuit
    RunningCircuit --> BetweenShots
    BetweenShots --> RunningCircuit
    RunningCircuit --> Complete
    Queued --> Deferred: preempt before dispatch
    BetweenShots --> Paused: policy preemption
    Paused --> Queued
    RunningCircuit --> Aborted: safety abort
    Complete --> [*]

This diagram is a proposed scheduler with explicit batch boundaries, not a promise about every provider API. Document cancellation, restart, retained results, billing, and any statistical stopping rule.

9.10 Cost accounting

Quantum cost is not only QPU seconds. It includes:

• compilation time,
• simulator preflight time,
• queue delay,
• calibration consumed for workload support,
• shots executed,
• failed or discarded shots,
• mitigation overhead,
• classical optimizer compute,
• human review for incidents.

A result report should make the cost model visible enough for users to optimize.

9.11 Scheduler observability

Scheduler dashboards should answer operational questions:

• Which jobs are blocked by calibration?
• Which jobs are likely to expire before dispatch?
• Which backend is underutilized because of quality degradation?
• Which users or projects are consuming scarce high-quality regions?
• Which workloads are repeatedly rejected or rewritten?
• Which scheduling decisions led to poor result quality?

flowchart TB
    Dash[Scheduler dashboard] --> QueueAge[Queue age]
    Dash --> Expiry[Calibration expiry risk]
    Dash --> Util[Quality-adjusted utilization]
    Dash --> Rejects[Admission rejects]
    Dash --> Incidents[Incident-linked jobs]
    Dash --> Fairness[Fairness and quota]

Quality-adjusted utilization is more useful than raw utilization. A busy degraded backend is not a healthy backend.

9.12 Operator checklist

• Perform admission control before expensive queueing.
• Classify workloads by scheduling mode.
• Recheck calibration validity immediately before dispatch.
• Score backends per workload, not globally.
• Give hybrid workloads bounded inter-iteration delay when policy allows.
• Batch compatible circuits, not arbitrary circuits.
• Define fairness, reservation, maintenance, and incident-recovery policies explicitly.
• Preempt only at safe boundaries except for safety aborts.
• Track quality-adjusted utilization and calibration expiry risk.

9.13 Chapter summary

The scheduler is a scientific instrument in software form. It decides which computations are physically worth running, when they should run, where they should run, and under which calibration assumptions. A quantum platform that schedules only for utilization will eventually optimize itself into producing fast, cheap, low-confidence answers.

Additional technical sources: [R251], [R255].