For most of its history, mathematical optimization ran on CPUs and lived behind expensive commercial licenses. Linear and mixed-integer programming solvers were treated as specialist tools: powerful, but slow to iterate on, costly to scale, and usually owned by a small operations research team. In 2025 and 2026 that picture started to shift. GPU-accelerated solvers moved into the open-source world, open-source CPU solvers became defaults inside mainstream scientific software, and generative AI began to lower the barrier to writing and debugging models.
This article explains what is actually changing in the solver landscape, which planning problems benefit from GPU acceleration and which do not, and how a planning or analytics team can run a disciplined evaluation instead of chasing headline speedups.
What Changed: Three Shifts in the Solver Landscape
Three developments, taken together, explain why optimization is a live topic again for CIOs and supply chain leaders rather than a niche concern of the operations research group.
1. GPU acceleration went open source
In June 2025 NVIDIA described cuOpt, its GPU-accelerated decision optimization engine, as open source under the Apache 2.0 license, with the code hosted in the COIN-OR organization on GitHub. According to NVIDIA’s developer blog, cuOpt targets linear programming (LP), mixed-integer programming (MIP) and vehicle routing problems (VRP), and it can be called from the PuLP and AMPL modeling layers with minimal code change, as well as through a Python API, a REST server and a command-line interface. NVIDIA reports speedups ranging from 10x to 5,000x on selected LP, MIP and VRP instances, with the top figure tied to one large multi-commodity flow problem, and cites a collaboration with Artelys and FICO showing up to 20x speedups on large unit commitment problems in energy modeling.
Those numbers are vendor benchmarks on chosen instances, and they should be read that way. The structural point matters more: GPU-native optimization is now something any team can download, inspect and test on its own data without a procurement cycle.
2. Open-source CPU solvers became mainstream defaults
The open-source solver HiGHS, developed at the University of Edinburgh and released under the MIT license, handles LP, MIP and convex quadratic programs. It is now the LP and MIP engine inside SciPy, it is documented for use with Julia’s JuMP, and it is the default LP and MIP solver in MathWorks’ Optimization Toolbox. Recent releases have added a first-order LP method that can run on NVIDIA GPUs and an optional interior point method. For many mid-sized planning models, that means a capable, license-free baseline is already sitting inside tools data teams use every day.
3. AI is changing how models get built
Gurobi’s 2026 State of Mathematical Optimization Report, released in October 2026 and based on a survey of 382 non-academic professionals, found that 79% of respondents use generative AI or large language models in their optimization work, up from 30% the year before. Respondents saw the most promise in code generation and debugging, model formulation, and natural-language interaction with models. The same release reported that 90% combine machine learning and optimization on at least one project. In other words, the human bottleneck of translating a business problem into a model is easing at the same time as the compute bottleneck.
Why GPUs Help Some Optimization Problems and Not Others
It is tempting to assume that anything moved to a GPU gets faster. Optimization is more nuanced, and understanding why will save weeks of misdirected effort.
Classical LP solvers rely on the simplex method or on interior point methods. Both involve sequences of operations, such as factorizing sparse matrices, that are hard to parallelize across thousands of GPU cores. First-order methods, in contrast, rely mostly on matrix-vector multiplications, which GPUs perform extremely well. The trade-off is that first-order methods usually reach a solution of modest precision quickly but can take many iterations to reach the very tight tolerances that simplex delivers.
For mixed-integer programs, the core engine is branch-and-bound with cutting planes and heuristics. Much of that logic is sequential and branchy. GPUs can still help, for example by solving LP relaxations faster or by running many primal heuristics in parallel, but the gains depend heavily on problem structure. Routing problems solved with metaheuristics are a natural fit, because evaluating thousands of candidate route modifications in parallel is exactly the kind of work GPUs are built for.
A practical rule of thumb follows from this:
- Strong candidates: very large LPs where a near-optimal answer is acceptable, such as network flow, transportation, and energy dispatch relaxations; large vehicle routing with time windows and capacities; and workloads that need many re-solves under changing inputs.
- Mixed candidates: MIPs with large LP relaxations, where faster relaxations can speed up the overall search but the benefit varies by instance.
- Weak candidates: small or medium models that already solve in seconds on a CPU, problems that need very tight optimality certificates for audit reasons, and models dominated by combinatorial logic rather than linear algebra.
Where Planning Teams Feel the Difference
Speed only matters if it changes a business decision. Faster solves create value in a few specific ways.
Re-planning frequency
When a network plan takes four hours to solve, it runs overnight and the business lives with yesterday’s answer. When the same plan solves in minutes, it can be refreshed after a demand spike, a port delay or a machine breakdown. Logistics and manufacturing teams increasingly talk about moving from batch planning to event-driven re-planning, and solve time is often the binding constraint.
Scenario breadth
Planners rarely want a single answer. They want to compare a base case against high demand, a supplier outage, a carbon price or a new warehouse. If each scenario costs an hour of compute, teams run three. If each costs a minute, they can run dozens and present a range of outcomes with clear trade-offs. This is where faster solvers support sales and operations planning, network design, and capacity investment decisions.
Model fidelity
Many production models are simplified to make them solvable: time buckets are coarsened, products are aggregated, and constraints are dropped. Additional solver headroom can be spent on fidelity instead of speed, such as hourly instead of daily buckets or SKU-level instead of family-level decisions. That often improves plan quality more than any algorithmic tweak.
Agent and copilot workflows
As planning tools add AI assistants that let users ask what-if questions in natural language, every question becomes a solve. Interactive response times are only possible if the underlying optimization returns quickly. Fast solvers are therefore an enabler for the agentic planning experiences that software vendors are now promoting.
A Practical Evaluation Framework
Rather than switching solvers on the strength of a benchmark chart, treat the decision as a structured experiment. The following sequence works for LP, MIP and routing models alike.
- Build a representative test set. Collect 20 to 50 real instances from production, covering normal days, peak periods and the awkward edge cases that cause planners pain. Benchmarks on synthetic data rarely predict production behavior.
- Define what “good” means. Agree on acceptable optimality gaps, maximum solve times, and the business KPIs a plan must hit. A plan that is 0.5% from optimal in two minutes may be worth more than a proven optimum in two hours.
- Establish a baseline. Run your current solver with tuned parameters on the same hardware class you use today. Record solve time, gap, objective value and memory use.
- Test alternatives fairly. Run open-source CPU options, GPU options and, where relevant, commercial alternatives. Use the same modeling layer where possible so differences reflect the solver, not the formulation.
- Measure total cost. Include GPU instance pricing, license costs, engineering time to integrate, and support arrangements. A faster solver that needs a premium GPU running around the clock may cost more than it saves.
- Check robustness. Look at variance across instances, not just averages. A solver that is ten times faster on average but occasionally fails to find a feasible solution can be worse for operations.
- Pilot in shadow mode. Run the new solver alongside production for several planning cycles and compare decisions, not just numbers, with experienced planners.
Solver speed is only valuable when it changes a decision: more frequent re-planning, broader scenarios or higher model fidelity. Benchmark on your own instances before you rewrite anything.
Architecture Patterns for Mixed Solver Estates
Few organizations will standardize on one solver for everything. A more realistic architecture separates the model from the engine.
- Solver-agnostic modeling layer. Keep formulations in a modeling library or language that supports several back ends, such as PuLP, Pyomo, JuMP or AMPL. This makes it practical to route different problem types to different solvers.
- Optimization as a service. Wrap models behind an internal API that accepts business inputs and returns plans. Planners and applications call the service; the platform team decides which engine and hardware run behind it.
- Elastic GPU capacity. Because many planning workloads are bursty, schedule GPU instances on demand in the cloud, or share a GPU pool with machine learning workloads, rather than dedicating hardware to the solver.
- Warm starts and hybrid pipelines. Use a fast first-order or GPU solve to produce a good starting point, then hand it to a CPU solver to polish and certify when tight optimality matters.
- Observability. Log every solve with inputs, solver version, parameters, runtime and result quality so that regressions can be detected after upgrades.
Hypothetical Example: A Regional Distributor Re-Plans Routes Intraday
Consider a hypothetical food distributor operating 400 delivery vehicles across three depots. Today, routes are planned once each evening using a CPU-based routing engine that takes about 90 minutes. During the day, dispatchers handle cancellations, urgent orders and traffic disruptions by hand.
The team assembles 30 historical days as a test set, including two holiday peaks. It defines success as routes within 2% of the current plan’s total distance, generated in under five minutes, with no violation of delivery windows. In testing, a GPU routing engine produces comparable plans in a few minutes on most days, but struggles on one peak instance with unusual depot constraints. The team keeps the evening CPU run as the authoritative plan and adds a GPU-based intraday re-optimization that runs every hour on the remaining stops. Dispatchers review suggested changes before release.
The result in this illustration is not a dramatic solver replacement but a new capability: intraday re-planning that did not previously exist. That is typical of how GPU acceleration creates value in practice.
Pitfalls to Avoid
- Benchmark tourism. Vendor benchmarks use instances chosen to show strengths. Your models have their own structure.
- Ignoring precision requirements. First-order methods may stop at a looser tolerance. Check whether downstream systems or auditors expect tighter answers.
- Underestimating integration work. Data pipelines, input validation and plan publishing usually take more effort than calling a new solver.
- Formulation debt. A poorly formulated model is slow on every solver. Reformulation often delivers bigger gains than new hardware.
- No owner for the platform. Mixed solver estates need someone accountable for versions, licenses, hardware and regression testing.
Outlook: 2027 and Beyond
Several trends look likely to continue. GPU support will spread across both open-source and commercial solvers, so hardware choice will increasingly be a deployment decision rather than a vendor lock-in decision. Open-source solvers will keep improving as energy system modelers, academics and cloud providers invest in them. Language models will become standard assistants for formulating and debugging models, which will widen the pool of people who can build optimization applications but also raise the importance of review and testing. And as planning software adds conversational and agentic interfaces, fast and reliable solvers will become invisible infrastructure behind everyday business questions.
Organizations that prepare by separating models from engines, building representative test sets and putting optimization behind well-governed services will be able to adopt each improvement as it arrives rather than rebuilding every time the landscape shifts.
Conclusion
GPU-accelerated and open-source solvers have made high-performance optimization far more accessible. The opportunity is real, but it is specific: large linear models, routing and frequent re-planning benefit most, while small models and audit-sensitive MIPs may see little change. Treat solver selection as an engineering experiment grounded in your own data, invest in a solver-agnostic architecture, and spend the extra speed where it changes decisions. That is how faster math turns into better plans.
How Hanoi Technology Can Help
Hanoi Technology helps planning teams benchmark solvers on real instances and build solver-agnostic optimization services, as projects, dedicated teams or managed services.