跳到主要内容

推荐硬件

摄像头​

若摄像头可输出 H.264 编码的视频与 AAC 音频，便能最大限度兼容 Frigate 和 Home Assistant 的全部功能特性。要是摄像头还支持多子码流设置就更完美了，这样可以给物体检测、实时监控、录像存储分别设置不同的清晰度，避免因为格式转换影响设备性能。

建议使用支持RTSP流和ONVIF功能的摄像头，例如海康威视、TP-Link等。不建议选择萤石等家用摄像头，他们对于RTSP的支持并不完善；尤其是不要选择360老款、小米等不支持获取RTSP流的摄像头，它们无法接入到Frigate中。

注意

根据中文社区成员反馈，TP-Link国内版大部分摄像头的ONVIF协议并不标准，可能导致自动追踪、PTZ、双向通话等功能无法正常使用。

如果条件允许的话，应尽可能避免或谨慎选择WiFi摄像头，其视频流稳定性较差，易导致连接中断或视频数据丢失。尤其是在有多路摄像头的情况下，传输稳定性会受到极大干扰，甚至会影响到你整个WiFi其他设备的使用。（中文相关讨论，需要使用代理访问：https://www.v2ex.com/t/1126166）。如果你所在的地方WiFi干扰严重（即有非常多2.4G的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支持多种硬件平台的检测器方案：

通用硬件

AMD

Intel

Nvidia

Rockchip

  • RKNN: 需搭载NPU的瑞芯微芯片

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
yolov6n~ 7 ms~ 11 ms

Google Coral TPU​

Frigate 同时支持 USB 和 M.2 两种版本的 Google Coral 加速模块：

  • USB版兼容性最佳，无需安装额外驱动，但缺少自动温控节流功能（长时间高负载可能降频）
  • PCIe 和 M.2 需要安装对应的驱动才能运行，参考：https://coral.ai

单个 Coral 使用默认模型即可处理多路摄像头，能满足大多数用户需求。你可以根据 Frigate 报告的推理速度计算 Coral 的最大性能：

当推理速度为 10ms 时，你的 Coral 最高可处理 1000/10=100，即每秒 100 帧。如果你的检测帧率经常接近这个值，你可以调整动态检测遮罩降低检测区域，或考虑增加第二个Coral设备。

OpenVINO​

OpenVINO 检测器可在以下硬件平台上运行：

  • 带集成显卡的第六代及以上 Intel 平台
  • 配备 VPU 硬件的 x86 & arm64 主机（如 Intel NCS2）
  • 多数现代 AMD CPU（虽然 Intel 官方未提供支持）

更多详细信息请参阅 检测器文档

推理速度因使用的CPU或GPU差异较大，以下是部分已知GPU的推理时间示例：

名称MobileNetV2 推理时间YOLO-NAS 推理时间RF-DETR 推理时间注释
Intel HD 53015 - 35 ms只能运行一个检测器实例
Intel HD 62015 - 25 ms320: ~ 35 ms
Intel HD 630~ 15 ms320: ~ 30 ms
Intel UHD 730~ 10 ms320: ~ 19 ms 640: ~ 54 ms
Intel UHD 770~ 15 ms320: ~ 20 ms 640: ~ 46 ms
Intel N100~ 15 ms320: ~ 25 ms只能运行一个检测器实例
Intel Iris XE~ 10 ms320: ~ 18 ms 640: ~ 50 ms
Intel Arc A380~ 6 ms320: ~ 10 ms 640: ~ 22 ms336: 20 ms 448: 27 ms
Intel Arc A750~ 4 ms320: ~ 8 ms

TensorRT - Nvidia GPU​

Frigate能够使用支持12.x系列CUDA库的英伟达GPU。

最低硬件支持​

使用的是12.x系列CUDA库，它们具有次版本兼容性。主机系统上的最低驱动程序版本必须为>=545。此外，GPU必须支持5.0或更高的计算能力。这通常对应于Maxwell-era或更新的GPU，请查看下面链接的NVIDIA GPU计算能力表。

确保主机系统安装了nvidia-container-runtime，以便将GPU传递给容器，并且主机系统为您的GPU安装了兼容的驱动程序。

较新的GPU架构具有一些改进的功能，TensorRT可以从中受益，例如INT8操作和张量核心。当模型转换为trt文件时，与您的硬件兼容的功能将得到优化。目前，用于生成模型的脚本提供了一个开关来启用/禁用FP16操作。如果您希望使用诸如INT8优化等较新的功能，则需要做更多操作。

