An edge AI solution is useful only if it compresses 200 raw detections into 6 delivered alerts. That is one number you can audit in five minutes.

TOPS measures silicon throughput, not whether the system produces output anyone reads. Two edge AI solutions with the same 40 TOPS rating can produce a 50:1 compression ratio and a 2:1 compression ratio on the same 16 cameras, because the ratio is determined by the filter stack (zone geometry, dwell thresholds, threat tiering, layout routing), not by the NPU. A 2:1 ratio means the property ops lead is receiving roughly one alert every five minutes from the cameras, which gets muted in a week. A 50:1 ratio is one alert every few hours with a specific thumbnail and zone label attached. Same silicon. Same cameras. Completely different product. TOPS is a hardware spec. Compression ratio is a deployment spec, and deployment is what you are actually buying.

It comes from counting person_detected lines against event_delivered lines across ~50 Cyrano installs on multifamily properties in the 16 to 25 camera range. A typical 16-camera 200-unit Class C property produces roughly 200 to 300 raw person detections per day across residents, vendors, delivery drivers, and passersby. A healthy Cyrano deployment compresses those to 3 to 8 delivered alerts that reach a property manager or guard. 200-300 raw / 3-8 delivered lands in roughly 40:1 to 100:1. The band is not Cyrano marketing; it is what the log files show. An edge AI solution with a different filter stack will produce a different band, and the band it lands in is the best single predictor of whether the channel stays active at month three.

Below a 25:1 compression ratio, an operator on a 16-camera property receives one alert every three to five minutes during daylight hours. That is not a security channel; that is background noise. In our install data, every property that ran below 25:1 for two consecutive weeks ended up either muting notifications entirely, reassigning alerts to a shared inbox that nobody opens, or asking for the system to be disabled. The failure is not that the edge AI solution is inaccurate; the model can still be firing correctly on real people. The failure is that its output-side filter stack is not compressing correctly, so humans never get past the first week. 25:1 is the minimum floor where the alert stream is still attention-compatible with a human on call.

Above 200:1 means the system is not emitting enough alerts to represent what actually happened at the property. On a 200-unit multifamily, 24 hours with only one or two alerts is not a good sign; it means either the zone polygons are drawn too tight (a person walking three feet outside the tripwire produces zero signal), the dwell threshold is set so aggressively that a loiterer standing 14 seconds at a door produces nothing (because the threshold is 15), or the threat classifier is demoting actual trespass events to LOW and filtering them at the outbox. A working edge AI solution has to be tunable down from 200:1 toward 60:1, and that tuning is a configuration artifact, not a model retraining job. If the vendor cannot show you where to loosen the zone or the dwell, the high ratio is silent under-reporting, not excellent precision.

Shell into the unit and count two things in the last 24 hours of logs. First: grep -c person_detected /var/log/cyrano/detector.log. That is the denominator. Second: wc -l /var/lib/cyrano/outbox/pending.ndjson and /var/lib/cyrano/outbox/sent/$(date -d yesterday +%Y-%m-%d).jsonl. Sum those two for the numerator of delivered alerts. Divide. If the number is in 40 to 100, the solution is deployed correctly. If it is below 25 or above 200, something in the filter stack is misconfigured. The audit takes under five minutes once you know where to look, and it works on any edge AI solution that writes detector output and delivered alerts to separate log files, not just Cyrano.

Stage 1 is layout routing: the frame capture identifies which tile the detection came from using the per-layout tile map, and drops detections from tiles that are not mapped to a camera (for example the DVR clock panel). Stage 2 is zone filtering: each camera has one or more zone polygons, and a detection that does not intersect a zone polygon is dropped. Stage 3 is dwell thresholding: a detection must persist across enough frames to pass a per-class dwell threshold (typically 2 seconds for trespass, 15 seconds for loitering, 60 seconds for package_dwell). Stage 4 is threat tiering: the threat classifier marks the event LOW or HIGH, and the outbox only forwards HIGH to the on-call channel while LOW lands in the digest. Those four stages are where the 50:1 to 100:1 compression happens. The model itself is the start of the pipeline, not the end.

It matters for throughput, not for whether the output is useful. A 25-camera feed running at DVR multiview framerate is on the order of 25 to 75 inferences per second depending on the per-tile scheduler, and that load needs a real NPU or GPU on the unit. But once the hardware clears that bar, more TOPS does not produce better compression. Better compression comes from better zone geometry, better dwell thresholds, better threat classification, and better layout-aware tile routing. That is why an edge AI solution that ships with a 100 TOPS chip can still underperform a 40 TOPS system with a well-tuned filter stack on the same cameras. The hardware is necessary. The filter stack is the thing that makes it work.

It should not, because the layout classifier tracks the active layout_id per frame and routes detections through the correct tile map. If it did break, you would see the compression ratio spike: a 4x4 grid collapsing to a 1x1 fullscreen makes one tile fill the whole frame, which makes the overlay mask wrong, which produces phantom detections around the DVR chrome. A functioning edge AI solution must handle this, or it cannot survive a guard drilling into a single camera and back. On a Cyrano unit, the layout_id is tagged on every event in the payload, which means an auditor looking at the outbox log sees exactly which layout was active at the time of each event, and a suspicious compression-ratio spike is traceable to a specific layout transition.

The framing applies to any edge AI solution whose output is alert events routed to humans, whether the compute sits on a camera SoC, an NVR, a dedicated appliance, or a cloud GPU. What is Cyrano-specific is the exact band (40:1 to 100:1), because that band is tied to a particular filter stack on a particular class of property (16 to 25 cameras, multifamily). The underlying principle, compression ratio predicts adoption, is transferable. If you are evaluating any edge AI solution, ask the vendor for their compression-ratio band on a comparable property, and ask how a new installer would tune the ratio down from a cold start. A vendor that cannot answer either question is selling you silicon, not a working deployment.

The top SERP results for edge ai solution are written for an OEM or a platform buyer. They compare TOPS, NPU architectures, INT8 vs FP16 quantization, cloud-vs-edge latency, and list industrial IoT use cases. None of them define a field-verifiable metric that tells a property manager whether the deployed system is useful. Compression ratio fills that gap: it is one number, computable from two log lines on the unit, and it predicts operator adoption better than any hardware spec. This guide is about that reframe, so that the edge AI solution an operator signs for is one they can audit, not one they have to trust.