What Is Quantum Optimization?

Educational disclaimer. This is a business-level explainer, not a specification. The algorithm is described by analogy; the papers cited under each claim carry the real thing. Service limits, free tiers and hardware names are snapshots from the day this was written and will drift. Treat the Kipu Quantum Hub and the linked papers as the single source of truth.

What quantum optimization is

Quantum optimization is the act or process of finding the absolute highest or lowest value of a function under specific rules, carried out by mapping that function into quantum states and using phenomena such as superposition and tunneling to navigate the solution landscape. The first half of that sentence is ordinary mathematical optimization, the discipline behind every scheduling tool and every portfolio model your organization already runs. The second half is the only part that is new: the search itself is performed by a physical quantum system rather than by a classical processor stepping through candidate answers.

That framing matters commercially, because it tells you where the quantum part can possibly help. It does not invent your objective, it does not know your business rules, and it does not replace the classical software around it. It is a specialist search engine you hand a finished mathematical model, and it hands back ranked candidate answers.

The problems in scope are combinatorial: a finite set of discrete choices whose combinations multiply faster than any machine can enumerate. Pick a subset of assets, assign crews to shifts, route a truck across segments. Classical exact solvers eventually hit that wall and stop being able to guarantee anything; classical heuristics stay useful by searching cleverly rather than exhaustively. Quantum optimization joins that second group. It is a heuristic, and it competes with other heuristics on measured results, not on a proof.

Does your problem fit? Three questions

Before anyone talks about hardware, a problem has to survive a triage. Three questions decide it, and each one has a standard workaround if the answer is no.

Is the core decision binary? Today's quantum optimizers work on yes/no variables, each taking the value 0 or 1. Select or don't select. Assign or don't assign. Route via A or not. Continuous quantities are not disqualifying, because they can usually be bucketed into a set of binary choices, but the buckets cost variables, so the reshaping is a real design decision rather than a formality.

Is there one number to optimize? Cost, time, energy, risk. The solver ranks candidate answers against a single figure of merit. If you have three objectives, you have to choose weights between them, and that is a business decision made by people, not a mathematical one the solver can make for you. Better to settle it consciously and up front than to discover it hidden in a formula later.

Can the rules become penalties? Every constraint has to be re-expressed as a cost added to any solution that breaks it. "Exactly fifty assets in the portfolio" becomes a term that grows when the count is wrong. "No crew works two shifts back to back" becomes a term that fires when the pattern appears. A hard physical limit is enforced by making its penalty large enough that no sensible answer ever pays it.

Three yes answers and the problem maps onto quantum optimization. A no names the reshaping step rather than ending the exercise: bucket the continuous quantities, fix the weights between the competing objectives, write the constraints as penalties. A problem that still sits outside after that is worth recording as outside, together with the reason it does.

From decisions to a formula the solver can read

The translation is mechanical once the triage is passed. Every yes/no decision becomes one binary variable. Each variable carries a coefficient: the cost or the gain of choosing it. Where two decisions interact, a risky pair of assets, two flights on the same corridor, a term joins them. Where three or more interact, a term joins those too.

Add up the choices, the interactions and the penalties and you have one function over all the bits. In the jargon it is a QUBO when interactions are pairwise only, and a HUBO, higher-order unconstrained binary optimization, when triples and higher appear. Kipu's solvers take HUBOs natively, so a genuinely three-body risk term does not have to be flattened into pairs first.

One candidate solution is therefore one string of bits, and the whole search is a walk over those strings. The value of the function at each string is its cost, and the answer you want is the string with the lowest cost. Picture that as a landscape with valleys: the deepest valley is the optimum, and every other valley is a spot where flipping any single decision makes things worse, which is exactly where cheap classical descent gets stuck.

Real landscapes are rugged. That ruggedness is the reason this problem class stays hard no matter how large your compute cluster is, and it is the reason a physically different way of searching is worth testing.

