Source-linked AI summary

TuniQ: Autotuning Compilation Passes for Quantum Workloads at Scale for Effectiveness and Efficiency

Mohammad Abrarul Hasanat, Jason Ludmir, Tirthak Patel, Rohan Basu Roy

arXiv:2605.11375v1quant-phcs.ET

TL;DR

Quantum compilers commonly apply fixed pass sequences even though effective choices vary across circuits and hardware conditions. TuniQ uses reinforcement learning to select passes across compilation stages. It improves fidelity and compilation time over IBM Qiskit, generalizes across backends, and scales to utility-scale circuits with growing advantage.

  • Problem

    Fixed pass sequences ignore that optimal pass choices vary with circuit and hardware conditions, despite the large, intractable space of possible transpilation paths.

    Source: §2 · p. 3
  • Method

    TuniQ uses reinforcement learning to select compilation passes across stages based on circuit, backend, and noise profile, with stage-aware encoders, shaped rewards, and action masking.

    Source: §1 · p. 2, §3.5 · p. 5
  • Results

    On representative benchmarks, TuniQ improves output fidelity and compilation time by average 20% and 34%, respectively, over the current state-of-the-art quantum compiler from IBM Qiskit.

    Source: §1 · p. 2
  • Takeaways & Limitations

    TuniQ generalizes across backends without retraining and scales to utility-scale circuits with growing advantage as circuits grow larger.

    Source: §1 · p. 2, §7 · p. 13

    TuniQ operates at the physical-circuit level before QEC; QEC-specific logical compilation is a separate upstream layer.

    Source: §3.6 · p. 8

Abstract

from arXiv · show

Quantum processors are being integrated into HPC ecosystems as co-processors, where compilation of quantum circuits into hardware-executable form determines both output fidelity and runtime. Current compilers use a fixed pass sequence and ignore the fact that optimal pass selection varies with circuit, hardware, and noise conditions. We present TuniQ, a reinforcement learning-based system that selects compilation passes at each pipeline stage, adapting to circuit, backend, and current noise profile. TuniQ introduces several novel design components like a dual-encoder for stage-aware representation, shaped rewards for cross-stage credit assignment, and dynamic action masking for valid compilation. Evaluated across diverse quantum workloads on multiple IBM Quantum Cloud processors, TuniQ improves fidelity and reduces compilation time over the state-of-the-art IBM Qiskit transpiler, generalizes across backends without retraining, and scales strongly to utility-scale circuits with growing advantage.

1 Introduction

Quantum compilation in HPC workflows affects circuit fidelity and compilation time, while fixed pass sequences overlook variation across circuits, backends, and noise conditions. TuniQ uses reinforcement learning to select passes across stages and improves reported benchmarks over IBM Qiskit.

1 Introduction

  • Fixed pass sequences overlook that optimal pass selection varies across circuits, backends, and noise conditions, while exhaustive search is intractable and greedy stage-wise choices can worsen end-to-end circuits.Source: §1 · pp. 1–2
  • TuniQ selects which existing compilation passes to apply at each stage based on the circuit, backend, and current noise profile, using reinforcement learning and stage-aware representations.Source: §1 · p. 2
  • On representative benchmarks, TuniQ improves output fidelity and compilation time by average 20% and 34%, respectively, over the current state-of-the-art quantum compiler from IBM Qiskit.Source: §1 · p. 2
  • TuniQ maintains effectiveness as hardware changes and noise levels improve over time.Source: §1 · p. 2
  • TuniQ scales to utility-scale circuits with growing advantage over the state-of-the-art as circuits grow larger.Source: §1 · p. 2

2 Background and Motivation of TuniQ

Quantum transpilation must balance hardware constraints, fidelity, and compilation cost across a large space of pass choices. The section shows that circuit structure, backend, and noise conditions change which pass configuration performs best.

