Engineering guidance, not a report of client results. Code fragments illustrate architecture and require testing before use.
Source-backed engineering and TCO planning guidance by Alector Lab. Cost formulas, Python sizing utilities, and architecture tables are illustrative planning tools rather than reports of specific customer savings or universal hardware benchmarks. Primary sources checked November 3, 2026. Source review: .
Executive answer: match the compute boundary to stream duty cycle and site constraints
Choose on-device edge inference when cameras run continuously, uplink bandwidth is constrained, raw video must remain on site, or decisions require deterministic local latency. Choose cloud vision APIs when image volume is sporadic, cameras trigger only on rare events, and internet connectivity is reliable. For many multi-site operations, the strongest architecture is a hybrid pipeline: a compact local model filters empty frames at the edge and forwards only cropped exceptions or low-confidence events for cloud reasoning and human review.
This guide is Alector Lab's engineering and total-cost-of-ownership (TCO) framework for technical buyers evaluating computer vision development and edge AI and industrial inspection. All cost equations and sizing examples below are illustrative planning models rather than claims of specific customer savings; every deployment must be benchmarked against your own camera streams, lighting conditions, and retention policies.
Before requesting hardware quotes or signing a cloud API commit, ask three operational questions:
- What is the true stream duty cycle? Inspecting five photos per hour from a handheld scanner is an entirely different economic problem from analyzing eight continuous 30-FPS RTSP camera feeds across two shifts.
- What must happen when the WAN link drops? If an inspection line, smart court, or facility gate must continue operating when external internet fails, cloud-only inference is an availability risk.
- Who reviews uncertain detections? Whether inference runs on an on-site module or in a hosted cloud, operators still need a source-linked review queue to inspect flagged frames and correct false alarms.
Why per-frame cloud vision bills compound on continuous camera streams
A common budgeting mistake in computer vision pilots is extrapolating a notebook test on a few hundred static images to a multi-camera facility rollout. In a cloud-only architecture, every frame inspected externally incurs four compounding operational costs:
- Continuous Upstream Bandwidth: Streaming multiple high-definition RTSP feeds out of a warehouse, manufacturing floor, retail store, or sports venue consumes sustained symmetric upload bandwidth that many commercial broadband and cellular connections cannot guarantee without frame drops.
- Cloud Ingress, Decode, and Storage: Hosted pipelines must terminate streams, decode video frames, store temporary clip buffers for auditability, and manage retention lifecycles.
- Per-Frame or Per-Token Inference Charges: When a pipeline samples continuous video, frame volume scales linearly with camera count, frame rate, and operating hours.
- Round-Trip Latency Jitter: Wide-area network traversal adds variable transport delay on top of model inference time, making tight closed-loop actuation or instant on-site feedback unreliable.
To compare an on-premise edge appliance against a cloud vision API over a 24-month horizon, evaluate the break-even month using your measured stream parameters:
Where is the upfront industrial compute and enclosure cost, is initial mounting and fleet setup, is the number of active camera feeds, is the monthly per-stream cloud API and storage spend at the required sampling rate, is dedicated uplink bandwidth cost, and is monthly on-site power, fleet telemetry, and maintenance. When the denominator is positive and falls well inside your hardware depreciation window, local or hybrid edge inference is structurally more economical.
Cloud vision APIs price by image inspection or visual token volume, whereas edge compute amortizes a fixed hardware and site-operations outlay across every frame processed during its service life. Once continuous multi-camera streams run past a few frames per second, network egress and per-call API charges dominate the 24-month budget.
Three reference architectures: on-device SOM, hybrid edge triage, and cloud burst
Rather than treating edge and cloud as an all-or-nothing binary, evaluate three distinct operating boundaries against your workflow requirements:
| Architecture | Data & Privacy Boundary | Typical Stream Profile | Network Dependency | Primary Cost Driver |
|---|---|---|---|---|
| 01. Dedicated Edge SOM | Raw video stays on site; only approved event metadata or redacted clips leave the LAN | Continuous multi-camera RTSP streams requiring low, predictable frame-to-event latency | Operates offline during WAN outages using local ring buffers | Upfront device BOM, quantization engineering, and fleet management |
| 02. Hybrid Edge + Cloud | Local detector filters empty frames; only event crops or ambiguous keyframes go to cloud | Continuous monitoring paired with complex multimodal reasoning or central QA | Local detection survives outages; cloud escalation queues until reconnection | Modest edge box plus event-proportional cloud API and review storage |
| 03. Pure Cloud Vision API | Full images or clips transmitted to external cloud endpoints under agreed provider terms | Burst photo capture, mobile uploads, or low-duty periodic frame sampling | Requires active internet uplink for every inference request | Per-image or per-token API consumption and cloud storage |
Text equivalent of the diagram: Column 01 (On-Device Edge SOM) keeps continuous RTSP decoding and quantized inference on site for low latency, offline survival, and local privacy, trading upfront hardware investment for predictable monthly operating cost. Column 02 (Hybrid Edge + Cloud) runs a lightweight local detector to discard empty frames and sends only event keyframes to cloud vision-language models and central review queues. Column 03 (Cloud Vision API) processes triggered still images or low-duty clips with zero on-site hardware, where cost scales directly with inspection volume.
For workflows that combine real-time tracking with higher-level reasoning, the hybrid pattern often delivers the cleanest trade-off. A quantized local detector—compiled via NVIDIA TensorRT or ONNX Runtime Execution Providers—handles continuous frame triage at the camera boundary, while a cloud or private-VPC multimodal model inspects only the flagged keyframes.
Sizing edge hardware beyond datasheet TOPS: decode, memory bandwidth, and thermal headroom
Buying edge hardware based solely on a vendor's peak sparse INT8 TOPS figure is one of the fastest ways to under-size a field deployment. NVIDIA's Jetson Orin NX module specifications document dedicated hardware video decoders alongside GPU and deep-learning accelerators, and NVIDIA's TensorRT developer guide details how FP16 and calibrated INT8 execution reduce memory footprint and latency compared with unoptimized FP32 weights. However, a complete vision appliance spends significant compute outside the neural network forward pass:
- RTSP Ingest and Hardware Video Decode: Decoding multiple high-bitrate H.264 or H.265 streams can saturate CPU cores if the pipeline fails to bind hardware decode engines or copies uncompressed frames repeatedly between system RAM and accelerator memory.
- Pre-Processing and Spatial Tiling: Undistorting wide-angle lenses, perspective warping, and slicing high-resolution frames into overlapping tiles consume memory bandwidth before inference begins.
- Multi-Object Tracking and Geometric Post-Processing: Kalman filtering, Hungarian association, homography projection, and local ring-buffer video encoding for clip evidence all share CPU and memory resources with the model.
- Thermal Derating in Sealed Enclosures: Industrial fanless enclosures mounted near ceilings or outdoors experience ambient heat soak. Always size hardware so sustained peak load remains comfortably below thermal throttling thresholds.
The illustrative Python module below shows how an engineering team can model concurrent stream capacity and 24-month break-even economics before ordering hardware:
from dataclasses import dataclass
@dataclass(frozen=True)
class StreamWorkload:
streams: int
fps_per_stream: float
hours_per_day: float
days_per_month: float = 30.0
decode_ms_per_frame: float = 1.8
inference_ms_per_frame: float = 6.5
postprocess_ms_per_frame: float = 1.2
@dataclass(frozen=True)
class EdgeVsCloudComparison:
total_fps: float
pipeline_utilization_ratio: float
monthly_cloud_cost_usd: float
monthly_edge_amortized_usd: float
break_even_months: float
def evaluate_vision_tco(
workload: StreamWorkload,
edge_capex_usd: float,
edge_monthly_ops_usd: float,
cloud_cost_per_1k_frames_usd: float,
thermal_headroom_limit: float = 0.75,
) -> EdgeVsCloudComparison:
total_fps = workload.streams * workload.fps_per_stream
frame_budget_ms = 1000.0 / max(total_fps, 0.1)
per_frame_compute_ms = (
workload.decode_ms_per_frame
+ workload.inference_ms_per_frame
+ workload.postprocess_ms_per_frame
)
utilization = per_frame_compute_ms / frame_budget_ms
if utilization > thermal_headroom_limit:
raise ValueError(
f"Workload exceeds thermal headroom ({utilization:.2f} > {thermal_headroom_limit:.2f}). "
"Reduce sampled FPS, quantize with TensorRT INT8/FP16, or split across nodes."
)
frames_per_month = (
total_fps * 3600.0 * workload.hours_per_day * workload.days_per_month
)
monthly_cloud_usd = (frames_per_month / 1000.0) * cloud_cost_per_1k_frames_usd
monthly_edge_amortized = edge_monthly_ops_usd + (edge_capex_usd / 24.0)
monthly_net_delta = max(monthly_cloud_usd - edge_monthly_ops_usd, 1.0)
break_even_months = edge_capex_usd / monthly_net_delta
return EdgeVsCloudComparison(
total_fps=round(total_fps, 1),
pipeline_utilization_ratio=round(utilization, 3),
monthly_cloud_cost_usd=round(monthly_cloud_usd, 2),
monthly_edge_amortized_usd=round(monthly_edge_amortized, 2),
break_even_months=round(break_even_months, 1),
)Commissioning and acceptance tests before purchasing fleet hardware
Before committing capital to edge appliances or long-term cloud contracts, commission a structured feasibility benchmark using your own cameras and operating conditions. Require five verifiable deliverables from the engineering team:
- Condition-Stratified Footage Audit: Evaluate detection and tracking separately across normal daylight, low-light/IR transition, motion blur, glare, and partial occlusion rather than accepting a single aggregate accuracy score. See our guide on building reliable computer vision pipelines for dataset stratification practices.
- End-to-End Latency Breakdown on Target Silicon: Measure RTSP capture, decode, pre-processing, quantized model execution, and event serialization on the exact target module (for details on setting frame budgets, see Vision Transformers at the Edge: How to Set and Test a Latency Budget).
- Network-Outage and Ring-Buffer Recovery Test: Physically disconnect the WAN uplink during active inference to verify that local event rules continue operating, local disk ring buffers rotate safely without filling the drive, and queued telemetry reconciles cleanly without duplicate alerts upon reconnection.
- Operator Review and False-Alarm Ergonomics: Confirm that every alert links back to the source video clip and bounding coordinates so staff can verify exceptions rapidly. Reference our real-time AI video analytics case study for an example of an operational alert and review architecture.
- OTA Rollback and Fleet Health Telemetry: Verify how model weights and container images are updated remotely, how device temperature and dropped-frame counters are monitored, and how an update automatically rolls back if health checks fail.
To explore an interactive estimate for your own stream count before scoping a two-week feasibility sprint, use the calculator on our Edge AI & Industrial Inspection service page or request a technical scoping review.
Frequently asked questions
When is a cloud vision API cheaper than dedicated edge hardware?
Cloud vision APIs are typically more economical when image capture is event-driven and low-volume—such as inspecting a few hundred uploaded delivery photos per day—or during a short discovery phase before camera placement and task requirements are finalized. Once multiple cameras stream continuously for hours each day, local or hybrid edge compute usually reaches break-even rapidly.
Can we run computer vision on our existing security or IP cameras?
Often yes, provided the cameras expose a stable RTSP or ONVIF stream with sufficient resolution, shutter speed, and viewing angle for the target objects. A short footage audit should always precede model training to verify whether compression artifacts, motion blur, or mounting height require optical adjustments.
Why shouldn't we size edge hardware from datasheet TOPS alone?
Peak TOPS numbers measure idealized low-precision matrix operations in isolation. Real vision pipelines are frequently bottlenecked by video decode concurrency, memory bandwidth between CPU and GPU, non-maximum suppression, multi-object tracking, and thermal limits inside fanless enclosures.
What happens to an edge computer vision system when internet connectivity drops?
A properly engineered edge appliance continues running local inference and safety or operational event rules offline, writing flagged clips and structured metadata to a bounded local ring buffer. When connectivity returns, the node synchronizes buffered events using idempotent event keys.
How does Alector Lab scope an edge AI feasibility audit?
We begin with representative footage from your cameras, benchmark quantized candidate models on target edge hardware, model the 24-month cloud-versus-edge operating cost, and deliver a hardware bill of materials, latency report, and known blind-spot register before full deployment begins.
References
What the sources support
- NVIDIA's Jetson Orin NX module documentation specifies dedicated hardware video decode alongside GPU and deep-learning accelerators for embedded edge inference. Jetson Modules specification page, checked November 3, 2026. Hardware architecture capabilities only; actual stream capacity depends on resolution, codec, model architecture, and thermal enclosure.
- NVIDIA's TensorRT developer guide documents FP16 and calibrated INT8 reduced-precision execution to lower latency and memory footprint compared with unoptimized FP32 inference. TensorRT Developer Guide, checked November 3, 2026. Compiler optimization mechanisms; accuracy and latency trade-offs must be validated per model and dataset.
- ONNX Runtime documents hardware-specific execution providers for deploying portable model graphs across edge and server accelerators. ONNX Runtime Execution Providers documentation, checked November 3, 2026. Runtime portability reference; operator coverage and performance must be tested on the target device.
- Jetson Modules Technical Specifications (Jetson Orin NX Series) — NVIDIA Embedded Developer Documentation · checked November 3, 2026
- NVIDIA TensorRT Developer Guide — Working with Reduced Precision — NVIDIA Deep Learning Documentation · checked November 3, 2026
- ONNX Runtime Execution Providers Reference — ONNX Runtime Documentation · checked November 3, 2026
