Why your best vision model should live at the edge, next to the camera

The substation sits at the end of a long feeder, forty minutes of gravel from the nearest depot, with a thermal camera on the fence line and a cellular modem in the control building that drops out whenever the weather comes in from the west. The camera is there to see a person at the fence after dark and to say so in Slack. On the nights it matters most, the nights with rain and no moon, the uplink is at its worst.

Streaming that camera to the cloud so a model can look at it is a habit rather than a requirement. For a site like this one it is the wrong call four ways at once, and the fourth is the one that decides it.

The round trip costs time the alert cannot spend

A frame leaves the camera, crosses the modem, reaches a model somewhere else, and an answer comes back. On a good night that takes a few seconds. On a bad night it takes long enough that the person at the fence has moved on before the alert about them arrives, and the alert is now a report about the past.

The rule is a sentence, a person at the fence line after dark, with a severity and a cooldown, and the value of it is entirely in how soon the frame reaches someone who can act, in Slack or on a phone. A model beside the recorder answers in the time it takes to run, and the alert leaves the site as a small message rather than waiting on a video stream to get out first. The monitoring and alerts guide covers the rule; the edge runner is what makes it fast on a poor link.

Cloud inference is priced by the frame, and frames are the thing you want more of

Cloud vision is generally priced per frame or per hour of stream, which means the bill scales with exactly the quantity a monitoring project wants to grow. Add a second camera at the gate and the cost doubles. Sample more often on the nights that matter and it climbs again.

A runner on the site watches every camera in parallel, one consumer per stream, sampled about every two seconds, and adding a camera adds a consumer on hardware the site already paid for, a Jetson in the control building. The cost of watching more is the cost of the box, once.

Footage should stay on the site that owns it

The thermal camera's footage is the substation's most sensitive record of itself: who came to the fence, when, what the gate looked like at three in the morning. Sending all of it off site to be looked at is a decision a security team should have to make on purpose, and usually would not.

With the runner beside the recorder, the footage stays on the site. What leaves is the answer: a detection, a count, an alert to Slack with one frame attached. What flows back for retraining is the review queue, the frames the model doubted and the verdicts a person gave on them, never the streams. The security page describes what moves and what does not, and for a security team the review shrinks to that list.

Edge deployment keeps watching when the uplink does not

A drill pad, an orchard, a substation at the end of a feeder: the places that most need a camera watched are the places with the worst connectivity, and a model in the cloud stops watching the moment the link drops. The fence camera at this substation would be unwatched precisely on the nights the operator bought it for.

A model beside the recorder does not know the link has gone. It keeps sampling, keeps answering, and with the edge runner the alert fires locally first, to the site's own siren or the operator's phone on the local network, and the message to Slack goes out when the modem comes back. The deployment guide describes the runner and what it reports about itself, including the last time it heard from the cloud.

My own view is that the link argument is the one that decides it, and the other three are how people justify the decision afterwards.

A model tuned to one site fits on modest hardware

The worry about the edge is usually that the model will not fit. It does, because a model tuned for one site and one set of cameras is carrying only that site's problem. A detector that has learned a person at this fence in thermal, at this distance, at night, does not need the weight of every object in the world, and it runs comfortably on a small box beside the recorder.

The export is by device rather than by architecture. Describe where it is going, a Jetson, a Raspberry Pi, a GPU server in the control building, and the model comes out as PT, ONNX or TorchScript sized for that box. The substation monitoring use case runs on hardware in the control building for that reason, and the accuracy that matters, on this site's classes, is the thing specialisation buys.

Weights travel in and answers travel out

The edge pattern turns the flow of a cloud deployment inside out. Improvements arrive as model weights, a versioned file that replaces the last one with no downtime. Answers leave as detections, counts and alerts to Slack. Doubted frames leave for review, one at a time, with a verdict coming back. The streams themselves never move.

That is the loop, run where the camera is. Lexi puts a box on every frame of the footage you upload, a person checks each label before anything trains on it, and the model then watches the cameras the site already has, on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one on the box. The accuracy the site launched with is the accuracy it keeps, and the operator's part of it is a few doubted frames a week on a phone.

At this substation the gate log is still a padlock and a clipboard in a steel box on the fence. The camera has not replaced it, and nobody has asked it to.

The model is an artifact the site owns

A model trained on a site's own checked footage should belong to the site: a file it can download, run on any box it chooses, and keep when the contract changes. The weights are the product of the site's own footage and its own reviewers' verdicts, and there is no good reason for them to live only behind someone else's endpoint.

That is how we ship them. The trained model exports as a PT, ONNX or TorchScript file, whichever the box needs, and the site runs it wherever it wants, on our runner or on its own. Owning the artifact is what makes the edge argument whole: a model that lives next to the camera, that keeps watching when the link drops, and that the site can carry with it.