When you build a system that detects key moments in a live sports feed, one architectural decision shapes everything downstream: where does the inference happen? At the edge, close to where the video is produced, or in the cloud, after the stream has been ingested? There is no universally right answer, but the trade-offs are sharp and worth laying out.
The case for the edge
Running detection near the source, at the venue or in an on-prem encoder, minimizes the round trip. The video does not have to travel to a data center and back before a moment is flagged, which can shave critical seconds off the time to clip. For genuinely live use cases, where a clip is worthless if it lands a minute late, that latency saving is the whole game. Edge inference also reduces egress: do the heavy frame analysis locally and ship only the clips that matter, instead of streaming everything to the cloud.
The cost of the edge
Edge hardware is constrained. You run on whatever GPU or accelerator fits in the rack at the venue, not on an elastic fleet. That bounds model size and concurrency. Updating models across many distributed edge nodes is an ops problem in itself, and a venue that hosts one event a week is idle hardware the rest of the time. Edge is fast but inflexible.
The case for the cloud
The cloud gives you elastic compute, easy model updates, and the ability to run larger or ensemble models you could never fit at the edge. If you process many concurrent streams, centralizing inference pools capacity instead of overprovisioning every venue. For workflows where a few seconds of extra latency is acceptable, near-live rather than instant, the cloud is simpler to operate and cheaper to scale.
The cost of the cloud
You pay for it in latency and bandwidth. Every frame you want to analyze has to be ingested first, and for high-bitrate broadcast feeds that adds up. The end-to-end path, capture, encode, transport, ingest, infer, clip, deliver, has more hops, each adding delay and a potential failure point.
It is usually a hybrid
In practice the interesting architectures split the work. Cheap, latency-critical first-pass detection runs at or near the edge to decide what is worth keeping; richer analysis, ranking, reframing, and assembly run in the cloud where there is room to be thorough. The design question is not edge or cloud but which stage of the pipeline belongs where.
Where it shows up in practice
A real-time highlight system lives or dies on its end-to-end latency budget, so where each model runs is a first-order decision, not an implementation detail. Zentag AI works from live RTMP and HLS feeds across 50+ sports, where the placement of detection in the pipeline directly determines how fast a moment becomes a publish-ready clip.
Takeaway
Decide your latency budget first, then place inference to meet it. The edge buys speed at the cost of flexibility; the cloud buys scale at the cost of latency; most production systems split the difference deliberately, stage by stage.
