Quantum Computing as a Service (QCaaS)

• Quantum Computing as a Service (QCaaS) is the remote delivery of quantum computing resources—including hardware, simulators, and algorithms—via standardized APIs.
• It integrates automated hybrid orchestration with classical pre- and post-processing, enabling efficient quantum circuit submission and per-shot billing.
• QCaaS platforms range from educational prototypes to high-performance systems, addressing challenges in latency, scheduling, and error management through advanced microservice architectures.

Searching arXiv for recent and foundational QCaaS papers to ground the article. Quantum Computing as a Service (QCaaS) is the delivery of quantum-computing resources—hardware, simulators, software libraries, and algorithms—over a network on a utility basis, so that users invoke quantum tasks via standardized service interfaces rather than buying or operating a quantum computer on premises. In the recent literature, QCaaS is also described as a service-oriented middleware that exposes quantum-native computations through well-defined service interfaces, allowing classical software developers to discover, invoke, and compose quantum tasks, and as a quantum-classical cloud in which QPUs and CPUs operate in tandem via a shared cloud infrastructure (Ahmad et al., 2023, Sabzevari et al., 2024, Karalekas et al., 2020).

1. Definition and service model

In QCaaS, the fundamental workload is the quantum circuit or job rather than a virtual machine or container, and the service boundary is typically expressed through API or SDK calls that submit circuits, parameters, and shot counts. A central economic and operational concept is the “shot,” one complete execution of a quantum circuit on a QPU returning measured classical bits; vendors typically charge per-shot or per-circuit execution, enabling fine-grained accounting for resource use (Ahmad et al., 2023). The model is motivated by the cost and scarcity of QPUs, the difficulty of maintaining cryogenic or otherwise highly isolated hardware, and the need to lower the barrier for users who do not possess intimate knowledge of quantum hardware or low-level circuit engineering (Sabzevari et al., 2024, Golec et al., 2024).

The service model is commonly stratified into quantum simulators, Noisy Intermediate-Scale Quantum devices, and future fault-tolerant hardware. The literature also treats hybrid classical–quantum execution as a defining feature rather than an optional extension: classical pre-processing, compilation, scheduling, and post-processing remain indispensable, while computationally intensive kernels are dispatched to quantum backends. This suggests that QCaaS is not merely remote access to a QPU, but a composite service stack in which compilation, orchestration, and hybrid workflow management are part of the product surface (Golec et al., 2024, Sabzevari et al., 2024, Karalekas et al., 2020).

2. Historical emergence and representative platforms

Public QCaaS emerged through cloud interfaces that exposed small-scale hardware to remote users. IBM Quantum Experience made a five-qubit superconducting processor accessible through a circuit-editor GUI or Python/REST API, permitted up to 8,192 shots per submitted job, and published daily calibration tables including $T_1$, $T_2$, and gate errors. Simulations returned results in seconds, while real-device jobs typically waited in a queue for minutes to hours, depending on load (Devitt, 2016). NMRCloudQ extended the public cloud model to a liquid-state NMR quantum processor, providing a web portal and RESTful API, server-side compilation to GRAPE pulse sequences, simulation of ideal and decohered density matrices, and randomized-benchmarking characterizations with $\epsilon_1 \simeq 1.26\%$ for single-qubit gates and $\epsilon_2 \simeq 1.77\%$ for two-qubit controlled-NOT gates (Xin et al., 2017).

A later generation of QCaaS platforms moved beyond public-access prototypes toward high-performance cloud offerings. Tianyan’s cloud-accessible superconducting prototype, Tianyan-287, features 105 qubits, with single-qubit gate fidelity $99.90\%$, two-qubit gate fidelity $99.56\%$, and readout fidelity $98.7\%$. For a 74-qubit random circuit sampling benchmark over 24 cycles, the platform completed one million samples in 18.4 minutes; the corresponding classical estimate reported for a Frontier-like setting was approximately 16,000 years (Group, 11 Dec 2025). This range suggests that QCaaS now spans educational access, pulse-level experimentation, variational-hybrid optimization, and cloud services designed around benchmarked quantum advantage claims.

Platform	Service access model	Published characteristics
IBM Quantum Experience (Devitt, 2016)	Browser or Python/REST API; simulator or queued hardware	Five qubits; up to 8,192 shots; daily calibration tables
NMRCloudQ (Xin et al., 2017)	Web portal and RESTful API	4 usable qubits; $\epsilon_1 \simeq 1.26\%$; $\epsilon_2 \simeq 1.77\%$
Tianyan (Group, 11 Dec 2025)	RESTful-style API and Cqlib SDK	105 qubits; 74-qubit, 24-cycle RCS; $10^6$ samples in 18.4 minutes

3. Reference architectures and hybrid workflows