2 Background and Motivation of TuniQ

  • Transpilation has six sequential stages, each with multiple algorithmic passes, whose choices compound to produce physical circuits of different sizes and quality.Source: §2 · p. 2
  • Selective compilation achieves substantially lower TVD than Qiskit (Fidelity Optimized) on every representative benchmark, with no single pass combination best across all benchmarks.Source: Figure 2 · p. 3, §2 · p. 3
  • TVD compares ideal and observed output distributions, while ESP uses calibration data as a lightweight pre-execution proxy that correlates with measured TVD.Source: §2 · p. 3
  • Qiskit Level 3 applies a fixed, aggressive pass set, while more than 100 passes across six stages create millions of possible paths that cannot be exhaustively explored.Source: §2 · p. 3
  • Selective compilation outperforms Qiskit (Fidelity Optimized) on all three backends, and QPE’s optimal pass subset differs across Torino, Pittsburgh, and Fez.Source: Figure 3 · p. 3, §2 · p. 3
  • As simulated noise decreases from 1.0× to 0.3×, selective compilation achieves lower TVD for Deutsch-Jozsa and the optimal pass set changes.Source: Figure 4 · p. 4, §2 · p. 4

3 System Design of TuniQ

TuniQ uses reinforcement learning to choose transpiler passes based on end-to-end circuit outcomes, targeting improved execution fidelity and reduced compilation time.

3 System Design of TuniQ

  • TuniQ frames pass selection as reinforcement learning over transpiler interactions, with rewards based on the final physical circuit’s quality.Source: §3 · p. 4

3.1 TuniQ’s Objectives

TuniQ’s objectives balance output fidelity with compilation time. It uses ESP as a training proxy for fidelity and constrains compilation time to remain competitive with Qiskit (Fidelity Optimized).

3.1 TuniQ’s Objectives

  • TuniQ targets correct output on noisy hardware, using ESP as a training proxy because evaluating TVD requires costly quantum hardware execution.Source: §3.1 · p. 4
  • TuniQ constrains compilation time to remain competitive with Qiskit (Fidelity Optimized), since slower compilation can erase fidelity gains in compilation-bound applications.Source: §3.1 · p. 4

3.2 Pass Selection Decisions

Pass selection spans six transpilation stages, where choices interact: early decisions constrain later passes, so independently optimizing stages can produce globally worse circuits.

3.2 Pass Selection Decisions

  • The pipeline offers distinct choices at init, layout, routing, translation, optimization, and cleanup, with different circuit transformations at each stage.These include logical-gate decomposition, physical-qubit mapping, connectivity routing, native-basis translation, iterative optimization, and cleanup.Source: §3.2 · p. 4
  • Passes interact across stages: layout choices constrain routing, and routing outcomes shape later optimization.On QPE for IBM Torino, independently choosing VF2L and CC yields 62% TVD, while VF2L without CC yields 51%.Source: §3.2 · p. 4

3.3 Design Requirements

The pass-selection policy must generalize across circuits and adapt to backend topology and changing noise while accounting for stage interactions, validity, and inference cost.

3.3 Design Requirements

  • The policy should generalize across circuit sizes, gate compositions, and connectivity patterns, including transfer from random circuits to algorithmic benchmarks.It should also adapt to backend topology and noise calibrations that drift over hours to days.Source: §3.3 · p. 4
  • Stage-aware choices must anticipate how early passes affect later routing and optimization, while keeping inference overhead negligible.Compilation must also produce hardware-valid sequences that preserve functional equivalence.Source: §3.3 · pp. 4–5
  • Greedy pass selection can improve intermediate metrics yet produce worse final circuits, so selection should target end-to-end quality.Table 1 identifies supervised DNN versus vanilla RL on QPE and marks lower compiled-circuit metrics as better, but the supplied passage gives no table values.Source: Figure 5 · p. 5, Table 1 · p. 5

3.4 Why Reinforcement Learning?

Fixed labels and locally optimized pass choices do not capture how circuit and noise changes alter downstream effects. Reinforcement learning learns from final compilation outcomes and improves the resulting circuits over the compared alternatives.

