by: Yuval Boger, QuEra Computing

Every quantum vendor talks about scale. Most of the time, that means a qubit count on a slide.

At Quantum World Congress last month, I sat on a panel called “Assembling Quantum: Hardware, Software, and the Road to Scale” with David Rivas, COO of Rigetti, and Jason Silbergleit, head of Americas at Classiq. Victor Bucklew of the University of Maryland moderated. We had hardware, software, and the road to scaling all on one stage, which seemed appropriate.

The moderator’s first question was the right one: what should scaling actually mean? My answer is that a qubit count is not the measure. Two questions are.

How big, and how long

Quantum computers exist to solve problems customers care about. To do that, you need to answer two things.

First, how complex an algorithm can you run? If the machine can only execute a short circuit before errors take over, it is like a spreadsheet with ten cells. Nice to look at. Not very useful.

Second, how long does it take? Even if you can run a very long calculation, it does not help if the answer arrives in two years. Wall-clock time matters as much as circuit size.

Everything else sits one layer below those two questions: usability, security, reliability, cloud or on-prem access, and integration with classical compute. Jason made a strong case for that layer, and he is right. An enterprise will not adopt a system that cannot pass a security review or run inside its own environment. But those requirements only matter once the machine can run something worth running.

David sharpened the point on stage. When we say operations, we mostly mean two-qubit gates, the quantum equivalent of an add or a multiply. Today’s best physical error rates are around one error in every thousand to few thousand operations. That is real progress, and it would also make for a useless laptop. Long calculations require error correction, which is why we focus on fault tolerance. It is the path from “quantum works” to “quantum solves the problem.”

Scaling up without building the Hoover Dam

Vendors scale in two ways. Scaling out connects machines together; David described how Rigetti uses chiplets to link smaller pieces of a QPU into one larger system. Scaling up adds more qubits to a single system.

Neutral atoms are well suited to scaling up. We have demonstrated 3,000 qubits in a system, and we expect to deliver a 10,000-qubit system in 2028. The computational core is about the size of my fingernail. It is surrounded by lasers, lenses and cameras, but the qubits themselves are atoms held in light, and adding more of them does not require rebuilding the machine.

The second part of scaling up is the infrastructure needed to install a computer. Some approaches require cryogenic cooling, large power budgets and purpose-built facilities. At the extreme, one planned system is the size of a football field, draws on the order of 100 megawatts and costs around a billion dollars. That is the B-2 bomber of quantum computing.

We are trying to build the Boeing 777. Our systems fit in roughly the footprint of two large dining tables, use about 50 kilowatts and need no cryogenic cooling. For an HPC center, that makes installation a procurement exercise, not an infrastructure project. It is like putting in a new kitchen, not building the Hoover Dam.

This is not theoretical. Our first machine, Aquila, is approaching four years on Amazon Braket, available about 130 hours a week with 99% uptime. We have installed a system on-premises in Japan. And with AWS, we have announced a fault-tolerant quantum computer with 256 logical, error-corrected qubits in 2028.

More science, less fiction

This industry has a science fiction problem. Quantum is inherently exciting: spooky action at a distance, God not playing dice. And some of us in the industry, myself included at times, have overstated what today’s machines can do.

Our approach with customers is to listen first. What problem would make a real difference to your organization if it were solved? Then we go through a realistic and sometimes disappointing exercise: does that problem fit, at a meaningful size, on this generation of hardware?

If you bring an optimization problem and the answer is three variables, you can solve it in your head. If the answer is three thousand variables, that is a different conversation. More often than you might expect, we tell a prospective customer that the problem will not fit yet, and to come back in two years. We would rather have a successful project later than a disappointing one now.

David put it more bluntly: the first thing Rigetti tries to do with customers is not lie. I agree. Credibility is the scarcest asset in this market, and every overpromise spends some of it for all of us.

That honesty also explains the timing of our AWS announcement. Some analysts asked why Amazon, which usually launches services you can use the same afternoon, would announce something two years out. The answer is that customers need time to prepare. Jason made the same point with a good question for the audience: if you had known two years in advance that ChatGPT was coming, would you have prepared differently?

Engage, but engage through co-design

The panel closed on what we each want to see in the next year. Jason’s answer was to engage: tools are far more accessible than they were 18 months ago, and AI plus good software has lowered the barrier to entry.

I agree that organizations should engage now. I would add that how you engage matters.

Quantum computers are still early, and each one is different. They have different strengths, different weaknesses and different native operations. Abstraction is valuable, and I spent years at Classiq building it. But at this stage of the industry, abstract away enough layers and you get software that works equally poorly on every computer.

So my advice is to pick one or two hardware vendors you believe in and co-design with them. Ask:

• Can we fit the problem on this machine?
• Can we scale it as the hardware grows?
• Can we optimize it for this hardware’s specific capabilities?

That is how you get the most out of any given machine, and how you build the expertise that will pay off when fault-tolerant systems arrive.

David added a point every buyer should hear: do your homework. Product flyers and conference stages are not enough. An informed buyer who can ask a vendor hard questions, and understand the answers, will get further than one who spins up a team because a keynote said quantum is here.

The bottom line

We used to say useful quantum computing was five to ten years away. Today, the people building these machines are talking about two. That is close enough that preparation is no longer optional, and far enough that honesty about current limits still matters.

When you hear a vendor talk about scale, ask the two questions. How complex an algorithm can I run? How long will it take? Then ask what it takes to install the system, and whether the vendor will work with you on your specific problem, including telling you when it does not fit yet.

My thanks to Victor, David and Jason for a substantive conversation. The full panel is below.