Research

Toward hybrid quantum-classical compute

We don't build quantum hardware and we're not going to. Our group works one layer up: how a classical GPU fleet schedules around, verifies and absorbs work from quantum processors reached through partner providers.

Enquire about the programme Read the notes

Scheduler, live

A simplified view of how classical nodes stay connected while work is handed off and taken back from a QPU.

Approach

The interesting problem isn't the qubit

Every serious quantum result today still depends on a classical system to compile the circuit, mitigate the noise, and make sense of the output. Whoever schedules that classical work well gets more out of scarce QPU time than whoever has the newest processor.

That's the layer we work on. The programme is small and part-funded by rental margin; results get folded into the production scheduler when they hold up under load, and nothing here is sold as a product on its own.

Researchers, part-funded by rental margin

312

GPUs on the fleet the programme schedules against

Production scheduler it all eventually feeds into

Focus areas

Four problems, one scheduler

Hybrid scheduling

Active

Handing a sub-problem to a QPU and taking the result back without leaving the GPU queue idle in the meantime. The scheduler treats a quantum call like any other long-latency operation.

Why it matters

Most quantum workloads today spend more time waiting on classical pre- and post-processing than on the QPU itself. If the classical fleet stalls waiting for that round trip, the economics never work.

Error-mitigated sampling

Active

Classical post-processing that makes noisy intermediate-scale output usable for small optimisation and sampling problems, run on the same GPU fleet as everything else.

Why it matters

Current-generation hardware is too noisy to trust raw. Mitigation run at scale is what turns a demo result into something a scheduling or logistics problem can actually use.

Simulator capacity

In service

State-vector and tensor-network simulation of small quantum circuits, offered on the same L40S and A100 nodes rental customers use for everything else.

Why it matters

Most teams evaluating quantum approaches need to test circuits long before they need real QPU time. A simulator that runs on rented GPUs is a cheaper, faster place to start.

QPU access

Exploratory

Brokered time on third-party quantum processors through the Sundancæ control plane, scheduled and billed alongside classical jobs. No timeline committed.

Why it matters

We don't build quantum hardware and don't plan to. This is about making someone else's QPU a schedulable resource next to a GPU, not a separate system to manage.

Access model

One queue, whichever QPU is free

We don't operate quantum hardware, so access always runs through a partner. What we own is the layer that makes that access usable without you managing three vendor relationships.

Submit

A job is submitted to the Sundancæ scheduler like any classical workload, tagged as QPU-eligible.

Compile

Our classical fleet compiles and optimises the circuit for the target processor before it ever reaches a queue.

Broker

The scheduler hands verified work to whichever partner has capacity, without you managing a separate account.

Verify

Results are mitigated and checked classically on return, and only then marked complete on your job.

What's next

Open questions we're chasing

These aren't announcements, they're the problems on the whiteboard right now. Some will show up as programme notes in a quarter; some won't work out at all.

Scheduling

Cross-provider QPU queueing

Right now we schedule against one partner's queue at a time. The open problem is bidding classical-verification work across two providers without doubling the wait.

Compilation

Cost-aware circuit compilation

Most compilers optimise for gate count. We're testing whether optimising for our actual mitigation cost on the classical side produces a cheaper circuit overall.

Verification

Cheaper noise mitigation

Zero-noise extrapolation is accurate but expensive to verify classically. We're looking at where a lighter mitigation pass is good enough for production use.

Programme notes

What we've been finding

Short internal notes from the group, published as they're written. Nothing here is a peer-reviewed paper; it's a record of what a four-person team funded by rental margin has actually been working on.

Q1 2026

Queue-aware batching for mitigated sampling

Short internal note on batching sampling jobs against scheduler idle windows instead of running them eagerly, cutting wasted GPU-hours on the mitigation pipeline meaningfully in early testing.

Q4 2025

Where tensor-network simulation stops being cheaper

A working estimate of the circuit width at which our simulator capacity should hand a job to real QPU time instead, once brokered access is live.

Q3 2025

Latency budget for a hybrid scheduling round trip

Notes from the first end-to-end test of the hybrid scheduler against a partner-provided QPU sandbox, and what it implies for how we queue classical work around it.

Q1 2025

Simulator capacity, six months in

Internal review of uptime, node allocation and who's actually using the simulator pool a couple of quarters after it went into service.

Enquire about the programme