推荐硬件
摄像头
若摄像头可输出 H.264 编码的视频与 AAC 音频，便能最大限度兼容 Frigate 和 Home Assistant 的全部功能特性。要是摄像头还支持多子码流设置就更完美了，这样可以给物体检测、实时监控、录像存储分别设置不同的清晰度，避免因为格式转换影响设备性能。
建议使用支持 RTSP 流和 ONVIF 功能的摄像头，例如海康威视、TP-Link等。不建议选择萤石等家用摄像头，他们对于 RTSP 的支持并不完善；尤其是不要选择 360 老款等不支持获取 RTSP 流的摄像头，它们无法接入到 Frigate 中。
提示
小米摄像头可以使用第三方应用 micam 将 RTSP 流转发出来给 Frigate 接入。本文不提供 micam 的使用教程。
警告
根据中文社区成员反馈，TP-Link 国内版大部分摄像头的 ONVIF 协议并不标准，可能导致自动追踪、PTZ、双向通话等功能无法正常使用。
如果条件允许的话，应尽可能避免或谨慎选择 WiFi 摄像头，其视频流稳定性较差，易导致连接中断或视频数据丢失。尤其是在有多路摄像头的情况下，传输稳定性会受到极大干扰，甚至会影响到你整个 WiFi 其他设备的使用。（中文相关讨论，需要使用代理访问：https://www.v2ex.com/t/1126166）。
同时，目前市面上大部分的 WiFi 摄像头并不是为长时间稳定推流而设计的。默认情况下，它们仅将视频保存至存储卡亦或者云存储中，对稳定性要求并不高；但 Frigate 非常依赖实时处理视频流，对稳定性的要求极高。并且在连续长时间的获取实时视频流的情况下，摄像头的温度将会非常高，很容易影响连接稳定性。
以及，如果你所在的地方 WiFi 干扰严重（即有非常多 2.4G 的 WiFi，信道干扰严重），也会导致连接不稳定而出现断流，强烈建议你选择有线摄像头，或选择能够稳定通讯的 5Ghz WiFi 摄像头。
服务器
考虑到家用环境，建议使用 N100 等低功耗 CPU 的主机，否则你的电费可能会比以往高很多。这些在淘宝或者闲鱼上都能够找到不错的选择。但需要注意关注一下是否有额外的 M.2 或者 PCIe 接口，因为可以选配 Hailo8 或者 Google Coral 这种 AI 加速器，能够极大的提升检测效率，并且耗电量相比独立显卡要低很多。当然，如果你需要监控的摄像头数量并不多（1-3 路），只使用核显也能够满足需求。但请优先选择 Intel 的产品，根据社区反馈，AMD 核显的配置较为繁琐。
务必使用 Linux 系统，例如 unRAID、TrueNAS、飞牛等专门适配 NAS 的操作系统；也可以直接安装常规的 Linux 发行版，例如 Ubuntu、Debian 等。
需要注意的是，很多 N100 之类的低功耗迷你主机默认预装的是 Windows 系统，你可以参考 入门指南，将系统换为 Linux。
检测器
检测器是专为高效运行物体识别推理而优化的硬件设备。使用推荐检测器可显著降低检测延迟，并大幅提升每秒检测次数。Frigate 的设计理念正是基于检测器硬件实现超低推理延迟：将 TensorFlow 任务卸载到专用检测器上，其速度可提升一个数量级，同时能极大降低 CPU 负载。
信息
Frigate 支持多种硬件平台的检测器方案：
通用硬件
Hailo: Hailo8 和 Hailo8L AI 加速模块有 M.2 接口版本及树莓派 HAT 扩展版本。Hailo8l 参考价约为 600 元。
- 支持多种模型
- 最好使用 tiny/small 尺寸的模型
Google Coral EdgeTPU: Google Coral EdgeTPU 有 USB/M.2 两种版本。M.2 版参考价约为 250 元。
- 社区支持 MemryX: The MX3 M.2 accelerator module is available in m.2 format allowing for a wide range of compatibility with devices.
- Supports many model architectures
- Runs best with tiny, small, or medium-size models
AMD
Apple Silicon
- Apple Silicon: Apple Silicon is usable on all M1 and newer Apple Silicon devices to provide efficient and fast object detection
- Supports primarily ssdlite and mobilenet model architectures
- Runs well with any size models including large
- Runs via ZMQ proxy which adds some latency, only recommended for local connection
Intel
- OpenVino: OpenVino 可以运行在 Intel Arc 独立显卡、Intel 核显以及 Intel 的 CPU
- 支持大部分主流模型
- 推荐使用 tiny/small/medium 尺寸的模型
Nvidia
TensortRT: TensorRT 可以运行在 Nvidia 显卡和 Jetson 开发板上
- 通过 ONNX 支持主流模型
- 可流畅运行包括 large 在内各尺寸模型
- 社区支持Jetson: Jetson devices are supported via the TensorRT or ONNX detectors when running Jetpack 6.
Rockchip社区支持
Synaptics社区支持
- Synaptics: synap models can run on Synaptics devices(e.g astra machina) with included NPUs to provide efficient object detection.
Hailo-8
Frigate 可以使用 Hailo-8 或 Hailo-8L AI 加速器，包括集成了 Hailo 模块的树莓派 5。Frigate 会自动识别你的 Hailo 类型，并且能够在你没设置型号的情况下自动选择并选择模型。
默认模型配置:
- Hailo-8L: 默认模型为 YOLOv6n.
- Hailo-8: 默认模型为 YOLOv6n.
在实际环境中，即使你有多路摄像头，Frigate 也能够表现出一致的性能。与树莓派相比，在 x86 平台上，Frigate 能够获得更高的帧率、吞吐量和更低的延迟。
| 模型名称 | Hailo‑8 推理时间 | Hailo‑8L 推理时间 |
|---|---|---|
| ssd mobilenet v1 | ~ 6 ms | ~ 10 ms |
| yolov9-tiny | 320: 18ms | |
| yolov6n | ~ 7 ms | ~ 11 ms |
Google Coral TPU
警告
如果你是新安装 Frigate，我们不再推荐使用 Coral 设备，除非你对功耗有特别严苛的要求，或者你的硬件无法使用其他可用于目标检测的 AI 加速器。我们建议你改用其他众多受支持的目标检测器之一。
Frigate 仍将为 Coral TPU 提供支持，因为它仍然是执行目标检测模型时能效最高的设备之一。
Frigate 同时支持 USB 和 M.2 两种版本的 Google Coral 加速模块：
- USB 版兼容性最佳，无需安装额外驱动，但缺少自动温控节流功能（长时间高负载可能降频）
- PCIe 和 M.2 需要安装对应的驱动才能运行，参考：https://github.com/jnicolson/gasket-builder 应该有用
单个 Coral 使用默认模型即可处理多路摄像头，能满足大多数用户需求。你可以根据 Frigate 报告的推理速度计算 Coral 的最大性能：
当推理速度为 10ms 时，你的 Coral 最高可处理 1000/10=100，即每秒 100 帧。如果你的检测帧率经常接近这个值，你可以调整动态检测遮罩降低检测区域，或考虑增加第二个 Coral 设备。
OpenVINO - Intel
OpenVINO 检测器类型支持在以下硬件平台上运行：
- 第六代 Intel 平台及更新版本（配备核显 iGPU）
- 搭载 Intel Arc 显卡的 x86 架构主机
- 大多数现代 AMD 处理器（虽然 Intel 官方没提供支持）
- 通过 CPU 运行的 x86 和 Arm64 架构主机（通常不建议此方式）
更多详细信息请参阅 检测器文档
推理速度因使用的 CPU 或 GPU 差异较大，以下是部分已知 GPU 的推理时间示例：
| 名称 | MobileNetV2 推理时间 | YOLOv9 | YOLO-NAS 推理时间 | RF-DETR 推理时间 | 备注 |
|---|---|---|---|---|---|
| Intel HD 530 | 15 - 35 ms | 只能运行一个检测器实例 | |||
| Intel HD 620 | 15 - 25 ms | 320: ~ 35 ms | |||
| Intel HD 630 | ~ 15 ms | 320: ~ 30 ms | |||
| Intel UHD 730 | ~ 10 ms | 320: ~ 19 ms 640: ~ 54 ms | |||
| Intel UHD 770 | ~ 15 ms | t-320: ~ 16 ms s-320: ~ 20 ms s-640: ~ 40 ms | 320: ~ 20 ms 640: ~ 46 ms | ||
| Intel N100 | ~ 15 ms | s-320: 30 ms | 320: ~ 25 ms | 只能运行一个检测器实例 | |
| Intel N150 | ~ 15 ms | t-320: 16 ms s-320: 24 ms | |||
| Intel Iris XE | ~ 10 ms | s-320: 12 ms s-640: 30 ms | 320: ~ 18 ms 640: ~ 50 ms | ||
| Intel Arc A310 | ~ 5 ms | t-320: 7 ms t-640: 11 ms s-320: 8 ms s-640: 15 ms | 320: ~ 8 ms 640: ~ 14 ms | ||
| Intel Arc A380 | ~ 6 ms | 320: ~ 10 ms 640: ~ 22 ms | 336: 20 ms 448: 27 ms | ||
| Intel Arc A750 | ~ 4 ms | 320: ~ 8 ms |
TensorRT - Nvidia GPU
Frigate 能够使用支持 12.x 系列 CUDA 库的 NVIDIA GPU。
最低硬件支持
本系统使用的是具有次版本兼容性的 CUDA 12.x 系列库。主机系统必须安装最低版本号为 >=545 的驱动程序，同时你的 GPU 需支持Compute Capability 5.0 或更高版本，这通常对应的是 Maxwell 架构或更新的 GPU，具体可参考下方链接中的NVIDIA GPU 计算能力。
请确保你的主机系统已安装 nvidia-container-runtime，这样才能将 GPU 设备传递给容器；同时主机上还需为当前 GPU 安装兼容的驱动程序。
较新的 GPU 架构（如支持 INT8 运算和 Tensor Core 的架构）具备更强大的特性，TensorRT 可以充分利用这些优化能力。当模型转换为 trt 文件时，系统会针对你的硬件自动优化兼容的功能特性。当前提供的模型生成脚本中包含一个开关，可用于启用或禁用 FP16 运算。但如果你希望使用 INT8 优化等更新的特性，则需要进行额外的适配工作。
兼容性参考资料
推理速度会因 GPU 和所用模型的不同而有显著差异。 tiny的变体比对应的非 tiny 模型更快，以下是一些已知示例：
| Name | YOLOv9 推理时间 | YOLO-NAS 推理时间 | RF-DETR 推理时间 |
|---|---|---|---|
| GTX 1070 | s-320: 16 ms | 320: 14 ms | |
| RTX 3050 | t-320: 15 ms s-320: 17 ms | 320: ~ 10 ms 640: ~ 16 ms | Nano-320: ~ 12 ms |
| RTX 3070 | t-320: 11 ms s-320: 13 ms | 320: ~ 8 ms 640: ~ 14 ms | Nano-320: ~ 9 ms |
| RTX A4000 | 320: ~ 15 ms | ||
| Tesla P40 | 320: ~ 105 ms |
ROCm - AMD GPU
通过使用 rocm 检测器，Frigate 可以工作在大部分 AMD 的显卡上。
| 型号 | YOLOv9 推理时间 | YOLO-NAS 推理时间 |
|---|---|---|
| AMD 780M | 320: ~ 14 ms | 320: ~ 25 ms 640: ~ 50 ms |
| AMD 8700G | 320: ~ 20 ms 640: ~ 40 ms |
社区支持的检测器
MemryX MX3
Frigate supports the MemryX MX3 M.2 AI Acceleration Module on compatible hardware platforms, including both x86 (Intel/AMD) and ARM-based SBCs such as Raspberry Pi 5.
A single MemryX MX3 module is capable of handling multiple camera streams using the default models, making it sufficient for most users. For larger deployments with more cameras or bigger models, multiple MX3 modules can be used. Frigate supports multi-detector configurations, allowing you to connect multiple MX3 modules to scale inference capacity.
Detailed information is available in the detector docs.
Default Model Configuration:
- Default model is YOLO-NAS-Small.
The MX3 is a pipelined architecture, where the maximum frames per second supported (and thus supported number of cameras) cannot be calculated as 1/latency (1/"Inference Time") and is measured separately. When estimating how many camera streams you may support with your configuration, use the MX3 Total FPS column to approximate of the detector's limit, not the Inference Time.
| Model | Input Size | MX3 Inference Time | MX3 Total FPS |
|---|---|---|---|
| YOLO-NAS-Small | 320 | ~ 9 ms | ~ 378 |
| YOLO-NAS-Small | 640 | ~ 21 ms | ~ 138 |
| YOLOv9s | 320 | ~ 16 ms | ~ 382 |
| YOLOv9s | 640 | ~ 41 ms | ~ 110 |
| YOLOX-Small | 640 | ~ 16 ms | ~ 263 |
| SSDlite MobileNet v2 | 320 | ~ 5 ms | ~ 1056 |
Inference speeds may vary depending on the host platform. The above data was measured on an Intel 13700 CPU. Platforms like Raspberry Pi, Orange Pi, and other ARM-based SBCs have different levels of processing capability, which may limit total FPS.
Nvidia Jetson
Frigate 支持所有的 Jetson 开发板，从经济实惠的 Jetson Nano 到性能强劲的 Jetson Orin AGX 都有覆盖。能够通过专门的编解码预设参数来调用 Jetson 视频硬解码功能进行加速。如果还配置了TensorRT 检测器则会利用 Jetson 的 GPU 和 DLA（深度学习加速器）执行目标检测任务。
推理速度会因 YOLO 模型、Jetson 平台型号及 NVPMode（GPU/DLA/EMC 时钟频率）配置而异。大多数模型的典型推理时间为 20-40 毫秒。 DLA（深度学习加速器）相比 GPU 能效更高但速度略慢，因此启用 DLA 会降低功耗，但会轻微增加推理耗时。
Rockchip 平台
Frigate 支持所有 Rockchip 开发板的硬件视频加速功能，但硬件目标检测仅限以下型号支持：
- RK3562
- RK3566
- RK3568
- RK3576
- RK3588
| Name | YOLOv9 推理时间 | YOLO-NAS 推理时间 | YOLOx 推理时间 |
|---|---|---|---|
| rk3588 3 cores | ~ 35 ms | small: ~ 20 ms med: ~ 30 ms | nano: 18 ms tiny: 20 ms |
| rk3566 1 core | small: ~ 96 ms |
启用全部 3 个核心的 RK3588 芯片运行 YOLO-NAS S 模型时，典型推理时间为 25-30 毫秒。
Synaptics
- Synaptics Default model is mobilenet
| Name | Synaptics SL1680 Inference Time |
|---|---|
| ssd mobilenet | ~ 25 ms |
| yolov5m | ~ 118 ms |
Frigate 如何分配 CPU 和检测器的工作？（通俗说法）
就好比家里的监控要盯着院子，别让野猫进来捣乱。负责处理信息的小 C（也就是 CPU）和专门认东西的小识（也就是那个检测器），俩得搭伙干活。
小 C 自己不太会认东西，看见有动静，也分不清是野猫还是风吹树叶，得琢磨半天。但小识不一样，它对认猫这块特别拿手，扫一眼就知道是不是。可小识也就这一个本事，别的啥也干不了。
所以他俩就商量着分工：小 C 先盯着监控画面，只要瞅见有啥在动，赶紧拍张照给小识。小识一看，很快就能说清那是啥。虽说大部分时候都是瞎报，不是树影晃了就是塑料袋飞过去了，但这不，总算逮着一回真的野猫了，任务总算是完成了。
提高摄像头分辨率会发生什么？
可后来发现，院子里还是有野猫来过的痕迹，这咋回事啊？小 C 明明一直盯着的。查了监控才知道，原来是监控镜头不行，视野窄，还模糊，跟蒙了层灰似的，好多地方都没拍到。后来换了个清楚的大镜头，整个院子都能看得明明白白。
但问题也跟着来了。小 C 这边忙得够呛，因为要看的地方比以前大了好几倍，每个角落都得盯着，稍有点风吹草动就得拍照，手忙脚乱的。小识那边也不轻松，现在拍的照片清楚得很，细节太多了，它得一点点看，辨认是不是藏着野猫，比以前费劲多了。
其实这就跟调高监控分辨率一个道理，分辨率一高，小 C 要处理的东西就多了去了，累得不行。小识虽说厉害，可精力也有限，尤其家里摄像头多的时候，根本顾不过来。
所以 Frigate 就想了个办法，让小 C 先当 “哨兵”，就盯着有没有动静，只有发现有东西在动，再把画面给小识去仔细辨认。这样一来，就算家里装了好几个摄像头，也能盯得过来，俩也不至于被累垮。
使用 Coral 加速器时，硬件加速参数（hwaccel args）还有用吗？
当然有用！因为 Coral 并不能进行视频编解码工作。
解压视频流会消耗大量 CPU 资源。视频压缩使用关键帧（I 帧）传输完整画面，后续帧只记录差异，CPU 需要将差异帧与关键帧合并还原每一帧（更多细节可参阅本文（英文））。 更高分辨率和帧率意味着需要更多算力来解码视频流，因此建议直接在摄像头端设置合适参数以避免不必要的解码负担。