Latency and Accuracy at Each Tier

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Every surveillance project decides where its analytics run, and that one choice fixes the system's reflexes and its judgment for years. The earlier articles in this block explained where analysis can run and what each placement costs; this one measures how each placement performs — the response time you can promise and the accuracy you can defend. The stakes are concrete: a perimeter alert that arrives 800 milliseconds late is an alert about something that already happened, and a face-match number quoted without its conditions is a number that will not survive contact with a real scene or a courtroom. Read this before you write a latency requirement into a spec, promise an operator an alert speed, or quote an accuracy figure to a client — because all three are easy to claim and expensive to walk back.

The performance view of the edge-and-cloud split

This block has examined the deployment tiers one at a time. The thesis — that where analytics run defines the system — lives in edge vs cloud analytics. The tiers each have their own article: the camera itself in on-camera edge AI, a server you own in edge servers and on-prem AI appliances, and a rented data center in cloud video analytics cost. The money view of all four tiers on one grid is in the economics of analytics. A commercial overview of the same trade-off is in our blog on edge AI versus cloud AI for video surveillance.

This article does the one job those do not: it puts the two performance numbers — latency and accuracy — on the table for each tier, so you can match the tier to what the use case actually needs. The economics article answers "what does it cost?"; this one answers "is it fast enough, and is it right often enough?" The two questions usually pull in opposite directions, and the art is knowing which one your use case cannot compromise. The numbers here are representative for 2026 hardware and models; treat them as a calibrated starting point to confirm against your own scene, not as fixed guarantees.

Two numbers, not one

Strip the marketing from any analytics pitch and a buyer needs to know exactly two things about performance. Naming them precisely matters, because vendors quote whichever one flatters their product.

The first number is latency — the time from a thing happening in front of the lens to the system raising its hand about it. We call the full path "glass-to-glass" when a human watches it and "detection latency" when software acts on it; either way it is measured in milliseconds (ms), and it decides whether anyone can intervene while the event is still unfolding. The mechanics of the video-transport half of this path belong to the streaming layer, covered in glass-to-glass latency explained; here we care about the analytics half.

The second number is accuracy — how often the system is right, which is never a single figure. It splits into precision (of the alerts it raises, how many are real) and recall (of the real events, how many it catches). A system tuned for high recall cries wolf often; one tuned for high precision stays quiet but misses things. The honest way to state accuracy is a precision/recall pair measured under stated conditions — scene, lighting, angle, distance — never a lone percentage and never "100 percent."

Latency is set mostly by where the compute sits relative to the camera. Accuracy is capped mostly by how much compute the tier can afford to spend per frame, which decides how large a model it can run. Those two sentences are the whole article; the rest is the arithmetic behind them.

Figure 1. The two numbers that define a tier's performance. Latency is set by where the compute sits relative to the camera; accuracy is capped by how much compute the tier can spend per frame. They usually trade against each other.

Latency: four legs, and the one that dominates

Detection latency is a sum of four legs, and the trick is seeing that the network legs — not the AI math — are what blow up the total when analysis happens off-site.

The first leg is capture and encode: the camera's sensor exposes a frame and its chip compresses it. This takes roughly 15 to 33 milliseconds and is the same whichever tier does the analysis, because it happens inside the camera either way. The second leg is getting the frame to the compute: nothing if the model runs on the camera, a millisecond or two across the local network if it runs on a server in the same building, and 40 to 200 milliseconds if it must cross the internet to a cloud region — more, and jumpier, over cellular. The third leg is inference, the AI model actually looking at the frame: 8 to 30 milliseconds for a small model on a camera chip, 10 to 25 milliseconds for a larger model on a real graphics processor (a GPU, the chip built to run AI models fast). The fourth leg is delivering the result back to whatever acts on it: a couple of milliseconds to a local alarm relay, or another 40 to 200 milliseconds back across the internet.

Read those legs together and the punchline is clear: the inference itself is the fastest leg, often quicker in the cloud because the cloud runs on bigger hardware. What sinks cloud latency is the two network crossings wrapped around it. Lay the budget out tier by tier:

Table 1. The detection-latency budget, leg by leg, for the same analytic at three placements. The inference leg is similar everywhere — the cloud even has the fastest chip — but the two internet crossings dominate the cloud total. Cellular or congested links push the cloud row past 1,200 ms. Figures are representative for 2026 hardware (a camera-class NPU, an on-prem GPU server, and a cloud GPU region).

