John Deere's on-device AI cuts herbicide use 59%, reshaping edge computing strategy

In 2024, John Deere's See & Spray technology demonstrated the practical power of on-device AI in agriculture. Running on embedded NVIDIA Jetson hardware, the system processes camera data from more than 2,100 square feet of crop per second and makes spray decisions—treat or skip—in real time with no network involvement. The results were substantial: across more than 1 million acres in 2024, See & Spray saved an estimated 8 million gallons of herbicide mix. When measured against broadcast spraying, the system cut herbicide use by an average of 59%, according to Deere's September 2024 announcement. An Iowa State University Extension study measured even higher savings of 76% on average, worth $15.7 per acre. By 2025, the technology had expanded to 5 million acres and 31 million gallons saved.

Behind these figures lies a computer vision system that distinguishes weeds from crops and fires individual nozzles as the machine moves. The inference budget is tiny—the model has a window measured in low tens of milliseconds—and connectivity is unreliable or absent in field conditions. This is why the decision must happen on the device, not in the cloud. On-device deployment also avoids a cost structure problem: in cloud inference, a successful product becomes more expensive to run in direct proportion to its success, an unusual dynamic in software economics.

On-device AI has become essential in other domains with similar constraints. In healthcare, GE HealthCare received FDA 510(k) clearance in December 2023 for Critical Care Suite 2.1, which runs pneumothorax detection on the mobile X-ray system itself, reporting a 57% reduction in reporting times for clinically actionable cases and a 17.7% increase in clinician detection of small pneumotharaces. Autonomous systems—robotics, drones, and vehicles—require hard real-time deadlines between perception and actuation with safety consequences; cloud assistance is useful for fleet learning but unusable inside the control loop. Industrial IoT and retail systems face similar pressures: continuous high-bandwidth sensor data that is almost never worth centralizing, and camera feeds where sending events rather than video changes both bandwidth costs and compliance exposure.

The reason edge AI only recently became practical at scale is not a hardware shortage. NPUs on mainstream SoCs, NVIDIA Jetson modules, Hailo accelerators, and Google Coral were all shipping before edge AI projects reached production. The real blocker was the engineering path from a trained model to a deployable artifact—fragile conversion pipelines, numerical mismatches between training and deployed graphs, and in some cases rewriting the model in C++. That path improved substantially over the last two years. PyTorch shipped ExecuTorch 1.0 in October 2025, with a base runtime of roughly 50KB and delegates for more than a dozen hardware backends, and Meta reports it running in production across its own apps and devices. LiteRT, ONNX Runtime, Core ML, and llama.cpp cover adjacent ground with different tradeoffs. Deploying to constrained hardware became a repeatable engineering task.

Model compression is where model and platform teams must negotiate a budget, with three mainstream techniques each trading something away. Quantization reduces weight and activation precision from FP32 to int8 or int4, cutting memory and increasing throughput; post-training quantization applies quickly but can degrade accuracy unpredictably, while quantization-aware training recovers most of that at the cost of retraining. Distillation trains a smaller student model against a larger teacher and usually gives the best capability per byte—DistilBERT established the pattern, cutting BERT's size by 40% and running 60% faster while retaining 97% of its language understanding on GLUE, though it requires a full training pipeline. Pruning removes redundant weights; structured pruning produces real speedups, but unstructured sparsity often does not because most edge accelerators lack hardware support for sparse execution. The sequencing that tends to work is distill first to set the architecture, quantize to fit the memory envelope, and treat pruning as targeted optimization.

Hardware constraints shape what architectures are feasible. The accelerator dictates the operator set—NPUs and TPUs are efficient on implemented operations and fall back to CPU otherwise, and a single unsupported operator can erase the entire performance advantage. Memory ceilings usually determine the feasible parameter count and quantization format before compute does. Power and thermal envelopes bound sustained throughput; devices in enclosures under continuous load throttle. Gartner's Predicts 2026 research projects fivefold growth in per-node embedded compute by 2029 against flat power envelopes, making thermal constraints permanent.

The operational challenges that separate prototype from shipped product are substantial and often underestimated. Fleet lifecycle management means staged rollouts, version skew between model and application code, rollback paths that work offline, and updates that survive a power loss mid-write—container-native operating systems paired with lightweight Kubernetes distributions such as K3s, MicroShift, and KubeEdge have become the common substrate, with KubeEdge splitting the control plane so nodes keep running when unreachable from the cloud. Observability without data exfiltration sits in direct tension: inference moved to the device because the data could not be centralized, yet detecting drift requires signals, and deciding which signals can leave without recreating the original privacy problem is expensive to retrofit. Hardware heterogeneity—a fleet accumulating different accelerators, memory, and drivers—requires compiled model variants and a device capability registry. The philosophy behind successful deployments is edge-first reasoning: starting from the constraint (latency budget, residency boundary, power envelope) and deciding what can centralize, rather than building the system first and discovering later which parts cannot survive a round trip. A local model handling the common case and routing uncertain inputs to the cloud captures most of the latency and cost benefit while preserving a capability ceiling, and instrumenting that confidence threshold matters more than the choice of accelerator.

The See & Spray deployment illustrates why edge AI has moved from academic interest to production necessity. For years, the hardware to run inference on constrained devices existed—NPUs on mainstream SoCs, NVIDIA Jetson modules, Hailo accelerators, and Google Coral were all shipping before edge AI projects reached scale. The actual bottleneck was the engineering path from a trained model to a deployable artifact. That path only stabilized over the last two years, as frameworks like PyTorch's ExecuTorch (shipped October 2025 with a roughly 50KB base runtime), LiteRT, ONNX Runtime, Core ML, and llama.cpp matured. Deploying to constrained hardware became a repeatable task rather than a bespoke project.

Where on-device AI is winning now reflects the hard constraints of real-world deployments: healthcare devices (GE HealthCare's Critical Care Suite 2.1 runs pneumothorax detection on mobile X-ray systems, reducing reporting times by 57%); autonomous systems requiring hard real-time deadlines between perception and actuation; industrial IoT generating continuous high-bandwidth sensor data that is almost never worth transmitting; and retail systems sending events rather than video feeds to avoid bandwidth and compliance costs. In each case, the economics and safety requirements of the use case dictate that intelligence must live on the device.

The gap between a working prototype and a shipped product, however, is substantial. Model compression (quantization, distillation, pruning) must be sequenced carefully—distill first to set architecture, quantize to fit memory, treat pruning as targeted optimization. Fleet lifecycle management demands staged rollouts, version skew handling between model and code, offline-survivable rollback paths, and container-native operating systems with lightweight Kubernetes tools like K3s or KubeEdge. Observability without data exfiltration remains unresolved design-time: detecting model drift requires signals, but deciding which signals can safely leave the device without recreating the original privacy problem is expensive to retrofit. Hardware heterogeneity—a fleet accumulating generations with different accelerators and drivers—requires compiled model variants and device capability registries. These operational challenges are what separate edge-first reasoning (starting from latency/power/residency constraints and deciding what centralizes) from cloud-first reasoning (building the system and later discovering what cannot survive a round trip).

No comments yet. Be the first to share your thoughts!