A detector looks at one frame and answers with a class, a score and a box: "cat, 0.83, here". Frigate can run that on several kinds of hardware, and the choice is where new builders spend the most money and the most worry, which is odd, because the whole decision comes down to multiplying two numbers you can read off Frigate's stats page after a day on whatever you already own. The options as they stand in 2026, what we measured on ours, and that arithmetic follow. How we got the Intel iGPU working under WSL2, with the code, is its own page; it is more than most people need.
The four options a home builder has
CPU. Costs nothing, works everywhere, and is the default. Frigate's own docs will tell you it is the slowest option, and it is, but "slow" means tens of milliseconds, not seconds. For two or three cameras at a few frames a second it is fine. Its real cost is that the same cores are decoding your video; on a small machine the two jobs fight.
Intel iGPU through OpenVINO. If your machine has an Intel CPU from roughly 2016 onward, it has a graphics unit inside it that OpenVINO can run detection on. It costs nothing you have not already bought, it runs the same SSDLite model Frigate ships, and it takes the detector load off the CPU cores entirely. This is what we use. Frigate supports it directly on Linux; on Windows under WSL2 it needs the side door described on the next page.
Google Coral (USB or M.2). The classic answer: a small accelerator that runs Frigate's model in a couple of milliseconds. It still works. But the Coral software repositories on GitHub (edgetpu, libedgetpu, pycoral) are archived and read-only, the hardware has been intermittently unavailable for years, and Frigate's community has discussed retiring it from the docs. If you already own one, use it. If you would be buying one today, read Frigate's hardware page for the current word before you do.
Hailo, or a discrete GPU (NVIDIA, AMD, Intel Arc). Real accelerators for real load: dozens of cameras, higher detect frame rates, larger and more accurate models than SSDLite. Worth it when you have that problem, which a cat cam does not.
What we measured
Frigate ran on the CPU of this machine from the day it moved here in August until 2026-08-29. It worked; we did not record a millisecond figure, and we moved off it because detection and decoding were sharing the same six cores and the box had other jobs. On the Intel UHD 630 inside the same i7-8700, through OpenVINO with a half-precision (f16) model:
| Measurement | Value |
|---|---|
| Inference as the detector process sees it | about 8.5 ms steady, 8 to 13 ms range |
Inference as Frigate reports it (inference_speed) | 12.4 ms, including the trip to and from the container |
| Inferences since it went live | 3,291,109 at time of writing |
| Cameras detecting | 7, at 640×360 and 2 fps each (eleven defined; three house cameras record only, one is disabled) |
| Detector busy | about 17 % at the ceiling; less in practice because only frames with motion are sent |
| Frigate's share of the whole CPU | 13.6 % for the whole Linux side (Frigate, go2rtc and every decoder) in the 2026-09-03 capture, with decode still on the CPU |
| Hardware bought | none |
# The only arithmetic that matters:
# sum over cameras of (detect fps) x inference_ms << 1000
7 cameras x 2 fps = 14 frames/s (the ceiling; motion gating makes it less)
14 x 12.4 ms = 174 ms of detector time per second -> ~17 % busy
# For comparison, the same maths with a slow detector:
14 x 60 ms = 840 ms per second -> nearly saturated; skipped_fps climbs
Take the number Frigate shows you for inference_speed, multiply it by the total detect frames per second across all your cameras, and if the answer is well under a thousand milliseconds you have headroom. Frigate's stats page also shows skipped_fps per camera; if it stays at 0.0, the detector is keeping up, whatever it is.
When a real accelerator is worth it
When the arithmetic above stops working. That happens with a lot of cameras (twenty or more at 5 fps is a hundred frames a second), with a desire for higher detect frame rates (fast-moving objects, a road), or with a bigger model than SSDLite because you need it to tell a fox from a cat at forty feet. Those are all legitimate. They are also all things you can discover from the stats page after running on what you have, rather than guessing before you start.
The decision
| If | Then |
|---|---|
| You have 1 to 3 cameras and any modern CPU | Start on the CPU. Look at inference_speed and skipped_fps after a day. |
| Your box has an Intel CPU with integrated graphics, on Linux | Use Frigate's built-in OpenVINO detector on device GPU. Free, and it removes the CPU contention. |
| Same, but you run Frigate on Windows under WSL2 | Frigate cannot see the iGPU from inside the container. Run the detector out of process: the ZMQ detector. |
| You already own a Coral | Use it. It is still the fastest thing per watt. |
| You are about to buy a Coral | Check the hardware page first; try the iGPU before you spend. |
| Twenty-plus cameras, high fps, or a big model | Hailo or a discrete GPU. This is the case those exist for. |
Whatever you pick, it is one block in the config. Ours is four lines under detectors: on the config page, and changing detectors later is changing those four lines. The machine underneath, including why there is no /dev/dri to give Frigate, is on the WSL2 setup page.