How today's leading method works

Kipu's optimizer implements an algorithm called BF-DCQO, bias-field digitized counterdiabatic quantum optimization. The name is a stack of three ideas, and each one is a fix for a specific problem with the idea before it. Read them in order and the whole thing becomes legible without a single equation.

The starting idea: evolve slowly

In adiabatic quantum computing, you start the machine in the easily prepared lowest-energy state of a simple system, then change that system slowly into the one whose lowest-energy state encodes your answer. If the change is slow enough, the system stays in its lowest-energy state throughout, and when you stop, reading the qubits gives you the solution.

Three things follow. In principle any computational problem can be encoded this way, so the approach is universal. The required runtime depends on the smallest energy gap the system passes through on its way, and for hard problems that gap tends to be small, which makes the run long. And a long run needs a machine that holds its quantum state for a long time, which today's hardware does not. Adiabatic evolution is the right intuition and the wrong implementation.

The first fix: take a shortcut

Counterdiabatic protocols let you go fast anyway. Think of carrying a flask of liquid. Tilt it slowly and the surface stays level. Tilt it fast and the liquid sloshes and spills. But tilt it fast while applying a compensating counter-motion, and the surface stays level at speed. The counterdiabatic term is that compensating motion: an extra piece added to the evolution that suppresses the transitions a fast schedule would otherwise cause.

Computing that compensating term exactly requires knowing the answer already, so in practice it is approximated by truncating a series expansion. The approximation is what makes it implementable: a short circuit instead of a long slow sweep, which is precisely what current hardware can run. The counterdiabatic idea itself predates quantum computing hardware by a decade and a half, developed in the physical chemistry and quantum control literature (Demirplak and Rice 2003, Berry 2009, Takahashi 2013, Sels and Polkovnikov 2017, Claeys et al. 2019).

The second fix: start closer, then iterate

A shortcut from an uninformed starting point still has a long way to go. The bias field is the answer to that. The first run begins with no preference at all: every one of the possible bit strings is equally likely. You run the short circuit a few thousand times, between 1,000 and 10,000 in the published experiments, and each run, called a shot, returns one candidate answer. How long a shot takes is a property of the hardware and not of the algorithm: microseconds on the superconducting processors this solver runs on today, of the order of a second on neutral-atom machines. A few thousand superconducting shots is therefore seconds of quantum time, which is what makes an iterative loop affordable in the first place. The measurement statistics across those shots say something about which decisions tend to be worth making. That information is folded back into the starting point of the next run as a small per-variable bias, so the second run starts nearer the good region than the first did. Then it repeats.

The published experiments use about ten rounds: ten in the Physical Review Research scaling study, eleven in the 156-qubit Communications Physics run, at both 156 and 433 variables. Fewer are needed when the first run is warm-started from a classical solution instead of from no preference at all, and the Hub run shown later on this page uses five. Circuits also get cheaper as the loop proceeds, because a better starting point needs less evolution to finish the job. The loop is what the "BF" stands for.

Keeping noise out of the loop

There is an obvious failure mode in a loop that learns from measurements: on noisy hardware, some of those measurements are corrupted, and a naive average would let the noise steer the next round. BF-DCQO handles this with a CVaR-based update rule. Instead of averaging all shots, it keeps only the best-scoring tail of them, a tunable fraction, and updates the bias field from that tail alone. High-energy shots, which is where noise mostly lands, are discarded before they can influence anything.

The commercial consequence is a cost one. Because the noise handling is part of the update rule and not a mitigation layer wrapped around it, it consumes no additional shots and no additional circuits, and on a machine billed by quantum runtime those are the two things you pay for.

Why this algorithm rather than another

Four properties separate BF-DCQO from the variational quantum algorithms that dominated earlier work on quantum optimization, and they are why it is the engine Kipu productizes. All four are reported in Gómez Cadavid, A. et al., Physical Review Research 7, L022010 (2025) and Romero V., S. et al., Communications Physics 8, 348 (2025); the algorithm itself is described in arXiv:2409.04477.

