# Podcast with Sam Stanwyck, Product Manager for Quantum Software, NVIDIA

My guest today is Sam Stanwyck, Senior Product Manager for Quantum Computing at NVIDIA. Sam and I spoke about NVIDIA’s foray into quantum computing, whether their simulator would become obsolete when larger quantum computers are launched, new enterprise computing architectures and much more.

Listen to additional podcasts here

# THE FULL TRANSCRIPT IS BELOW

**Yuval Boger (CMO, Classiq)**: Hello, Sam. And thanks for joining me today.

**Sam Stanwyck (senior product manager, quantum software, NVIDIA)**: Hi, Yuval. Great to be here.

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

**Sam**: So I’m Sam Stanwyck and I’m a product manager for Quantum Computing at NVIDIA. And so, NVIDIA is building tools to accelerate quantum circuit simulation, and by extension, quantum algorithms research and quantum information science generally.

**Yuval**: So is that the main thrust in the quantum space? You’re not building computers, right? Or, it’s really about the simulators?

**Sam**: Yeah, that’s right. So we’re not building our own quantum computer. The goal is to kind of enable the whole ecosystem, so people who are building quantum computers and people who are trying to understand what to do with them.

**Yuval**: So when you decided to do this, you must have seen certain challenges for companies who are getting into quantum computing. Could you share what you found before deciding to launch this effort?

**Sam**: Sure. Well there are, as you’re well aware, a few sets of challenges. So there’s first, kind of obviously, there’s the fact that quantum computers need to improve by quite a lot before we’re able to do something valuable with them. So we need to increase the qubit count of quantum computers. And more importantly, reduce error rates to be able to run useful algorithms.

**Sam**: But then there’s also kind of a set of challenges around understanding what we’re actually going to do with those more powerful quantum computers once they arrive. And it would be unfortunate if we made a lot of progress on hardware and then didn’t have a good sense of what algorithms might be best suited to realize quantum advantage.

**Sam**: And so, our product is called cuQuantum. The idea is to enable people to more easily answer questions, like what quantum algorithms might be best suited for quantum advantage on a particular problem. How do they scale compared to the best classical algorithms? What sort of are the requirements on the quantum hardware in terms of scale and error rates? And what quantum processor architectures might be best suited to which problems? So I think those are kind of the key problems in the space that we at NVIDIA are hoping to help everyone answer.

**Yuval**: So if I use the cuQuantum library from NVIDIA, I think people say that depending on their level of entanglement and a couple other factors about 50 qubits is the limit on which you can no longer simulate quantum software on a classical computer. So does that limit change with an NVIDIA library? Or are the results just a little bit faster than you would do on a classical simulator?

**Sam**: That’s a great question. So there are a few different ways to simulate a quantum circuit. So what most people are familiar with, I think is called state vector simulation. And that’s basically brute force classical emulation of a quantum computer where you hold the entire state of the system and in memory. And so if that state is N qubits, that requires a vector of size two to the N. And so, that’s very powerful for simulating perfect or noisy qubits at arbitrary depth and having the flexibility to do things like mid circuit measurements.

**Sam**: But as you refer to in your question, the limitation there is the memory. So on a single GPU, it’s usually in the thirties of qubits that can be simulated. And even on a supercomputer, it’s usually somewhere in the forties, not more than 50 qubits.

**Sam**: But there are alternative ways to simulate quantum circuits. And so another library in cuQuantum is built around accelerating what’s called tensor network simulation. And so the idea with tensor network simulation is to model the quantum circuit as a network of tensors, do some optimization upfront to figure out an optimal path to contract those tensors, and then simulate the circuit by contracting the tensors one by one. And so it turns out that this kind of changes the scaling from this hard memory requirement with scale to the difficulty depending on the depth of the circuit and the entanglement of the circuit. And so it turns out that for a lot of practical quantum circuits that are candidates for near term quantum advantage, I’m thinking of variational quantum algorithms in particular, they tend to be pretty low depth and tend to be pretty low entanglement. And so the state vector simulation can often be overkill. And tensor networks allow you to scale to hundreds or sometimes even thousands of qubits, depending on the circuit.

**Yuval**: There’s a branch of computing that’s called quantum-inspired, where people say, “Well, we’ve learned some concepts from quantum computing. And now we’re going to run them on classical machines.” Is that what you’re trying to do here, basically bypass the need for quantum computers in a certain set of problems, such as the VQE that you described?

**Sam**: If something along that direction comes out of it, obviously that would be great, but that’s really not our goal. The goal is to build tools for people researching and developing quantum computers. And so, with both state vector simulation and tensor network simulation, I see them as ways to kind of look ahead and answer important questions in advance. So if we had 35 perfect logical qubits that we could run something to arbitrary depth with, what could we do and how would that compare to classical methods? Or if we had hundreds or thousands of noisy qubits and could run something to shallow depth, what could we do? And how would that compare to classical methods? So it’s really more around accelerating the quantum research ecosystem.