Make the arithmetic concrete with the case that matters most. A person at an easy walking pace covers about 1.4 meters every second. In the roughly 800 milliseconds a cloud round-trip can take, that person moves about:

1.4 m/s × 0.8 s ≈ 1.1 meters — more than a full stride past the line you were watching.

In the roughly 60 milliseconds an on-camera detection takes, the same person moves about 1.4 × 0.06 ≈ 8 centimeters — still effectively standing on the line. That gap is the whole reason latency placement exists.

Figure 2. The same four legs at three placements. Capture, inference, and result delivery are comparable; the cloud's two internet crossings are what stretch its bar from tens of milliseconds to hundreds. The dashed lines mark the 200 ms and 1,000 ms thresholds that decide which tier a use case can tolerate.

The placement rule: 200 milliseconds and one second

Those numbers collapse into a rule of thumb that survives most arguments. If the alert must fire in under 200 milliseconds, the analysis has to run on or beside the camera — there is no budget for an internet round-trip. If the budget is 200 milliseconds to one second, a hybrid works: detect at the edge, confirm or enrich in the cloud. If multiple seconds are acceptable, the cloud is fine and you are optimizing for throughput and cost, not reflexes. A useful midpoint to remember is that "real time" in active surveillance means a response measured in seconds — fast enough for a guard to act while an event unfolds — and the sub-250-millisecond band is where automated, no-human-in-the-loop reactions live.

The on-prem edge server is the quietly underrated tier here, because it buys near-camera latency (everything stays on the local network) while running a far larger model than a camera can host. That combination — tens of milliseconds and a heavy model — is why the middle tier exists, and the deployment economics behind it live in edge servers and on-prem AI appliances.

One reassurance before you commit to a tier: whichever tier produces a detection, it reaches the Video Management System (the software that ingests and manages many camera streams, the VMS) through the same standardized interface — the analytics metadata and events defined by ONVIF Profile M. The tier sets the latency and the accuracy, but not the integration contract, so you can move an analytic from the cloud to the edge without re-plumbing the VMS. For the commercial overview of how ONVIF fits a security system, see our blog on ONVIF profiles in security systems; the engineering depth is in ONVIF explained for engineers.

Accuracy: the tier caps the model, but not the way you would guess

Now the second number. The instinct is that the cloud is "more accurate" because it has unlimited compute. The reality is more interesting, and it has two parts.

The first part is true: model size sets an accuracy ceiling, and the tier's compute budget sets the model size. Object-detection accuracy is usually scored as mean average precision (mAP, a single percentage that rolls precision and recall across many object types into one comparable number on a standard test set). On the public COCO benchmark, a "nano" model small enough to run on a camera chip scores around 40 percent mAP, while an "extra-large" model that needs a serious GPU scores around 55 percent — a gap of roughly 15 percentage points that comes purely from having more compute to spend per frame. A camera draws a few watts; a server GPU draws hundreds. That power gap is the accuracy ceiling, tier by tier.

The second part is the one that overturns the instinct: for the everyday surveillance classes, the gap nearly closes once the model is tuned. Putting a model on a camera means shrinking its numbers from full precision to compact integers — a process called quantization — which trades a little accuracy for a lot of speed. Done crudely, that costs 5 to 8 percent of mAP. Done with calibration data sampled from the actual cameras (a few hundred frames spanning day, night, weather, and crowding), the loss drops under 3 percent, while inference runs 30 to 50 percent faster. For the classes a surveillance system cares about most — person, vehicle, package, left-behind bag — the practical detection rate on the camera is close to indistinguishable from the same model in the cloud.

So where is the cloud genuinely more accurate? Not at spotting a person in one frame, but at reasoning across frames and cameras: re-identifying the same individual across fifty cameras on a campus, describing an unusual scene with a large vision-language model, or correlating events over a shift. Those models are too heavy to fit a camera's memory, so they are the cloud's real job. The clean division is detect at the edge, reason in the cloud — and the model internals behind both live in the AI section, in distillation and quantization for edge video AI and the YOLO production lineage.

Figure 3. Detection accuracy climbs with model size — about 40 percent mAP on a camera-class model to about 55 percent on a cloud-class one — but a well-tuned edge model sits within a few points of its full-size cousin. The cloud's decisive advantage is not raw detection; it is reasoning across many cameras, which no camera chip can host.

Accuracy is a range, not a number — and biometrics are the proof

