Frigate中文文档

主题

2025-12-16
3809
14.8m

推荐硬件 ​

摄像头 ​

若摄像头可输出 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 支持多种硬件平台的检测器方案：

通用硬件

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
yolov9-tiny320: 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 架构主机（通常不建议此方式）

NOTE

Intel NPU 部署的实际效果根据社区反馈称较为有限（英文社区讨论），尽管官方目前尚未提供支持。

测试数据显示，NPU 的处理性能仅与核显相当，甚至在某些场景下甚至表现更差。

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

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

名称MobileNetV2 推理时间YOLOv9YOLO-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 mst-320: ~ 16 ms s-320: ~ 20 ms s-640: ~ 40 ms320: ~ 20 ms 640: ~ 46 ms
Intel N100~ 15 mss-320: 30 ms320: ~ 25 ms只能运行一个检测器实例
Intel N150~ 15 mst-320: 16 ms s-320: 24 ms
Intel Iris XE~ 10 mss-320: 12 ms s-640: 30 ms320: ~ 18 ms 640: ~ 50 ms
Intel Arc A310~ 5 mst-320: 7 ms t-640: 11 ms s-320: 8 ms s-640: 15 ms320: ~ 8 ms 640: ~ 14 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 库的 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 优化等更新的特性，则需要进行额外的适配工作。

兼容性参考资料 ​

NVIDIA TensorRT 支持矩阵

NVIDIA CUDA 兼容性

NVIDIA GPU 计算能力

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

NameYOLOv9 推理时间YOLO-NAS 推理时间RF-DETR 推理时间
GTX 1070s-320: 16 ms320: 14 ms
RTX 3050t-320: 15 ms s-320: 17 ms320: ~ 10 ms 640: ~ 16 msNano-320: ~ 12 ms
RTX 3070t-320: 11 ms s-320: 13 ms320: ~ 8 ms 640: ~ 14 msNano-320: ~ 9 ms
RTX A4000320: ~ 15 ms
Tesla P40320: ~ 105 ms

ROCm - AMD GPU ​

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

型号YOLOv9 推理时间YOLO-NAS 推理时间
AMD 780M320: ~ 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 平台 ​

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 需要将差异帧与关键帧合并还原每一帧（更多细节可参阅本文（英文））。 更高分辨率和帧率意味着需要更多算力来解码视频流，因此建议直接在摄像头端设置合适参数以避免不必要的解码负担。

最近更新