Towards Continuous Profiling and Optimization of Quantum-Classical Pipelines

Towards Continuous Profiling and Optimization of Quantum-Classical Pipelines Ayush Bansal1 , Owen Cochell1 , Santiago Núñez-Corrales1 , Marcos Frenkel1 , Seetharami Seelam2 , Apoorve Mohan2 ∗ , Tianyin Xu1

arXiv:2609.05814v1 [quant-ph] 5 Sep 2026

1

University of Illinois Urbana-Champaign

2

IBM Research

drastically different classical resource requirements, interact differently with the underlying quantum hardware, and produce different execution fidelity. In this paper, we focus on QEM, which is resource-demanding and tightly coupled to the quantum hardware state. Its optimization depends jointly on workload characteristics, classical resources, and the evolving hardware state, rather than on any single factor in isolation. Decomposing a workload into phases and profiling them individually is a well-established practice in classical highperformance computing (HPC). There, a profile is taken against stationary hardware—the same code on the same node next week exhibits the same bottleneck; hence, one characterization serves many executions. However, these HPC practices do not directly apply to quantum workloads. QPU error rates drift on timescales of minutes [20]. A noise model learned at the start of a sampling campaign can be invalid by its end; a qubit layout scored against a calibration snapshot can be stale before the job leaves the queue. The cost to recover fidelity is a function of the noise it must cancel, so a change in device state propagates into the quantumclassical resource bill. The decision variables span quantum and classical resources, and the objective is non-stationary— which is why one characterization does not suffice, and why profiling must be continuous beyond a one-time calibration. Unfortunately, many existing frameworks (e.g., [21, 22]) optimize the QPU, not the pipeline. Pipeline-aware frameworks [23, 24, 25, 26, 27, 28, 29, 30, 31] focus on orchestrating quantum-classical execution through scheduling, backend management, and job execution as part of the effort to integrate quantum devices with classical HPC infrastructure [32, 33, 34]. They provide relatively little visibility into the interactions between individual pipeline stages, classical resource behavior, and quantum hardware state. As a result, decisions such as qubit mapping, QEM selection, and resource provisioning are typically made independently or statically, despite being tightly coupled through both execution fidelity and resource consumption. Table III in Section VIII places existing systems along the axes this coupling implies. Our empirical characterization, using QEM as the representative stage, makes the implications concrete. QEM techniques differ by orders of magnitude in classical compute and memory demand; the classical phases within a single mitigation run differ in kind (memory-bound vs. compute-bound) and no single average utilization describes them; the classical host

Abstract—Quantum applications increasingly execute as multistage quantum-classical pipelines, interleaving QPU computation with classical stages such as circuit generation, transpilation, layout mapping, quantum error mitigation (QEM), and postprocessing. These stages have diverse resource requirements and exhibit stochastic behavior under drifting hardware noise, yet existing workflow frameworks treat them as static, isolated components. We present LLQM (Low-Level Quantum Machine), a profiling-driven meta-framework for quantum-classical pipelines. LLQM decomposes pipelines into fine-grained tasks and continuously profiles their CPU/GPU, memory, QPU, and queue dependencies alongside real-time hardware states. This unified runtime abstraction captures cross-stage resource dependencies and reveals how classical and quantum decisions interact, enabling characterization of their impact on fidelity and resource consumption. We evaluate LLQM using QEM as a representative pipeline stage, on IBM 156-qubit Heron r2 processors with circuits up to 100 qubits and 107 transpiled gates. Our results show that continuous profiling exposes runtime bottlenecks and enables hardware-, fidelity-, and workload-aware optimizations. Index Terms—Quantum, quantum-classical pipelines, quantum error mitigation, profiling, resource optimization.

I. I NTRODUCTION Quantum applications have evolved from small-scale experiments to utility-scale computations for quantum chemistry [1, 2], drug discovery [3, 4], and many-body dynamics [5, 6, 7]. These applications span tens to hundreds of physical qubits [8, 9, 5] on quantum processors such as the IBM Nighthawk (120 qubits) [10], IBM Heron (156 qubits) [11], and Google’s Willow (105 qubits) [12]. Current-generation Quantum Processing Units (QPUs) suffer from decoherence, gate imperfections, and readout errors that compound exponentially with circuit depth and width [13, 14, 15]. Producing a usable result therefore takes more than executing a circuit—an application runs as a multi-stage quantum-classical pipeline, where quantum computation is interleaved with classical stages, including circuit generation, transpilation, qubit mapping, error mitigation, and post-processing. Different stages of quantum-classical pipelines exhibit distinct computational characteristics, resource requirements, and optimization objectives, which collectively determine the fidelity and the cost of computation. Moreover, stages are not fixed in their own behavior. As we demonstrate in this work using Quantum Error Mitigation (QEM) [16, 17, 18, 19], different techniques within the same pipeline stage exhibit ∗ Project Co-PI and co-advisor.

1

can sit idle in polling loops for up to 92% of wall-time while waiting on the device, then spend 25–290× longer in classical mitigation than the quantum execution itself; switching QEM techniques swings the fidelity of the same circuit by more than 50%; and qubit layout alone can collapse one technique’s fidelity to near zero while inflating another’s QPU time by 1.8×. Few of these behaviors are visible in the per-circuit measurements that current frameworks report, and few of the underlying choices can be fixed correctly ahead of execution. Section II elaborates these observations in detail. In this paper, we present LLQM (Low-Level Quantum Machine), a profiling-driven meta-framework for quantumclassical pipelines. Rather than introducing another workflow runtime, LLQM provides a common profiling substrate that continuously characterizes pipeline stages together with the hardware state under which they execute. It decomposes each application into fine-grained typed tasks along a five-stage pipeline: classification, pre-processing, job queuing, execution, and post-processing. LLQM records each task’s classical and quantum resource behavior against the calibration snapshot it uses as a reference, and feeds telemetry back through two loops: (1) an intra-job loop that revisits a decision when fidelity falls short, and (2) an inter-job loop that keeps the cost models updated with the latest device states for subsequent jobs. Since tasks are independent by construction, a resource profile can be attributed to one stage of one technique on specific circuits, rather than averaged across a job—which is what makes the task graph a measurement abstraction. Atop the profiling substrate, LLQM defines common interfaces for decisions that consume real resources: hardwareaware qubit mapping via an Expected Success Probability (ESP) metric, QEM technique and configuration selection, and classical resource provisioning, taking fidelity targets and resource budgets as inputs. LLQM does not prescribe the policy behind any decision. It provides the runtime abstraction under which hardware-, fidelity-, and workload-aware policies can be implemented, evaluated, and compared on identical workloads, hardware states, and budgets. We discuss the LLQM architecture in Sections III and IV, and characterize the profiling substrate on QASMBench circuits [35] of up to 100 qubits and 107 transpiled gates on IBM Heron r2 processors, using mirror circuits [36] to evaluate fidelity at circuit sizes beyond the reach of state-vector simulation. The paper makes the following contributions: 1) We identify continuous profiling as a missing runtime primitive for quantum-classical pipelines, and show why static optimizations are insufficient when stage behavior depends on dynamic device state; 2) We develop LLQM, a profiling-driven meta-framework that decomposes a pipeline into typed tasks and records per-phase classical and quantum resource behavior alongside runtime device states, with common interfaces for hardware-, fidelity-, and workload-aware policies; 3) Using LLQM, we present a characterization of QEM, exposing the interactions among hardware state, mitigation effectiveness, qubit layout, execution fidelity, and

1.2 Fidelity by Technique and Circuit 1.0

Unmitigated REM

ZNE PEC

1.0

Mitigated Fidelity

Mitigated Fidelity

0.8

ibm_fez (bad HW) ibm_marrakesh (good HW) 1.00

0.90

0.91

0.97

0.86

0.8

0.6

0.63

0.6

0.4

0.4

0.2 0.0

1.2

Fidelity by Technique: good vs bad h/w (vqe_n4)

0.44

0.50

worse than REM!

0.2

vqe_n4 vqe_uccsd_n4ising_n10

0.0

d EM Unmitigate R

ZNE

PEC

(a) Fidelity of different techniques (b) Fidelity of different tech(ZNE/PEC/REM) on Ising and niques for the vqe_n4 circuit in VQE circuits of different sizes. different hardware states.

Fig. 1: QEM algorithm choice causes large workload- and noise-dependent fidelity swings: (a) A QEM algorithm’s fidelity varies widely with the type and size of the workload and may even fall below the unmitigated baseline; (b) The fidelity of the QEM algorithms changes with a slightly different hardware state: PEC performs worse than REM on the circuit.

quantum-classical resource consumption. 4) LLQM is maintained as an open-source project. II. M OTIVATION We present three case studies to motivate continuous resource profiling and holistic optimization for quantumclassical pipelines. Each study was conducted with LLQM across circuits ranging from 4 to 98 qubits and ∼400 to ∼107 transpiled gates over real IBM QPUs. The profiling of individual tasks across QEM configurations, hardware states, and qubit mappings made these measurements possible. Together they show that seemingly local configuration choices—which QEM algorithm to run, what parameters to choose, and which physical qubits to use—have first-order effects on both fidelity and quantum-classical resource usage, and that none of these choices can be made well without dynamic profiling. The choice of QEM algorithms drives major, non-uniform fidelity swings. Figure 1 shows that QEM results are non-uniform, non-deterministic, and workload- and noisedependent; applying QEM does not guarantee fidelity gains, and misconfigured techniques can greatly degrade fidelity. As shown in Figure 1(a), configured open-source Zero-Noise Extrapolation (ZNE) [17] achieves consistent fidelity gains across VQE and Ising circuits on an IBM 156-qubit Heron r2 processor, whereas Probabilistic Error Cancellation (PEC) [17, 18] degrades fidelity on bigger Ising workloads (ising_n10). Circuit width, gate count, and algorithm family (e.g., VQE or Transverse-Field Ising Model) play important roles in QEM algorithm choice and configuration.

2

1.00

ZNE classical (folding only)

0.70