兼容性参考资料​

NVIDIA TensorRT支持矩阵

NVIDIA CUDA兼容性

NVIDIA GPU计算能力

推理速度会因GPU和所用模型的不同而有显著差异。 tiny的变体比对应的非tiny模型更快，以下是一些已知示例：

NameYOLOv7 推理时间YOLO-NAS 推理时间RF-DETR 推理时间
GTX 1060 6GB~ 7 ms
GTX 1070~ 6 ms
GTX 1660 SUPER~ 4 ms
RTX 30505 - 7 ms320: ~ 10 ms 640: ~ 16 ms336: ~ 16 ms 560: ~ 40 ms
RTX 3070 Mobile~ 5 ms
RTX 30704 - 6 ms320: ~ 6 ms 640: ~ 12 ms336: ~ 14 ms 560: ~ 36 ms
Quadro P400 2GB20 - 25 ms
Quadro P2000~ 12 ms

AMD GPU​

通过使用 rocm 检测器，Frigate可以工作在大部分AMD的显卡上。

型号YOLOv9 推理时间YOLO-NAS 推理时间
AMD 780M~ 14 ms320: ~ 25 ms 640: ~ 50 ms
AMD 8700G320: ~ 20 ms 640: ~ 40 ms

社区支持的检测器​

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 platform​

Frigate 支持所有 Rockchip 开发板的硬件视频加速功能，但硬件目标检测仅限以下型号支持：

  • RK3562
  • RK3566
  • RK3568
  • RK3576
  • RK3588
NameYOLOv9 推理时间YOLO-NAS 推理时间YOLOx 推理时间
rk3588 3 cores~ 35 mssmall: ~ 20 ms med: ~ 30 msnano: 18 ms tiny: 20 ms
rk3566 1 coresmall: ~ 96 ms

启用全部3个核心的RK3588芯片运行YOLO-NAS S模型时，典型推理时间为25-30毫秒。

Frigate如何分配CPU和检测器的工作？（通俗说法）​

就好比家里的监控要盯着院子，别让野猫进来捣乱。负责处理信息的小 C（也就是 CPU）和专门认东西的小识（也就是那个检测器），俩得搭伙干活。

小 C 自己不太会认东西，看见有动静，也分不清是野猫还是风吹树叶，得琢磨半天。但小识不一样，它对认猫这块特别拿手，扫一眼就知道是不是。可小识也就这一个本事，别的啥也干不了。

所以他俩就商量着分工：小 C 先盯着监控画面，只要瞅见有啥在动，赶紧拍张照给小识。小识一看，很快就能说清那是啥。虽说大部分时候都是瞎报，不是树影晃了就是塑料袋飞过去了，但这不，总算逮着一回真的野猫了，任务总算是完成了。

提高摄像头分辨率会发生什么？

可后来发现，院子里还是有野猫来过的痕迹，这咋回事啊？小 C 明明一直盯着的。查了监控才知道，原来是监控镜头不行，视野窄，还模糊，跟蒙了层灰似的，好多地方都没拍到。后来换了个清楚的大镜头，整个院子都能看得明明白白。

但问题也跟着来了。小 C 这边忙得够呛，因为要看的地方比以前大了好几倍，每个角落都得盯着，稍有点风吹草动就得拍照，手忙脚乱的。小识那边也不轻松，现在拍的照片清楚得很，细节太多了，它得一点点看，辨认是不是藏着野猫，比以前费劲多了。

其实这就跟调高监控分辨率一个道理，分辨率一高，小 C 要处理的东西就多了去了，累得不行。小识虽说厉害，可精力也有限，尤其家里摄像头多的时候，根本顾不过来。

所以 Frigate 就想了个办法，让小 C 先当 “哨兵”，就盯着有没有动静，只有发现有东西在动，再把画面给小识去仔细辨认。这样一来，就算家里装了好几个摄像头，也能盯得过来，俩也不至于被累垮。

使用 Coral 加速器时，硬件加速参数（hwaccel args）还有用吗？​

当然有用！因为Coral并不能进行视频编解码工作。

解压视频流会消耗大量CPU资源。视频压缩使用关键帧（I帧）传输完整画面，后续帧只记录差异，CPU需要将差异帧与关键帧合并还原每一帧（更多细节可参阅本文（英文））。 更高分辨率和帧率意味着需要更多算力来解码视频流，因此建议直接在摄像头端设置合适参数以避免不必要的解码负担。