Source-linked AI summary
Towards Continuous Profiling and Optimization of Quantum-Classical Pipelines
Ayush Bansal, Owen Cochell, Santiago Núñez-Corrales, Marcos Frenkel, Seetharami Seelam, Apoorve Mohan, Tianyin Xu
TL;DR
Quantum-classical pipelines combine stages with different resource demands, while QEM decisions interact with workload characteristics and changing hardware states. LLQM decomposes pipelines into fine-grained tasks for continuous profiling; its QEM characterization exposes workload- and hardware-dependent resource and fidelity behavior, including polling that occupies up to 92% of wall-time.
Problem
QEM optimization depends jointly on workload characteristics, classical resources, and evolving hardware state, while existing frameworks provide limited visibility into interactions among pipeline stages and hardware.
Source: §I · p. 1Method
LLQM decomposes quantum-classical applications into fine-grained typed tasks and profiles their resource behavior against calibration snapshots, updating telemetry within and across jobs.
Source: §I · p. 2Results
LLQM’s QEM characterization exposed workload-, hardware-, and technique-dependent resource and fidelity behavior, including up to 92% of wall-time spent polling while waiting on the device.
Source: §I · pp. 1–2Takeaways & Limitations
LLQM shifts pipeline optimization from a fixed workflow recipe toward a measurable system profiled as hardware states evolve.
Source: §IX · p. 10Mirror-circuit fidelity proxies use a roughly twice-as-deep circuit with a different observable, and QEM performance is observable-dependent.
Source: §VI · p. 9
Abstract
from arXiv · showhide
Quantum applications increasingly execute as multi-stage quantum-classical pipelines, interleaving QPU computation with classical stages like circuit generation, transpilation, layout mapping, quantum error mitigation (QEM), and post-processing. These stages have diverse resource requirements and exhibit stochastic behavior under drifting hardware noises, 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 1e7 transpiled gates. Our results show that continuous profiling exposes runtime bottlenecks and enables hardware-, fidelity-, and workload-aware optimizations.
I. INTRODUCTION
Quantum-classical pipelines couple resource-diverse stages to drifting QPU states, while existing frameworks provide limited visibility into interactions among stages, resources, and hardware. LLQM introduces continuous task-level profiling, and its QEM characterization exposes substantial runtime, resource, and fidelity variation.
I. INTRODUCTION
- QPU error rates drift on minute timescales, making calibration snapshots and one-time workload characterizations potentially stale before queued jobs execute.The resource cost of recovering fidelity also depends on the noise that must be canceled.Source: §I · p. 1
- Existing pipeline frameworks provide limited visibility into stage interactions, while mapping, QEM selection, and resource provisioning are often decided independently or statically despite their coupling.The coupling affects both execution fidelity and resource consumption.Source: §I · p. 1
- QEM techniques differ by orders of magnitude in classical compute and memory demand, and mitigation phases can be memory-bound or compute-bound, so average utilization is inadequate.The passage describes heterogeneous resource demands within a single mitigation run.Source: §I · p. 1
- QEM profiling found up to 92% of wall-time spent polling, mitigation 25–290× longer than quantum execution, >50% same-circuit fidelity swings, and layout-driven near-zero fidelity or 1.8× QPU time.These observations show that QEM technique and qubit layout can substantially change resource use and fidelity.Source: §I · pp. 1–2
- LLQM decomposes applications into fine-grained typed tasks and continuously profiles their resource behavior against calibration snapshots, with feedback loops within and across jobs.Task-level records attribute resource profiles to a stage, technique, and circuit rather than averaging them across a job.Source: §I · p. 2
- LLQM provides common interfaces for hardware-aware qubit mapping, QEM selection, and classical resource provisioning, taking fidelity targets and resource budgets as inputs without prescribing decision policies.The framework supports implementing and comparing policies on identical workloads, hardware states, and budgets.Source: §I · p. 2
II. MOTIVATION
QEM fidelity and resource costs depend on the mitigation technique, hardware state, and physical-qubit layout. The case studies show sharply different classical phase demands and substantial QPU waiting, motivating profiling across the full pipeline.
II. MOTIVATION
- Configured ZNE gains fidelity across VQE and Ising circuits, whereas PEC degrades fidelity on bigger Ising workloads such as ising_n10.The outcome varies with circuit width, gate count, algorithm family, and configuration.Source: §II · p. 2
- On slightly degraded hardware, PEC fidelity is 0.500 versus 0.628 for REM on vqe_n4, showing that hardware state changes technique performance.PEC can fully cancel noise bias but consume 25–290× more total execution time than ZNE for the same circuit.Source: §II · p. 3
- 0.910 to near zero: degraded-qubit mapping collapses ZNE fidelity, while PEC reaches 0.891 at 1.8× QPU time (278s to 498s).The comparison is for a 4-qubit state-preparation circuit.Source: Figure 3 · p. 3, §II · p. 3
- On degraded qubits, PEC’s higher sampling overhead increases QPU execution time, while ZNE’s fidelity collapses.The figure compares fidelity and QPU time for a 4-qubit circuit; the QPU-time y-axis changes between the two plots.Source: Figure 3 · p. 3, §II · p. 3
- QPU execution/queuing stalls classical host CPUs in polling loops, accounting for 92% of total wall-time at low IPC (≈31%); PEC representation generation is memory-bound and sampling is compute-bound.PEC is much more resource-hungry than ZNE; PEC classical phases move substantial DRAM traffic, whereas ZNE’s are negligible.Source: §II · p. 3, Figure 2 · p. 3
III. OVERVIEW
LLQM is a profiling-driven framework that decomposes quantum-classical jobs into typed tasks and uses live task and hardware telemetry to adjust pipeline decisions. It accepts fidelity and resource constraints and feeds execution outcomes back into later decisions.
III. OVERVIEW
- LLQM takes target fidelity and resource budgets as inputs, while dynamically tuning stages to workload structure and execution-time device noise.The budgets include quantum time, classical compute, memory, and shot-count caps.Source: §III · pp. 3–4
- LLQM provides a common profiling substrate and interfaces for optimization rather than prescribing the policy behind each decision.Its current implementation focuses on qubit layout and QEM technique and configuration.Source: §III · pp. 3–4, Figure 4 · p. 4
- LLQM profiles individual tasks across classical nodes and QPUs, monitors calibration drift, and dynamically adjusts QEM configurations, layout mappings, and schedules.Fidelity verdicts feed decisions within a job, while completed-task statistics calibrate the cost model for later jobs.Source: §III · p. 4
- Jobs pass through five stages: workload classification, pre-processing, job queuing, execution, and post-processing.The workflow checks constraints, selects a backend, layout, and QEM configuration, queues typed sub-jobs, executes them, then evaluates fidelity and may resubmit with more shots or restart.Source: §III · pp. 4–5
A. Profiling Substrate
LLQM uses independent, typed tasks as units of measurement and builds cost models from their profiles. The model estimates quantum time, classical time, and peak memory while accounting for configuration-dependent memory and partial opacity of cloud execution.
A. Profiling Substrate
- Each task is an independent atomic CPU, GPU, or QPU operation whose resource record captures one phase of one technique on one circuit.The task graph connects operations through inputs and outputs and ends in a single terminal task that returns the job result.Source: A. Profiling Substrate · p. 5
- Short profiling windows calibrate a model that predicts quantum time, classical time, and peak memory for a candidate configuration, program features, layout, and device calibration state.The model is represented as r̂(c | P, L, Bt) = (tq, tc, µ).Source: A. Profiling Substrate · p. 5
- Cloud tasks expose queue wait, execution time, and shots consumed, but not provider-side host counters; PEC memory also grows with sampled circuits.The memory qualification makes memory a first-class budget, while host-counter opacity does not apply to local backends and simulators.Source: A. Profiling Substrate · p. 5
B. Qubit-Layout Selection
LLQM selects a qubit layout against the program and device snapshot, then chooses a QEM configuration that satisfies fidelity and resource constraints at minimum cost.
B. Qubit-Layout Selection
- The committed layout sets the run’s starting fidelity and determines which QEM configurations are feasible, so LLQM selects it before choosing mitigation.Layout selection uses the device snapshot and program structure.Source: B. Qubit-Layout Selection · p. 5
- CWA weights qubit and coupler error rates by how often the layout uses them, so rarely used poor qubits do not dominate the score.It also avoids hiding a medium-quality qubit on the critical path among good but idle neighbors.Source: B. Qubit-Layout Selection · p. 5
- ESP estimates the probability of error-free execution, but falls sharply with circuit depth; CWA remains comparable across depths but omits compounding error.Neither metric is meaningful absolutely; both rank layouts only for the same circuit.Source: B. Qubit-Layout Selection · p. 5
- LLQM scores layouts from a pluggable mapping portfolio and retains non-noise-aware baselines because noise-aware mapping may add classical cost without fidelity benefit.The framework returns the best candidate meeting user constraints, or reports failure if the portfolio is exhausted.Source: B. Qubit-Layout Selection · p. 5
C. QEM Selection
- LLQM chooses the cheapest QEM configuration whose predicted fidelity meets the user’s target and whose predicted resource use fits the budgets.Fidelity is a requirement, not a quantity to maximize, because excess QPU use is a cost to other jobs.Source: C. QEM Selection · p. 6
- The QEM portfolio includes no mitigation, REM, ZNE, and PEC, and remains open to techniques that provide parameters, a calibrated cost model, and an estimator.No mitigation is a valid option because some mitigated configurations can have lower fidelity than the baseline.Source: C. QEM Selection · p. 6
- A sound fidelity predictor remains unavailable, although LLQM collects workload and real-time noise information and calibrates the cost vector.QEM effectiveness remains empirical and problem-specific, with few guidelines for choosing a technique.Source: C. QEM Selection · p. 6
D. Resource Provisioning
LLQM uses per-task profiles and predicted costs to allocate resources and schedule ready work across jobs, then closes the loop through device checks and job feedback.
D. Resource Provisioning
- Per-task intensity profiles distinguish memory-bound PEC representation generation, compute-bound sampling, and QPU execution that uses no classical work but pins memory.These distinctions inform classical resource provisioning.Source: D. Resource Provisioning · p. 6
- LLQM chooses CPU/GPU placement and core/memory allocation per task, while globally scheduling ready tasks across jobs to use otherwise stalled capacity.The scheduler respects dependency order and uses task graphs, constraints, cost predictions, live hardware state, and profiler records.Source: D. Resource Provisioning · p. 6
E. Closing the Loop
- Before submission, LLQM rereads the device snapshot and reconfigures or fails a task if drift makes its layout miss the fidelity target.The gate cannot catch drift after submission; long PEC campaigns can outlast the learned noise model, and the profiler does not measure calibration-decay timescales.Source: E. Closing the Loop · p. 6
- A unified backend interface returns consistent execution records across cloud providers, local QPUs, and simulators.Records include result type, measurements, achieved fidelity, shots, and time consumed.Source: E. Closing the Loop · p. 6
- After completion, LLQM checks results against constraints and may resubmit, revisit decisions, or fail; each run also records achieved fidelity and true resource cost.LLQM does not learn the missing fidelity predictor, but job outcomes accumulate data that could supervise it.Source: E. Closing the Loop · p. 6
V. PRELIMINARY RESULTS
Preliminary experiments across diverse circuits reinforce that QEM configuration cannot be chosen statically. The setup benchmarks circuits on IBM Heron r2 processors and profiles mitigation work under a single-host configuration.
V. PRELIMINARY RESULTS
- The preliminary results across diverse circuits reinforce that the right QEM configuration cannot be chosen statically.The experiments extend earlier motivating studies across circuits, though the passage characterizes these results as preliminary.Source: §V · p. 6
A. Setup
- The benchmark spans OpenQASM-2 VQE, UCCSD-VQE, Ising, and Trotter circuits up to about 100 qubits and 10^7 transpiled gates.Transpiled counts are reported because the mapped circuit, rather than the logical circuit, runs on the QPU.Source: A. Setup · p. 6, Table II · p. 7
- Quantum runs used IBM 156-qubit Heron r2 processors, while classical mitigation phases ran single-threaded on one Xeon core to establish per-task costs before parallelization.Fidelity was evaluated with mirror circuits whose ideal output is all zeros; the observable’s ideal value is +1.Source: A. Setup · pp. 6–7
B. Results and Observations
QEM results vary substantially by mitigation technique and circuit conditions, while transpiled gate count tracks cost and fidelity better than qubit count. PEC can impose high classical costs and fail when its noise model becomes stale during long sampling.
B. Results and Observations
- ZNE improves fidelity by +0.10 to +0.55, REM is near-neutral and occasionally negative, and PEC reaches 0.00 on every larger circuit it ran on.PEC improves the two smallest circuits; Fig. 5 reports fidelity change relative to the unmitigated baseline.Source: B. Results and Observations · p. 7, Figure 5 · p. 7
- PEC circuit sampling reaches ∼1.3 × 10^4 s, or 25–290× the ZNE cost for the same circuit, with execution time overwhelmingly dominated by CPU work.The reported classical times are single-threaded per-task costs; sampled circuits are mutually independent and could be parallelized across spare cores.Source: B. Results and Observations · p. 7, Figure 6 · p. 8
- On large, higher-fault circuits, PEC’s raw estimator diverges outside [0, 2], while hours of sampling can let hardware drift invalidate its learned noise model.The generated samples then no longer cancel the true noise, collapsing fidelity.Source: B. Results and Observations · p. 8, Figure 7 · p. 8
- Transpiled gate count predicts cost and fidelity better than qubit count; the 4-qubit basis_trotter_n4 takes longer and reaches lower fidelity than the 98-qubit ising_n98.Measured QPU time follows near-monotonic trajectories by transpiled gate count, while measurements against qubit count collapse into a band with no usable trend.Source: B. Results and Observations · p. 8, Figure 8 · p. 8, Figure 9 · p. 8
VI. EXPERIENCE AND DISCUSSION
LLQM’s optimization perspective treats fidelity as a hard target rather than a resource to trade, though runtime fidelity is not directly observable. Mirror-circuit probes offer a proxy with important costs and mismatches, while accumulated profiling records support improving and fairer policy comparisons.
VI. EXPERIENCE AND DISCUSSION
- Below Fmin, a result is unusable and its resources are wasted; above Fmin, extra fidelity has no user value, so flexible resources should be spent rather than accepting insufficient fidelity.Time and memory can be traded, but fidelity is treated as a constraint rather than a currency.Source: §VI · pp. 8–9
- Mirror-circuit probes provide a known-output proxy, but use a roughly twice-as-deep circuit and different observable, and each incurs full QPU cost with return on investment unresolved.The proxy can obscure workload-specific techniques such as SQD because UU† destroys the chemistry structure those methods exploit.Source: §VI · p. 9
- As workloads accumulate, recorded configuration, device state, fidelity, and cost support pipeline decisions and fair policy comparisons under identical workloads, hardware states, and budgets.The paper states that optimization quality improves as the profiler collects data.Source: §VI · pp. 8–9
VII. OPEN PROBLEMS
LLQM’s runtime decisions remain difficult because hardware state, workload configuration, resource valuation, and available profiling history constrain what can be chosen reliably. Several decision and measurement problems remain open.
VII. OPEN PROBLEMS
- Layout algorithms cannot be ranked reliably in advance, and a device-state evaluation may not transfer to the next job after hardware drift.Static scores only filter clearly poor layouts; which algorithm is best for a circuit remains unknown until device evaluation.Source: §VII · p. 9
- Rapid drift can outpace reconfiguration, causing queued tasks to livelock while repeatedly consuming classical budget without reaching execution.The profiler does not yet measure calibration-decay timescales to distinguish persistent rapid drift from an unlucky sequence of reconfigurations.Source: §VII · p. 9
- QEM selection must search whole configurations across technique, parameters, and shot budget, but calibrating the resulting model at tractable cost remains open.Technique rankings can change with shot budget, and ZNE degrades estimates below a finite-shot boundary.Source: §VII · p. 9
- Reducing QPU-seconds, CPU-seconds, and memory to one cost requires a deployment-policy exchange rate that profiling cannot determine.The appropriate valuation for users on a shared system, and whether one rate can serve them all, remain open.Source: §VII · p. 9
- The selection model covers single techniques, not layered mitigation, whose combined cost and fidelity are not known from its components.Predicting stacks or profiling them directly at feasible cost remains unresolved.Source: §VII · p. 9
- For a broad class of QEM protocols, sampling overhead grows exponentially with circuit depth, so selection under a fixed budget remains necessary.The section frames selection as a runtime responsibility rather than merely a response to immature hardware.Source: §VII · p. 9
- Incomplete executor observability, including inaccessible host-side counters, limits resource-provisioning decisions.How to provision effectively with incomplete executor state remains open.Source: §VII · p. 9
- Cold-start decisions lack sufficient task history, especially for new deployments, backends, or portfolio techniques.Reliable choices before history accumulates, and how to bound their cost, remain open.Source: §VII · p. 9
VIII. RELATED WORK
Prior frameworks address orchestration, multiplexing, scheduling, or individual configuration choices, while LLQM adds continuous profiling to inform joint pipeline decisions. The conclusion presents this profiling as a step toward systems that adapt as hardware, software, and workloads change.
VIII. RELATED WORK
- LLQM complements orchestration frameworks by profiling the primitives they execute, enabling dynamic optimization of configurations already chosen by those frameworks.Examples include QFw’s HPC-aware orchestration and distributed simulation, and QRMI’s scheduling of QPUs alongside CPUs and GPUs.Source: §VIII · p. 9
- Multiplexing work treats mitigation uniformly, while schedulers decide when jobs run; LLQM accounts for mitigation’s classical cost and decides a job’s configuration before queuing.The related-work discussion says multiplexing can trade fidelity for utilization, which LLQM’s constraint semantics disallow.Source: §VIII · p. 10
- LLQM extends prior characterization and configuration approaches with per-phase continuous measurements that jointly account for layout and classical budget.It records per-job outcomes to compare policies under identical workloads, hardware states, and budgets; Table III frames framework comparison across profiling and optimization capabilities.Source: §VIII · p. 10, Table III · p. 10
IX. CONCLUSION AND FUTURE WORK
- Decomposing jobs into typed tasks and profiling them against their execution-time calibration state shifts optimization from a fixed recipe to a measurable, evolving system.The conclusion connects this shift to the close coupling of pipeline stages, heterogeneous phase demands, and drifting hardware.Source: §IX · p. 10
- Future work calls for backend-independent policies, automated choices from circuit constraints, and systems that evolve with changing hardware, software stacks, and workloads.The conclusion notes that fault-tolerant decoding will add latency-sensitive classical computation and real-time resource demands to the quantum loop.Source: §IX · pp. 10–11