Why supervised learning falls short

  • 3.8× more two-qubit gates and 2.4× greater depth are produced by supervised DNN than vanilla RL on a 13-qubit QPE benchmark.The comparison uses gate count and depth as fidelity proxies; the passage attributes the gap to fixed training labels and independent stage predictions.Source: §3.4 · p. 5

Why greedy selection falls short

  • Greedy selection yields fewer two-qubit gates and lower depth after routing, yet produces worse final circuits than brute-force selection.Across seven init-stage optimization passes, locally favorable choices can leave circuits that downstream passes cannot improve as effectively.Source: §3.4 · p. 5

Why reinforcement learning

  • RL learns from final compilation outcomes, allowing it to account for delayed effects of early pass choices on downstream transformations.Its reward captures cross-stage interactions rather than relying on fixed labels or optimizing intermediate metrics alone.Source: §3.4 · p. 5

3.5 RL Formulation for Circuit Transpilation

TuniQ formulates transpilation as sequential pass selection, using stage-aware circuit representations, validity masks, and intermediate rewards to optimize final physical-circuit quality.

3.5 RL Formulation for Circuit Transpilation

  • TuniQ models compilation as an MDP in which a pass-selection agent acts on circuit states through the Qiskit transpiler and is rewarded for final physical-circuit quality.The sequential formulation captures delayed consequences of early choices for later stages.Source: §3.5 · p. 5

3.5.1 State Space

  • Separate encoders represent logical-qubit interactions before mapping and physical-qubit topology and noise after routing.Circuit statistics and circuit/backend topology descriptors supplement the stage-appropriate representation.Source: §3.5.1 · p. 6

3.5.2 Action Space and Masking

  • Dynamic action masks restrict pass choices to stage-appropriate and currently valid actions, ensuring completed episodes produce hardware-executable circuits.Masks enforce requirements such as decomposition, mapping, routing connectivity, basis translation, and pass dependencies.Source: §3.5.2 · p. 6

3.5.3 Transition Dynamics

  • The Qiskit transpiler applies each selected pass as a deterministic state transition, with fixed seeds making stochastic passes reproducible during training.The next state is the updated circuit state.Source: §3.5.3 · p. 6

3.5.4 Reward Structure

  • Stage-dependent shaped rewards use TQ proxies when exact ESP is unavailable, then switch to ESP after translation completes.Layout quality and routing quality provide intermediate feedback; the final reward combines logarithmic ESP improvement with auxiliary gate-count and depth terms.Source: §3.5.4 · p. 7
  • The final reward compares the agent’s ESP with a Qiskit Level 3 reference and adds gate-count and depth terms.The reference compilation is part of training reward computation.Source: §3.5.5 · p. 7, §3.5.4 · p. 7

3.5.5 Putting It All Together: Training and Inference

  • Training samples masked actions and updates the policy with MaskablePPO, while inference selects the highest-probability valid action from a frozen policy.Inference omits reward calculations and reference compilation; its per-step overhead is one MLP pass and masked arg max, measured at less than 1% of transpilation time.Source: §3.5.5 · p. 7

3.6 Improving TuniQ’s Robustness

TuniQ addresses compilation corner cases with safeguards for pass failures, valid stage transitions, reward stability, and backend diversity. Its design also targets applicability across evolving hardware and compiler passes.

Pass failures

  • TuniQ times out and tracks failed passes, masks failures for the episode, and uses fallback layout or routing methods to ensure compilation completes.VF2Layout may exhaust its call limit, routing may loop, and optimization may cause gate explosion or oscillation.Source: §3.6 · p. 8

Stage enforcement

  • Dynamic action masking enforces stage order, and a final basis check triggers retranslation when gates fall outside the target set..Source: §3.6 · p. 8

