Combinatorial optimization problems arise in logistics, scheduling, and resource allocation, yet existing approaches face a fundamental trade-off among generality, performance, and usability. We present cuGenOpt, a GPU-accelerated general-purpose metaheuristic framework that addresses all three dimensions simultaneously. At the engine level, cuGenOpt adopts a "one block evolves one solution" CUDA architecture with a unified encoding abstraction (permutation, binary, integer), a two-level adaptive operator selection mechanism, and hardware-aware resource management. At the extensibility level, a user-defined operator registration interface allows domain experts to inject problem-specific CUDA search operators. At the usability level, a JIT compilation pipeline exposes the framework as a pure-Python API, and an LLM-based modeling assistant converts natural-language problem descriptions into executable solver code. Experiments across five thematic suites on three GPU architectures (T4, V100, A800) show that cuGenOpt outperforms general MIP solvers by orders of magnitude, achieves competitive quality against specialized solvers on instances up to n=150, and attains 4.73% gap on TSP-442 within 30s. Twelve problem types spanning five encoding variants are solved to optimality. Framework-level optimizations cumulatively reduce pcb442 gap from 36% to 4.73% and boost VRPTW throughput by 75-81%. Code: https://github.com/L-yang-yang/cugenopt
Figures & tables
Method
GPU
Univ. Enc.
AOS
Op. Ext.
Python
New Problem
MIP (SCIP/CBC)
×
×
×
×
✓
Math modeling
OR-Tools Routing
×
×
×
×
✓
Not supported
cuOpt [ 17 ]
✓
×
×
×
✓
VRP/MILP only
GPU-ACO [ 4 ]
✓
×
×
×
×
Rewrite kernel
ALNS [ 23 ]
×
✓
✓
✓
×
Custom op. pairs
GPU-EA [ 26 ]
✓
Partial
×
×
×
Partial rewrite
Table 1: Feature comparison of cuGenOpt with existing approaches.
Figure 1: cuGenOpt system architecture. The framework provides three-layer abstraction: user interface (Python API and CUDA problem definition), core components (adaptive search and operator management), and GPU execution engine (L2-aware memory management and CUDA kernels).
Figure 2: GPU parallel execution model. The population is distributed across CUDA blocks (P blocks = population size). Within each block, 128 threads sample candidate moves in parallel, perform block-level reduction to find the best move, and thread 0 executes accept/reject decision. Shared memory holds current solution, operator weights, and reduction buffer.
Figure 3: Adaptive Operator Selection (AOS) mechanism. Each CUDA block maintains local statistics (usage count and improvement count) for each operator. Every 10 batches, weights are updated via EMA based on observed effectiveness. The two-level structure controls both K-step (number of operators per iteration) and sequence-level (specific operator) selection probabilities.
GPU
SMs
Max Shared Mem/Block
Architecture
Tesla T4
40
64 KB
Turing (sm_75)
Tesla V100
80
96 KB
Volta (sm_70)
A800/A100
108
164 KB
Ampere (sm_80)
H20/H100
132
228 KB
Hopper (sm_90)
Table 4: Maximum shared memory per block across GPU generations.
Figure 4: L2 cache-aware population sizing. The framework automatically adjusts population size to fit the working set into L2 cache, preventing cache thrashing. For TSP n=1000 (working set 3.8 MB), V100 (L2=6 MB) selects pop=32, while A800 (L2=40 MB) can support larger populations.
Figure 5: JIT compilation pipeline. User-provided CUDA code snippets (objective and constraints) are injected into a template, compiled via nvcc, and executed as a subprocess. SHA-256 hashing enables compilation caching. The entire process is transparent to users, appearing as a standard Python function call.
Component
Specification
GPU platforms (cuGenOpt)
Tesla T4
40 SMs, 64 KB shared/block, 4 MB L2, 320 GB/s
V100-SXM2
80 SMs, 96 KB shared/block, 6 MB L2, 900 GB/s
V100S-PCIE
80 SMs, 96 KB shared/block, 6 MB L2, 1134 GB/s
A800-SXM4
108 SMs, 164 KB shared/block, 40 MB L2, 2039 GB/s
CPU platform (baselines)
Table 5: Experimental environment.
Instance
cuGenOpt
SCIP
CBC
Winner
eil51 ( n=51 )
0.00%
69.5%
31.2%
cuGenOpt
ch150 ( n=150 )
0.34%
709.9%
infeasible
cuGenOpt
A-n32-k5 ( n=32 )
0.00%
56.8%
—
cuGenOpt
Table 6: cuGenOpt vs. MIP solvers (gap%, 60 s, Tesla T4).
Instance
n
cuGenOpt
OR-Tools
Winner
eil51
51
0.00%
0.00%
Tie
kroA100
100
0.00%
0.00%
Tie
ch150
150
0.34%
0.54%
cuGenOpt
tsp225
225
2.30%
− 0.61%
OR-Tools
lin318
318
5.16%
2.85%
OR-Tools
pcb442
442
4.75%
1.87%
OR-Tools
Table 7: cuGenOpt vs. OR-Tools Routing (gap%, 60 s, Tesla T4).
Figure 6: Baseline comparison across TSP instances. cuGenOpt dominates general MIP solvers (SCIP/CBC) across all scales, with gaps 100-2000× smaller. Against specialized routing solvers (OR-Tools Routing with GLS metaheuristic), cuGenOpt is competitive at small-medium scale ( n≤150 ) but trails at large scale ( n>200 ).
Metric
cuGenOpt
OR-Tools
Scenario A: Priority constraints
Priority violations
0
17
Scenario B: Nonlinear cost
Nonlinear cost
826.67
874.30
Table 8: Custom scenario comparison (A-n32-k5, 60 s, Tesla T4).
Figure 7: Cross-hardware solution quality comparison (30s, gap%). Three memory regimes emerge: (1) Shared memory regime ( n≤100 ): A800’s 164KB shared memory enables best quality. (2) L2 cache regime (n=150-225): A800’s adaptive large population (P=128) hurts convergence despite ample L2. (3) DRAM regime ( n≥318 ): A800’s 40MB L2 and 2TB/s bandwidth achieve best quality at large scale.
Problem
n
Solution
Time (s)
Gens/s
TSP
300
8,156.07
4.2
1,190
TSP
1000
77,691.52
15.3
327
VRP
150
4,504.37
3.8
1,316
VRP
500
56,732.55
10.1
495
VRP
1000
163,426.00
18.7
267
Table 10: Large-scale problem results (V100S, 5000 generations).
Problem
n
1 GPU
2 GPUs
Improv.
CUDA Graph
TSP
150
4,504.37
4,395.03
+2.43%
Enabled
TSP
300
8,156.07
8,054.83
+1.24%
Enabled
TSP
1000
77,691.52
74,962.60
+3.51%
Enabled
TSP
1000
43,888.89
43,600.11
+0.66%
Disabled
VRP
50
4,569.13
4,473.00
+2.10%
Enabled
VRP
500
56,732.55
55,624.84
+1.95%
Enabled
Table 11: Multi-GPU comparison (2×V100S, 5000 generations, mean of 3 runs).
Figure 8: Multi-GPU improvement across problem scales. TSP shows increasing benefit with scale, reaching 3.51% at n=1000 (CUDA Graph enabled). CUDA Graph configuration significantly affects effectiveness (3.51% vs 0.66%). VRP effectiveness depends on both scale and problem feasibility.
Config
Vehicles
1 GPU
2 GPUs
Improv.
Insufficient
24
266,471.97
266,471.97
0.00%
Adequate
80
56,732.55
55,624.84
1.95%
Table 12: VRP configuration impact on multi-GPU effectiveness (n=500).
Table 15: Cumulative optimization ablation on pcb442.
Figure 9: Cumulative optimization impact on pcb442 (Tesla T4, 30s). Heuristic initialization provides the largest improvement (-82% gap). AOS update frequency optimization boosts throughput by 240%. Profile-driven weights and population adaptation further refine solution quality and throughput. Final configuration achieves 6.15% gap at 625 gens/s.
We introduce cvxgenrust, an open-source tool for generating custom Rust code that solves families of parameterized convex optimization problems modeled in CVXPY. cvxgenrust canonicalizes a problem family, extracts affine maps to Clarabel cone-program data, and generates a specialized Rust crate that updates parameters and calls Clarabel natively at runtime. The generated solver can also be exposed to Python and registered as a custom CVXPY solver. Our code generator supports a wide range of convex optimization problems up to semidefinite programs and exponential-cone problems. Numerical experiments show reduced runtime relative to direct CVXPY solves and performance comparable to CVXPYgen on shared problem classes.
Hao Zhu, Joschka Boedecker
IMBIT//BrainLinks-BrainTools · Department of Computer Science, University of Freiburg
Can a single LLM-based optimization system match specialized tools across fundamentally different domains? We show that when optimization problems are formulated as improving a text artifact evaluated by a scoring function, a single AI-based optimization system-supporting single-task search, multi-task search with cross-problem transfer, and generalization to unseen inputs-achieves state-of-the-art results across six diverse tasks. Our system discovers agent architectures that nearly triple Gemini Flash's ARC-AGI accuracy (32.5% to 89.5%), finds scheduling algorithms that cut cloud costs by 40%, generates CUDA kernels where 87% match or beat PyTorch, and outperforms AlphaEvolve's reported circle packing solution (n=26). Ablations across three domains reveal that actionable side information yields faster convergence and substantially higher final scores than score-only feedback, and that multi-task search outperforms independent optimization given equivalent per-problem budget through cross-task transfer, with benefits scaling with the number of related tasks. Together, we show for the first time that text optimization with LLM-based search is a general-purpose problem-solving paradigm, unifying tasks traditionally requiring domain-specific algorithms under a single framework. We open-source optimize_anything with support for multiple backends as part of the GEPA project at https://github.com/gepa-ai/gepa .
This paper presents a hybrid CPU-GPU framework for solving combinatorial scheduling problems formulated as Integer Linear Programming (ILP). While scheduling underpins many optimization tasks in computing systems, solving these problems optimally at scale remains a long-standing challenge due to their NP-hard nature. We introduce a novel approach that combines differentiable optimization with classical ILP solving. Specifically, we utilize differentiable presolving to rapidly generate high-quality partial solutions, which serve as warm-starts for commercial ILP solvers (CPLEX, Gurobi) and rising open-source solver HiGHS. This method enables significantly improved early pruning compared to state-of-the-art standalone solvers. Empirical results across industry-scale benchmarks demonstrate up to a 10× performance gain over baselines, narrowing the optimality gap to <0.1%. This work represents the first demonstration of utilizing differentiable optimization to initialize exact ILP solvers for combinatorial scheduling, opening new opportunities to integrate machine learning infrastructure with classical exact optimization methods across broader domains.
Mingju Liu, Jiaqi Yin, Alvaro Velasquez +1
University of Maryland, College Park, Maryland, USA · University of Colorado, Boulder, Colorado, USA