<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Johnny is piggy</title>
    <description>The latest articles on DEV Community by Johnny is piggy (@johnnyispiggy).</description>
    <link>https://dev.to/johnnyispiggy</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4131973%2F6f44e82a-5a6a-44b8-ac1e-4c20f164447b.jpg</url>
      <title>DEV Community: Johnny is piggy</title>
      <link>https://dev.to/johnnyispiggy</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/johnnyispiggy"/>
    <language>en</language>
    <item>
      <title>Learning-Based Optimization and Planning Algorithms: A Comprehensive Technical Survey and Engineering Adoption Guide</title>
      <dc:creator>Johnny is piggy</dc:creator>
      <pubDate>Sat, 19 Sep 2026 13:10:35 +0000</pubDate>
      <link>https://dev.to/johnnyispiggy/learning-based-optimization-and-planning-algorithms-a-comprehensive-technical-survey-and-2img</link>
      <guid>https://dev.to/johnnyispiggy/learning-based-optimization-and-planning-algorithms-a-comprehensive-technical-survey-and-2img</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;Survey current as of September 2026. This is a long-form deep dive (~20,000 words) — use the table of contents below to jump to the sections you care about. A Chinese version of this report is also available.&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h2&gt;
  
  
  Table of Contents
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Executive Summary&lt;/li&gt;
&lt;li&gt;1. Scope and Taxonomy&lt;/li&gt;
&lt;li&gt;2. Paradigm 1: End-to-End Neural Combinatorial Optimization (NCO)&lt;/li&gt;
&lt;li&gt;3. Paradigm 2: Learning-Augmented Classical Solvers&lt;/li&gt;
&lt;li&gt;4. Paradigm 3: Learning to Optimize (Learned Optimizers)&lt;/li&gt;
&lt;li&gt;5. Paradigm 4: Decision-Focused Learning and Differentiable Optimization (Predict-then-Optimize)&lt;/li&gt;
&lt;li&gt;6. Paradigm 5: LLM-Driven Optimization&lt;/li&gt;
&lt;li&gt;7. Paradigm 6: Learning-Based Planning and Control&lt;/li&gt;
&lt;li&gt;8. Scheduling and Manufacturing: The Practical Landscape of Deep-Learning Scheduling&lt;/li&gt;
&lt;li&gt;9. Industrial Adoption Panorama: A Global Practice Map&lt;/li&gt;
&lt;li&gt;10. Open-Source Toolchain Panorama and Selection&lt;/li&gt;
&lt;li&gt;11. Engineering Adoption Guide&lt;/li&gt;
&lt;li&gt;12. Challenges, Controversies, and Open Problems&lt;/li&gt;
&lt;li&gt;13. Frontier Trends (2025–2026) and Outlook&lt;/li&gt;
&lt;/ul&gt;




&lt;h2&gt;
  
  
  Executive Summary
&lt;/h2&gt;

&lt;p&gt;"Learning-based optimization and planning" refers to the family of methods that use machine learning—especially deep learning, reinforcement learning, and large language models—to &lt;strong&gt;replace, accelerate, or augment&lt;/strong&gt; traditional optimization and planning algorithms. Over the decade-plus since 2015, the field has evolved from the academic demonstration of Pointer Networks into a vast technical system spanning combinatorial optimization, mixed-integer programming, production scheduling, robot control, autonomous driving, and automated algorithm discovery, delivering quantifiable gains in real production environments such as Google data center cooling, the LLVM standard library, DiDi's dispatch system, and Google TPU chip design.&lt;/p&gt;