No classical optimizer sits in the loop tuning circuit parameters, which is what a variational algorithm does and what gives it trainability problems as it scales. Here the measurement statistics update the starting point directly, and the circuit parameters are obtained analytically, so moving to more qubits requires no retraining. Noise robustness comes from the CVaR-based bias field described above; because that sits inside the algorithm rather than in a mitigation layer on top, it costs no additional shots or circuits. And the feedback loop is short: the Physical Review Research study reaches its result in ten iterations, against a QAOA baseline given up to 300 classical optimizer evaluations from each of twenty starting points, two orders of magnitude more. On machines billed by quantum runtime, the sampling budget is the bill.

That plot ranks the three methods against each other; it does not forecast absolute performance. Success probability falls off as problems get bigger for all three, and the fitted decay rate is simply slower for BF-DCQO at 0.0840 than for plain digitized counterdiabatic optimization at 0.1283 or adiabatic optimization at 0.1940 (Gómez Cadavid et al. 2025, qubit counts on a log scale). What it establishes is that the bias-field loop earns its keep against its own ancestors. It carries no information about classical solvers.

What the evidence against classical solvers says

Beating your own predecessors is table stakes. The commercially interesting question is how a quantum pipeline does against the classical solvers a company would otherwise buy, measured end to end, on the same problems.

One limit governs every number below it. BF-DCQO is a heuristic, so it carries no a-priori bound on how far a returned answer sits from the optimum. Individual properties can be established analytically, noise robustness among them, and scaling behaviour can be measured across a range of problem sizes, which is what the plot above does. General performance against another heuristic cannot be settled that way at all and has to be benchmarked empirically. That is not a quantum caveat: simulated annealing carries the same absence of a guarantee, and so does an exact solver like CPLEX the moment it is stopped before it has proved optimality. The working consequence is that an advantage claim without a named classical baseline and a stated metric carries no information, including when the claim is ours.

A preprint from Kipu Quantum with IBM Research Europe, TU Berlin, the Zuse Institute Berlin and the University of the Basque Country reports exactly that benchmark: an end-to-end evaluation of a hybrid quantum solver for HUBO problems on IBM Heron r3 processors, published as arXiv:2603.13607.

Four things about the setup decide what the result is worth. The problems were made hard on purpose: higher-order binary optimization at sizes reaching 156 qubits, with as many as a thousand three-body terms, and coefficients drawn from heavy-tailed Cauchy distributions rather than a uniform range. The heavy tails are the point, because they produce the badly conditioned landscapes that a friendlier benchmark would avoid.

The pipeline is hybrid and says so. Classical preprocessing, then quantum optimization with BF-DCQO, then classical post-processing, with the classical stages counted inside the measured time rather than treated as setup.

The metric is runtime to reach a target solution quality, measured against five classical baselines: memetic tabu search, simulated annealing, parallel tempering, and the QUBO++ solvers EasySolve and ABS3. Time-to-target is the comparison that stays honest, because best-answer-ever rewards whichever solver was given the longest run.

The sampling budgets are uneven by six orders of magnitude, in the classical solvers' favour. Classical sampling runs at gigahertz rates and quantum sampling on today's hardware at kilohertz rates, so the quantum side draws roughly a million times fewer samples per second than the baselines it is being timed against.

On that footing the hybrid pipeline came out competitive: one quantum processor reached the target quality in comparable time to a 128-vCPU classical instance, and to eight data-centre GPUs, on this problem family (Chandarana, P. et al., arXiv:2603.13607, verified 2026-08-20). An earlier study from the same group reported the complementary result on 156-qubit IBM devices, a faster time-to-approximate-solution than simulated annealing and CPLEX on the hard instances it selected (arXiv:2505.08663, verified 2026-08-20).

