Why a calculator is better than a camera-count table

Frigate does not perform one fixed inference for every frame from every camera. Motion and tracked regions determine how object detection work arrives, so simultaneous activity changes the detector queue dramatically.

A camera-count table can still be useful as a rough tier, but a calculator that asks about activity and detect FPS is less likely to oversize a quiet property or undersize a busy entrance.

Camera count sets the upper envelope

More cameras create more opportunities for simultaneous detector work, especially in commercial or street-facing deployments. The calculator therefore starts with total cameras but does not stop there.

If most cameras cover low-traffic interiors, the system can be sized more modestly than a same-size installation watching roads, gates and checkout areas.

Detect FPS controls how often Frigate evaluates motion regions

Higher detect FPS can improve temporal responsiveness but also increases the potential inference workload. Running every camera at unnecessarily high detect FPS can waste detector capacity.

Tune the detect stream to the problem. The calculator uses the selected FPS to adjust the planning score but does not claim that every configured frame becomes an inference.

Activity factor approximates concurrency

Low, moderate and high activity are used as planning multipliers for how many cameras are likely to request detection around the same time. This is intentionally conservative rather than a claim about exact event frequency.

For critical installations, monitor real detector latency after deployment and revise the hardware tier if activity patterns are more intense than expected.

Model class matters

Tiny and small models generally fit efficient accelerators more easily than large detector models. Frigate's hardware guidance reflects this by describing Hailo as a strong fit for tiny and small models while GPUs provide more flexibility for larger models.

Choose the accuracy and object classes you need before buying hardware. A calculator cannot rescue a mismatch between the desired model and the selected backend.

Host interface can eliminate options

A USB-only appliance cannot accept an internal Hailo M.2 module without redesign. A system with no full PCIe slot cannot accept most discrete GPUs. A Core Ultra host may already contain a usable NPU.

The interface question is therefore treated as a filter, not a preference. Compatible hardware comes before performance ranking.

Enrichments can justify a GPU even when detection does not

If semantic search or large face recognition is important, a supported Intel or NVIDIA GPU can have more system value than a detector-only accelerator.

The calculator can therefore recommend a GPU-oriented architecture for an enrichment-heavy system even when a small Hailo module would be sufficient for object detection alone.

Power priority changes the architecture

A dedicated M.2 accelerator can provide excellent inference per watt, while a discrete GPU brings broader flexibility at higher system power. An integrated Intel NPU can be efficient when you were already buying the host.

Select the power goal based on the full 24/7 server. The calculation does not pretend accelerator TDP equals wall consumption.

Existing hardware should influence the result

The cheapest path is often to use supported hardware already inside the server. Intel iGPU or NPU detection can avoid an add-in purchase, while an existing NVIDIA GPU can be more practical than adding Hailo.

Conversely, a Hailo module can extend a perfectly good older host and postpone a complete system replacement.

The result is a tier, not a product endorsement

The calculator outputs a detector direction and headroom level. The live cards then show products that match the architecture, while exact board dimensions, seller terms and price remain separate buying checks.

This is intentionally different from a quiz that always ends by promoting one SKU.

Validate with real detector latency after deployment

Once Frigate is running, monitor inference time and system utilization under actual activity. That data is more valuable than any pre-purchase estimate.

If latency remains low and queues stay clear, there is no prize for upgrading. If detector saturation appears, you have evidence for a targeted change.

Useful post-deployment evidence includes detector inference time, CPU and GPU utilization, dropped or delayed events, ffmpeg decode load and enrichment queue behavior. Watching those signals separately helps you avoid blaming the accelerator for a bottleneck caused by video decoding, storage I/O or an overloaded host.

Re-check current support before ordering

Frigate evolves quickly, including detector backends, model support and GPU/NPU compatibility. The calculator is grounded in current official documentation, but the final purchase check should always use the latest Frigate pages.

The methodology section links the exact official references so the recommendation remains auditable instead of becoming a static listicle.

Keep a short record of the inputs you used—camera count, detect FPS, activity assumption, model class and enrichment plan—so you can compare the estimate with real telemetry later. If the deployed detector has far more headroom than expected, the next expansion may not need new AI hardware. If activity or model complexity grows, you can rerun the same inputs with the new assumptions and see whether the architecture should move from an integrated Intel path to Hailo or from a dedicated accelerator to a GPU-backed design.