When the cloud is not an option
The default mental model for computer vision is simple: capture an image, send it to a powerful model in the cloud, get a result. For a great many real deployments, that model is a non-starter. Bandwidth in a grocery store, a factory, or a warehouse is precious and unreliable. Sending a continuous video feed of every aisle to the cloud is expensive, slow, and often forbidden outright on privacy grounds. The interesting, hard, valuable work in computer vision increasingly happens at the edge, on modest hardware sitting a few feet from the camera.
The constraints that shape edge vision
Edge deployment flips the usual priorities. Instead of optimising purely for accuracy on a research benchmark, you are optimising for accuracy per watt, per dollar, and per millisecond on a device that might cost less than a hundred dollars. That reframing touches every decision. You cannot assume a connection, so the system has to keep working offline and reconcile later. You cannot ship a four-gigabyte model, so it has to be compressed. And you cannot send a technician to every site, so it has to update and recover itself remotely.
Making models small enough to run in the aisle
Getting a capable model onto cheap hardware is a craft. Quantisation reduces the numerical precision of the weights, often with negligible accuracy loss and large speed gains. Pruning removes the parts of the network contributing least. Choosing an architecture designed for constrained devices, rather than shrinking one designed for data-centre GPUs, frequently beats both. Running a segmentation model on commodity edge hardware rather than a GPU box per aisle is only possible when compression is treated as a core part of modelling rather than a last-minute afterthought.
Offline first, reconcile later
An edge system that assumes connectivity will fail in exactly the environments where it is most valuable. The robust pattern is offline-first: the device makes its decisions locally and queues results, then syncs when a connection is available. This demands careful thought about what happens during an outage, how conflicts are resolved on reconnection, and how you avoid a thundering herd when a thousand devices come back online at once. Get this right and the system degrades gracefully; get it wrong and a flaky network takes the whole deployment down.
From detection to action
A detection nobody acts on is wasted compute. The value of edge vision is realised in the last mile, when a result becomes an alert that reaches the right person fast enough to matter. For shelf availability, that meant comparing what the camera saw against the planogram and pinging the correct associate, in their own language, within ninety seconds, integrated with the store's existing operations tooling rather than a new app nobody would open. The detection model was the easy half; the alerting and integration that turned a detection into restocked shelves was where the revenue actually came from.
Managing a fleet of thousands
One camera is a science project. Thousands of devices across thousands of sites is an operations problem. You need to deploy model updates remotely, monitor the health of every device, detect the camera that has been knocked out of alignment or covered by a stray box, and roll back a bad update without dispatching a single van. Treating the edge fleet as infrastructure, with the same monitoring and lifecycle discipline you would apply to servers, is what makes a rollout across thousands of sites feasible rather than a permanent firefight.
Edge vision is an engineering discipline
The lesson from large edge deployments is that the model is necessary but nowhere near sufficient. Compression, offline operation, last-mile alerting, and fleet management are the parts that decide whether the project lifts revenue or quietly dies. Our computer vision practice treats all of them as first-class, because pixels only become decisions when the whole system around the model is built to run in the real world.