Reward stability

  • Log-ratio reward bounds control ESP scale, while gate-count and depth terms, no-op penalties, and convergence checks provide learning signals and stop unproductive loops.The reward is relative to Qiskit Level 3 transpilation; cumulative net effects of opposing passes are reflected in state encoding and shaped rewards.Source: §3.6 · p. 8

Backend diversity

  • Training perturbs gate errors, coherence times, and coupling edges to expose the policy to hardware variation and support generalization across backend conditions.The passage describes simulated backend-instance perturbations during training.Source: §3.6 · p. 8

Generalization as hardware and compilers evolve

  • TuniQ’s state representation uses circuit and hardware characteristics, while adapting to new hardware requires calibration data and new passes require updated mask rules.The design is described as platform-agnostic across quantum modalities; QEC-specific logical compilation composes as a separate upstream layer.Source: §3.6 · p. 8

4 Implementation and Methodological Details

TuniQ wraps Qiskit transpilation in a Gymnasium environment and uses masked PPO with stage-aware features and shaped rewards. The section describes its implementation, training, and evaluation across IBM hardware and circuit benchmarks.

Interface and environment

  • TuniQ implements its RL formulation as a Gymnasium environment around Qiskit and provides a transpilation-style API with separate circuit, feature, masking, and reward components.Separating these components supports independent testing and integration with policy-gradient algorithms; batch compilation amortizes inference overhead across circuits.Source: §4 · p. 8

Feature extraction

  • The dual encoder uses circuit-layer depths, backend error and coherence features, topology and compatibility statistics, and recent pass history to represent circuit and hardware state.Backend noise features are extracted for post-routing stages; the last five passes and their application counts help detect convergence.Source: §4 · p. 8

RL approach

  • TuniQ trains with MaskablePPO, whose action masking assigns probability only to valid passes; alternatives showed weaker or less consistent benchmark behavior.DQN’s TVD improvement fell to 5.8% on QPE and -5% on Grover, versus TuniQ’s 34% and 16%; A2C reached -66% on Deutsch-Jozsa, all over Qiskit (Fidelity Optimized).Source: §4 · p. 9

Training configuration

  • Training uses eight parallel workers, soft reward normalization, standard PPO hyperparameters, and 30 perturbed backend instances for noise robustness.Perturbations add Gaussian noise to error rates and coherence times and randomly disable coupling edges.Source: §4 · p. 9

Execution on real quantum backends

  • Evaluation combines real runs on four IBM Quantum Cloud processors with simulation studies for controlled noise scaling and decoherence sensitivity.Real-hardware circuits use 8192 shots; simulations use IBM-calibration-derived noise models, 16384 shots, and eight NVIDIA H200 GPUs.Source: §4 · p. 9

Benchmark circuits and evaluation

  • The evaluation spans structured and random circuits, scales representative benchmarks to 65 qubits, and compares against Qiskit and selection-based alternatives using TVD and compilation time.The primary baseline is Qiskit (Fidelity Optimized), and Figure 9’s caption reports higher fidelity for TuniQ than competitive methods.Source: §4 · p. 9, Figure 9 · p. 9

5 Evaluation

TuniQ improves fidelity and reduces compilation time across representative workloads, transfers across backends and noise conditions, and retains growing advantages as circuits scale. The evaluation attributes these gains to joint stage decisions and selective pass use, while also identifying conditions where performance can degrade.

5.1 Effectiveness of TuniQ

  • TuniQ improves TVD by an average of 20% and reduces compilation time by an average of 34% versus Qiskit (Fidelity Optimized).The reported fidelity gains span representative benchmarks; compilation-time results are lower in most cases.Source: §5.1 · p. 10, Figure 10 · p. 10

