Send every video frame to the cloud for analysis and you’ve created a system that’s expensive, slow, and fragile. At 30 frames per second from a single 1080p camera, you’re pushing around 1.5 Gbps of raw data before compression. Multiply that across a factory floor or a logistics facility with dozens of cameras and the numbers become impractical fast — not just for bandwidth but for the processing costs on the receiving end.
Edge AI computer vision solves this by running the inference model where the data originates: on the camera itself, on a nearby box PC, or on a small compute module connected directly to the sensor. The cloud might receive a metadata summary or a flagged event, not a continuous video stream. That changes the economics and the latency profile of the whole system.
The Hardware Tier Decisions
Computer vision at the edge comes down to three broad hardware approaches, each with different capability and cost profiles.
The first is the embedded camera with onboard inference. Manufacturers like Axis, Bosch, and Hikvision all offer camera lines with NPUs or SoCs capable of running pre-trained object detection and classification models directly within the camera housing. Axis’s ARTPEC-9 chip handles real-time analytics through their ACAP platform; Bosch’s VideoAnalytics SDK runs on their traffic and security cameras. These units require no external compute box, use PoE power, and push only metadata or cropped event images to the network. For large-scale deployments where running cables to separate compute boxes is impractical, they’re genuinely compelling.
The second approach uses a companion AI compute box connected to standard cameras. Products built around NVIDIA Jetson Orin or Hailo-8 accelerators handle inference for one to four camera streams simultaneously. This works well when you need more model flexibility than embedded cameras offer, or when you’re retrofitting edge AI onto an existing camera infrastructure. A Hailo-8 module can sustain multiple simultaneous 4K streams at over 26 TOPS, comfortably handling YOLOv8n or similar models in real time.
The third is a small single-board compute module for lower-throughput scenarios. A Raspberry Pi 5 with a Coral USB Accelerator or Hailo-8L M.2 module handles single-stream inference well, particularly for inspection tasks where frame rate can be lower and the processing budget is smaller. Power consumption is low, cost is low, and you can prototype the entire pipeline before committing to purpose-built hardware.
The Model Side: YOLO26 and Deployment Options
YOLO26, released in January 2026, introduced a simplified architecture optimised specifically for CPU-constrained edge hardware. The nano variant, YOLO26-N, delivers approximately 43% faster CPU inference than YOLO11-N while maintaining comparable accuracy on standard object detection benchmarks. For deployments where an NPU or GPU isn’t available — embedded industrial PCs, older hardware, cost-sensitive projects — that improvement is significant.
For NPU-accelerated deployments, the model quantisation step is where things get interesting. Most inference engines accept ONNX format as an intermediate representation, and from ONNX you can compile to the target hardware’s native format: TensorRT for NVIDIA, HAILOv1 for Hailo, TFLite for Coral. Quantising from FP32 to INT8 typically delivers a two-to-four times speedup with accuracy loss of less than one percent on well-calibrated models. Running quantisation calibration on a representative sample of your actual deployment data — not just the training dataset — matters a lot for maintaining detection quality on the specific object classes and lighting conditions you care about.
ONNX Runtime is the practical deployment target for most edge computer vision work. Export your PyTorch or TensorFlow model to ONNX once, and ONNX Runtime handles inference across CPU, CUDA, TensorRT, CoreML, and Hailo backends from the same codebase. You get the flexibility to swap hardware without rewriting inference code, which matters as hardware generations change and costs shift.
Pipeline Architecture
A functional edge computer vision pipeline has a few standard stages. The camera feed comes in over RTSP or MIPI CSI. A preprocessing step handles frame decoding, resizing, normalisation, and batching. The inference engine runs the detection model and produces bounding boxes, class labels, and confidence scores. A postprocessing step applies non-maximum suppression, confidence thresholding, and translates pixel coordinates to real-world geometry if needed. Finally, an event output stage decides what to do with results: write to a local SQLite log, publish an MQTT message, trigger an alarm, or forward to an upstream system.
The key design decision is where to draw the boundary between local processing and upstream communication. For safety applications — PPE compliance on a factory floor, vehicle presence detection at a loading bay — the event trigger can be entirely local. The camera detects a non-compliant worker and immediately triggers an alert without any network dependency. For analytics applications — shelf occupancy over time, footfall counting, quality control statistics — local inference plus periodic batch uploads to a time-series database keeps bandwidth minimal while preserving the data you need.
Use Cases That Work Well at the Edge
Manufacturing quality control is the most mature application area. Defect detection on production lines requires sub-second latency to trigger rejection mechanisms, and the “defective” or “not defective” classification is well within the capability of models running on Hailo or Jetson hardware. Published accuracy figures for edge-deployed quality control models range up to 99.7% on specific defect types in controlled lighting environments, though real-world accuracy is always environment-dependent.
Warehouse safety applications fit naturally too. PPE detection (hard hats, high-visibility vests, safety footwear), forklift proximity monitoring, and pedestrian exclusion zone monitoring all operate on the same basic pipeline: detect objects, classify them, check spatial relationships, trigger alerts. Latency requirements for safety systems typically allow a few hundred milliseconds, which is well within edge inference capability.
Smart retail analytics — customer counting, shelf presence detection, queue monitoring — benefits from edge deployment because it avoids transmitting identifiable video footage to the cloud, which simplifies GDPR compliance considerably. You’re sending counts and occupancy metrics rather than raw video.
What to Watch
Vision Language Models are starting to appear in edge deployments, running on higher-spec hardware like Jetson AGX Orin. The promise is contextual scene understanding rather than rigid class detection: a VLM can describe what’s happening in a scene rather than just flagging predefined object categories. The compute requirement is higher than standard detection models, but the capability gap between cloud and edge VLMs is narrowing as the hardware generation improves.
For most deployments today, a well-tuned YOLO-class model on NPU hardware handles the task better than a larger, heavier model that struggles to meet frame rate requirements. Choose the right model for your hardware, not the fanciest model available.