 I'm Blake Johnson and I'm the Quantum Platform Lead at IBM Quantum. Today I want to tell you about bringing classical to quantum. And we're going to continue the story that Jay started. We introduced the three factors that determine quantum system performance. The scale, quality and speed. Let's look at each in turn. Scale is the number of qubits in our system and it directly determines the size of the problem that we can encode and eventually solve with quantum hardware. This is the reason we must continue investing in hardware technologies to ensure scale advances each year. The second is quality. This is a measure of how large of a quantum circuit we can execute without too many errors. And third and finally we have speed. This is a measure of how fast our systems can solve a problem. We need to be able to solve problems in a reasonable amount of time or we don't have a business. We continue to make advances on all elements of system performance every year. On scale, in three years we've watched three successive generations of quantum hardware. Leading up to this year's 127 qubit Eagle processor. On quality, we've doubled quantum volume every year showing quantum volume of 128 in the past year. And at speed, we've completely re-architected our systems to take what was previously a months-long calculation and be able to complete it in just a few hours. Today we're going to look closer at that system architecture that enabled that speed up. In order to appreciate the problem of speed, we have to consider that real problems, real workloads, are not purely quantum but involve interactions between quantum and classical resources. But if you look closer at these interactions, you notice they come in several different varieties. There's a real-time interaction domain involving feedback and feed forward of quantum measurements to enable dynamic circuits and steering of a computation in real-time. This is a very demanding latency domain in order to get the data to different parts of the quantum processor in time to execute it. There's also a near-time interaction domain which doesn't have the same stringent latency requirements but really demands a much more generic computing facility. These latency domains are sufficiently different that we've built different technologies to address each of them. In the real-time domain, we've extended the description of quantum circuits to incorporate that real-time classical computation into a new version of the open chasm circuit description language. The near-time domain is enabled through a technology that we call the Kiskit runtime. The Kiskit runtime is a container execution environment for classical code that executes an environment which is tightly coupled to our quantum hardware. The Kiskit runtime changes the use model for quantum hardware so that instead of submitting circuits, you can now submit a program. And that program will execute near-co-located with our quantum hardware in one of IBM's quantum data centers. When we initially launched the Kiskit runtime, we set ourselves a goal of showing 100x speedup on a chemistry problem, which seemed like a very difficult goal. But we are very pleased we could actually surpass that goal and show 120x speedup on a chemistry simulation thanks to improvements across the hardware and software stack. You can directly observe the impact of the Kiskit runtime itself in the figure on the right-hand side of your screen, which shows the iteration trip times in a variational algorithm where the circuit model API times are shown in blue and the Kiskit runtime is shown in green. You can see that we take what is almost a two-minute round-trip time down to just about 20 seconds, which is a little over 4x increase in speed from the Kiskit runtime alone. We have recently been able to greatly extend the number of users through a partnership with the team at StrangeWorks. To tell you more about that, I'm delighted to invite to the stage Worley, CEO of StrangeWorks. Thanks, Blake. I'd like to tell you all today about what we've been able to do using Kiskit runtimes on the StrangeWorks ecosystem. To start, we're able to integrate it to thousands of customers in over 120 countries, and we'd like to show you a demo of exactly how you can use it on the StrangeWorks platform. So if you go to quantumcomputing.com, you simply need to go to the hardware tab, and on the right-hand side, you'll see Kiskit runtime access. Once you've clicked there, you can see all of the available runtimes that we have deployed so far, and especially the one we're going to use today for our demo, which is a variational quantum eyeing solver. So from the Kiskit runtimes page, we'll just select it and then look at the code. Once we get into the VQE example, you can see that there's an example set on how to run it, as well as a ready-to-run section. So one thing that makes this different for our users is instead of the normal flow of code we see, we get all the input and output parameters for the program. So users need to simply go to the hardware page, access the Kiskit runtimes, and then they can run them directly on the StrangeWorks ecosystem. So once we get the code, we can simply go to Run, and this will execute the job and send it to the IBM quantum machines. So you've seen we've been put in the IBM Q. In a moment, we'll get the results back, and here they are. As you can see, we have the circuit gate, we have the optimization of the variational quantum eyeing solver, and we have all of the other reporting brought back to us thanks to the benefit of Kiskit. So this is a great result, but what's more important is seeing this used in the real world. What we've done is worked with Deloitte and IBM to deploy Kiskit runtimes for their quantum development. This has led to them seeing an increase in speed on the variational quantum eyeing solver of 42 times. This is a dramatic speedup enabling Deloitte to work better and faster to achieve their quantum strategy. This is really great to see. Is this available to all StrangeWorks users today? This is available to everyone that can sign up both not only for our paid platform but also for the free platform available at quantumcomputing.com. I'm excited to see what you guys have built with Kiskit Runtime. Thanks for coming. Thanks for having me. All right, to wrap up this section, let's look back at this year. In May, we launched the Kiskit Runtime on one IBM backend on the IBM Cloud. At that point in time, a small number of premium users could execute Kiskit Runtime programs pre-built by the IBM developer team. As of a few weeks ago, the Kiskit Runtime is now available on all backends on the IBM Cloud, and our premium users can upload and execute their own quantum programs. Next, we're going to look at using the Kiskit Runtime as a cloud-native service on the IBM Cloud. To tell you about that, I'm going to throw it to Carl Weiden, our program director for IBM Quantum Cloud Services. I'm Carl Weiden, program director for the IBM Quantum Cloud. And I'm here to talk to you today about quantum in the service and the work that we're doing in this area. IBM Quantum Services is starting to expand the accessibility of quantum overall, and we're starting that journey with IBM Cloud. IBM Cloud offers great combination of core technologies like data management, AI services, serverless HPC, and the limitless capacity of the cloud overall. What does this fundamentally mean? It means that we're going to be able to give you clear visibility of how to use the cloud to enhance your tools. We are expanding accessibility of features specifically for third-party product developers, including things like the ability to integrate accounts and resources across IBM Cloud with IBM Quantum Services to deliver unique capabilities. That means you can select things like systems based on availability and not just specification so you can get your work done faster. And that combined with scalable classical compute, like serverless HPC, gives you an unparalleled level of power to execute combined workloads that include high-rid quantum classical algorithms and other new techniques that are part of the story. So what's new for expert users? We are really focused on giving the area of research and development our full attention, and we are there to give you access to larger and better devices, experimental devices in certain cases, and we peel back all layers of abstraction so you can pick the exact system that meets your parametrics and specifications that you need to execute your experiment or ongoing evaluation. And more importantly than anything else, you can pay for exactly what you need and still get access to these core systems as part of that story. What's changed? A lot. What's not changed? We've been exposing quantum systems on the internet for over five years and we've learned a ton and we're here to make this simpler and easier to use. All you have to do is create an instance, select a plan, and you are ready to execute your quantum workloads overall. We're really excited to bring this to you but it's a process, so we're starting in January with a limited beta release. The whole idea here is to get some feedback from core users so that we can make sure that when we get to March, which is our full beta, we will be comfortable turning on pay as you go access. We'll give you way more systems to use as part of that story and we're going to continue to add exciting, powerful systems over time. In summer, this is really we're going to focus on making sure that we understand the type of workloads that we support today and how they could potentially transition. So we'll allow you to look at IBM Cloud as a viable alternative to some of your existing agreements. We're going to continue to add exciting exploratory systems and features and we're going to continue to make it simpler to use overall as part of that story. But it's important to note that during this process, all your current access models and contracts will remain unchanged and we're going to continue to work with you if you're an existing quantum network member. So that's what we have in store for you in terms of quantum as a service. We're really excited to embark on this journey with you. We really appreciate your time. We're looking forward to working with you on this process and thanks so much. Back to you Blake. Thanks Carl. Now I want to give you a glimpse into where we are going next. It's something we call quantum serverless and it aims to allow an even greater amount of flexibility and experimentation to what you can already do with the Kisket runtime. To give you an idea of why this matters, let me return to some of the concepts that Jay introduced. Jay told you about a variety of techniques that allowed a developer to trade off quantum and classical resources. These techniques include things like circuit cutting which can reduce the width or depth of a circuit and use classical post processing to reassemble the execution of the entire thing. The entanglement forging work we published this year is an example of this technique where the post processing cost is small because it takes advantage of a symmetry of the problem. Error mitigation techniques are another class of methods that extend the power of quantum circuits with classical post processing. This year, we extended the reach of error mitigation to simulation of a 2D icing lattice on our Falcon processors. In general, we believe that combining quantum and classical computation can extend the reach of near-term hardware by allowing execution on smaller or noisier processors. Furthermore, quantum plus classical increases computational accuracy, letting us get meaningful results all sooner. In combination, our devices will be able to outperform classical computer sooner than they could otherwise. Taking advantage of these techniques can require substantial classical computing resources. Let me invite Michael Berent, Distinguished Engineer and Chief Architect of IBM Cloud Functions to join us to tell you about how you can flexibly combine the entire world of cloud computing technologies with quantum. Hello, my name is Michael Berent. I'm part of the IBM Cloud Development Organization and they're responsible for everything around serverless. I want to talk a little bit about serverless. So what are the three key attributes that constitute serverless from our perspective? The three key attributes are the developer and the scientist only focuses on the code. They never have to deal with infrastructure or infrastructure management. They do not have to worry about capacity management, about the lifecycle management of capacity, like bringing up machines, tearing them down. And as a result of that, they don't have to worry about seamless scaling either. Also, they only pay for consumption, like they never pay for idle capacity at all as part of this. From a product perspective, IBM Cloud Code Engine is our service that implements all of these attributes for a variety of artifacts, be it containers, be it batch jobs, be it apps, be it functions, and so on. And what we're doing together with the quantum team is we are establishing a serverless programming model that allows us to very flexibly combine QPUs, CPUs and GPUs as well. How does this look like from an architectural perspective? On the left-hand side here, we see there is a quantum application. The quantum application consists out of a quantum part and a classical part in most of the cases. So what we are introducing is IBM Cloud Code Engine as the component that knows how to delegate quantum logic to the quantum cluster and classical logic to the classic cluster. And the classical cluster can have GPUs or CPUs included. From both of them, data can be accessed either as input for the processing or as a result of output of the processing. What are the attributes that developers need in order to use quantum and classical compute in combination? One important aspect for us is we want developers to be able to reuse their existing skills. Skills in terms of programming languages, we are focusing on the Python ecosystem here. Skills in terms of tools they are using for debugging, development, monitoring, operational management and so on. We want to make it as simple as possible for them to specify the processor architecture, the memory they need, the compute capacity the region they are running in. Like I said before, we want them to do it in a serverless fashion meaning they only focus on their code and never worry about the underlying infrastructure in any way. And they want to do this for both sequentially dependent and embarrassingly parallel algorithms. So algorithms where one step depends on the previous one versus other algorithms where things can be executed in parallel without any interdependencies. I want to talk about two scenarios where this is really relevant. Scenario one is about using classical compute to run expensive classical computation. That could include for example, very compute-intensive or data-intensive pre-processing of data which is then used in a second step for running the quantum logic. And the way we set up things like I indicated before, it is easy for the developer to all represent this in one application that has the quantum and the classical part to it. And then co-vention will take care of delegating first or after the classical part to the classical cluster and the quantum part to the quantum cluster and then also establish a connection between the two of them if data needs to be handed over for example from one to the other. The second scenario that is really interesting here is processing a large quantum circuit by using classical compute in support of that. Like you've heard before from Blake it is possible for us to cut a large quantum circuit, a quantum circuit that's larger than what we can usually process in a standalone fashion into smaller quantum circuits and then have them run on smaller quantum machines and use the partial results that come back in order to compose the overall result out of it. And we do that by using classical compute. So classical compute cuts the circuits into smaller ones and once they are done processing with the quantum machines we take the partial results that came back and return them back to the requester. So let's have a look at the anatomy of a quantum application and how that really looks like from a semantical perspective. On the right hand side here you can see an example that illustrates how this would look like. We are using this concept of decorators here which are these lines of code that start with an ad and the decorators just give the execution engine hints about which architecture we want to be used for which part of the application. So you can see here the first one the pre-processing logic is run on CPUs the quantum logic is run on QPUs and the classical post-processing logic in this case is run on GPUs. And we can imagine also tying in additional processor architectures down the road as this allows us to do not only local optimization execution optimization for the respective processor architectures but also cross processor architecture optimization in terms of co-location memory sharing and things like that. I want to talk about the variational quantum eigens solver scenario that you've probably seen at Think and other occasions where we presented this. We want to take this same scenario but illustrate how we can solve this or implement this in a slightly different more flexible way. In the first part we define the problem by configuring some numbers. In the second part which is now new to this scenario we are calling the cloud orchestration capability of code engine where we basically tell the system which function in this case the minimize energy function should be executed and which parameters should be used in the context of that of that is execution and you can see here those parameters are the ones that are defined in the upper half of this slide. And what we're doing in the minimize energy function is we both set up the logic that is needed in order to report execution progress to the outside world to the developer for example who is sitting in front of the screen and waiting for the results and we are also defining the actual business logic that should be executed both the quantum part and the classical part and also the part that combines those two. And the interesting or important part here is the developer literally only writes that code and executes it. I also want to show you a little bit of an animation that illustrates how this would look like on a graphical level. So here you can see the code that we talked about before on the laptop of the developer we have the classical data center on the left the quantum data center on the right and we see the delegation happening to the orchestration component of code engine that code will then open up a session with the Qiskit runtime. It will write parameters into that session and receive values from it by reading from it and it will do that in an iterative way to iterate its way towards a converging value which then represents the result that we want to get out of this calculation. So as we report progress we can for example graph it on the user's laptop and we'll see it's going to converge towards a certain value. So here we can see how the numbers look like for a number of these iterations. We start with a certain number we we iterate our way towards more stable numbers and about at the 30-33 iteration we see the number basically being stable which means we found the result of this calculation. Another important part is we talked about general purpose classical compute execution. Of course this can be done in a more traditional code execution environment on classical compute hardware but it can also be done in an HPC environment where we have very large machines where we maybe have special specific accelerator hardware where we have network communication that's more sophisticated than in classical environments. So there are various ways for us to optimize also on the classical compute execution side. So with that I want to thank you for listening. I hope you enjoyed the session. I would encourage you to go to our quantum computing webpage where you can find additional information and try things out by yourself. Thank you. So to recap our plan is to leverage the serverless framework that brings high performance computing to the cloud by combining it with quantum. In doing so we can empower the developer with tools that they already know how to use like IBM code engine. We will bring the developer philosophy to our researchers and we will give quantum technical services tools that will scale quantum computing. In all of these steps we combine quantum and classical computing to accelerate our path toward quantum advantage.