Video breaks the usual edge-versus-cloud reasoning because it is not request-shaped. A camera streams whether or not anything happens, so a cloud deployment pays to move footage every second of every day, and that cost scales linearly with every camera you add. Bandwidth, not GPU price, is normally what settles the architecture. There are also three tiers rather than two, and the sensible answer is usually a split: detect locally, send events onward.
Most AI deployment advice is written for request-shaped workloads. Something happens, you send it off, you get an answer back, and when nothing is happening you send nothing and pay nothing. Under that model the cloud looks excellent, and for a great many workloads it is.
Video does not behave like that, and the difference is not a detail. It inverts the economics.
A camera never stops talking
A camera produces footage continuously, whether or not anything worth analysing is in frame. An empty loading bay at three in the morning generates very nearly as much data as a busy one at noon.
If the analysis happens in the cloud, you are paying to move all of it — permanently, per camera, for the life of the system. That is not a usage-based cost that scales with value; it is a fixed tax that scales with how many cameras you own. Add twenty cameras and you add twenty cameras' worth of continuous upload, regardless of how often they see anything.
This is why the familiar cloud argument — pay only for what you use — lands differently here. With video you are always using it. Teams who modelled this as an inference cost and were surprised by the network bill usually made exactly this substitution.
Three tiers, not two
The framing is also wrong in a second way. The analysis can run in three places, and they have genuinely different properties:
- On the camera. No extra infrastructure and nothing leaves until there is something to report. Constrained by whatever that chip supports, and upgrading the model means touching hardware.
- On a server inside your network. The most flexible option: current models, many cameras from one box, upgraded independently of the cameras, and footage stays on site. This is the usual home for a serious deployment.
- In the cloud. Best for what it is genuinely good at — aggregation across sites, dashboards, long-term trends, and retraining on accumulated data.
Latency you are paying for but not using
Latency only matters when something acts on the result quickly.
If a detection stops a machine, opens a barrier, interrupts a process or raises an alarm someone responds to within seconds, a wide-area round trip is a poor foundation and local analysis is close to mandatory.
If the output is a footfall count in a weekly report, a compliance trend by shift, or a queue-length analysis someone reviews the next morning, latency is close to irrelevant — and a surprising number of deployments are architected for real-time response to produce exactly this kind of output.
So ask what consumes the result, and how fast. It is the cheapest question in the project and it eliminates whole architectures.
The failure mode nobody specifies
If the connection drops, cloud analytics stops.
For a trend dashboard that is an inconvenience you catch up on. For anything doing safety or security work it is a design question that deserves an explicit answer in advance, rather than discovery during an outage. Local analysis keeps running and forwards its backlog when connectivity returns — which is often the deciding argument on a site where the link is not reliable to begin with, and many industrial sites are precisely that.
What crosses the boundary
Footage of people at work or in public is personal data. Sending frames to a cloud provider creates a transfer, a processor relationship, and a retention question that someone must own.
Running the analysis locally changes what leaves to metadata — a count, an event, a flagged clip. In many designs no personal data crosses the boundary at all, which is a materially easier position to hold in front of a works council, a DPO, or a customer's security review. On a PPE monitoring deployment this is frequently the difference between a system the floor accepts and one it resists.
Decide these three things first
- What acts on the output, and how quickly? Sets your latency requirement, and usually rules out one tier immediately.
- How many cameras in three years? Bandwidth and per-camera licensing scale with that number, not today's. A design that is comfortable at eight cameras can be untenable at eighty.
- What is allowed to leave the site? Often removes options outright, and it is cheaper to discover now than during a security review.
These are business questions, not technical ones, and they narrow the architecture more than any benchmark will. Answer them before anyone evaluates hardware — and note that in most of the deployments we build, the answers point at an on-site server doing detection with the cloud doing aggregation, which is not a compromise so much as each tier doing what it is actually good at.
Questions we get asked
Why is video different from other AI workloads?
Most AI work is request-shaped — nothing happens, nothing is sent. Video is stream-shaped: cameras produce footage continuously, so cloud analytics pays to move it every second. Bandwidth becomes a permanent cost scaling linearly with camera count, and it usually decides the architecture rather than GPU cost.
Is it a straight edge-or-cloud choice?
No — there are three tiers and most good deployments mix them. On-camera needs no infrastructure but is constrained; an on-site server is the most flexible; the cloud is best for aggregation, dashboards and retraining. Detection locally with events sent onward is the common split.
When does latency genuinely matter?
Only when something acts quickly — stopping a machine, opening a barrier, raising an alarm. Footfall counts, compliance trends and queue analysis read the next morning are not latency-sensitive. Plenty of money goes into real-time architectures serving outputs nobody reads until tomorrow.
What if the internet connection drops?
Cloud analytics stops detecting. For a trend dashboard that is an inconvenience; for safety or security work it is a design question needing an explicit answer beforehand. Local analysis continues and forwards its backlog when the link returns.
How does this affect privacy and data protection?
It changes what leaves your network. Frames of people are personal data, so cloud analysis creates a transfer, a processor relationship and a retention question. Local analysis means only metadata leaves — often no personal data crosses at all, which is far easier to defend.
What should we decide first?
What acts on the output and how fast; how many cameras you will have in three years; and what is allowed to leave the site. All three are business questions, and together they narrow the architecture more than any benchmark.
We build computer vision that runs on the client's own network, with the cloud used for what it is genuinely better at. If you are weighing the split, start with your three-year camera count — it changes the answer more often than anything else on the list.