QCaaS architectures are commonly organized around explicit separations between user interaction, orchestration, and backend execution. In QCSHQD, the framework consists of three principal components: a Local Integrated Development Environment, an Abstraction / Orchestration Layer, and a Service Provider Module for quantum backend integration. The Eclipse / PyDev plug-in is specified to provide a Service Browser, Code Snippet Insertion, and a Visual Parameter Editor. The orchestration layer contains an Input Translator that maps high-level requests into OpenQASM or Quil, a Quantum Computer Recommender that selects a backend based on queue length, qubit count, and gate-fidelity metrics, and a Service Manager that handles deployment, queuing, and retrieval of results (Sabzevari et al., 2024).

A complementary hardware-near decomposition appears in the Rigetti quantum-classical cloud. There, the platform is built from a Physical Qubit Apparatus, a Classical Control System, a Quantum Executor, a Quantum Compiler, and a colocated classical compute environment called the Quantum Machine Image. The compiler maps backend-independent circuits onto native gate sets and connectivity, lowers them into pulse-level instruction binaries using up-to-date calibration information, and interacts with the executor through low-latency data-center links rather than the public Internet (Karalekas et al., 2020). Reference architectures at the software-engineering level then add lifecycle structure: service development, service deployment, and service split layers, with the quantum-classic split pattern dividing each service into classical pre- and post-processing modules and quantum modules for actual QPU circuit execution (Ahmad et al., 2023).

Hybrid workflow descriptions are correspondingly explicit. In the QCSHQD workflow, a developer selects VQE_Optimizer in the IDE, the IDE invokes the input translator, the quantum recommender picks an optimal QPU, the service manager submits the job, the result is returned, and an output translator decodes it for presentation in the IDE. The example interaction includes high-level inputs such as a Hamiltonian matrix, ansatz choice UCCSD, shots, and tolerance, followed by classical post-processing of the returned energy (Sabzevari et al., 2024). In practice, this workflow pattern recurs across QCaaS systems: user-level code remains classical, while parameterized quantum subroutines are invoked as remote services.

4. Performance, latency, scheduling, and cost

QCaaS performance is often dominated by orchestration overheads rather than raw gate times alone. For variational hybrid algorithms, Rigetti defines the observed latency as

$T_2$0

where $T_2$1 is the number of qubits, $T_2$2 is the number of shots per step, $T_2$3 is the variational step latency, and $T_2$4 is the quantum shot latency. The per-step latency budget reported in that study includes $T_2$5, AWG load and arm $T_2$6, AWG trigger $T_2$7, and network communications $T_2$8; the per-shot budget includes single-qubit gates $T_2$9, two-qubit gates $\epsilon_1 \simeq 1.26\%$0, readout capture $\epsilon_1 \simeq 1.26\%$1, and passive reset $\epsilon_1 \simeq 1.26\%$2 (Karalekas et al., 2020).

Two platform-level optimizations in that work—parametric compilation and active qubit reset—substantially reduced runtime. On Aspen-4 with the RPG(3) benchmark, the reported values were $\epsilon_1 \simeq 1.26\%$3 and $\epsilon_1 \simeq 1.26\%$4 for the first-generation Forest Web API, $\epsilon_1 \simeq 1.26\%$5 and $\epsilon_1 \simeq 1.26\%$6 for colocated QCS without parametric compilation or active reset, $\epsilon_1 \simeq 1.26\%$7 with parametric compilation, and finally $\epsilon_1 \simeq 1.26\%$8 and $\epsilon_1 \simeq 1.26\%$9 with active reset. The paper reports a step-latency improvement of more than $\epsilon_2 \simeq 1.77\%$0 and a shot-latency improvement of more than $\epsilon_2 \simeq 1.77\%$1 relative to the Forest API baseline (Karalekas et al., 2020).

Cloud studies also show that toolchain and provider choice strongly affect cost, scale, and fidelity. In a three-month comparison across Azure Quantum and AWS Braket, total latency was decomposed as

$\epsilon_2 \simeq 1.77\%$2

Queue times varied from tens of seconds to minutes or even hours; Azure’s queue-time estimates were reported to over-predict $\epsilon_2 \simeq 1.77\%$3 of the time, and actual times scattered over a wide band. For an 8-qubit QFT on IonQ Aria-1, Azure’s Qiskit provider transpiled to approximately 28 two-qubit gates, whereas AWS Braket’s Qiskit provider produced approximately 56 two-qubit gates; the reported fidelities were approximately 0.947 and 0.942, respectively. For a 10-qubit QFT with 500 shots, example costs were approximately $\epsilon_2 \simeq 1.77\%$415.30 on AWS Braket, and approximately $2,289.86 on Quantinuum H2 via Azure (Teegarden et al., 15 Jan 2026). These results show that QCaaS metrics are inseparable from compilation policy, queueing regime, and pricing model.

5. Deployment models, tooling, and security

