Architecting for Quantum Cloud Workloads

An optimizer that converges in 300 iterations submits 300 jobs to a quantum processor. Give each job a 90-second wait in a shared queue before it runs, and the loop spends roughly seven and a half hours waiting against a few minutes of actual computation. Those numbers are illustrative, not measured, but the ratio they describe is the ordinary case rather than the pathological one. Nothing in the algorithm produced that result. The placement of the classical driver produced it.

Most introductions to cloud quantum access answer the question of what is available. This one answers a later question. Access exists, your organisation has an account, and someone now has to decide where each piece of the workflow runs. That decision is the difference between a pilot that finishes and a pilot that quietly stalls in a queue.

What you are actually integrating

A quantum processing unit (QPU) is the physical device that executes a quantum circuit. You never touch it directly. You submit a job, which bundles one or more circuits, a target backend, and a shot count. A shot is a single execution of the circuit that yields one measurement outcome, so a thousand shots yield a thousand outcomes. The result you get back is a distribution over bitstrings rather than an answer, and you extract the answer by post-processing that distribution classically.

Architects arriving from GPU or FPGA work reach for the accelerator analogy immediately, and it is useful up to a point. The analogy holds because a QPU is a specialised device that a classical program calls for one part of a computation. It breaks in three specific places, and every design decision in this article follows from one of them.

The device keeps no state between jobs. There is no residency, no warm cache, no allocated memory that persists after your circuit finishes. Each job arrives with everything it needs and leaves nothing behind. You cannot load data once and query it repeatedly, which rules out the whole family of designs that make GPU integration efficient.

Turnaround is dominated by scheduling, not execution. A circuit with a few hundred operations executes in microseconds to milliseconds. Getting to the front of a shared queue takes seconds to hours. When we measure a workflow’s wall-clock time, the compute term is usually a rounding error against the wait term.

The output is statistical. Two identical jobs return different bitstring distributions, and the size of that difference depends on shot count, device noise, and how recently the device was calibrated. Shot count becomes an architectural parameter with a direct cost, because more shots buy tighter statistics and nothing else.

Add these three together and a pattern falls out. Anything that calls a QPU in a tight loop is expensive by construction, and anything that calls it once with a large batch is cheap. That is the whole design problem in one sentence.

The workloads that provoke the problem are the variational ones. A variational algorithm splits work between a classical optimizer and the QPU: the optimizer proposes a set of circuit parameters, the QPU evaluates a cost function at those parameters, the optimizer proposes a better set, and the loop repeats until it converges. Variational quantum eigensolver (VQE) for chemistry and the quantum approximate optimization algorithm (QAOA) for combinatorial problems both work this way. They are the dominant application shape today, and they are precisely the shape that punishes bad placement.

Four placement patterns

There are only four sensible places to put the classical half of a hybrid workflow. We teach them as a ladder, because each step buys lower latency at the cost of more integration work and less flexibility.

Pattern A. Submit and forget

The classical program runs wherever it already runs, on a laptop, an on-premises server, an HPC login node. It builds one batch of circuits, submits the batch as a single job, and collects results later through a callback or a poll.

One round trip. Queue time and network latency are irrelevant, because nothing waits on them. This pattern suits benchmarking, characterisation runs, sampling problems, and any single-shot use of a quantum annealer. It also suits the first six months of most exploratory programs, and we push learners toward it harder than they expect. If a problem can be expressed as one batch, expressing it as one batch removes every other issue in this article.

Pattern B. Provider-hosted hybrid runtime

The classical driver runs inside the provider’s own environment, adjacent to the QPU, as a container or session that the provider schedules. IBM’s Qiskit Runtime and AWS’s Braket Hybrid Jobs are the two best-known implementations. You upload the optimizer along with the circuits, and the whole loop executes on the provider’s side of the wire.

This collapses the round trip to something close to the device’s own turnaround, and it usually gets the loop treated as one queued unit rather than 300 separately queued jobs. That second effect is the one that saves the seven and a half hours. The cost is portability. Your optimizer now lives in a provider-specific container format, and moving it to another vendor means rewriting the wrapper code even when the circuits themselves are portable.

Pattern C. Same-region co-location

The classical driver runs on ordinary cloud compute in the same region as the QPU, and calls the quantum service over the provider’s internal network. You write standard code on standard infrastructure, and you cut the network term to a few milliseconds.

What this pattern does not fix is queue position. Each iteration is still an independent job competing with every other tenant, so the wait term survives intact. Pattern C is the right answer when your loop is short, when you need classical resources the hosted runtime does not offer, or when the workflow has to sit inside your own cloud account for governance reasons.