The most important accuracy rule in surveillance is that there is no such thing as the accuracy. Every analytic delivers a precision/recall range that bends with the scene, and two everyday analytics make the point.

Reading license plates — automatic number-plate recognition (ANPR, also called LPR) — is among the most mature analytics, and in controlled lanes with good lighting it can exceed 99 percent. Yet real-world accuracy is usually quoted at 90 to 98 percent, and it falls further with the conditions every integrator meets: a fast vehicle blurs the characters, a steep camera angle stretches them, low light or headlight glare washes them out, and a dirty or bent plate defeats the read. Same analytic, same software — the number moves 10 points or more on the scene alone.

Face recognition makes the rule impossible to ignore, and it is why this section never quotes a single figure. The United States National Institute of Standards and Technology runs the long-standing Face Recognition Vendor Test, the closest thing the field has to an independent referee. Its measured findings are blunt: at a fixed false-match setting, error rates vary by demographic group by as much as a factor of tens, within-group false-positive rates span enormous ranges across algorithms, and every disparity widens in low-quality imaging. The lesson is not that face recognition does not work; it is that its accuracy is a distribution shaped by the subject and the conditions, so any vendor's single "99-point-something percent" is a lab number that says nothing about your camera at dusk. Because face and plate data are biometric, they are also a legal gate, not just a performance question — the EU AI Act (Regulation (EU) 2024/1689) classifies real-time remote biometric identification as high-risk and Illinois' Biometric Information Privacy Act (740 ILCS 14) requires consent before capture, restrictions that apply no matter which tier runs the model. The deep treatment of both lives in Block 6; the tuning craft lives in tuning analytics: false alarms and accuracy.

One more performance fact survives every tier: detectors raise false alarms, and the cure is rarely a bigger model. Pairing detection with a tracker that enforces temporal consistency — an object must persist across several frames before it counts — cuts false positives sharply, because a one-frame mistake never reaches the operator. A healthy deployment runs under about five false alerts per camera per week, and models drift, so that number creeps up after 12 to 18 months without retraining. None of that is fixed by moving tiers; it is fixed by tuning, which is why accuracy is an operating discipline, not a spec-sheet line.

A common mistake to avoid

The costliest performance error we see is quoting a benchmark number as if it were a field guarantee — promising "55 percent mAP" or "99 percent face match" from a datasheet, then watching the deployed system miss detections at the far end of a dim parking lot. Its twin is putting latency-critical analytics in the cloud to save money, wiring a perimeter or intrusion alert through a 600-millisecond round-trip because the cloud model benchmarked a hair more accurate — and discovering the extra accuracy is worthless when the alert arrives after the intruder is inside. The fix is the same for both: state accuracy as a precision/recall range measured on your own footage, set a latency budget the use case actually requires, and place each analytic on the tier that meets both — detection near the camera where reflexes matter, reasoning in the cloud where judgment matters and seconds are fine.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, and computer-vision software since 2005, across 625+ shipped projects, and the first thing we pin down on a surveillance build is the performance contract: the latency budget each alert must meet and the precision/recall each analytic must hold in the real scene, not the demo. Teams come to us when a cloud pilot that looked accurate turns out to alert too slowly to act on, when an edge model that benchmarked well drifts into false alarms after a year, or when nobody can say which detections truly need sub-200-millisecond reflexes and which can wait for cloud reasoning. We measure each leg of the latency budget and each analytic's accuracy under real load — real lighting, real angles, real camera count — and we lead with the honest range a model holds in your conditions, never a benchmark's best number. Placing detection near the camera and reserving the cloud for cross-camera reasoning routinely delivers both faster alerts and steadier accuracy than a single-tier design built on a datasheet figure.

What to read next

• Edge vs cloud analytics: the deployment decision that defines the system
• The economics of analytics: bandwidth, compute, and storage tradeoffs
• Tuning analytics: false alarms, accuracy, and the operator's reality

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your edge vs cloud latency plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Latency & Accuracy Tier Cheat Sheet — A one-page reference to match each surveillance analytic to the tier that meets its performance budget: the four-leg detection-latency budget (capture/encode, frame-to-compute, inference, result delivery) with edge ~25–120 ms vs cloud….

References