Both are preprints rather than peer-reviewed results, and competitive is not better. What they establish is a trajectory rather than an advantage: a pipeline drawing a million times fewer samples per second already keeps pace on this problem family, which locates the remaining gap in hardware sampling rates rather than in the algorithm. No commercial-scale quantum advantage in combinatorial optimization has been demonstrated in this field, by Kipu or by anyone else, and this benchmark is not one.

See it run: Miray on the Kipu Quantum Hub

The algorithm reaches you as a service. Miray Advanced Quantum Optimizer is the BF-DCQO implementation on the Kipu Quantum Hub marketplace, and Iskay is the same solver family delivered as a Qiskit Function for teams working inside IBM's stack. You subscribe to the solver and build the wrapper around it; you do not build the solver.

The interface is a dictionary. Keys are tuples of variable indices, values are coefficients, and that object is the entire problem.

from qhub.service.client import HubServiceClient  # pip install qhub-service

problem = {"(0,)": -1.0, "(1,)": 0.75, "(0,1)": 0.51, "(0,1,2)": -0.62}

client = HubServiceClient(
    service_endpoint=SERVICE_ENDPOINT,      # Miray Advanced Quantum Optimizer - Simulator
    access_key_id=ACCESS_KEY_ID,
    secret_access_key=SECRET_ACCESS_KEY,
)
execution = client.run(request={"problem": problem, "problem_type": "binary"})
execution.wait_for_final_state()
print(execution.result().result["cost"], execution.result().result["mapped_solution"])

Four numbers, four lines of meaning. "(0,)" and "(1,)" are the standalone costs of the first two decisions. "(0,1)" is what it costs when those two are chosen together. "(0,1,2)" is a genuine three-body term, the kind a QUBO cannot express. What comes back is the best bit string found, decoded per variable, together with its cost.

Getting there on the Hub is three steps: create an application, which issues your access credentials; subscribe to the Miray simulator, which is free; run the example code. The free simulator handles problems of up to 20 variables, which is prototyping scale rather than production scale: enough to prove that your encoding and your penalties behave, not enough to solve the real instance. The paid version states no variable cap of its own and is bounded instead by the IBM backend you name when you call it. The rule from the first session applies unchanged, that you develop against the simulator and move to hardware once the workflow is proven.

What a converged run looks like

Convergence has a recognisable shape on a dashboard. Below is one of our own runs on the Hub, small enough to check by hand: ten variables, Miray on ibm_aachen, five iterations, 5,000 shots in the first of them. It is a demonstration of the shape, not evidence of performance, because a ten-variable problem is solvable by enumeration.

Iteration one is a haze: 5,000 shots came back as 805 distinct answers and the best one held 0.26 percent of them. By iteration five that same answer holds 27.8 percent, an amplification of about 107 times, and the number of distinct answers has fallen to 283. One bit string dominating the distribution is what convergence looks like here.

Two numbers are worth asking for whenever a run like this is presented, ours included. The found cost divided by the best-known cost, expressed in the objective's own units, since a quality figure normalised against anything else can be made to look arbitrarily good. And the quantum seconds actually consumed, summed per job, rather than the wall-clock time of the session around them.

Your move

There are three ways on from here, in increasing order of commitment. The cheapest is to run one yourself: the hands-on Miray lab walks the dictionary above from formulation to ranked result on the free simulator, and the quantum portfolio optimization tutorial builds a cardinality-constrained selection problem with a genuine three-body risk term, which part two then scales past the simulator's qubit ceiling by decomposition. If you want the product boundaries instead, the Miray page covers the optimizer's scope, its interfaces and where it runs, and subscriptions live on the Hub marketplace.

The one that costs a morning and decides the most is to score a problem of your own against the triage above: count the decisions, count the interactions, and write down where the problem sits and what it would cost to run once. If the answer is that it does not fit, that is a result worth having written down, and it is cheaper to reach here than in a pilot.

The full curriculum is on the Academy page.