Quantum-as-a-Service (QaaS): Renting Quantum Computing in the Cloud

Almost nobody who runs quantum circuits owns a quantum computer. A dilution refrigerator, its control electronics, and the team required to keep the system 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, abbreviated QaaS and occasionally QCaaS.

This article sets out what QaaS actually consists of, how the two distinct products sold under the name are priced, how the major platforms differ, and which decisions determine whether a research budget is spent well or wasted. The figures are list prices and measured runs rather than estimates.

What is Quantum-as-a-Service (QaaS)?

Quantum-as-a-Service is renting access to quantum hardware or simulators over the internet, billed by usage, instead of buying a machine. You submit a circuit through an API or a web console, it runs on somebody else's processor, and results come back. Nobody in your organisation touches a dilution refrigerator.

It is the same structural idea as infrastructure-as-a-service in classical computing, and it exists for the same reason: the hardware costs millions, needs specialist operators, and would otherwise sit idle.

What is QaaS technology?

The underlying technology is unremarkable, and that is the point. A QaaS platform is a job queue, a scheduler, an API and a billing system sitting in front of quantum processors and classical simulators. The quantum part is the backend. Everything a user touches is ordinary cloud software.

The acronyms are marketing distinctions rather than technical ones, and they all describe the same act of submitting a circuit and getting a result:

• QaaS, Quantum-as-a-Service. The general term.
• QCaaS, Quantum Computing as a Service. The same thing, spelled out.
• QPU as a Service, emphasising access to real hardware rather than simulation.
• QFaaS, Quantum Function as a Service. A serverless framing: circuit in, result out.

What is QPU as a service?

QPU as a service is the subset that guarantees your circuit runs on real quantum hardware rather than on a simulator. The distinction matters because most platforms marketed as quantum computing services spend the majority of their compute on classical simulation. That is usually the right answer for the user, and it is not what the name implies.

If a vendor does not tell you which of the two you are buying on any given run, that is the first question to ask.

What are cloud based quantum services used for?

Almost entirely for research, algorithm development and evaluation. There is no production workload in 2026 where a quantum computer beats a classical one on a commercially valuable problem, and any vendor implying otherwise is selling something.

What these services are genuinely good for is establishing what a quantum approach would require for your problem, at a cost measured in cents rather than millions. We publish that comparison across six industries with the classical baseline shown alongside, in Applications.

The two products sold under one name

QaaS covers two things that are frequently conflated because they sit behind a single login and a single SDK.

The first is classical simulation. A classical computer computes what a quantum computer would output, exactly or to a stated accuracy. This is not an inferior substitute for hardware; within its range it returns the noise-free answer that hardware cannot produce, and it is where the overwhelming majority of published quantum computing work is actually performed.

The second is quantum processing unit access, meaning a real device: superconducting transmons, trapped ions, neutral atoms or photonic hardware, reached over an API with a scheduler in front of it. The device is shared, the queue is real, and the result carries the device's noise.

The distinction matters commercially because the two are priced on entirely different bases, and a platform that presents them as interchangeable tiers of the same product obscures a cost difference of two to three orders of magnitude.

How each is billed

Simulation is billed by consumption of classical resources: per job, per second, or per GPU-hour. Because a small circuit completes in milliseconds, a simulation job commonly costs a fraction of a cent. Hardware is billed per task plus per shot, where a shot is one execution of the circuit, and statistical significance requires many shots.

Access type              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.000425/shot
QPU, trapped ion         per task + per shot       $0.30 + $0.08/shot

The per-shot column is where budgets are decided. A 1,000-shot experiment costs $0.725 on a superconducting device and $80.30 on a trapped-ion device, a ratio of 111 to 1 for the same circuit and the same statistics. The same experiment on a classical simulator costs a tenth of a cent. Neither figure is a markup; they are the providers' published list prices, and the spread reflects gate speed rather than commercial positioning.

What the platforms actually differ on

The major platforms in 2026, IBM Quantum, Amazon Braket, Azure Quantum, Google's stack, and a set of specialist providers, are less differentiated than their marketing implies. They wrap substantially the same open-source simulation engines: Qiskit Aer, Stim, quimb, cuQuantum, ITensor. A statevector simulation of a 25-qubit circuit returns the same amplitudes everywhere, because it is the same arithmetic.