5.2 Robustness Across Hardware and Noise

  • Zero-shot transfer from Pittsburgh improves TVD on 14 of 16 benchmark-backend pairs, with gains up to 64%, while compilation time falls 27–67%.The two TVD degradations occur on QPE on Kingston and QNN on Fez, both Heron R2 devices.Source: §5.2 · pp. 10–11, Figure 11 · p. 11
  • In a controlled noise-scaling study, compilation-time benefits persist at 27–70%, while TVD improvement holds across most benchmarks and noise levels.At 0.3× noise, QPE shows slight degradation; the study scales calibrated gate and readout errors and omits effects including crosstalk.Source: §5.2 · p. 11, Figure 12 · p. 11
  • With gate errors disabled and T1/T2 scaled to 1.5–2.5× baseline, Deutsch-Jozsa shows 50–60% TVD improvement, while QNN degrades at 2.5×.The simulation isolates decoherence effects; the QNN result is attributed to routing that avoids high-error edges but adds unnecessary depth.Source: §5.2 · p. 11, Figure 13 · p. 11

5.3 Why TuniQ Works?

  • Restricting RL control to init and optimization drops TVD improvement from 34% to 17% and degrades compilation time by 73%.The analysis also reports TVD falling to 27% with gate-count-and-depth rewards, and compilation-time improvement falling from 53% to 47% without noise features.Source: §5.3 · p. 11, Table 3 · p. 11
  • Pass choices vary by circuit and backend: CommutativeCancellation is selected on 100% of HHL episodes versus 33% of Grover episodes, while some uniformly applied passes are skipped.For Grover, ContractIdleWiresInControlFlow is selected 67% of the time on Pittsburgh and 0% on Fez and Kingston.Source: §5.3 · p. 12
  • TuniQ achieves the best TVD on three of four benchmarks; per-circuit search incurs 1–8 seconds of overhead, while TuniQ inference takes under 0.1 seconds.Evolutionary search slightly outperforms TuniQ on Deutsch-Jozsa, 22% versus 20%, and fails on Grover at −5%.Source: §5.3 · p. 12, Figure 14 · p. 12

5.4 Performance Scaling

  • At 65 qubits, transferred pass sequences yield 40% fewer gates, 50% lower depth, and 2–3× faster compilation than Qiskit (Fidelity Optimized).With per-circuit inference at 30–50 qubits, TuniQ improves compilation time by 68%, gate count by 27%, and depth by 25%.Source: §5.4 · pp. 12–13, Figure 16 · p. 13

6 Related Works

Prior work develops quantum compilation optimizations, but typically addresses individual stages or treats transpilation as a black box. TuniQ focuses on pass selection across Qiskit’s full pipeline while conditioning on hardware noise.

6 Related Works

  • Prior work targets individual compilation stages, including circuit rewriting, targeted gate optimization, and RL-based routing, while temporal and device-varying noise motivates noise-aware transpilation.These approaches do not examine how pass choices interact across stages; early choices can constrain later optimization.Source: §6 · p. 13
  • Per-circuit NSGA-II search explores LLVM/QIR pass subsets and sequences, whereas TuniQ selects passes across all stages of Qiskit’s pipeline and conditions on hardware noise.The paper characterizes TuniQ as the first noise-conditioned system jointly selecting passes across the full IBM Qiskit circuit-transpilation pipeline.Source: §6 · p. 13
  • HPC quantum workloads are compilation-sensitive, and existing calibration-aware transpilation and noise-aware scheduling approaches often treat transpilation as a black box.The cited workload context includes variational algorithms and NISQ machine-learning and optimization applications.Source: §6 · p. 13

7 Conclusion

TuniQ replaces fixed compiler pass sequences with learned, circuit- and noise-aware selection across transpilation stages. It improves fidelity and reduces compilation time, generalizes across backends without retraining, and scales to utility-scale circuits with growing advantage.

  • TuniQ is the first adaptive quantum-compilation pass selector, replacing fixed sequences with learned circuit- and noise-aware selection across transpilation stages.Source: §7 · p. 13
  • TuniQ improves fidelity and reduces compile time, generalizes across backends without retraining, and scales to utility-scale circuits with growing advantage.Source: §7 · p. 13
Loading 2605.11375v1…