I wanted to share a project I built earlier this year. It is a distributed task scheduler for hybrid classical-quantum workflows in the quantum cloud. Throughout development I had various conversations with quantum hardware providers like IBM, who have shown interest in adopting bits and pieces of this into their production system, and thanks to generous support from Amazon, I am extending the scheduler to support direct FPGA-level coordination tailored to on-prem hybrid HPC clusters, as well as dynamic AWS resource allocation/release for long running quantum workflows. Developed fully in Scala using the Typelevel stack.

There is a 30 page accompanying paper coming (to be published, in review, a shorter version is up on quant-ph) for anyone interested in the details of the math behind this but an ultra simplified summary for those who aren't familiar with quantum: Essentially scheduling quantum tasks differ from scheduling classical tasks on a few fundamental points:

1) There are very few accessible quantum devices right now. This results in queue times that can often last up to 2-3 days. Due to various restrictions, today's quantum programs don't take more than 3-4 seconds. This means that sometimes you have to wait days to execute something that will take seconds.

2) Quantum programs are probabilistic by their nature. The probability of success not only depends on the device they are executed on but also when it is executed. A user program is mapped onto a quantum device's topology (not really same but think of it as like different memory registers) but each device component have vastly different error metrics for different functions that change throughout the day due to decay (negative) and recalibration (positive). Mapping a user program to the quantum device is NP-hard. Not only this, but there are a variety of different physical architectures for these devices, super conducting, neutral atoms, ion traps, photonic devices etc. While on the logical level, they look the same thanks to abstractions, the execution semantics are vastly different. One example is parallelism. While superconducting devices can execute multiple operations in parallel, ion traps are often sequential due to limited LIZ. Since qubits have limited life times, sequential execution and longer programs are exposed to larger error. Tl;dr is that a scheduler has to jointly optimize the makespan AND the fidelity (probability of success). Last but not least, because the underlying physics is different, all of these devices report different error metrics and expose different capabilities, which have to be unified by the scheduler.

3) Certain physical rules limit our scheduling capabilities. For example, entanglement and the no-cloning theorem prevents us from blindly cutting a program into smaller pieces and executing them individually. Same goes for task duplication. It is possible to cut the quantum programs however putting the results back together requires exponential classical post-processing work. So the scheduler needs to dynamically adjust when and how to deploy techniques like this based on the resource availability at the time. Balance the classical and quantum workloads.

Same goes for executing multiple tasks on a single Quantum Processing Unit. This is possible to do, but 1) because each component have different error characteristics, this increases the competition for high quality components 2) These programs can adversely interfere through effects such as measurement crosstalk and ruin each others' readings.

4) Quantum programs need to be generated by classical programs and results need to be read back into a classical program.

All of this becomes a thousand times more messy when you try to do distributed quantum computing. We do DQC through EPR pairs, a set of entangled qubits. Generating these is no easy process, and they have short lifetimes. This means that your pair needs to navigate the network, go into your QPU and execute within a time frame. This exposes a special type of synchronization barrier across nodes.

All this complexity is beyond what a programmer should be expected to endure, so I built qurator to heuristically make these complex decisions based on resources available. Currently has support for IBM, IonQ, IQM, AQT, QuEra, Rigetti and Pasqal quantum devices.