0.75 0.25

0.05

0.0

IPC utilisation (%)

(b) Per-phase utilisation within a bounded band 80

71% 54% 38%

20 0

PEC sampling (423 s)

PEC exec (5100 s)

QPU wait

ZNE folding (0.54 s)

ZNE exec (137 s)

0.907

QPU time (right)

600

498 s

400

0.8 0.6 0.4

200

278 s

0.2 0

0.891

0.0

good qubits Fidelity (left)

bad qubits

0

QPU time (right)

(b) PEC’s QPU cost 1.8×.

generation is memory-bound and NUMA-sensitive (moving up to 1.16 GB/s DRAM read traffic at 38% physical IPC), circuit sampling is compute-bound and highly parallelizable (54% IPC over 423 seconds), and the QPU execution/queuing phase stalls classical host CPUs in polling loops for 5, 100 seconds (92% of total wall-time) at low IPC (≈ 31%). Since per-phase intensity stays within a bounded band, an algorithm’s footprint is predictable from a short profiling window; however, PEC’s aggregate memory grows with the number of sampled circuits, making memory a first-class, algorithm-dependent budget dimension that a profiler must account for. Existing schedulers fail to account for heterogeneous classical burdens, wasting classical resources during QPU queue polling.

Fig. 2: The QEM algorithm determines the classical memory/compute footprint: PEC is much more resource-hungry than ZNE, and PEC’s classical phases move substantial DRAM traffic while ZNE’s are negligible. Phases differ in compute nature: some are memory-bound (PEC representation generation), others compute-bound (PEC sampling); the QPU wait phase polls the QPU for results (vqe_n4). Figure 1(b) demonstrates that spatial and temporal variations in QPU hardware state (comparing a good set of hardware qubits to slightly degraded hardware qubits) drastically change the performance of the techniques. On slightly degraded hardware qubits, open-source PEC’s fidelity collapses to 0.500— performing worse than simple readout error mitigation (REM) (0.628) [37] on the vqe_n4 circuit. The gap between the best and worst QEM choices often determines the usefulness of the result, yet the optimal choice cannot be predicted statically from the circuit alone—it depends heavily on the workload and the device’s real-time noise profile. QEM algorithms impose drastically different classical computing resource costs. Figure 2 shows that error mitigation algorithms exhibit vastly different classical compute and memory bottlenecks that dominate total execution cost. While both PEC and ZNE are “pre-heavy” techniques, ZNE is a lightweight technique where classical folding takes less than one second (for vqe_n4) and the runtime is dominated by QPU execution, whereas PEC requires a classical sampling overhead γ 2 that scales exponentially with circuit fault rate: ! Y X γ= exp(2λk ) = exp 2 λk (1) k∈K

10

800 1.0

Fig. 3: Qubit selection strongly affects both fidelity and QPU execution time: poor qubits collapse ZNE’s fidelity and inflate PEC’s QPU cost (4-qubit circuit); note the change in QPUtime y-axis of the two figures.

QPU wait

PEC repr-gen (19 s)

bad qubits

20

(a) ZNE’s fidelity collapses to 0.

50% ref

31%

good qubits Fidelity (left)

67%

21 s ≈0

0.2

0.09

0.00

60

20 s

0.4

QPU wait

30

0.910

0.8 0.6

0.37

0.50

40

1.0

40

QPU time (s)

1.16

fidelity nearly held (0.907 → 0.891) QPU cost grows 1.8×

Fidelity

1.25

(b) PEC

50

QPU time (s)

(a) ZNE fidelity collapses (0.910 → ≈ 0) QPU cost essentially flat (1.05×)

PEC classical (repr-gen + sampling) Fidelity

DRAM READ bandwidth (GB/s)

(a) Classical memory traffic set by QEM technique

Physical qubit selection and mapping dictate both fidelity and the scale of quantum-classical costs. Figure 3 shows that physical qubit layout has first-order impacts on both execution fidelity and QPU time—directly impacting quantumclassical resource costs. Mapping a 4-qubit state-preparation circuit onto degraded physical qubits causes ZNE fidelity to collapse from 0.910 to near zero, rendering the QPU run useless. Conversely, PEC recovers high fidelity (0.891) on the degraded qubits, but does so at the cost of inflating QPU execution time by 1.8× (from 278s to 498s) due to the higher sampling overhead γ 2 required to cancel the increased physical noise (more noise → larger γ 2 → more samples → more QPU time). Despite this, the impacts of hardware-aware qubit selection on fidelity and resource cost remain comparatively under-studied. LLQM treats qubit selection as a first-class optimization target alongside QEM selection and resource provisioning to prevent cascading resource inflations. III. OVERVIEW

k∈K

LLQM is an extensible framework for continuous profiling and closed-loop optimization of quantum-classical pipelines. Figure 4 shows its components and workflow. LLQM takes user-specified fidelity targets and resource budgets as inputs, and jointly optimizes quantum-classical hardware resources by dynamically tuning pipeline stages based on the structure of

where λk are the learned parameters of the sparse PauliLindblad noise model [17, 18]. However, PEC can fully cancel noise bias, but it can consume 25–290× more total execution time than ZNE for the same circuit. Profiling reveals stark phase-dependent resource characteristics: PEC representation

3

1 Users (input job) Inputs: • Circuit (workload) • Constraints Features: • Constraints • Fidelity • Resource • Shot count • Techniques • Transpilation • QEM

Circuit + Features 2 Workload

Classifier

(workload specific decisions) Determine Tools: app type: • LLQM Profiler • VQE • Qiskit • Trotter functions • Ising • QAOA …

input, config hints

Doesn’t block on single user

Pre-processor

(fix workload properties)

3A

Qubit Layout Selection (pick layout with best ESP)

Pick Qubit Mapping Algo => Pick a layout Apply Transpilation (based on h/w) LLQM Qubit Selection, Qiskit Library, Cuda-Q, Custom algorithms …

Intra-job feedback loop: Back to pre-processing stage

5 Is qubit layout still good ?

NO

4

QEM Profiler Profile QEM Algo: • ZNE • PEC • PNA • SQD …. (over different h/w states & workloads)

Collect Execution Results

YES 6

Job Queues

Preschedule Planner

QPU Queue

Creating Co-schedules (time-slicing)

Sync layout

H/W Qubit Layout

3B QEM Technique Selection Fix one technique and configuration, given qubit layout and constrains

GPU Queue

QEM Profiler, Qiskit QEM Library, Mitiq

Classical Quantum

3

Task Specifications

3C

Prepare Jobs to run

7

8 Post-Processor

Executor (External)

Workflow Orchestrator Quantum (if present) Backends • QFw • Cuda-Q • Qiskit • MQT • Cirq …

Compute Results

• IBM Qiskit • LCCFQ …

7B

Classical Backends Using API Endpoints

CPU Queue

Resource-based task classification, task decomposition & parallelism QEM Profiler, Qiskit Library

7A

Inter-job feedback loop: Fidelity, resource usage and statistics

from scratch

NO

• IBM Cloud • NCSA Cloud • Local …

7C

• LLQM Profiler and Workload Manager • Qiskit • Mitiq • CUDA-Q … Output: • Computation Result • Achieved Fidelity • Resource Usage

(output job)

10B Run

more samples

YES

Provide Results (+ Fidelity) Resource Cost (if relevant)

Can more executions 10 improve fidelity ?

Tools:

Parallel

Small Jobs to schedule

• Merge outputs across jobs • QEM Post-processing • Produce Results • Calculate Fidelity

11 Users 10ARestart

Features: • Telemetry • Resource Usage

NO Is Fidelity

9 constraint satisfied?

YES

Check fidelity against constraints

Fig. 4: LLQM decomposes a quantum-classical pipeline into fine-grained tasks, dynamically profiling each to understand local bottlenecks and their implications for dependent operations. The framework holistically improves resource efficiency by optimizing configurations (e.g., QEM algorithms), resource provisioning, and hardware-aware qubit mapping.

ranked list of candidate QEM and qubit-mapping algorithms. Ranking must happen here because later stages see only a circuit, and the workload family is what determines whether a technique applies—SQD [1], for instance, exploits chemistry-specific structure that no inspection of the gate list recovers. 2) Pre-processor 3 decides what to run. It selects a backend and physical qubit layout using an Expected Success Probability (ESP) metric 3A , then commits to a QEM technique and configuration for that layout 3B . Both decisions are made against a calibration snapshot, and are only effective when the snapshot is fresh. The committed configuration is decomposed into a directed acyclic graph of typed sub-jobs (memory-bound, GPU/CPU-parallel, or QPU) and pushed to resource queues 3C . 3) Job queues and pre-schedule planner 4 – 6 hold ready work in heterogeneous CPU, GPU, and QPU queues 4 . Queued tasks are monitored continuously: if drift invalidates the layout a task was planned for, that layout and its dependent sub-jobs are reconfigured 5 . The planner then co-schedules independent classical and quantum tasks, in parallel or time-sliced across workers, ensuring neither resource remains idle 6 . Ready tasks are admitted to a ready set that is global across all jobs rather than per-job, so the scheduler may interleave tasks from different jobs and defer work when hardware is unavailable. 4) Executor 7 dispatches tasks to external quantum backends (e.g., IBM Quantum and LCCFQ; 7B ) and classical HPC resources 7C , directly or via an orchestrator 7A such as QFw [24] or CUDA-Q [40]. LLQM exposes a uniform backend abstraction so every task returns a canonically formatted record regardless of where it ran. 5) Post-processing and feedback 8 – 11 fuse job outputs, apply the selected QEM’s estimator, and compute fidelity 8 . If constraints are met 9 , the result returns to the user 11 ; if a shortfall can be addressed by more

