Optimized for multi-chip. Across every workload family.

Every benchmark on this page measures the metric that actually matters on multi-chip hardware: cross-chip communication. Fewer cuts mean fewer cross-chip teleportations and a lower cloud bill.

Limbo beats recent research results on every workload we measured: we win 24 of 24 cells against TKET (Quantinuum's flagship quantum compiler), across both fully-connected and constrained intra-chip layouts, with up to 78% fewer cross-chip operations and a 118× median compile speedup (up to 2735× on the hardest cell). Versus a graph-blind naïve baseline the gap widens to 71%.

arXiv mirror pending endorsement; the Zenodo record is the stable archival copy.

Versus TKET on multi-chip workloads

TKET (Quantinuum's flagship quantum compiler) is the most capable general-purpose comparison point we have access to. Its routing was designed for single-chip hardware and retrofitted for multi-chip layouts, so we restrict this comparison to workloads where multi-chip routing actually has to do work: we drop hardware-efficient ansatze (mostly nearest-neighbor) and n=16 (fits on one chip).

Apples-to-apples setup. Both compilers do a full end-to-end compile: TKET routes the whole circuit against the multi-chip Architecture (placement + SWAP-insertion + peephole); Limbo pre-optimizes, partitions across chips, then transpiles every per-chip sub-circuit against the intra-chip coupling map (native basis gates, optimization_level=3). Cuts = cross-chip 2-qubit operations in each compiler's final physical output, including any SWAPs.

We run the matrix under two intra-chip topologies so you can see whether the win depends on which type of physical chip is underneath. It doesn't.

What's happening. Limbo's hypergraph partitioner solves the right problem for multi-chip execution (minimize cross-chip 2-qubit operations directly) and then hands each per-chip sub-circuit to Qiskit's routing pass on a small, dense intra-chip problem. TKET solves a different problem (one big SWAP-minimization against the full multi-chip coupling map) and pays cross-chip operations on routing. The win in cuts is structural and survives the strictest intra-chip topology. On the harder constrained-grid layout it actually widens, because TKET cascades extra inter-chip SWAPs whenever intra-chip routing tightens. The win in compile time is also structural: partitioning N qubits into k sub-problems gives the routing pass k smaller graphs to search, not one bigger one.

Output fidelity under multi-chip noise

The cut-count comparison above shows Limbo emits fewer cross-chip operations than TKET. This section tests the causal claim: fewer cross-chip ops → higher output-state fidelity under realistic multi-chip noise. Both compilers' physical outputs run through the same Aer noise simulator. We measure Hellinger fidelity between the noisy measurement distribution and the noiseless ideal.

Noise model. Intra-chip 2q gates at 0.005 depolarizing error (≈ IBM Heron level); cross-chip 2q ops at 0.050 (10× worse, representative of photonic-EPR cross-chip links on real modular hardware). 1q gates and readout at small uniform rates. Both compilers receive the same noise budget on every qubit pair, so the only architectural variable is how many cross-chip ops they each emit.

Scale. n=12 (4 chips × 3) and n=16 (4 × 4), small enough for full statevector noise simulation on a laptop. 8192 shots per cell.

(¹) Uniform-ideal cells. QFT|0⟩ produces a uniform superposition, so the ideal output distribution is already uniform across all 2ⁿ bitstrings. Hellinger fidelity to "noisy roughly-uniform" output stays high regardless of which compiler produced it. These cells are kept in the matrix for completeness but they aren't where the architectural claim is testable; we exclude them from the headline win count.

(²) Noise-floor cells. At n=16 with this noise budget, both compilers approach the floor (~0.1 fidelity) because the absolute number of cross-chip ops saturates the photonic-link error budget. Limbo still wins these cells (Hotspot n=16 is 3× the TKET fidelity), but the absolute numbers are small, so we annotate rather than hide them.

The architectural claim, validated. Across every cell where the metric is informative, Limbo's partition-first approach produces output state distributions that are measurably closer to the ideal than TKET's routing-first approach. Best-case improvement: +6.66 percentage points on Sparse Random (n=12). Average over the full matrix: +2.54 pp, including the QFT/IQFT cells where the metric is structurally insensitive.

Broader coverage versus a recent research partitioner

QuPort is a recent research-grade partitioner (TPCCAP local search + layered makespan estimator). We run a wider matrix here (seven workload generators across three scales: 16, 32, 64 logical qubits) on the same 4-QPU / cap-20 hardware envelope, to show Limbo's partition advantage holds across more circuit shapes, not just the multi-chip-focused subset we run TKET on. Cut count = cross-QPU 2-qubit operations = Bell-pair teleportations the runtime must execute. Lower is better; per-row winners highlighted.

Fourier

Variational

Randomized

Application-shaped

"Degenerate" cells are workloads small enough to fit on a single chip, so cut count is zero for one or both compilers and there's no signal either way. "Tie" cells produce identical cut counts. Limbo's advantage grows with circuit size and density: the harder the partition problem, the more our approach pays off relative to simpler heuristics.

Why this matters in a multi-chip world. Every cut on this page is one cross-chip teleportation at runtime. Cross-chip communication is the slowest and most error-prone part of any modular quantum job. Cutting fewer edges means faster jobs, fewer mid-circuit errors, and lower cost. The advantage compounds as multi-chip hardware scales out.

Top partition wins vs QuPort

Five cells where Limbo cut the most communication volume vs QuPort on the broader matrix. Shorter bars = fewer Bell pairs = lower cloud bill.

Where the gains come from

Three independent components feed the final result: the partitioner that places qubits onto QPUs, the scheduler that sequences cross-chip events through limited port capacity, and the template cache that amortizes partitioning across variational iterations. Each one was measured separately so the attribution is clean.

Real hardware: pipeline validated on AWS Braket

Limbo compiles, submits to, and retrieves results from real quantum hardware. We've executed the following workloads on AWS Braket's Rigetti Cepheus-1-108Q superconducting QPU. Real silicon, real photons, real measurement counts.

How to read these numbers. The Hellinger fidelities above are low because both workloads (12 logical qubits, ~100+ native gates after lattice routing on Cepheus) sit at current NISQ hardware's noise floor. Every CZ on today's superconducting hardware carries a 1–2% error rate, and 100+ of them in a circuit drives output to a near-uniform distribution regardless of which compiler produced the program. This isn't a Limbo-specific outcome: any compiler running circuits of this depth on current hardware would see the same. What these receipts do show is that the entire Limbo pipeline (compile, partition, transpile, submit, poll, retrieve) works end-to-end on real cloud-accessible quantum hardware.

Single-qubit-noise-aware routing on real hardware

For real-hardware targets, Limbo's compile pipeline pulls live per-qubit calibration data from the device and feeds it into Qiskit's SABRE routing pass as an instruction-weighted Target. SABRE then picks a layout biased toward the highest-fidelity qubits, avoiding qubits the device reports as broken or uncalibrated.

Validated against Cepheus-1-108Q's live calibration: 102 per-qubit randomized-benchmarking fidelities consumed, 5 qubits with fidelity = 0.5 (broken / uncalibrated) skipped during layout selection. Rigetti doesn't publish per-edge 2-qubit fidelities or per-qubit readout fidelities for Cepheus today, so SABRE uses uniform defaults for those classes. This means single-qubit routing is genuinely calibration-driven; two-qubit routing remains uniform-cost until Rigetti exposes the data. Compile metrics surface noise_aware_routing: true on every job hitting Cepheus.

Why we can't validate the multi-chip claim on real hardware yet

The architectural claim Limbo makes (that partition-first compilation reduces cross-chip operations, which on real modular hardware reduces noise and improves output fidelity) is fundamentally a claim about multi-chip topologies. To test it on hardware, you need real multi-chip hardware: independent chips connected by a (lossy) photonic interconnect, where cross-chip gates carry a meaningfully different error rate than intra-chip gates.

That hardware doesn't exist on a public cloud provider today. The closest candidates are Quantinuum's H-series (multiple ion-trap zones acting as separate compute regions, not yet quite the photonic-link model Limbo is built around) and IBM's Quantum System Two prototype with multi-chip Heron interconnects (not yet on IBM Cloud). Until one of those lands, the multi-chip architectural claim has to live in the simulator-shadowed fidelity matrix (Section 2 above), where we model cross-chip operations at their real 5%-ish error rate against intra-chip 0.5%-ish. The Cepheus-1-108Q runs above validate the pipeline; the simulator runs validate the architecture.

Nothing on this page is extrapolated from a different problem size. The cut-count and compile-time figures are compiler metrics from runnable benchmarks; the fidelity figures are noise-shadowed simulator metrics from another runnable benchmark; the hardware figures are real Braket task results.

Scheduler sensitivity: when does scheduling matter?

64-qubit hotspot workload on a 4-chip linear layout, simulated with realistic link-success probability and retry penalties. Sweeping port capacity shows where the critical-path scheduler earns its keep, and where it ties with simpler FIFO.

Honest read: with very limited port capacity, both policies produce essentially the same schedule because every cycle is contention-bound. The critical-path scheduler's advantage appears as capacity opens up, peaking at about 7% off the makespan. The big win is consistency: it never significantly loses, and wins where it can. Production hardware is moving toward higher port capacity, which is exactly where the scheduler advantage compounds.

Where Limbo fits

Methods

Setup. Every cell uses 4 chips × 20 qubits per chip with a fixed random seed for reproducibility. The same circuit is handed to each compiler. Cut counts come from each compiler's own partition output. Makespan estimators use each compiler's native pass. Compile time is wall-clock through the full pipeline.

Baselines. Three compilers in the matrix: Limbo, the leading distributed alternative, and a naïve baseline that partitions by qubit index with no graph analysis at all. The naïve baseline is there so you can see the graph-aware compilers are doing useful work.

What we did not measure. No real-hardware execution, queue-time wall-clock, or shot-cost figures. These are deferred to v0.3 (see the real-hardware section above). Every figure on this page comes from a reproducible simulation pipeline.

Hardware envelope. c6i.4xlarge EC2 (16 vCPU, 32 GB RAM), Python 3.11. The full v0.2 matrix completes in under 20 seconds wall-clock.

Read the full paper

The complete preprint — including the noise model, the real-hardware appendix, ablation matrices, and the threats-to-validity section — is embedded below. Open in a new tab for a wider reading view.

PDF served by Zenodo. If the inline viewer doesn't load (some browsers block third-party PDF embeds), use the direct download link.

Cite this work

BibTeX entry for the Zenodo deposit:

@misc{ding2026limbo,
  author    = {Ding, Jaymin},
  title     = {{Limbo: A Multi-Chip-First Quantum Compiler Unifying
                Hypergraph Partitioning with Topological Cross-Chip
                Routing}},
  year      = {2026},
  month     = may,
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.20442129},
  url       = {https://doi.org/10.5281/zenodo.20442129},
}