Executive summary
In short: Chora, the GPU-powered optimization engine inside Tramm TMS, was benchmarked against Tramm's original CPU-based solver (Solo) across four scenarios and against two leading commercial routing solvers on a real U.S. manufacturer's network. In every test Chora solved in about one minute, versus 10 minutes to 2 hours for CPU solvers, and produced equal or better plans: fewer vehicles, shorter distances, more jobs planned, and full compliance with driver-fatigue and loading-bay constraints.
Traditional CPU-based solvers have for a long time been the biggest bottleneck in optimizing supply chain and distribution networks. As global logistics operations are growing in complexity, the limitation of this approach has only gotten worse. In addition, traditional CPU-based solvers not only take long to solve, but they are also reaching limits as routing, scheduling, and compliance constraints become more critical to generating executable results and saving costs.
Chora, a GPU-powered optimization engine developed by Opsi Systems that is used in its TMS platform Tramm, represents a fundamental leap forward, delivering faster, more scalable, and higher-quality route optimization. This paper, co-authored with JBF Consulting, presents validated performance findings from both a comparative study between Tramm's original solver and results from two well-respected commercial routing and scheduling tools.
In this paper we describe how traditional methods have reached a plateau in performance, while the burgeoning AI technology infrastructure has opened a new world of possibilities that were unavailable only a few years ago and that Chora can now leverage to profound effect.
Foreword
Assumptions and truisms are prevalent in many aspects of the transportation industry, though one that rarely generates a discussion is the traditional idea of using Central Processing Units (CPUs) to solve routing problems. For decades it has been a given that more power and faster processors would speed up optimization and generate a better result. But this path reached its diminishing returns far longer ago than most of us have realized.
It has taken an entirely new, and in hindsight exceedingly logical, idea of shifting away from CPUs and using the latest breakthrough in Graphics Processing Units (GPUs) to transform our approach to transportation algorithms. The results are, and we state this without exaggeration, a massive leap forward in processing times and quality of results.
We are only scratching the surface of what these optimization speeds can unlock. This will go well beyond what can be improved in a single fleet routing cycle, ultimately impacting the entire tactical process of daily and weekly routing, before then transforming what can be accomplished with strategic supply chain network optimization.
The industry challenge
As supply chains expand, transportation planners face more complex optimization problems: multi-day horizons, time windows, dock scheduling, fatigue rules, dynamic capacity constraints, traffic, and more. Existing solvers built on traditional CPU architectures struggle to maintain both speed and solution quality at the scale demanded by modern supply chains. These systems, designed decades ago, are ill-equipped for the parallelized, data-intensive needs of today's logistics routing problems.
Why traditional solvers plateau
Even leading optimization engines, like those underpinning current market-leading transportation management platforms, depend primarily on CPU-based architecture. As problem size and constraint diversity grow, computation time scales exponentially. In real-world conditions, this leads to long solve times, suboptimal fleet utilization, and reduced agility.
Chora's predecessor, Solo (built on Google OR-Tools), has been used successfully with numerous customers and is already considered to be a strong solver by industry standards. Despite that success, Solo is still limited by its CPU-based optimization approach, motivating a full architectural redesign by Opsi Systems based on the theoretical improvements using GPUs as the primary optimization tool.
The Chora architecture
Chora is a GPU-powered vehicle routing solver engineered to address large-scale problems involving complex constraints. Built using NVIDIA's CUDA framework, it leverages thousands of GPU threads and advanced genetic algorithms to explore solution spaces faster and more thoroughly than CPU solvers. This GPU-first approach enables Chora to deliver high-quality solutions in seconds, solving problems that previously took minutes or hours.
Chora's success heralds a structural change in how optimization can be performed. GPU-based computing scales linearly with problem size, offering consistent performance even in highly complex, multi-constraint environments. This technology empowers planners to re-optimize in near real-time, improving fleet utilization, reducing costs and emissions, and enabling dynamic responsiveness to operational variability.
Opsi Systems internal study: Tramm's original solver (Solo) versus Chora
Opsi Systems conducted a study benchmarking Chora against Tramm's original solver, Solo. Four of the study scenarios are outlined below. All scenarios used the same data set:
Scenario 1: Single-day planning with time windows and capacity constraints
The first scenario was a simple case that looked at single-day planning with time windows and capacity constraints. All of the 417 jobs were planned by both Solo and Chora. Solo planned them all in 10 minutes while Chora managed to plan them all in 1 minute. Chora also showed significant improvements in trip duration, distance travelled, vehicles used, and cost:
| Solver | Runtime | Jobs planned | Total trip duration | Total trip distance | Vehicles used | Total cost |
|---|---|---|---|---|---|---|
| Solo | 10 min | 417/417 | 430 hr 38 min | 7,137 km | 27/34 | $77,385.70 |
| Chora | 1 min −90% | 417/417 0% | 405 hr 48 min −6.1% | 6,606 km −7.4% | 26/34 −3.7% | $74,586.10 −3.6% |
To understand how Chora was able to achieve such significant improvements, we examined the routes provided by each solver. Two major differences stand out. For the northern section of trips, Chora was able to consolidate two of the major long-distance trips into a single trip. For the south-eastern trips, Chora managed to consolidate three of the major long-distance trips into two trips.
Decreasing distance by 7.4% and saving a vehicle was an unexpectedly large improvement for such a simple scenario.
Scenario 2: Scenario 1 constraints plus planning of high-priority jobs over low-priority jobs
The second scenario includes the constraints from Scenario 1 but adds the prioritization of high-priority jobs over low-priority jobs while respecting working-hours constraints. The idea is to simulate an environment where there are not enough vehicles to deliver all jobs, while maintaining a rolling set of jobs on the floor and prioritizing those reaching the end of their delivery window. This approach is often used to maximize vehicle utilization and reduce the number of trips to distant locations.
In this scenario, the available vehicles were reduced from 34 to 12. The scenario included 150 high-priority jobs and 267 low-priority jobs. Solo managed to plan 128 of the 150 high-priority jobs and 177 of the 417 total jobs in a solve time of 10 minutes. Chora planned all 150 high-priority jobs and 201 of the 417 total jobs in 1 minute. Both solvers used all 12 vehicles available.
| Solver | Runtime | High-priority jobs planned | Total jobs planned | Vehicles used |
|---|---|---|---|---|
| Solo | 10 min | 128/150 | 177/417 | 12 |
| Chora | 1 min | 150/150 +17.2% | 201/417 +11.9% | 12 |
Adding priorities is well known to be difficult with traditional solving methods1, so it was no surprise that Solo did not do well with this constraint. The fact that Chora beat Solo by 11% in the total number of jobs planned was an impressive level of improvement.
Scenario 3: Scenario 1 constraints plus fatigue rules and time windows extended over two days
The third scenario includes the constraints from Scenario 1 but extends the delivery windows over a two-day period and includes European Union (EU) driver-fatigue rules (similar to US fatigue rules). A midday break of 30 minutes must be taken after 4.5 hours of working. In addition, an overnight break of 11 hours must be taken after 13 total hours of working or 9 hours of driving.
Solo managed to plan 196 of the 417 jobs in a solve time of 60 minutes. Chora planned 416 of the 417 jobs in a solve time of 1 minute.
| Solver | Runtime | Jobs planned |
|---|---|---|
| Solo | 60 min | 196/417 |
| Chora | 1 min | 416/417 +112% |
This is a completely dominant result, highlighting the inability of the Solo solver to adequately handle fatigue breaks.
It is also instructive to view Chora's convergence graph to understand how results became optimal over the course of the 60-second solve time:
| Elapsed time | Objective cost | Reduction |
|---|---|---|
| 5 seconds | 3,635,714 | — |
| 10 seconds | 2,967,346 | −18% |
| 20 seconds | 2,676,530 | −26.4% |
| 60 seconds | 2,491,795 | −31.5% |
Scenario 4: Scenario 1 constraints plus loading bays
The fourth scenario includes the constraints from Scenario 1 but adds a single loading dock with only 8 loading bays at the depot. These loading bays are set up to allow reservation slots in 15-minute units. There are not enough loading bays to load all vehicles at once, so loading must be staggered in such a way as to minimize the total waiting time of the vehicles.
Solo did not manage to find a solution after a 60-minute runtime. Chora found a solution in 1 minute and planned 383 of the 451 jobs while achieving 95.3% loading-dock utilization and 100% loading-slot utilization. Some jobs could not be planned because they could not all be loaded, given the individual loading durations combined with the limited number of bays, despite the 12-hour loading window that was available (18:00–06:00).
| Solver | Runtime | Solution found | Jobs planned | Loading dock utilisation | Loading slot utilisation |
|---|---|---|---|---|---|
| Solo | 60 min | No | — | — | — |
| Chora | 1 min | Yes | 383/451 | 95.3% | 100% |
Real-world validation: leading U.S. manufacturer study
JBF Consulting conducted a benchmarking study of Chora for a leading U.S. manufacturer. The study compared Chora's GPU-based solver to vendor solvers from two leading providers under realistic operational conditions including multi-day routing, capacity, regional constraints, and fatigue rules. The objective was to solve for optimal trip distance (as opposed to trip duration) while maintaining optimal vehicle utilization.
Regions
The data defined four distinct operating regions, and the solver was required to respect these boundaries, meaning no route was allowed to cross into another region: NY (Upstate New York), DE (Delaware & Maryland), VA (Virginia) and PA (Pennsylvania).
Fatigue rules
- Working break: between any two 14-hour work windows (driving + labor), a 10-hour break must occur. A driver may drive a maximum of 11 hours within that 14-hour window, after which the break is required regardless of total labor time.
- Driving break: after a maximum of 8 consecutive hours of driving, a 30-minute break is mandatory.
Vendor data differences
The key difference between Vendor-A and Vendor-B was the planning horizon. Vendor-A operated over 3 days, with vehicles required to return to the depot by 19:30 on Day 3 (a soft constraint; some trips returned slightly later). Vendor-B operated over 4 days, with the same soft 19:30 return time applied to Day 4.
Vehicle cap
No maximum fleet size was provided. To ensure feasibility, 30 vehicles were supplied for Chora to utilize during the solve.
Key indicative results
| Solver | Runtime | Jobs planned | Total trip duration | Total trip distance | Vehicles used |
|---|---|---|---|---|---|
| Vendor-A | ~2 hours | 845/845 | 1,237 hr 42 min | 18,239.10 miles | 27 |
| Chora | 1 min −99.1% | 845/845 0% | 1,154 hr 22 min −6.7% | 15,622.63 miles −14.4% | 26 −3.7% |
| Solver | Runtime | Jobs planned | Total trip duration | Total trip distance | Vehicles used |
|---|---|---|---|---|---|
| Vendor-B | 18 min | 845/845 | 1,204 hr 01 min | 16,373.98 miles | 24 |
| Chora | 1 min −94.4% | 845/845 0% | 1,280 hr 19 min +6.1% | 15,219.51 miles −7.1% | 23 −4.2% |
The vendors were using CPU-based optimizers and, like any vehicle routing solver, they were subject to the exponential complexity inherent in the Capacitated Vehicle Routing Problem (CVRP)2. As the number of jobs and sites increases, the complexity grows exponentially. This problem set contained 478 unique sites and 845 jobs (465 collections and 380 deliveries), with the requirement that collections and deliveries at the same site could not be separated. All loading also had to be completed within the first two days of the window; fatigue rules needed to be applied and respected, and strict regional constraints were enforced. A problem of this size, combined with these operational constraints, represents a significant challenge for any CPU-based solver.
Vendor-A struggled the most, taking 2 hours to produce its solution. Vendor-B achieved a stronger result, with the extra planning day making the problem easier to solve, but still required 18 minutes to complete. Chora, benefiting from massive parallel execution on the GPU, produced an even better solution than both Vendor-A and Vendor-B in a fraction of the time, representing a 99.2% speed-up over Vendor-A and a 94.4% speed-up over Vendor-B. Importantly, Chora ran on only one sixth of a GPU for these tests; using a full GPU would improve run-time by up to an additional factor of 6.
"GPU-accelerated optimization represents the next frontier in transport planning efficiency."
CTO, Opsi Systems
The screenshot below from Tramm illustrates how Chora achieved extremely high vehicle utilization across the board:
"Not only did we see the quality and cost benefits of GPU-based solvers like Chora, the dramatic reduction in solve time marks a paradigm shift in logistics optimization."
Principal, JBF Consulting
Implications for the logistics industry
Chora's success signals a structural change in how optimization can be performed. The enormous computing power in GPUs allows for consistent performance even in large datasets with highly complex multi-constraint environments. This technology empowers planners to re-optimize in near real-time, improving fleet utilization, reducing emissions, and enabling dynamic responsiveness to operational variability.
Future vision
Chora demonstrates how AI and GPU acceleration can fundamentally redefine logistics optimization. Opsi Systems is expanding the framework to include traffic and weather constraints, continuous real-time optimization, and predictive analytics for end-to-end supply chain efficiency.
1 Doan, T. T., Bostel, N., & Hà, M. H. (2021). The vehicle routing problem with relaxed priority rules (VRP-RPR). EURO Journal on Transportation and Logistics, 10, Article 100039. https://doi.org/10.1016/j.ejtl.2021.100039
2 Chen, Y. (2023). Approximation Schemes for Capacity Vehicle Routing Problems: A Survey. arXiv. https://doi.org/10.48550/arXiv.2306.01826