the workload and the noise state of the device at execution time. Any stage can plug into LLQM through a common interface by declaring its configuration space. Our current implementation focuses on qubit layout and on QEM technique and configuration—because these decisions dominate both fidelity and resource cost on today’s devices (Section II). Closed-loop continuous profiling. LLQM establishes a continuous closed-loop workflow. It profiles individual task execution across classical nodes and QPUs and monitors QPU calibration drift in real time. It then dynamically adjusts QEM configurations, layout mappings, and job schedules using the telemetry. Two feedback edges close the loop on different timescales. The intra-job edge sends a fidelity verdict back to the decisions that produced it (steps 9 → 10 → 3 ). The interjob edge returns fidelity, resource usage, and execution statistics from every completed task to the profiler (step 8 → QEM profiler), calibrating the cost model that the next job’s decisions consume against hardware in a similar noise state. Constraints and inputs. A job enters step 1 as a quantum circuit U (e.g., OpenQASM [38] or Qiskit [39]), optionally with hints steering method selection and hard constraints: target fidelity Fmin ∈ [0, 1] (e.g., ≥ 0.80), quantum time budget Tq , classical compute budget Tc , memory ceiling µmax , and shot-count caps. Tc covers all CPU and GPU time consumed by the job: though LLQM types every task by the processor it runs on and provisions CPU/GPU separately (Section IV-D), both count against the same budget to prevent policies from bypassing limits by shifting work between processors. These classical budgets may be unnecessary for single-user deployments but are important for the shared systems LLQM targets. Pipeline. LLQM routes each job through a fine-grained pipeline of five stages, spanning the eleven steps of Figure 4: 1) Workload classifier 2 admits the circuit, checks user constraints, identifies the workload family (e.g., VQE, Ising, Trotterized dynamics, QAOA), and produces a

4

TABLE I: Information recorded by the LLQM profiler.

sampling 10 , the job is resubmitted with a larger shot budget 10B ; otherwise it is restarted 10A , or fails if no configuration can satisfy the constraints. IV. M AIN C OMPONENTS

Group

Quantities

Consumer

Program P

Circuit width, one- and two-qubit gate counts, workload family One- and two-qubit gate error rates, readout error rates, calibration age CWA and ESP derived from Bt over a specific qubit layout Wall-clock CPU/GPU/QPU time, IPC, DRAM read/write bandwidth, shots, queue wait vs. execution

§IV-C

Device Bt

A. Profiling Substrate Layout L

LLQM decomposes a job into tasks so that it can optimize task executions based on circuit size, noise profile, and resource availability. Fine-grained task decomposition in LLQM is not only an engineering discipline but also a precondition for effective optimizations.

Task record

Tasks as the unit of measurement. LLQM compiles a job into a directed acyclic graph of tasks. Each task is an atomic operation, typed as QPU, CPU, or GPU work, that consumes a fixed set of inputs and produces outputs feeding its child tasks. Tasks are independent by construction: given its inputs, a task can complete on its own, with no dependency on any other task. A single terminal task returns the job’s result. Independence is what makes the graph a measurement abstraction and not merely a scheduling one—a resource record attributed to a task belongs to one phase of one technique on one circuit, instead of being averaged away across a job.

§IV-B §IV-B §IV-C, §IV-D

does not dominate the score, and a medium-quality qubit on the critical path is not hidden by good but idle neighbors. The expected success probability (ESP) is the probability that the circuit executes with no error, Y Y ESP = (1 − ϵq )Nq × (1 − ϵc )Nc , (2) q∈Qused

c∈Cused

where ϵq , ϵc are single- and two-qubit error rates and Nq , Nc count how many times the transpiled circuit acts on physical qubit q or coupler c; higher is better. The two are complementary: ESP is dominated by circuit depth and falls off sharply for large circuits, making it a weak discriminator between layouts of the same deep circuit, whereas CWA stays comparable across depths but discards the compounding effect that makes deep circuits fail. Neither is meaningful in absolute terms; both only rank layouts of the same circuit against one another. LLQM treats layout selection as a pluggable interface over a portfolio of qubit-mapping algorithms such as Identity, SABRE [41], GreedyV/E and R-SMT [42], VQA/VQM [43], and JIT [44]. It generates candidate layouts, scores them, and returns the best one that satisfies the user’s constraints, falling through the portfolio until one is acceptable or the portfolio is exhausted—exhaustion being the failure state of Section III. We retain the non-noise-aware baselines deliberately: aggressive noise-aware transpilation concentrates work onto a small subset of “good” qubits and yields only marginal mean-fidelity gains over a randomized mapping, which itself exhibits lower run-to-run variability [45]. If that generalizes, always paying for the most expensive selection pass spends classical time for no fidelity benefit. Keeping the baselines lets LLQM detect this per circuit rather than assume it away.

From profiles to cost models. Table I lists the information recorded by the profiler. Section II shows that per-phase resource intensity remains within a bounded range, enabling a short profiling window to calibrate the cost model r̂(c | P, L, Bt ) = (tq , tc , µ). Here, c is a candidate configuration (a QEM technique with parameters and shot count from Section IV-C), while (P, L, Bt ) denote program features, qubit layout, and device calibration state from Table I. The model predicts quantum time tq , classical time tc , and peak memory µ consumed by c under those conditions. Two qualifications are important. First, µ is configurationdependent: for example, PEC memory grows with sampled circuits, so memory must be modeled as a first-class budget rather than folded into time. Second, the executor is partially opaque: cloud tasks expose queue wait, execution time, and shots consumed, but not provider-side host counters; local backends and simulators do not have this limitation. Online, these records provide estimates for the three decisions below. Offline, they reveal actual resource bottlenecks—e.g., the 92% polling stall in Section II, which no selection policy addresses and existing frameworks fail to expose. B. Qubit-Layout Selection

C. QEM Selection

Layout selection consumes Bt and the program’s structural features. It runs first because it changes which QEM configurations are feasible (Figure 3): the layout fixes the fidelity the run starts from, which in turn determines the technique required and the quantum–classical cost that technique incurs. To compare candidates before committing QPU time, LLQM scores each with two static metrics derived from Bt . The circuit-weighted average (CWA) error weights each physical qubit’s and coupler’s error rate by how often the layout uses it, so a low-quality qubit the circuit barely touches

At this stage, the pipeline holds a committed layout L, the snapshot Bt , program P (Table I), and the calibrated cost model r̂. LLQM decides how to mitigate noisy circuit runs. Let M be the set of QEM techniques. Each m ∈ M carries a parameter space Θm , and every execution additionally fixes a shot allocation s, so a QEM S configuration is a triple c = (m, θ, s) drawn from C = m∈M {m} × Θm × S, of which exactly one element is committed before any task is generated. A configuration induces a predicted fidelity F̂ (c | P, L, Bt ) ∈

5

[0, 1] and a predicted cost vector r̂(c | P, L, Bt ) = (tq , tc , µ), and the user constraints of Section III carve out a feasible set o n Cfeas = c ∈ C F̂ (c) ≥ Fmin ∧ r̂(c) ≤ (Tq , Tc , µmax ) , (3) from which the stage returns the cheapest member, c⋆ = arg minc∈Cfeas cost(c), signaling the failure state when Cfeas = ∅. Fidelity is a requirement the user states, not a quantity to maximize: spending more of a shared QPU than Fmin demands is a cost borne by every other job in the system. LLQM currently supports four options: no mitigation, REM, ZNE, and PEC. REM corrects only measurement errors; ZNE is cheap and broadly applicable but leaves a residual bias no amount of sampling removes; PEC cancels noise bias given a learned noise model, at a sampling overhead γ 2 that grows exponentially with the circuit fault rate (Equation 1). The nomitigation baseline is a genuine option: Figure 5 shows mitigated configurations that fall below it in fidelity, so choosing not to mitigate is a decision and not merely the absence of one. A technique joins the portfolio by supplying three things—its parameter space Θm , a cost model r̂ calibrated by the profiler, and an estimator that consumes task outputs—so M is open and implementation-defined rather than fixed by the pipeline; we are adding support for more QEM techniques, including PNA [46], SQD [1], and QuePP [47]. Equation 3 has three terms; profiling makes two of them cheap: the constraints are given a priori and the cost vector is calibrated. The fidelity predictor F̂ remains a challenge: no sound construction is known. Its arguments are clear— workload structure and real-time noise profile jointly determine the outcome, and the profiler collects both—but the function itself is not. A recent community assessment reports that much of the QEM landscape remains empirical and problem-specific, with few guidelines on when to apply a given technique [48]. LLQM offers extensible interfaces to plug in different QEM techniques and configurations—the profiler supplies (P, L, Bt ) and r̂, each QEM technique supplies Θm , the constraints supply Fmin and the budgets, and the job generator consumes whichever c⋆ is returned.

E. Closing the Loop Staleness gate. Since selection and execution may be separated by arbitrary delays, LLQM monitors the device while a task waits and re-reads the snapshot before submission. If Bt drifts enough that the committed layout no longer meets Fmin , the task is reconfigured and its graph updated, either by re-running the decisions of Sections IV-B and IV-C or by returning failure as per deployment policy. The gate cannot catch drift after submission: Section V shows PEC campaigns running for hours, long enough for the device to drift away from the Pauli-Lindblad model learned at startup. Preventing this requires bounding a technique’s sampling duration by its calibration-decay timescale, which the profiler does not yet measure. Backend abstraction. Quantum tasks are dispatched through a unified interface across cloud providers, local QPUs, and simulators. This enables comparable profiles: every execution returns a unified result format (result type, raw and normalized measurements, achieved fidelity, shots, and time consumed), so task records have consistent meaning across backends. Feedback. When a job’s terminal task completes, its results are fused and checked against the constraints. If the constraints are satisfied, the result returns to the user. If the shortfall looks correctable by more shots or a minor parameter change, the job is reconfigured and resubmitted. Otherwise, it re-enters the decision stages or fails. Each outcome is also a measurement: a completed job yields a (c, L, Bt ) triple annotated with achieved fidelity and true resource cost—the supervision the missing predictor F̂ of Section IV-C would require. LLQM does not learn that predictor, but it is built such that the data needed to learn it accrues as a by-product of running jobs. V. P RELIMINARY R ESULTS The motivating studies in Section II showed, on a handful of representative circuits, that the choices of QEM techniques, configuration parameters, and qubit selection have first-order effects on fidelity and quantum-classical resource consumption. This section extends the experiments across diverse circuits (Table II). Despite being preliminary, the results reinforce our observations at a larger scale: the right configuration cannot be chosen statically, strengthening the motivation of LLQM’s profiling-driven, closed-loop optimizations.

