Quantum-as-a-Service (QaaS): Renting Quantum Computing in the Cloud
· 5 min read · ZKSF team
Almost nobody who runs quantum circuits owns a quantum computer. A dilution refrigerator, control electronics, and the team required to keep them calibrated cost millions of dollars and belong to a small number of laboratories. Everyone else accesses quantum computing the way they access other heavy compute: as a cloud service, on demand, paying only for what is used. That model is Quantum-as-a-Service, or QaaS.
The animation walks through a real dilution refrigerator's cooling stages, from 300 K down to about 10 mK, where a superconducting qubit chip sits at the coldest point. A Hadamard gate puts the first qubit into superposition, then a CNOT gate entangles it with the second qubit, producing the Bell state (|00⟩+|11⟩)/√2. As the two qubits entangle, each one's individual Bloch vector shrinks to the center of its sphere: on its own, each qubit is now a fully random coin flip, even though the pair together sits in a single, well-defined joint state.
QaaS covers two distinct offerings under a single login: classical simulators that emulate quantum circuits, and real quantum processors (QPUs) accessed remotely. Most day-to-day work uses the first; hardware is reserved for questions that genuinely require it.
What is actually being purchased
Simulator access is typically billed by compute time, per second or per hour of CPU or GPU, sometimes per job. Because a small circuit finishes in milliseconds, a simulation job often costs a fraction of a cent. Real QPU access is billed differently: a fixed fee per task plus a small fee per shot, where a shot is one repetition of the circuit.
Access type Typical billing unit Representative cost
CPU simulation per job / per second fractions of a cent
GPU simulation per second, per GPU-hour ~$3-4/GPU-hour
QPU (superconducting) per task + per shot ~$0.30 + $0.0004-0.001/shotThe major platforms in 2026, including IBM Quantum, Amazon Braket, Azure Quantum, and Google's simulation stack, each wrap a mix of simulators and hardware from one or more vendors. They differ less in their underlying open-source engines, which overlap substantially, and more in routing, pricing, and how much information they provide about the accuracy of a given result.
The decision that saves the most money
The single most valuable habit in QaaS is checking whether a circuit requires hardware at all.
- Circuits under roughly 32 qubits simulate exactly on inexpensive CPU hardware.
- Structured circuits at 50 to 128 qubits, including QAOA and ansatz workloads, often run on tensor-network engines in seconds.
- Clifford circuits run at effectively any scale.
- Real hardware earns its cost when validating behavior under genuine device noise, when circuit sizes exceed classical reach with entanglement no method compresses, or in error-correction experiments that require physical qubits by definition.
A well-designed QaaS platform makes this decision easy by estimating cost and feasibility before a job runs, and by attaching an error statement to approximate results so the degree of trust placed in them is explicit rather than assumed.
One SDK, several backends
The practical value of QaaS is that a single line of code can target a CPU simulator, a GPU simulator, or a real QPU, with the platform determining where and how the circuit executes. A circuit is written once in a standard framework, submitted, and returned with a record of how the result was produced. There is no capital expense, no idle hardware, and no lock-in to a single device, which for most research budgets remains the only sensible way to compute.
Run your own 100-qubit circuit, with an error bar.