I Ran the Amazon Last-Mile Routing Challenge on a Raspberry Pi 400 | by martin vizzolini | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

I Ran the Amazon Last-Mile Routing Challenge on a Raspberry Pi 400

martin vizzolini

11 min read·<br>Just now

Listen

Share

Routing 1 million stops and 2.5 million packages across 17 depots on a $70 4GB RAM microcomputer in 10 hours , proves high-volume optimization doesn’t require expensive cloud infrastructure, just the right architecture .<br>Press enter or click to view image in full size

The entire Amazon Last-Mile Routing Challenge dataset running on a Raspberry Pi 400 (Quad-core, 4GB RAM).1. The experiment<br>A few weeks ago, I published two experiments about large-scale last-mile route optimization.<br>The first compared my optimizer against the public Amazon Last Mile Routing Challenge routes and showed that the system could reduce total distance and route count while running on a laptop.<br>The second showed that a routing engine could process one million stops with near-linear scaling on commodity hardware .<br>Those experiments had one central idea: Large-scale routing should not require expensive infrastructure, hard request caps, or manual pre-zoning before the optimizer can even start.<br>So I took the public Amazon Last Mile Routing Challenge dataset and ran the full planning pipeline on a Raspberry Pi 400 : a keyboard computer with 4GB of RAM.<br>The point was to test whether the routing architecture itself could survive being pushed down to the smallest reasonable hardware.<br>Not a server.<br>Not a GPU.<br>Not a cloud cluster.<br>A Raspberry Pi.<br>2. What this experiment is really about<br>Most routing systems are built on a quiet assumption: large-scale optimization requires large infrastructure.<br>This experiment is not about Raspberry Pi performance. It is about architectural pressure.<br>A Raspberry Pi 400 has 4GB of RAM, a low-power ARM CPU, and a microSD card for storage. There is almost no room for brute force. The optimizer does not depend on a large shared solver state , excessive memory, or heavyweight centralized computation.<br>That is exactly why this hardware matters as a benchmark. If the Amazon Last Mile dataset can be planned on a machine this constrained, then the limiting factor in routing is not hardware. It is how the computation is organized.<br>3. The Hardware<br>To put this experiment into perspective, we are benchmarking our VRP algorithm across two opposite ends of the modern ARM64 spectrum.<br>The Constrained Environment<br>Component: Raspberry Pi 400<br>CPU: Quad-core ARM Cortex-A72 @ 1.8GHz<br>RAM: 4GB LPDDR4 Storage: microSD card<br>Estimated hardware cost: ~$70 unit / ~$100 kit<br>The ‘High’ Performance Hardware<br>Component: MacBook Pro M4<br>CPU: 14-core Apple M4<br>RAM: 48GB Unified Memory Storage: Ultra-fast PCIe NVMe SSD<br>Estimated hardware cost: ~$2,500+ USD<br>If our optimization engine can resolve complex routing challenges under the severe computing, memory, and I/O bottlenecks of a Raspberry Pi, it can scale efficiently anywhere.<br>4. The Amazon Dataset<br>For anyone coming to this experiment without the previous article, some context matters.<br>The Amazon Last Mile Routing Research Challenge is a public dataset released by Amazon and MIT, based on real delivery operations across five major US metropolitan areas: Los Angeles, Seattle, Chicago, Boston, and Austin. It contains 6,112 historical routes , over one million stops , and more than 2.5 million packages , organized across 17 depot stations.<br>This is not a synthetic benchmark. These are actual Amazon delivery routes, with real geographic coordinates, real package dimensions and weights, real vehicle capacities, and real time-window constraints for a subset of stops.<br>The challenge it poses is not just scale. It is the combination of scale with operational reality: vehicles have capacity limits, packages have sizes, some customers have delivery windows, and routes need to be geographically coherent enough for a driver to actually follow them.<br>The optimizer was run against this dataset with a specific goal: improve on Amazon’s reported routes without relaxing any of the constraints. Same fleet composition. Same vehicle capacities. Same package volumes. Same time-window requirements. The only objective was to do more with the same resources: fewer total kilometers, fewer routes, higher vehicle utilization, and equal or better time-window compliance.<br>The results from that experiment: roughly 15–20% less total distance, 10–15% fewer routes, and 10–20% higher average vehicle utilization across depots.<br>Those are the numbers this Raspberry Pi was asked to reproduce.<br>More info about the process and detailed depots can be found in this previous article<br>5. What the optimizer actually does<br>The optimizer is not just calculating shortest paths.<br>Press enter or click to view image in full size

DLA7, Solution for Los Angeles depot with 174K stops, 975 Optimizer routes.It builds a complete fleet plan:<br>-...