D. Resource Provisioning Once c⋆ in Equation 3 is fixed, LLQM expands it into a task graph and provisions classical resources for each task. Profiling provides not only scalar cost but also each task’s intensity class. Section II shows that PEC representation generation is memory-bound, circuit sampling is compute-bound and parallelizable, and QPU execution performs no useful classical work while pinning large memory. These distinctions drive provisioning and are invisible without per-task profiling. Two decisions are intertwined. Per task, LLQM selects placement (CPU or GPU) and core/memory allocation; globally, it selects the next ready task to run. The ready set spans all jobs, allowing cross-job interleaving and turning the queue-wait stall and post-processing gap in Section II into schedulable capacity. LLQM only enforces dependency order; the scheduler optimizes using the task graph, user constraints, cost predictions r̂, live hardware state, and profiler records.

A. Setup Benchmark. We evaluate LLQM on benchmark programs from OpenQASM-2 [35], spanning its small, medium, and large categories and covering VQE, UCCSD-VQE, Ising, and Trotter families with widths of up to ∼100 qubits and up to ∼107 transpiled gates. Table II lists each circuit with its native and transpiled gate counts; we report transpiled counts because the transpiled circuit—not the logical one—is run on the QPU. Hardware measurement. Quantum workloads ran on IBM 156-qubit Heron r2 processors; QPU time is the providerreported billed duration for which the QPU was locked.

6

TABLE II: Benchmark circuits used in our studies (from QASMBench [35]). Native counts are the logical OpenQASM2 gates and CNOT counts; transpiled gate count is measured after mapping onto the IBM Heron r2 processor.

Fidelity Improvement over Unmitigated (Δ fidelity) Circuit labels show gate count (g) (414g)

vqe_uccsd_n4 (1,832g)

Circuit vqe_n4 vqe_uccsd_n4 ising_n10 ising_n26 ising_n34 ising_n66 ising_n98 basis_trotter_n4 vqe_uccsd_n6 vqe_uccsd_n8 vqe_uccsd_n28

Gates

CNOTs

Transpiled gates

ising_n10

89 220 480 280 368 720 1,072 1,626 2,282 10,808 399,482

9 88 90 50 66 130 194 582 1,052 5,488 296,648

414 1,832 2,481 1,982 2,463 5,415 7,948 12,739 21,769 116,974 9,178,441

ising_n26

(2,481g)

(1,982g)

ising_n34 (2,463g)

ising_n66 (5,415g)

ising_n98 (7,948g)

basis_trotter_n4 (12,739g)

vqe_uccsd_n6 (21,769g)

vqe_uccsd_n8 (116,974g)

vqe_uccsd_n28 (9,178,441g)

All classical mitigation work (folding, representation generation, sampling, estimation) ran single-threaded on one core of an Intel Xeon Platinum 8474C, giving a conservative, parallelization-free per-task cost. This single-host configuration is deliberate: it establishes the per-phase resource profile of each technique in isolation, before parallelization or multinode placement is applied. The profiling substrate and the three decisions it feeds are independent of deployment scale; what changes with scale is the difficulty of the provisioning policy in Section IV-D, not the measurements it consumes. Classical time is instrumented per pipeline phase; DRAM bandwidth and IPC were collected with Linux perf [49] in a separate run so that profiling overhead would not perturb the reported timings. To evaluate fidelity without incurring the exponential cost of classical state-vector simulation, every circuit U is transformed into a mirror circuit by appending its inverse U † , ensuring that the ideal output is exactly the allzeros |0 . . . 0⟩ [36]. The observable M is the spatial average of the single-qubit Pauli-Z expectation values across all n qubits, 1X ⟨Zi ⟩, n i=1

+0.10

+0.07

-0.01

+0.55

+0.16

-0.00

+0.24

-0.07

0.4

+0.03

+0.22

-0.71 => 0.00

0.3

-0.05

+0.30

-0.69 => 0.00

0.2

-0.04

+0.33

-0.57 => 0.00

0.1

+0.02

+0.35

-0.47 => 0.00

0.0

+0.00

+0.32

-0.21 => 0.00

−0.1

+0.00

+0.01

-0.02

+0.13

0.5

−0.2 −0.3

-0.01

REM

ZNE

PEC

Fig. 5: Fidelity improvement over the unmitigated baseline (∆ fidelity) for each technique across circuits (row label: transpiled gate count g). ZNE delivers consistent gains, REM is near-neutral, and PEC ranges from improvement on small circuits to severe degradation as circuit size grows. unmitigated baseline itself falls with gate count, so an identical collapse to 0.00 registers as a progressively smaller ∆ (−0.71 on ising_n26 down to −0.21 on basis_trotter_n4). On the other hand, recall from Figure 3, with a slightly degraded hardware state, ZNE’s fidelity collapses, but PEC is able to recover. For a large fraction of circuits, the wrong technique results in worse fidelity than no mitigation; the best choice is not predictable from the circuit family alone, showing the importance of profiling-driven QEM selection. The classical resources, not the QPU, can be the execution bottleneck; the cost is QEM-technique-dependent. Figure 6 breaks down the execution of ZNE and PEC into quantum and classical components. (Note that the timescales are different.) The execution time of ZNE is modest and is dominated by the QPU time; the execution time of PEC, on the other hand, is overwhelmingly dominated by the CPU time: circuit sampling reaches ∼1.3 × 104 s, which is 25–290× of ZNE cost for the same circuit. QPU time is irreducible by provisioning; PEC’s classical cost is not. The bottleneck here is classical sampling—the host drawing and constructing the quasi-probability circuits, before any of them reaches the QPU—and the classical times we report are single-threaded (Section V-A). They are therefore a per-task cost profile rather than an achievable latency: the sampled circuits are mutually independent, so this is precisely the phase a scheduler with spare cores could collapse. A QPU-centric scheduler does not; it provisions for the quantum time and leaves this classical work unaccounted for entirely. PEC’s degradation is not random noise but can be explained (and avoided). Figure 7 explains the PEC collapse in Figure 5. On large circuits with more faults, the raw (unclipped) estimator diverges far outside the measurement

n

M=

+0.01

Δ fidelity

vqe_n4

(4)

whose ideal value is ⟨M ⟩ideal = +1. Execution fidelity is its linear distance from the mitigated expectation value M̂ ,   Fidelity = max 0, 1 − |M̂ − 1| . (5) B. Results and Observations No single QEM technique is universally effective; an illfit technique or suboptimal configuration parameters can impair fidelity. Figure 5 reports the fidelity change relative to the unmitigated baseline (∆ fidelity) for each technique across circuits. ZNE configured per circuit improves fidelity consistently (+0.10 to +0.55). REM is near-neutral and occasionally negative, as measurement-error mitigation cannot address a gate-error-dominated regime. PEC improves the two smallest circuits and then collapses fidelity to 0.00 on every larger circuit it ran on. One reading of the figure worth guarding against: ∆ understates PEC’s harm as circuits grow, because the

7

Time (seconds)

200 150 100

vqe vqe ising ising ising ising ising basis vqe vqe n4 uccsd n26 n34 n10 n66 n98 trotter uccsd uccsd n4 n4 n6 n8

100

103

104

105

106

107

102

101

0

20

40

60

Number of Qubits

80

100

Fig. 8: Transpiled gate count is the primary cost driver for different techniques.

PEC: Quantum vs Classical Breakdown (sampling dominates) Repr. generation (classical) Job-setup gap (classical) Circuit sampling (classical) QPU execution (quantum)

Unmitigated REM

0.8

5000

ZNE PEC

0.6 0.4 0.2

2500 vqe uccsd n4

ising n26

ising n34

ising n10

ising n66

ising n98

105

106

107

0

20

40

60

80

100

Qubit Count

lation decouples it from the work the device actually performs. Measured QPU time follows the transpiled gate count (Figure 8(a)): each technique traces its own near-monotonic trajectory, PEC highest and steepest, so a cost model keyed on the gate count both separates the techniques from one another and extrapolates within one. Against qubit count (Figure 8(b)) the same measurements collapse into a band with no usable trend. Fidelity behaves the same way (Figure 9). The 4-qubit basis_trotter_n4 consumes more total execution time than the 98-qubit ising_n98 (Figure 6), and reaches lower fidelity (Figure 5). LLQM therefore uses transpiled gate count as a primary feature for r̂ (Section IV); sizing the same jobs by qubit count would mis-provision them by orders of magnitude.

PEC fidelity collapses where its estimator diverges 10 valid range [0, 2]

0.75 0.5 0.25 0 −102 −105 −107

vqe vqe ising ising ising ising ising basis n4 uccsd n10 n26 n34 n66 n98 trotter n4 n4 Raw estimator: in range [0, 2] Raw estimator: diverged

0.4

Fig. 9: Transpiled gate count is the primary fidelity driver for different techniques.

Fig. 6: Breakdown of execution time of ZNE and PEC into quantum and classical components, across various circuit sizes.

2 1

104

Transpiled Gate Count (log)

basis trotter n4

0.6

0.0 103

vqe n4

0.8

0.2

0.0

0

Fidelity vs Qubit Count (qubit count alone is not a good predictor) 1.0

Fidelity

7500

Fidelity vs Gate Count (gate count is the primary driver of quality) 1.0

Fidelity

10000

Time (seconds)

Unmitigated REM ZNE PEC

101

QPU Time Scaling with Qubit Count (contrast with gate-count scaling)

(a) QPU time versus gate count. (b) QPU time versus qubit count.

12500

Fidelity / raw mitigated value (log below 0, shared zero)

102

Transpiled Gate Count (log scale)

50 0

QPU Time Scaling with Circuit Size (Gate Count) Different techniques scale very differently