**Yuval**: Can this tensor network simulation be run on non-NVIDIA hardware? I mean, could we take the same approach and just run it classically on a classical CPU?

**Sam**: It can be run. These sorts of problems are very good fits for our GPUs. And so what we see when we use really cuStateVec or cuTensorNet compared to a simulator running on classical or running on a CPU, is at least an order of magnitude acceleration and often more. So I think for kind of just test, like trying out quantum algorithms, testing small circuits, that’s fine for CPUs. But then if you want to kind of push performance, GPUs are a very natural fit for this kind of work, really for the same reason that they’re a natural fit for deep learning.

**Yuval**: Do you see this product line as being transient? Meaning in a couple of years, there will be, we hope, quantum computers with hundreds or thousands of qubits. The qubit fidelity will be better. The gate error will be better. So will there still be a need in a couple of years for a library like cuQuantum from NVIDIA?

**Sam**: Yeah, it’s a great question. So in terms of cuQuantum, I actually see it becoming even more important, but maybe more targeted. So right now, while we’re still pretty far from quantum advantage and practice, there are a lot of big picture questions that we’ve talked about that quantum circuit simulation is helping to answer, just in sort of way ahead of today’s quantum computers in terms of scale and performance and answering questions about when quantum computers get there, how will they compare to classical classical algorithms on classical computers? As quantum computers improve, I think that picture will start clarifying and we’ll have a much better understanding of where we’re likely to see value in the space.

**Sam**: And then quantum circuit simulation will be really important for more specific problems like understanding what tweak to a variational quantum algorithm might make it scale better or be better suited to some particular molecular simulation, for example. Or given a certain average to qubit cubic gate fidelity, what variation on an error correction algorithm might work best for fault-tolerant quantum computing. Not to mention, quantum processors are going to be kind of still limited in availability for a long time compared to classical resources. So I still see researchers and developers doing most of their work on simulators for a very long time.

**Yuval**: Many of the quantum algorithms, and you mentioned VQE, are hybrid algorithms, where part runs classically and the other on quantum. Does cuQuantum allow me to do this, basically to simulate the quantum part on your simulator, but still run classically on a general purpose CPU?

**Sam**: Yeah, so a nice thing about cuQuantum that we haven’t really talked about yet is that it’s very low level. So in terms of state vector simulation, the API for cuQuantum is at the level of multiplying your gate matrix by a state vector. And so that makes it very kind of flexible and agnostic. And so cuQuantum is not a simulator itself. It plugs into simulators from Cirq or Qiskit or Pennylane, and accelerates them and doesn’t know too much about the circuit. So cuQuantum runs hybrid algorithms fine. It runs noisy gates fine, and you don’t really have to change any of your code in order to leverage it.

**Yuval**: So to use cuQuantum today, I could just deploy an instance on AWS, for instance, and just run it like I use any other GPU workload?

**Sam**: Yeah. That’s right. So we have an integration with the Cirq framework and QSim simulator from Google that’s publicly available today. So you can run through Cirq. And we also, as of a couple weeks ago, are actually offering a container that’s all of that packaged together. So you can just pull that container, deploy on your favorite cloud provider and run it as you would run Cirq with no changes.

**Yuval**: Very often when people speak about QPU’s quantum processor unit, they give the GPU analogy that we don’t expect to run Zoom meetings on quantum processors, but we expect them to be able to offload certain computational tasks from the general purpose CPU. Do you agree with this analogy? Do you think that in the future there’ll be CPU, GPU, QPU triplets? Or how does that work? How do you expect that to look in an enterprise architecture?

**Sam**: That’s another great question. So there are certainly some parallels between a GPU and a QPU in the way that they fit in an enterprise architecture, but also some major differences that are important to understand.

**Sam**: And I guess parallels, of course, there are a set of tasks where our GPU is much better suited than a CPU. It can achieve a dramatic speed up. We expect something similar for a QPU. Another parallel is that as people start using quantum computers as part of a hybrid data center, it’s going to be really important to think about the model for how quantum computers are co-programmed with high performance classical computing resources, as it was with GPUs in order to get the most out of them.

**Sam**: But for GPUs, we’re really at a fundamental physics level still talking about the same model for computing as a CPU. And so the applications where a GPU can be close to a drop in improvement are an extremely broad set of computationally intensive tasks. While quantum computers are a fundamentally different computing model based on fundamentally different physics. And so, on one hand, that’s extremely exciting. On the other hand, we’re still understanding how big the space is where we expect a practical advantage from quantum computers, but we do expect it to be much smaller. And so we don’t expect QPUs to be a replacement for things GPUs are good for. We see them as kind of complimentary in the data center.

**Yuval**: That all sounds fascinating. How can people get in touch with you to learn more about your work?

**Sam**: So I’m most available on LinkedIn. I think I’m the only Sam Stanwyck in the world. So if you search my name, it should come up. And I’d, yeah, love to connect with anyone.

**Yuval**: That’s great. Thank you so much for joining me today.

**Sam**: Thanks Yuval, it was great to be here.

*Originally published at **https://www.classiq.io**.*