Frigate 物体检测器Object Detectors配置完全指南从硬件选型、模型尺寸到多后端部署实战【免费下载链接】frigateNVR with realtime local object detection for IP cameras项目地址: https://gitcode.com/GitHub_Trending/fr/frigateFrigate 的核心能力是实时物体检测当运动检测在一帧画面中发现动静后Frigate 会把该区域裁剪出来交给**物体检测器detector**推理识别出画面里出现的是什么人、车、动物等、所在位置与置信度进而驱动目标跟踪、事件与通知。由于推理计算量巨大Frigate 默认把检测放到专门的 AI 加速器或 GPU 上执行。本文以 Frigate 官方 Object Detectors 文档 为主线结合仓库源码系统讲解受支持的检测器类型、模型尺寸选型策略、各硬件平台Edge TPU、Hailo-8、OpenVINO、Apple Silicon、ROCm、ONNX、TensorRT、RKNN、MemryX、Synaptics、AXERA 等的配置方法与底层实现原理帮助你为自有摄像头硬件选择并落地最优的检测后端。检测器Detector到底是什么在理解配置之前先厘清两个概念物体检测Frigate 的运动检测发现帧内有活动后将活动区域region发送给物体检测器检测器返回识别出的目标、其位置以及置信度得分。这些检测结果是后续被跟踪目标、提醒、侦测、通知等一切功能的数据来源。Detector检测器Frigate 运行推理所使用的硬件模型后端组合。检测器是否与你的硬件匹配是影响检测性能最重要的因素之一。从源码角度看Frigate 的所有检测后端都实现自同一个抽象基类 DetectionApi其中声明了两个关键类属性type_key检测器类型字符串如edgetpu、openvinosupported_models该后端支持的模型架构列表如 SSD、YOLO 泛型等。在 frigate/detectors/detector_types.py 中Frigate 会通过pkgutil扫描plugins包下的所有插件模块并收集所有DetectionApi子类用type字段作为 pydantic discriminated union 的分辨器——也就是说YAML 中detectors:下每个名字的type值直接决定实例化哪个后端插件。全部官方内置插件位于 frigate/detectors/plugins/ 目录cpu_tfl.py、edgetpu_tfl.py、openvino.py、onnx.py、tensorrt.py、rknn.py、hailo8l.py、memryx.py、synaptics.py、axengine.py、deepstack.py、teflon_tfl.py等。支持检测的硬件一览官方文档按硬件阵营汇总了可用的检测器后端标注 CommunityBadge 的为社区维护实现其余为官方内置阵营可用后端兼容性最广Coral EdgeTPUUSB / Mini PCIe / M.2Hailo8 / Hailo8LM.2 与树莓派 HATMemryX MX3M.2社区AMDROCmAMD 独显ONNX在-rocm镜像中自动使用 ROCmApple SiliconApple SiliconM1 及更新机型IntelOpenVINOArc 独显 / 核显 / CPUONNX默认镜像中自动使用 OpenVINONvidia GPUONNX-tensorrt镜像中自动使用Nvidia JetsonTensorRT社区ONNX-tensorrt-jp6镜像中自动使用RockchipRKNN带 NPU 的 Rockchip 设备社区SynapticssynapSL 系列 NPU社区AXERAAXEngineAXERA AI 加速器社区仅用于测试CPU detector不推荐用于实际使用两条容易踩坑的规则不同检测器不能混用做物体检测。例如 OpenVINO 与 Coral EdgeTPU 不能在同一时刻同时承担物体检测。这不影响把硬件用于加速其他任务例如语义搜索的向量嵌入、人脸识别等。默认行为如果不写detectors配置Frigate 默认使用单个 CPU 检测器。从源码可见 frigate/config/config.py 中保留了DEFAULT_DETECTORS {cpu: {type: cpu}}用于兼容旧版配置而全新生成的默认配置模板DEFAULT_CONFIG则直接给出ovOpenVINO/CPU 模式加默认 SSDLite 模型见 frigate/config/config.py。如何选择模型尺寸分辨率与变体挑选检测器之外你还需要决定模型的输入分辨率如320x320或640x640以及 YOLOv9 这类模型家族的变体大小tiny、small等。两者共同决定准确度与推理负载的平衡。分辨率320x320 vs 640x640Frigate 针对320x320做了专门优化绝大多数场景下它都是首选。关键原因Frigate 会从整帧中裁剪出运动区域并放大后再送检因此320x320模型对小而远的物体反而更友好而不是更差。640x640更慢、资源占用更高主要收益是当大量目标分散在大范围区域时可以在单次推理里容纳更多目标。较新版本的 Frigate 对640x640模型支持已有改进但320x320仍是几乎所有场景的推荐起点。变体大小tiny / small / medium更大变体逐级更准但更慢。经验法则是——使用你的硬件在不丢检测前提下能跑起的最大模型是否丢检测可在 UI 的System Metrics Cameras页观察。准确度只有在检测器能跟上所有相机的检测负载时才真正有意义。可接受的推理耗时取决于硬件算力推理耗时本身不能单独说明问题因为不同硬件并发能力不同。GPU 可以同时运行同一模型的多个实例30ms 左右的推理耗时也能扛住多路相机而 Google Coral 只能运行单个模型实例因此需要低得多的推理耗时10ms 左右才能跟上。关于自定义训练模型精度最好的检测模型来自贴近 Frigate 真实视野的训练图像——即裁剪到感兴趣区域后的安防摄像头画面。可以自训练或微调模型后作为自定义模型接入见下文各检测器小节Frigate 则通过用户自身上报画面帮助完成训练。对 YOLOv9 而言ssmall变体配320x320分辨率是不错的起点。通用模型配置model段的底层字段无论使用哪个检测器模型相关配置都写在配置顶层的model段而非嵌套在某个detectors项之下。源码 frigate/config/config.py 明确提示并忽略嵌套在 detectors 下的 model 键。模型字段由 ModelConfig 定义核心字段及默认值如下字段默认值含义path无自定义模型文件路径或plus://model_id形式的 Frigate 模型labelmap_path/labelmap.txt把数字类别映射为字符串标签的 labelmap 文件路径width/height320/320模型输入张量的宽高像素labelmap{}内联的标签覆盖 / 重映射合并进标准 labelmapattributes_map默认属性映射目标标签到其属性标签的映射如car - [license_plate]用于附加元数据input_tensornhwc输入张量布局nhwc/nchw等input_pixel_formatrgb输入像素色彩空间rgb/bgr/yuvinput_dtypeint输入张量数据类型float/float_denorm非归一化浮点/intmodel_typessd模型架构ssd/yolox/yolonas/yolo-generic/rfdetr/dfine默认模型路径会按检测器类型自动注入CPU/TFLite 类使用/cpu_model.tfliteEdgeTPU 使用/edgetpu_model.tfliteOpenVINO 使用容器内置的 SSDLite见 frigate/config/config.py。labelmap 的合并逻辑读取文件 内联覆盖见 detector_config.py。仓库中可见的 labelmap 参考文件容器内的/labelmap/coco-80.txt80 类 COCO与/labelmap/coco.txt对应构建产物位于 docker/main/rootfs/labelmap/根目录另有默认的 labelmap.txt。官方内置Officially Supported检测器Edge TPU DetectorCoralEdge TPU 检测器使用 Google Coral delegate 运行 TensorFlow Lite 模型配置时把type设为edgetpu通过device属性指定设备。device的取值遵循 TensorFlow Lite Python API 文档。在源码 edgetpu_tfl.py 中可以看到实现要点load_delegate(libedgetpu.so.1.0, device_config)根据 device 加载 delegate然后创建带该 delegate 的 Interpreter若抛ValueError且模型扩展名不是.tflite会提示只有 .tflite 模型可用于 Coral反之提示未检测到 Edge TPU。加载后还会按model_type区分 SSD 与 YOLOyolo-generic两套预处理/后处理路径YOLO 需要解码 DFL 边界框并做 NMS见 edgetpu_tfl.py。该后端声明支持的模型类型为ssd与yolo-generic。单 USB Coraldetectors: coral: type: edgetpu device: usbUI 操作进入Settings System Detectors and model检测器类型选EdgeTPU并点击Add把 device 设为usb。多个 USB Coraldevice 分别写usb:0、usb:1。detectors: coral1: type: edgetpu device: usb:0 coral2: type: edgetpu device: usb:1Dev Board 原生 Coralv0.9.x之后可能存在兼容性问题device 留空即可。detectors: coral: type: edgetpu device: 单 PCIE/M.2 Coraldevice 设为pci。detectors: coral: type: edgetpu device: pci多 PCIE/M.2 Coraldevice 分别写pci:0、pci:1。混插 Coral可以同时定义 USB 与 PCI 两种接口的 Coral。detectors: coral_usb: type: edgetpu device: usb coral_pci: type: edgetpu device: pci模型选项来自 docs/data/object_detectors_models.yaml 中 edgeTPU 段Mobiledet推荐默认容器内置/edgetpu_model.tflite默认使用若要换模型把文件 bind mount 进容器并用model.path指定。YOLOv9非默认需下载一个 320 输入、int8、edgetpu 专用.tflite同时需要配套的 17 类 COCO labelmap。关键配置是把model.model_type设为yolo-genericwidth/height设为与模型 imgsize 一致的320并指定labelmap_pathdetectors: coral: type: edgetpu device: usb model: model_type: yolo-generic width: 320 # 需与模型 imgsize 一致通常为 320 height: 320 path: /config/model_cache/yolov9-s-relu6-best_320_int8_edgetpu.tflite labelmap_path: /config/labels-coco17.txtHailo-8 / Hailo-8LHailo-8 与 Hailo-8L 检测器可通过 Hailo CLI 自动探测硬件架构若未提供自定义模型会根据探测到的硬件自动选择默认模型。硬件安装可参考安装文档中 Hailo-8 一节镜像构建产物位于 docker/hailo8l/其中有user_installation.sh。默认模型与缓存行为不提供自定义模型时Hailo 检测器在首次启动时从 Hailo Model Zoo 下载默认模型YOLOv6nyolov6n.hef缓存于/config/model_cache/hailo后即可完全离线工作。相关网络要求见网络要求中硬件专属检测模型部分。模型指定方式model.path既可以是本地.hef路径也可以是 URL。检测器会先检查本地路径是否存在存在则直接用不存在或本身就是 URL则从 URL 下载。.hef是 Hailo 编译后的模型格式任何包含 HailoRT 后处理的 Hailo Model Zoo 模型如 Hailo8 支持都可用于此检测器。ROCm 官方推荐用yolo-generic后处理配置。示例配置detectors: hailo: type: hailo8l device: PCIe model: width: 320 height: 320 input_tensor: nhwc input_pixel_format: rgb input_dtype: int model_type: yolo-generic labelmap_path: /labelmap/coco-80.txt # 硬件架构会自动选择默认模型Hailo-8 / Hailo-8L 均默认 yolov6n.hef # 可选用本地路径覆盖默认模型 # path: /config/model_cache/hailo/yolov6n.hef # 也可用自定义 URL 覆盖 # path: https://hailo-model-zoo.s3.eu-west-2.amazonaws.com/ModelZoo/Compiled/v2.14.0/hailo8/yolov6n.hef若使用 SSD 类模型SSD MobileNet v1则需把model_type改为ssd、width/height设为300并显式提供模型 path 或 URL见 object_detectors_models.yaml 的 hailo8l 段。OpenVINO DetectorOpenVINO 检测器在 AMD/Intel CPU、Intel GPU 与 Intel NPU 上运行 OpenVINO IR 模型配置时type设为openvino用device指定设备。常用设备为CPU、GPU、NPU。硬件要求Intel 第 6 代Skylake及更新平台GPU/NPU设备需要受支持的 Intel 平台AMD CPU 虽无官方支持也能运行。NPU GPU 双设备系统的最佳分工若同时拥有 NPU 与 GPU如 Intel Core Ultra建议 NPU 负责物体检测、GPU 负责 enrichment 类任务语义搜索、人脸识别等以获得最佳性能与兼容性。相机很多时单个检测器可能跟不上可定义多个检测器前提是 GPU 资源充足detectors: ov_0: type: openvino device: GPU # 或 NPU ov_1: type: openvino device: GPU # 或 NPUIntel NPU 主机侧要求NPU 固件由宿主内核加载不属于 Frigate 镜像。容器内已捆绑 NPU 所需的其他组件因此永远不要把宿主 NPU 库挂载进容器。Frigate 捆绑了特定版本的 Intellinux-npu-driver宿主固件必须来自该版本或更新版本。固件过旧时可能出现MAPPED_INFERENCE_VERSION is NOT compatible with the ELF报错Expected为固件支持的版本、received为捆绑编译器产出的版本。发行版常打包比 Frigate 所带驱动更旧的固件可用sudo dmesg | grep -i vpu查看宿主构建日期必要时更新。Home Assistant OS 不含 NPU 固件因此无法在 HA OS 下使用 Intel NPU。模型选项OpenVINO 官方默认模型为 SSDLite MobileNet v2容器内/openvino-model/ssdlite_mobilenet_v2.xml由 Intel Open Model Zoo 转换的 FP16 IR另支持自导出 ONNX 的 YOLOv9、YOLOv3/4/7、YOLO-NAS、YOLOX、RF-DETR、D-FINE/DEIMv2。以推荐的 YOLOv9 为例先在构建机导出 ONNX可用仓库外的 yolov9 工程 Docker 多阶段导出MODEL_SIZE可取t/s/m/c/eIMG_SIZE常用320/640然后配置detectors: ov: type: openvino device: GPU # 或 NPU model: model_type: yolo-generic width: 320 # 必须与导出时设置的 imgsize 一致 height: 320 input_tensor: nchw input_dtype: float path: /config/model_cache/yolo.onnx labelmap_path: /labelmap/coco-80.txt注意不同模型家族的输入细节差异详见 object_detectors_models.yaml openvino 段SSDLite 使用bgr/nhwc/int且width300YOLO-NAS 使用bgr输入 nchwYOLOX 的 dtype 为float_denormD-FINE 使用640x640RF-DETR 使用float/nchw。Apple Silicon DetectorApple SiliconM1 及更新机型的 NPU 无法从容器内直接访问因此需要先在宿主机上运行独立的 Apple Silicon detector clientFrigate 通过 ZMQ 与该客户端通信。推荐使用带-standard-arm64后缀的镜像如stable-standard-arm64。部署步骤搭建并运行 Apple Silicon detector client在 Frigate 中配置该检测器并启动 Frigate。实际连接通过 ZMQ 端点完成由社区/第三方客户端实现支撑配置形如detectors: apple-silicon: type: zmq endpoint: tcp://host.docker.internal:5555 model: model_type: yolo-generic width: 320 height: 320 input_tensor: nchw input_dtype: float path: /config/model_cache/yolo.onnx labelmap_path: /labelmap/coco-80.txt注意该 labelmap 使用完整 COCO 标签集的子集仅有 80 个类别即/labelmap/coco-80.txt。相关模型导出方式与 OpenVINO/ONNX 共用YOLOv9、YOLOv3/4/7 等。AMD/ROCm GPU DetectorAMD GPU 支持基于ONNX 检测器实现。要使用 AMD GPU 推理需使用带-rocm后缀的 Frigate 镜像如stable-rocm。构建产物位于 docker/rocm/。Docker 设备透传ROCm 需要访问/dev/kfd与/dev/dri。若 Docker/Frigate 非 root 运行还需要加入video可能还有render、ssl/_ssl组。docker run方式$ docker run --device/dev/kfd --device/dev/dri \ ...Docker Compose 方式services: frigate: ... devices: - /dev/dri - /dev/kfd覆盖 GPU 芯片组版本chipsetAMD/ROCm 软件栈自带的 GPU 驱动有限对较新或缺省的型号需要把 chipset 版本覆盖为较老/通用的版本。ROCm 对核显也无官方支持多数核显可用但需要特殊设置——即配置HSA_OVERRIDE_GFX_VERSION环境变量。rocm 构建已内置两条自动探测映射gfx1031 - 10.3.0gfx1103 - 11.0.0其他芯片组需要自行覆盖例如希望用10.0.0版本$ docker run -e HSA_OVERRIDE_GFX_VERSION10.0.0 \ ...Docker Composeservices: frigate: ... environment: HSA_OVERRIDE_GFX_VERSION: 10.0.0由于芯片组名与驱动无法从 AMD 品牌名直接判断官方给出排查流程先在容器内执行/opt/rocm/bin/rocminfo确认 ROCm 环境正确应同时列出 CPU 与 GPU 及其属性从输出中找到你的 gfx 芯片组版本gfxNNN搜索确定该 gfx 对应的HSA_OVERRIDE_GFX_VERSION取值用该值覆盖仍异常则检查 frigate docker 日志。验证 AMD/ROCm 是否找到 GPU$ docker exec -it frigate /opt/rocm/bin/rocminfo查看 AMD GPU 芯片组版本先 unset 覆盖变量以免干扰结果$ docker exec -it frigate /bin/bash -c (unset HSA_OVERRIDE_GFX_VERSION /opt/rocm/bin/rocminfo |grep gfx)模型转换的已知注意事项AMD GPU 内核在做 mxr 格式模型转换时较易出问题。推荐做法先在配置里禁用物体检测 → 以配置好 onnx 检测器的状态启动 Frigate让主检测模型完成 mxr 转换并缓存到配置目录 → 日志显示转换完成后在 UI 中启用物体检测并确认工作正常 → 最后再在配置中重新启用物体检测。模型支持上与 ONNX 相同但有两条限制D-FINE / DEIMv2 模型不支持YOLO-NAS 在核显上表现不佳。ONNX通用后端ONNX 是开放的模型交换格式。Frigate 支持在CPU、OpenVINO、ROCm、TensorRT上运行 ONNX 模型启动时若可用会自动尝试使用 GPU。关键在于使用与 GPU 匹配的镜像AMD-rocm镜像中 ONNX 检测器自动探测并使用 ROCmIntel默认镜像中自动探测并使用 OpenVINONvidia-tensorrt镜像自动探测 GPU-tensorrt-jp6镜像自动探测 Jetson。多相机负载下可定义多个 ONNX 检测器detectors: onnx_0: type: onnx onnx_1: type: onnxONNX 支持的模型家族最广YOLOv9、RF-DETR、YOLO-NAS、YOLOX、D-FINE/DEIMv2、YOLOv3/4/7各模型的输入细节nchw、rgb/bgr、float/int/float_denorm、320/416/640请以 object_detectors_models.yaml onnx 段中的完整配置为准。其中 YOLO-NAS 权重来自 DeciAI需注意其许可证不允许商业用途。CPU Detector不推荐CPU 检测器在无硬件加速的 CPU 上运行 TensorFlow Lite 模型type设为cpu。官方明确警告不推荐日常使用若没有 GPU 或 Edge TPU用 OpenVINO 的 CPU 模式通常比 CPU detector 更高效。要点解释器线程数由num_threads指定默认3源码 cpu_tfl.py 中可见num_threads字段并回退到 3。容器内置/cpu_model.tfliteSSD MobileNet v2 类作为默认模型如需自定义把文件 bind mount 进容器并设置model.path。每个相机最多配一个 CPU 检测器检测器数量超过相机数不会提升性能。detectors: cpu1: type: cpu num_threads: 3Deepstack / CodeProject.AI Server Detector该检测器通过网络把检测请求转发给 DeepStack 或 CodeProject.AI Server——两者均为可在树莓派、Nvidia Jetson 等设备上运行的开源 AI 平台。注意因为走网络推理时延通常不如 Frigate 原生检测器但仍是稳定可靠的目标检测与跟踪方案。安装CodeProject.AI Server 的安装步骤以其官方文档为准不在 Frigate 文档范围内。配置type为deepstack替换your_codeproject_ai_server_ip与port为你的 AI 服务器地址与端口detectors: deepstack: api_url: http://your_codeproject_ai_server_ip:port/v1/vision/detection type: deepstack api_timeout: 0.1 # 秒验证启动 Frigate 后观察日志中是否有与 CodeProject.AI 相关的报错并可在 Web 界面确认目标是否被正确显示与跟踪。社区支持Community Supported检测器MemryX MX3MemryX MX3 是 M.2 形态的加速模块。Frigate 在兼容硬件平台上提供 MX3 支持type设为memryx。硬件安装参考安装文档中 MemryX 一节镜像脚本见 docker/memryx/user_installation.sh。默认模型为YOLO-NAS 320x320运行时自动下载并编译为 DFP也可把输入调成640x640detectors: memx0: type: memryx device: PCIe:0 model: model_type: yolonas width: 320 # 可设 640 以获得更高分辨率 height: 320 input_tensor: nchw input_dtype: float labelmap_path: /labelmap/coco-80.txt # 可选模型默认由运行时拉取除非用自定义/本地模型否则可省略 path # path: /config/yolonas.zip使用自定义模型先把模型编译成 MemryX 使用的.dfpDataflow Program文件。编译必须用MemryX SDK 2.1在宿主机安装 MemryX Neural Compiler 工具建议在宿主机或独立机器上编译不要装在 Frigate 容器内避免与容器内包冲突建议创建 Python 虚拟环境安装用 MemryX Compiler 编译命令行示例mx_nc -m yolonas.onnx -c 4 --autocrop -v --dfp_fname yolonas.dfp把编译产物打包为.zip其中必须包含.dfp文件某些模型编译器还会额外生成裁剪后处理网络文件名以_post.onnx后缀命名如yolonas_post.onnx。若提供本地model.path且文件存在则优先使用本地文件否则回退下载# 可选本地模型路径.zip。zip 内须包含 # ├── yolonas.dfp .dfp 文件 # └── yolonas_post.onnx 可选仅当模型含裁剪后处理网络时把.zipbind mount 进容器并用model.path指定路径同步把labelmap_path更新为自定义模型的标签。MemryX 还支持 YOLOv9yolo-generic与 YOLOXfloat_denorm、640x640、SSDLite MobileNet v2 等模型完整细节见 object_detectors_models.yaml memryx 段。Nvidia TensorRT DetectorJetsonJetson 设备可用 TensorRT 库做物体检测面向 YOLO 系列模型。因库体积较大该检测器只存在于带-tensorrt-jp6后缀的镜像如stable-tensorrt-jp6。生成模型关键前提TensorRT 使用的模型必须在将要运行的同一硬件平台上预处理生成因此每个用户都要额外执行一步。Frigate 镜像在启动时若发现指定模型不存在会自动生成模型文件产物存放在/config/model_cache文件夹/config通常已映射到宿主目录无需单独映射model_cache除非希望换位置存放。默认不生成任何模型通过YOLO_MODELS环境变量覆盖可用逗号分隔列出多个模型名逐个生成只有当model_cache下缺少对应{model}.trt文件时才会生成因此想强制重建模型需先从 Frigate 数据目录删除该文件。Jetson 带 DLAXavier 或 Orin时在模型名后追加-dla可生成在 DLA 上运行的模型如YOLO_MODELSyolov7-320-dla模型运行在 DLA0Frigate 目前不支持 DLA1DLA 不兼容的层会回退到 GPU。GPU 不支持 FP16 时传USE_FP16False。可用模型列表yolov3-288/416/608、yolov3-spp-288/416/608、yolov3-tiny-288/416、yolov4-288/416/608、yolov4-csp-256/512、yolov4-p5-448/896、yolov4-tiny-288/416、yolov4x-mish-320/640、yolov7-tiny-288/416、yolov7-640/416/320、yolov7x-640/320。示例docker-compose.yml片段转换yolov7-320与yolov7x-640frigate: environment: - YOLO_MODELSyolov7-320,yolov7x-640 - USE_FP16false配置参数type为tensorrt。GPU 透传方法与视频硬件加速中 Nvidia GPU 相同见硬件加速文档。若透传多块 GPU可用device指定检测器使用哪块 GPU——值为容器内nvidia-smi显示的 GPU 索引整数。.trt模型默认放在/config/model_cache/tensorrt路径与尺寸取决于生成的模型detectors: tensorrt: type: tensorrt device: 0 # 默认值选择第一块 GPU model: path: /config/model_cache/tensorrt/yolov7-320.trt labelmap_path: /labelmap/coco-80.txt input_tensor: nchw input_pixel_format: rgb width: 320 # 必须与所选模型匹配如 yolov7-320 - 320、yolov4-416 - 416 height: 320SynapticsSL1680Synaptics SL1680 SoC 提供硬件加速物体检测实现基于 Synaptics model conversionv3.1.0与 sdk v1.5.0。type为synaptics模型以本地路径方式指定。硬件安装参考安装文档中 Synaptics 一节。容器内置/synaptics/mobilenet.synap源自 Synap-release 的 MobileNet SSD224 输入、80 类 COCO作为默认模型。配置中标注为 required 的行是启用检测器所必需的detectors: # required synap_npu: # required type: synaptics # required model: # required path: /synaptics/mobilenet.synap # required width: 224 # required height: 224 # required input_tensor: nhwc # 默认值可选换模型后必须检查 labelmap_path: /labelmap/coco-80.txt # requiredRockchip PlatformRKNNRKNN 检测器支持以下 Rockchip SoCRK3562、RK3566、RK3568、RK3576、RK3588实现基于 Rockchip 的 RKNN-Toolkit2 v2.3.2。安装需先遵循安装文档中的 Rockchip 专属说明构建产物见 docker/rockchip/。默认模型不提供自定义模型时首次启动会从网络下载默认模型缓存后完全离线模型统一存放在config/model_cache/rknn_cache。Frigate 升级后应删除旧模型以释放空间。自定义.rknn模型不要放进rknn_cache直接放model_cache或其子文件夹即可。多检测器与 NPU 核分配相机很多时可用num_cores控制核分配、定义多个检测器。可先查看 NPU 负载$ cat /sys/kernel/debug/rknpu/load NPU load: Core0: 0%, Core1: 0%, Core2: 0%,detectors: rknn_0: type: rknn num_cores: 0 rknn_1: type: rknn num_cores: 0内置模型与参考推理耗时RK3588、3 个 NPU 核测得数据来自官方文档仅供参考模型大小MB推理耗时msdeci-fp16-yolonas_s2425deci-fp16-yolonas_m6235deci-fp16-yolonas_l8145frigate-fp16-yolov9-t635rock-i8-yolox_nano314rock-i8-yolox_tiny618YOLOv9 配置示例model.path填内置模型名会自动下载model: # required # 模型名自动下载或你自己的 .rknn 文件路径 # 可选值 # - frigate-fp16-yolov9-t / -s / -m / -c / -e # - 你的 yolo_model.rknn path: frigate-fp16-yolov9-t model_type: yolo-generic width: 320 height: 320 input_tensor: nhwc labelmap_path: /labelmap/coco-80.txt另有 YOLO-NASdeci-fp16-yolonas_s/m/l输入bgr/nhwc与 YOLOXrock-i8-yolox_nano/tiny、rock-fp16-yolox_nano/tiny输入416等内置模型。把自有 ONNX 模型转换为 rknn转换工具 rknn-toolkit2 需要 x86 机器且目前只有受支持模型才有后处理。转换步骤在 Docker 宿主机把一个或多个ONNX 模型放入目录config/model_cache/rknn_cache/onnx可能需要sudo保存配置文件config/conv2rknn.yaml在容器内执行转换$ docker exec frigate_container_id python3 /opt/conv2rknn.py转换成功后会生成 rknn 模型到config/model_cache/rknn_cache。容器内/opt/conv2rknn.py对应仓库中的 docker/rockchip/conv2rknn.py。配置示例soc: [rk3562, rk3566, rk3568, rk3576, rk3588] quantization: false output_name: {input_basename} config: mean_values: [[0, 0, 0]] std_values: [[255, 255, 255]] quant_img_RGB2BGR: true参数说明soc要为哪些 SoC 构建 rknn 模型的列表不指定时脚本尝试自动探测你的 SoC 并只构建对应模型。quantizationtrue为 8 位整型i8量化false为 16 位浮点fp16。默认false。output_name输出模型名可用变量包括quanti8/fp16、input_basename输入模型基名如输入为my_model.onnx则为my_model、soc构建目标 SoC如rk3588、tk_versionrknn-toolkit2 版本如2.3.0。例output_name frigate-{quant}-{input_basename}-{soc}-v{tk_version}可得到frigate-i8-my_model-rk3588-v2.3.0.rknn。config透传给 rknn-toolkit2 的模型转换参数详见 RKNN Toolkit2 手册的 Model configuration 章节。AXERAAXEngineAXEngine 检测器支持 AX650N 与 AX8850N SoC实现基于 AXera Pulsar2 工具链。type为axengine配置时需要指定模型名。硬件安装参考安装文档中 AXera 一节。默认模型容器/axmodels下内置 yolov9 axmodel首次启动时从 HuggingFace 下载默认模型缓存后完全离线。以默认模型名frigate-yolov9-tiny为例detectors: axengine: type: axengine model: path: frigate-yolov9-tiny model_type: yolo-generic width: 320 height: 320 input_dtype: int input_pixel_format: bgr labelmap_path: /labelmap/coco-80.txt从源码理解检测器如何被装配把上述所有配置串起来的关键逻辑在 frigate/config/config.py遍历self.detectors用TypeAdapter(DetectorConfig)按type判别器把每个检测器字典校验成具体的BaseDetectorConfig子类实例如EdgeTpuDetectorConfig若用户在detectors内嵌套了model会告警并忽略模型应在顶层model段把顶层model配置与检测器的model_path旧式写法合并未显式给path时按type注入默认模型路径CPU/*_tfl→/cpu_model.tfliteedgetpu→/edgetpu_model.tfliteopenvino→ 内置 SSDLite生成ModelConfig处理 Frigateplus://模型下载detector_config.py 会把模型与元数据下载到MODEL_CACHE_DIR即/config/model_cache见 frigate/const.py计算模型哈希并合并 labelmap检测器统一持有detector_config.model运行时各插件通过 DetectionApi 的detect_raw接口逐帧做推理。仓库内还提供YOLO_NAS_Pretrained_Export.ipynbnotebooks/用于把带预训练权重的 YOLO-NAS 导出为兼容 Frigate 的 ONNX 模型可作为上述 OpenVINO/ONNX/Apple Silicon 等后端的模型来源。相关检测后端与配置解析也有对应单元测试可参考frigate/test/test_object_detector.py、frigate/test/test_detection_runners.py 与 frigate/test/test_config.py。选型决策速查有 Coral EdgeTPU直接选edgetpu注意分辨 USB/PCI 接口写法这是低功耗、单实例、需 10ms 级推理的设备。有 Intel CPU/核显/Arc 独显默认镜像选openvinodevice: CPU/GPU/NPUCore Ultra 双 NPUGPU 机器用 NPU 检测 GPU enrichment。有 AMD 独显用-rocm镜像 ONNX 检测器必要时设置HSA_OVERRIDE_GFX_VERSION。有 Nvidia GPU / JetsonJetson 用-tensorrt-jp6镜像 TensorRT先按YOLO_MODELS生成.trtx86 Nvidia 卡在-tensorrt镜像中走 ONNX。Apple Silicon跑第三方客户端 ZMQtype: zmq配-standard-arm64镜像。Rockchip / Synaptics / AXERA / MemryX / Hailo按 SoC 分别使用rknn/synaptics/axengine/memryx/hailo8l注意各平台的模型格式.rknn/.synap/axmodel/.dfp/.hef与下载缓存目录。兜底测试cpu检测器只做连通性验证生产环境优先 OpenVINO CPU 模式。最后再次强调官方给出的重要提示任何检测后端优先保证检测器能跟得上所有相机的负载——准确度高的模型若导致丢检测实际效果反而不如负载轻松的小模型并用 UI 的System Metrics Cameras持续观察检测延迟与丢帧情况来指导模型降级或升级。【免费下载链接】frigateNVR with realtime local object detection for IP cameras项目地址: https://gitcode.com/GitHub_Trending/fr/frigate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考