Quantum Seconds (log scale)

250

Quantum Seconds (log scale)

ZNE: Quantum vs Classical Breakdown (quantum dominates) Circuit folding (classical) QPU execution (quantum)

Fidelity: unmitigated Fidelity: PEC (clipped)

VI. E XPERIENCE AND D ISCUSSION Our experience building LLQM exposes several implications for quantum-classical pipeline optimization. We show that fidelity is fundamentally different from conventional resource objectives. However, the desired outcome cannot be directly observed during production execution, and optimization quality improves as the system accumulates workload and device experience. In this section, we discuss these implications and clarify the boundary of LLQM’s current design, including optimizations that fit its abstraction but introduce trade-offs it cannot yet make (which we will discuss in Section VII).

Fig. 7: PEC failure mechanism. On large and higher-fault circuits the estimator diverges; each PEC point requires a large sampling time (∼3–4 hours), during which hardware drift can invalidate the learned noise model. value range [0, 2], collapsing fidelity. The cause is strongly correlated with cost: for these circuits, PEC’s sampling time can be as long as hours, long enough for hardware calibration to drift and invalidate the learned Pauli-Lindblad noise model, so the generated samples no longer cancel the true noise [18]. PEC’s viability is thus tied to both circuit fault rate and hardware stability, precisely the conditions LLQM profiles before committing to a technique, and monitors for changes. Transpiled gate count predicts cost and quality better than qubit count. Qubit count is the number a QPU is advertised by, and the one a scheduler most readily has, but transpi-

Fidelity is a constraint, not a currency. Time and memory are tradable—a policy may spend classical cores to save QPU-seconds, or vice versa. Fidelity is not. Below the target Fmin , the result is unusable and its resources are wasted: in Section II, a layout choice collapses fidelity to ≈ 0, making the QPU time worthless. Above Fmin , extra fidelity has no value to a user who set the target, while the QPU time it consumes is

8

expensive. Thus, when resources are flexible, spending more resources is preferable to accepting insufficient fidelity.

below which it degrades the estimate [51]. Equation 3 therefore ranges over whole configurations c = (m, θ, s) rather than techniques alone, but doing so enlarges the search space. Hence, F̂ must be accurate across shot budgets, not merely across techniques; how to calibrate it over that larger space at a tractable profiling cost is an open question. Second, resources may not have a common price. Reducing cost(c) to a scalar requires an exchange rate among QPUseconds, CPU-seconds, and memory, and that rate decides whether PEC is selected. No amount of profiling supplies the number—it is a valuation, not a measurement—so it has to come from deployment policy. What that policy should be on a shared system whose users value the two resources differently, and whether one rate can serve them at all, remains open. Third, composition is excluded. The configuration c⋆ returned by Section IV-C commits to a single technique, whereas deployed mitigation is often layered. Layering breaks the machinery the stage depends on: the profiler records cost per technique in isolation, and neither the cost r̂ of a stack nor its fidelity is known to follow from those of its parts, so a calibrated model does not extend to the composed space, which is combinatorially larger than the single-technique space C. How to predict a stack from its components, or profile stacks directly at feasible cost, is unresolved. Selection is therefore a fundamental runtime responsibility, not merely a response to immature hardware: sampling overhead for a broad class of QEM protocols grows exponentially with circuit depth [52], so no engineering effort removes the need to choose what to run under a fixed budget.

The computation result is not observable at runtime. The fidelity constraint cannot be measured on the production job: its expectation value is unknown by definition. Mirror circuits provide an obvious proxy: appending U † produces a circuit with a known noise-free output (Section V), enabling fidelityconstrained optimization across configurations. However, the probe is a different, roughly twice-as-deep circuit with a different observable, and QEM performance is observabledependent. It also obscures workload-specific techniques: U U † destroys the chemistry structure exploited by methods such as SQD [1]. Moreover, each probe incurs full QPU cost, leaving its return on investment an open question. Optimizations improve as the profiler collects data. Every completed job records its configuration, device state, achieved fidelity, and cost. Thus, decision-making across pipeline stages gains supporting data as workloads accumulate, while the same records enable fair comparison of competing policies under identical workloads, hardware states, and budgets, rather than the anecdotal comparisons common in prior work [48]. VII. O PEN P ROBLEMS LLQM provides the substrate for continuously profiling quantum-classical pipelines to inform three decisions: layout selection, QEM technique and configuration, and quantumclassical resource provisioning. However, making optimal decisions remains challenging. In this section, we discuss these challenges, which are fundamental to any system making these decisions, and are essential for efficient pipeline execution.

Resource provisioning. First, executors differ in observability. As noted in Section IV-A, host-side counters (e.g., queue delays) can be inaccessible outside cloud providers. The partial observability limits provisioning decisions, and how to provision effectively with incomplete executor state remains an open problem. Second, the profiler starts cold. Cost models rely on task records that accumulate over time (Section IV-E), yet the short profiling window in Section IV-A presumes sufficient history. New deployments, backends, or portfolio techniques therefore keep the gap open. How to make reliable decisions before sufficient history exists, and how to bound the cost of those early decisions, remain open.

Qubit layout selection. First, no mapping algorithm is known to be best a priori. Many exist, and LLQM maintains a portfolio (Section IV-B), but its static scores rank their output layouts, not the algorithms. These scores serve only as an inexpensive filter for clearly poor candidates. Which algorithm is best for a circuit remains unknown until its layout is evaluated on the device state at execution. Even that measurement may not transfer to the next job if the device has since drifted. Second, drift can outpace reconfiguration. Before submission, LLQM re-scores a queued task against a fresh snapshot and reconfigures it if its committed layout no longer meets Fmin (Section IV-E). If reconfiguration takes longer than the snapshot’s validity, the task can livelock, repeatedly consuming classical budget without reaching the executor. Avoiding livelock requires choosing among three costly outcomes: submitting with a stale layout, accepting a lowerranked one, or failing the job. Unlike time or memory, fidelity cannot be traded away (Section VI). Detecting this condition is itself an open problem: the profiler does not yet measure the calibration-decay timescales needed to distinguish persistent rapid drift from an unlucky sequence of reconfigurations.

VIII. R ELATED W ORK Resource orchestration. Prior work [23, 24, 25, 26, 27] orchestrates heterogeneous devices, treating QPUs as manageable resources alongside CPUs and GPUs. For example, QFw provides HPC-aware orchestration and distributed simulation [24]; QRMI makes QPUs schedulable alongside CPUs and GPUs in workload managers [25]. These frameworks execute a specific configuration whose QEM technique, qubit layout, and shot budget are already chosen. LLQM enables dynamic optimizations by profiling the primitives these frameworks build on, while using them as the execution layer.

QEM selection. First, shots and technique cannot be optimized independently. The rank order of techniques changes with the shot budget [50]; ZNE crosses a finite-shot boundary

9

TABLE III: Comparing LLQM with other quantum frameworks. ◦: partial support, e.g., overly coarse granularity, static compute, or no feedback loop. Notation: accounting unit (G), continuous phase-level profiling (P), hardware-aware qubit selection (L), QEM selection (M), adaptation to dynamic hardware (D), fidelityaware optimization (F), and joint quantum-classical optimization (J). Approach

G

P

L

M

D

F

J

Resource orchestration QFw [24], XACC [23] Pilot-Quantum [27] QRMI [25], MQSS [26]

Job Task Job

✗ ◦ ✗

✗ ✗ ◦

✗ ✗ ✗

✗ ✗ ◦

✗ ✗ ✗

◦ ◦ ◦

Multi-programming QOS [21] HyperQ [22], [57]

Circuit Circuit

✗ ✗

✓ ◦

Fixed ✗

◦ ✗

✓ ◦

✗ ✗

Scheduling SCIM MILQ [28, 29] Qurator [30] Fluence [31], [58] Co-exec [53, 54, 55, 56]

Circuit Task Job Job

✗ ✗ ◦ ✗

◦ ◦ ✗ ✗

✗ ✗ ✗ ✗

✗ ◦ ✗ ✗

◦ ✓ ✗ ✗

✗ ◦ ◦ ◦

Characterization Mini-apps [59] Perf. model [60] QFC [61], [45]

Task Workflow Circuit

◦ ◦ ✗

✗ ✗ ✗

✗ ✗ ✗

✗ ✗ ✗

✗ ✗ ◦

◦ ◦ ✗

Configuration Noise-aware [42, 43, 44] QuanTEM [62] ML-QEM [63], [64]

Circuit Circuit Circuit

✗ ✗ ✗

✓ ✗ ✗

✗ Selected Selected

◦ ✗ ✓

◦ ◦ ✓

✗ ✗ ✗

LLQM

Task

✓

✓

Selected

✓

✓

✓

Multi-programming. Prior work [21, 22] improves QPU utilization by sharing a single QPU across multiple programs. QOS [21] jointly optimizes circuits, error mitigation, multi-programming, and spatio-temporal multiplexing, while HyperQ [22] provides virtual-machine isolation for multiplexed programs. Both apply mitigation uniformly rather than selecting it under a budget, and neither accounts for the classical resources that mitigation consumes. LLQM instead makes this cost explicit; its stage interface can compose with multiplexing, but multiplexing trades fidelity for utilization, which LLQM’s constraint semantics disallow (Section VI). Scheduling. Existing schedulers optimize when and where jobs run to keep quantum and classical resources utilized. For example, SCIM MILQ minimizes makespan while reducing noise [28], QuMod does so across modular QPUs [29], Qurator ranks quantum DAGs using calibration-derived success scores [30], and Fluence addresses the two-queue problem [31]. Other systems expose QPUs to conventional schedulers without scoring work [53, 54, 55, 56]. Where fidelity enters, it is a static pre-submission score, and none accounts for the classical cost of the chosen mitigation. LLQM complements rather than replaces these schedulers: it decides what a job is before queuing, while the scheduler decides when it runs using measured quantum and classical costs. Characterization. Prior work measures quantum-classical execution costs under specific configurations. Quantum miniapps [59] benchmark quantum-HPC tasks; a workflow-level performance model [60] predicts hybrid runtime. Recent work