The real differences sit in four places.

• Routing. Whether the platform selects an appropriate simulation method from the circuit's structure, or requires the user to know in advance that their circuit is Clifford, or low-entanglement, or shallow. Poor routing is expensive: it sends a 1,000-qubit stabilizer circuit to a method that cannot hold it, or a 30-qubit circuit to hardware that does not need to see it.
• Accuracy reporting. Whether an approximate result arrives with a bound on its error. Tensor-network and Pauli-propagation engines are approximate by construction, and an approximate number without a bound is an assertion rather than a measurement. Most platforms return the number alone.
• Hardware markup. Whether QPU time is passed through at the provider's list price or resold at a margin. This is checkable: compare the platform's per-shot figure against the device vendor's published rate.
• Pre-run feasibility. Whether the platform states cost and feasibility before charging, or accepts the job, runs it, and reports the failure afterwards.

The decision that determines the budget

The single most valuable habit in QaaS is establishing whether a circuit requires hardware at all. The answer is usually no, and the reasoning is structural rather than a matter of scale.

• Circuits under roughly 32 qubits simulate exactly on inexpensive CPU hardware. The state fits in memory and the answer is the mathematically exact one, free of device noise.
• Clifford circuits run at effectively any width. The Gottesman-Knill theorem guarantees polynomial-time classical simulation for the Clifford gate set, so a 5,000-qubit stabilizer circuit is tractable while a 60-qubit generic circuit is not. Width is the wrong variable; gate content is the right one. This is developed in Clifford circuits and Stim.
• Structured circuits at 50 to 128 qubits, which describes most QAOA instances, hardware-efficient ansatze and Trotterised dynamics, run on tensor-network engines in seconds, because they generate far less entanglement than their width permits.
• Hardware earns its cost in three cases: measuring how an algorithm degrades under genuine device noise, error-correction experiments that require physical qubits by definition, and circuits whose entanglement structure defeats every classical method, a condition that should be verified rather than assumed.

The cost most vendor pages omit

Every price above is the cost of one circuit execution. The workloads people want to run are not one circuit. Variational algorithms, which is to say most of what is currently interesting, wrap an optimizer around a circuit and evaluate it repeatedly.

The multiplier follows from the optimizer. SPSA costs two circuit evaluations per iteration regardless of parameter count, so a 150-iteration run is 301 submissions. The parameter-shift rule costs two evaluations per parameter per iteration, so the same run on a 32-parameter ansatz is 9,601 submissions. Priced on superconducting hardware at 2,048 shots, that is $352.29 against $11,237.01 for a decision most practitioners make on convergence grounds without considering the invoice. The full arithmetic is in What does it cost to rent a quantum computer?.

Wall-clock time compounds it. Each evaluation queues separately, and published queue times on shared devices range from minutes to hours. At a one-minute median, a 301-evaluation run occupies roughly five hours before any result exists.

What a QaaS platform should be asked to provide

Four requirements distinguish a service that supports research from one that merely sells compute.

• A stated error bound on every approximate result, derived from the method rather than estimated. For a matrix-product-state simulation the bound follows from discarded weight as sqrt(2 x epsilon); for Pauli propagation it follows from discarded coefficient mass. Both are computable, and a platform that computes them is making a falsifiable claim.
• Refusal rather than a meaningless answer. When an approximation has discarded enough of the state that the bound admits any outcome, returning the number without comment is the more dangerous behaviour.
• A reproducible record. The engine, shot count, parameters and bound for each run, retrievable afterwards and inspectable by a third party. Results that cannot be independently checked are not evidence.
• Cost transparency before execution, including hardware pass-through at list price.

One SDK, several backends

The practical value of the model is that a single line of code targets a CPU simulator, a GPU simulator or a physical device, with the platform determining where the circuit runs and reporting how the result was produced. The circuit is written once in a standard framework, submitted, and returned with a record of its provenance. There is no capital expense, no idle hardware and no commitment to one device technology at a point when it is genuinely unclear which will prevail.

That last point is the strategic argument for QaaS over procurement, and it is stronger than the cost argument. Superconducting, trapped-ion, neutral-atom and photonic approaches each have a plausible path and materially different characteristics, examined in Transmon or trapped ion?. Committing capital to one of them in 2026 is a bet on an unsettled question. Renting all of them is not.