Pattern D. Physical co-location

The QPU lives in the same facility as the classical compute, wired into the site network and often into the site’s job scheduler. The Julich Supercomputing Centre’s JUNIQ infrastructure is the reference example, with quantum systems installed alongside the centre’s own supercomputing resources. Finland’s VTT operates Helmi at its own site in Espoo and integrates it with national supercomputing over the network, which is a step short of physical co-location and a useful illustration of the difference.

This is the only pattern that supports sub-millisecond feedback between classical and quantum steps, and it is the only one available to workloads that cannot leave a facility at all. It is also a capital project with a multi-year horizon, a specialised facility requirement, and a systems integration effort that we cover in a separate module. Very few organisations should be choosing Pattern D as their first move, and the ones that should already know it.

Picking a pattern with arithmetic

The decision rule is short enough to write on a whiteboard. Estimate three quantities before you design anything.

Count the round trips your algorithm needs, call it N. Estimate the per-job overhead on your target backend, call it T, and take it as the sum of queue wait, submission latency, and result retrieval rather than execution time alone. Multiply. If N × T is acceptable against your deadline, use Pattern A or C and spend your effort elsewhere. If it isn’t, you either reduce N or move to a pattern that reduces T.

Reducing N is almost always cheaper than reducing T, and it is the step teams skip. Three techniques do most of the work. Batch every circuit that does not depend on the previous result into one submission, which matters enormously for gradient estimation, since the parameter-shift evaluations within a single gradient are mutually independent. Switch to an optimizer that tolerates noisy evaluations and converges in fewer iterations, because gradient-free methods and simultaneous perturbation approaches were designed for exactly this cost profile. And run the loop against a simulator until the parameters are close, then hand the warm start to hardware.

Work an example. Take a variational problem with 60 parameters and a naive design that submits one circuit per evaluation. Parameter-shift gradients need two evaluations per parameter, so 120 jobs per iteration, and 200 iterations gives 24,000 jobs. At a 30-second average overhead that is 200 hours of wall clock, which is not a pilot, it’s an abandoned project.

Now batch. The 120 evaluations in a gradient are independent, so they go in one job, and N drops to 200. Same overhead, and the wait falls to about 100 minutes. Move that batched loop into a hosted runtime under Pattern B, where the whole session is queued once, and the wait term becomes a single admission cost. The algorithm never changed. The submission topology did.

Two cautions on that arithmetic. Batch size has a ceiling set by each provider, so check it before you build around it. And per-job overhead is not a constant, since queues vary by device, by hour, and by how many other tenants are running. Measure it on your actual backend across a week before you plan against it.

Reproducibility and calibration drift

Today’s devices are described as noisy intermediate-scale quantum, or NISQ: enough qubits to be interesting, not enough error suppression to make results exact. What that means operationally is that a QPU’s error characteristics change between calibration cycles, and calibration typically runs on a schedule you do not control.

The architectural consequence is that a result is only meaningful alongside the device state that produced it. Design for that from the first job rather than the first audit. Pin the backend explicitly instead of accepting whatever the service selects. Capture the calibration snapshot the provider publishes for that device at submission time and store it with the results, along with the transpiled circuit rather than only the source circuit. Record shot counts, seeds, and SDK versions the same way you would record a container digest.

Engineers we train tend to assume this is a scientific nicety. It becomes an engineering necessity the first time a result fails to reproduce three weeks later and nobody can say whether the code changed, the device changed, or the compiler changed.

One related point on hardware roadmaps, because architects are routinely asked about them. Vendor announcements distinguish between physical qubits, which are the actual devices on the chip, and logical qubits, which are error-corrected units built from many physical qubits. Announced counts and demonstrated counts also differ. When a roadmap promises logical qubits by a given year, the architectural question to ask is not the number but whether the programming model changes, because a fault-tolerant device with a deep circuit budget invites algorithms that no current NISQ workflow supports.

Keeping the backend swappable

Portability across quantum providers is genuinely better than it was five years ago and still worse than most architects assume on first contact.

Two efforts carry most of the weight. OpenQASM, the Open Quantum Assembly Language, gives a textual circuit representation that many platforms accept, and its third revision added classical control flow. QIR, the Quantum Intermediate Representation maintained by the QIR Alliance, defines a compiler-level representation built on LLVM so that toolchains can target multiple hardware families. Several SDKs also present a backend-agnostic interface over multiple vendors, which is usually the practical entry point.