1. National Institute of Standards and Technology (NIST) — "Face Recognition Vendor Test (FRVT) Part 3: Demographic Effects" (NISTIR 8280) and the ongoing FRVT demographics reporting (NISTIR 8429). Measured finding: at a fixed false-match threshold, false-positive rates differ across demographic groups by up to a factor of tens, within-group rates span orders of magnitude across algorithms, and all disparities widen in low-quality imaging — the evidence that face-recognition accuracy is a condition-dependent range, never a single number or "100%". Primary measured benchmark (tier 1). https://pages.nist.gov/frvt/reports/demographics/nistir_8429.pdf
2. ONVIF — "Profile M — Metadata and events for analytics applications" (Profile M Specification v1.1, 2024). Standardizes how an analytic surfaces detections and events to the VMS; a conformant producer can be a camera, an edge server, or a cloud service — so the tier changes latency and accuracy but not the integration interface. Primary standard (tier 1). https://www.onvif.org/profiles/profile-m/
3. IETF — "RFC 3550: RTP, a Transport Protocol for Real-Time Applications" (with RTCP for timing/feedback). RTP carries the surveillance video whose round-trip is the network leg that dominates cloud detection latency; the protocol derivation lives in the Video Streaming section. Primary standard (tier 1). https://www.rfc-editor.org/rfc/rfc3550
4. European Union — "Artificial Intelligence Act, Regulation (EU) 2024/1689, Art. 5 and Annex III" and Illinois General Assembly — "Biometric Information Privacy Act (BIPA), 740 ILCS 14". Real-time remote biometric identification is high-risk/restricted under the AI Act, and BIPA requires consent before biometric capture — the legal gate on the highest-accuracy biometric models regardless of which tier runs them. Primary law (tier 1). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Ultralytics / Roboflow — "YOLO model benchmarks on COCO" (YOLO nano variants ≈ 40% mAP vs extra-large variants ≈ 55% mAP; nano latency in single-digit milliseconds on a T4 GPU). The measured basis for the model-size-sets-accuracy-ceiling claim and the ~15-point edge-to-cloud mAP span. First-party engineering / measured benchmark (tier 3). https://docs.ultralytics.com/models/
6. NVIDIA — "DeepStream SDK and Jetson platform" (GPU-accelerated multi-stream inference; sub-30 ms end-to-end latency on edge hardware with TensorRT-optimized detectors; stream density depends on resolution, frame rate, and model). The basis for the on-prem-edge-server inference-latency row. First-party engineering (tier 3). https://developer.nvidia.com/deepstream-sdk
7. Fora Soft — "Edge AI vs Cloud AI for Video Surveillance: 2026 Latency, Cost & Privacy" (per-leg latency budget: edge end-to-end 25–100 ms vs cloud 300–800 ms; INT8 quantization costs 5–8% mAP, under 3% with quantization-aware training; detect-at-edge, reason-in-cloud). The commercial overview this article is the deep educational layer beneath. Vendor engineering (tier 4). https://www.forasoft.com/blog/article/edge-ai-vs-cloud-ai-video-surveillance
8. Carmen Cloud (Adaptive Recognition) — "ANPR Accuracy Unveiled" and ANPR illumination guidance. Real-world plate-recognition accuracy typically 90–98% (exceeding 99% only in controlled lanes), degrading with vehicle speed (motion blur), camera angle (character distortion), and lighting (glare/low contrast) — the worked example that accuracy is a condition-dependent range. Institutional/vendor (tier 5). https://carmencloud.com/anpr-accuracy-unveiled-how-reliable-is-automatic-number-plate-recognition/
9. Silex Technology — "NPU vs CPU: Edge AI Benchmarks for Real-Time Vision" (camera-class NPUs at 1–6 TOPS run quantized detectors at 15–30 fps; on-device inference in roughly 5–20 ms). Corroboration of the on-camera inference-latency row. Institutional/engineering (tier 5). https://www.silextechnology.com/unwired/npu-vs-cpu-object-detection-benchmarks
10. Omnilert / AIS — "Real-time video surveillance" and "ultra-low-latency video security" (the operative latency bands: under ~200 ms for automated reaction, 200 ms–1 s for hybrid, multi-second acceptable for trend analytics; "real time" in active surveillance means seconds to human action). Institutional (tier 5). https://www.omnilert.com/blog/real-time-video-surveillance
11. IntelliSee — "Perimeter intrusion: the response window" (the 30–90-second window between intrusion and human response, and why avoiding cloud round-trip latency keeps detection inside it). Institutional (tier 5). https://intellisee.com/intelligence/perimeter-intrusion-90-second-window-security-posture/