Computer vision with YOLOv8 at the edge

Training an object detector is the easy part. The hard part starts when that model has to run far away from your development GPU: on a camera, on an industrial device, over a connection that keeps dropping. These are the lessons I’ve collected from taking computer vision with YOLOv8 into real-world environments running on infrastructure.

Why “at the edge” changes the rules

In the lab you measure accuracy. In production you measure latency, power draw, and robustness against the unexpected. Processing video on the device itself (the edge) instead of shipping it to a central server has clear advantages:

• Low, predictable latency, because you don’t depend on the network for every frame.
• Less bandwidth, because you transmit events and metadata, not raw video.
• Privacy by design, because the image may never leave the device.

The price is that you work with limited compute. That forces decisions you’d never even consider on a desktop GPU.

The model isn’t the problem (almost never)

YOLOv8 ships in several sizes, from nano to extra-large. The temptation is to reach for the biggest model “just in case”. At the edge, that’s usually a mistake: a smaller model fed well beats a bigger one fed badly.

Where quality is really won or lost is in the preprocessing and the capture conditions:

• Resolution and framing. An object that takes up a handful of pixels won’t be detected by even the best model. Sometimes the fix isn’t retraining: it’s moving the camera.
• Lighting. Backlight, hard shadows, and light shifting across the day produce more false negatives than any model limitation.
• Training domain. A model trained on clean images falls apart against the dirt, rain, and dust of the real world. If your training data doesn’t look like what the camera will see, the metrics are lying to you.

In real-world computer vision, most “model failures” are actually data failures or physical-mounting failures.

False positives: the hidden cost

A detector that fires alarms constantly is worse than no detector at all, because it trains operators to ignore it. Managing false positives matters as much as detecting in the first place:

• Per-class confidence thresholds, not a single global one.
• Temporal persistence: confirming a detection across several frames before accepting the event cuts the noise dramatically.
• Regions of interest: limiting detection to the area where the event actually makes sense avoids reacting to whatever drifts through the background.

I’ve applied these ideas in monitoring systems where the video feeds real-time control panels, like the monitoring dashboard I built to visualize sensor status, and in deployments of 4G-connected cameras where bandwidth is a scarce and expensive resource.

A deployment playbook that works for me

1. Start with the data, not the model. Collect images from the real environment before training anything.
2. Measure end-to-end latency, not just inference: capture, preprocessing, postprocessing, and event delivery.
3. Define what an acceptable false positive is together with whoever will use the system. That’s a business decision, not a technical one.
4. Monitor in production. Performance degrades over time: cameras that drift, seasons that change, scenes that evolve.

What I take away

On-device computer vision is an exercise in systems engineering as much as machine learning. The model is one component; the result depends on the camera, the light, the network, and how you turn detections into useful decisions.

If you have a computer-vision case on infrastructure or industrial processes and you want an honest read on what’s feasible, let’s talk.