&lt;p&gt;This report divides the field into six paradigms—&lt;strong&gt;end-to-end neural combinatorial optimization (NCO), learning-augmented classical solvers, learning to optimize (L2O), decision-focused learning (DFL), LLM-driven optimization, and learning-based planning &amp;amp; control&lt;/strong&gt;—and for each traces its technical lineage, representative methods, toolchain, and maturity, with engineering selection advice. On industrial adoption, the report systematically maps global practice by industry (Chapter 9): semiconductor EDA (Synopsys DSO.ai; Cadence Cerebrus production cases with Samsung/MediaTek/Phison), energy &amp;amp; power (Tesla Autobidder; Yokogawa × Saudi Aramco/ENEOS reinforcement-learning autonomous control; France's RTE grid competitions), logistics &amp;amp; warehousing (UPS ORION, Amazon DeepFleet, Ocado), urban transportation (Pittsburgh Surtrac, Google Green Light, Alibaba City Brain), financial execution (JPMorgan LOXM), and commercial platforms (Blue Yonder, NVIDIA cuOpt, Huawei OptVerse)—more than 20 traceable cases in total. Four core conclusions follow. First, &lt;strong&gt;the hybrid route (learning-augmented classical solvers) is the most reliable mainstream in industry today&lt;/strong&gt;; end-to-end neural solvers still lag classical methods such as LKH-3, HGS, and Gurobi in generality, scale extrapolation, and feasibility guarantees. Second, &lt;strong&gt;the LLM-driven "generate–evaluate–evolve" paradigm (the FunSearch/AlphaEvolve lineage) is the fastest-growing direction since 2023&lt;/strong&gt;, lifting the object of optimization from "solutions" to "algorithms themselves." Third, multiple large-scale industrial deployments have demonstrated quantifiable value, yet virtually all successful cases worldwide adopt a conservative "learned model + classical solver/safety layer" architecture and follow a staged deployment path of "simulator training → shadow mode → human-in-the-loop → bounded closed-loop autonomy." Fourth, open-source tools such as RL4CO, PyEPO, Ecole, OpenEvolve, and cuOpt have dramatically lowered the engineering barrier, allowing small teams to complete a proof of concept within weeks. Every chapter includes a "frontier progress" section covering the latest literature through 2026: cross-problem unified neural solvers (URS covers 107 routing problems), LLM-discovered solver branching policies (LLM4Branch), the birth and industrialization of the Muon optimizer (adopted end-to-end by the trillion-parameter Kimi K2), the crystallization of LLM-optimization evaluation suites (CO-Bench, SolverLLM), VLA robot foundation models (π0.5, GR00T N1), and large driving models (Tesla FSD V14; commercial Waymo/Tesla robotaxi in Austin), among others.&lt;/p&gt;




&lt;h2&gt;
  
  
  1. Scope and Taxonomy
&lt;/h2&gt;

&lt;h3&gt;
  
  
  1.1 What Is "Learning-Based Optimization and Planning"
&lt;/h3&gt;

&lt;p&gt;Traditional optimization and planning rely on hand-crafted algorithms: branch-and-bound, cutting planes, column generation, and metaheuristics in operations research; model predictive control (MPC) in control; sampling- and graph-search-based planners such as RRT/A* in robotics. These methods carry solid theoretical guarantees, but their performance depends heavily on rules hand-tuned by experts for each specific problem (e.g., branching variable selection rules, neighborhood structure design, dispatching rules), and they cannot benefit from historical data when facing large volumes of repeated problems drawn from the same distribution. The core idea of &lt;strong&gt;learning-based optimization and planning&lt;/strong&gt; is this: since industrial optimization problems are typically "the same family of problems, re-solved day after day with different data" (daily vehicle routing, per-shift production scheduling), data-driven methods can learn regularities in the problem distribution and inject them into the solving pipeline, thereby outperforming general-purpose algorithms on that distribution.&lt;/p&gt;

&lt;p&gt;In their foundational 2021 survey in the &lt;em&gt;European Journal of Operational Research&lt;/em&gt;, Bengio, Lodi, and Prouvost organized the field's methodology into two complementary machine-learning paradigms: &lt;strong&gt;learning by demonstration (imitation learning)&lt;/strong&gt;—using supervised learning to approximate expensive but effective expert decisions (such as strong branching), trading approximation for computational efficiency; and &lt;strong&gt;learning by experience (reinforcement learning)&lt;/strong&gt;—modeling the solving process as a Markov decision process (MDP) and discovering entirely new decision policies through trial and error. The two can be combined, initializing with imitation learning and fine-tuning with reinforcement learning (&lt;a href="https://arxiv.org/abs/1811.06128" rel="noopener noreferrer"&gt;Bengio et al., EJOR 2021&lt;/a&gt;). This "imitation + reinforcement" dichotomy remains the basic coordinate system for understanding the field today.&lt;/p&gt;

&lt;h3&gt;
  
  
  1.2 A Six-Paradigm Taxonomy
&lt;/h3&gt;

&lt;p&gt;With the rise of LLMs, the original "machine learning for combinatorial optimization" framing no longer covers the full picture. This report classifies existing methods into six paradigms according to &lt;strong&gt;the role learning plays in the optimization/planning pipeline&lt;/strong&gt;, as shown in Figure 1:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Flkrlb8dvhnr6gahlwt2t.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Flkrlb8dvhnr6gahlwt2t.png" alt=" " width="800" height="477"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Figure 1. The six-paradigm taxonomy of learning-based optimization and planning algorithms&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The six paradigms are: (1) &lt;strong&gt;end-to-end neural combinatorial optimization&lt;/strong&gt;—a neural network directly outputs solutions; representatives include Pointer Networks, the Attention Model, POMO, and recent diffusion-model approaches; (2) &lt;strong&gt;learning-augmented classical solvers&lt;/strong&gt;—learned models are embedded as components inside classical frameworks such as branch-and-bound and large neighborhood search; representatives include GNN branching prediction, RL cut selection, Neural Diving, and NeuroLKH; (3) &lt;strong&gt;learning to optimize (L2O)&lt;/strong&gt;—the object being learned is the optimization algorithm itself (e.g., the update rule of gradient descent, hyperparameter search policies); representatives include LSTM meta-optimizers, VeLO, OptFormer, and Lion; (4) &lt;strong&gt;decision-focused learning (DFL)&lt;/strong&gt;—connecting the two-stage "predict–optimize" pipeline so that predictive models are trained for downstream decision quality; representatives include the SPO+ loss and differentiable optimization layers; (5) &lt;strong&gt;LLM-driven optimization&lt;/strong&gt;—using large language models as black-box optimizers, heuristic generators, or automated modelers; representatives include OPRO, FunSearch, AlphaEvolve, EoH, and OptiMUS; (6) &lt;strong&gt;learning-based planning &amp;amp; control&lt;/strong&gt;—sequential decision-making for continuous physical systems, covering learning-augmented MPC, diffusion motion planning, end-to-end autonomous driving, and LLM embodied task planning. These six paradigms share the same underlying technologies (GNNs, Transformers, RL, diffusion models) but face radically different problem forms and engineering constraints.&lt;/p&gt;

&lt;h3&gt;
  
  
  1.3 Historical Arc: Three Eras
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fuxj59357s0uuohgmlw2w.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fuxj59357s0uuohgmlw2w.png" alt=" " width="800" height="377"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Figure 2. The development arc of learning-based optimization and planning&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The timeline in Figure 2 summarizes a decade-plus of progress in three eras. &lt;strong&gt;The Foundations era (2015–2019)&lt;/strong&gt; was marked by sequence-to-sequence models entering combinatorial optimization: in 2015 Vinyals et al. proposed Pointer Networks, the first neural network to solve TSP; in 2016 Andrychowicz et al. learned optimizers with LSTMs and Khalil et al. approximated strong branching with imitation learning; in 2017 Bello et al. introduced reinforcement learning to escape dependence on optimal-solution labels and Khalil et al. proposed S2V-DQN on graphs; in 2019 Kool et al.'s Attention Model and Gasse et al.'s GNN branching model established the technical foundations of the end-to-end and hybrid routes respectively; during the same period DiDi had already put an RL-based dispatch system into production (see Chapter 9) (&lt;a href="https://cloud.tencent.com/developer/article/1346161" rel="noopener noreferrer"&gt;DiDi KDD 2018 paper walkthrough&lt;/a&gt;). &lt;strong&gt;The Systematization era (2020–2022)&lt;/strong&gt; witnessed methodological maturation and the first heavyweight industrial results: POMO, the L2D scheduling model, Neural Diving, and RL cut selection appeared in succession; in 2021 Bengio et al.'s survey gave the field its canonical account, and Google's RL chip macro-placement result was published in &lt;em&gt;Nature&lt;/em&gt;; in 2022 AlphaTensor used RL to discover faster matrix-multiplication algorithms, the SPO+ loss was finalized, and SayCan opened up LLM embodied planning (&lt;a href="https://www.amacad.org/publication/daedalus/introductory-notes-ai-science-future-of-discovery" rel="noopener noreferrer"&gt;survey of AI for algorithm discovery&lt;/a&gt;). &lt;strong&gt;The LLM era (2023–present)&lt;/strong&gt; is defined by bringing LLMs into the optimization loop: FunSearch and AlphaEvolve turned "LLM + evolutionary search + automatic evaluator" into a general-purpose algorithm-discovery engine; AlphaDev's discovered sorting algorithms entered the LLVM libc++ standard library; OPRO demonstrated that an LLM itself can act as an optimizer; and systems such as OptiMUS and ORLM began automating operations-research modeling—the most labor-intensive step of all. Meanwhile, the establishment of unified benchmarks such as RL4CO (KDD 2025) and ML4CO-Bench-101 (NeurIPS 2025) marks the field's entry into a phase of standardized evaluation (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;RL4CO, KDD 2025&lt;/a&gt;, &lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  1.4 Representative Surveys and Community Resources
&lt;/h3&gt;

&lt;p&gt;For readers who wish to follow the field systematically, the following surveys and resource lists are the most reliable entry points today. At the methodological-overview level, the Bengio–Lodi–Prouvost EJOR survey (cited in §1.1) establishes the "imitation + reinforcement" coordinate system; a &lt;strong&gt;systematic survey of the LLM × combinatorial optimization intersection&lt;/strong&gt; was published in &lt;em&gt;ACM Computing Surveys&lt;/em&gt; in 2026, comprehensively mapping LLM intervention points along the optimization workflow (modeling, solving, verification, explanation) (&lt;a href="https://dl.acm.org/doi/10.1145/3801961" rel="noopener noreferrer"&gt;ACM CSUR 2026&lt;/a&gt;); the LLM-driven meta-optimizer direction also received a dedicated 2026 survey covering three frontier lines—neuro-symbolic hybrids, agent-assisted optimization, and domain-specific optimizers (&lt;a href="https://link.springer.com/article/10.1007/s10462-025-11470-w" rel="noopener noreferrer"&gt;Springer survey 2026&lt;/a&gt;). A 2024 "learning to optimize" tutorial for continuous and mixed-integer optimization offers an on-ramp for practitioners moving from purely data-driven approaches toward "neural networks guiding classical solvers" (&lt;a href="https://arxiv.org/pdf/2405.15251v1" rel="noopener noreferrer"&gt;L2O tutorial&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;For community-maintained living lists, &lt;strong&gt;awesome-ml4co&lt;/strong&gt; (Thinklab, Shanghai Jiao Tong University) systematically indexes neural combinatorial optimization papers and code, while &lt;strong&gt;awesome-fm4co&lt;/strong&gt; (the AI4CO community) tracks the "foundation models for combinatorial optimization" direction at monthly granularity—the density of its 2025–2026 entries vividly illustrates that direction's explosive growth (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;, &lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;). On evaluation resources, beyond RL4CO and ML4CO-Bench-101 (§2.4), the 2026 &lt;strong&gt;FrontierCO&lt;/strong&gt; benchmark is the first to systematically evaluate contemporary ML solvers on real-world, large-scale instances (covering branching learning, LNS learning, FJSP reinforcement learning, and more), making it an important reference for judging the engineering value of any published method (&lt;a href="https://arxiv.org/html/2505.16952v3" rel="noopener noreferrer"&gt;FrontierCO&lt;/a&gt;). A recommended following cadence combines "one overview survey + one living list + one unified benchmark": the survey sets the framework, the list tracks increments, and the benchmark checks truth.&lt;/p&gt;




&lt;h2&gt;
  
  
  2. Paradigm 1: End-to-End Neural Combinatorial Optimization (NCO)
&lt;/h2&gt;

&lt;h3&gt;
  
  
  2.1 Three Technical Routes
&lt;/h3&gt;

&lt;p&gt;End-to-end neural combinatorial optimization (NCO) pursues the most radical goal: &lt;strong&gt;train a neural network that takes a problem instance as input and directly outputs a near-optimal solution&lt;/strong&gt;, invoking no traditional solver at inference time. Its industrial appeal lies in inference speed—a single forward pass takes milliseconds and natively supports batched GPU parallelism, making it theoretically suitable for online scenarios that must solve massive volumes of instances in extremely short time. A 2025 industrial-engineering survey in &lt;em&gt;Artificial Intelligence Review&lt;/em&gt; systematically summarizes the application landscape of NCO-RL across vehicle routing, bin packing, assignment, scheduling, and planning problems, noting that the paradigm has become one of the standard candidate techniques for NP-hard problems in industrial engineering (&lt;a href="https://link.springer.com/article/10.1007/s10462-024-11045-1" rel="noopener noreferrer"&gt;AI Review 2025&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Technically, NCO falls into three routes. &lt;strong&gt;Constructive&lt;/strong&gt; methods model solution generation as sequential decision-making, autoregressively selecting elements one by one: from Pointer Networks (supervised learning), through Bello et al.'s RL training framework, to Kool et al.'s Transformer-based Attention Model (AM) and Kwon et al.'s POMO (which exploits solution symmetry to build multi-start baselines), forming the current mainstream skeleton; subsequent works such as Sym-NCO, MatNet, and BQ mostly improve encoder architectures, baseline design, and decoding strategies (&lt;a href="https://github.com/ai4co/rl4co" rel="noopener noreferrer"&gt;RL4CO&lt;/a&gt;). &lt;strong&gt;Improvement&lt;/strong&gt; methods learn operator-selection policies for local search: given an initial solution, a policy network decides which neighborhood operation (2-opt, relocate, exchange, etc.) to apply; typical representatives include NeuRewriter, DACT, and learned large neighborhood search (Neural LNS); this route's advantage is that solution quality keeps improving as search time is extended. &lt;strong&gt;Non-autoregressive / heatmap&lt;/strong&gt; methods have a GNN output, in one shot, the probability that each edge (or decision variable) belongs to the optimal solution, then decode legal solutions with beam search, Monte Carlo tree search, or guided sampling; representative works include UTSP, DIFUSCO, and the diffusion-model solvers emerging since 2024 (e.g., the unsupervised diffusion framework at ICML 2024 and StruDiCO structured denoising diffusion at NeurIPS 2025) (&lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;). Since 2025 there has also been a trend toward unifying all three: UniCO (ICLR 2025) reduces multiple combinatorial problems to a matrix-encoded general TSP for unified solving, while Unify ML4TSP (ICLR 2025) distills methodological principles from a streamlined "learning + search" design space (&lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.2 Comparison of Representative Methods
&lt;/h3&gt;

&lt;p&gt;The table below summarizes representative end-to-end methods and their key characteristics as a reference for engineering selection.&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Method&lt;/th&gt;
&lt;th&gt;Year / Venue&lt;/th&gt;
&lt;th&gt;Route&lt;/th&gt;
&lt;th&gt;Training&lt;/th&gt;
&lt;th&gt;Core idea&lt;/th&gt;
&lt;th&gt;Applicable problems&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Pointer Networks&lt;/td&gt;
&lt;td&gt;2015, NeurIPS&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;Supervised&lt;/td&gt;
&lt;td&gt;Pointer attention outputs a permutation of the input sequence&lt;/td&gt;
&lt;td&gt;TSP and geometric problems&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Bello et al.&lt;/td&gt;
&lt;td&gt;2017, ICLR&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;RL (REINFORCE)&lt;/td&gt;
&lt;td&gt;Label-free; train policy on rewards&lt;/td&gt;
&lt;td&gt;TSP, knapsack&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;S2V-DQN (Khalil et al.)&lt;/td&gt;
&lt;td&gt;2017, NeurIPS&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;RL (DQN)&lt;/td&gt;
&lt;td&gt;Graph embedding + Q-learning to build solutions node by node&lt;/td&gt;
&lt;td&gt;Graph CO (MIS, MaxCut)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Attention Model (Kool et al.)&lt;/td&gt;
&lt;td&gt;2019, ICLR&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;RL (rollout baseline)&lt;/td&gt;
&lt;td&gt;Transformer encoder–decoder for routing&lt;/td&gt;
&lt;td&gt;TSP/VRP family&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;POMO (Kwon et al.)&lt;/td&gt;
&lt;td&gt;2020, NeurIPS&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;Multi-start policy exploiting solution symmetry&lt;/td&gt;
&lt;td&gt;TSP/CVRP/scheduling&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L2D (Zhang et al.)&lt;/td&gt;
&lt;td&gt;2020, NeurIPS&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;RL (PPO)&lt;/td&gt;
&lt;td&gt;GNN encodes disjunctive graph to learn dispatching rules&lt;/td&gt;
&lt;td&gt;Job-shop scheduling (JSP)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;NeuroLKH (Xin et al.)&lt;/td&gt;
&lt;td&gt;2021, NeurIPS&lt;/td&gt;
&lt;td&gt;Hybrid (heatmap + LKH)&lt;/td&gt;
&lt;td&gt;Supervised + unsupervised&lt;/td&gt;
&lt;td&gt;Learned edge scores and node penalties injected into LKH&lt;/td&gt;
&lt;td&gt;Large-scale TSP&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DACT / improvement Transformers&lt;/td&gt;
&lt;td&gt;2021–2023&lt;/td&gt;
&lt;td&gt;Improvement&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;Learn sequences of neighborhood operators&lt;/td&gt;
&lt;td&gt;TSP/CVRP&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DIFUSCO / diffusion solvers&lt;/td&gt;
&lt;td&gt;2023–2025&lt;/td&gt;
&lt;td&gt;Heatmap&lt;/td&gt;
&lt;td&gt;Supervised / unsupervised&lt;/td&gt;
&lt;td&gt;Graph diffusion generates solution distributions + guided sampling&lt;/td&gt;
&lt;td&gt;Graph CO, TSP&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;UniCO&lt;/td&gt;
&lt;td&gt;2025, ICLR&lt;/td&gt;
&lt;td&gt;Unified constructive framework&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;Multiple problems reduced to matrix-encoded general TSP&lt;/td&gt;
&lt;td&gt;Multiple CO classes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;LLM end-to-end solvers&lt;/td&gt;
&lt;td&gt;2025, NeurIPS&lt;/td&gt;
&lt;td&gt;Constructive&lt;/td&gt;
&lt;td&gt;Supervised / RL&lt;/td&gt;
&lt;td&gt;LLMs directly as CO solvers&lt;/td&gt;
&lt;td&gt;Classical graph problems&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;(Compiled from &lt;a href="https://github.com/ai4co/rl4co" rel="noopener noreferrer"&gt;RL4CO&lt;/a&gt;, &lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;, and &lt;a href="https://link.springer.com/article/10.1007/s10462-024-11045-1" rel="noopener noreferrer"&gt;AI Review 2025&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;It must be emphasized that the relative performance of the methods above is highly sensitive to the evaluation setup. RL4CO's systematic comparison under a unified implementation found that &lt;strong&gt;some new methods claiming SOTA actually fall behind their predecessors once the evaluation criterion changes (zero-shot performance, generalization, adaptability)&lt;/strong&gt;, and that simple inference-time data augmentation can even outperform sampling-based decoding schemes with far higher computational cost (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;RL4CO, KDD 2025&lt;/a&gt;). This finding has a direct lesson for engineering practice: selection decisions must re-test methods under a unified framework on your own instance distribution, rather than trusting numbers reported in papers.&lt;/p&gt;

&lt;h3&gt;
  
  
  2.3 The Real Gap with Classical Solvers: A Critical Assessment
&lt;/h3&gt;

&lt;p&gt;End-to-end NCO enjoys great academic visibility, but engineering must confront its gap with classical methods head-on. The 2024 ACM paper &lt;em&gt;Applicability of Neural Combinatorial Optimization&lt;/em&gt; offers a critical analysis of the literature, noting that many NCO works compare only against weak baselines on randomly generated small-scale instances—MatNet, for example, still loses to LKH-3 on asymmetric TSP, and a considerable share of papers never compare against state-of-the-art metaheuristics at all (&lt;a href="https://dl.acm.org/doi/full/10.1145/3647644" rel="noopener noreferrer"&gt;ACM 2024&lt;/a&gt;). A 2025 systematic review covering &lt;strong&gt;253 papers&lt;/strong&gt; on "machine learning for routing problems" from 2016–2025 likewise observes that despite the explosive growth of learning-based publications, classical solvers such as LKH-3 and HGS retain near-optimal accuracy thanks to decades of engineering accumulation, while end-to-end NCO models are generally constrained by missing scalability, generalization, and convergence guarantees (&lt;a href="https://arxiv.org/pdf/2507.00218" rel="noopener noreferrer"&gt;ML-for-routing survey&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2606.04039v1" rel="noopener noreferrer"&gt;neural-guided ACO paper&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Concretely, the engineering shortcomings of end-to-end NCO concentrate in four areas. First, &lt;strong&gt;scale extrapolation&lt;/strong&gt;: a model trained on 100-node instances degrades significantly when applied directly to 1,000-node instances, requiring additional mechanisms such as GLOP-style "global partitioning + local construction" or curriculum learning (e.g., the Oxford team's RASCL adaptive stair curriculum, which reduced the average optimality gap on Taillard scheduling benchmarks to 10.46%) (&lt;a href="https://www.maths.ox.ac.uk/node/67090" rel="noopener noreferrer"&gt;Oxford Math&lt;/a&gt;). Second, &lt;strong&gt;feasibility guarantees&lt;/strong&gt;: learned models may output constraint-violating solutions, so industrial problems with hard constraints must append repair procedures. Third, &lt;strong&gt;distribution shift&lt;/strong&gt;: performance becomes uncontrollable when the training distribution diverges from the live distribution. Fourth, &lt;strong&gt;training cost&lt;/strong&gt;: training an NCO model often takes days of GPU time, a cost typically hidden in papers' "inference-time comparisons." That said, the gap is closing fast: recent work such as RsGCN has reached LKH-level quality on large-scale TSPs above 1,000 nodes (while still lagging the exact solver Concorde), with far fewer parameters and lower training cost than earlier NCO models (&lt;a href="https://arxiv.org/html/2506.00533" rel="noopener noreferrer"&gt;RsGCN&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.4 Benchmarks and Evaluation Infrastructure
&lt;/h3&gt;

&lt;p&gt;Standardized evaluation is a prerequisite for the end-to-end route to become engineering-ready. The most important public infrastructure today is &lt;strong&gt;RL4CO&lt;/strong&gt;: a unified RL-for-CO library built on TorchRL, TensorDict, PyTorch Lightning, and Hydra, covering &lt;strong&gt;27 combinatorial optimization environments (TSP, CVRP, job-shop scheduling, facility location, EDA placement, and more) and 23 baseline algorithms&lt;/strong&gt;, fully decoupling policies, environments, RL algorithms, and trainers—researchers can launch a complete training run in under 30 lines of code (&lt;a href="https://github.com/ai4co/rl4co" rel="noopener noreferrer"&gt;RL4CO GitHub&lt;/a&gt;). Published at KDD 2025, the library's greatest value is not the methods themselves but the reproducible comparison benchmarks it provides—the community has since discovered that evaluation protocols influence conclusions far more than expected (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;RL4CO, KDD 2025&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;On the benchmark side, Shanghai Jiao Tong University's Thinklab team built &lt;strong&gt;ML4CO-Bench-101&lt;/strong&gt; (NeurIPS 2025), a unified benchmark for classical combinatorial problems on graphs (maximum cut, maximum independent set, minimum vertex cover, maximum clique, etc.), complemented by COExpander (ICML 2025, adaptive solution expansion) and diffusion generative search methods targeting test-time scaling (NeurIPS 2025); the awesome-ml4co repository continuously maintains problem-categorized paper lists and benchmark results, including leaderboards for standard settings such as TSP-1000 (&lt;a href="https://github.com/orgs/Thinklab-SJTU/repositories" rel="noopener noreferrer"&gt;Thinklab-SJTU&lt;/a&gt;, &lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;). For engineering teams, the recommended evaluation discipline is: start from RL4CO or ML4CO-Bench, add at least one strong classical baseline (LKH-3/HGS/Gurobi) on your own instance distribution, and report all three metrics—solution quality, end-to-end latency, and amortized training cost.&lt;/p&gt;

&lt;h3&gt;
  
  
  2.5 Frontier Progress (2024–2026): From Single-Task Specialists to Cross-Problem Generalist Solvers
&lt;/h3&gt;

&lt;p&gt;Since 2024, end-to-end NCO has undergone a clear paradigm shift: the research focus has moved from "training one expert model per problem" to &lt;strong&gt;training a single unified (multi-task) solver that generalizes across problems&lt;/strong&gt;. This route unfolds along two technical paths. The first is &lt;strong&gt;constraint-compositional multi-task learning&lt;/strong&gt;: treating different VRP variants as different combinations of constraint attributes and training a unified model in the combinatorial space to share knowledge—MTPOMO (KDD 2024) and MVMoE (ICML 2024, mixture-of-experts architecture) pioneered coverage of 16 problems; RouteFinder (2024) expanded to &lt;strong&gt;48 VRP variants&lt;/strong&gt; with an explicit "vehicle-routing foundation model" goal; CaDA (ICML 2025) introduced constraint-aware dual attention to further improve cross-problem capability; and &lt;strong&gt;URS&lt;/strong&gt; (2025) pushed coverage to &lt;strong&gt;107 routing problems&lt;/strong&gt; through a unified data representation while retaining zero-shot cross-problem generalization (&lt;a href="https://arxiv.org/html/2509.23413v1" rel="noopener noreferrer"&gt;URS&lt;/a&gt;). The second path is &lt;strong&gt;shared backbone + problem adapters&lt;/strong&gt;: GOAL (ICLR 2025) trains a generalist agent covering 9 problem classes with supervised learning, while TSP-FT and MTL-MAB use adapters to cut re-training costs for new problems (&lt;a href="https://arxiv.org/html/2509.23413v1" rel="noopener noreferrer"&gt;URS related-work table&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2506.02935v3" rel="noopener noreferrer"&gt;MTL-KD&lt;/a&gt;). The table below summarizes key attributes of representative unified solvers:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Method&lt;/th&gt;
&lt;th&gt;Year / Venue&lt;/th&gt;
&lt;th&gt;Training paradigm&lt;/th&gt;
&lt;th&gt;Problems covered&lt;/th&gt;
&lt;th&gt;Zero-shot cross-problem&lt;/th&gt;
&lt;th&gt;Mechanism highlights&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;MTPOMO&lt;/td&gt;
&lt;td&gt;2024, KDD&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;16&lt;/td&gt;
&lt;td&gt;✓&lt;/td&gt;
&lt;td&gt;Constraint-compositional multi-task&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;MVMoE&lt;/td&gt;
&lt;td&gt;2024, ICML&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;16&lt;/td&gt;
&lt;td&gt;✓&lt;/td&gt;
&lt;td&gt;Mixture of experts (MoE)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;RouteFinder&lt;/td&gt;
&lt;td&gt;2024&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;48&lt;/td&gt;
&lt;td&gt;✓&lt;/td&gt;
&lt;td&gt;Toward a VRP foundation model&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;CaDA&lt;/td&gt;
&lt;td&gt;2025, ICML&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;16&lt;/td&gt;
&lt;td&gt;✓&lt;/td&gt;
&lt;td&gt;Constraint-aware dual attention&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;GOAL&lt;/td&gt;
&lt;td&gt;2025, ICLR&lt;/td&gt;
&lt;td&gt;Supervised&lt;/td&gt;
&lt;td&gt;9&lt;/td&gt;
&lt;td&gt;✗ (adapter fine-tuning)&lt;/td&gt;
&lt;td&gt;Generalist CO agent&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;URS&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2025&lt;/td&gt;
&lt;td&gt;RL&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;107&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;✓&lt;/td&gt;
&lt;td&gt;Unified data representation&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;(Sources: &lt;a href="https://arxiv.org/html/2509.23413v1" rel="noopener noreferrer"&gt;URS paper, Table 1&lt;/a&gt;, &lt;a href="https://github.com/meshkorea/NCO-solvers-for-VRP-fork" rel="noopener noreferrer"&gt;NCO-VRP literature list&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;A parallel main line confronts NCO with the complexity of &lt;strong&gt;real-world routing&lt;/strong&gt;: RRNCO (ICLR 2026) observes that the uniform random point sets of academic benchmarks differ enormously from demand distributions on real road networks, and its systematic evaluation on real map data shows that many methods that excel on standard benchmarks change rank significantly under real distributions—echoing the critique in §2.3 and marking the community's adoption of "real-distribution generalization" as a first-class evaluation target (&lt;a href="https://proceedings.iclr.cc/paper_files/paper/2026/file/9446c291a8744a125a0bda5b18f4d5a1-Paper-Conference.pdf" rel="noopener noreferrer"&gt;RRNCO, ICLR 2026&lt;/a&gt;). In addition, a 2026 paper in &lt;em&gt;AI&lt;/em&gt; (MDPI) explores a "&lt;strong&gt;near-training-free&lt;/strong&gt;" foundation-model route—constructing routing solvers directly from pre-trained representations and attempting to compress NCO's training cost toward zero, the latest attempt to lower the adoption barrier of the end-to-end route (&lt;a href="https://www.mdpi.com/2673-4117/7/8/375" rel="noopener noreferrer"&gt;MDPI AI 2026&lt;/a&gt;). Overall assessment: the unified-solver direction has significantly expanded the practical imagination of the end-to-end route, but its solution-quality gap relative to HGS/LKH-3 on real distributions and large-scale instances persists, and the hybrid architecture of Chapter 3 remains the holder of the current performance ceiling.&lt;/p&gt;




&lt;h2&gt;
  
  
  3. Paradigm 2: Learning-Augmented Classical Solvers
&lt;/h2&gt;

&lt;h3&gt;
  
  
  3.1 Learning Components Inside MIP Solvers
&lt;/h3&gt;

&lt;p&gt;In contrast to the end-to-end route's "replacement" philosophy, the learning-augmented route (learning-augmented / learning-guided optimization) embeds learned models at decision points inside classical solvers, &lt;strong&gt;preserving the solver's completeness and feasibility guarantees while letting machine learning take over heuristic decisions that traditionally rely on human experience&lt;/strong&gt;. This is currently the most theoretically robust and industrially accepted route. A 2024 survey in &lt;em&gt;Mathematical Programming&lt;/em&gt; systematically organizes learning tasks in mixed-integer programming (MIP) into five categories: branching variable selection, node selection, cut selection, primal heuristics, and solver configuration (&lt;a href="https://link.springer.com/article/10.1007/s10107-024-02130-y" rel="noopener noreferrer"&gt;Math. Programming 2024&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;In &lt;strong&gt;branching&lt;/strong&gt;, Khalil et al. pioneered imitation learning of strong branching in 2016; Gasse et al. (2019) introduced bipartite-graph representations + graph convolutional networks, exploiting the permutation invariance of the MIP variable–constraint bipartite graph and becoming the standard encoding for all subsequent learned branching methods; theoretical work in 2025 further proved that carefully designed second-order GNNs can approximate strong-branching scores on general MIPs with high precision, providing a theoretical foundation for the route (&lt;a href="https://journal.hep.com.cn/fem/EN/10.1007/s42524-026-5153-z" rel="noopener noreferrer"&gt;survey of math-programming solvers&lt;/a&gt;). In &lt;strong&gt;cut selection&lt;/strong&gt;, Tang et al. (2020) modeled cut selection as an MDP trained with RL; Paulus et al.'s 2022 follow-up validated solving-time gains in SCIP, and other work performs adaptive learning directly on the convex-combination weights of SCIP's four default cut-scoring functions (&lt;a href="https://link.springer.com/article/10.1007/s10107-024-02130-y" rel="noopener noreferrer"&gt;Math. Programming 2024&lt;/a&gt;). In &lt;strong&gt;primal heuristics&lt;/strong&gt;, Nair et al.'s Neural Diving (2020) uses a deep network to predict partial assignments of integer variables, leaving the rest to the MIP solver; Han et al.'s Predict-and-Search framework (2023) combines GNN prediction with trust-region search, reducing the primal gap by 51% relative to SCIP and 9.9% relative to Gurobi; subsequent work includes RL primal heuristics that model feasible-solution search as an MDP (improving the average primal gap over classical heuristics by up to 44×) and FMIP, which uses flow matching to generate joint solution distributions over integer and continuous variables (improving mean absolute gap by 50% over classical GNN heuristics) (&lt;a href="https://arxiv.org/html/2406.12349v1" rel="noopener noreferrer"&gt;Guided Diffusion for IP&lt;/a&gt;, &lt;a href="https://www.emergentmind.com/topics/mixed-integer-linear-programming-milp-problem" rel="noopener noreferrer"&gt;MILP learned-heuristics survey&lt;/a&gt;). The 2025–2026 frontier is MIP foundation models: MILP-Evolve uses LLMs to generate training data and trains unified neural models across problem categories, serving integrality-gap prediction, branching, and language–MIP alignment tasks alike (&lt;a href="https://www.emergentmind.com/topics/mixed-integer-linear-programming-milp-problem" rel="noopener noreferrer"&gt;EmergentMind MILP&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  3.2 Learning-Guided Neighborhood Search and Hybrid Frameworks
&lt;/h3&gt;

&lt;p&gt;On the metaheuristic side, learning's role is to guide search toward more promising regions. &lt;strong&gt;NeuroLKH&lt;/strong&gt; (NeurIPS 2021) is the landmark of this route: it uses a sparse graph network to learn edge scores (supervised) and node penalties (unsupervised), injecting them into the classic Lin-Kernighan-Helsgaun algorithm; trained on instances of at most 500 nodes, it generalizes to 5,000-node instances and outperforms the original LKH overall on 72 TSPLIB instances (&lt;a href="https://link.springer.com/article/10.1007/s10462-025-11267-x" rel="noopener noreferrer"&gt;ML-for-TSP survey, Springer 2025&lt;/a&gt;). Similarly, learned large neighborhood search (Neural LNS) learns where to destroy in the destroy-and-repair operator; new 2026 work injects neural guidance into ant colony optimization (ACO), replacing hand-crafted pheromone rules with dynamic neural signals—the paper explicitly states that such &lt;strong&gt;learning-guided optimization (LGO) usually achieves state-of-the-art performance by combining the strengths of both paradigms&lt;/strong&gt; (&lt;a href="https://arxiv.org/html/2606.04039v1" rel="noopener noreferrer"&gt;neural-guided ACO&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Another important form of the hybrid route is &lt;strong&gt;combining learning with decomposition/column generation&lt;/strong&gt;: for example, using ML to predict pricing-subproblem heuristics in column generation, using classifiers to identify structural features of high-quality solutions, or using RL to guide search trees in constraint programming to minimize search size (already validated on scheduling benchmarks) (&lt;a href="https://www.euraxess.cz/jobs/415421" rel="noopener noreferrer"&gt;CIIRC project description&lt;/a&gt;). The common trait of these works is "small but precise"—the learned model is responsible for only one narrow decision point, and training data can be generated offline by the solver itself, so training cost is low and failure risk is contained: precisely the properties industrial deployment values most.&lt;/p&gt;

&lt;h3&gt;
  
  
  3.3 Why the Hybrid Route Is Today's Industrial Mainstream
&lt;/h3&gt;

&lt;p&gt;From an engineering perspective, the hybrid route beats the end-to-end route for three reasons. &lt;strong&gt;First, risk structure&lt;/strong&gt;: in hybrid methods, even if the learned component fails entirely, the solver degrades to its default heuristic rules and still produces legal solutions with guaranteed quality—this "graceful degradation" property is vital for production systems, whereas an end-to-end model's failure modes are uncontrollable. &lt;strong&gt;Second, evidence accumulation&lt;/strong&gt;: commercial and open-source solvers (Gurobi, SCIP, CP-SAT) have been validated for decades, and the organizational cost of migrating trust far exceeds what a few percentage points on academic metrics can motivate. &lt;strong&gt;Third, data availability&lt;/strong&gt;: training data for hybrid methods (branching decision logs, cut-plane payoffs, solutions to historical instances) accumulates automatically during everyday solving, requiring no extra labeling. A strong corroborating data point: even on academic benchmarks, the strongest "learning-based" results today mostly come from hybrid architectures—for example, a scalable "learning + integer linear programming" framework improves large-scale CVRP solving while preserving feasibility and practical constraints (&lt;a href="https://peerj.com/articles/cs-3516/" rel="noopener noreferrer"&gt;PeerJ CS 2026&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;For teams adopting this route, &lt;strong&gt;Ecole&lt;/strong&gt; is the most important piece of infrastructure: a Gym-like library that exposes decision points inside the SCIP solver (branching, node selection, etc.) as standard reinforcement-learning environments, turning the training of customized solver components into an ordinary RL engineering task (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;Ecole cited in the RL4CO paper&lt;/a&gt;). Together with PySCIPOpt and open-source SCIP, a two-person team can build a "learned branching policy" prototype within weeks.&lt;/p&gt;

&lt;h3&gt;
  
  
  3.4 Frontier Progress (2024–2026): LLMs Enter the Solver; the Predict-and-Search Family Grows
&lt;/h3&gt;

&lt;p&gt;Learning-augmented solvers deepened along three directions in 2024–2026. &lt;strong&gt;First, the engineering and lightweighting of learned branching.&lt;/strong&gt; Gupta et al.'s hybrid architecture (whose influence from NeurIPS 2020 continues to grow) showed that a "heavy–light" arrangement—GNN only at the root node, MLP for subsequent nodes—can cut solving time by up to &lt;strong&gt;26%&lt;/strong&gt; in a pure-CPU environment, a result of major significance for deployment since virtually all commercial MILP solving runs on CPUs (&lt;a href="https://proceedings.neurips.cc/paper/2020/file/d1e946f4e67db4b362ad23818a6fb78a-Paper.pdf" rel="noopener noreferrer"&gt;Hybrid Learn2Branch&lt;/a&gt;). A 2025 paper in &lt;em&gt;Soft Computing&lt;/em&gt; further unifies node selection and variable selection in a single GNN framework, surpassing SCIP and then-current RL baselines on four classical benchmark families (&lt;a href="https://www.sciencedirect.com/science/article/abs/pii/S1568494625001747" rel="noopener noreferrer"&gt;Soft Computing 2025&lt;/a&gt;); meanwhile Symb4CO uses symbolic regression to search directly for &lt;strong&gt;human-readable branching rules&lt;/strong&gt;, and SORREL combines offline pre-training with self-imitation learning, advancing on the pain points of "interpretability" and "escaping expensive expert demonstrations" respectively (&lt;a href="https://arxiv.org/html/2605.10401v1" rel="noopener noreferrer"&gt;LLM4Branch related work&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Second, the predict-and-search family is growing rapidly.&lt;/strong&gt; After Neural Diving and Predict-and-Search came the contrastive-learning variant Contrastive Predict-and-Search, SymILO exploiting MILP permutation symmetry, DiffILO introducing gradient information, the "predict–correct" framework Apollo-MILP, and—in late 2025—CoCo-MILP, which further improves GNN solution prediction with inter-variable contrastive losses and intra-constraint competition layers (&lt;a href="https://arxiv.org/pdf/2511.09209" rel="noopener noreferrer"&gt;CoCo-MILP&lt;/a&gt;, &lt;a href="https://openreview.net/pdf?id=ztCVzRbnvQ" rel="noopener noreferrer"&gt;Apollo-MILP related work&lt;/a&gt;). &lt;strong&gt;Third—and most paradigm-significant—LLMs are entering the design loop of internal solver components.&lt;/strong&gt; &lt;strong&gt;LLM4Branch&lt;/strong&gt; (2026) lets an LLM (DeepSeek-R1) automatically discover branching policies as executable programs: the LLM generates program skeletons for policies, zeroth-order optimization (Bayesian optimization) fine-tunes parameters against real solver feedback, and the whole evolutionary loop—built on OpenEvolve and Ecole—automatically evolves policies that beat hand-crafted rules, optimizing the geometric mean of branch-and-bound node counts (&lt;a href="https://arxiv.org/html/2605.10401v1" rel="noopener noreferrer"&gt;LLM4Branch&lt;/a&gt;); contemporaneous work includes LLM-driven large neighborhood search for MILP (ICML 2025), LLM-guided dynamic scheduling of branching rules, and online algorithm configuration (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). This means the two threads of "learning-augmented components" (this chapter) and "LLM-evolved heuristics" (Chapter 6) are now converging inside solvers.&lt;/p&gt;

&lt;p&gt;On the evaluation side, the 2026 &lt;strong&gt;FrontierCO&lt;/strong&gt; benchmark systematically stress-tested contemporary ML solvers on real-world and large-scale instances; entrants span tree-MDP branching (tMDP), SORREL, GCNN branching, IL-LNS/CL-LNS neighborhood search, MPGN for FJSP, and learning-guided rolling-horizon optimization (L-RHO), among others. Its conclusions extend this report's thesis: learning methods deliver real speedups on in-distribution cases, but classical solvers remain the baseline of performance and robustness under distribution shift and at very large scale (&lt;a href="https://arxiv.org/html/2505.16952v3" rel="noopener noreferrer"&gt;FrontierCO&lt;/a&gt;). The direct advice for engineering teams: when evaluating any learning-augmented component, prefer results from such third-party unified benchmarks over the speedups self-reported in the original paper.&lt;/p&gt;




&lt;h2&gt;
  
  
  4. Paradigm 3: Learning to Optimize (Learned Optimizers)
&lt;/h2&gt;

&lt;h3&gt;
  
  
  4.1 Replacing Hand-Designed Optimization Algorithms with Learning
&lt;/h3&gt;

&lt;p&gt;Learning to Optimize (L2O) is the most "meta" of the six paradigms: &lt;strong&gt;the object being learned is not the solution to some problem, but the optimization algorithm itself&lt;/strong&gt;. Its standard formalization: given a family of training optimization problems 

&lt;span class="katex-element"&gt;
  &lt;span class="katex"&gt;&lt;span class="katex-mathml"&gt;&lt;/span&gt;&lt;span class="katex-html"&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord mathcal"&gt;F&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;
&lt;/span&gt;
, learn a parameterized update map 
&lt;span class="katex-element"&gt;
  &lt;span class="katex"&gt;&lt;span class="katex-mathml"&gt;&lt;/span&gt;&lt;span class="katex-html"&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathnormal"&gt;x&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t vlist-t2"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mord mtight"&gt;&lt;span class="mord mathnormal mtight"&gt;t&lt;/span&gt;&lt;span class="mbin mtight"&gt;+&lt;/span&gt;&lt;span class="mord mtight"&gt;1&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-s"&gt;​&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;span class="mrel"&gt;=&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathnormal"&gt;x&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t vlist-t2"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mord mathnormal mtight"&gt;t&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-s"&gt;​&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;span class="mbin"&gt;−&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathnormal"&gt;g&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t vlist-t2"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mord mathnormal mtight"&gt;θ&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-s"&gt;​&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mopen"&gt;(&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathnormal"&gt;I&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t vlist-t2"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mord mathnormal mtight"&gt;t&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-s"&gt;​&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mclose"&gt;)&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;
&lt;/span&gt;
 (where 
&lt;span class="katex-element"&gt;
  &lt;span class="katex"&gt;&lt;span class="katex-mathml"&gt;&lt;/span&gt;&lt;span class="katex-html"&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathnormal"&gt;I&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t vlist-t2"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mord mathnormal mtight"&gt;t&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-s"&gt;​&lt;/span&gt;&lt;/span&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;
&lt;/span&gt;
 contains historical iterates and gradient information) such that, on new problems sampled from the distribution, the learned optimizer converges faster than analytic optimizers like SGD/Adam or reaches better solutions under the same compute budget (&lt;a href="https://openreview.net/pdf/d861873084f9cebb326b2c8b521d6dc9b05b3f0a.pdf" rel="noopener noreferrer"&gt;OpenReview L2O&lt;/a&gt;). The direction was founded by Andrychowicz et al.'s 2016 LSTM optimizer and Li &amp;amp; Malik's RL optimizer, followed by a long period of improvements overcoming pathological long-unroll gradients and improving cross-task generalization; the 2022 JMLR paper &lt;em&gt;Learning to Optimize: A Primer and A Benchmark&lt;/em&gt; (by teams including USTC and Huawei Noah's Ark) established unified implementation standards and a benchmark, and remains the standard introductory reading (&lt;a href="http://jmlr.org/papers/volume23/21-0308/21-0308.pdf" rel="noopener noreferrer"&gt;JMLR 2022&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;L2O has long been criticized for "working only on the training distribution and lacking convergence guarantees"; both shortcomings have seen substantive progress recently. On generalization, an AISTATS 2023 paper used Hessian regularization to give learned optimizers provable generalization to unseen network architectures and datasets (&lt;a href="https://proceedings.mlr.press/v206/yang23h/yang23h.pdf" rel="noopener noreferrer"&gt;AISTATS 2023&lt;/a&gt;); on convergence guarantees, a 2024 framework decomposes the update rule into a "convergence-guaranteed gradient-descent term + a performance-boosting neural-network innovation term," achieving—for the first time—an optimizer with both provable convergence on smooth non-convex functions and learned acceleration (&lt;a href="https://www.enzymestudy.com/posts/michaelismenten-parameter-estimation-a-2025-guide-to-accurately-determining-vmax-and-km-for-drug-development" rel="noopener noreferrer"&gt;technical overview&lt;/a&gt;). A more theoretical sub-line interprets Transformers' in-context learning as implicitly executing (preconditioned) gradient descent, mechanistically connecting "large-model inference" with "learning to optimize" (&lt;a href="https://arxiv.org/html/2410.13981v1" rel="noopener noreferrer"&gt;arXiv 2024&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  4.2 The Industrialization of HPO and Symbolic Optimizer Discovery
&lt;/h3&gt;

&lt;p&gt;The most mature industrial form of L2O is not in neural-network training but in &lt;strong&gt;black-box / hyperparameter optimization (HPO)&lt;/strong&gt;. Google's &lt;strong&gt;OptFormer&lt;/strong&gt; (NeurIPS 2022) is the landmark: it serializes entire hyperparameter-optimization processes (including task metadata text) into tokens and pre-trains a Transformer on years of real optimization trajectories accumulated by Google's Vizier service plus the public HPO-B and BBOB benchmarks; the resulting model can both imitate the behavior of classical algorithms such as Regularized Evolution and serve as a better-calibrated objective predictor than Gaussian processes—a first sketch of a "universal hyperparameter optimizer" (&lt;a href="https://ai.googleblog.com/2022/08/optformer-towards-universal.html" rel="noopener noreferrer"&gt;Google AI Blog&lt;/a&gt;). OptFormer's significance is the demonstration that when an organization possesses massive historical optimization-experiment data, meta-learning can convert that sediment into transferable optimization capability.&lt;/p&gt;

&lt;p&gt;A second sub-line with more direct industrial impact is &lt;strong&gt;symbolic optimizer discovery&lt;/strong&gt;. Google's VeLO (Versatile Learned Optimizer, 2022) meta-trained a general-purpose learned optimizer over thousands of tasks; the 2023–2024 "symbolic discovery of optimization algorithms" work used evolutionary search in program space to discover the &lt;strong&gt;Lion&lt;/strong&gt; optimizer directly—its update rule consists of simple symbolic expressions, uses less memory than Adam, and performs better on many models, and it has since been adopted by numerous open-source training frameworks (&lt;a href="https://www.linkedin.com/pulse/deepmind-has-always-published-best-research-ai-solve-hard-math-deedy-das" rel="noopener noreferrer"&gt;DeepMind math-optimization research roundup&lt;/a&gt;). This idea of "searching algorithm space rather than numerical space" descends from the same lineage as Chapter 6's FunSearch/AlphaEvolve family, jointly pointing to one trend: &lt;strong&gt;optimization algorithms themselves are turning from hand-crafted artifacts into searchable, evolvable objects&lt;/strong&gt;.&lt;/p&gt;

&lt;h3&gt;
  
  
  4.3 Frontier Progress (2024–2026): The Muon Event and the Industrialization of Optimizer Discovery
&lt;/h3&gt;

&lt;p&gt;In late 2024 the L2O field saw its most industrially consequential event in a decade—the birth and explosive adoption of the &lt;strong&gt;Muon optimizer&lt;/strong&gt;. Muon (MomentUm Orthogonalized by Newton-Schulz) was forged by Keller Jordan and collaborators in the NanoGPT speedrun competition: momentum updates to hidden-layer parameters are orthogonalized via Newton-Schulz iteration before being applied. In October 2024 it improved the NanoGPT training-speed record by &lt;strong&gt;1.35×&lt;/strong&gt;; the record was subsequently refreshed 12 times by 7 different researchers without being overturned, compressing GPT-2 training wall-clock time from a 45-minute baseline to under 3 minutes (&lt;a href="https://kellerjordan.github.io/posts/muon/" rel="noopener noreferrer"&gt;original Muon blog post&lt;/a&gt;, &lt;a href="https://github.com/kellerjordan/modded-nanogpt" rel="noopener noreferrer"&gt;modded-nanogpt&lt;/a&gt;). In February 2025, Moonshot AI and UCLA's &lt;em&gt;Muon is Scalable for LLM Training&lt;/em&gt; demonstrated roughly &lt;strong&gt;2× compute efficiency&lt;/strong&gt; over AdamW on 3B/16B-parameter MoE models and proposed stabilization techniques such as MuonClip; the trillion-parameter-class MoE model &lt;strong&gt;Kimi K2&lt;/strong&gt;, released in July 2025, was trained end-to-end with the Muon family without a single loss spike—marking this "competition artifact's" formal entry into frontier-LLM production pipelines (&lt;a href="https://arxiv.org/abs/2502.16982" rel="noopener noreferrer"&gt;Muon is Scalable&lt;/a&gt;, &lt;a href="https://arxiv.org/abs/2507.20534" rel="noopener noreferrer"&gt;Kimi K2&lt;/a&gt;). Microsoft's &lt;strong&gt;Dion&lt;/strong&gt; (August 2025) works to adapt orthogonalized updates to the communication constraints of distributed training, further clearing engineering obstacles (&lt;a href="https://www.marketscreener.com/news/microsoft-dion-boosts-optimization-method-for-training-new-ai-models-ce7c51d9dd8df020" rel="noopener noreferrer"&gt;Microsoft Dion coverage&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The Muon event's significance for L2O methodology arguably exceeds that of the optimizer itself. Jordan states explicitly in his blog that the NanoGPT speedrun, as a &lt;strong&gt;competitive task framework&lt;/strong&gt;, fundamentally solves the "undertuned baseline" problem that has long plagued optimizer research: anyone can overturn Muon's record by switching back to carefully tuned AdamW, so the record's continued existence is itself publicly verifiable evidence—a brand-new empirical-sociological mechanism for the controversy over "whether learned/searched optimizers are actually good" (&lt;a href="https://kellerjordan.github.io/posts/muon/" rel="noopener noreferrer"&gt;original Muon blog post&lt;/a&gt;). Building on this, the 2025 &lt;strong&gt;automated LLM speedrun benchmark&lt;/strong&gt; goes one step further: having AI agents automatically reproduce and surpass the NanoGPT lineage of improvements, turning "optimization-algorithm design" itself into an automatically scoreable agent task (&lt;a href="https://arxiv.org/html/2506.22419v2" rel="noopener noreferrer"&gt;Automated Speedrun Benchmark&lt;/a&gt;); the speedrun competition subsequently added Track 3, which fixes model, data, and scripts while opening only the optimization algorithm and hyperparameters—dedicated to evaluating automated optimizer discovery—and platforms such as Prime Intellect have begun running &lt;strong&gt;autonomous AI research agents&lt;/strong&gt; against that track (&lt;a href="https://www.primeintellect.ai/auto-nanogpt" rel="noopener noreferrer"&gt;Prime Intellect&lt;/a&gt;). With this, L2O has closed a loop: from "learning an optimizer" (§4.1) to "screening optimizers with competitive benchmarks" to "letting AI agents design optimizers autonomously"—optimizer design is becoming an automatable, verifiable, iterable engineering discipline.&lt;/p&gt;




&lt;h2&gt;
  
  
  5. Paradigm 4: Decision-Focused Learning and Differentiable Optimization (Predict-then-Optimize)
&lt;/h2&gt;

&lt;h3&gt;
  
  
  5.1 Problem Setup: Making Predictions Accountable to Decisions
&lt;/h3&gt;

&lt;p&gt;Real industrial optimization pipelines are almost always two-stage: first use machine learning to predict uncertain parameters (demand, prices, travel times), then feed the predictions into an optimization model. Traditional "predict-then-optimize" trains the predictive model to minimize prediction error (e.g., MSE), but &lt;strong&gt;accurate prediction does not equal good decisions&lt;/strong&gt;—a symmetric prediction error can have highly asymmetric effects on decision cost (overestimating demand and underestimating it carry completely different costs). Decision-focused learning (DFL) targets precisely this mismatch: at training time it embeds the downstream optimization problem into the computation graph and trains directly on final decision quality (regret). Mandi et al.'s 2024 survey systematically maps the DFL technical landscape, classifying gradient-acquisition methods into four families—surrogate losses, differentiable relaxations, perturbation methods, and gradient-free estimation—and experimentally compares 11 mainstream techniques on benchmark problems (&lt;a href="https://arxiv.org/html/2307.13565v4" rel="noopener noreferrer"&gt;Mandi et al. 2024&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The paradigm's cornerstone is Elmachtoub and Grigas's &lt;strong&gt;Smart Predict-then-Optimize (SPO)&lt;/strong&gt; framework and its convex surrogate loss SPO+: since the true regret's gradient with respect to predicted coefficients is zero almost everywhere, SPO+ constructs a Fisher-consistent convex upper-bound surrogate and provides a subgradient usable for neural-network backpropagation, 
&lt;span class="katex-element"&gt;
  &lt;span class="katex"&gt;&lt;span class="katex-mathml"&gt;&lt;/span&gt;&lt;span class="katex-html"&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathbf"&gt;x&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mbin mtight"&gt;⋆&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mopen"&gt;(&lt;/span&gt;&lt;span class="mord mathbf"&gt;c&lt;/span&gt;&lt;span class="mclose"&gt;)&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;span class="mbin"&gt;−&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord"&gt;&lt;span class="mord mathbf"&gt;x&lt;/span&gt;&lt;span class="msupsub"&gt;&lt;span class="vlist-t"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="sizing reset-size6 size3 mtight"&gt;&lt;span class="mbin mtight"&gt;⋆&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mopen"&gt;(&lt;/span&gt;&lt;span class="mord"&gt;2&lt;/span&gt;&lt;span class="mord accent"&gt;&lt;span class="vlist-t"&gt;&lt;span class="vlist-r"&gt;&lt;span class="vlist"&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="mord mathbf"&gt;c&lt;/span&gt;&lt;/span&gt;&lt;span&gt;&lt;span class="pstrut"&gt;&lt;/span&gt;&lt;span class="accent-body"&gt;&lt;span class="mord"&gt;^&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;span class="mbin"&gt;−&lt;/span&gt;&lt;span class="mspace"&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="base"&gt;&lt;span class="strut"&gt;&lt;/span&gt;&lt;span class="mord mathbf"&gt;c&lt;/span&gt;&lt;span class="mclose"&gt;)&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;
&lt;/span&gt;
 (&lt;a href="https://arxiv.org/html/2307.13565v4" rel="noopener noreferrer"&gt;Mandi et al. 2024&lt;/a&gt;). Other important techniques include Fenchel–Young losses (structured prediction), Berthet et al.'s differentiable perturbed optimizers (obtaining smooth gradients by averaging over perturbed solutions), and the OptNet line of methods that embed optimization problems as differentiable layers in networks. A 2025 contextual-optimization survey in &lt;em&gt;EJOR&lt;/em&gt; broadens the view to contextual decision problems under uncertainty, covering the full spectrum from sample average approximation to distributionally robust approaches (&lt;a href="https://tristan2025.org/proceedings/TRISTAN2025_ExtendedAbstract_334.pdf" rel="noopener noreferrer"&gt;TRISTAN 2025 proceedings&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  5.2 Toolchain and Applicable Scenarios
&lt;/h3&gt;

&lt;p&gt;DFL has the &lt;strong&gt;most complete engineering loop&lt;/strong&gt; of the six paradigms, and its core tool is &lt;strong&gt;PyEPO&lt;/strong&gt;: a PyTorch-based end-to-end "predict–optimize" library with built-in autograd functions for mainstream methods (SPO+, differentiable perturbation, contrastive losses), optimization backends connectable to Gurobi and other solvers; users only need to subclass &lt;code&gt;optGrbModel&lt;/code&gt; to define their optimization model and gain end-to-end training capability. The library has been formally published in &lt;em&gt;Mathematical Programming Computation&lt;/em&gt; (&lt;a href="https://arxiv.org/html/2206.14234v3" rel="noopener noreferrer"&gt;PyEPO&lt;/a&gt;). Its surrounding research ecosystem also includes decision-focused fine-tuning (2025)—balancing prediction accuracy against decision loss in a constrained-optimization form for data-limited settings (&lt;a href="https://arxiv.org/html/2501.01874v1" rel="noopener noreferrer"&gt;arXiv 2025&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Engineering-wise, DFL fits best when three features coincide: the optimization model's objective coefficients depend on predictions (costs, demand, travel times); there is a known asymmetry between prediction error and decision cost; and historical (features, realizations, decision outcomes) data is abundant. Typical applications include electricity-price prediction + unit commitment in power markets, travel-time prediction + vehicle routing in logistics, and demand prediction + replenishment optimization in inventory. Conversely, if prediction error is already near the noise floor, or decisions are insensitive to prediction error, DFL's extra complexity (each training iteration must solve an optimization problem, significantly increasing compute) is hard to recoup. In practice, first use PyEPO on small-scale data to compare decision regret between the "two-stage MSE baseline" and "SPO+ end-to-end," then decide whether to invest.&lt;/p&gt;

&lt;h3&gt;
  
  
  5.3 Frontier Developments: Benchmark Standardization and a Unified View of Contextual Decisions
&lt;/h3&gt;

&lt;p&gt;DFL's important progress in 2024–2026 lies not in any single new algorithm but in &lt;strong&gt;standardized evaluation and a unified problem perspective&lt;/strong&gt;. Mandi et al.'s 2024 survey, beyond organizing the technical genealogy, conducted the first controlled experimental comparison of 11 mainstream DFL methods on unified benchmark problems, revealing the global picture of "the trade-off curve between training efficiency and decision quality for surrogate-loss methods"—previously obscured by papers' individual reporting conventions—providing the first horizontal evidence base for engineering selection (&lt;a href="https://arxiv.org/html/2307.13565v4" rel="noopener noreferrer"&gt;Mandi et al. 2024&lt;/a&gt;). The 2025 contextual-optimization survey in &lt;em&gt;EJOR&lt;/em&gt; places DFL under a larger umbrella: any problem that makes uncertainty-facing decisions conditioned on covariates (features)—whether using SPO-style regret training, sample average approximation, or distributionally robust optimization—shares the same theoretical framework of "how predictive distributions should serve decisions" (&lt;a href="https://tristan2025.org/proceedings/TRISTAN2025_ExtendedAbstract_334.pdf" rel="noopener noreferrer"&gt;TRISTAN 2025 proceedings&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Another noteworthy development is DFL's interface with the foundation-model era. Decision-focused fine-tuning (2025) transplants DFL's objective to the adaptation stage of pre-trained models: in data-limited settings it simultaneously constrains prediction accuracy and decision loss in constrained-optimization form, preventing the fine-tuning process from degrading downstream decision performance (&lt;a href="https://arxiv.org/html/2501.01874v1" rel="noopener noreferrer"&gt;arXiv 2025&lt;/a&gt;). The implicit judgment of this direction: as predictive models are increasingly carried by general-purpose foundation models, "how to preserve decision quality when freezing or fine-tuning a foundation model" will replace "how to train a decision-friendly predictor from scratch" as DFL's main battleground. The engineering action advice is unchanged—first run a small-scale PyEPO comparison between the two-stage MSE baseline and SPO+ end-to-end—but the evaluation checklist should gain one item: if the prediction side already uses (or plans to use) a foundation model, prefer decision-focused fine-tuning methods over full retraining.&lt;/p&gt;




&lt;h2&gt;
  
  
  6. Paradigm 5: LLM-Driven Optimization
&lt;/h2&gt;

&lt;h3&gt;
  
  
  6.1 LLMs as Optimizers: OPRO and Prompt-Space Search
&lt;/h3&gt;

&lt;p&gt;Since 2023, large language models have brought an entirely new working mode to optimization. The most direct form is &lt;strong&gt;OPRO (Optimization by PROmpting, ICLR 2024)&lt;/strong&gt;: treat the LLM itself as a black-box optimizer—place previously evaluated "solution–score" pairs in the prompt, let the model generate better candidate solutions, and iterate. OPRO validated the idea on linear regression and the traveling salesman problem; its essence is to hand the optimization "proposal distribution" to the language model's prior knowledge (&lt;a href="https://arxiv.org/html/2609.05740v1" rel="noopener noreferrer"&gt;SimTIO survey chapter&lt;/a&gt;). The paradigm's advantages are a zero-code threshold and native multi-objective trade-off ability (preferences can be described in natural language); its limitations are suitability only for small-scale, textually representable search spaces, with evaluation costs borne by the caller.&lt;/p&gt;

&lt;p&gt;OPRO's idea quickly combined with classical prompt engineering, spawning variants such as automatic prompt optimization, adaptive zeroth-order optimization (AdaEvolve), and EvoX, which lets the LLM evolve both candidate solutions and the search strategy itself; academia has also begun systematically building evaluations, such as OPT-BENCH (measuring LLM agents' optimization ability in large search spaces), ALE-Bench for long-horizon algorithm engineering (a NeurIPS 2025 datasets-and-benchmarks track), and HeuriGym (ICLR 2026, an agentic benchmark for LLM-designed combinatorial-optimization heuristics) (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). For engineering teams, the best current positioning of such methods is &lt;strong&gt;rapid prototyping and small-scale black-box tuning&lt;/strong&gt;, not replacing numerical optimizers.&lt;/p&gt;

&lt;h3&gt;
  
  
  6.2 Heuristic Evolution and Algorithm Discovery: The FunSearch–AlphaEvolve Lineage
&lt;/h3&gt;

&lt;p&gt;The most influential form of LLM optimization is the triple structure of "&lt;strong&gt;LLM generation + automatic evaluation + evolutionary search&lt;/strong&gt;." DeepMind's &lt;strong&gt;FunSearch&lt;/strong&gt; (&lt;em&gt;Nature&lt;/em&gt; 2023) is the paradigm's founding work: it frames problems as "search in the space of functions (programs)"; the LLM rewrites the priority functions of candidate programs; an automatic evaluator scores candidates and filters hallucinations; and island-style evolutionary strategies maintain population diversity. The system discovered a new size-512 construction for the Cap Set problem in combinatorial mathematics (surpassing known human results) and evolved heuristics for online bin packing that beat first-fit/best-fit—becoming the first LLM system to produce verifiable new knowledge (&lt;a href="https://deepmind.google/blog/funsearch-making-new-discoveries-in-mathematical-sciences-using-large-language-models/" rel="noopener noreferrer"&gt;DeepMind blog&lt;/a&gt;, &lt;a href="https://en.wikipedia.org/wiki/FunSearch" rel="noopener noreferrer"&gt;Wikipedia: FunSearch&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The lineage then evolved rapidly: &lt;strong&gt;EoH (Evolution of Heuristics, 2024)&lt;/strong&gt; co-evolves heuristics' natural-language "thoughts" and their corresponding code, surpassing FunSearch on multiple combinatorial problems; &lt;strong&gt;ReEvo (NeurIPS 2024)&lt;/strong&gt; introduces reflection, converting performance comparisons into linguistic feedback guiding the next generation; &lt;strong&gt;MCTS-AHD&lt;/strong&gt; organizes candidate programs with Monte Carlo tree search; and &lt;strong&gt;AlphaEvolve (DeepMind, May 2025)&lt;/strong&gt; pushed the entire paradigm to industrial scale—a Gemini-powered evolutionary coding agent that can evolve &lt;strong&gt;entire codebases&lt;/strong&gt; (rather than single functions), supports arbitrary programming languages, can evaluate in parallel for hours, and optimizes multiple metrics simultaneously; its results include breaking the matrix-multiplication algorithm record (48 multiplications for 4×4 complex matrices) and improving Google's data-center scheduling and chip-design circuits (&lt;a href="https://richardcsuwandi.github.io/blog/2025/llm-algorithm-discovery/" rel="noopener noreferrer"&gt;FunSearch vs AlphaEvolve comparison&lt;/a&gt;, &lt;a href="https://github.com/closedloop-technologies/awesome-llm-evolution" rel="noopener noreferrer"&gt;awesome-llm-evolution&lt;/a&gt;). The table below compares the capability differences of the lineage's two milestone systems:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Capability dimension&lt;/th&gt;
&lt;th&gt;FunSearch (2023)&lt;/th&gt;
&lt;th&gt;AlphaEvolve (2025)&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Code scope&lt;/td&gt;
&lt;td&gt;Evolves a single function&lt;/td&gt;
&lt;td&gt;Evolves entire codebases&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Code size&lt;/td&gt;
&lt;td&gt;10–20 lines&lt;/td&gt;
&lt;td&gt;Up to hundreds of lines&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Language support&lt;/td&gt;
&lt;td&gt;Python only&lt;/td&gt;
&lt;td&gt;Any programming language&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Evaluation compute&lt;/td&gt;
&lt;td&gt;≤20 min / single CPU core&lt;/td&gt;
&lt;td&gt;Parallel, accelerators, hours-long runs&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;LLM usage&lt;/td&gt;
&lt;td&gt;Millions of samples&lt;/td&gt;
&lt;td&gt;Thousands of samples suffice&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Context feedback&lt;/td&gt;
&lt;td&gt;Historical solutions only&lt;/td&gt;
&lt;td&gt;Rich context and evaluation feedback&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Optimization target&lt;/td&gt;
&lt;td&gt;Single metric&lt;/td&gt;
&lt;td&gt;Multiple metrics simultaneously&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Representative results&lt;/td&gt;
&lt;td&gt;New Cap Set construction; bin-packing heuristics&lt;/td&gt;
&lt;td&gt;Matrix-multiplication record; data-center scheduling improvements&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;(Source: &lt;a href="https://richardcsuwandi.github.io/blog/2025/llm-algorithm-discovery/" rel="noopener noreferrer"&gt;Richard Suwandi's technical blog&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;On the open-source side, &lt;strong&gt;OpenEvolve&lt;/strong&gt; provides an open reproduction framework of AlphaEvolve (supporting multi-language generation, integrated agents, and custom evaluation loops), while &lt;strong&gt;LLaMEA&lt;/strong&gt; uses GPT-4 to iteratively evolve optimization-algorithm code and surpasses classical optimizers on benchmark suites; the community-maintained awesome-llm-evolution list continuously indexes frameworks in this space by direction—code discovery, game strategies, molecules and materials, prompt optimization, and more (&lt;a href="https://github.com/closedloop-technologies/awesome-llm-evolution" rel="noopener noreferrer"&gt;awesome-llm-evolution&lt;/a&gt;). The lesson for engineering teams is clear: &lt;strong&gt;if your team has a programmatically evaluable objective function (even a simulator), a FunSearch-style framework is currently the most cost-effective path to "automatically inventing domain heuristics,"&lt;/strong&gt; and OpenEvolve has brought the setup cost down to an acceptable level.&lt;/p&gt;

&lt;h3&gt;
  
  
  6.3 LLM Automated Modeling: From Natural Language to Solver Code
&lt;/h3&gt;

&lt;p&gt;The biggest labor bottleneck in OR adoption has never been solving but &lt;strong&gt;modeling&lt;/strong&gt;—translating business language into mathematical programming models. LLMs are systematically attacking this step. Milestone works include: the NL4OPT competition's natural-language-to-LP modeling benchmark; Microsoft's &lt;strong&gt;Chain-of-Experts&lt;/strong&gt; multi-agent framework, which significantly surpasses GPT-4 baselines; &lt;strong&gt;OptiMUS&lt;/strong&gt; (ICML 2024), which completes MILP modeling and solving with a structured agent sequence (preprocessing—connection graph—per-item modeling—code generation—unit testing—debugging iterations), improving over the previous best method by more than 20% on a simple dataset and by more than 30% on its released complex dataset NLP4LP; and &lt;strong&gt;ORLM&lt;/strong&gt;, which instead fine-tunes open-source models on semi-synthetic data, achieving performance comparable to OptiMUS while protecting data privacy (&lt;a href="https://icml.cc/virtual/2024/poster/33771" rel="noopener noreferrer"&gt;OptiMUS, ICML 2024&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2405.17743v4" rel="noopener noreferrer"&gt;ORLM&lt;/a&gt;). Microsoft's &lt;strong&gt;OptiGuide&lt;/strong&gt; uses LLMs to explain supply-chain optimization results and support "what-if" interactive queries, while &lt;strong&gt;OptiChat&lt;/strong&gt; specializes in diagnosing infeasible models (&lt;a href="https://arxiv.org/html/2405.17743" rel="noopener noreferrer"&gt;ORLM literature review&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The engineering value of this direction is immediate: business users describe problems in natural language; the LLM generates models and solver code; classical solvers guarantee correctness and optimality—&lt;strong&gt;the LLM never touches numerical computation, doing only the semantic translation it excels at&lt;/strong&gt;, and the architecture's risk structure is exactly that of Chapter 3's hybrid route. Follow-up work in 2025–2026 (ORMind's cognition-inspired end-to-end reasoning framework, AutoOR's scalable automated-formalization post-training, NED-Tree's support for nonlinear-optimization modeling) is further covering more complex modeling scenarios (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). On the commercial side, NVIDIA has released validated "agent skills" for cuOpt, letting AI agents complete the "natural-language business problem → mathematical model → optimized decision" loop in seconds (&lt;a href="https://www.nvidia.com/en-us/ai-data-science/products/cuopt/" rel="noopener noreferrer"&gt;NVIDIA cuOpt&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  6.4 LLM End-to-End Solving and Inference-Time Search
&lt;/h3&gt;

&lt;p&gt;The most radical direction has LLMs directly output solutions to combinatorial optimization problems. NeurIPS 2025's &lt;em&gt;Large Language Models as End-to-end Combinatorial Optimization Solvers&lt;/em&gt; explored the feasibility of training LLMs as end-to-end solvers, covering classical graph problems such as maximum independent set and vertex cover (&lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;). A concurrent rise is "LLM + tree search" for inference-time planning: an October 2025 unifying survey systematically organizes MCTS variants in LLM reasoning (MCTSr, RethinkMCTS, AB-MCTS, etc.); the core design question is reliable value estimation for partial reasoning trajectories—from training external reward models, to LLM self-evaluation, to backpropagating environment rewards, to simply dropping the rollout step and guiding expansion directly with self-evaluation scores (&lt;a href="https://arxiv.org/html/2510.09988v1" rel="noopener noreferrer"&gt;tree-search unifying survey&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;A sober assessment is needed: LLM end-to-end solving currently cannot touch specialized NCO models in scale or precision, let alone classical solvers; its strategic value lies in &lt;strong&gt;generality and interface naturalness&lt;/strong&gt;—the same model can cross problem types and directly consume natural-language constraints. The pragmatic judgment: as of 2026, the LLM's best position in the optimization stack is the "modeling layer" and the "heuristic-design layer" (§6.2, §6.3), not the "numerical-solving layer"; but with the rapid accumulation in FM4CO (foundation models for combinatorial optimization)—the awesome-fm4co list indexed dozens of related papers in 2025–2026—this judgment warrants quarterly re-examination (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  6.5 Frontier Progress (2025–2026): Evaluation Suites Crystallize and Paradigms Fuse
&lt;/h3&gt;

&lt;p&gt;The most significant change in LLM optimization in 2025–2026 is the &lt;strong&gt;rapid crystallization of evaluation infrastructure&lt;/strong&gt;, moving the field from "case demonstrations" to "capability characterization." On the modeling side appeared a large batch of benchmarks and datasets: OptiBench (with the ReSocratic reverse-synthesis data method, ICLR 2025), ORQA measuring OR reasoning (AAAI 2025), CP-Bench for constraint-programming modeling (ECAI 2025), the cross-domain modeling dataset Text2Zinc, and DRoC, a constraint-decomposition retrieval method covering 48 VRPs (ICLR 2025) (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). On the algorithm-discovery side, beyond ALE-Bench, OPT-BENCH, and HeuriGym introduced earlier, AAAI 2026's &lt;strong&gt;CO-Bench&lt;/strong&gt; specifically measures language-model agents' end-to-end ability in combinatorial-optimization algorithm search; on training methods, NeurIPS 2025's &lt;strong&gt;SolverLLM&lt;/strong&gt; uses a training-free improved MCTS (dynamic expansion + prompt backpropagation + uncertainty backpropagation) to search the "modeling-solution space" at inference time, while &lt;strong&gt;Solver-Informed RL&lt;/strong&gt; (NeurIPS 2025) uses solver feedback directly as reinforcement-learning reward to train modeling models, and StepORLM (2025) further introduces generative process supervision for self-evolution (&lt;a href="https://neurips.cc/virtual/2025/poster/116215" rel="noopener noreferrer"&gt;SolverLLM&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2509.22558v2" rel="noopener noreferrer"&gt;StepORLM&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The second change is &lt;strong&gt;fusion among paradigms&lt;/strong&gt;. Beyond the FunSearch lineage, 2025–2026 brought CALM (co-evolution of algorithms and language models, ICLR 2026), ShinkaEvolve (open-ended, sample-efficient program evolution, ICLR 2026), EvoCut (evolution-guided strengthening of cutting planes for integer programming), and FormuEvo (LLM-guided evolution to discover more easily solvable MILP formulations, EMNLP 2026)—extending the object of evolution from "heuristic functions" to cutting planes, model formulations, and multi-objective heuristic portfolios (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). Especially noteworthy is &lt;strong&gt;EALG&lt;/strong&gt;'s adversarial co-evolution: letting the LLM simultaneously evolve "ever-harder problem-instance generators" and "heuristics that solve them," integrating instance generation and solver design into one closed loop and exploring automatic benchmark renewal to avoid overfitting (&lt;a href="https://www.researchgate.net/publication/392371809_EALG_Evolutionary_Adversarial_Generation_of_Language_Model-Guided_Generators_for_Combinatorial_Optimization" rel="noopener noreferrer"&gt;EALG&lt;/a&gt;). The publication of a systematic survey in &lt;em&gt;ACM Computing Surveys&lt;/em&gt; (April 2026) and a dedicated LLM meta-optimizer survey (January 2026) signals that knowledge accumulation in this direction has reached a density requiring secondary synthesis (&lt;a href="https://dl.acm.org/doi/10.1145/3801961" rel="noopener noreferrer"&gt;ACM CSUR 2026&lt;/a&gt;, &lt;a href="https://link.springer.com/article/10.1007/s10462-025-11470-w" rel="noopener noreferrer"&gt;Springer survey 2026&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;For engineering practice, these developments carry three direct implications. First, selection should prefer publicly available results on unified benchmarks such as OptiBench and CO-Bench, and be wary of single-paper claims on self-built datasets. Second, "solver-in-the-loop" has become standard design at both training and inference—SolverLLM and Solver-Informed RL prove from two paths the necessity of constraining LLM outputs with solver feedback. Third, the boundary between LLMs and solvers/evolutionary search is blurring; per Chapter 11's architectural principles, design the LLM layer as a replaceable module so the system can absorb the latest results of this fast-moving layer.&lt;/p&gt;




&lt;h2&gt;
  
  
  7. Paradigm 6: Learning-Based Planning and Control
&lt;/h2&gt;

&lt;h3&gt;
  
  
  7.1 Learning-Augmented MPC and Safety Guarantees
&lt;/h3&gt;

&lt;p&gt;In continuous control, the most mature form of "learning-based planning" is the &lt;strong&gt;fusion of learning with model predictive control (MPC)&lt;/strong&gt;. Hewing et al.'s 2020 review in the &lt;em&gt;Annual Review of Control, Robotics, and Autonomous Systems&lt;/em&gt; laid the framework: use data to learn MPC's dynamics model, cost function, or constraints (e.g., Gaussian processes for residual dynamics) while exploiting MPC's constraint-handling ability to guarantee safety (&lt;a href="https://arxiv.org/pdf/2509.15799" rel="noopener noreferrer"&gt;cited in arXiv 2509.15799&lt;/a&gt;). Reiter et al.'s 2025 &lt;em&gt;Synthesis of Model Predictive Control and Reinforcement Learning&lt;/em&gt; in the &lt;em&gt;IEEE Open Journal of Control Systems&lt;/em&gt; further provides a unified taxonomy of MPC × RL: MPC can serve as RL's function approximator (parameterizing MPC with value functions/policies), and RL can serve as MPC's global approximator (learning value functions to shorten prediction horizons and reduce online computation)—the two routes complement each other in engineering (&lt;a href="https://arxiv.org/pdf/2507.14025" rel="noopener noreferrer"&gt;Reiter et al. 2025&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Safety is the paradigm's central concern. Representative mechanisms include: Koller et al.'s 2018 safe exploration for learning-based MPC (constraining exploration regions with Gaussian-process confidence bounds), Zanon &amp;amp; Gros's robust-MPC-based safe reinforcement learning (&lt;em&gt;IEEE TAC&lt;/em&gt; 2021), and Wabersich &amp;amp; Zeilinger's &lt;strong&gt;predictive safety filter&lt;/strong&gt;—wrapping the learned policy's output in an MPC safety layer that intercepts actions that might cause constraint violations (&lt;a href="https://arxiv.org/pdf/2509.15799" rel="noopener noreferrer"&gt;cited in arXiv 2509.15799&lt;/a&gt;). In engineering practice, this "learned policy + safety filter" sandwich architecture has become the standard pattern for deploying learned policies in robotics and industrial control: 2024 quadrotor wind-disturbance-rejection research used incremental Gaussian processes to learn wind-disturbance models online, embedded in an MPC framework, significantly improving trajectory accuracy in gusty environments (&lt;a href="https://doi.org/10.1145/3687488.3687518" rel="noopener noreferrer"&gt;ACM 2024&lt;/a&gt;); DeepSafeMPC combines deep-learning dynamics predictors with MPC constraint enforcement for multi-agent safe reinforcement learning (&lt;a href="https://arxiv.org/abs/2403.06397" rel="noopener noreferrer"&gt;arXiv 2024&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  7.2 Robot Motion Planning and Task-and-Motion Planning (TAMP)
&lt;/h3&gt;

&lt;p&gt;The learning-ization of robot motion planning has two main threads. The first is &lt;strong&gt;using learning to accelerate or replace sampling/optimization planners&lt;/strong&gt;: from early neural motion planning (RL achieving faster planning than sampling planners on new environments) through CoMPNetX (conditional generative networks + neural projection operators generating constraint-satisfying configurations) to 2024's &lt;strong&gt;Neural MP&lt;/strong&gt;—a large-scale neural motion planner aimed at generalization, targeting single-model cross-scenario planning (&lt;a href="https://dl.acm.org/doi/10.1145/3583136" rel="noopener noreferrer"&gt;ACM TAMP trends&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2608.24026v1" rel="noopener noreferrer"&gt;cited in NeurRAFT&lt;/a&gt;). The second is &lt;strong&gt;diffusion-model planning&lt;/strong&gt;: Motion Planning Diffusion (&lt;em&gt;IEEE T-RO&lt;/em&gt; 2025) models trajectory generation as a diffusion process with test-time cost guidance; EDMP guides diffusion with cost ensembles; DiffusionSeeder (CoRL 2025) uses diffusion models to generate high-quality initial solutions (warm starts) for optimization-based planners; and 2026's NeurRAFT further introduces flow matching and gap-aware preference fine-tuning (&lt;a href="https://arxiv.org/html/2608.24026v1" rel="noopener noreferrer"&gt;NeurRAFT&lt;/a&gt;). The diffusion route's engineering appeal: after one training run, planning becomes a few denoising forward passes, and multimodal solution distributions naturally fit the interaction scenario of "offering operators multiple candidate trajectories."&lt;/p&gt;

&lt;p&gt;At the higher level of task-and-motion planning (TAMP), learning's role is to guide the coupling of symbolic and geometric planning: learning importance distributions for sampling, learning feasibility classifiers to replace expensive motion-feasibility checks, learning low-level transition models for operators, and even using video world models in place of analytical simulators for zero-shot planning (&lt;a href="https://prpl-group.com/tamp-learning-survey.pdf" rel="noopener noreferrer"&gt;TAMP learning survey&lt;/a&gt;). These component-level learning methods share Chapter 3's hybrid philosophy: the symbolic planner guarantees logical correctness; learned modules provide acceleration and generalization.&lt;/p&gt;

&lt;h3&gt;
  
  
  7.3 End-to-End Autonomous Driving Planning
&lt;/h3&gt;

&lt;p&gt;Autonomous driving is the most industrially invested area of learning-based planning. In 2023, &lt;strong&gt;UniAD&lt;/strong&gt; (CVPR 2023 Best Paper) integrated perception, prediction, and planning into a single network with a "planning-oriented" unified framework, eliminating error accumulation from module cascades and opening the end-to-end paradigm; the &lt;strong&gt;VAD&lt;/strong&gt; series improved efficiency with vectorized scene representations, and VADv2 introduced probabilistic planning over 8,192 anchor trajectories to handle multimodality; in 2024–2025 diffusion policies entered the planning module (DiffusionDrive generates diverse trajectory proposals on anchor trajectories with truncated denoising), the world-model route (WoTE uses a BEV world model for online trajectory evaluation and selection) and the VLM/LLM-augmented route (DriveVLM, EMMA, etc., using language models' world knowledge for long-tail scenarios) advanced in parallel (&lt;a href="https://arxiv.org/html/2605.10564v1" rel="noopener noreferrer"&gt;DeepSight related work&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2603.14851v3" rel="noopener noreferrer"&gt;AutoMoT related work&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The core shortcoming of end-to-end methods lies in imitation learning's inherent flaw: the training objective is reproducing expert trajectories rather than optimizing driving performance, leading to insufficient generalization and interpretability in long-tail closed-loop scenarios (&lt;a href="https://arxiv.org/html/2605.10564v1" rel="noopener noreferrer"&gt;DeepSight&lt;/a&gt;). A clear trend since 2025 is &lt;strong&gt;using reinforcement learning to complement imitation learning&lt;/strong&gt;—the READ framework, for example, uses RL on top of a diffusion planner to explicitly optimize driving-performance metrics, unlocking the full potential of multimodal action spaces; NeurIPS 2024's closed-loop evaluation benchmark (an end-to-end driving benchmark augmented with world-model RL experts) provides a standardized arena for such research (&lt;a href="https://openreview.net/pdf?id=UOYkiemcUP" rel="noopener noreferrer"&gt;READ, OpenReview&lt;/a&gt;, &lt;a href="https://github.com/orgs/Thinklab-SJTU/repositories" rel="noopener noreferrer"&gt;Thinklab repositories&lt;/a&gt;). The engineering conclusion: autonomous-driving planning stacks are converging to a composite architecture of "imitation learning as the base + diffusion/anchor representations for multimodality + RL fine-tuning + a rule-based safety layer as backstop," highly isomorphic to robotics' "learning + safety filter" pattern.&lt;/p&gt;

&lt;h3&gt;
  
  
  7.4 LLM Embodied Task Planning
&lt;/h3&gt;

&lt;p&gt;What LLMs bring to robotics is not low-level control but &lt;strong&gt;commonsense-driven task-level planning&lt;/strong&gt;. &lt;strong&gt;SayCan&lt;/strong&gt; (Google, 2022) is the foundational work: the LLM scores candidate skills for semantic relevance; each skill's learned value function (affordance) evaluates executability in the current state; their product selects the next action—achieving &lt;strong&gt;84% planning success and 74% execution success&lt;/strong&gt; across 101 real kitchen tasks (Figure 3a), with performance automatically improving as the underlying language model is upgraded (&lt;a href="https://say-can.github.io/" rel="noopener noreferrer"&gt;SayCan website&lt;/a&gt;). &lt;strong&gt;Code as Policies&lt;/strong&gt; (Google, 2022) has the LLM directly generate executable robot policy code, exploiting code's loops, conditionals, and library calls to express complex logic; &lt;strong&gt;Voyager&lt;/strong&gt; (2023) demonstrated a lifelong-learning agent paradigm of "automatic curriculum + skill library + iterative prompting" in Minecraft; Inner Monologue, SayPlan, LLM+P and others explored environment-feedback loops, 3D scene-graph planning, and the neuro-symbolic combination of "LLM translation + classical planner solving" respectively (&lt;a href="https://arxiv.org/html/2608.16806v1" rel="noopener noreferrer"&gt;embodied-agent attack-surface survey&lt;/a&gt;, &lt;a href="https://arxiv.org/pdf/2310.10645" rel="noopener noreferrer"&gt;ITP paper&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkdktc3eh3q5ajp7780p0.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fkdktc3eh3q5ajp7780p0.png" alt=" " width="799" height="323"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Figure 3. (a) SayCan planning/execution success rates by task family in mock and real kitchens (data: Ahn et al. 2022, 101 tasks in total); (b) summary of quantified gains from representative industrial deployments (sources cited throughout Chapter 9)&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Figure 3a reveals a law vital to engineering deployment: &lt;strong&gt;there is a systematic gap between planning success and execution success&lt;/strong&gt;, and noun-based instructions (involving object reference) and embodied-reasoning tasks have significantly higher failure rates—SayCan's error analysis attributes roughly 65% of errors to the LLM side and 35% to the affordance-evaluation side (&lt;a href="https://say-can.github.io/assets/palm_saycan.pdf" rel="noopener noreferrer"&gt;SayCan paper&lt;/a&gt;). This means that when deploying LLM task planning, the bottleneck often lies not in the language model itself but in skill-library coverage and the calibration quality of affordance models; behavior-tree execution shells, failure-retry mechanisms, and decision audit logs are mandatory components of production systems.&lt;/p&gt;

&lt;h3&gt;
  
  
  7.5 Frontier Progress (2024–2026): VLA Robot Foundation Models and Large Driving Models
&lt;/h3&gt;

&lt;p&gt;Between 2024 and 2026, robot learning completed a paradigm leap from "task-specific policies" to &lt;strong&gt;vision–language–action (VLA) foundation models&lt;/strong&gt;—essentially the sinking and fusion of §7.4's LLM task planning into low-level control. Physical Intelligence's &lt;strong&gt;π0&lt;/strong&gt; (2024) established the mainstream architecture: a pre-trained VLM (PaliGemma 3B) as the backbone inherits internet-scale semantic understanding, while an attached "action expert" module generates continuous action sequences via &lt;strong&gt;flow matching&lt;/strong&gt;, achieving unprecedented completion on long-horizon dexterous tasks requiring 5–20 minutes of continuous execution (laundry folding, table bussing), with pre-training roughly doubling fine-tuning efficiency for new tasks versus training from scratch (&lt;a href="https://arxiv.org/abs/2410.24164" rel="noopener noreferrer"&gt;π0&lt;/a&gt;). &lt;strong&gt;π0.5&lt;/strong&gt; (April 2025) further achieved open-world generalization—performing mobile manipulation in entirely unseen home environments (&lt;a href="https://arxiv.org/html/2509.23121v1" rel="noopener noreferrer"&gt;VLA industrial-transfer survey&lt;/a&gt;). NVIDIA's &lt;strong&gt;GR00T N1&lt;/strong&gt; (March 2025) takes a "dual-system" route: a vision–language module (System 2) handles environment understanding and instruction parsing, while a diffusion Transformer module (System 1) generates fluid actions in real time; the two modules are trained end-to-end jointly on a heterogeneous mixture of real robot trajectories, human videos, and synthetic data, and the system has been deployed on the Fourier GR-1 humanoid for language-conditioned bimanual manipulation (&lt;a href="https://arxiv.org/abs/2503.14734" rel="noopener noreferrer"&gt;GR00T N1&lt;/a&gt;). Google's Gemini Robotics (2025) and the open-source ecosystem's OpenVLA, Octo, RDT-1B and others complete the spectrum of this direction (&lt;a href="https://github.com/DefaultRui/vision-language-action-models-for-embodied-AI" rel="noopener noreferrer"&gt;VLA model genealogy list&lt;/a&gt;). The table below summarizes the architectural divides among mainstream VLA / robot foundation models:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Model&lt;/th&gt;
&lt;th&gt;Organization, year&lt;/th&gt;
&lt;th&gt;Architectural highlights&lt;/th&gt;
&lt;th&gt;Open source&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;RT-2&lt;/td&gt;
&lt;td&gt;Google DeepMind, 2023&lt;/td&gt;
&lt;td&gt;VLM co-fine-tuning; actions discretized as tokens&lt;/td&gt;
&lt;td&gt;No&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Octo&lt;/td&gt;
&lt;td&gt;Multi-university, 2024&lt;/td&gt;
&lt;td&gt;Open generalist robot policy; Transformer diffusion head&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;OpenVLA&lt;/td&gt;
&lt;td&gt;Stanford et al., 2024&lt;/td&gt;
&lt;td&gt;7B open VLA built on Llama 2 + vision encoder&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;RDT-1B&lt;/td&gt;
&lt;td&gt;Tsinghua, 2024&lt;/td&gt;
&lt;td&gt;Bimanual-manipulation diffusion foundation model&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;π0 / π0.5&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;Physical Intelligence, 2024/2025&lt;/td&gt;
&lt;td&gt;VLM backbone + flow-matching action expert; open-world generalization&lt;/td&gt;
&lt;td&gt;Partial&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;GR00T N1&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;NVIDIA, 2025&lt;/td&gt;
&lt;td&gt;Dual system: VLM slow thinking + diffusion Transformer fast reflexes&lt;/td&gt;
&lt;td&gt;Yes&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Gemini Robotics&lt;/td&gt;
&lt;td&gt;Google DeepMind, 2025&lt;/td&gt;
&lt;td&gt;Gemini's multimodal capability extended to the physical world&lt;/td&gt;
&lt;td&gt;No&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;(Sources: &lt;a href="https://github.com/DefaultRui/vision-language-action-models-for-embodied-AI" rel="noopener noreferrer"&gt;VLA genealogy list&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2509.23121v1" rel="noopener noreferrer"&gt;VLA industrial-transfer survey&lt;/a&gt;)&lt;/p&gt;

&lt;p&gt;On the autonomous-driving side, the 2024–2026 main line is the end-to-end paradigm moving from research consensus to &lt;strong&gt;commercial deployment and architectural upgrades&lt;/strong&gt;. A 2026 industry survey systematically records the transition from modular rule-based pipelines to "large driving models" (LDM): Tesla FSD switched to true end-to-end operation from V12, with V13/V14 adding audio-based environment perception and multi-second temporal reasoning; in June 2025, Waymo and Tesla simultaneously launched commercial robotaxi services in Austin—a head-on collision between the "multi-sensor redundancy" and "pure-vision end-to-end" routes; in early 2026 NVIDIA released an urban autonomous-driving development ecosystem spanning world foundation models, large-scale evaluation datasets, and open-source driving agents (&lt;a href="https://arxiv.org/html/2603.16050v1" rel="noopener noreferrer"&gt;LDM industry survey&lt;/a&gt;). On the academic frontier, NeurIPS 2025's &lt;strong&gt;AutoVLA&lt;/strong&gt; brings VLA architecture and test-time compute into driving planning: through chain-of-thought reasoning and physical-action tokenization it directly generates planned trajectories in a unified autoregressive process, and with GRPO reinforcement fine-tuning achieves a 10.6% PDMS improvement on NAVSIM while cutting runtime overhead by 66.8%, scoring highest on the hardest scenario dimension (RFS Spotlight) of the Waymo vision-based end-to-end challenge (&lt;a href="https://github.com/ucla-mobility/AutoVLA" rel="noopener noreferrer"&gt;AutoVLA&lt;/a&gt;, &lt;a href="https://autovla.github.io/" rel="noopener noreferrer"&gt;AutoVLA project page&lt;/a&gt;). This "VLA + reinforcement fine-tuning" combination is highly isomorphic to robotics' evolution, corroborating Chapter 13's judgment that "the six paradigms are converging."&lt;/p&gt;




&lt;h2&gt;
  
  
  8. Scheduling and Manufacturing: The Practical Landscape of Deep-Learning Scheduling
&lt;/h2&gt;

&lt;h3&gt;
  
  
  8.1 From L2D to the GNN+DRL Standard Paradigm
&lt;/h3&gt;

&lt;p&gt;Job-shop scheduling (JSP) and its flexible variant (FJSP) are the most industrialized learning battleground in combinatorial optimization. The foundational work is NeurIPS 2020's &lt;strong&gt;L2D (Learning to Dispatch)&lt;/strong&gt;: modeling JSP as a Markov decision process on disjunctive graphs, extracting state embeddings with GNNs and training dispatching policies with PPO, it demonstrated that "learned dispatching rules can generalize to larger instances and beat classical dispatching rules" (&lt;a href="https://link.springer.com/article/10.1007/s10462-024-11059-9" rel="noopener noreferrer"&gt;GNN+DRL scheduling survey&lt;/a&gt;). Over the following five years the direction settled into a stable technical stack: states represented as disjunctive/heterogeneous graphs, actions as machine–job pair selections, algorithms dominated by PPO/MAPPO, and rewards mostly incremental forms of makespan. Multiple 2024–2025 surveys systematically map this landscape: graph representations evolved from single disjunctive graphs to heterogeneous graphs containing machine and job nodes (HGIN); training evolved from single-agent PPO to multi-agent MAPPO; objectives expanded from makespan alone to multiple objectives including energy consumption and tardiness (&lt;a href="https://link.springer.com/article/10.1007/s10462-024-11059-9" rel="noopener noreferrer"&gt;Springer survey 2024&lt;/a&gt;, &lt;a href="https://www.sciencedirect.com/science/article/abs/pii/S0950705125006793" rel="noopener noreferrer"&gt;KBS survey 2025&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2406.14096v3" rel="noopener noreferrer"&gt;arXiv 2406.14096&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Notably, most engineering improvements in this area come from training strategies rather than network architectures: &lt;strong&gt;curriculum learning&lt;/strong&gt; (RASCL, training on easy instances first and gradually increasing difficulty), &lt;strong&gt;end-to-end multi-agent&lt;/strong&gt; approaches (E2E-MAPPO uses a shared attention policy network to jointly learn job sequencing and machine assignment for flexible job shops, with a complete open-source implementation), and &lt;strong&gt;sim-to-real transfer&lt;/strong&gt; (training in digital-twin simulators, deploying to real MES systems) are the three most frequently cited boosters (&lt;a href="https://github.com/RKWin93/E2E-MAPPO-for-MT-FJSP" rel="noopener noreferrer"&gt;E2E-MAPPO&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2406.14096v3" rel="noopener noreferrer"&gt;arXiv 2406.14096&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  8.2 Adoption Status and a Sober Assessment
&lt;/h3&gt;

&lt;p&gt;Scheduling is one of the areas where the gap between "learned optimization" hype and reality most needs honest assessment. On one hand, learned dispatching policies do outperform any single hand-designed rule (SPT, MWKR, etc.) on specific distributions, and with millisecond-level inference they suit dynamic rescheduling scenarios; on the other hand, multiple surveys and benchmark studies point out that when instance distributions shift or constraint types exceed the training set (new bottleneck machines, batching constraints, setup times), learned policies degrade noticeably, while mature metaheuristics (genetic algorithms, tabu search) and constraint-programming solvers often produce more robust solutions within the same time budget (&lt;a href="https://www.sciencedirect.com/science/article/abs/pii/S0950705125006793" rel="noopener noreferrer"&gt;KBS survey 2025&lt;/a&gt;). This is consistent with Chapter 2.3's overall critique of end-to-end NCO and is a scheduling-domain replay of the phenomenon confirmed by RL4CO's unified evaluation.&lt;/p&gt;

&lt;p&gt;The pragmatic engineering conclusion: learned scheduling fits two scenarios best—&lt;strong&gt;high-frequency dynamic rescheduling&lt;/strong&gt; (second-level re-planning after rush orders or equipment failures) and &lt;strong&gt;very-large-scale instances&lt;/strong&gt; (thousands of jobs, where metaheuristics' time budget falls short); for medium-to-large-scale scheduling with stable constraints and minute-level solving-time allowances, OR-Tools CP-SAT and professional APS software remain the safer default. Hybrid strategies—learned policies generate initial solutions/dispatch sequences, then local search or CP solvers refine them—have proven in multiple industrial papers to be the route with the best risk–return ratio (&lt;a href="https://link.springer.com/article/10.1007/s10462-024-11059-9" rel="noopener noreferrer"&gt;Springer survey 2024&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  8.3 Frontier Progress (2024–2026): LLMs Enter Shop-Floor Scheduling
&lt;/h3&gt;

&lt;p&gt;Since 2024, scheduling has gained a second technical line beyond "GNN+DRL"—&lt;strong&gt;LLMs directly participating in scheduling decisions&lt;/strong&gt;. Early path-finding work &lt;em&gt;LLMs can Schedule&lt;/em&gt; (2024) probed the capability boundary of LLM end-to-end JSP solving; the work that truly demonstrates practical potential is &lt;strong&gt;ReflecSched&lt;/strong&gt; (2025): instead of letting the LLM schedule directly, it has the LLM analyze multi-planning-horizon simulation results driven by heuristic rules, distill natural-language "strategic experience," and use that experience to guide the final decision module—thereby solving dynamic flexible job-shop scheduling (DFJSP) zero-shot, achieving a &lt;strong&gt;71.35% win rate&lt;/strong&gt; over direct LLM use, reducing RPD by 2.755%, and surpassing every single heuristic rule evaluated (&lt;a href="https://arxiv.org/html/2508.01724v1" rel="noopener noreferrer"&gt;ReflecSched&lt;/a&gt;). The paper's diagnosis is equally valuable: baseline LLMs scheduling directly suffer three traps—the "long-context paradox" (key data diluted), underuse of expert heuristics, and myopic decisions—which precisely explains why the layered architecture of "LLM does strategic analysis; rules/algorithms do tactical execution" is currently the most effective form.&lt;/p&gt;

&lt;p&gt;Multi-agent architectures are another active thread. The &lt;strong&gt;MASC&lt;/strong&gt; framework (published 2025 in &lt;em&gt;Advanced Engineering Informatics&lt;/em&gt;) builds a four-agent collaboration chain—ObsAgent (observation), SchedAgent (scheduling), PlanAgent (planning), CtrlAgent (control)—where SchedAgent, based on an improved ReAct method, dynamically selects scheduling algorithms from an algorithm library according to indicators such as job-time dispersion and available machine counts, and the LLM is fine-tuned with the DialBag dialogue-distillation method to retain domain knowledge; the system has been validated on both simulation and real robotic-arm platforms (&lt;a href="https://www.sciencedirect.com/science/article/abs/pii/S1474034625004203" rel="noopener noreferrer"&gt;MASC&lt;/a&gt;). Fusion directions also include: LUCA, which fuses GNNs, LLM semantic understanding, and DRL policy networks for the first carbon-aware FJSP scheduling with dual objectives of carbon emissions and makespan; Gu et al., who use pre-trained LLMs to coordinate multi-agent DRL across production stages of hybrid flow shops; and 2026's DSevolve, which uses LLMs to evolve &lt;strong&gt;heuristic portfolios&lt;/strong&gt; for real-time adaptive DFJSP scheduling (&lt;a href="https://arxiv.org/html/2608.07148v1" rel="noopener noreferrer"&gt;MARL×LLM smart-manufacturing reference-architecture survey&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2603.27628v2" rel="noopener noreferrer"&gt;DSevolve&lt;/a&gt;). The 2026 smart-manufacturing MARL×LLM reference-architecture survey organizes these works into four LLM roles—state/knowledge augmentation, decision guidance, reflection analysis, and cross-stage coordination—which can serve as a classification framework for scheduling teams' selection decisions.&lt;/p&gt;

&lt;p&gt;A sober assessment remains necessary: LLM scheduling today mostly stays at the benchmark and prototype-validation stage; inference latency and hallucination risk make it unsuitable for millisecond online-rescheduling loops; its relationship with §8.1's GNN+DRL route is closer to "complementary layering" than replacement—LLMs handle semantic understanding, anomaly explanation, and policy selection, while numerical policy networks handle high-frequency execution. The pragmatic advice for manufacturers: on top of existing APS/MES, first let LLM agents take on low-risk auxiliary functions such as "schedule explanation, rush-order impact analysis, and rule-parameter recommendation" (corresponding to upstream positions in Chapter 11's decision-chain framework), then evaluate introducing DRL policy networks as data accumulates.&lt;/p&gt;




&lt;h2&gt;
  
  
  9. Industrial Adoption Panorama: A Global Practice Map
&lt;/h2&gt;

&lt;h3&gt;
  
  
  9.1 Overview: From "Point Demonstrations" to "Global Rollout"
&lt;/h3&gt;

&lt;p&gt;Industrial adoption of learning-based optimization and planning has crossed both geographic and industry boundaries. Building on the landmark cases, this chapter systematically maps global practice by industry: North America's tech giants and parcel carriers (Google, Amazon, UPS, Tesla), Europe's power grids and transport (France's RTE, the UK's Ocado), Japan and Korea's process industries and robotics (Yokogawa, ENEOS, Panasonic-owned Blue Yonder), Middle Eastern energy facilities (Saudi Aramco's Fadhili gas plant), and China's mobility, delivery, and urban governance (DiDi, Alibaba City Brain, Huawei). Figure 3b summarizes early landmark gains; Figure 4 further presents the expanded global panorama of quantified gains—spanning relative improvements on the order of percentage points to absolute economic gains on the order of hundreds of millions of dollars.&lt;/p&gt;

&lt;p&gt;Two methodological caveats apply when reading this chapter's numbers. First, &lt;strong&gt;evidence grades differ&lt;/strong&gt;: DeepMind cooling and SayCan success rates are backed by peer-reviewed papers, UPS ORION's benefits are documented in INFORMS literature, while figures from vendor press releases (such as EDA tools' PPA improvements) are self-reported and should be discounted accordingly; citations in this chapter note source nature wherever possible. Second, &lt;strong&gt;cross-case horizontal patterns matter more than any single number&lt;/strong&gt;: virtually every successful scaled deployment adopts a conservative hybrid architecture of "learned model + classical solver/safety layer/rule constraints," and not a single case lets a learned component control a production system without constraints or fallbacks—this architectural fingerprint is this chapter's most important conclusion and mutually corroborates the technical analyses of Chapters 3 and 7.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftixhmljx7wgc1zhhh5n0.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftixhmljx7wgc1zhhh5n0.png" alt=" " width="800" height="376"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Figure 4. Quantified gains from representative global industrial deployments. (a) Relative improvements (ranges plotted at midpoints, e.g., Yokogawa × Aramco at the midpoint of 10–15%); (b) absolute economic gains (different bases: UPS is annual savings, Tesla Autobidder is cumulative trading profit, WFP is cumulative program savings). Data sources are cited throughout this chapter&lt;/strong&gt;&lt;/p&gt;

&lt;h3&gt;
  
  
  9.2 Semiconductors and EDA: The Most Commercialized Battleground for Learning Optimization
&lt;/h3&gt;

&lt;p&gt;Electronic design automation (EDA) is—without rival—the most commercialized domain of learning-based optimization. Synopsys's &lt;strong&gt;DSO.ai&lt;/strong&gt;, released in 2020, was the industry's first autonomous chip-design AI application, using reinforcement learning to automatically explore process-parameter combinations in the vast design spaces of Fusion Compiler and IC Compiler II; per company disclosures, users have achieved double-digit-percentage PPA (power, performance, area) improvements on real production designs with substantially shortened design cycles, and industry media report cumulative production tape-outs in the hundreds (&lt;a href="https://www.ad-hoc-news.de/boerse/news/ueberblick/flagship-twist-for-synopsys-dso-ai-anchors-the-ai-driven-chip-design-push/69544982" rel="noopener noreferrer"&gt;ad-hoc-news&lt;/a&gt;, &lt;a href="https://bitsilica.com/ai-in-real-world-chip-design-workflows-a-technical-overview/" rel="noopener noreferrer"&gt;bitsilica technical overview&lt;/a&gt;). Competitor &lt;strong&gt;Cadence Cerebrus&lt;/strong&gt;'s full-flow RL engine has likewise accumulated a dense set of production cases: Samsung Semiconductor India Research (SSIR) achieved 8–11% PPA improvement on SoC subsystems, and Samsung's Austin R&amp;amp;D Center (SARC) saw a 4× productivity gain (&lt;a href="https://community.cadence.com/cadence_blogs_8/b/di/posts/transforming-chip-design-with-cadence-cerebrus-ai-studio" rel="noopener noreferrer"&gt;Cadence community blog&lt;/a&gt;); Phison Electronics automatically reduced power by &lt;strong&gt;35%&lt;/strong&gt; and shrank area by 3% on a 12nm NAND controller within one week (&lt;a href="https://www.design-reuse.com/news/15490-phison-deploys-cadence-cerebrus-ai-driven-chip-optimization-to-accelerate-product-development/" rel="noopener noreferrer"&gt;design-reuse&lt;/a&gt;); Himax reported up to 30× single-design productivity improvement and 70% fewer DRC violations (&lt;a href="https://community.cadence.com/cadence_blogs_8/b/di/posts/himax-accelerates-chip-design-with-cadence-cerebrus-intelligent-chip-explorer" rel="noopener noreferrer"&gt;Cadence community blog&lt;/a&gt;); and after its floor-plan optimization shrank chip area by 5% and cut power by over 6%, MediaTek moved Cerebrus into full production flows (&lt;a href="https://iconnect007.com/article/132323/cadence-cerebrus-delivers-transformative-results-on-nextgen-designs/132326/ein" rel="noopener noreferrer"&gt;iconnect007&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Why EDA became the perfect battleground for learning optimization is worth borrowing by every industry: &lt;strong&gt;the evaluator is programmatic and authoritative&lt;/strong&gt; (timing/power analysis from sign-off tools is ground truth, requiring no human labeling); &lt;strong&gt;trial-and-error costs nothing&lt;/strong&gt; (a failed exploration is just one simulation, and rollback is free); &lt;strong&gt;data generates itself&lt;/strong&gt; (RL agents explore the design space and produce their own training data, without relying on historical accumulation). Google's AlphaChip (used in mass production of multiple TPU generations and open-sourced) and NVIDIA ChipNeMo (a domain LLM generating Verilog and EDA scripts) represent the two complementary routes of RL placement and LLM-assisted design respectively (&lt;a href="https://internet-pros.com/blog/ai-chip-design-eda-automation-synopsys-cadence-2026/" rel="noopener noreferrer"&gt;internet-pros industry overview&lt;/a&gt;). Architecturally they share the same fingerprint: the learning engine handles large-scale search and proposals; deterministic sign-off tools handle final verification—exactly the hybrid philosophy of Chapter 3.&lt;/p&gt;

&lt;h3&gt;
  
  
  9.3 Energy and Power: From Data Centers and Power Markets to Oil &amp;amp; Gas Plants
&lt;/h3&gt;

&lt;p&gt;The energy sector contributes both the earliest and the latest milestones of learning optimization. The earliest is the DeepMind data-center cooling case detailed earlier (2016); the newest heavyweight player is &lt;strong&gt;Tesla Autobidder&lt;/strong&gt;: its machine-learning engine Opticaster predicts electricity prices, load, and generation output, and automatically executes power-market bidding and battery charge/discharge scheduling; per Tesla job postings, the platform manages over &lt;strong&gt;7 GWh&lt;/strong&gt; of storage assets worldwide and has generated over &lt;strong&gt;$420 million&lt;/strong&gt; in cumulative trading profit (&lt;a href="https://talents.vaia.com/companies/tesla-motors-inc/staff-quantitative-energy-trading-meteorologist-autobidder-33533481/" rel="noopener noreferrer"&gt;Tesla job posting&lt;/a&gt;); benchmark projects such as Australia's Hornsdale Power Reserve report double-digit ROI improvements (&lt;a href="https://www.linkedin.com/pulse/tesla-autobidder-ai-powerhouse-thats-reshaping-energy-swapnil-amin-hzxoc" rel="noopener noreferrer"&gt;LinkedIn industry analysis&lt;/a&gt;). On the grid side, French transmission operator RTE's &lt;strong&gt;L2RPN (Learning to Run a Power Network)&lt;/strong&gt; competition series (running since 2019) and its open-source simulator Grid2Op turned grid topology control into an "ImageNet moment" for RL—the standardized benchmark has drawn the global research community into competing to improve line-overload remediation agents, with 2025 frontier work covering multi-objective RL, multi-agent zonal coordination, and graph-augmented agents (&lt;a href="https://howtostoreelectricity.com/ai-grid-congestion-management-redispatch/" rel="noopener noreferrer"&gt;howtostoreelectricity&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Autonomous control in process industries is the most underrated breakthrough of 2022–2025. The FKDPP reinforcement-learning algorithm, co-developed by &lt;strong&gt;Yokogawa&lt;/strong&gt; and the Nara Institute of Science and Technology, achieved 35 consecutive days of AI-autonomous operation on a butadiene distillation column at &lt;strong&gt;ENEOS&lt;/strong&gt;'s Yokkaichi plant in 2022—stably producing on-spec product, eliminating off-spec batches, and reducing steam consumption by &lt;strong&gt;40%&lt;/strong&gt;—before formally transitioning to normal production operation in 2023, which the vendor claims as the world's first AI-autonomous control of a chemical plant (&lt;a href="https://www.cbinsights.com/company/arc-advisory-group" rel="noopener noreferrer"&gt;ARC Advisory case record&lt;/a&gt;). In October 2025, Yokogawa and &lt;strong&gt;Saudi Aramco&lt;/strong&gt; commissioned multiple coordinated FKDPP autonomous-control agents at the Fadhili gas plant, directly controlling the acid gas removal (AGR) unit; preliminary results show &lt;strong&gt;10–15%&lt;/strong&gt; lower amine and steam consumption, about &lt;strong&gt;5%&lt;/strong&gt; lower electricity use, and significantly reduced manual intervention; deployment strictly followed a three-stage path of "simulator training → reliability verification → integration with the safety functions of the CENTUM VP control system" (&lt;a href="https://www.yokogawa.com/vn/news/press-releases/2025/2025-10-29/" rel="noopener noreferrer"&gt;Yokogawa official press release&lt;/a&gt;, &lt;a href="https://www.businesswire.com/news/home/20251028792329/en/" rel="noopener noreferrer"&gt;Business Wire&lt;/a&gt;). US-based Imubit and others have also launched RL closed-loop optimization products for process industries (&lt;a href="https://noga.es/en/blog/nn-controllers-real-industrial-deployments/" rel="noopener noreferrer"&gt;survey of industrial NN-control deployments&lt;/a&gt;). These cases are direct realizations of §7.1's "learned policy + safety layer" architecture in process industries; their staged deployment paths are elaborated in §11.3.&lt;/p&gt;

&lt;h3&gt;
  
  
  9.4 Logistics, Parcel, and Warehouse Robotics: The Largest-Scale Online Optimization Systems
&lt;/h3&gt;

&lt;p&gt;The parcel-transport benchmark is &lt;strong&gt;UPS ORION&lt;/strong&gt; (On-Road Integrated Optimization and Navigation): deployed starting 2012 and fully completed in 2022, the system generates optimized routes daily for more than 55,000 US drivers, eliminating about &lt;strong&gt;100 million miles&lt;/strong&gt; of driving per year, saving &lt;strong&gt;10 million gallons&lt;/strong&gt; of fuel, cutting roughly &lt;strong&gt;100,000 tonnes&lt;/strong&gt; of CO₂ emissions, and delivering estimated annual economic benefits of &lt;strong&gt;$300–400 million&lt;/strong&gt; (&lt;a href="https://arxiv.org/html/2604.25847v1" rel="noopener noreferrer"&gt;arXiv 2604.25847 citing INFORMS literature&lt;/a&gt;, &lt;a href="https://www.articsledge.com/post/ai-automation-success-stories" rel="noopener noreferrer"&gt;Articsledge case roundup&lt;/a&gt;); the 2020 Dynamic ORION upgrade added real-time intra-shift rerouting, saving another 2–4 miles per driver per day on top of existing gains (&lt;a href="https://nextbillion.ai/feeds/blog/ups-orion-ai-route-optimization-savings" rel="noopener noreferrer"&gt;NextBillion.ai technical analysis&lt;/a&gt;). ORION's technical essence is a textbook hybrid of "OR engine + ML prediction layer"—deterministic optimization handles hard constraints such as time windows and working hours, while ML supplies predictive inputs for traffic, weather, and delivery patterns. FedEx (SenseAware cutting spoilage of temperature-controlled goods by up to 40%; AI rerouting reducing delays by 25% on average) and DHL (AI delay prediction cutting freight delays by up to 30%) demonstrate the same paradigm spreading across the industry (&lt;a href="https://aibusinessweekly.net/p/ai-supply-chain-statistics" rel="noopener noreferrer"&gt;AI Business Weekly&lt;/a&gt;, &lt;a href="https://www.apptunix.com/blog/ai-in-logistics-benefits-use-cases-challenges/" rel="noopener noreferrer"&gt;Apptunix&lt;/a&gt;). The public sector benefits too: the UN World Food Programme (WFP) used analytics and optimization to restructure its humanitarian supply chain during COVID-19, saving over &lt;strong&gt;$150 million&lt;/strong&gt; while serving about 100 million people across 80+ countries (&lt;a href="https://arxiv.org/html/2604.25847v1" rel="noopener noreferrer"&gt;arXiv 2604.25847 citing Peters et al. 2022&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;In warehouse robotics, &lt;strong&gt;Amazon&lt;/strong&gt; deployed its 1-millionth warehouse robot in 2025 and released &lt;strong&gt;DeepFleet&lt;/strong&gt;—the first foundation model for multi-robot coordination: using a Transformer architecture to predict interactions and congestion evolution among robots on fulfillment-center floors, it guides task assignment and path rerouting, improving robot-fleet travel efficiency by &lt;strong&gt;10%&lt;/strong&gt; (&lt;a href="https://www.amazon.science/blog/amazon-builds-first-foundation-model-for-multirobot-coordination" rel="noopener noreferrer"&gt;Amazon Science&lt;/a&gt;). This is the first time the foundation-model paradigm (Chapter 13's FM4CO trend) has entered ultra-large-scale industrial logistics. The UK's &lt;strong&gt;Ocado&lt;/strong&gt; uses swarm intelligence to coordinate thousands of robots for high-speed order fulfillment in its automated warehouses, embedding machine learning directly into robots' self-diagnosis and anomaly recovery (&lt;a href="https://encord.com/blog/ai-and-robotics/" rel="noopener noreferrer"&gt;Encord&lt;/a&gt;, &lt;a href="https://cloudfresh.com/en/blog/ocado-significant-results-thanks-to-big-data/" rel="noopener noreferrer"&gt;Cloudfresh&lt;/a&gt;). A capital-market signal is also worth noting: &lt;strong&gt;InstaDeep&lt;/strong&gt;, which specializes in RL decision optimization (products covering container-loading optimization DeepPack, railway scheduling, PCB routing, and more, with customers including Deutsche Bahn), was acquired by BioNTech in 2023 for &lt;strong&gt;€636 million&lt;/strong&gt;—evidence that "RL solving industrial combinatorial optimization" has itself become a validated business model (&lt;a href="https://startupintros.com/orgs/instadeep" rel="noopener noreferrer"&gt;StartupIntros&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  9.5 Urban Traffic Signals and Mobility Platforms
&lt;/h3&gt;

&lt;p&gt;Urban traffic-signal control is the most successful domain of public-sector learning-optimization adoption. CMU's &lt;strong&gt;Surtrac&lt;/strong&gt; (Scalable Urban Traffic Control) was piloted in 2012 at nine intersections in Pittsburgh's East Liberty district: each intersection runs a local "schedule-driven" real-time optimization algorithm, recomputing signal timing at 1Hz and exchanging traffic-flow predictions with neighboring intersections; measured results included &lt;strong&gt;25%&lt;/strong&gt; lower travel times, over &lt;strong&gt;40%&lt;/strong&gt; lower waiting times, &lt;strong&gt;31%&lt;/strong&gt; fewer stops, and about &lt;strong&gt;21%&lt;/strong&gt; lower emissions; the system later expanded to more than 50 intersections and was commercialized to multiple US cities including Atlanta via Rapid Flow Technologies (later acquired by Miovision) (&lt;a href="https://publications.ri.cmu.edu/storage/publications/pub_files/2013/1/13-0315.pdf" rel="noopener noreferrer"&gt;CMU technical paper&lt;/a&gt;, &lt;a href="https://ojs.aaai.org/index.php/ICAPS/article/download/13594/13443" rel="noopener noreferrer"&gt;ICAPS application report&lt;/a&gt;). &lt;strong&gt;Google Green Light&lt;/strong&gt; takes an asset-light route: without replacing any hardware, it uses Maps traffic data and ML models to recommend signal-timing adjustments to city traffic engineers, achieving &lt;strong&gt;10–20%&lt;/strong&gt; fewer stops and about 10% lower intersection emissions in cities including Jakarta, Rio de Janeiro, and Seattle (&lt;a href="https://aibuzz.blog/ai-in-transportation-and-smart-cities/" rel="noopener noreferrer"&gt;aibuzz industry overview&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;China's practice is equally substantial in scale: &lt;strong&gt;Alibaba City Brain&lt;/strong&gt; achieved roughly &lt;strong&gt;15%&lt;/strong&gt; lower travel times in central Hangzhou and up to 50% shorter passage times for emergency vehicles (&lt;a href="https://www.aicerts.ai/news/urban-ai-slashes-commute-times-by-32/" rel="noopener noreferrer"&gt;AICerts, citing CGTN coverage&lt;/a&gt;); DiDi's and Meituan's dispatch and scheduling systems were detailed earlier. The success factors of traffic-signal control carry general lessons: short evaluation loops (effects observable same-day), safety constraints naturally embedded in engineering boundaries (timing plans have physical and regulatory bounds), and benefits accruing simultaneously on efficiency and emissions dimensions, easing public support. Together with data-center cooling, it proves a siting principle—&lt;strong&gt;the best entry points for learning optimization are closed-loop physical systems where "constraints are naturally clear, gains are immediately visible, and trial-and-error is cheap."&lt;/strong&gt;&lt;/p&gt;

&lt;h3&gt;
  
  
  9.6 Financial Trade Execution: Reinforcement Learning's Invisible Large-Scale Deployment
&lt;/h3&gt;

&lt;p&gt;Finance is a domain where reinforcement learning has quietly achieved large-scale production deployment. &lt;strong&gt;JPMorgan's LOXM&lt;/strong&gt; has used deep reinforcement learning to execute large equity orders since 2017: trained on billions of real and simulated trades, the system learns how to choose the timing, size, and venue of order slicing in fragmented markets to minimize market impact; in pilots on the European equities business it outperformed both humans and traditional execution algorithms, and was subsequently rolled out to global equities (&lt;a href="https://endroid.com/2017/jp-morgan-develops-ai-that-executes-trades/" rel="noopener noreferrer"&gt;Endroid relaying &lt;em&gt;Financial Times&lt;/em&gt; coverage&lt;/a&gt;, &lt;a href="https://appinventiv.com/blog/ai-trading-agents/" rel="noopener noreferrer"&gt;Appinventiv industry analysis&lt;/a&gt;). Especially noteworthy is its governance architecture: LOXM's learning and trading behavior is strictly bounded within the firm's electronic-trading risk framework, supervised by an internal control group and validated by regulators—a financial-sector version of §7.1's "safety filter" idea.&lt;/p&gt;

&lt;p&gt;Among peers, BlackRock's Aladdin platform embeds production-grade AI agents into risk-management and portfolio-decision processes covering trillions of dollars in assets, and Citadel Securities has supported its market-making strategies with machine learning for over two decades (&lt;a href="https://appinventiv.com/blog/ai-trading-agents/" rel="noopener noreferrer"&gt;Appinventiv&lt;/a&gt;). One principle from finance holds for every industry: "&lt;strong&gt;narrow problems first&lt;/strong&gt;"—RL proved production value on trade execution (a narrow problem with a clear objective—minimizing impact cost—and immediate feedback), while open problems such as price prediction still have no reproducible success; when choosing an entry point for learning optimization, a problem's "evaluability" is more decisive than its "importance" (&lt;a href="https://www.tradealgo.com/trading-guides/ai-trading/machine-learning-stock-prediction" rel="noopener noreferrer"&gt;TradeAlgo technical analysis&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  9.7 Commercial Platforms and Solver Vendors Go All-In on Learning
&lt;/h3&gt;

&lt;p&gt;Beyond NVIDIA cuOpt and Huawei OptVerse (detailed earlier), the traditional supply-chain planning software (APS) industry is also going all-in on AI. &lt;strong&gt;Blue Yonder&lt;/strong&gt; (owned by Panasonic, a global APS leader) integrates ML demand sensing, multi-echelon inventory optimization, and constraint-aware planning into a unified platform, officially claiming up to &lt;strong&gt;74%&lt;/strong&gt; forecast-accuracy improvement, 47% planning-efficiency gains, and up to 24% lower inventory costs (&lt;a href="https://blueyonder.com/solutions/supply-chain-planning" rel="noopener noreferrer"&gt;Blue Yonder website&lt;/a&gt;); third-party firm Nucleus Research's customer interviews show post-deployment delivery rates of 95–98%, with one global semiconductor manufacturer raising priority-customer fulfillment from 45% to 88% (&lt;a href="https://nucleusresearch.com/research/single/blue-yonder-supply-chain-planning-drives-resilience-across-industries/" rel="noopener noreferrer"&gt;Nucleus Research&lt;/a&gt;). In 2026 Blue Yonder went further, partnering with NVIDIA to build a "model training factory" using the NeMo toolchain to mass-produce specialized AI agents that autonomously execute supply-chain processes (&lt;a href="https://readmagazine.com/industries/blue-yonder-and-nvidia-partner-to-accelerate-the-autonomous-supply-chain/" rel="noopener noreferrer"&gt;Read Magazine&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;At the lowest solver layer, learning's penetration is more invisible but equally thorough: &lt;strong&gt;Gurobi&lt;/strong&gt;'s built-in automatic parameter-tuning tool searches for better parameter combinations over a corpus of thousands of customer models, and its default parameters are themselves the product of large-scale experimental tuning (&lt;a href="https://support.gurobi.com/hc/en-us/articles/19998635021713-What-is-parameter-tuning" rel="noopener noreferrer"&gt;Gurobi official documentation&lt;/a&gt;); Gurobi also publicly recommends machine learning for automatic selection of model structures and solving strategies. This corroborates Chapter 3's core thesis: &lt;strong&gt;the first place learning components get commercialized is the "invisible interior" of solvers&lt;/strong&gt;—users may not even realize they are using learning optimization. From DeepMind cooling's bespoke 2016 project to 2025's platformized products (cuOpt, Cerebrus, Blue Yonder), learning optimization is completing its commoditization along the maturity curve of "custom project → replicable product → platform ecosystem."&lt;/p&gt;

&lt;h3&gt;
  
  
  9.8 Consolidated Comparison of Global Deployments
&lt;/h3&gt;

&lt;p&gt;The table below consolidates the global deployments covered in this chapter and earlier, organized by "region × industry × paradigm," to facilitate horizontal comparison of each paradigm's maturity and evidence strength:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Case&lt;/th&gt;
&lt;th&gt;Region&lt;/th&gt;
&lt;th&gt;Industry&lt;/th&gt;
&lt;th&gt;Paradigm&lt;/th&gt;
&lt;th&gt;Quantified gains&lt;/th&gt;
&lt;th&gt;Evidence source&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;DeepMind cooling optimization&lt;/td&gt;
&lt;td&gt;US / global&lt;/td&gt;
&lt;td&gt;Data centers&lt;/td&gt;
&lt;td&gt;Learning-based control&lt;/td&gt;
&lt;td&gt;Cooling energy −40%, PUE −15%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://deepmind.google/blog/deepmind-ai-reduces-google-data-centre-cooling-bill-by-40/" rel="noopener noreferrer"&gt;DeepMind blog&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;AlphaChip&lt;/td&gt;
&lt;td&gt;US&lt;/td&gt;
&lt;td&gt;Chip design&lt;/td&gt;
&lt;td&gt;End-to-end RL&lt;/td&gt;
&lt;td&gt;Multiple TPU generations in production; placement weeks → hours&lt;/td&gt;
&lt;td&gt;&lt;a href="https://deepmind.google/discover/blog/how-alphachip-transformed-computer-chip-design/" rel="noopener noreferrer"&gt;DeepMind&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;AlphaDev&lt;/td&gt;
&lt;td&gt;US&lt;/td&gt;
&lt;td&gt;Foundational software&lt;/td&gt;
&lt;td&gt;RL algorithm discovery&lt;/td&gt;
&lt;td&gt;Sorting +70% (small), hashing +30%; merged into LLVM libc++&lt;/td&gt;
&lt;td&gt;&lt;a href="https://pmc.ncbi.nlm.nih.gov/articles/PMC10247365/" rel="noopener noreferrer"&gt;Nature/PMC&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Synopsys DSO.ai&lt;/td&gt;
&lt;td&gt;US / global&lt;/td&gt;
&lt;td&gt;EDA&lt;/td&gt;
&lt;td&gt;RL design-space search&lt;/td&gt;
&lt;td&gt;Double-digit PPA gains on production designs (vendor-disclosed)&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.ad-hoc-news.de/boerse/news/ueberblick/flagship-twist-for-synopsys-dso-ai-anchors-the-ai-driven-chip-design-push/69544982" rel="noopener noreferrer"&gt;ad-hoc-news&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Cadence Cerebrus × Samsung SSIR/SARC&lt;/td&gt;
&lt;td&gt;Korea / India / US&lt;/td&gt;
&lt;td&gt;EDA&lt;/td&gt;
&lt;td&gt;RL full-flow optimization&lt;/td&gt;
&lt;td&gt;PPA +8–11%; productivity 4×&lt;/td&gt;
&lt;td&gt;&lt;a href="https://community.cadence.com/cadence_blogs_8/b/di/posts/transforming-chip-design-with-cadence-cerebrus-ai-studio" rel="noopener noreferrer"&gt;Cadence blog&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Cerebrus × Phison&lt;/td&gt;
&lt;td&gt;Taiwan, China&lt;/td&gt;
&lt;td&gt;EDA&lt;/td&gt;
&lt;td&gt;RL full-flow optimization&lt;/td&gt;
&lt;td&gt;Power −35%, area −3% (one week)&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.design-reuse.com/news/15490-phison-deploys-cadence-cerebrus-ai-driven-chip-optimization-to-accelerate-product-development/" rel="noopener noreferrer"&gt;design-reuse&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Cerebrus × MediaTek&lt;/td&gt;
&lt;td&gt;Taiwan, China&lt;/td&gt;
&lt;td&gt;EDA&lt;/td&gt;
&lt;td&gt;RL floor-planning&lt;/td&gt;
&lt;td&gt;Area −5%, power −6%; full production adoption&lt;/td&gt;
&lt;td&gt;&lt;a href="https://iconnect007.com/article/132323/cadence-cerebrus-delivers-transformative-results-on-nextgen-designs/132326/ein" rel="noopener noreferrer"&gt;iconnect007&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Tesla Autobidder&lt;/td&gt;
&lt;td&gt;US / Australia / Europe&lt;/td&gt;
&lt;td&gt;Energy trading&lt;/td&gt;
&lt;td&gt;Predict + optimize&lt;/td&gt;
&lt;td&gt;Manages 7+ GWh storage; $420M cumulative trading profit&lt;/td&gt;
&lt;td&gt;&lt;a href="https://talents.vaia.com/companies/tesla-motors-inc/staff-quantitative-energy-trading-meteorologist-autobidder-33533481/" rel="noopener noreferrer"&gt;Tesla job posting&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Yokogawa × ENEOS column&lt;/td&gt;
&lt;td&gt;Japan&lt;/td&gt;
&lt;td&gt;Chemicals&lt;/td&gt;
&lt;td&gt;FKDPP RL control&lt;/td&gt;
&lt;td&gt;Steam −40%; 35-day autonomy then normal operation&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.cbinsights.com/company/arc-advisory-group" rel="noopener noreferrer"&gt;ARC/CB Insights&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Yokogawa × Saudi Aramco Fadhili&lt;/td&gt;
&lt;td&gt;Saudi Arabia&lt;/td&gt;
&lt;td&gt;Natural gas&lt;/td&gt;
&lt;td&gt;FKDPP multi-agent control&lt;/td&gt;
&lt;td&gt;Amine/steam −10–15%, electricity −5%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.yokogawa.com/vn/news/press-releases/2025/2025-10-29/" rel="noopener noreferrer"&gt;Yokogawa press release&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;RTE L2RPN / Grid2Op&lt;/td&gt;
&lt;td&gt;France&lt;/td&gt;
&lt;td&gt;Power grids&lt;/td&gt;
&lt;td&gt;RL benchmark ecosystem&lt;/td&gt;
&lt;td&gt;Became the global standard competition &amp;amp; simulator for grid RL&lt;/td&gt;
&lt;td&gt;&lt;a href="https://howtostorelectricity.com/ai-grid-congestion-management-redispatch/" rel="noopener noreferrer"&gt;howtostoreelectricity&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;UPS ORION&lt;/td&gt;
&lt;td&gt;US&lt;/td&gt;
&lt;td&gt;Parcel&lt;/td&gt;
&lt;td&gt;OR engine + ML prediction&lt;/td&gt;
&lt;td&gt;100M miles, $300–400M, 100k tonnes CO₂ saved annually&lt;/td&gt;
&lt;td&gt;&lt;a href="https://arxiv.org/html/2604.25847v1" rel="noopener noreferrer"&gt;arXiv 2604.25847&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Amazon DeepFleet&lt;/td&gt;
&lt;td&gt;US / global&lt;/td&gt;
&lt;td&gt;Warehouse robotics&lt;/td&gt;
&lt;td&gt;Multi-robot foundation model&lt;/td&gt;
&lt;td&gt;Fleet travel efficiency +10%; million-robot scale&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.amazon.science/blog/amazon-builds-first-foundation-model-for-multirobot-coordination" rel="noopener noreferrer"&gt;Amazon Science&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Ocado smart warehouses&lt;/td&gt;
&lt;td&gt;UK&lt;/td&gt;
&lt;td&gt;Warehouse robotics&lt;/td&gt;
&lt;td&gt;Swarm intelligence + ML&lt;/td&gt;
&lt;td&gt;Thousands of robots in coordinated fulfillment&lt;/td&gt;
&lt;td&gt;&lt;a href="https://encord.com/blog/ai-and-robotics/" rel="noopener noreferrer"&gt;Encord&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;InstaDeep&lt;/td&gt;
&lt;td&gt;UK / Tunisia&lt;/td&gt;
&lt;td&gt;Logistics / rail&lt;/td&gt;
&lt;td&gt;RL combinatorial optimization&lt;/td&gt;
&lt;td&gt;Acquired by BioNTech for €636M&lt;/td&gt;
&lt;td&gt;&lt;a href="https://startupintros.com/orgs/instadeep" rel="noopener noreferrer"&gt;StartupIntros&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;UN WFP supply chain&lt;/td&gt;
&lt;td&gt;Global, 80+ countries&lt;/td&gt;
&lt;td&gt;Humanitarian logistics&lt;/td&gt;
&lt;td&gt;Analytics + optimization&lt;/td&gt;
&lt;td&gt;$150M+ cumulative savings&lt;/td&gt;
&lt;td&gt;&lt;a href="https://arxiv.org/html/2604.25847v1" rel="noopener noreferrer"&gt;arXiv 2604.25847&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Surtrac (Pittsburgh)&lt;/td&gt;
&lt;td&gt;US&lt;/td&gt;
&lt;td&gt;Traffic signals&lt;/td&gt;
&lt;td&gt;Distributed adaptive optimization&lt;/td&gt;
&lt;td&gt;Travel −25%, waiting −40%, emissions −21%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://publications.ri.cmu.edu/storage/publications/pub_files/2013/1/13-0315.pdf" rel="noopener noreferrer"&gt;CMU paper&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Google Green Light&lt;/td&gt;
&lt;td&gt;Multiple cities worldwide&lt;/td&gt;
&lt;td&gt;Traffic signals&lt;/td&gt;
&lt;td&gt;ML timing recommendations&lt;/td&gt;
&lt;td&gt;Stops −10–20%, emissions −10%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://aibuzz.blog/ai-in-transportation-and-smart-cities/" rel="noopener noreferrer"&gt;aibuzz&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Alibaba City Brain&lt;/td&gt;
&lt;td&gt;China&lt;/td&gt;
&lt;td&gt;Urban transport&lt;/td&gt;
&lt;td&gt;Learning + optimization&lt;/td&gt;
&lt;td&gt;Central Hangzhou travel −15%; emergency vehicles −50%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.aicerts.ai/news/urban-ai-slashes-commute-times-by-32/" rel="noopener noreferrer"&gt;AICerts&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DiDi smart dispatch&lt;/td&gt;
&lt;td&gt;China&lt;/td&gt;
&lt;td&gt;Mobility platform&lt;/td&gt;
&lt;td&gt;RL + combinatorial optimization&lt;/td&gt;
&lt;td&gt;20+ cities; GMV +0.5%–2%&lt;/td&gt;
&lt;td&gt;&lt;a href="https://blog.csdn.net/comli_cn/article/details/162374132" rel="noopener noreferrer"&gt;DiDi technical sharing&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;JPMorgan LOXM&lt;/td&gt;
&lt;td&gt;US / Europe&lt;/td&gt;
&lt;td&gt;Financial execution&lt;/td&gt;
&lt;td&gt;Deep reinforcement learning&lt;/td&gt;
&lt;td&gt;Outperformed humans &amp;amp; traditional execution algorithms (pilot)&lt;/td&gt;
&lt;td&gt;&lt;a href="https://endroid.com/2017/jp-morgan-develops-ai-that-executes-trades/" rel="noopener noreferrer"&gt;Endroid/FT&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Blue Yonder platform&lt;/td&gt;
&lt;td&gt;Japan / US&lt;/td&gt;
&lt;td&gt;Supply-chain APS&lt;/td&gt;
&lt;td&gt;ML demand sensing + optimization&lt;/td&gt;
&lt;td&gt;Forecast accuracy +74%; delivery rate 95–98%&lt;/td&gt;
&lt;td&gt;
&lt;a href="https://blueyonder.com/solutions/supply-chain-planning" rel="noopener noreferrer"&gt;Blue Yonder&lt;/a&gt;, &lt;a href="https://nucleusresearch.com/research/single/blue-yonder-supply-chain-planning-drives-resilience-across-industries/" rel="noopener noreferrer"&gt;Nucleus&lt;/a&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;NVIDIA cuOpt&lt;/td&gt;
&lt;td&gt;US&lt;/td&gt;
&lt;td&gt;Solver platform&lt;/td&gt;
&lt;td&gt;GPU heuristics + LLM skills&lt;/td&gt;
&lt;td&gt;Lyric case 240×; COIN-OR Cup 2025&lt;/td&gt;
&lt;td&gt;
&lt;a href="https://www.coin-or.org/2025/10/26/2025-coin-or-cup-award-nvidia-cuopt/" rel="noopener noreferrer"&gt;COIN-OR&lt;/a&gt;, &lt;a href="https://lyric.tech/blog/lyric-leverages-nvidia-cuopt-to-elevate-supply-chain-ai" rel="noopener noreferrer"&gt;Lyric&lt;/a&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Huawei OptVerse&lt;/td&gt;
&lt;td&gt;China&lt;/td&gt;
&lt;td&gt;Commercial solver&lt;/td&gt;
&lt;td&gt;Learning-augmented components&lt;/td&gt;
&lt;td&gt;Ports, manufacturing, supply chain scenarios&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.huaweicloud.com/product/optverse.html" rel="noopener noreferrer"&gt;Huawei Cloud&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;Surveying this global map yields four cross-case regularities. First, &lt;strong&gt;gain magnitude correlates positively with industry digital maturity&lt;/strong&gt;: "fully digital closed-loop" industries such as semiconductor EDA and data centers see the largest gains (double-digit percentages), because evaluation and rollback both happen inside software; physical-world industries (transport, logistics) cluster in the 10–25% range but with enormous absolute amounts. Second, &lt;strong&gt;the hybrid architecture is the only repeatedly validated form&lt;/strong&gt;: from ORION's "OR engine + ML prediction" to Yokogawa's "RL agent + DCS safety system" to LOXM's "RL policy + risk framework," no scaled deployment uses bare end-to-end learning. Third, &lt;strong&gt;deployment cycles are measured in years&lt;/strong&gt;: ORION took 11 years (a J-curve), and ENEOS took a year from 35-day pilot to normal operation—building organizational trust takes longer than training algorithms. Fourth, &lt;strong&gt;platformization is compressing costs for latecomers&lt;/strong&gt;: cuOpt, Cerebrus, and Blue Yonder let 2026 adopters avoid repeating the self-development path of 2016 pioneers.&lt;/p&gt;




&lt;h2&gt;
  
  
  10. Open-Source Toolchain Panorama and Selection
&lt;/h2&gt;

&lt;h3&gt;
  
  
  10.1 A Tool Map by Paradigm
&lt;/h3&gt;

&lt;p&gt;The first step of engineering adoption is choosing the right tools. The table below summarizes current mainstream open-source tools and libraries by paradigm, covering positioning, underlying dependencies, and applicable stages:&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Paradigm&lt;/th&gt;
&lt;th&gt;Tool / library&lt;/th&gt;
&lt;th&gt;Positioning and characteristics&lt;/th&gt;
&lt;th&gt;Underlying dependencies&lt;/th&gt;
&lt;th&gt;Source&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;End-to-end NCO&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;RL4CO&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;Unified RL framework for neural CO; 20+ models, 20+ environments; standardized evaluation&lt;/td&gt;
&lt;td&gt;PyTorch Lightning&lt;/td&gt;
&lt;td&gt;
&lt;a href="https://github.com/ai4co/rl4co" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;, &lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;KDD 2025&lt;/a&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;End-to-end NCO&lt;/td&gt;
&lt;td&gt;Unify ML4TSP / ML4CO-Bench-101&lt;/td&gt;
&lt;td&gt;Unified implementations of TSP methods and a large-scale benchmark suite&lt;/td&gt;
&lt;td&gt;PyTorch&lt;/td&gt;
&lt;td&gt;&lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Learning-augmented solvers&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;Ecole&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;"In-solver RL environment" library deeply integrated with SCIP; standard interfaces for learnable components such as branching/cut selection&lt;/td&gt;
&lt;td&gt;SCIP, Python&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.ecole.ai/" rel="noopener noreferrer"&gt;Ecole docs&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Learning-augmented solvers&lt;/td&gt;
&lt;td&gt;Huawei OptVerse, NVIDIA cuOpt&lt;/td&gt;
&lt;td&gt;Learning components / GPU acceleration in commercial solvers&lt;/td&gt;
&lt;td&gt;Commercial / cloud services&lt;/td&gt;
&lt;td&gt;
&lt;a href="https://www.huaweicloud.com/product/optverse.html" rel="noopener noreferrer"&gt;Huawei Cloud&lt;/a&gt;, &lt;a href="https://www.nvidia.com/en-us/ai-data-science/products/cuopt/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;L2O&lt;/td&gt;
&lt;td&gt;JMLR 2022 benchmark, learn2optimize&lt;/td&gt;
&lt;td&gt;Standardized L2O benchmark and reference implementations&lt;/td&gt;
&lt;td&gt;JAX/PyTorch&lt;/td&gt;
&lt;td&gt;&lt;a href="https://www.jmlr.org/papers/v23/21-0308.html" rel="noopener noreferrer"&gt;JMLR 2022&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Decision-focused learning&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;PyEPO&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;End-to-end predict-then-optimize library; SPO+ / perturbation / contrastive losses; autograd&lt;/td&gt;
&lt;td&gt;PyTorch + Gurobi&lt;/td&gt;
&lt;td&gt;&lt;a href="https://arxiv.org/html/2206.14234v3" rel="noopener noreferrer"&gt;PyEPO&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;LLM optimization&lt;/td&gt;
&lt;td&gt;&lt;strong&gt;OpenEvolve&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;Open-source reproduction of AlphaEvolve; LLM code-evolution framework&lt;/td&gt;
&lt;td&gt;Any LLM API&lt;/td&gt;
&lt;td&gt;&lt;a href="https://github.com/closedloop-technologies/awesome-llm-evolution" rel="noopener noreferrer"&gt;awesome-llm-evolution&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;LLM optimization&lt;/td&gt;
&lt;td&gt;OptiMUS / ORLM&lt;/td&gt;
&lt;td&gt;Natural language → MILP modeling and solving&lt;/td&gt;
&lt;td&gt;GPT-4 / fine-tuned open models&lt;/td&gt;
&lt;td&gt;
&lt;a href="https://icml.cc/virtual/2024/poster/33771" rel="noopener noreferrer"&gt;ICML 2024&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2405.17743v4" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;
&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Robot planning&lt;/td&gt;
&lt;td&gt;Motion Planning Diffusion, MπNets, etc.&lt;/td&gt;
&lt;td&gt;Open-source diffusion / neural motion-planning implementations&lt;/td&gt;
&lt;td&gt;PyTorch + MuJoCo/simulators&lt;/td&gt;
&lt;td&gt;&lt;a href="https://prpl-group.com/tamp-learning-survey.pdf" rel="noopener noreferrer"&gt;TAMP survey&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Classical baselines&lt;/td&gt;
&lt;td&gt;
&lt;strong&gt;OR-Tools&lt;/strong&gt; (CP-SAT), SCIP, LKH-3, HGS&lt;/td&gt;
&lt;td&gt;The mandatory control group for every learning method&lt;/td&gt;
&lt;td&gt;C++/Python&lt;/td&gt;
&lt;td&gt;&lt;a href="https://developers.google.com/optimization" rel="noopener noreferrer"&gt;OR-Tools&lt;/a&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;p&gt;(Compiled from &lt;a href="https://github.com/Thinklab-SJTU/awesome-ml4co" rel="noopener noreferrer"&gt;awesome-ml4co&lt;/a&gt;, &lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;, and each tool's official documentation)&lt;/p&gt;

&lt;h3&gt;
  
  
  10.2 Key Dimensions of Selection Decisions
&lt;/h3&gt;

&lt;p&gt;Tool selection is essentially a trade-off across five dimensions. &lt;strong&gt;Problem scale and latency budget&lt;/strong&gt; determine architecture: millisecond inference and very-large-scale instances favor end-to-end NCO or learned dispatching rules; minute-level budgets at medium scale should default to classical solvers or learning-augmented solvers. &lt;strong&gt;Data availability&lt;/strong&gt; determines paradigm feasibility: DFL needs historical (features, realizations) pairs; NCO needs large volumes of in-distribution instances for training; LLM modeling has an almost-zero data threshold. &lt;strong&gt;Guarantee requirements&lt;/strong&gt; determine risk structure: safety-critical scenarios must keep classical solvers or safety filters as the backstop layer, with learned components providing only acceleration and suggestions. &lt;strong&gt;Team capability&lt;/strong&gt; determines build-vs-buy: organizations without a dedicated optimization team should realistically start with cuOpt/OptVerse-class platforms and OR-Tools; only teams with research capability should invest in RL4CO/Ecole self-development. &lt;strong&gt;Maintenance cost&lt;/strong&gt; is often overlooked: learned models need retraining pipelines as business distributions drift, while pure-solver solutions have near-zero operations overhead—over a system lifecycle of three-plus years, this difference often exceeds initial development cost.&lt;/p&gt;

&lt;p&gt;One practical recommendation runs through this chapter: &lt;strong&gt;whichever learning route you choose, first establish a classical baseline with OR-Tools CP-SAT or SCIP&lt;/strong&gt;. This is both the mandatory exam question for any subsequent learning method (§2.3's critique is essentially "missing rigorous baseline comparisons") and the production fallback if the learning approach fails. RL4CO's unified evaluation shook the community precisely because it revealed that many papers' SOTA claims do not hold under fair baselines (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;RL4CO, KDD 2025&lt;/a&gt;).&lt;/p&gt;




&lt;h2&gt;
  
  
  11. Engineering Adoption Guide
&lt;/h2&gt;

&lt;h3&gt;
  
  
  11.1 A Paradigm-Selection Decision Framework
&lt;/h3&gt;

&lt;p&gt;Synthesizing the evidence across this report yields a paradigm-selection flow for engineering decision-makers. &lt;strong&gt;Question 1: Does the optimization problem have a mature mathematical-programming formulation and an acceptable solving time?&lt;/strong&gt; If yes, default to the learning-augmented solver route (Chapter 3) or pure solvers, using learned components only for initial solutions, branching, cut selection, and parameter tuning—the lowest-risk, most certain-payoff path. &lt;strong&gt;Question 2: Are there massive volumes of in-distribution instances with extreme latency requirements?&lt;/strong&gt; If yes (e.g., tens of thousands of routing or scheduling decisions daily), end-to-end NCO or learned dispatching rules are worth the investment, but must be paired with a classical refinement layer. &lt;strong&gt;Question 3: Is there a known cost asymmetry between prediction and decision?&lt;/strong&gt; If yes, DFL (Chapter 5) is the most targeted and theoretically complete choice, and PyEPO can complete a proof of concept within a week. &lt;strong&gt;Question 4: Is the bottleneck modeling labor rather than solving?&lt;/strong&gt; If yes, adopt LLM modeling solutions directly (OptiMUS/ORLM/cuOpt agent skills)—let the LLM do translation and the solver do computation. &lt;strong&gt;Question 5: Do you have a programmatically evaluable objective function and an ambition to explore "uncharted" algorithms?&lt;/strong&gt; If yes, FunSearch/OpenEvolve-style evolutionary frameworks are currently the only validated general method that can produce heuristics surpassing human designs.&lt;/p&gt;

&lt;p&gt;The unifying logic behind this framework is one this report has emphasized repeatedly: &lt;strong&gt;the value density of a learned component is inversely proportional to its position in the decision chain&lt;/strong&gt;—the closer to final action output, the higher the risk and verification cost; the further upstream (prediction, modeling, initial solutions, parameter suggestions), the lower the failure cost and the smoother the integration with existing systems. Every successful industrial case (Chapter 9) obeys this law without exception.&lt;/p&gt;

&lt;h3&gt;
  
  
  11.2 Common Pitfalls and a Deployment Checklist
&lt;/h3&gt;

&lt;p&gt;Six high-frequency pitfalls can be distilled from the literature and industrial cases. First, &lt;strong&gt;train/production distribution drift&lt;/strong&gt;: scheduling and routing models are extremely sensitive to distribution shift; retraining triggers and offline simulation regression tests are mandatory. Second, &lt;strong&gt;missing or unfair baselines&lt;/strong&gt;: many projects' "improvements" are relative to weak baselines (greedy rules) and may vanish against CP-SAT/metaheuristics—lock in strong baselines at project kickoff. Third, &lt;strong&gt;ignoring infeasibility&lt;/strong&gt;: end-to-end methods may output hard-constraint-violating solutions; a repair or constraint-projection layer is mandatory. Fourth, &lt;strong&gt;reward hacking&lt;/strong&gt;: RL optimizing proxy metrics (e.g., makespan proxies) can damage true business metrics; practices such as DiDi's use online A/B business metrics as the final arbiter. Fifth, &lt;strong&gt;the sim-to-real gap&lt;/strong&gt;: after training in simulation, real-system latency, noise, and exceptional events significantly erode learned scheduling and control policies; domain randomization and online adaptation are standard mitigations. Sixth, &lt;strong&gt;LLM hallucinations entering the decision chain&lt;/strong&gt;: LLM-generated model code or heuristics must pass automated unit tests and feasibility checks (OptiMUS's debugging iterations and FunSearch's evaluator filtering are designed precisely for this); no unverified LLM output should ever reach production execution.&lt;/p&gt;

&lt;p&gt;Correspondingly, a minimum viable production-deployment checklist includes: a classical baseline solver and its service encapsulation; input/output schemas and a constraint-validation layer for learned components; offline simulation replay and regression benchmark suites; canary releases with automatic rollback (backstopped by classical baseline outputs); decision audit logs (especially for LLM-involved steps); and distribution-drift monitoring with a retraining pipeline. The essence of this checklist is designing the architecture to treat learned components as "replaceable performance enhancers" rather than "the heart of the system"—the heart is always the verifiable constraint-and-rule layer.&lt;/p&gt;

&lt;h3&gt;
  
  
  11.3 From Shadow Mode to Closed-Loop Autonomy: A Staged Deployment Path
&lt;/h3&gt;

&lt;p&gt;Synthesizing deployment records from Yokogawa, DeepMind, UPS, and other global cases yields a repeatedly validated &lt;strong&gt;four-stage deployment path&lt;/strong&gt;, applicable to almost any safety-critical or high-value learning-optimization system. &lt;strong&gt;Stage 1: simulator training and offline replay&lt;/strong&gt;—build a digital twin of the physical system or business process, train the learned policy inside it, and validate with historical-data replay; Yokogawa built plant-level simulators for both the ENEOS and Aramco projects and touched real equipment only after simulation validation passed (&lt;a href="https://www.yokogawa.com/vn/news/press-releases/2025/2025-10-29/" rel="noopener noreferrer"&gt;Yokogawa press release&lt;/a&gt;). &lt;strong&gt;Stage 2: shadow mode&lt;/strong&gt;—the learning system runs in parallel with the existing system, recording only "what would happen if its suggestions were followed" without actually executing, exposing distribution shift and long-tail failures. &lt;strong&gt;Stage 3: human-in-the-loop&lt;/strong&gt;—the AI outputs suggestions and operators review them before manual execution; the ENEOS project stayed in this stage for a considerable time, with operators reviewing each AI-suggested valve setting before entering it into the DCS—"this extended review period reduced risk and helped operators understand and trust the model" (&lt;a href="https://www.controlglobal.com/show-coverage/ynow-a-yokogawa-users-conference/article/55402763/yokogawa-how-eneos-put-reinforcement-learning-in-control-of-a-chemical-plant" rel="noopener noreferrer"&gt;Control Global coverage&lt;/a&gt;). &lt;strong&gt;Stage 4: bounded closed-loop autonomy&lt;/strong&gt;—the AI executes directly but is wrapped layer upon layer by rule-based bounds, existing safety instrumented systems, and one-click fallback mechanisms; the ENEOS project's principle was summarized by its engineers as "the AI model is never the only safety barrier" (&lt;a href="https://www.controlglobal.com/show-coverage/ynow-a-yokogawa-users-conference/article/55402763/yokogawa-how-eneos-put-reinforcement-learning-in-control-of-a-chemical-plant" rel="noopener noreferrer"&gt;Control Global&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The most underestimated aspect of this path is the &lt;strong&gt;organizational and change-management dimension&lt;/strong&gt;. UPS ORION's benefit curve follows a classic J shape: early deployment in 2013–2014 produced almost no gains because drivers distrusted routes that violated their years of experience; only after the ML models absorbed driver feedback and training programs caught up did benefits accelerate—the full journey took 11 years (&lt;a href="https://www.linkedin.com/pulse/roi-curve-ai-adoption-across-industries-andre-dcxme" rel="noopener noreferrer"&gt;LinkedIn ROI analysis&lt;/a&gt;). DeepMind's cooling system likewise ran in "recommendation mode" for months, with on-site engineers reviewing each suggestion, before gradually transitioning to autonomous control. The pragmatic lessons for engineering teams: budget more time for Stage 3 (human-in-the-loop) than for algorithm development in project plans; design operator feedback as part of the training data rather than as noise outside the system; and set explicit "promotion criteria" for each stage (e.g., shadow-mode regret below threshold for 30 consecutive days before advancing), making the trust-building process itself engineered and measurable.&lt;/p&gt;




&lt;h2&gt;
  
  
  12. Challenges, Controversies, and Open Problems
&lt;/h2&gt;

&lt;h3&gt;
  
  
  12.1 Fundamental Questions on Generalization and Scaling
&lt;/h3&gt;

&lt;p&gt;The sharpest challenge facing end-to-end NCO comes from critical research in the ACM computing-surveys lineage in 2024: learned constructive/improvement solvers degrade far more on out-of-distribution instances than advertised, and generally lag specialized classical solvers such as LKH-3, HGS, and Concorde in solution quality, holding an advantage only in inference latency (&lt;a href="https://dl.acm.org/doi/10.1145/3643806" rel="noopener noreferrer"&gt;Applicability critique, ACM 2024&lt;/a&gt;). Work such as RsGCN further points out that many NCO papers' "generalization" conclusions stem from the sampling artifact of training and test sets drawn from the same distribution (&lt;a href="https://arxiv.org/abs/2403.00990" rel="noopener noreferrer"&gt;RsGCN&lt;/a&gt;). The controversy has not subsided in 2025–2026 but has instead converted into a stricter evaluation culture: ML4CO-Bench-101, RL4CO's unified protocol, and COExpander's cross-scale generalization tests are all products of the community's self-correction (&lt;a href="https://dl.acm.org/doi/10.1145/3711896.3737433" rel="noopener noreferrer"&gt;RL4CO&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Deeper open problems are theoretical: why can deep models approach or even locally surpass heuristics polished for decades on some combinatorial problems—what is the essence of their inductive bias; after learned components are embedded in solvers, how can classical optimality/convergence guarantees be formally preserved or their degradation quantified (the "guarantee-free acceleration" of learned MIP branching is currently empirical); and how should reproducibility and novelty criteria be established for the outputs of LLM-evolved algorithms (AlphaEvolve-type)—when "algorithm invention" itself is automated, peer review and intellectual-property frameworks face new questions (&lt;a href="https://github.com/closedloop-technologies/awesome-llm-evolution" rel="noopener noreferrer"&gt;awesome-llm-evolution&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  12.2 Data, Evaluation, and Trustworthiness
&lt;/h3&gt;

&lt;p&gt;Data and evaluation infrastructure are bottlenecks constraining the entire field. Combinatorial optimization lacks ImageNet-style public datasets and accepted splits, and papers' self-built instances make horizontal comparison difficult; scheduling simulators are mutually incompatible; in L2O, despite the JMLR 2022 benchmarking effort, systematic characterization of "how learned optimizers fail on unseen task families" is still missing (&lt;a href="https://www.jmlr.org/papers/v23/21-0308.html" rel="noopener noreferrer"&gt;JMLR 2022&lt;/a&gt;). On trustworthiness, safety-critical scenarios demand not average performance but worst-case guarantees—precisely why industry insists on architectures such as learning-augmented MPC's safety filters and solvers' exact backstops (&lt;a href="https://arxiv.org/pdf/2507.14025" rel="noopener noreferrer"&gt;Reiter et al. 2025&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Interpretability likewise remains unresolved: what structural features do GNN branching policies actually learn; why do diffusion planners' generated trajectories avoid certain configurations; why are LLM-evolved heuristics effective—answers to these questions currently remain mostly case-by-case analyses. For engineering teams, the practical implication of this status quo: learned components should be designed as black boxes that are "performance-monitorable, behavior-auditable, and failure-isolatable," with architectural redundancy reserved for their uninterpretability—rather than waiting for theory to mature.&lt;/p&gt;




&lt;h2&gt;
  
  
  13. Frontier Trends (2025–2026) and Outlook
&lt;/h2&gt;

&lt;h3&gt;
  
  
  13.1 The Rise of Foundation Models for Combinatorial Optimization (FM4CO)
&lt;/h3&gt;

&lt;p&gt;The clearest academic trend since 2025 is &lt;strong&gt;foundation models for combinatorial optimization (FM4CO)&lt;/strong&gt;: emulating language models' pretrain–finetune paradigm by pre-training unified models on large-scale, multi-type CO instances and then adapting them to specific problems. The awesome-fm4co list shows the direction already spans three routes: unified solvers across problem types, LLM end-to-end CO solving (NeurIPS 2025), and MILP foundation models (the MILP-Evolve lineage) (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). Its motivation directly answers Chapter 12's generalization critique: if a single model is pre-trained on sufficiently diverse instance distributions, out-of-distribution degradation should in theory be significantly mitigated. If this direction delivers, it will reshape the technical landscape of Chapters 2–3—the end-to-end vs. hybrid divide may be replaced by a new architecture of "pre-trained backbone + solver decoding/refinement."&lt;/p&gt;

&lt;p&gt;In parallel, evaluation and data infrastructure is maturing: large-scale benchmarks such as ML4CO-Bench-101, RL4CO's standard protocol, and new benchmarks targeting "algorithm-engineering capability"—HeuriGym (ICLR 2026) and ALE-Bench (NeurIPS 2025)—are pushing the field from "leaderboard-point racing" toward "capability characterization" (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). The signal for engineering teams: when selecting tools, prefer methods and tools with public, reproducible results on unified benchmarks over claims in individual papers.&lt;/p&gt;

&lt;h3&gt;
  
  
  13.2 Deep Coupling of LLMs and Solvers
&lt;/h3&gt;

&lt;p&gt;The second trend is LLMs' continued convergence toward—and consolidation in—the "semantic layer" of the optimization stack: &lt;strong&gt;four positions now each have mature representatives—modeling (OptiMUS/ORLM), explanation (OptiGuide/OptiChat), diagnosis (infeasibility analysis), and heuristic invention (FunSearch/AlphaEvolve/OpenEvolve)&lt;/strong&gt;, while the numerical-solving layer firmly remains with classical algorithms. NVIDIA's agent skills for cuOpt and Huawei OptVerse's integrated learning components show that commercial platforms have adopted "LLM frontend + strong solver backend" as the standard product form (&lt;a href="https://www.nvidia.com/en-us/ai-data-science/products/cuopt/" rel="noopener noreferrer"&gt;NVIDIA cuOpt&lt;/a&gt;). This division of labor will not change in the short term: numerical solving's requirements for precision, worst-case complexity, and certificates (optimality proofs, infeasibility proofs) are fundamentally incompatible with LLMs' probabilistic generation mechanism, whereas semantic translation, result explanation, and code generation sit squarely in the sweet spot of the LLM capability curve.&lt;/p&gt;

&lt;p&gt;The variable worth watching is the migration of the test-time-compute paradigm into optimization: MCTS-guided LLM reasoning search and long-chain-of-thought models' progress on mathematical-programming modeling may gradually raise the scale ceiling of problems LLMs can directly handle over the next two to three years (&lt;a href="https://arxiv.org/html/2510.09988v1" rel="noopener noreferrer"&gt;tree-search survey&lt;/a&gt;). Supporting evaluation infrastructure is also falling into place—OPT-BENCH measures agents' optimization ability in large search spaces, ALE-Bench examines long-horizon algorithm engineering, and HeuriGym specifically evaluates LLMs' level at designing combinatorial-optimization heuristics (&lt;a href="https://github.com/ai4co/awesome-fm4co" rel="noopener noreferrer"&gt;awesome-fm4co&lt;/a&gt;). For engineering teams, the pragmatic approach is to design system interfaces now around the architecture "LLMs own semantics, solvers own numerics," while abstracting the solving layer as a replaceable module—so that however the LLM capability boundary moves in the future, the system can absorb new capabilities with minimal change.&lt;/p&gt;

&lt;h3&gt;
  
  
  13.3 A Converging Unified Picture
&lt;/h3&gt;

&lt;p&gt;Looking across 2026, the six paradigms are converging into one unified engineering picture: &lt;strong&gt;classical solvers and simulators provide the skeleton of correctness and guarantees; learned components supply acceleration, generalization, and semantic interfaces at every seam of that skeleton&lt;/strong&gt;. End-to-end methods hold their niche in specific high-throughput scenarios; hybrid methods become the default architecture; LLMs take over human-machine interaction and heuristic design; and safety filters and audit layers guard the last mile of all learned outputs. For engineers and researchers entering this field, this report's final advice condenses to four points: start from strong classical baselines, and never evaluate a learning method without one; place learned components upstream in the decision chain and manage risk with architecture rather than hope; prefer toolchains endorsed by unified benchmarks (RL4CO, Ecole, PyEPO, OpenEvolve, OR-Tools/cuOpt); and track, at quarterly cadence, the two variables most likely to redraw the landscape—FM4CO and LLM-as-solver.&lt;/p&gt;




&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Disclaimer&lt;/strong&gt;: This report is a technical research survey. All cited data comes from public literature and official releases, and is provided for learning and technology-selection reference only; it does not constitute any commercial decision-making, investment, or legal advice. When deploying to specific production systems, please conduct independent verification and evaluation against your organization's actual business scenarios.&lt;/p&gt;
&lt;/blockquote&gt;

</description>
      <category>machinelearning</category>
      <category>operationsresearch</category>
      <category>optimization</category>
      <category>ai</category>
    </item>
    <item>
      <title>GPU-Accelerated Optimization Algorithms: A Complete Survey and Selection Guide (2026)</title>
      <dc:creator>Johnny is piggy</dc:creator>
      <pubDate>Fri, 18 Sep 2026 18:28:29 +0000</pubDate>
      <link>https://dev.to/johnnyispiggy/gpu-accelerated-optimization-algorithms-a-complete-survey-and-selection-guide-2026-2n6b</link>
      <guid>https://dev.to/johnnyispiggy/gpu-accelerated-optimization-algorithms-a-complete-survey-and-selection-guide-2026-2n6b</guid>
      <description>&lt;h2&gt;
  
  
  Executive Summary
&lt;/h2&gt;

&lt;p&gt;GPU-accelerated optimization algorithms have expanded far beyond their traditional home of deep learning training into virtually every branch of optimization: mathematical programming, combinatorial optimization, evolutionary computation, Bayesian optimization, robot motion planning, and even quantum-inspired annealing. The underlying logic is consistent everywhere: restructure the most time-consuming operators of an iterative optimizer (sparse matrix–vector products, batched candidate evaluation, matrix factorization, Monte Carlo sampling) into a massively parallel, memory-bandwidth-friendly form, compressing "overnight" problems into minutes or even milliseconds. This report systematically surveys the mainstream GPU-accelerated optimization algorithms and representative tools across five domains, presenting publicly reported performance figures (e.g., NVIDIA cuOpt delivering up to &lt;strong&gt;5,000×&lt;/strong&gt; speedup on a large multicommodity-flow LP instance; cuLoRADS achieving &lt;strong&gt;100×+&lt;/strong&gt; over CPU solvers on hundred-million-scale SDPs; cuRobo motion planning at &lt;strong&gt;60×&lt;/strong&gt; over CPU planners), and concludes with a scenario-by-scenario engineering selection table. It must be stressed that reported speedups come from very different measurement setups, and GPUs do not win on every problem — small instances, high-accuracy requirements, and branch-and-bound-style search remain CPU territory. Selection should always be validated by benchmarking on your own problem sizes and accuracy needs.&lt;/p&gt;

&lt;h2&gt;
  
  
  1. Overview: The Landscape of GPU-Accelerated Optimization
&lt;/h2&gt;

&lt;p&gt;"GPU-accelerated optimization algorithms" form a large family spanning multiple disciplines. Broadly speaking, they follow two lines of thinking. The first is &lt;strong&gt;algorithms that are naturally parallel&lt;/strong&gt;: in evolutionary algorithms every individual in the population can be evaluated independently; in Bayesian optimization thousands of candidate points can be scored in a batch; in motion planning hundreds of trajectories can be rolled out simultaneously. Such algorithms routinely gain one to several orders of magnitude on GPUs. The second line is &lt;strong&gt;algorithms redesigned for GPUs&lt;/strong&gt;: the most typical example is the shift in linear programming from the simplex method and interior-point methods (which depend on hard-to-parallelize sparse matrix factorization) toward the first-order PDHG/PDLP family (whose iteration core is just sparse matrix–vector products), which finally unlocks the bandwidth advantage of GPUs (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;). Representatives of the first line include EvoX, evosax, BoTorch, and cuRobo; representatives of the second include cuPDLP, cuOpt, ClarabelGPU, and cuLoRADS.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fsi3bzqs3g64bokb0l35j.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fsi3bzqs3g64bokb0l35j.png" alt=" " width="800" height="489"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;From an engineering perspective, the first step in selection is identifying which class of problem you face. For &lt;strong&gt;continuous differentiable&lt;/strong&gt; problems (deep learning training, nonlinear least squares), look first at optimizers inside deep learning frameworks and differentiable optimization libraries. For &lt;strong&gt;constrained continuous problems of enormous scale&lt;/strong&gt; (LP/QP/SDP), look at GPU first-order solvers. For &lt;strong&gt;discrete/combinatorial&lt;/strong&gt; problems (MILP, VRP, scheduling), GPUs currently play the role of heuristics and relaxation solvers, working best in hybrid combination with CPU branch-and-bound. For &lt;strong&gt;black-box, gradient-free&lt;/strong&gt; problems (hyperparameters, structural design, expensive-simulation optimization), look at GPU implementations of evolutionary computation and Bayesian optimization. Each of the following sections expands on these in turn.&lt;/p&gt;

&lt;h2&gt;
  
  
  2. Mathematical Programming and Operations Research Solvers
&lt;/h2&gt;

&lt;p&gt;Mathematical programming is the domain where GPU-ification has advanced fastest over the past two years and had the greatest industrial impact. The turning point came from Google's PDLP, proposed in 2021: LP is reformulated as a minimax saddle-point problem and solved with the primal-dual hybrid gradient method (PDHG) augmented by restarts, diagonal preconditioning, and adaptive step sizes, so the iteration core reduces to sparse matrix–vector products that are naturally suited to GPUs and distributed hardware (&lt;a href="https://arxiv.org/abs/2501.07018" rel="noopener noreferrer"&gt;Google Research&lt;/a&gt;). The work received the 2024 Beale–Orchard-Hays Prize, and its C++ implementation is open-sourced as part of OR-Tools (&lt;a href="https://kavourei.github.io/PDLP" rel="noopener noreferrer"&gt;Kavour&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.1 Linear Programming (LP): The PDHG/PDLP Family and cuOpt
&lt;/h3&gt;

&lt;p&gt;The academic pathbreaker for GPU-ified LP is &lt;strong&gt;cuPDLP.jl&lt;/strong&gt; (a Julia implementation) from Haihao Lu's group at MIT: on the LP relaxations of MIPLIB 2017, at medium accuracy (1e-4) it solves more instances than all CPU versions of PDLP and is comparable to Gurobi; on large instances with over ten million nonzeros it is &lt;strong&gt;3.7× faster&lt;/strong&gt; than Gurobi's best barrier method, and up to &lt;strong&gt;20× faster&lt;/strong&gt; than its own Julia CPU version (&lt;a href="https://arxiv.org/pdf/2311.12180" rel="noopener noreferrer"&gt;arXiv:2311.12180&lt;/a&gt;). It was followed by a C implementation, &lt;strong&gt;cuPDLP-C&lt;/strong&gt; (roughly another 50% faster), and by &lt;strong&gt;cuPDLP+&lt;/strong&gt;, which adopts restarted Halpern PDHG (rHPDHG) with reflection updates and PID-controlled primal-weight updates — a further &lt;strong&gt;2–4× speedup&lt;/strong&gt; over cuPDLP on MIPLIB LP relaxations (2.9× at high accuracy with presolve, 4.63× on hard instances) (&lt;a href="https://arxiv.org/html/2507.14051v1" rel="noopener noreferrer"&gt;arXiv:2507.14051&lt;/a&gt;). This line of work directly influenced the design of commercial and open-source solvers including Gurobi, COPT, FICO Xpress, and NVIDIA cuOpt (&lt;a href="https://www.emergentmind.com/topics/gpu-accelerated-pdlp" rel="noopener noreferrer"&gt;EmergentMind&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The industry benchmark is &lt;strong&gt;NVIDIA cuOpt&lt;/strong&gt;: open sourcing was announced in March 2025 in collaboration with the COIN-OR Foundation, and from June 2025 the complete LP/MIP/VRP solver source code has been released under the Apache 2.0 license (&lt;a href="https://developer.nvidia.com/blog/accelerate-decision-optimization-using-open-source-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;). On the Mittelmann LP benchmark (1e-4 tolerance), cuOpt's PDLP solver is faster than a top CPU LP solver on 60% of the instances where both converge, more than 10× faster on 20% of instances, and up to &lt;strong&gt;5,000×&lt;/strong&gt; on a single large multicommodity-flow instance; against CPU PDLP implementations it is consistently 10×–3,000× faster (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;). In October 2025 cuOpt added a &lt;strong&gt;GPU-accelerated barrier (interior-point) method&lt;/strong&gt;, which internal benchmarks show averaging more than 8× faster than a leading open-source CPU solver and more than 2× faster than a popular commercial CPU solver, filling the high-accuracy gap (&lt;a href="https://developer.nvidia.com/blog/solve-linear-programs-using-the-gpu-accelerated-barrier-method-in-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Among commercial solvers, &lt;strong&gt;Gurobi&lt;/strong&gt; has landed GPU support along two routes: its barrier method uses NVIDIA cuDSS for sparse linear-system solves, and its PDHG method uses cuSPARSE for sparse matrix–vector products with data resident in GPU memory throughout; Gurobi also cautions that GPU PDLP's advantage depends strongly on problem characteristics, and in its internal test set CPU solvers still win on the majority of instances (&lt;a href="https://www.gurobi.com/resources/blog/using-gpus-to-solve-lps-what-s-in-it-for-me" rel="noopener noreferrer"&gt;Gurobi&lt;/a&gt;). The Chinese solver &lt;strong&gt;COPT&lt;/strong&gt; (Shanshu Technology) open-sourced cuPDLP-C, and its GPU version COPTG performs strongly on third-party leaderboards (&lt;a href="https://arxiv.org/pdf/2506.02174" rel="noopener noreferrer"&gt;arXiv:2506.02174&lt;/a&gt;). Nothing illustrates the shifting landscape better than Hans Mittelmann's LPfeas leaderboard (data of 12 June 2026): the top three — COPTG (1.00), cuOpt 26.06 (1.07), HPRLP (1.36) — are all GPU solvers, ahead of CPU COPT (1.67), MOSEK (5.28), HiGHS (17.24), and PDLP (27.85); three of the top four entries are GPU-accelerated (&lt;a href="https://mattmilten.github.io/mittelmann-plots/" rel="noopener noreferrer"&gt;Mittelmann Plots&lt;/a&gt;, &lt;a href="https://plato.asu.edu/bench.html" rel="noopener noreferrer"&gt;ASU&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyw2xieqfgep9fpumee3s.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyw2xieqfgep9fpumee3s.png" alt=" " width="800" height="435"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Boundary conditions that should be stated honestly: PDLP-type methods &lt;strong&gt;scale linearly with memory bandwidth&lt;/strong&gt;, so reproducing the paper numbers requires relatively recent server-grade GPUs; on small LPs the GPU advantage is limited (which is why cuOpt offers a batch mode that solves hundreds of small LPs in parallel); and on the 49 public instances, 8 timed out due to slow convergence (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;). Gurobi's engineering advice is therefore "pick the algorithm by model characteristics" rather than blanket GPU-ification (&lt;a href="https://arxiv.org/pdf/2506.02174" rel="noopener noreferrer"&gt;arXiv:2506.02174&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.2 Quadratic Programming (QP) and Conic Programming (SOCP)
&lt;/h3&gt;

&lt;p&gt;GPU-ification of QP advances along two routes. One is first-order methods: restarted accelerated PDHG (rAPDHG) targets large-scale convex QP, and its successor &lt;strong&gt;PDHCG&lt;/strong&gt; (PDHG combined with conjugate gradients) is about 5× faster again than rAPDHG on specific large-scale tests and nearly two orders of magnitude faster than other solvers (&lt;a href="https://journal.hep.com.cn/fem/EN/10.1007/s42524-026-5153-z" rel="noopener noreferrer"&gt;Front. Eng. Mgmt.&lt;/a&gt;). The other route is &lt;strong&gt;moving the linear-system solves of interior-point methods onto the GPU&lt;/strong&gt;: ClarabelGPU, the GPU version of the open-source conic solver Clarabel, factorizes the KKT system with the NVIDIA cuDSS library, and on large QP benchmarks it is the fastest of all solvers tested — more than 2× faster than Gurobi, about 4× faster than MOSEK, and about 10× faster than its own multithreaded Rust CPU implementation (&lt;a href="https://arxiv.org/html/2412.19027v2" rel="noopener noreferrer"&gt;arXiv:2412.19027&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;These two routes correspond to the "factorization-free, bandwidth-hungry" and "GPU-accelerated factorization" paradigms respectively, and they also foreshadow the GPU-ification path for more general conic programs such as SOCP and SDP. cuOpt has listed QCQP and SOCP support in beta (&lt;a href="https://github.com/NVIDIA/cuopt" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;). For engineering users, if you already model with CVXPY, both cuOpt and ClarabelGPU can be swapped in as backends at very low migration cost (&lt;a href="https://www.nvidia.com/en-us/ai-data-science/products/cuopt/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.3 Semidefinite Programming (SDP): cuLoRADS
&lt;/h3&gt;

&lt;p&gt;SDP has long been bottlenecked by the factorization of huge matrix variables inside interior-point methods. &lt;strong&gt;cuLoRADS&lt;/strong&gt; (open-sourced by the COPT team at Shanshu Technology) ports a two-stage algorithm — Burer–Monteiro low-rank factorization with an augmented-Lagrangian warm start followed by ADMM splitting — wholesale onto the GPU, using custom kernels and compressed storage exploiting the column sparsity of the constraint matrices to cut quadratic memory overhead down to something proportional to the number of nonzeros (&lt;a href="https://arxiv.org/html/2407.15049v2" rel="noopener noreferrer"&gt;arXiv:2407.15049&lt;/a&gt;). Its reported numbers are striking: on an H100 it solves MaxCut instances with 10⁷×10⁷ matrix variables in just 10–60 seconds each, whereas previous CPU solvers needed at least tens of hours for the same scale; a MaxCut with a 170M×170M matrix variable and 170 million constraints is solved in 160 seconds; on matrix-completion problems it is over 100× faster than the CPU version of LoRADS, and can solve a problem with an 8-million×8-million matrix variable and 320 million constraints in about 89 seconds — in the same time the CPU version can only handle 20,000×20,000 (&lt;a href="https://arxiv.org/html/2407.15049v2" rel="noopener noreferrer"&gt;arXiv:2407.15049&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;On Mittelmann's sparse SDP leaderboard, cuLoRADS 1.0.0 already ranks second (score 3.01, behind only CPU COPT at 1.00, ahead of MOSEK at 3.67), making it the only GPU SDP solver currently in the leaderboard's top tier (&lt;a href="https://mattmilten.github.io/mittelmann-plots/" rel="noopener noreferrer"&gt;Mittelmann Plots&lt;/a&gt;). Its limitations are that it does not yet support mixed problems containing linear variables, and robustness on general SDPs is still being improved (&lt;a href="https://github.com/COPT-Public/cuLoRADS" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;).&lt;/p&gt;

&lt;h3&gt;
  
  
  2.4 Mixed-Integer Programming (MILP), Combinatorial Optimization, and Vehicle Routing (VRP)
&lt;/h3&gt;

&lt;p&gt;MILP is the hardest nut for GPU-ification: in branch-and-bound trees the LP subproblems at different nodes vary enormously in size and structure, and the highly irregular workload is a poor fit for the GPU's SIMT model (&lt;a href="https://journal.hep.com.cn/fem/EN/10.1007/s42524-026-5153-z" rel="noopener noreferrer"&gt;Front. Eng. Mgmt.&lt;/a&gt;). The currently viable paradigm is a &lt;strong&gt;hybrid architecture&lt;/strong&gt;: the GPU runs massively parallel heuristics (to find high-quality feasible solutions quickly), while CPU branch-and-bound uses those solutions to prune the tree. This is exactly the idea behind NVIDIA cuOpt's MIP beta — GPU-accelerated primal heuristics (including three evolutionary algorithms, stagnation detection, subMIP evolution, and diving threads with branch-and-bound) rapidly produce feasible solutions, and it has even found new solutions for four open instances in MIPLIB (&lt;a href="https://alphasignal.ai/news/nvidia-s-cuopt-beats-every-open-source-solver-with-5000x-gpu-speedup" rel="noopener noreferrer"&gt;AlphaSignal&lt;/a&gt;). In a commercial case study, SimpleRose combined its parallel MIP solver with cuOpt (cuOpt provides heuristic solutions, Rose prunes in parallel), accelerating overall MILP solve time by up to &lt;strong&gt;61.7×&lt;/strong&gt; and the root LP by up to 50.2× (&lt;a href="https://simplerose.com/blog/how-simplerose-and-nvidia-cuopt-solve-lp-and-milp-problems-faster/" rel="noopener noreferrer"&gt;SimpleRose&lt;/a&gt;); combining HiGHS with cuOpt cut the MIP gap from 28% to 21% on one problem class (&lt;a href="https://alphasignal.ai/news/nvidia-s-cuopt-beats-every-open-source-solver-with-5000x-gpu-speedup" rel="noopener noreferrer"&gt;AlphaSignal&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;VRP and routing optimization is cuOpt's most mature commercial module. By combining GPU-accelerated heuristics with evolutionary strategies, as of March 2024 it had broken world records on 15 instances of the Gehring &amp;amp; Homberger benchmark and 8 instances of the Li &amp;amp; Lim benchmark, and it has held all records in the CVRPTW and PDPTW categories for three consecutive years; NVIDIA claims routing solutions up to 100× faster (&lt;a href="https://developer.nvidia.com/blog/record-breaking-nvidia-cuopt-algorithms-deliver-route-optimization-solutions-100x-faster/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;). Practical deployments include: a 10,000-node VRP with real-world constraints solved on a single GPU in about 30 seconds; large-scale power unit commitment accelerated by up to 20×; and o9 Solutions achieving more than 10× planning speedup on production supply-chain data, turning "overnight batch processing" into "minute-level on-demand solving" (&lt;a href="https://simplerose.com/rosecuopt/" rel="noopener noreferrer"&gt;SimpleRose&lt;/a&gt;, &lt;a href="https://apnews.com/press-release/business-wire/press-release-ffd3d7ed1fc748fdaecee925a2db5a78" rel="noopener noreferrer"&gt;AP News&lt;/a&gt;).&lt;/p&gt;

&lt;h2&gt;
  
  
  3. Deep Learning Training Optimizers
&lt;/h2&gt;

&lt;p&gt;Deep learning is the most mature market for GPU optimization algorithms. "GPU acceleration" here operates at three levels: the &lt;strong&gt;implementation layer&lt;/strong&gt; (fusing optimizer updates into CUDA kernels), the &lt;strong&gt;memory layer&lt;/strong&gt; (low-bit/low-rank optimizer states so larger models fit in GPU memory), and the &lt;strong&gt;algorithm layer&lt;/strong&gt; (new optimizers designed for GPU matrix compute).&lt;/p&gt;

&lt;h3&gt;
  
  
  3.1 Implementation Layer: Fused and Multi-Tensor Kernels
&lt;/h3&gt;

&lt;p&gt;PyTorch provides &lt;code&gt;foreach&lt;/code&gt; (horizontal fusion across multiple tensors) and &lt;code&gt;fused&lt;/code&gt; (vertical fusion into a single CUDA kernel) implementations for Adam/AdamW/SGD and others. The principle is that multi-tensor-apply combines pointer management, memory alignment, vectorization, and the Adam math into one kernel, significantly reducing kernel-launch overhead and memory round-trips; this is the de facto default for large-scale training (&lt;a href="https://christianjmills.com/posts/cuda-mode-notes/lecture-006/" rel="noopener noreferrer"&gt;GPU MODE&lt;/a&gt;). There is also the more advanced trick of "fusing the optimizer into backpropagation": using &lt;code&gt;register_post_accumulate_grad_hook&lt;/code&gt; to apply the update as soon as each parameter's gradient is ready, eliminating the persistent gradient tensor — an official PyTorch tutorial claims this can be done in 10 lines of code (&lt;a href="https://pytorch-cn.com/tutorials/intermediate/optimizer_step_in_backward_tutorial.html" rel="noopener noreferrer"&gt;PyTorch&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;These tricks do not change the optimizer's mathematical behavior, only constant factors, typically delivering single-digit to two-digit percentage speedups — but they are risk-free and tuning-free, and should be the baseline configuration for any GPU training task. In the JAX ecosystem the equivalents are Optax combinators and &lt;code&gt;jax.jit&lt;/code&gt; XLA fusion, with similar effects.&lt;/p&gt;

&lt;h3&gt;
  
  
  3.2 Memory Layer: Low-Bit and Low-Rank Optimizers
&lt;/h3&gt;

&lt;p&gt;Adam maintains two 32-bit states (first and second moments) per parameter, so optimizer memory often dominates training memory. &lt;strong&gt;bitsandbytes' 8-bit optimizers&lt;/strong&gt; (the full family: Adam8bit/AdamW8bit/Lion8bit and more) use block-wise dynamic quantization to store states in 8 bits, dequantizing to FP32 for the update and re-quantizing each step, saving roughly &lt;strong&gt;75%&lt;/strong&gt; of optimizer memory with negligible accuracy loss; this is the quantization backend for Hugging Face Transformers/PEFT/Diffusers (&lt;a href="https://github.com/bitsandbytes-foundation/bitsandbytes" rel="noopener noreferrer"&gt;bitsandbytes&lt;/a&gt;, &lt;a href="https://leeroopedia.com/index.php/Principle:Bitsandbytes_foundation_Bitsandbytes_8bit_Adam_Optimizer" rel="noopener noreferrer"&gt;Leeroopedia&lt;/a&gt;). Paged variants can additionally swap states out to CPU automatically when GPU memory runs low.&lt;/p&gt;

&lt;p&gt;Another route is structural rank reduction: &lt;strong&gt;GaLore&lt;/strong&gt; projects gradients onto a low-rank subspace before feeding them to Adam; GaLore 2 further combines low-bit projection matrices with deep FSDP sharding integration, substantially reducing per-GPU memory for Llama-3-class models on 2 GPUs (&lt;a href="https://arxiv.org/html/2504.20437v1" rel="noopener noreferrer"&gt;arXiv:2504.20437&lt;/a&gt;). Adafactor (row/column factorization of second moments) and DeepSpeed ZeRO's optimizer-state sharding with CPU offload are system-level approaches: ZeRO-Offload moves optimizer computation to the CPU (using AVX instructions) in exchange for memory (&lt;a href="https://arxiv.org/pdf/2209.00099v1.pdf" rel="noopener noreferrer"&gt;arXiv:2209.00099&lt;/a&gt;). The engineering rule of thumb: if memory is tight, start with 8-bit Adam (almost lossless); if still insufficient, add GaLore/FSDP sharding; ZeRO-Offload is the last resort (with obvious throughput loss).&lt;/p&gt;

&lt;h3&gt;
  
  
  3.3 Algorithm Layer: A New Generation of GPU-Born Optimizers
&lt;/h3&gt;

&lt;p&gt;Over the past two years a batch of "matrix-aware" methods has emerged in LLM pretraining optimizers, sharing a common idea: trade GPU-friendly dense matrix operations for fewer training steps. &lt;strong&gt;Muon&lt;/strong&gt; (proposed by Keller Jordan) orthogonalizes the momentum of hidden-layer 2D weight matrices via Newton–Schulz iteration; it maintains only momentum (no second moments, halving state memory), and achieves roughly 30–50% wall-clock advantage over AdamW in the NanoGPT speedrun and Karpathy's nanochat, i.e. about 2× compute efficiency (&lt;a href="https://grokipedia.com/page/muon-optimizer" rel="noopener noreferrer"&gt;Grokipedia&lt;/a&gt;). Muon has been integrated into NVIDIA Megatron Core, and through layered distributed optimization and distributed Newton–Schulz iteration achieves throughput on GB300 nearly on par with AdamW (&lt;a href="https://developer.nvidia.com/blog/advancing-emerging-optimizers-for-accelerated-llm-training-with-nvidia-megatron/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;); Turbo-Muon further accelerates the orthogonalization subroutine itself by 2.8× (Triton fused kernels + AOL preconditioning), cutting per-step time on a 1.3B model by about 8–10% (&lt;a href="https://www.emergentmind.com/topics/turbo-muon-preconditioning" rel="noopener noreferrer"&gt;EmergentMind&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;In the second-order and full-matrix preconditioning direction, &lt;strong&gt;Sophia&lt;/strong&gt; (a lightweight second-order optimizer using diagonal Hessian estimates with element-wise clipping) reports roughly 2× speedup over Adam in steps, compute, and wall-clock; however, independent reproductions by Fraunhofer IIS show that although Sophia achieves the lowest training and validation loss, Lion is fastest in GPU-hours and AdamW scores best on downstream evaluation — demonstrating that "new optimizers are faster" depends heavily on the evaluation protocol (&lt;a href="https://www.facebook.com/groups/DeepNetGroup/posts/2006256899767182/" rel="noopener noreferrer"&gt;Facebook/DeepNet&lt;/a&gt;, &lt;a href="https://arxiv.org/pdf/2507.08472" rel="noopener noreferrer"&gt;arXiv:2507.08472&lt;/a&gt;). The &lt;strong&gt;Shampoo/SOAP&lt;/strong&gt; family trades full-matrix preconditioning for stronger per-step progress: distributed Shampoo's per-step overhead, amortized across multiple GPUs, is typically only about 10% higher than Adam (&lt;a href="https://www.emergentmind.com/topics/shampoo-family-of-algorithms" rel="noopener noreferrer"&gt;EmergentMind&lt;/a&gt;); NVIDIA's large-scale pretraining study shows both SOAP and Muon consistently beat AdamW and scale to larger batch sizes, recommending KL-SOAP when memory is not tight (&lt;a href="https://arxiv.org/html/2607.20548v1" rel="noopener noreferrer"&gt;arXiv:2607.20548&lt;/a&gt;). Lion (a sign-momentum optimizer discovered by Google through evolutionary search) needs only one state tensor and suits memory-constrained scenarios where hyperparameter tuning is acceptable (&lt;a href="https://web3.arxiv.org/pdf/2312.03863v3" rel="noopener noreferrer"&gt;arXiv:2312.03863&lt;/a&gt;).&lt;/p&gt;

&lt;h2&gt;
  
  
  4. Evolutionary Computation and Swarm Intelligence
&lt;/h2&gt;

&lt;p&gt;Evolutionary algorithms (EAs) are naturally GPU-friendly: fitness evaluation of every individual in the population is fully independent, and crossover and mutation can also be vectorized. The bottleneck has historically been software frameworks rather than the algorithms — traditional Python EA libraries (such as DEAP) are CPU-serial. A new generation of GPU frameworks fills this gap: &lt;strong&gt;EvoX&lt;/strong&gt; (EMI Group) is built on PyTorch and ships 50+ algorithms including GA, DE, PSO, CMA-ES, NSGA-II/RVEA/MOEA/D together with 100+ benchmark problems; it officially claims &lt;strong&gt;100×+&lt;/strong&gt; acceleration on heterogeneous hardware, supports distributed multi-node execution, and interfaces with the Brax physics engine for evolutionary reinforcement learning (&lt;a href="https://www.evox.group/releases/evox-1-0-0/" rel="noopener noreferrer"&gt;EvoX&lt;/a&gt;, &lt;a href="https://github.com/EMI-Group/evox" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;). On the JAX side there is &lt;strong&gt;evosax&lt;/strong&gt; (focused on evolution strategies, a GPU-optimized collection of ES algorithms) and &lt;strong&gt;EvoJAX&lt;/strong&gt; (oriented toward neuroevolution); on the PyTorch side there is also &lt;strong&gt;EvoTorch&lt;/strong&gt; (&lt;a href="https://arxiv.org/html/2412.20980v1" rel="noopener noreferrer"&gt;arXiv:2412.20980&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;Academic evaluations highlight an important fact: different EAs gain very differently on GPUs — parallel granularity (individual-level vs gene-level), problem dimension, and the computational intensity of the fitness function determine the speedup, which cannot be summarized by a single number (&lt;a href="https://arxiv.org/html/2601.18446v1" rel="noopener noreferrer"&gt;arXiv:2601.18446&lt;/a&gt;). Practical experience says: the heavier the fitness evaluation itself (e.g., neuroevolution, simulation rollouts), the greater the GPU benefit; on pure numerical benchmark functions, GPUs can actually lose to CPUs at small population sizes due to kernel-launch overhead, and populations of thousands or more are needed to saturate the GPU. The non-dominated sorting step of multi-objective algorithms is highly irregular and harder to GPU-ify than single-objective ones; EvoX handles such problems through a unified tensorized programming model (&lt;a href="https://arxiv.org/html/2609.02387v1" rel="noopener noreferrer"&gt;arXiv:2609.02387&lt;/a&gt;).&lt;/p&gt;

&lt;h2&gt;
  
  
  5. Bayesian Optimization and Hyperparameter Search
&lt;/h2&gt;

&lt;p&gt;GPU-ification of Bayesian optimization (BO) shows up in two ways: Gaussian-process (GP) matrix computations on the GPU, and &lt;strong&gt;batched parallel evaluation&lt;/strong&gt; of the acquisition function over tens of thousands of candidate points. Meta's &lt;strong&gt;BoTorch&lt;/strong&gt; (built on GPyTorch) supports batch evaluation in all components; increasing the number of Monte Carlo samples of the acquisition function has little impact on wall-clock time, and the official appendix reports significant GPU speedups; multi-objective acquisition functions (qLogNEHVI and others) can be solved efficiently in practical scenarios thanks to automatic differentiation and GPU acceleration (&lt;a href="https://proceedings.neurips.cc/paper/2020/file/f5b1b89d98b7286673128a5fb112cb9a-Supplemental.pdf" rel="noopener noreferrer"&gt;NeurIPS&lt;/a&gt;, &lt;a href="https://botorch.org/docs/multi_objective" rel="noopener noreferrer"&gt;BoTorch&lt;/a&gt;). Trust-region variants for high-dimensional problems, TuRBO/FuRBO, also run on GPUs and suit expensive-simulation optimization (CFD, chip design).&lt;/p&gt;

&lt;p&gt;In hyperparameter optimization (HPO), &lt;strong&gt;Optuna&lt;/strong&gt;'s TPE sampler with pruning algorithms is the mainstream choice for single machines and small clusters, scalable to thousands of workers through a shared database backend (&lt;a href="https://laboak.com/a-comprehensive-guide-to-optuna-next-generation-hyperparameter-optimization/" rel="noopener noreferrer"&gt;LabOak&lt;/a&gt;); &lt;strong&gt;Ray Tune&lt;/strong&gt; targets parallel trial scheduling on GPU clusters, integrating search algorithms such as Optuna/HyperOpt with early-stopping schedulers such as ASHA/HyperBand/PBT. Industry practice shows that ASHA early stopping can cut total GPU compute cost of HPO by 70–80% without accuracy loss, roughly a 5–10× compute saving over grid/random search (&lt;a href="https://www.swfte.com/ko/blog/ray-tune-hyperparameter-tuning-guide" rel="noopener noreferrer"&gt;Swfte&lt;/a&gt;, &lt;a href="https://mljourney.com/hyperparameter-tuning-with-optuna-vs-ray-tune/" rel="noopener noreferrer"&gt;ML Journey&lt;/a&gt;). Selection advice: for a single machine with flexibility as priority, use Optuna; for multi-machine multi-GPU setups with fault tolerance and productionization as priorities, use Ray Tune (&lt;a href="https://mljourney.com/hyperparameter-tuning-with-optuna-vs-ray-tune/" rel="noopener noreferrer"&gt;ML Journey&lt;/a&gt;).&lt;/p&gt;

&lt;h2&gt;
  
  
  6. Robot Motion Planning and Differentiable Nonlinear Optimization
&lt;/h2&gt;

&lt;p&gt;The flagship in robotics is NVIDIA &lt;strong&gt;cuRobo&lt;/strong&gt;: collision-free minimum-jerk trajectory generation for robot arms is formulated as a global optimization problem, solved by a combination of particle-sampling exploration, L-BFGS gradient refinement, and parallel noisy line search, optimizing hundreds of trajectories simultaneously on the GPU. The official paper reports solving hard motion-generation problems within an average of 50 ms — &lt;strong&gt;60× faster&lt;/strong&gt; than SOTA trajectory-optimization methods — with collision-free IK solved over &lt;strong&gt;7,000 times per second&lt;/strong&gt; (80× faster than common libraries), and on the embedded Jetson Orin NX platform it processes 512 trajectories × 64 steps in parallel at 500 Hz (&lt;a href="https://huggingface.co/papers?q=training-free%20acceleration%20framework" rel="noopener noreferrer"&gt;Hugging Face&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2508.04146" rel="noopener noreferrer"&gt;arXiv:2508.04146&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The more general tool is Meta's &lt;strong&gt;Theseus&lt;/strong&gt;: a differentiable nonlinear least-squares library built on PyTorch, providing second-order optimizers such as Gauss–Newton, Levenberg–Marquardt, and Dogleg, with built-in batching, automatic vectorization, GPU sparse solvers (including its self-developed batched sparse Cholesky solver Baspacho), and support for implicit differentiation that embeds the entire optimization process into a neural network for end-to-end learning (&lt;a href="https://proceedings.neurips.cc/paper_files/paper/2022/file/185969291540b3cd86e70c51e8af5d08-Paper-Conference.pdf" rel="noopener noreferrer"&gt;NeurIPS 2022&lt;/a&gt;). The two represent "domain-specific parallel global optimization" and "general-purpose differentiable optimization infrastructure" respectively: the former is ready out of the box for motion planning, the latter suits scenarios like SLAM, pose-graph optimization, and inverse dynamics where optimization must be a layer inside a network.&lt;/p&gt;

&lt;h2&gt;
  
  
  7. Quantum-Inspired and Annealing Optimization
&lt;/h2&gt;

&lt;p&gt;Combinatorial optimization in QUBO/Ising form has spawned a family of "physics-inspired" solvers, several offering GPU implementations: Fujitsu's &lt;strong&gt;Digital Annealer&lt;/strong&gt; (improved simulated annealing with parallel trial moves and dynamic escape, on digital CMOS hardware, with CPU/GPU software modes; about two orders of magnitude faster than single-core SA on fully connected spin glasses, though with no advantage on sparse graphs) (&lt;a href="https://www.frontiersin.org/journals/physics/articles/10.3389/fphy.2019.00048/full" rel="noopener noreferrer"&gt;Frontiers&lt;/a&gt;); Toshiba's &lt;strong&gt;Simulated Bifurcation Machine&lt;/strong&gt; (CPU/GPU/FPGA supported); and the pure-GPU route of Compal's &lt;strong&gt;Quantix GPUA&lt;/strong&gt; (multi-body adaptive search) (&lt;a href="https://arxiv.org/pdf/2509.09862" rel="noopener noreferrer"&gt;arXiv:2509.09862&lt;/a&gt;). Cross-annealer benchmark studies show: on classic problems like Max-Cut, TSP, and job-shop scheduling, GPU annealers match Fujitsu's DA in solution quality with wins on both sides, but on many small and medium instances well-tuned classical algorithms (such as OR-Tools) actually have the shortest solve times — the annealers' advantage lies mainly in extremely large, fully connected QUBOs (&lt;a href="https://inspirehep.net/files/4fe80467349063e47992a429c236f2e6" rel="noopener noreferrer"&gt;IEEE/InspireHEP&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2507.22117v1" rel="noopener noreferrer"&gt;arXiv:2507.22117&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;The lesson for engineering users: if your problem maps cleanly onto a large-scale QUBO and classical solvers are already struggling, GPU annealing/bifurcation methods are worth trying as a complement; otherwise the mature mathematical-programming route (GPU LP relaxations + heuristics + CPU branch-and-bound) is usually more controllable and easier to integrate.&lt;/p&gt;

&lt;h2&gt;
  
  
  8. Speedup Overview and Boundary Conditions
&lt;/h2&gt;

&lt;p&gt;Placing the public figures of each domain on one chart makes the "order-of-magnitude distribution" of GPU acceleration immediately visible: in any domain whose bottleneck can be restructured as massively parallel regular computation (first-order LP methods, low-rank ADMM for SDP, evolutionary evaluation, trajectory sampling), speedups reach the 10²–10³ range; in domains where algorithms are already highly optimized and the GPU only contributes a constant-factor improvement (deep learning optimizers, QP interior points), typical gains are 2–10×. Note that the bars in the figure below come from mutually incomparable measurement setups (different hardware, different accuracy tolerances, different baselines); they are for perceiving magnitudes only, not for direct cross-comparison (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;, &lt;a href="https://arxiv.org/html/2407.15049v2" rel="noopener noreferrer"&gt;arXiv:2407.15049&lt;/a&gt;, &lt;a href="https://www.evox.group/releases/evox-1-0-0/" rel="noopener noreferrer"&gt;EvoX&lt;/a&gt;).&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fqwazwp4lgrq08a51qr4o.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fqwazwp4lgrq08a51qr4o.png" alt=" " width="800" height="476"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Typical situations where GPU acceleration fails or its benefit shrinks include: problems that are too small (kernel-launch and PCIe transfer overheads outweigh parallel gains — this is why cuOpt provides a small-LP batch mode); requirements for 1e-8-level high accuracy (first-order methods converge slowly, and GPU barrier/interior-point methods are more appropriate here); irregular tree search like branch-and-bound (hard for GPUs to schedule efficiently); and problems that do not fit in GPU memory (in the PDLP paper, some very large instances exceed single-GPU memory and can only be handled by large-memory CPU machines) (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA Developer&lt;/a&gt;, &lt;a href="https://arxiv.org/abs/2501.07018" rel="noopener noreferrer"&gt;arXiv:2501.07018&lt;/a&gt;). Before selecting, it is advisable to run a small-scale benchmark on your own 3–5 most representative instances rather than taking vendor numbers at face value.&lt;/p&gt;

&lt;h2&gt;
  
  
  9. Engineering Selection Table
&lt;/h2&gt;

&lt;p&gt;The table below aggregates the main GPU optimization tools covered in this report by problem type, together with their key attributes, for quick reference. Licenses and feature status are as of mid-2026; please check each project's latest documentation before deployment.&lt;/p&gt;

&lt;div class="table-wrapper-paragraph"&gt;&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Problem Type&lt;/th&gt;
&lt;th&gt;Representative Tools&lt;/th&gt;
&lt;th&gt;Core Algorithm&lt;/th&gt;
&lt;th&gt;Hardware/Ecosystem&lt;/th&gt;
&lt;th&gt;Representative Public Performance&lt;/th&gt;
&lt;th&gt;License&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Large-scale LP&lt;/td&gt;
&lt;td&gt;NVIDIA cuOpt (&lt;a href="https://github.com/NVIDIA/cuopt" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;PDLP (PDHG) + GPU barrier&lt;/td&gt;
&lt;td&gt;CUDA; Python/C/Server APIs; plugs into CVXPY/PuLP/AMPL&lt;/td&gt;
&lt;td&gt;#2 on Mittelmann LPfeas (1.07); up to 5,000× on a single instance (&lt;a href="https://developer.nvidia.com/blog/accelerate-large-linear-programming-problems-with-nvidia-cuopt/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Apache 2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Large-scale LP&lt;/td&gt;
&lt;td&gt;cuPDLP.jl / cuPDLP-C / cuPDLP+ (&lt;a href="https://arxiv.org/html/2507.14051v1" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Restarted (Halpern) PDHG&lt;/td&gt;
&lt;td&gt;Julia/C + CUDA; research-friendly&lt;/td&gt;
&lt;td&gt;3.7× vs Gurobi barrier on large LP; cuPDLP+ another 2–4× (&lt;a href="https://arxiv.org/pdf/2311.12180" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Open source&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;LP (commercial)&lt;/td&gt;
&lt;td&gt;COPT GPU / Gurobi GPU (&lt;a href="https://www.gurobi.com/resources/blog/using-gpus-to-solve-lps-what-s-in-it-for-me" rel="noopener noreferrer"&gt;Gurobi&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;GPU PDHG / cuDSS barrier&lt;/td&gt;
&lt;td&gt;Commercial solver + CUDA&lt;/td&gt;
&lt;td&gt;COPTG tops LPfeas (1.00) (&lt;a href="https://mattmilten.github.io/mittelmann-plots/" rel="noopener noreferrer"&gt;Mittelmann&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Commercial&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;QP / SOCP&lt;/td&gt;
&lt;td&gt;ClarabelGPU (&lt;a href="https://arxiv.org/html/2412.19027v2" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;); cuOpt QP (beta)&lt;/td&gt;
&lt;td&gt;Interior point + cuDSS / PDHG family&lt;/td&gt;
&lt;td&gt;Rust/CUDA; CVXPY backend&lt;/td&gt;
&lt;td&gt;2×+ faster than Gurobi, ~4× faster than MOSEK on large QP&lt;/td&gt;
&lt;td&gt;MIT / Apache 2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;SDP&lt;/td&gt;
&lt;td&gt;cuLoRADS (&lt;a href="https://github.com/COPT-Public/cuLoRADS" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Low-rank Burer–Monteiro + ALM/ADMM&lt;/td&gt;
&lt;td&gt;Julia/CUDA&lt;/td&gt;
&lt;td&gt;10⁷-scale MaxCut in 10–60 s; 100×+ vs CPU&lt;/td&gt;
&lt;td&gt;Open source&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;MILP&lt;/td&gt;
&lt;td&gt;cuOpt MIP (beta); Rose+cuOpt (&lt;a href="https://simplerose.com/blog/how-simplerose-and-nvidia-cuopt-solve-lp-and-milp-problems-faster/" rel="noopener noreferrer"&gt;SimpleRose&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;GPU primal heuristics + CPU B&amp;amp;B hybrid&lt;/td&gt;
&lt;td&gt;CUDA; composable with HiGHS etc.&lt;/td&gt;
&lt;td&gt;Up to 61.7× overall MILP (hybrid scheme)&lt;/td&gt;
&lt;td&gt;Apache 2.0 / Commercial&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;VRP / Routing&lt;/td&gt;
&lt;td&gt;cuOpt Routing (&lt;a href="https://developer.nvidia.com/blog/record-breaking-nvidia-cuopt-algorithms-deliver-route-optimization-solutions-100x-faster/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;GPU heuristics + evolutionary strategy&lt;/td&gt;
&lt;td&gt;CUDA; Python/REST&lt;/td&gt;
&lt;td&gt;23 world records; 10k-node VRP in ~30 s&lt;/td&gt;
&lt;td&gt;Apache 2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DL training (general)&lt;/td&gt;
&lt;td&gt;fused AdamW / torch.compile (&lt;a href="https://christianjmills.com/posts/cuda-mode-notes/lecture-006/" rel="noopener noreferrer"&gt;GPU MODE&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Fused kernels&lt;/td&gt;
&lt;td&gt;Built into PyTorch/JAX&lt;/td&gt;
&lt;td&gt;Constant-factor speedup; risk-free baseline&lt;/td&gt;
&lt;td&gt;Open source&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DL training (memory-saving)&lt;/td&gt;
&lt;td&gt;bitsandbytes 8-bit; GaLore 2 (&lt;a href="https://arxiv.org/html/2504.20437v1" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Block-wise quantization / low-rank gradient projection&lt;/td&gt;
&lt;td&gt;PyTorch; HF ecosystem default&lt;/td&gt;
&lt;td&gt;−75% optimizer memory&lt;/td&gt;
&lt;td&gt;MIT&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;DL training (new algorithms)&lt;/td&gt;
&lt;td&gt;Muon / KL-SOAP / Sophia / Lion (&lt;a href="https://developer.nvidia.com/blog/advancing-emerging-optimizers-for-accelerated-llm-training-with-nvidia-megatron/" rel="noopener noreferrer"&gt;NVIDIA&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Matrix orthogonalization / full-matrix preconditioning / diagonal second-order&lt;/td&gt;
&lt;td&gt;Megatron Core, pytorch-optimizer&lt;/td&gt;
&lt;td&gt;~1.5–2× compute efficiency vs AdamW (protocol-dependent)&lt;/td&gt;
&lt;td&gt;Open source&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Evolutionary / Swarm&lt;/td&gt;
&lt;td&gt;EvoX (&lt;a href="https://github.com/EMI-Group/evox" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;); evosax&lt;/td&gt;
&lt;td&gt;GA/DE/PSO/CMA-ES/NSGA-II fully tensorized&lt;/td&gt;
&lt;td&gt;PyTorch / JAX + GPU&lt;/td&gt;
&lt;td&gt;Officially claimed 100×+; 50+ algorithms&lt;/td&gt;
&lt;td&gt;Open source&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Bayesian optimization&lt;/td&gt;
&lt;td&gt;BoTorch + GPyTorch (&lt;a href="https://botorch.org/docs/multi_objective" rel="noopener noreferrer"&gt;BoTorch&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;GP + batched MC acquisition evaluation&lt;/td&gt;
&lt;td&gt;PyTorch GPU&lt;/td&gt;
&lt;td&gt;Significant batched/multi-objective acceleration&lt;/td&gt;
&lt;td&gt;MIT&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Hyperparameter search&lt;/td&gt;
&lt;td&gt;Optuna / Ray Tune (&lt;a href="https://mljourney.com/hyperparameter-tuning-with-optuna-vs-ray-tune/" rel="noopener noreferrer"&gt;ML Journey&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;TPE + ASHA/PBT early stopping&lt;/td&gt;
&lt;td&gt;Single machine → GPU cluster&lt;/td&gt;
&lt;td&gt;Early stopping saves 70–80% GPU compute&lt;/td&gt;
&lt;td&gt;MIT / Apache 2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Robot planning&lt;/td&gt;
&lt;td&gt;cuRobo (&lt;a href="https://arxiv.org/html/2508.04146" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Particle optimization + parallel L-BFGS&lt;/td&gt;
&lt;td&gt;CUDA; ROS2 interface&lt;/td&gt;
&lt;td&gt;60× vs CPU planners; IK at 7,000 queries/s&lt;/td&gt;
&lt;td&gt;Apache 2.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Differentiable NLS&lt;/td&gt;
&lt;td&gt;Theseus (&lt;a href="https://proceedings.neurips.cc/paper_files/paper/2022/file/185969291540b3cd86e70c51e8af5d08-Paper-Conference.pdf" rel="noopener noreferrer"&gt;NeurIPS&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Gauss–Newton / LM / Dogleg + batched sparse Cholesky&lt;/td&gt;
&lt;td&gt;PyTorch GPU&lt;/td&gt;
&lt;td&gt;Significant batched-vectorization speedup&lt;/td&gt;
&lt;td&gt;MIT&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;QUBO / Annealing&lt;/td&gt;
&lt;td&gt;Fujitsu DA / Toshiba SBM / Quantix GPUA (&lt;a href="https://arxiv.org/pdf/2509.09862" rel="noopener noreferrer"&gt;arXiv&lt;/a&gt;)&lt;/td&gt;
&lt;td&gt;Parallel simulated annealing / simulated bifurcation&lt;/td&gt;
&lt;td&gt;Dedicated hardware / GPU&lt;/td&gt;
&lt;td&gt;~100× vs single-core SA on fully connected spin glass&lt;/td&gt;
&lt;td&gt;Mostly commercial&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;&lt;/div&gt;

&lt;h2&gt;
  
  
  10. Conclusion
&lt;/h2&gt;

&lt;p&gt;The landscape of GPU-accelerated optimization algorithms can be summed up in one sentence: &lt;strong&gt;rewriting an optimization problem into a "massively parallel + bandwidth-friendly" form usually pays far more than simply porting an existing algorithm&lt;/strong&gt;. In mathematical programming, the paradigm replacement of simplex/interior-point methods by PDHG first-order methods is the most profound change, and cuOpt, COPT GPU, and cuLoRADS have already surpassed traditional CPU commercial solvers on authoritative leaderboards. In deep learning, fused kernels and 8-bit states are "free lunches" that must be taken, while matrix-aware optimizers like Muon/SOAP represent the next wave of algorithm-level dividends. Evolutionary computation, Bayesian optimization, and robot planning gain order-of-magnitude improvements from their naturally batched parallel structure. For engineering deployment, three principles apply: first, use the selection table to lock in one or two candidate tools by problem type; second, benchmark on your own instances under real accuracy requirements; third, keep CPU options as a fallback for small-scale, high-precision, or branch-heavy problems — the hybrid architecture (GPU for speed, CPU for accuracy and global certificates) will remain the most robust deployment form for the foreseeable few years.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Note: This report is a general technical survey. All cited speedups come from public tests conducted by their respective sources, with varying measurement setups and hardware environments, and do not constitute a guarantee of product selection or commercial advice.&lt;/p&gt;
&lt;/blockquote&gt;

</description>
      <category>optimization</category>
      <category>gpu</category>
      <category>machinelearning</category>
      <category>programming</category>
    </item>
  </channel>
</rss>