A prominent engineering trend in QCaaS is the use of microservice and serverless patterns to encapsulate quantum routines behind standard web interfaces. Q-AIM presents a vendor-independent, open-source framework built around dockerized microservices, an NGINX reverse proxy, a FastAPI-based API Gateway, Keycloak for OAuth 2.0 / OpenID Connect, and internal services for user management, orchestration, monitoring, aggregation, and QC access. It exposes a single RESTful entrypoint, supports circuit-, IR-, and pulse-level interactions, and is designed to run on edge devices, on-premises servers, or public cloud VMs. Reported resource metrics include $\epsilon_2 \simeq 1.77\%$5 per microservice base layer, $\epsilon_2 \simeq 1.77\%$6–$\epsilon_2 \simeq 1.77\%$7, startup latency $\epsilon_2 \simeq 1.77\%$8, and maximum concurrent job throughput $\epsilon_2 \simeq 1.77\%$9 per FastAPI worker on an 8 GB VM (Zhu et al., 16 Jun 2025).

Serverless QCaaS pushes this encapsulation further. QFaaS organizes quantum services into six loosely-coupled layers, including Core APIs and API Gateway, an application deployment layer with Git-based repositories and templates for Qiskit, Cirq, Braket, and Q#, a Kubernetes-orchestrated classical cloud layer, a quantum cloud layer, monitoring, and user interfaces. Its function lifecycle covers development, deployment, classical pre-processing, backend selection, quantum computation, and classical post-processing; evaluation includes a quantum random number generator and Shor’s algorithm, as well as concurrency scaling under Kubernetes Horizontal Pod Autoscaler (Nguyen et al., 2022). A related chapter on the quantum serverless paradigm documents deployment via OpenFaaS/Kubernetes, a default maximum wait of 60 seconds for external job completion, and unified invocation through HTTPS endpoints with backend auto-selection (Nguyen et al., 2024).

Microservice-oriented deployment pipelines have also been proposed around modified OpenAPI specifications and CI/CD systems. One AWS-based design extends OpenAPI 3.0 with x-quantum-circuit-url and x-qiskit-code-url, uses GitHub Actions to validate the spec, generate Python/Flask stubs, build Docker images, and deploy them to EC2-hosted containers (Moguel et al., 2023). Another serverless integration on IBM Cloud combines a Java Spring Boot façade, Cloud Functions with Qiskit, Kafka-backed Event Streams for asynchronous job submission and result retrieval, WebSocket updates to the frontend, and queue-aware polling logic for IBM Quantum jobs (Grossi et al., 2021). Security and multi-tenancy in these designs are handled through OAuth2 or IAM bearer tokens, JWT-checked role-based access control, TLS, topic-level ACLs, per-job tagging with user_id and group_id, and tenant isolation through disjoint physical qubit allocation or temporal slicing (Zhu et al., 16 Jun 2025, Golec et al., 2024).

6. Limitations, conceptual debates, and future directions

The literature consistently identifies hardware fragility, heterogeneity, and queueing uncertainty as central limitations of QCaaS. QCSHQD lists the rapid evolution of quantum hardware, potential compatibility issues between different QPU vendors, and scalability concerns under high demand for quantum resources (Sabzevari et al., 2024). Early cloud access studies documented the lack of mid-circuit measurements and real-time feedforward, fixed circuit descriptions, and gate fidelities that limited circuit depth before noise overwhelmed results (Devitt, 2016). Broader surveys of quantum cloud computing emphasize qubit stability, coherence time, efficient resource allocation under uncertain job profiles, dynamic pricing models, multi-cloud interoperability, advanced virtualization, and automated error-mitigation orchestration as unresolved research gaps (Golec et al., 2024).

There is also a conceptual debate over the status of quantum services within service-oriented systems. QSOC treats quantum backends as auxiliary extensions managed by a classical service orchestrator, emphasizing model-driven composition, separation of concerns, and mixed quantum- and conventional applications (Kumara et al., 2021). By contrast, the SOQ paradigm argues that quantum services should be autonomous, composable, and interoperable first-class entities, published, discovered, composed, and orchestrated in the same way as classical microservices, with rich service contracts covering fidelity, pricing, and quality of service (Garcia-Alonso et al., 4 Oct 2025). This difference is architectural rather than terminological: it concerns whether QCaaS is fundamentally a subordinate component in hybrid software or a peer in a service graph.

Future directions extend both deeper into software engineering and outward into quantum networking. QCSHQD identifies prototype implementation of the IDE plug-in, formal orchestration models for latency and throughput, and schema extensions for advanced quantum primitives such as mid-circuit measurements and error-mitigation parameters as immediate next steps (Sabzevari et al., 2024). In distributed quantum computing, service differentiation has been formalized as a weighted max–min fairness problem over entanglement-generation resources, with Quantum-DRR proposed as a practical allocator and the Quantum Workers’ Assignment Problem introduced for fair peer selection across a quantum network (Cicconetti et al., 2023). A plausible implication is that QCaaS will evolve from single-provider cloud access toward multi-provider, policy-driven orchestration over heterogeneous QPUs, simulators, and eventually networked quantum resources.