Portability holds and fails in systematic, not random, places.

Circuits written in a common gate set generally move. Transpilation does not, and transpilation is the step that rewrites your circuit into the native gate set and physical qubit connectivity of one specific device. A circuit optimized for a device with all-to-all connectivity between trapped ions will pick up a great many additional operations on a superconducting chip with nearest-neighbour connectivity, and those extra operations add error. The circuit moved. Its performance did not.

Device-specific capabilities do not move at all. Mid-circuit measurement with classical feedback, dynamic circuits, pulse-level control, and error mitigation options are all vendor features with vendor semantics. Quantum annealing is a different model entirely: problems are expressed as an objective function to be minimised rather than as a gate circuit, so an annealing workload and a gate-model workload are not two configurations of one program.

The design response is ordinary software engineering. Put a thin interface between your application and any vendor SDK, keep problem formulation separate from circuit construction, and treat the transpiled artefact as a build output rather than source. Then decide deliberately how much vendor-specific capability to use, and write the decision down. Using a hosted hybrid runtime is often the correct call even though it binds you to one platform. Making that trade without noticing is the failure.

What crosses the trust boundary

The security conversation around cloud quantum access is smaller than teams expect, and the small parts are the ones that get missed.

Start with what actually leaves your network. For most workloads it is a circuit description, a parameter vector, and a shot count, which is to say a few kilobytes. Bulk data almost never crosses, because there is no efficient way to load a large classical dataset into a quantum state on current hardware. The sensitivity, when it exists, is in the structure of the problem rather than the volume of the data. A circuit can reveal the shape of a portfolio model or the class of molecule under study, and that is a disclosure question your risk team can reason about with tools they already have.

Everything else is standard cloud practice applied without exceptions. Credentials for quantum services are long-lived API tokens by default on several platforms, so put them in the same secret manager as everything else and rotate them on the same schedule. Route through private connectivity where your policy requires it. Confirm in the contract, not the documentation, what the provider retains after execution and for how long. Tag jobs to a cost centre and an owner from the first day, because untagged experimental spend is the thing that gets a program cancelled.

Where an organisation genuinely cannot send problem structure outside its own facility, that constraint points at Pattern D and at a very different conversation about capital and operations. It is a real constraint for some defence and critical infrastructure work. It is not a general one, and applying it by reflex removes the cheapest path to capability for no security gain.

Guardrails before the first production job

Four failure modes account for most of the operational trouble we see, and each has a cheap guardrail.

1. Runaway shot spend. A misconfigured sweep can submit thousands of jobs before anyone notices. Enforce a per-project shot budget in your submission wrapper and alert on daily consumption.
2. Jobs that never return. Queues stall and sessions expire. Set explicit timeouts, make submissions idempotent so retries do not double-charge, and never let a workflow block indefinitely on a quantum result.
3. Device retirement. Providers retire backends with limited notice, and a pinned backend eventually becomes a broken reference. Keep an allowlist of approved backends, review it quarterly, and validate against a simulator so a retirement produces a clear failure rather than a silent fallback.
4. Silent backend substitution. Some services will route to an alternative device when your target is unavailable. That is convenient and it destroys comparability. Turn it off, or record the device that actually ran the job and treat substitution as a result-invalidating event.

The decision record

Before the first job goes to hardware, we ask learners to write a one-page record answering seven questions. It takes an hour and it prevents most of what this article describes.

1. Which pattern, A through D, and what changes would force a move up the ladder?
2. What is N, the round-trip count, and what has been done to reduce it?
3. What is T, the measured per-job overhead, on which specific backend and measured when?
4. Which backends are on the allowlist, and what is the fallback when one retires?
5. What is captured with each result: transpiled circuit, calibration snapshot, shot count, SDK version, backend identifier?
6. What leaves the network, and who approved it?
7. What is the shot budget, and who gets alerted when it is reached?

A workflow that answers all seven produces a defensible verdict on whether quantum access helped, which is what an architect is accountable for at this stage of the technology.

Where to take this next

The pattern ladder, the round-trip arithmetic, and the portability trade-offs form Module 4 of the Certified Quantum Systems Integrator (CQSI) program at Quantum Academy, where participants work through hybrid workflow design against real submission constraints rather than diagrams. The module sits alongside the facility and procurement material that Pattern D demands, so the on-premises decision gets treated as an engineering problem with a cost rather than an aspiration.

For the wider picture of how cloud quantum access developed and which providers offer what, the underlying survey on PostQuantum.com covers the market in more detail than an architecture piece should.