Multi-QPU Federation and Workload Routing — Operating Quantum Computers

As platforms mature, users will not want “a quantum computer.” They will want access to the best available target for a workload under constraints of quality, cost, latency, access rights, and reproducibility.

That requires federation.

47.1 Federation model

Diagram loads as you read

47.1 Federation model · Figure 1

View diagram source

flowchart TB
    User[User or application] --> API[Unified platform API]
    API --> Policy[Policy and admission control]
    Policy --> Router[Workload router]
    Router --> QPU1[QPU provider A]
    Router --> QPU2[QPU provider B]
    Router --> Sim[Simulator or emulator]
    Router --> HPC[Classical HPC/GPU resources]
    QPU1 --> Evidence[Evidence store]
    QPU2 --> Evidence
    Sim --> Evidence
    HPC --> Evidence

Federation does not mean pretending all targets are equivalent. It means making differences explicit enough that the platform can route responsibly.

Qiskit Serverless is documented as a way to manage classical and quantum resources across Qiskit workflows, Amazon Braket reservations provide scheduled exclusive device access, and Azure Quantum jobs expose a cloud job lifecycle. These services point toward a world where orchestration, not raw device invocation, becomes the primary platform interface. [R76] [R77] [R78]

47.2 Routing inputs

A workload router needs more than provider name.

Input	Examples
algorithm shape	sampling, expectation estimation, chemistry, optimization
circuit properties	width, depth, native gates, dynamic requirements
data constraints	region, confidentiality, retention
quality constraints	required uncertainty, benchmark class
time constraints	deadline, reservation window, interactive loop
cost constraints	budget, shot cap, simulator fallback
reproducibility constraints	target pinning, calibration snapshot, runtime image

Diagram loads as you read

47.2 Routing inputs · Figure 2

View diagram source

flowchart LR
    Workload[Workload metadata] --> Router
    Health[Target health] --> Router
    Policy[Access and compliance policy] --> Router
    Cost[Cost model] --> Router
    Evidence[Historical evidence] --> Router
    Router --> Decision[Route, delay, split, simulate, or reject]

47.3 Target capability contract

Each target should expose a capability contract.

Illustrative listing · yaml

target_capability_contract:
  target_id: string
  provider: string
  modality: superconducting | trapped_ion | neutral_atom | photonic | annealing | simulator
  native_operations: [string]
  dynamic_features: [string]
  connectivity_model: string
  max_supported_workload:
    qubits: integer
    depth: integer
    shots: integer
  quality_evidence:
    benchmark_family: string
    timestamp: datetime
  data_policy:
    region: string
    retention: string
  cost_policy:
    pricing_unit: string

Diagram loads as you read

47.3 Target capability contract · Figure 3

View diagram source

flowchart TB
    Contract[Capability contract] --> Compile[Compilation feasibility]
    Contract --> Quality[Quality prediction]
    Contract --> Security[Policy check]
    Contract --> Cost[Cost estimate]
    Contract --> Repro[Reproducibility plan]

47.4 Routing decisions

Routing should be a structured decision, not a hidden heuristic.

Diagram loads as you read

47.4 Routing decisions · Figure 4

View diagram source

stateDiagram-v2
    [*] --> Received
    Received --> Classified
    Classified --> SimulateFirst: uncertain feasibility
    Classified --> QueueQPU: feasible and healthy
    Classified --> Reserve: needs exclusive window
    Classified --> Reject: violates constraints
    SimulateFirst --> QueueQPU: passes preflight
    QueueQPU --> Complete
    Reserve --> Complete
    Reject --> [*]
    Complete --> [*]

Possible decisions:

Decision	Meaning
simulate	run locally or on GPU/HPC to validate structure
queue	submit to ordinary device queue
reserve	schedule dedicated device access
split	route subproblems to different resources
delay	wait for health, calibration, or reservation window
reject	cannot satisfy constraints honestly

47.5 Federated reproducibility

Federation makes reproducibility harder. A result is not reproducible merely because the source code is the same.

Diagram loads as you read

47.5 Federated reproducibility · Figure 5

View diagram source

flowchart LR
    Code[Source code] --> Build[Runtime build]
    Build --> Compile[Compiled workload]
    Compile --> Target[Selected target]
    Target --> Cal[Calibration snapshot]
    Cal --> Execute[Execution]
    Execute --> Result[Result]
    Result --> Evidence[Evidence package]

The evidence package should identify the selected target, provider API version, target capability contract, calibration data available at submission, runtime image, compiler version, queue/reservation mode, job tags, and result decoder.

47.6 Reservation-aware scheduling

Reservations are not just procurement artifacts. They are scheduling primitives.

Diagram loads as you read

47.6 Reservation-aware scheduling · Figure 6

View diagram source

gantt
    title Reservation-aware workload plan
    dateFormat  YYYY-MM-DD HH:mm
    section Preflight
    simulate and compile :a1, 2026-05-01 09:00, 2h
    section Reservation
    exclusive QPU window :crit, b1, 2026-05-01 13:00, 1h
    section Postprocess
    aggregate and validate :c1, 2026-05-01 14:00, 3h

The preflight phase should complete before the reservation starts. Using reserved QPU time to debug syntax, packaging, or trivial compilation errors is operational waste.

47.7 Federation failure modes

Failure	Control
target drift hidden by abstraction	expose target-specific evidence
provider API change	pin versions and run contract tests
cost surprise	preflight budget envelope
data residency violation	policy engine before routing
false portability	capability contract and test suite
queue unpredictability	reservation mode or deadline-aware routing

Diagram loads as you read

47.7 Federation failure modes · Figure 7

View diagram source

flowchart TD
    Federation[Federated platform] --> Abstraction[Common API]
    Abstraction --> Risk[False equivalence]
    Risk --> Control[Capability contracts and evidence]
    Control --> Trust[Qualified portability]

47.8 Operating rule

A federated quantum platform should optimize for qualified routing, not universal abstraction. The router should say: “This target is appropriate for this workload under these constraints and this evidence.”