Quantum Annealer Versus Classical Solver on Live Portfolio Optimization

We raced a quantum annealer against a classical solver nearly 2,000 times at our Quantum.Tech World booth, on portfolio problems that conference visitors created. The classical solver never came back with a better portfolio.

Every one of those races ran as a job on Quip Network, the decentralized marketplace where hardware providers list spare capacity on their quantum processing units (QPUs), consumers submit workloads and pay for what they use, and the network routes, verifies, and settles the work. Our event recap covered the booth and the competition, and this is the technical write-up we promised there, covering the method and the full two days of results.

The trading game

Every visitor built an agent. They started with a watchlist, at least fifteen names out of a 28-asset universe split evenly between cryptocurrencies and stocks. Four sliders set the strategy:

• Risk preference set how much volatility the agent would accept for a given expected return.

• Max position size capped how much of the money could sit in any one name.

• Number to hold fixed how many watchlist names it would own at once.

• Rebalance set how often it reoptimized, anywhere from every 30 minutes to not at all.

Once an agent launched, it traded a virtual $10,000 against live prices, reoptimizing on whatever schedule its owner had set.

Each press turned that watchlist and those sliders into an optimization problem, and the problem went to two solvers at once, a classical one running on an ordinary CPU and a quantum annealer in a data center, a D-Wave Advantage QPU. The two raced to optimize the portfolio, and the better portfolio won. Over the expo's two days that race ran 1,930 times, on problems chosen by close to a hundred different visitors.

The leaderboard

The winning agent ran an unusually concentrated strategy. Its owner picked a 15-name watchlist mixing crypto with quantum-hardware and big-tech stocks, set risk preference and the position cap to their maximums, and the number to hold to three names. The agent ran 11 optimizations over its roughly 20-hour life, most of them on its two-hour auto-rebalance schedule, and the QPU's answer won all 11 optimization races. It finished up 4.05%, or $10,404.53 on the virtual $10,000, holding an 85% position in IBM with the remainder split between Bitcoin and Zcash. The agents in second and third finished at +3.23% and +3.14%.

What we were testing

We set out to answer one narrow question about quantum hardware:

On a live problem, under conditions that give the machine no hidden advantage, how do its answers and its speed compare with the classical solver you would actually deploy?

That makes this a time-to-quality test on live financial problems. Quantum advantage is a stronger claim, and establishing it would take a broader test than this one.

A conference booth is an unusually good sampling frame for that question, because we didn't choose the problems. Each one came from whichever assets a participant liked and whichever sliders they set, and every race is in the counts below.

The problem underneath the game

Underneath the sliders and the leaderboard, every press posed the same textbook problem, cardinality-constrained mean-variance portfolio selection. From a watchlist of n names, hold exactly K of them, and choose how much of each to hold so the portfolio trades expected return against risk. A lower score means a better portfolio, and that score is what the two solvers competed on.

Once you know which names to hold, setting the weights takes milliseconds. It's a smooth problem with a single best answer, and a convex optimizer returns it directly. Choosing which names to hold is the hard part. That's a discrete search over every way to pick K of the n names, C(n, K) of them, with no smooth shortcut and no gradient to follow, which makes it NP-hard in the worst case. Because all of the combinatorial difficulty lives in that one choice, we raced the two solvers on the choice alone and let a single classical step handle the count and the weights.

Making it a fair fight

A quantum-versus-classical comparison is only as good as its setup, and most ways to get one wrong come down to handing the two solvers different problems or different amounts of help. We gave them the same question and the same finish.

What the solvers actually see

The solvers only ever see the selection, and not the constraint that comes with it. Each one gets one yes/no question per name, hold it or not. There is no “exactly K” rule inside that question and no weights to set, just a score over yes/no choices that rewards high-return names, charges for names that move together, and adds a further charge for holding correlated pairs. One binary variable per name, carrying linear and pairwise-quadratic terms and no constraints, is a QUBO (quadratic unconstrained binary optimization). That is the form a quantum annealer minimizes natively, which is why the selection is the only part we hand it.

The selection score ranks a candidate set as if the money were split evenly across it, and the shared finish then re-scores every candidate by the true objective.

Why the correlated-pair charge is there

