I tend to get obsessively interested in things, to the point my curiosity is insatiable. If I do not understand how everything works I will absolutely implode. That has recently started to happen with quantum computing. I will precede this with a warning that I have zero background in Physics beyond a class in high school that was terrible, and my background in everything else STEM is largely self-taught during my working years. I am going to dive in anyway, because I am on ☁️ nine learning about this. First, I want to review projects that I have encountered in the space.
Projects
When you attend meetings or hear people talk about quantum computing, these are commonly named. I still have a lot of learning to do, and especially diving into each one, but I am starting to put them together.
- Qiskit is IBMs software SDK is what you use to write circuits and compile instructions. This is the slack community that a lot of people that work on qrmi are in. They also have a runtime and serverless that are products to combine classical resources and quantum. If I want to write a program for Quantum, I can use Qiskit.
- QRMI is the quantum resource management interface, what I have been working on with Flux. This is what is relevant to scheduling, because it helps expose quantum resources as interfaces. It is middleware to schedule and manage jobs on quantum. E.g., I can acquire a session to connect to a quantum device, or submit / cancel / monitor tasks.
- QDMI is what Martin works on - the same but device interface. It works with devices as a back-end interface for software to read hardware characteristics and compile specific instructions (e.g., from qiskit).
- A qubit is analogous to a bit, but a quantum bit (my deep dive on this below).
So QRMI is system level, and QDMI is hardware level, and they are both parts of a “submit my work to quantum machines” but different layers. To get a sense of how centers are integrating classical and quantum, watch this talk by Martin Schultz (a year old) and this more recent talk that I attended in person! And asked a very naive question… how do I get access to one of these computers? I did not have an answer until about a month ago.
Learning about Qubits
There are several different ways to actually create them (analogous to hardware, an example from IBM is microwave pulses) but for my understanding, I’m considering one like a supersonic spinning coin in the air. At any point in time, I can slam the coin on the table to get heads or tails, but while it’s spinning, it is some combination of heads or tails. At first I was imagining heads and tails having probabilities, but that isn’t quite right. They call them amplitudes, where each can be positive or negative, and they can cancel each other out. A positive number means the quantum wave is in a crest, and a negative is a trough. The mental imagery I have is of a grid of little intersecting waves, which if you imagine combined, is like a moving sheet. Each configuration has its own amplitude point on the sheet in a crest, trough, or neither (this state is called superposition). When a microwave pulse fires, it adds positive or negative values to these points. A path that adds 5 and a rule-breaking path that adds -5 would pool into the same spot and become 0, and that is how they would cancel each other out. A 5 and -3 would leave a tiny little wave of 2. When we take a measurement, which is like freezing the sheet, the computer squares these final values to turn them into positive percentages (probabilities) that add up to 100%. It doesn’t use a threshold to round up or down; instead, it rolls a quantum dice based on those percentages. An optimal path with a high percentage is highly likely to be chosen, while a bad path with 0% will never be seen. When a measurement is taken, that dice roll is what we get back—a single string of 0s and 1s representing that one frozen grid configuration, which is why we run it multiple times to see which answer pops up the most. To go back into my visual imagery, I see water rolling across a valley and pooling into the rivers, the solutions to our problem, but only frozen at a single point in time by the measurement.
My next question was how you model a problem into this kind of program, and you can use software called Docplex that works with qiskit. There are two matrices you define - a distance matrix for some kind of topology (e.g., we could model hardware topology) and a penalty matrix for constraints. The assumption (for something like QAOA) is to assume pairwise constraints, but there are ways to add in helper qubits to model three way+ interactions. I’m going to avoid thinking about that for now. So we write a Python program that loads in the matrices, and sets the objective (e.g., minimize distance). And here is a cool part that I can’t best explain because I have almost zero actual STEM background aside from throwing myself into it like a noodle. There is a wave landscape (!) called an Ising Hamiltonian, and it’s a mathematical equation. Qiskit takes our inputs and translates them to that. And at this point, every valid path (e.g., maybe a scheduling solution) sits at the bottom of a low-energy valley, and all of our distance/penalty violations are steep, high-energy hills. God, this is so cool. 😎
Now we run the algorithm. The one I mentioned is QAOA (Quantum Approximate Optimization Algorithm). In Vanessa terms - “how many times should I let my waves crash and slide around this landscape to find a lowest point? As a reminder, a really high point (heavy penalty) is what we have modeled to be not ideal, and ideal is low.” So in the actual quantum computer, assuming IBM with microwave pulses, the qubits are initialized into superpositions of all possible solutions, and then the machine fires microwave pulses based on distance rules. Invalid options will destructively cancel out, and we go until we take a final measurement coinciding with our last planned pulse. Then the quantum computer does the freeze, convert to 0/1, and it returns them via QRMI/qiskit to our classical computer, and we convert that back to meaningful variables based on our model (Docplex variables).
Scheduling Quantum
We have started modeling Quantum APIs into our scheduler, Flux Framework. More specifically, flux-sched or fluxion, isolated from the core of flux (flux-core). I do not need the core components to build stuff in Kubernetes. This is what I am calling the two-queue problem, or the fact that we are modeling a queue that we do not control (but can inspect the depth of) and need a good means to orchestrate work between classical and quantum systems that does not have resources running idle on the classical.
I love this work, and am in that state of being inspired, thoughtful, and focused, all at once. Right now I am still working on our custom scheduler plugin, fluence, and doing early experiments to measure latency and test approaches in Kubernetes to handle it. I started using IBM Quantum Cloud, ran out of the free trial, and have now moved over to Braket. I will ideally be able to work with both. Next we will look at local on-premises quantum modeling, which I will not talk about publicly. In parallel, I am interested in the actual programs, and specifically modeling problems (algorithms) in scheduling to run on quantum devices. I will note that I have been working on this for less than a month, so please excuse my lack of expertise - you are seeing someone learn about a new area in real time! Here is the first set of projects that reflect the Kubernetes work, recorded to present at a 6am meeting at which point I was sleeping. :)
They are already much further along than I presented there. Stay tuned for more! 🥳
Suggested Citation:
Sochat, Vanessa. "Quantum Computing." @vsoch (blog), 19 Jun 2026, https://vsoch.github.io/2026/quantum-computing/ (accessed 20 Jun 26).