10

proposes to measure fidelity per cost [61] and shows that cost-aware backend ranking differs from fidelity-only ranking across 12 cloud QPUs. A controlled study [45] finds noiseadaptive transpilation barely outperforms randomized mapping. The last two studies are offline, per-circuit comparisons. LLQM builds on this work with per-phase, continuous characterization that feeds directly into configuration decisions. Configuration. Existing work decides configurations of components independently. Qubit-selection methods use reliability, variation, or just-in-time re-characterization [42, 43, 44], while QEM methods select codes, learned surrogates, or online policies under drift [62, 63, 64]. Each is a policy, and none couples its choice to the layout it runs on or to the classical budget it spends. LLQM does not replace any configuration technique; instead, it defines the interface through which such a policy plugs in, jointly accounts for layout and classical budget, and records per-job outcomes to compare policies under identical workloads, hardware states, and budgets. Summary. Table III positions LLQM in the related work. Overall, no existing framework pairs a sub-circuit accounting unit with continuous profiling, and none feeds that measurement back into the technique, layout, and shot-budget decisions jointly, under quantum and classical budgets, against a device that drifts between decision and execution. IX. C ONCLUSION AND F UTURE W ORK Treating a quantum job as a black box obscures where fidelity and quantum-classical resources are actually lost. Looking inside reveals a deeper systems challenge: these pipelines are tightly coupled, so a local decision can reshape costs and outcomes globally; each stage is internally heterogeneous, with phases that demand fundamentally different resources; and the underlying hardware drifts, turning every optimization decision into a non-stationary one. LLQM addresses these challenges by decomposing jobs into typed tasks and continuously profiling them against the calibration state under which they execute. In doing so, it shifts quantum pipeline optimization from treating the workflow as a fixed recipe to a measurable, evolving system. More broadly, it suggests that as quantum applications become more sophisticated, the boundary between quantum algorithm design and systems optimization will become increasingly difficult to draw. Future work follows Section VII toward a broader vision of autonomous quantum systems. Decision-making should move out of the user’s hands: techniques, configurations, and layouts should be inferred from the circuit and its constraints, so that effective quantum computing does not depend on knowing the intricacies of every mitigation technique or device. This intelligence should be separated from any particular backend. As quantum technologies and provider stacks diverge, we need abstractions that allow optimization policies to be learned once and executed across heterogeneous machines rather than rebuilt for each backend. Finally, the system must evolve with the hardware itself. Continuous profiling is only a first step toward operating in a world where device characteristics, software stacks, and workloads all change. Fault-tolerant quantum

computing will make this challenge even more pronounced: decoding will introduce latency-sensitive classical computation into the quantum loop, with resource demands and realtime deadlines of its own. The long-term question, then, is not simply how to optimize a quantum circuit, but how to build systems that can continuously understand, adapt, and optimize an evolving quantum-classical computation without requiring humans to anticipate every interaction.

A. Del Toro Barba, S. Demura, A. Dunsworth, D. Eppens, C. Erickson, L. Faoro, E. Farhi, R. Fatemi, V. S. Ferreira, L. F. Burgos, E. Forati, A. G. Fowler, B. Foxen, W. Giang, C. Gidney, D. Gilboa, M. Giustina, R. Gosula, A. G. Dau, J. A. Gross, S. Habegger, M. C. Hamilton, M. Hansen, M. P. Harrigan, S. D. Harrington, P. Heu, J. Hilton, M. R. Hoffmann, T. Huang, A. Huff, W. J. Huggins, L. B. Ioffe, S. V. Isakov, J. Iveland, E. Jeffrey, Z. Jiang, C. Jones, P. Juhas, D. Kafri, T. Khattar, M. Khezri, M. Kieferová, S. Kim, A. Kitaev, P. V. Klimov, A. R. Klots, A. N. Korotkov, F. Kostritsa, J. M. Kreikebaum, D. Landhuis, P. Laptev, K.-M. Lau, L. Laws, J. Lee, K. W. Lee, B. J. Lester, A. T. Lill, W. Liu, A. Locharla, E. Lucero, F. D. Malone, O. Martin, J. R. McClean, T. McCourt, M. McEwen, K. C. Miao, A. Mieszala, M. Mohseni, S. Montazeri, E. Mount, R. Movassagh, W. Mruczkiewicz, O. Naaman, M. Neeley, C. Neill, A. Nersisyan, M. Newman, J. H. Ng, A. Nguyen, M. Nguyen, M. Y. Niu, T. E. O’Brien, S. Omonije, A. Petukhov, R. Potter, L. P. Pryadko, C. Quintana, C. Rocque, N. C. Rubin, N. Saei, D. Sank, K. Sankaragomathi, K. J. Satzinger, H. F. Schurkus, C. Schuster, M. J. Shearn, A. Shorter, N. Shutty, V. Shvarts, J. Skruzny, W. C. Smith, R. Somma, G. Sterling, D. Strain, M. Szalay, A. Torres, G. Vidal, B. Villalonga, C. V. Heidweiller, T. White, B. W. K. Woo, C. Xing, Z. J. Yao, P. Yeh, J. Yoo, G. Young, A. Zalcman, Y. Zhang, N. Zhu, N. Zobrist, H. Neven, S. Boixo, A. Megrant, J. Kelly, Y. Chen, V. Smelyanskiy, E.-A. Kim, I. Aleiner, P. Roushan, and Google Quantum AI and Collaborators, “Non-Abelian Braiding of Graph Vertices in a Superconducting Processor,” Nature, vol. 618, no. 7964, pp. 264–269, Jun. 2023. [8] F. Arute, K. Arya, R. Babbush, D. Bacon, J. C. Bardin, R. Barends, R. Biswas, S. Boixo, F. G. S. L. Brandao, D. A. Buell, B. Burkett, Y. Chen, Z. Chen, B. Chiaro, R. Collins, W. Courtney, A. Dunsworth, E. Farhi, B. Foxen, A. Fowler, C. Gidney, M. Giustina, R. Graff, K. Guerin, S. Habegger, M. P. Harrigan, M. J. Hartmann, A. Ho, M. Hoffmann, T. Huang, T. S. Humble, S. V. Isakov, E. Jeffrey, Z. Jiang, D. Kafri, K. Kechedzhi, J. Kelly, P. V. Klimov, S. Knysh, A. Korotkov, F. Kostritsa, D. Landhuis, M. Lindmark, E. Lucero, D. Lyakh, S. Mandrà, J. R. McClean, M. McEwen, A. Megrant, X. Mi, K. Michielsen, M. Mohseni, J. Mutus, O. Naaman, M. Neeley, C. Neill, M. Y. Niu, E. Ostby, A. Petukhov, J. C. Platt, C. Quintana, E. G. Rieffel, P. Roushan, N. C. Rubin, D. Sank, K. J. Satzinger, V. Smelyanskiy, K. J. Sung, M. D. Trevithick, A. Vainsencher, B. Villalonga, T. White, Z. J. Yao, P. Yeh, A. Zalcman, H. Neven, and J. M. Martinis, “Quantum Supremacy Using a Programmable Superconducting Processor,” Nature, vol. 574, no. 7779, pp. 505–510, Oct. 2019. [9] Y. Wu, W.-S. Bao, S. Cao, F. Chen, M.-C. Chen, X. Chen, T.-H. Chung, H. Deng, Y. Du, D. Fan, M. Gong, C. Guo, C. Guo, S. Guo, L. Han, L. Hong, H.-L. Huang, Y.-H. Huo, L. Li, N. Li, S. Li, Y. Li, F. Liang, C. Lin, J. Lin, H. Qian, D. Qiao, H. Rong, H. Su, L. Sun, L. Wang, S. Wang, D. Wu, Y. Xu, K. Yan, W. Yang, Y. Yang, Y. Ye, J. Yin, C. Ying, J. Yu, C. Zha, C. Zhang, H. Zhang, K. Zhang, Y. Zhang, H. Zhao, Y. Zhao, L. Zhou, Q. Zhu, C.-Y. Lu, C.-Z. Peng, X. Zhu, and J.-W. Pan, “Strong Quantum Computational Advantage Using a Superconducting Quantum Processor,” Phys. Rev. Lett., vol. 127, no. 18, p. 180501, Oct. 2021. [10] IBM, “IBM delivers new quantum processors, software, and algorithm breakthroughs on path to advantage and fault tolerance,” IBM Newsroom, Nov 2025. [Online]. Available: https://newsroom.ibm.com /2025-11-12-ibm-delivers-new-quantum-processors,-software,-andalgorithm-breakthroughs-on-path-to-advantage-and-fault-tolerance [11] ——, “IBM launches its most advanced quantum computers, fueling new scientific value and progress towards quantum advantage,” IBM Newsroom, Nov 2024. [Online]. Available: https://newsroom.ibm.com /2024-11-13-ibm-launches-its-most-advanced-quantum-computers,fueling-new-scientific-value-and-progress-towards-quantum-advantage [12] Google, “Meet Willow, our state-of-the-art quantum chip,” Google Blog, Dec 2024. [Online]. Available: https://blog.google/innovationand-ai/technology/research/google-willow-quantum-chip/ [13] J. Preskill, “Quantum Computing in the NISQ Era and Beyond,” Quantum, vol. 2, p. 79, Aug. 2018. [14] J. A. Montanez-Barrera, K. Michielsen, and D. E. B. Neira, “Evaluating the Performance of Quantum Processing Units at Large Width and Depth,” arXiv:2502.06471, Feb. 2025. [15] S. N. Filippov, S. Maniscalco, and G. Garcı́a-Pérez, “Scalability of Quantum Error Mitigation Techniques: From Utility to Advantage,” arXiv:2403.13542, Mar. 2024. [16] Z. Cai, R. Babbush, S. C. Benjamin, S. Endo, W. J. Huggins, Y. Li,

