Every edge AI computing guide describes N cameras as N decoders as N pipelines. For a property with 25 cameras, the unit of compute is a tile, not a stream.

Edge AI computing means the machine learning inference happens on a device at the property, not in a cloud region. For security cameras the inference is typically computer vision: person, vehicle, loitering, tailgating, package, restricted-area entry. The model was trained in a data center but the matrix multiplies that produce detections run on local silicon (a Jetson-class NPU, a Coral TPU, or an embedded GPU) inside a box on the same LAN as the DVR. The generic edge AI framing you see on Cisco, IBM, NVIDIA, and Red Hat pages is correct as far as it goes, it just stops before the interesting engineering question in security, which is what shape the compute workload takes. A camera system is not a 5G IoT endpoint streaming one sensor. It is 4 to 25 high-bitrate video feeds that all have to be looked at at once. The architecture choice for how to schedule that compute is where the real decisions get made.

Because the dominant cost item in real-time video AI is not inference, it is decoding. Each H.264 or H.265 stream an edge box ingests consumes a hardware decoder slot and a ring buffer of memory. On a Jetson Orin Nano the NVDEC has a bounded decode budget, measured in pixels per second. A 16-camera RTSP ingest at 1080p 15fps puts you against that budget immediately, then you pay the cost of managing 16 asynchronous decoders, 16 stream reconnect timers, 16 credential rotations, and 16 per-stream failure modes. Cyrano's architecture takes one HDMI frame buffer at 1080p 30fps, decodes it once, and treats the tile polygons inside it as the inference workload. The per-camera decoder cost collapses to one. The stream-management complexity collapses to zero. The total pixels-per-second of inference is bounded by the display refresh of the wall monitor, not by the camera count. That is a different compute shape from what the generic edge AI literature describes.

On a 1080p HDMI input (1920x1080) in a 5x5 multiview layout, each tile is about 384x216 pixels before adjustments for on-screen borders, timestamps, and camera labels. In a 4x4 layout, tiles are 480x270. In a 3x3 layout, tiles are 640x360. The Cyrano auto-detects layout from the HDMI frame and maps tile polygons accordingly. Person and vehicle detection at typical parking-lot and entry distances work well at these tile sizes because the targets are already large relative to the tile, not small relative to a full 1080p scene. This differs from direct-stream AI where each camera is analyzed at native resolution and the model has to handle a much wider subject-size distribution. In the tile model, the range narrows, which is one reason inference cost is stable across layouts.

The ceiling on a single unit is tiles per HDMI input rather than cameras per device. The current limit is 25 tiles per HDMI input per unit. Past that, a property plugs in a second unit to a second DVR HDMI output or to a second DVR altogether. The unit itself consumes under 15 watts, takes under 2 minutes to install, runs inference at about 30 frames per second against the composite input, and emits alerts with thumbnails over WhatsApp or SMS within seconds of the event. The unit price is $450 hardware, $200 per month software. No RTSP, no ONVIF, no network reconfiguration, no camera replacement. The compute ceiling and the install ceiling are both tied to HDMI inputs, not camera count, which is how a portfolio of 4-camera and 20-camera properties ends up with the same per-site BOM.

The subjects are larger relative to the frame, which is an accuracy advantage for small-object detection in low light. The tile has less absolute pixel detail than a 4K RTSP pull, which is an accuracy cost for fine-grained tasks like license plate OCR or face recognition at distance. For the detection classes Cyrano ships (person, vehicle, loitering, tailgating, package, restricted-area entry) the tile-sized subject is well within the resolution the model needs. The relevant tradeoff is that tile-based edge AI computing is optimized for the security events a property manager acts on (was someone in the back parking lot for 90 seconds at 2am) rather than for forensic reconstruction that demands native-resolution footage. The native-resolution footage is already preserved on the DVR, the edge compute adds the real-time awareness layer on top of it.

Because the usual edge AI guides are written for IoT vendors, not for security integrators. The canonical edge AI customer in the Cisco or IBM framing is a factory line with one sensor, a retail shelf with one camera, or a telemedicine kit with one medical feed. One sensor, one model, one endpoint. That framing predates the real-world multifamily security camera problem, which starts at 8 cameras and scales to 48. Edge AI computing for security camera systems is a multi-tile scheduling problem dressed up as an IoT problem. The right architecture answer is not more TOPS on a smarter camera, it is a different decomposition of the workload: decode once, partition the frame, run inference per tile. That is the gap between the generic edge AI literature and what actually runs on a real property.

Yes, an IP camera with built-in analytics is an edge AI device in the strict sense. The problem is that those cameras are a greenfield install. A Class B or Class C multifamily property already has 8 to 24 cameras wired, most of them analog HD-CVI or HD-TVI going to a hybrid DVR, bought between 2015 and 2022. Ripping all of those to install new IP cameras with on-board AI costs $50k to $150k per property. A Cyrano unit brings edge AI computing to that existing system without the rip-and-replace, for $450 hardware per property and a 2-minute install. The strategic difference is that the industry's preferred answer is a new camera, and the operator's need is AI on the system they already paid for.

Inference runs on silicon inside the Cyrano unit on the same LAN as the DVR. The HDMI frame buffer never leaves the device. The only outbound traffic is the alert payload, which is a short thumbnail plus metadata (timestamp, zone label, event class, track id, dwell seconds). When the internet goes out, the device keeps running inference, keeps writing events to the on-device index, and queues alerts. When connectivity restores, the queue drains. This matters because the generic cloud-AI architecture fails hard when the property's uplink drops, which happens often on older properties with a single ISP. Edge AI computing in the tile-scheduling model keeps the safety layer live through outages.

One Cyrano unit covers up to 25 tiles from one HDMI output. Most multifamily DVRs expose a single HDMI output driving a wall monitor in the leasing office, so one unit is sufficient through 25 cameras. For larger sites, an HDMI splitter, a second DVR HDMI output, or a second DVR handles the 26th camera and beyond with a second unit. The relevant math for a property manager is not TOPS per dollar, it is tiles-covered per dollar per month: one unit at $450 hardware plus $200 per month software, divided across up to 25 tiles, is $18 per tile hardware and $8 per tile per month in steady state. No comparable direct-stream edge AI device is even close on that axis at that install complexity.

Within about 90 seconds of the unit receiving its first HDMI signal, it has detected the multiview layout, mapped tile polygons, registered per-tile camera identifiers (read from the DVR's on-screen-display text or assigned by the installer in the UI), and begun publishing events. Within the first 10 minutes it has collected enough scene statistics to run the loitering and restricted-area detectors cleanly. Within the first hour it has resolved normal vs unusual motion patterns well enough that the false-positive rate has dropped to steady state. All of this happens on the device. No scene data is uploaded to any training pipeline. The model that runs on the device was trained against a general multifamily dataset in advance, not against this property's specific feed.