Stephen DiAdamo (Qoro Quantum): Middleware that hides QPUs, GPUs, and CPUs behind 20 lines of code

Stephen DiAdamo, co-founder and CTO of Qoro Quantum, is interviewed by Yuval Boger. DiAdamo discusses Qoro’s position as a software middleware company that abstracts hardware away from applications, walking through the Divi SDK, circuit serialization and parallelization, and an orchestrator that automatically selects between 12 simulation methods on CPU and GPU or dispatches to QPUs from any vendor. They explore how Qoro plugs into HPC schedulers like SLURM rather than replacing them, the CESGA proof of concept built on the CUNQA platform, the “150,000 lines of code to 20” claim, and the argument that multi-QPU centers are needed today for fallback and resilience and for scaling applications. DiAdamo also reflects on developer experience for students learning QAOA and variational algorithms, and Qoro’s two-year history.

Transcript

I’ll read the transcript cleanup skill first, then clean this.“`text Yuval: Hello, Stephen, and thank you for joining me today.

Stephen: Thank you very much.

Yuval: So who are you and what do you do?

Stephen: So I’m Stephen DiAdamo. I am the CTO of Qoro Quantum. Qoro Quantum is a software company looking at quantum computing from a bit of a different perspective, as we are approaching from the middleware of the stack. So Qoro Quantum, we do look at the other layers of the stack, but our focus is on middleware, but we look top down. This is our approach. As we start with applications, we move into the middleware and then we do orchestration and access multiple quantum computers, heterogeneous compute systems, including traditional compute technologies like CPUs, GPUs, and QPUs, and of different QPU modalities. And what we do is make it as easy as possible to access this type of compute network by making applications abstract from the hardware and automating the stack. And this is our unique position in the market, because we make this, you know, PhD is not necessary to have anymore because the applications are inputs that people are familiar with. The abstractions are there to scale for hardware agnosticism. We don’t rely on any particular vendor to be hosting the quantum computer. And we can also move to simulation when we need to. And we essentially are targeting high-performance simulation in the cloud. And of course I go into a lot of detail in that. But you can consider us a software middleware company looking at simplifying infrastructure deployments and accessing many quantum computers from any vendor in a seamless and automated way.

Yuval: So let’s take an example just to help me clarify. So let’s assume I have an optimization problem and I have an algorithm that I want to execute. Do you provide the compiler? Do you rely on the hardware vendor or someone else to provide the compiler? How would that work for me as an end user?

Stephen: So as an end user, we start with our software layer called Divi. Divi is an open source Python SDK. And we look at just taking the optimization inputs. So oftentimes an optimization problem requires a QUBO or a HUBO or a variational quantum algorithm for material science or in other aspects, and we take in just the parameters. And Divi will then translate this into a collection of quantum circuits. We focus really on parallelization, partitioning of problems, breaking them down so that we can use what’s available in the network to then optimize what we send to the network to compute with. This is automated through Divi. Then we serialize these circuits. This is very important because oftentimes you can produce 10,000 circuits, but getting them over the wire is very costly, or even producing the circuits themselves is very costly. And so you need to be very focused on how you can generate all those circuits in the first place. Once we send them to the cloud, we have our orchestrator there ingesting all of these circuits and we can put them into one of two paths. One is send them for simulation or send them for hardware execution. And we handle this automatically by looking at how many qubits are in the quantum computer. Can we put multiple circuits together to use the quantum resources effectively? What modality would be best suited for this quantum circuit? Is it too connected for a superconducting quantum computer? Is it, you know, too many gates for a trapped ion based quantum computer? And we make these decisions on the fly. If we send it on the other hand to the simulation platform, again, we do an automation there because we interface to many simulators. We support 12 different simulation methods on CPU and GPU. And of course, not everyone is familiar with developing their own tensor network simulations. They don’t know how to develop a Pauli propagation simulation. So we always take circuit input to optimal simulation engine, and we put a layer there in place to analyze the circuit again to see what simulation method would be best. Is it a stabilizer simulation? Is it going to be instantaneous? Or is it going to be a three-day job with a GPU MPS-based simulation? And then on the simulation side, we scale because we’re parallelizing 10,000 circuits, for example, we can parallelize. They’re all independent and they all need to be executed, so we can put 50 nodes in place immediately and get a big horizontal improvement there. So we’re looking at it really from the traditional standpoint of high-performance computing in the cloud for now and in the future, we of course integrate very deeply with HPC. But to bring it back all the way around, all these things come back together. All the results from all the circuit execution, CPU, GPU, QPU come through this pipeline all the way back and then are processed again at the application layer, where now all you see is the final results. You don’t have to worry about error mitigation, transpilation, compilation, resource selection, scheduling, orchestration, all these things are handled by us and from the optimization, you, the person who wants to run such a problem, they just put in their inputs, run, everything happens for them, results come in and the job is finished.

Yuval: How far is this from reality? I mean, as an end user, some would say this sounds too good to be true. So where are you in the process of building the environment that you’re describing?

Stephen: This is ready today. We’ve already been working with customers on different use cases. It’s also application agnostic, or not targeting any particular type of consumer. We’ve worked in the energy sector, we’ve worked in the finance sector, and in our work with these types of customers, we see they want to access quantum computers like this. We see them get stuck because they’re so integrated with IBM, but they’re using libraries from here and here and here, and they don’t know how to put it all into one environment, or they don’t know about these transpilation techniques. So they get stuck trying to run large-scale simulations for their research or for their job. And what happens is we say, OK, put the same problem into our software. Let’s see what happens. Let’s see if we can scale. We bring them Tensor Network Simulation. It’s already deployed in the cloud. You can access it today. And then we bring them access to different computers that are hosted on the cloud- quantum computers, specifically, I mean- that are hosted in the cloud. And we do the interfacing for them. And so we’ve done this many times with different customers showing them, look how easy it could be. Just trust us. It’s a unique perspective, of course, and not anyone else is really doing this. So it takes a bit of convincing that, trust us to handle the middleware. But once they see it, it changes the entire direction of the projects.

Yuval: Let me see if I can organize this in my head and then maybe go layer by layer and ask you some questions. So as I think about it, listening to you, there’s sort of layer zero simulation, say you guys can parallelize it and I have a lot of computing resources and I can run a lot of circuits in different places and speed up the time. I think I can understand that. One layer above that is optimizing the circuit for a particular type of quantum computer. One layer above that, at least in my mind, is synchronizing and orchestrating a quantum computer with a classical computer. And then the third layer is, oh, by the way, we can do that with multiple quantum computers or even with multiple quantum modalities, not just multiple computers of the same type, but multiple modalities. So I think I understand level 0. But let’s talk about level 1. As you mentioned, it does seem that a circuit that’s optimized for, say, a superconducting machine is not going to run very well on a trapped ion machine. A circuit that is optimized for using the parallelism and transversal gates and whatever, if an atom machine might not be optimal or might not be possible to execute on superconducting. And this is a very active area of research where the vendors themselves are putting a lot of effort in that. So is this something that you believe that you’ve already solved? How do you address the complexities and the differences between different modalities?

Stephen: Yeah, so we don’t invent transpilation techniques. We always rely on the vendor to provide the transpilation methods. This way, we bring the circuits from application layer to the lowest point that we can bring, and then we use the vendors’ transpilation techniques. We may adjust them slightly by doing, you know, if they’re heuristic or something, we may wrap a little bit of software around them to try to improve them as much as we can. But generally, we’re relying on the vendor to come with their own transpiler and compilers. And what we do is we just automate this system for the user so they don’t have to think about it. And what that also allows is if the user really wants to use a particular vendor, they can add configurations to send along with the job so that, you know, they can use transpiler version one versus transpiler version two, or optimize for a particular gate set. But it’s always up to the vendor to provide that layer. It’s a hard problem, of course, and we’re not there to solve it. We’re just here to bring access to the users in a simple way.

Yuval: So let’s talk about the next layer of the classical quantum interface. And I think that some people are thinking about this in three sort of timescales. One is batch processing, where the quantum computer is almost like a printer. I send the job, and when it’s done, it’s done. The other one is sort of near time, where a QAOA circuit or something has to sort of go back and forth. And then there’s almost real time, especially that relates to quantum error correction, mid-circuit measurement, dynamic decisions. Where do you guys come in and how do you address these issues?

Stephen: We’re at the top two, more or less. We’re not doing any low latency close to the QPU type of work, where we’re not focused on error correction at all. I mean, these are things that we know are coming, but these are huge topics. And what we’re here to do is bring access as fast as possible to people who want it. So with layer one, or sorry, with the layer, I forget the order, you know, the slow latency layer, the printer version, that’s where we put a lot of effort in because we treat them as independent devices. And there we send, you know, 15, you know, many circuits per device to execute in parallel, but there’s no connection between the devices at that stage. And then when we go for the QAOA, for example, where there’s a feedback loop, we try to use, again, parallelization techniques when applicable. Sometimes it doesn’t work, sometimes it does. But if you choose an optimizer that is more of an exploratory optimizer, let’s say it samples the entire space in a clever way. So this could be like Monte Carlo sampling or different types of optimizers that use populations. This generates many circuits and can be parallelized in the same way. So we can break up the problem set, you know, half the load there, half the load there, and parallelize in a slow latency environment. And this is really well suited for, you know, networks of computers over the internet where they may be sitting across the country and we don’t get low latency, but you still get this horizontal scale up instantly. But of course, yeah, these low level, you know, right to the computer, this requires more than software, I would say it requires some hardware innovation to get things right. So we don’t touch hardware, we’re not hardware to manufacture.

Yuval: So that’s very interesting. You bring up a sampling algorithm as something that could be parallelized across multiple machines. For my education, I’m curious, what other algorithms other than sampling do you see that have the potential of being parallelized?

Stephen: So, for example, time evolution is one that we focus on a lot. Material science and looking at how systems evolve over time is a very natural thing to simulate on quantum computers. There of course, you need to check every point in time what’s happening. So if you want to, for a pixel, you could parallelize like that. You can parallelize error mitigation, for example, when you need to add folding layers for ZNE, you can parallelize like that. You can parallelize search algorithms. So if you need to search a space and check is this working or not in this area, no, this area, you can always search in parallel. So there’s so many different parallelizations that we see and they tend to be application specific, of course, that’s what Divi is for. Divi optimization problems or the search problems or the sampling problems. And this always generates batches of jobs so we can scatter them across the compute network and be more efficient.

Yuval: Today, HPC centers often use SLURM or PBS Pro for scheduling and related in synchronization and resource reservation and so on. How does your software fit in that framework? Does it replace them? Does it become a plugin? Where do you sit relative to them?

Stephen: It’s precisely in the plugin layer. So we’re never gonna replace SLURM, we don’t want to go into that direction, but we need to look at the new types of resources joining the compute network, which are these new quantum computers. What information should they be transmitting so we can make decisions? This is something we need to control from Qoro side. And then we built, essentially this engine we have deploying in the cloud, we put it into the HPC as a SLURM plugin. This could also be two separate layers because perhaps what we envision is people can then send jobs from the application layer to the HPC. That requires an orchestration layer. And then inside the HPC, it requires orchestration at another layer. And that’s because they’ll have GPUs available or not available. They’ll have CPUs available and not available. And they may have multiple quantum computers available and not available. And the scheduler needs to be informed about this because you may have multiple users with hundreds of thousands of circuits that need to be executed at once. And now you need to be making optimal resource allocations. And this is something we also will work on when we, you know, with time. So we’re really not changing anyone’s scheduler. We’re putting in something that can be intelligent inside the scheduler to make better use of the resource system.

Yuval: I read someplace that someone said that you’re replacing 150,000 lines of code with 20. What do these 150 lines of code contain?

Stephen: I would say that’s a very, very low estimate. This is a bit of marketing that we do, but people can’t really distinguish in their brain 100,000, a million, 100 million. It’s a lot of abstraction in these huge numbers. But what this means is we take the application layer and we abstract everything outside of application away so that they can focus on just building the application. And because Divi is so simple to use, it’s simply populating about 20 lines of configuration code that will generate the entire workflow for them. And do optimization, and do transpilation, and do compilation, and do all this resource management. But from the user perspective, they only see 20 lines of code. So we’re handling so much of the infrastructure. We have, I don’t know, almost 40 repos in our GitHub. There’s so many packages that we separate and make services out of that they don’t see any of that. They see only that much, you know, the 20 lines. And that’s what we’re promoting there.

Yuval: I think you did a proof of concept or a project at CESGA. Could you tell me a little bit about that? What was the challenge? What were the results? What was the innovation that you added there?

Stephen: Yeah, so CESGA is very much aligned with the mentality of Qoro and Divi of Qoro in that distributed systems will work together. And what we did there is we used their software platform called CUNQA and CUNQA is integrated nicely with SLURM sessions so that you can allocate resources and do real-time computations mimicking a distributed quantum computing network. And what we did is we put our interface in place that points to their HPC center through a secure channel. And then we used their resources inside of CESGA allocating, I think in that experiment, quite some time, but I think we had 15 compute nodes mimicking a quantum computer, and we were generating the application load outside of the center. I was doing it from my chair at home, and we sent them 15, 20,000 circuits through this secure channel through our orchestrator and making the resource adjustments so that we say, this batch of circuits goes to compute one, this batch of circuits goes to compute two, this batch of circuits compute three, etc. And we made this interface with them. And later, what we did was introduce our simulation platform Maestro, which I was saying is this multi simulator automatic decision maker for which simulation choice to make, that sits also in CUNQA. And so the results were that we could make this connection and what was really nice about it is because we have these layers of abstraction, this took us just a day of wiring up the secure channel and once it was ready, everything was in place to start running. And so we ran a couple of optimization problems using this sampling approach where we needed a batch of circuits and it worked very well. I think the results were that it’s possible users can be sending jobs to HPCs from their home and you’d be using you know state-of-the-art simulation techniques on state-of-the-art compute technologies without having to purchase a thing and still use those 20 lines of code to do it all.

Yuval: I want to go back to my simple mental model of simulation and then a single quantum computer and then quantum with classical and then multiple quantum computers. I can understand the immediate need to do a parallel simulation today, but for the rest, you know, I work in a quantum computing vendor and I know that it’s hard work to make quantum computers, even a single one, truly useful. So to what extent are you ahead of your time? You know, when do you think people will really need this.

Stephen: I think it’s absolutely necessary. I mean, of course, you’re going to predict what I’m going to say, but it’s needed today. And the reasons are very simple. It’s simply imagine you’re an HPC center and you have one quantum computer. And let’s say that one quantum computer goes down. What do you do with your user base? Do you just let them sit for a week or who knows how long that maintenance is going to take to get it back online? And we see this repeatedly, even just yesterday, we were running experiments and not to throw them under the bus, but IBM, the network went down for about a day. And we needed those quantum computers. What do we do? They have six of them and they all went down. So you can imagine, what do we do in that situation? If with our platform, we can just point it to another backend and all those transpilation passes and all the complexity of accessing a new modality or a new vendor is all taken care of. So the user will never have downtime. And that’s my answer. People should be thinking about more quantum computers in the center because you need fallbacks, you need resilience, you need robustness. You can’t let your users sit idle if they’re spending a hundred thousand on a project per day or something. They’re paying contractors, there’s so much on the line, they can’t sit for a week when quantum computers are not accessible. So building multiples of them is just smart for that situation. When it comes to scaling applications, correct, I don’t think it’s necessary, but it’s more about the user experience and the production readiness and bringing it to market. You know, you can’t, for now, it’s, you know, individual sales one at a time, but in the future, I can’t imagine, even in the near future, if we want to be selling cloud infrastructure and cloud access to quantum computers, supporting a thousand users, can’t have one quantum computer. Need to have more.

Yuval: You mentioned user experience. So I wanted to latch onto that. So a user starts and does, you know, pip install Qiskit and starts working and running a sample program. When do you think the sort of light goes on and says, “Oh wow, I really need these Qoro guys.”

Stephen: Yeah, I mean, so what we see is we work with universities and they teach applications of quantum computers. And what that usually entails is pip install Qiskit, go to Qiskit guide and look at how to implement QAOA. And now they need to understand, you know, what different mixers are involved and how to set the layers of the QAOA and what optimization parameters to use. What optimizers to execute, build your own optimizer. And there’s a lot behind Qiskit, of course, and a lot of plugins for Qiskit, a lot of open source. But then you’ll see very quickly that you need to build a lot of pieces repeatedly from scratch, copy and paste different code snippets from different packages, or sorry, different examples, and then, you know, the lessons even just as a student complex. If you just want to know what is the input of QAOA and what does QAOA produce and now I want to compare against IBM quantum computer one or QuEra quantum computer two and see how do they perform differently. That’s what the students want, should be learning. They should be learning engineering problems not software bottlenecks. They should be being able to compare and contrast and test different methods instead of having to, especially in the era of AI that we have, we can get examples done, but what we can do is bring the complexities way up, sorry, not way up, way down, and see, okay, now people can just use QAOA out of the box as a tool, or use variational quantum algorithms as a tool, or build a quantum neural network as a tool, and this just speeds things up significantly. This is also a problem we face, is how do we convince people that this is still, this is the new way of quantum programming. Take the pieces that we know work and build on those instead of rebuilding the pieces that we know work every single time you want to do something new.

Yuval: Tell me a bit about the company. Size of company, where are you located, what is the funding situation, about the founders, anything you can share.

Stephen: So we started the company in 2024. We just passed two year mark this month officially. That was our incorporation date. And we’re incorporated both in the United Kingdom and in Germany. So I’m based in Munich and my co-founder, Dan, he’s based in the UK. And we come from a background of network technologies. I worked at Cisco as well as Dan, and I was researching quantum network technologies. How do you put quantum networks into practice? And part of that was in distributed quantum computing. And Dan has a long history of working in network technologies, deploying national networks and data center networks and working more on from the business side. So we are coming from, my background is in research and PhD level of education. Dan has a long history of working in the business units of networking companies. So we come together and Qoro was a perfect fit because we’re a networking quantum computing company. The team now is 10 full time, pretty sure. We’re growing quite fast and we lose track sometimes. We just raised a pre-seed in March and we’re looking into finishing a seed round coming hopefully by the end of summer.

Yuval: And if I were an HPC center, do I buy a license for a software package? Is that something that I use on the cloud? How long does integration take? I mean, take me sort of through the customer journey if you could.

Stephen: Yeah. So our products are threefold in a sense. We have our go to market or kind of landing page where, our landing product where people can sign up today, get an API token and start running immediately with no contracts, it’s pay as you go. We have the cloud infrastructure in place. So anyone can do that. There’s credits, it’s a credit system, very simple. And they can build their applications in Divi, run them in the cloud, get access to CPUs and GPUs, very standard. Then for enterprise-based customers, we have something very similar, but we dedicate all of the compute nodes for that customer. So if they have a team of researchers constantly running simulations and eventually accessing quantum computers, we provide that dedicated access as an infrastructure service. So it’s infrastructure as a service, for example. But when it comes to HPC, of course, they have a lot of constraints. They need a lot of on-premise solutions. And so with an HPC center, we have two different things that we offer them. Is one is purely our simulation capabilities. So the GPU based simulation and the CPU based simulation, of course, with some services and support around them as a company, but our software is also a lot of it is open source. So it’s an open core type model with premium features as a service. And that was the one thing that we, that’s one of the products we offer HPC. And then the second is an integration demo, for example. So this is the bottleneck generally is how do we integrate quantum into an HPC center and essentially deploy the software aspect of that via pure software integration where we mimic the quantum computer via emulation. So we still have all the software components in place, we still use control technologies, we still bring them the simulation aspects, but it’s as if the quantum computer was there but they don’t have to buy a quantum computer. At this play, it helps them to keep the cost down, keep the investment a bit more, a lot less risky, because if they need to invest a million or five million just to see how it feels to have a quantum computer, it’s a lot more risky if they can spend, let’s say, 100k or 200k to see the same thing. And so that’s how we approach HPC centers.

Yuval: Excellent. And so as we come to the end of our conversation today, I wanted to ask you a hypothetical. If you could have dinner with one of the quantum greats, dead or alive, who would that be?

Stephen: Yeah, I knew this question was coming, so I prepared a little bit. And my answer is mixed. I mean, I would like to have dinner with Claude Shannon, because I come from an information theory background, but he’s not exactly a quantum guy. So I changed it to John von Neumann, who took a lot of the information theory concepts and brought them to Qoro. Actually, I forget who did it first. I think Shannon may have taken from von Neumann, but I forget the history. But the reason von Neumann is also a great fit for me is he’s a scientist and an engineer and just explored so many different topics. And I love that you can take concepts from, I don’t know, all these different fields and bring them together into one. And I think this is what’s happening at Qoro is we’re looking at network technologies, interfacing, different hardware components, communication, latency, all these things that result from a lot of the technologies that he would have been highly interested in and definitely influenced. So John von Neumann is my answer. I think because of him, I’m here today being able to work on these types of topics.

Yuval: Wonderful. Stephen, thank you so much for joining me today.

Stephen: And thank you for the time and the great conversation.

—

First-person (host voice)

My guest today is Stephen DiAdamo, co-founder and CTO of Qoro Quantum. We talk about Qoro’s top-down, middleware-first approach to quantum computing, how their open source Divi SDK turns optimization inputs into parallelized batches of circuits, and how their orchestrator routes those circuits to simulation or to hardware across different vendors and modalities. We also get into where Qoro sits relative to schedulers like SLURM, the CESGA pilot using the CUNQA platform across 15 compute nodes, why an HPC center needs more than one quantum computer for resilience, and much more.

Third-person (editorial voice)

Stephen DiAdamo, co-founder and CTO of Qoro Quantum, is interviewed by Yuval Boger. DiAdamo discusses Qoro’s position as a software middleware company that abstracts hardware away from applications, walking through the Divi SDK, circuit serialization and parallelization, and an orchestrator that automatically selects between 12 simulation methods on CPU and GPU or dispatches to QPUs from any vendor. They explore how Qoro plugs into HPC schedulers like SLURM rather than replacing them, the CESGA proof of concept built on the CUNQA platform, the “150,000 lines of code to 20” claim, and the argument that multi-QPU centers are needed today for fallback and resilience and for scaling applications. DiAdamo also reflects on developer experience for students learning QAOA and variational algorithms, and Qoro’s two-year history.

Yuval Boger is the Chief Commercial Officer of QuEra Computing.