ACKNOWLEDGEMENT We thank the IBM Quantum Open Plan for QPU time and Richard Welp for classical infrastructure access. We acknowledge the support of the National Center for Supercomputing Applications (NCSA) and the IBM-Illinois Discovery Accelerator Institute (IIDAI). This work was funded in part by NSF CNS-2145295 and OAC-2323116. R EFERENCES [1] J. Robledo-Moreno, M. Motta, H. Haas, A. Javadi-Abhari, P. Jurcevic, W. Kirby, S. Martiel, K. Sharma, S. Sharma, T. Shirakawa, I. Sitdikov, R.-Y. Sun, K. J. Sung, M. Takita, M. C. Tran, S. Yunoki, and A. Mezzacapo, “Chemistry Beyond the Scale of Exact Diagonalization on a Quantum-Centric Supercomputer,” Science Advances, vol. 11, no. 25, Jun. 2025. [2] I. Liepuoniute, K. D. Doney, J. Robledo Moreno, J. A. Job, W. S. Friend, and G. O. Jones, “Quantum-Centric Computational Study of Methylene Singlet and Triplet States,” Journal of Chemical Theory and Computation, vol. 21, no. 10, pp. 5062–5070, May 2025. [3] J. Kenneth M. Merz, A. Shajan, D. Kaliakin, F. Liang, Y. Otsuka, T. Shirakawa, L. Broers, H. Xu, M. Tsuji, M. Sato, S. Yunoki, R. Wakizaka, Y. Kawashima, J. Doi, T. Itoko, H. Horii, T. Pellegrini, J. R. Moreno, K. J. Sung, E. Fejer, R. Walkup, S. Seelam, and M. Motta, “Crossing the 12,000-Atom Barrier with Heterogeneous Quantum-Classical Supercomputing: Quantum Chemistry of Protein-Ligand Complexes,” arXiv:2605.01138, May 2026. [4] A. Shajan, D. Kaliakin, F. Liang, T. Pellegrini, H. Doga, S. Bhowmik, S. Das, A. Mezzacapo, M. Motta, and K. M. M. Jr, “Molecular Quantum Computations on a Protein,” arXiv:2512.17130, 2026. [5] Y. Kim, A. Eddins, S. Anand, K. X. Wei, E. van den Berg, S. Rosenblatt, H. Nayfeh, Y. Wu, M. Zaletel, K. Temme, and A. Kandala, “Evidence for the Utility of Quantum Computing Before Fault Tolerance,” Nature, vol. 618, no. 7965, pp. 500–505, Jun. 2023. [6] X. Mi, M. Ippoliti, C. Quintana, A. Greene, Z. Chen, J. Gross, F. Arute, K. Arya, J. Atalaya, R. Babbush, J. C. Bardin, J. Basso, A. Bengtsson, A. Bilmes, A. Bourassa, L. Brill, M. Broughton, B. B. Buckley, D. A. Buell, B. Burkett, N. Bushnell, B. Chiaro, R. Collins, W. Courtney, D. Debroy, S. Demura, A. R. Derk, A. Dunsworth, D. Eppens, C. Erickson, E. Farhi, A. G. Fowler, B. Foxen, C. Gidney, M. Giustina, M. P. Harrigan, S. D. Harrington, J. Hilton, A. Ho, S. Hong, T. Huang, A. Huff, W. J. Huggins, L. B. Ioffe, S. V. Isakov, J. Iveland, E. Jeffrey, Z. Jiang, C. Jones, D. Kafri, T. Khattar, S. Kim, A. Kitaev, P. V. Klimov, A. N. Korotkov, F. Kostritsa, D. Landhuis, P. Laptev, J. Lee, K. Lee, A. Locharla, E. Lucero, O. Martin, J. R. McClean, T. McCourt, M. McEwen, K. C. Miao, M. Mohseni, S. Montazeri, W. Mruczkiewicz, O. Naaman, M. Neeley, C. Neill, M. Newman, M. Y. Niu, T. E. O’Brien, A. Opremcak, E. Ostby, B. Pato, A. Petukhov, N. C. Rubin, D. Sank, K. J. Satzinger, V. Shvarts, Y. Su, D. Strain, M. Szalay, M. D. Trevithick, B. Villalonga, T. White, Z. J. Yao, P. Yeh, J. Yoo, A. Zalcman, H. Neven, S. Boixo, V. Smelyanskiy, A. Megrant, J. Kelly, Y. Chen, S. L. Sondhi, R. Moessner, K. Kechedzhi, V. Khemani, and P. Roushan, “TimeCrystalline Eigenstate Order on a Quantum Processor,” Nature, vol. 601, no. 7894, pp. 531–536, Jan. 2022. [7] T. I. Andersen, Y. D. Lensky, K. Kechedzhi, I. K. Drozdov, A. Bengtsson, S. Hong, A. Morvan, X. Mi, A. Opremcak, R. Acharya, R. Allen, M. Ansmann, F. Arute, K. Arya, A. Asfaw, J. Atalaya, R. Babbush, D. Bacon, J. C. Bardin, G. Bortoli, A. Bourassa, J. Bovaird, L. Brill, M. Broughton, B. B. Buckley, D. A. Buell, T. Burger, B. Burkett, N. Bushnell, Z. Chen, B. Chiaro, D. Chik, C. Chou, J. Cogan, R. Collins, P. Conner, W. Courtney, A. L. Crook, B. Curtin, D. M. Debroy,

11

High-Performance Computing: A Perspective from the ADAC Institute,” Future Generation Computer Systems, vol. 182, p. 108487, Sep. 2026. [34] A. Shehata, P. Groszkowski, T. Naughton, M. Gopalakrishnan Meena, E. Wong, D. Claudino, R. Ferreira da Silva, and T. Beck, “Bridging Paradigms: Designing for HPC-Quantum Convergence,” Future Generation Computer Systems, vol. 174, p. 107980, 2026. [35] Pacific Northwest National Laboratory (PNNL), “Qasmbench,” GitHub Repository. [Online]. Available: https://github.com/pnnl/QASMBench [36] T. Proctor, S. Seritan, K. Rudinger, E. Nielsen, R. Blume-Kohout, and K. Young, “Scalable Randomized Benchmarking of Quantum Computers Using Mirror Circuits,” Phys. Rev. Lett., vol. 129, no. 15, p. 150502, Oct. 2022. [37] S. Bravyi, S. Sheldon, A. Kandala, D. C. Mckay, and J. M. Gambetta, “Mitigating Measurement Errors in Multiqubit Experiments,” Phys. Rev. A, vol. 103, no. 4, p. 042605, Apr. 2021. [38] A. Cross, A. Javadi-Abhari, T. Alexander, N. De Beaudrap, L. S. Bishop, S. Heidel, C. A. Ryan, P. Sivarajah, J. Smolin, J. M. Gambetta, and B. R. Johnson, “OpenQASM 3: A Broader and Deeper Quantum Assembly Language,” ACM Transactions on Quantum Computing, vol. 3, no. 3, Sep. 2022. [39] A. Javadi-Abhari, M. Treinish, K. Krsulich, C. J. Wood, J. Lishman, J. Gacon, S. Martiel, P. D. Nation, L. S. Bishop, A. W. Cross, B. R. Johnson, and J. M. Gambetta, “Quantum Computing with Qiskit,” arXiv:2405.08810, May 2024. [40] J.-S. Kim, A. McCaskey, B. Heim, M. Modani, S. Stanwyck, and T. Costa, “CUDA Quantum: The Platform for Integrated QuantumClassical Computing,” in Proceedings of the 60th Annual ACM/IEEE Design Automation Conference (DAC’25), 2025. [41] G. Li, Y. Ding, and Y. Xie, “Tackling the Qubit Mapping Problem for NISQ-Era Quantum Devices,” in Proceedings of the 24th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’19), 2019. [42] P. Murali, J. M. Baker, A. Javadi-Abhari, F. T. Chong, and M. Martonosi, “Noise-Adaptive Compiler Mappings for Noisy Intermediate-Scale Quantum Computers,” in Proceedings of the 24th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’19), 2019. [43] S. S. Tannu and M. K. Qureshi, “Not All Qubits Are Created Equal: A Case for Variability-Aware Policies for NISQ-Era Quantum Computers,” in Proceedings of the 24th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS’19), 2019. [44] E. Wilson, S. Singh, and F. Mueller, “Just-in-Time Quantum Circuit Transpilation Reduces Noise,” arXiv:2005.12820, May 2020. [45] Y. Huo, J. Wei, C. Kverne, M. Akewar, J. Bhimani, and T. Patel, “Revisiting Noise-Adaptive Transpilation in Quantum Computing: How Much Impact Does It Have?” arXiv:2507.01195, Jul. 2025. [46] A. Eddins, C. Johnson, A. Baiardi, F. Tacchino, E. van den Berg, R. Elkabetz, V. Tripathi, S. Majumder, M. Rossmannek, L. Shirizly, and A. Kandala, “Computing Noise-Canceling Observables via Pauli Propagation,” arXiv:2606.20441, Jun. 2026. [47] S. Majumder, J. R. Garrison, L. Luo, B. Mitchell, M. Amico, A. Seif, M. Tran, K. Sharma, E. van den Berg, Z. Minev, and L. C. G. Govia, “Quantum Enhanced Pauli Propagation,” arXiv:2603.14485, Mar. 2026. [48] N. Stemen, P. Gokhale, R. LaRose, A. Mari, P. P. Orth, G. Quiroz, M. Wahl, W. Zeng, and N. Shammah, “Report on the 2025 workshop on error resilience in quantum computing (WERQSHOP),” Unitary Foundation, Tech. Rep., Sep 2025. [Online]. Available: https://unitary.foundation/assets/WERQSHOP report.pdf [49] Linux Programmer’s Manual, “perf(1) - linux manual page,” man7.org. [Online]. Available: https://man7.org/linux/man-pages/man1/perf.1.html [50] D. Bultrini, M. H. Gordon, P. Czarnik, A. Arrasmith, M. Cerezo, P. J. Coles, and L. Cincio, “Unifying and Benchmarking State-of-the-Art Quantum Error Mitigation Techniques,” Quantum, vol. 7, p. 1034, Jun. 2023. [51] V. S. Alfaro, “The Finite-Shot Help-Harm Boundary of Zero-Noise Extrapolation,” arXiv:2605.08251, May 2026. [52] R. Takagi, H. Tajima, and M. Gu, “Universal Sampling Lower Bounds for Quantum Error Mitigation,” Phys. Rev. Lett., vol. 131, no. 21, p. 210602, Nov. 2023. [53] A. Esposito and U.-U. Haus, “SLURM Heterogeneous Jobs for Hybrid Classical-Quantum Workflows,” arXiv:2506.03846, Jun. 2025.

