This article started off intending to demonstrate how using Q-CTRL’s Fire Opal application can save you money on quantum computer hardware access. And it’ll start off doing that. But as experimentation is prone to do, an unexpected twist was discovered along the way.
A graphic of how Q-CTRL’s Fire Opal works to find innovative solutions. (PC Q-CTRL)
First: Saving Considerable Money
Q-CTRL has published an article titled “Reducing quantum compute costs 2,500X with Fire Opal” in which they claim “the estimates went from a projected $89,205 for a single run of a QAOA algorithm to only $32” using Fire Opal’s QAOA solver.
Without getting technical, QAOA uses a parameterized quantum circuit. We guess the parameters and then run the circuit. Based on the results, we iteratively adjust the parameters and re-run the circuit until we arrive at an acceptable solution approximation.
What we’re concerned with here is the cost of running that circuit. Every time we run that circuit, we incur that cost. Consequently, our goal is to run this algorithm with the fewest possible iterations. Doing so is both faster and cheaper.
I have personally benchmarked Fire Opal’s QAOA solver against two other QAOA solvers, and there’s no question that Fire Opal reduced this number of iterations. Fire Opal dramatically improves the quality of each iteration’s results so that you actually arrive at an approximate solution. To be honest, I gave up on the other two solvers. So, while I’m not personally going to spend $90,000 just to verify Q-CTRL’s claim of 2500X, I can verify that Fire Opal stops running circuits when it arrives at an approximate solution, while I can’t verify that the other solvers get there at all. The featured image at the top of this article came from Q-CTRL and shows a 5700X savings, but it doesn’t have an associated article to link to.
Second: Spending Infinitely More Money
What we really ought to be interested in, though, are algorithms that are intended for fault-tolerant quantum computing (FTQC). These algorithms take so long to execute that today’s quantum computers return sheer noise. While we normally focus on the quality of the results or lack thereof, we may also need to consider runtime. A price model might be based on how many times we’ll run each circuit, but it might also be based on how long it runs. If Fire Opal can improve the efficiency of circuit execution, that might translate into lower runtime-related costs.
I use the Classiq Platform’s Python SDK to synthesize huge circuits, such as those required for quantum phase estimation (QPE). If we want to see how much less expensive Fire Opal is, we’ll need to run the largest possible circuits so we can see a clear spread.
I started with molecular hydrogen (H2) with one counting qubit. If you’re unfamiliar, QPE calculates the ground state energy of molecules using one register (data qubits) to represent the molecule and one register (counting qubits) to determine the precision of the solution. Ideally, we want to use eight counting qubits for H2, but I’ve already tested that and current hardware can’t handle it. H2 requires only one data qubit, so this first circuit only used two qubits in total.
Both Qiskit and Fire Opal used seven seconds of IBM Quantum runtime. However, Fire Opal automatically applied error mitigation, which consumed an additional 21 seconds of runtime. To be fair, I applied Qiskit’s equivalent, called M3, and M3 used only 11 additional seconds of runtime. For H2 with one counting qubit, Qiskit actually won the runtime comparison.
But I then tried H2 with two counting qubits. The Qiskit job failed, whereas the Fire Opal job completed with enough accuracy that you can roughly estimate the solution. The precision is far from where it needs to be, but it’s at least in the correct ballpark.
And therein lies the unexpected twist. The cost of the failed Qiskit job is $0.00. Because the Fire Opal job completed, ironically, it’s infinitely more expensive when using an IBM Quantum premium plan.
Furthermore, Fire Opal can push past H2 with two counting qubits. I’ve personally pushed it to H2 with 6 counting qubits as well as to molecular oxygen (O2) – which requires 11 data qubits – with 2 counting qubits. O2 with 2 counting qubits consumed 4 minutes 28 seconds of IBM Quantum runtime, and the result still keeps you in the correct ballpark. Pushing further returns error messages from IBM Quantum.
Therefore, the largest QPE circuit that can run on current hardware, consuming 268 seconds of runtime at $1.60 per second, costs $428.80 using Fire Opal with premium access to IBM Quantum hardware, or $0.00 without Fire Opal because the job will fail.
Conclusion: Fire Opal isn’t Necessarily Cheaper
They say that “quantum” is unintuitive, and it never fails to disappoint. Instead of being less expensive by running fewer iterations or shortening runtime, Fire Opal ends up being more expensive because you can push it further. You can run an algorithm that might otherwise cost $90,000 because it’s not going to cost anywhere near that. And you can run circuits that would otherwise fail and cost nothing. Therefore, Fire Opal is more expensive simply by virtue of actually working.
Brian N. Siegelwax is an independent Quantum Algorithm Designer and a freelance writer for Inside Quantum Technology. He is known for his contributions to the field of quantum computing, particularly in the design of quantum algorithms. He has evaluated numerous quantum computing frameworks, platforms, and utilities and has shared his insights and findings through his writings. Siegelwax is also an author and has written books such as “Dungeons & Qubits” and “Choose Your Own Quantum Adventure”. He regularly writes on Medium about various topics related to quantum computing. His work includes practical applications of quantum computing, reviews of quantum computing products, and discussions on quantum computing concepts.