To bring value to our users and clients with our systems we need our programing model to fit seamlessly into their workflows, where they can focus on their code and not have to worry about the deployment and infrastructure. In other words, we need a serverless architecture.
The rate of progress in any field is often dominated by iteration times, or how long it takes to try a new idea in order to discover whether it works. Long iteration times encourage careful behavior and incremental advances, because the cost of making a mistake is high. Fast iterations, meanwhile, unlock the ability to experiment with new ideas and break out of old ways of doing things. Accelerating progress therefore relies on increasing the speed we can iterate. It is time to bring a flexible platform that enables fast iteration to quantum computing.
At this year’s Quantum Summit, we debuted our 127-qubit Eagle quantum processor, and showed concepts for IBM Quantum System Two. Atop these crucial advances, we must prepare quantum computing to tackle some of the world’s most difficult challenges in energy, materials and chemistry, finance, and elsewhere — and perhaps areas that we haven’t considered yet. In order to apply quantum to real-world problems, though, we need to enter the realm of quantum advantage, where quantum computers are either cheaper, faster, or more accurate than classical computers at the same relevant task.
Integrating quantum into real-world workflows will take advancements across the stack. We need to think holistically about quantum performance, including the scale, quality, and speed of our processors. We are working to introduce new capabilities that take advantage of today’s classical computing resources if we hope to bring quantum advantage about, faster. Finally, we need to ensure that our users can take advantage of quantum resources at scale without having to worry about the intricacies of the hardware — we call this frictionless development — which we hope to achieve with a serverless execution model.
Earlier in 2021, we began efforts to remove bottlenecks in the execution of actual use cases of quantum hardware through Qiskit Runtime. Qiskit Runtime provides a containerized execution environment for classical code that has low-latency access to quantum hardware. This enables a wide variety of workloads that make iterative or repeated use of quantum hardware to execute dramatically faster than was previously possible. In fact, with Qiskit Runtime we were able to show a 120x speed-up on a variational quantum eigensolver algorithm compared to our previous circuit API model.
We need to enter the realm of quantum advantage, where quantum computers are either cheaper, faster, or more accurate than classical computers at the same relevant task.
In May, we launched Qiskit Runtime on a single IBM Quantum system and premium users within the IBM Quantum Network could execute programs pre-built by the IBM Developer team. Now, Qiskit Runtime is enabled on all IBM Quantum systems, and users can upload and execute custom programs.
We believe so strongly in the utility of this usage model that we are elevating Qiskit Runtime to be the standard interface for our quantum systems through two building block programs — the sampler and estimator — that will serve as primitives to connect quantum computation with classical computation via Quantum Serverless.
Qiskit Runtime enables fast execution of classical code, near the quantum hardware, and in the case of Qiskit Runtime base programs, tightly coupled with quantum systems. However, its container execution environment is somewhat constrained by the computing resources that are co-located with IBM’s quantum systems.
What if developers could access and integrate with the broader world of classical computing and services? We’ve begun thinking of the classical resources that are coupled with quantum systems as coming in two flavors:
On the one hand, we employ a flavor of classical computing that is closely involved in the generation of quantum circuits with the goal of pushing speed and full utilization of the quantum processor (i.e. Qiskit Runtime). This flavor drives the performance of our systems.
On the other hand, we also employ Classical computing power to enable new capabilities in quantum computation by incorporating Classical operations as a part of quantum programs at the application level (Cloud/HPC/GPU).
Our team has been researching methods to employ this second flavor of classical resources to allow us to explore larger problems and find more-accurate solutions with our quantum computing systems. These methods include circuit knitting, quantum embedding, and error mitigation. Circuit knitting uses classical resources to find useful cuts in the problem to produce smaller quantum circuits to run on near-term quantum devices, and then use classical processing to combine the pieces back together to simulate a larger problem.
A recent example1 we demonstrated is entanglement forging which exploits symmetry in chemistry problems to simplify the knitting. Meanwhile, quantum embedding re-frames the problem to allow classical computers to simulate those pieces that can be well-approximated classically, while looping in quantum resources for only the classically difficult parts of the problem. In the context of chemistry, this might describe an active-space calculation that runs on the QPU with a Hamiltonian iteratively updated by a classical simulation of the inactive space.
Finally, error mitigation uses classical post-processing in order to reduce the impact of some classes of errors and get a more-accurate quantum solution. We hope that Quantum + Classical will allow us to realize quantum advantage in certain applications sooner than expected
To bring value to our users and clients with our systems, we need our programing model to fit seamlessly into their workflows, where they can focus on their code and not have to worry about the deployment and infrastructure. In other words, we need a serverless architecture.
A serverless architecture incorporates four key attributes:
- A developer focuses on coding only, with no need for infrastructure management consideration
- Everything is a cloud service
- The service requires no capacity or life cycle management considerations and scales seamlessly
- Users pay only for consumption, never for idle time.
IBM Cloud Code Engine will allow us to establish a serverless programming and operations model. Today, we are giving a glimpse of the future with a simple demonstration of how we can use IBM Cloud Code Engine with Qiskit Runtime as the quantum system interface to allow users to seamlessly use CPUs, GPUs and QPUs as part of a single application.
What would this workflow look like for a complex quantum problem?
First, a user submits an application incorporating both classical and quantum code to the IBM Cloud. IBM Cloud Code Engine delegates classical logic to scalable classical computing resources, and quantum to Qiskit Runtime, communicating with classical compute resources when necessary to prepare circuits and perform post-processing. This architecture allows quantum and classical to work in parallel: quantum to call classical and classical to call quantum. Doing this will enable capabilities such as circuit knitting, error mitigation, and circuit embedding to become part of the standard development workflow.
By rethinking the way that quantum programs run, we hope that users will be able to explore even more complex quantum computations, and more-easily realize quantum advantage. Most importantly, it will be easier than ever for users to explore quantum processing as part of their computing workflow. We have shown a proof of concept for Quantum Serverless, and this is how we see the future programing of quantum computing evolving.
We look forward to bringing this flexible serverless architecture to our users soon. We’re glad to have you on this journey as we work to make quantum computing as accessible as classical computing to organizations around the world.
Date16 Nov 2021
Eddins, A., Motta, M., Gujarati, T., et al. Doubling the size of quantum simulators by entanglement forging. arXiv. (2021). ↩