J. R. McClean, and T. E. O’Brien, “Quantum Error Mitigation,” Rev. Mod. Phys., vol. 95, no. 4, p. 045005, Dec. 2023. [17] K. Temme, S. Bravyi, and J. M. Gambetta, “Error Mitigation for ShortDepth Quantum Circuits,” Phys. Rev. Lett., vol. 119, no. 18, p. 180509, Nov. 2017. [18] E. van den Berg, Z. K. Minev, A. Kandala, and K. Temme, “Probabilistic Error Cancellation with Sparse Pauli–Lindblad Models on Noisy Quantum Processors,” Nature Physics, vol. 19, no. 8, pp. 1116–1121, Aug. 2023. [19] S. Endo, S. C. Benjamin, and Y. Li, “Practical Quantum Error Mitigation for Near-Future Applications,” Phys. Rev. X, vol. 8, no. 3, p. 031027, Jul. 2018. [20] T. Proctor, M. Revelle, E. Nielsen, K. Rudinger, D. Lobser, P. Maunz, R. Blume-Kohout, and K. Young, “Detecting and Tracking Drift in Quantum Information Processors,” Nature Communications, vol. 11, no. 1, p. 5396, Oct. 2020. [21] E. Giortamis, F. Romão, N. Tornow, and P. Bhatotia, “QOS: Quantum Operating System,” in Proceedings of the 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI’25), Jul. 2025. [22] R. Tao, H. Zhu, J. Nieh, J. Yao, and R. Gu, “Quantum Virtual Machines,” in Proceedings of the 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI’25), Jul. 2025. [23] A. J. McCaskey, D. I. Lyakh, E. F. Dumitrescu, S. S. Powers, and T. S. Humble, “XACC: A System-Level Software Infrastructure for Heterogeneous Quantum-Classical Computing,” arXiv:1911.02452, Nov. 2019. [24] S. Chundury, A. Shehata, S. Kim, M. Gopalakrishnan Meena, C. Lu, K. Gottiparthi, E. A. C. Perez, F. Mueller, and I.-S. Suh, “Scaling Hybrid Quantum–HPC Applications with the Quantum Framework,” in Proceedings of the SC’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis (SC Workshops’25), 2025. [25] T. Badts, T. Boyle, C. Carvalho, A. Córcoles, A. Damin, V. Elisseev, J. Frassineti, D. Gruber, H. Horii, E.-K. Lee, J. Machin, S. Marzella, M. Meller, D. Milroy, M. Moreau, M. Ohtani, E. Ortega-Carrasco, D. Oucharek, Y. Park, A. Patil, E. M. Sahin, G. Samu, S. Seelam, A. Shehata, V. Sochat, J. Thorne, O. Wallis, and A. Wennersteen, “Examining QRMI as a Unified Interface for Quantum-HPC Integration,” arXiv:2607.19591, Jul. 2026. [26] L. Burgholzer, J. Echavarria, P. Hopf, Y. Stade, D. Rovara, L. Schmid, E. Kaya, B. Mete, M. N. Farooqi, M. Chung, M. De Pascale, L. Schulz, M. Schulz, and R. Wille, “The Munich Quantum Software Stack: Connecting End Users, Integrating Diverse Quantum Technologies, Accelerating HPC,” in Proceedings of the Supercomputing Asia and International Conference on High Performance Computing in Asia Pacific Region (SCA/HPCAsia’26), 2026. [27] P. Mantha, F. J. Kiwit, N. Saurabh, S. Jha, and A. Luckow, “PilotQuantum: A Middleware for Quantum-HPC Resource, Workload and Task Management,” in Proceedings of the IEEE 25th International Symposium on Cluster, Cloud and Internet Computing (CCGRID’25), May 2025. [28] P. Seitz, M. Geiger, C. Ufrecht, A. Plinge, C. Mutschler, D. D. Scherer, and C. B. Mendl, “SCIM MILQ: An HPC Quantum Scheduler,” in Proceedings of the 5th IEEE International Conference on Quantum Computing and Engineering (QCE’24), Sep. 2024. [29] V. Kulkarni, A. Orenstein, X. Li, S. Xu, D. Blankenberg, and V. Chaudhary, “QuMod: Parallel Quantum Job Scheduling on Modular QPUs Using Circuit Cutting,” arXiv:2604.11013, Apr. 2026. [30] S. Pehlivanoglu, U. de Muelenaere, P. Kogge, and A. Sabry, “Qurator: Scheduling Hybrid Quantum-Classical Workflows Across Heterogeneous Cloud Providers,” arXiv:2604.05505, Apr. 2026. [31] V. Sochat and D. Milroy, “Hybrid Quantum and Classical Workload Management with Graph-Based Scheduling,” arXiv:2607.09151, Jul. 2026. [32] S. Seelam, J. M. Chow, A. Córcoles, S. Sheldon, T. Mittal, A. Kandala, S. Dague, I. Hincks, H. Horii, B. Johnson, M. Le, H. Jamjoom, and J. M. Gambetta, “Reference Architecture of a Quantum-Centric Supercomputer,” arXiv:2603.10970, Mar. 2026. [33] G. Buchs, T. L. Beck, R. S. Bennink, D. Claudino, A. Delgado, N. A. Fadel, P. Groszkowski, K. E. Hamilton, T. S. Humble, N. Kumar, A. Li, P. C. Lotshaw, O. Mukkula, R. Takano, A. Saxena, I.-S. Suh, M. Tsuji, R. Van Beeumen, U. Varetto, Y. Wang, K. Yamazaki, and M. P. Johansson, “The Role of Quantum Computing in Advancing Scientific

12

[54] A. Mahesh, S. Mittal, and F. Mueller, “CONQURE: A Co-Execution Environment for Quantum and Classical Resources,” arXiv:2505.02241, 2026. [55] G. Ni, D. Ferrari, L. Ho, and M. Amoretti, “Advanced Scheduling Strategies for Distributed Quantum Computing Jobs,” arXiv:2602.24152, Feb. 2026. [56] A. Younesi, N. Innan, A. Marchisio, and M. Shafique, “EFaaS: A Quantum-Classical Serverless Entangled Scheduler for Hybrid Variational Algorithms,” arXiv:2605.27540, May 2026. [57] N. Tornow, E. Giortamis, and P. Bhatotia, “QVM: Quantum Gate Virtualization Machine,” Proc. ACM Program. Lang., vol. 9, no. PLDI, Jun. 2025. [58] M. Cipollini, S. Rizzo, S. Iserte, P. Viviani, G. Vitali, M. Barbieri, G. Bettonte, E. Boella, F. Ganz, R. Rocco, O. Spina, A. J. Peña, P. Sandås, I. Colonnelli, A. Scionti, C. Vercellino, E. Dri, J. Frassineti, S. Marzella, A. Muratori, D. Ottaviani, O. Terzo, B. Montrucchio, and D. Gregori, “Three Ways to Share a QPU: Scheduling Strategies for Hybrid Quantum-HPC Applications,” arXiv:2604.14955, Apr. 2026. [59] N. Saurabh, P. Mantha, F. J. Kiwit, S. Jha, and A. Luckow, “Quantum Mini-Apps: A Framework for Developing and Benchmarking QuantumHPC Applications,” in Proceedings of the 2024 Workshop on High Performance and Quantum Computing Integration (HPQCI’24), 2024. [60] P. Rao, D. Trenev, J. Gonthier, T. Patti, S. Stern, T. Takeshita, Y. Alexeev, C. Lin, S. McArdle, J. Lietz, K. Klymko, E. Rrapaj, N. Tubman, K. Svore, P. Komar, and E. Kyoseva, “Performance Model for Hybrid Quantum-Classical Workflows,” arXiv:2607.15426, Jul. 2026. [61] S. Shinde and J. Szefer, “Quantum Fidelity-per-Cost: A Metric for Evaluation of Quantum Computing Systems,” arXiv:2607.28572, Jul. 2026. [62] J. Liu, Q. Langfitt, M. J. Jeng, A. Gonzales, N. Agyeman-Bobie, K. J. S. Vijaymurugan, D. Dilley, Z. H. Saleem, N. Hardavellas, and K. N. Smith, “QuantEM: The Quantum Error Management Compiler,” arXiv:2509.15505, Sep. 2025. [63] H. Liao, D. S. Wang, I. Sitdikov, C. Salcedo, A. Seif, and Z. K. Minev, “Machine Learning for Practical Quantum Error Mitigation,” Nature Machine Intelligence, vol. 6, no. 12, pp. 1478–1486, Dec. 2024. [64] S. Szachara, S. Rajakrishnan, D. J. V. Allen, J. Pollack, T. Desell, and D. Krutz, “GSC-QEMit: A Telemetry-Driven Hierarchical Forecast-and-Bandit Framework for Adaptive Quantum Error Mitigation,” arXiv:2604.24551, Apr. 2026.

13

Related documents

• A Dynamic Intermediate Representation for Hybrid Quantum-Classical Programs#821025
• Towards Continuous Profiling and Optimization of Quantum-Classical Pipelines#1043167
• Towards Continuous Profiling and Optimization of Quantum-Classical Pipelines#999308
• Automated Quantum Software and AI Engineering#124121
• Scalable Benchmarking Framework for Dynamic Quantum Circuits#1123062