We didn't add that charge to help the hardware. It's a real portfolio preference, and the backtests support it. On the booth universe, out of sample, baskets built with the term earned better risk-adjusted returns than baskets built without it. At the full 28-name universe it produced a daily Sharpe of 0.057 against 0.047 and beat the no-term version in 46 of 82 rolling windows. The effect was modest at the smallest baskets and clearest at the large, tangled ones.

The term also makes the selection harder to search. It leaves the problem frustrated, which is the physics term for a system whose parts cannot all be satisfied at once. Names that are attractive on their own start pulling against one another, so the space of possible baskets fills with competing near-best answers instead of one obvious winner. We raise the term as the basket grows, so a 15-name watchlist gets a gentle version and the full 28-name universe the strongest.

The shared finish

Whatever subset a solver settles on runs through the same two classical steps:

• Repair the selection to exactly K names.

• Solve the weights with a small convex optimizer that returns one provably best answer.

That optimizer works between a floor and the cap rather than from zero, so a name that makes the cut has to hold a real position instead of the rounding error an unconstrained solver would nudge it toward. The floor moved with the portfolio, landing between roughly 3.5% and 6% of the money.

The “exactly K” rule and the weights live entirely in those steps, never in what the solvers search. Because the finish is identical, two solvers that pick the same names get the same portfolio and the same score, so they can only differ when they pick different names. When one portfolio beats another, the gap measures which solver found the better set of names and nothing else.

Both solvers got the same 10-second deadline and the same 500-read sampling budget, so neither ran out of time.

The result

At the booth, across all 1,930 head-to-head races, using the live system's own threshold for materially better (a half-percent gap in the objective), the races broke down like this:

Drop the threshold to zero, so that any better objective counts, and it doesn't change:

When D-Wave won, the margin was usually large. The median quality win improved the portfolio's objective by 2.56%, roughly five times our materially-better line, and in the most lopsided race the quantum portfolio's objective was 199% better than the classical one's. Those are the races where the two solvers picked different baskets.

Controlled lab runs explain the gap. There we check both solvers against Gurobi, a classical exact solver that certifies the true optimum at these problem sizes, so optimal here means certified-optimal and not just the best answer anyone saw. At booth basket sizes, the QPU's 500-read runs recovered the certified optimum in our replays, every time at 20 and 28 names and about seven times in ten at the smallest 15-name baskets. The simulated annealing configuration we deployed landed 1.2% to 4.4% short of it. At 20 and 28 names the QPU was already sitting on the certified optimum, so there was no better answer left for a classical solver to find.

Speed only ever broke ties. Inside the shared 10-second deadline both solvers usually finished in about 0.1 to 0.3 seconds. The QPU was faster in about 70% of races, and its runtime barely varied while the classical solver's times ran a long tail. Where the two portfolios landed within a half-percent of each other, the system called the quality a tie and took whichever answer came back first; every race with a real quality difference was decided on quality. That timing is the QPU's time on the annealer, and it excludes network and queueing, which are scheduling artifacts rather than properties of the computation.

Final thoughts

This test was narrow on purpose. It compared two solver configurations on one family of problems. A verdict on quantum computing against classical computing would take a much wider range of problems and more than one configuration of each solver, and that is the test we want to see run. A differently tuned classical solver, given a different algorithm or a longer budget, might close the gap. Most races were ties, and those went to whichever answer came back first. When one portfolio was clearly better, it won no matter which solver was faster.

We didn't choose the problems, and for a comparison like this that matters as much as the sample size. A benchmark is usually run by the same people who pick the instances it runs on, and instances can be picked to favor a method. These came from whoever walked up to the booth and whatever they set the sliders to, and we saw each one for the first time when the solvers did. Every race ran as a job on Quip Network, which routed it to the hardware, verified the answer, and settled the work. We're building toward a market where a workload finds the machine that solves it best, and where the answer is something you can verify rather than something we assert.

FAQ

Links

• → Website: quip.network

• → Docs: quip.gitbook.io/docs

• → GitHub: github.com/quipnetwork

• → Discord: discord.gg/quipnetwork

• → Telegram: t.me/quipnetwork

• → X: @quipnetwork