Marin Ivezic
A quantum computer arrives as hardware you can order. The cryostat is a purchase, the quantum processing unit (QPU) is a purchase, and the control rack is a purchase. The software that turns those three into a machine a user can submit a job to is not a purchase, and for most Western builds it is an assembly job. There are five software layers between a rack of components and a working multi-user system. Two of them follow automatically from decisions already made, and three demand deliberate engineering. This post covers the three.
We teach this material because it is the part of a build our learners most often inherit rather than plan. Hardware budgets get scrutinised line by line. The software layer gets a placeholder.
The five layers
| Layer | Function | Procurement status | Representative options |
|---|---|---|---|
| 1. Pulse and firmware | Direct waveform programming, conditional flow | Follows the control-system choice | QUA, Q1ASM, LabOne Q, Pulser |
| 2. Calibration | Automated tuning, drift correction | Active decision | Boulder Opal Scale-Up, QuantrolOx Quantum EDGE, QUAlibrate |
| 3. Framework | Circuit and algorithm development | Follows the framework choice | Qiskit, Cirq, CUDA-Q, PennyLane |
| 4. Middleware and orchestration | Scheduling, queues, quotas, authentication | Active decision, no turnkey product | Kubernetes and Slurm assembly, QUB reference architecture, QRMI |
| 5. Operating system | Unified cross-hardware orchestration | Active decision, no Western turnkey product | Roll your own, reference architecture, or integrator-delivered |
Pick a control system and layer 1 is largely settled. Pick Qiskit or CUDA-Q and layer 3 is settled. Layers 2, 4 and 5 are where the engineering work sits, and two of those three have nothing you can buy off a shelf.
What the orchestration layer actually does
Strip the operating-system label away and the job description is concrete. The orchestration layer decides which physical qubits a job runs on. It schedules jobs and manages a queue when more than one user wants the machine. It enforces per-tenant quotas and authentication, and it coordinates the hybrid lifecycle where a quantum circuit and a classical computation hand work back and forth.
It does all of that while the hardware underneath drifts on hourly timescales. That is the difference between this and a classical job scheduler, which never has to recheck whether last week’s allocation is still valid.
Take an illustrative case. A user submits a 50-circuit job at 9 AM, and the machine was calibrated at 7 AM. At calibration time, qubits 3 and 7 were the highest-fidelity pair on the device. By 10 AM, frequency drift has degraded qubit 7’s T1 (the energy relaxation time, roughly how long a qubit holds its excited state), and a two-level-system defect in the substrate has shifted qubit 3 off its calibrated frequency. Does the scheduler check calibration timestamps before assigning qubits to the remaining circuits? Does it reject the job and trigger a recalibration? Does it silently route the rest of the batch to a different pair and record that it did so?
Those are design decisions, and someone on the build team has to answer them. They have no classical analogue. Slurm, the workload scheduler most HPC sites run, allocates GPU partitions without ever asking whether a GPU has drifted since Tuesday. A quantum scheduler allocates resources whose error rates change between calibrations, and whose jobs cannot be paused and resumed, because a half-finished quantum state decoheres the moment the schedule slips.
Calibration, the layer nobody can defer
Calibration is the one software layer that cannot be improvised, because without it the machine stops working. A two-qubit gate calibrated to 99.5 percent fidelity in the morning can fall well below that by midday if a defect shifts a qubit frequency or thermal cycling moves the flux bias point.
Calibration software is what keeps that from becoming a daily manual intervention. A machine with autonomous calibration retunes on its own schedule and reports drift upward; a machine without it needs a specialist watching the fidelity numbers and deciding when to stop taking jobs. The cost of skipping this layer is not paid once at commissioning, it is paid in staff time every week the machine is in service.
Three platforms dominate the choice. Q-CTRL’s Boulder Opal Scale-Up is AI-driven autonomous calibration, integrated across several control vendors. QuantrolOx Quantum EDGE competes directly and is installed at the UK’s National Quantum Computing Centre. Quantum Machines’ QUAlibrate ships with OPX control hardware and is tied to the QUA language.
One of the three comes with a control rack, and two are independent purchases that work across vendors. Teams that default to whatever shipped with the electronics have made the decision without evaluating it.
Layer 5, the operating system that does not exist yet
A true quantum operating system would orchestrate qubit allocation, error correction, scheduling, calibration and security across heterogeneous hardware, and it would be portable rather than locked to one vendor’s machine. By that standard, the West doesn’t have one. IBM’s Qiskit Runtime handles scheduling and error mitigation for IBM hardware. Riverlane’s Deltaflow handles real-time error correction, but a decoder is not a system orchestrator. Google, Microsoft and Amazon each run capable internal stacks, and none of them are downloadable or portable.
The one publicly downloadable quantum operating system comes from Origin Quantum in Hefei. Origin Pilot supports superconducting, trapped-ion and neutral-atom hardware behind a single driver layer, with unified resource scheduling, multi-user quotas, automatic calibration and hybrid orchestration. Origin Quantum sits on the U.S. Entity List, so for Western and allied buyers this is a benchmark to study rather than software to install. The unified driver model means the orchestration stack above it does not change when the qubit modality below it does. No Western stack matches that portability yet.
Three ways to get an orchestration layer
Build it. Most Western integrators assemble layer 4 from Kubernetes and Slurm plus custom REST and gRPC services. In practice that means a scheduler plugin that understands QPU availability and calibration state, a metadata store tracking when each qubit was last calibrated and at what fidelity, an authentication and tenant-isolation layer, monitoring that surfaces both infrastructure health and qubit performance, and a lifecycle manager for the classical-quantum-classical handoff. Budget three to six months for a small team, plus maintenance indefinitely. National laboratories with strong software groups often choose this, because it produces a stack they fully control.
Start from a reference architecture. The Quantum Utility Block, a joint reference design from QuantWare, Q-CTRL and Qblox, includes an orchestration layer and gives you a validated blueprint instead of a blank sheet. The emerging Quantum Resource Management Interface (QRMI) standard exposes a QPU as a Slurm-native schedulable resource, which removes a chunk of the custom integration work. You trade some flexibility for speed and lower risk.
Contract it. Several systems integrators will deliver and support the orchestration layer (layer 4) as a component. For an organisation whose mission is running quantum workloads rather than maintaining quantum middleware, this is the same calculation that leads most teams not to write their own database engine.
There is no default answer. The choice turns on in-house engineering depth, on whether the deployment is a sovereign program or a commercial installation, and on how much control over the stack you are willing to trade for deployment speed. Discovering the question in month six of a build is expensive.
Where orchestration meets HPC
The orchestration layer decides how jobs are scheduled and how the machine is shared. HPC integration is the physical and architectural coupling to classical supercomputing: the interconnect, the fabric, the memory path. QRMI sits on the seam between them. At CINECA in Bologna, a Pasqal neutral-atom QPU appears in the Slurm queue alongside classical GPU partitions, and researchers submit hybrid jobs through the interface they already use. Plan the two as coordinated decisions rather than one.
What this asks of engineers
The skills this layer demands sit awkwardly between two disciplines. Classical distributed-systems engineers know Kubernetes, Slurm and gRPC, and they generally do not know why a scheduler should care about a calibration timestamp. Quantum physicists know why the timestamp matters, and they have rarely built a multi-tenant authentication layer. Systems integration work requires both skill sets at once, and the overlap between the two groups is thin.
Our quantum systems integration program is built for that overlap. It covers the full stack decision path: control-system selection, calibration platform evaluation, the build-or-buy call on orchestration, and the HPC coupling that follows. Learners work through the same procurement decisions described here against realistic multi-vendor configurations. You can review the curriculum and current cohort dates at quantumacademy.com/.
For the engineering detail behind this summary, including qubit-mapping complexity, compilation pipelines and decoder internals, the full build guide on PostQuantum.com goes considerably further than a curriculum overview needs to.