Latency: the argument the cloud cannot win
Real-time vision runs on a frame budget. At 30 frames per second, every frame has to be handled inside roughly 33 milliseconds. On an embedded accelerator, the forward pass of an optimised model runs in perhaps 5 to 20 milliseconds, comfortably inside that window. Sending the same frame to the cloud adds a round trip of 50 to 500 milliseconds before the model even starts, and that round trip is variable, dependent on network conditions you do not control.
real-time computer vision the right architecture whenever a decision has to be made inside the frame budget rather than reported after it.
Bandwidth: the arithmetic that surprises finance
The latency argument is well known. The bandwidth argument is the one that quietly wrecks cloud vision budgets. Streaming a single 1080p camera at a modest 4 megabits per second is roughly 1.8 gigabytes per hour, which is on the order of 1,300 gigabytes per month per camera, and cloud egress and ingest are not free. Multiply by a fleet of cameras and the number stops being a rounding error. A hundred cameras streaming continuously to the cloud can run into five figures a month in data transfer alone, before a single GPU-hour of inference is billed.
Privacy and sovereignty: where the data is allowed to be
The third axis is regulatory, and it is increasingly the one that removes the choice entirely. When cameras capture people, patients, or protected environments, the question of where that data is processed becomes a compliance question, not an engineering one. GDPR, HIPAA, the EU AI Act, and data-sovereignty rules can all constrain whether video may leave a site or a jurisdiction at all. Processing frames on the device, and transmitting only derived, non-identifying outputs, keeps sensitive data where it was captured and shrinks the compliance surface dramatically. In some deployments this is not an optimisation, it is the only lawful architecture, and it settles the edge-versus-cloud debate before latency or cost is even discussed.
The honest comparison
| Dimension | Edge inference | Cloud inference |
| Latency | Deterministic, 5-20 ms local | 50-500 ms round trip, variable |
| Bandwidth cost | Low, sends only outputs | High, streams raw video |
| Compute ceiling | Tens of TOPS at 5-15 W | Effectively unlimited |
| Data/privacy | Stays on device | Leaves site/jurisdiction |
| Model updates | Requires an OTA mechanism | Trivial, centralised |
| Retraining/heavy jobs | Impractical on device | Natural fit |
The answer is usually hybrid
Framing this as edge versus cloud is the mistake. The strongest architectures use both, deliberately. Inference that has to be fast, private, or bandwidth-light runs at the edge. Training, retraining, long-horizon analytics across a fleet, and management sit in the cloud, where elastic compute and mature tooling belong. The edge device makes the decision in 20 milliseconds; the cloud aggregates results from across the fleet, spots the drift, trains the next model version, and pushes it back down through a staged, validated update. Each layer does what it is physically and economically best at.
Designing that split well is the actual engineering task, and it is a systems decision rather than a platform preference. It requires deciding which computations are time-critical, which data is sensitive, where the bandwidth costs concentrate, and how models will be updated on devices in the field without a truck roll. Teams that engineer edge and cloud as one system, rather than defaulting everything to the cloud and discovering the latency and bandwidth problems in production, are the ones whose real-time vision deployments actually hold up. The practical guidance from InTechHouse on this is consistent: put the decision where the data is, and put the scale where the elasticity is.
Getting the split wrong, in both directions
The failure modes are symmetric, and both are common. Push too much to the cloud and you get a system that is accurate in testing and unusable in production: the control loop misses its deadline, the monthly egress bill climbs past the value the system creates, and a compliance review discovers that video of people has been leaving the jurisdiction. These problems rarely show up in a pilot with three cameras and a good network. They show up at fleet scale, which is exactly when they are most expensive to unwind.
The bottom line
For real-time vision, the edge-versus-cloud decision is not about which is more powerful. It is about latency the round trip cannot meet, bandwidth costs that compound with every camera, and privacy rules that dictate where data is allowed to live. The cloud remains the right home for training, retraining, and fleet analytics. The real-time decision loop belongs at the edge, and the best systems connect the two rather than choosing between them. Default everything to the cloud and your vision system will be accurate, expensive, and half a second too late. Design the split on purpose and it will be fast where it has to be and scalable where it can afford to be.

Holly Keenstier is a crucial helper at The Code Crafters Hub, where her contributions significantly enhance the platform's capabilities. Keenstier's background in software development and her meticulous approach to project tasks have made her an integral part of the team. Her role involves various responsibilities, from aiding in technical troubleshooting to supporting content development, all of which are essential to maintaining the hub’s high-quality standards.
Keenstier’s dedication to The Code Crafters Hub is evident in her commitment to delivering relevant and insightful content. Her efforts help ensure that the platform remains a leading resource for the latest advancements in web development, game development, IoT, and cybersecurity. Based in Warren, MI, Keenstier’s work is instrumental in keeping the hub’s offerings dynamic and up-to-date.
