Frigate 真正开始有用的时刻，往往出现在团队意识到“存视频”和“判断视频”并非同一个问题之后。许多消费级方案会把两件事缝在一起：向厂商付费，把画面上传，等手机推送，再寄望于默认告警逻辑已经足够好。Frigate 走的是另一条更窄、也更像工程系统的路。它是一套 self-hosted NVR，它的价值来自把视频路径、object detection 路径与 review 路径都留在自己控制的基础设施上。[1][4][5][8]

这层理解很重要，因为 Frigate 并不只是“给安防摄像头加上 AI”。真正有意思的设计，在于它把监控重新组织成一条留在本地的事件回看管线。摄像头可以送出一条 detect 流，也可以按需要送出另一条 record 流；detector 硬件决定对象识别能跑得多快；而 UI 则围绕 review items 展开，而并非让人陷在一整片原始录像里反复拖时间轴。[1][3][5] 若要给 Frigate 写一篇项目介绍，最应当先讲清的正是这条运行逻辑。

截至 2026-05-06T17:03:53Z UTC，GitHub API 显示 blakeblackshear/frigate 公开仓库拥有 31,779 stars、3,069 forks、121 个 open issues，最近一次 push 时间是 2026-05-06T16:01:54Z。[6] 公开 release 流中，v0.17.1 发布于 2026-03-22，此前的 v0.17.0 发布于 2026-02-27。[7] 这些数字无法单独证明 Frigate 适合所有安装场景，却足以说明这并非一个停在旧教程里的项目，它仍在被维护，也仍在逼近更清楚的操作边界。

配图说明：题图使用的是一张真实 PTZ 安防摄像机照片，而并非渲染出来的智能家居图标，或光洁的移动端界面样张。[9] 这更贴合本文的重心。Frigate 的核心选择带着很强的物理与基础设施质地：摄像头输出什么流，哪块硬件负责解码，哪种 detector 负责推理，哪些内容会被保留，哪些内容会进入人工回看。

真正的产品是 review 纪律，而并非原始录像堆积

Frigate 的 review 文档把它的产品形状写得很直接。review items 可以按日期、对象类型与摄像头过滤；而在当前版本里，一个 review item 指的是某一段时间内有一个或多个 tracked objects 处于活跃状态，而并非过去那种“一段录像只对应一个事件块”的做法。[5] Frigate 还会把 review items 分成 alerts 与 detections，然后鼓励操作者用 zones 把它们进一步收窄，让系统更关心车道、院门、门口这类位置，而并非整幅画面里任何一块会动的区域。[5]

表面上看，这像是 UI 设计细节；放在操作层面看，它其实是整套系统的论点。一个好用的 NVR，并不只是把视频越存越多。一个好用的 NVR，应当能把注意力压缩到值得检查的时段里，同时又不把底层录像藏起来。Frigate 的 review 模型正是在做这件事。它让操作者先得到一条更小、更像任务列表的检查队列，再在需要时点开更高分辨率、更完整的记录。[5]

recording 文档又从存储这边把同一件事说深了一层。recordings 存在 /media/frigate/recordings 下，路径按 UTC 时间分层，视频直接从摄像头流写入，不经过 re-encoding，而清理时则取 recording retention 与 tracked object retention 中更大的那一个值作为删除依据。[4] 这和云摄像头方案里那种只有一个“保留 30 天”滑块的体验，完全并非一种系统哲学。Frigate 要求操作者按管线来理解它：采集、检测、回看、保留、过期。[4][5]

在模型之前，摄像头拓扑已经决定了资源账本

Frigate 的 camera setup 指南写得相当直白，这也是它和许多包装得更像“智能产品”的系统之间最重要的差别。Detection 是 Frigate 唯一真正会解码并用于处理的那条流；推荐 detect 帧率是 5 fps，多数场景下上限建议到 10 fps；而 recording 流则通常应当是你愿意长期保存的最高分辨率，帧率建议在 15 fps 左右。[1] 同一页还写到，detection 与 recording 流应当共享相同 aspect ratio；更高分辨率也不会自动让 detection 更准，因为 Frigate 会先裁剪 motion 区域，再把它缩放到模型的工作尺寸，文档里把这一尺度写成 320x320。[1]

正因为如此，Frigate 最适合被理解成一套 camera pipeline，而并非一款泛化的 computer vision 应用。第一批真正有效的性能收益，并不来自追逐更花哨的 detector，而来自给 detection 配一条便宜的 substream，给 recording 留一条质量更高的主流，再让两条流维持一致的画面比例，使预览与回放不至于变形或错位。[1] 如果部署时忽略了这一层，把每台摄像头的一路 4K 大流同时塞给检测、存储与展示，系统会在“AI”问题真正开始之前，就先把 CPU、网络与 I/O 花在错误的地方。

recommended hardware 文档把同样的现实感继续推开。Frigate 偏好 H.264 视频与 AAC 音频，喜欢支持 multiple substreams 的摄像头，也明确提醒不要依赖 Wi-Fi cameras，因为流不稳定就意味着连接丢失与视频丢失。[2] 这条提醒重要。Frigate 安装里真正先要回答的问题，往往并非“该选哪一个模型来识别人”，而是“这些摄像头能不能稳定地输出彼此分工清楚的几路视频流，让 detection、recording 与 viewing 各自拥有不同的成本结构”。[1][2]

detector 选择，其实是一道硬件采购题

detector 文档与硬件指南共同把第二条架构线索摆得很清楚：Frigate 从一开始就假定，object detection 在理想情况下应当尽量卸载到专门的加速硬件上。[2][3] 文档列出了 Coral Edge TPU、Hailo、Intel 硬件上的 OpenVINO、Nvidia GPU 以及其他几条路线，同时也明确说明，当活跃摄像头数量增加时，一个 detector 未必跟得上，若 GPU 或 NPU 资源足够，可以定义多个 detectors 并行工作。[2][3]

这意味着，采用 Frigate 有一部分其实是在做采购判断。若团队手上是一台 Intel mini PC，那么 OpenVINO 往往就是自然路径；若已经有 Coral 或 Hailo 模块，detector 配置会顺着那块硬件展开；若准备扩展到更多摄像头，那么 detector 的数量与平台能力，很快会比 Docker 容器本身更重要。[2][3] 软件是开源的，体验却仍然会被非常实体的选择塑造：CPU 指令集、GPU 可得性、NPU 接入、PCIe 插槽、存储布局，全都参与最后的结果。

也正因为这一点，独立媒体对 Frigate 的外部判断，并没有把它写成一个小型玩具功能。Heise 把它描述成 Unifi Protect 与 Synology Surveillance Station 一类系统的 self-hosted open-source alternative，并且强调了本地处理与 accelerator support。[8] 这个外部判断是准确的。Frigate 最强的论点从来并非“新鲜”，而是整条监控链可以留在操作者自己的基础设施上，同时又足够有选择性，足够适合每天真实使用。[8]

Frigate 适合什么地方，也在哪些地方开始变硬

Frigate 最强的场景，是操作者已经接受 RTSP-capable cameras、本地存储、显式 review policy，并且愿意把 streams、detectors 与 retention 一起调顺的场景。[1][2][3][4][5] home lab、小型办公室、工作间、仓库一角，或挂在 Home Assistant 旁边、带 camera VLAN 的系统，都属于很合适的土壤。在这些地方，Frigate 用配置工作去换掉云订阅租金，这笔交换往往是划算的。

它较弱的边界也一样清楚。若真实需求是“买一套成品，扫个二维码，让厂商把移动端体验、远程中继与默认调优一并包掉”，Frigate 并非要在那块地盘上取胜。它预设操作者会关心 codecs、frame rates、object labels、detector hardware 与 retention windows。[1][2][3][4] 这并非缺陷，而是产品边界本身。

因此，在 2026 年读 Frigate，最合适的方式，是把它理解成一套带着 computer vision 内核的本地回看系统，而并非一颗会自动看懂世界的摄像头大脑。只要 camera streams 的形状被认真配置，detector hardware 被有意识地选定，review queue 又被收窄到真正重要的位置，Frigate 就会变得非常清楚。[1][2][3][5] 若你面对的正是这样一个问题，它仍然是 OSS 世界里最值得认真看的答案之一。

来源

  1. Frigate Docs，《Camera setup》—— detect 流帧率建议、recording 流建议、画面比例建议，以及 320x320 detect-resolution 边界。
  2. Frigate Docs，《Recommended hardware》—— 编码格式偏好、multi-substream 摄像头建议、Wi-Fi 摄像头警告、服务器建议与 detector 硬件路线。
  3. Frigate Docs，《Object Detectors》—— Edge TPU 与 OpenVINO detector 行为、支持的硬件路线，以及多 detector 扩展方式。
  4. Frigate Docs，《Recording》—— 直写摄像头视频流、UTC 路径结构，以及 retention 策略行为。
  5. Frigate Docs，《Review》—— review item 模型、alert / detection 分类、过滤方式，以及按 zone 收窄 review 的配置路径。
  6. GitHub API，blakeblackshear/frigate 仓库快照 —— 文章写作时的 stars、forks、open issues 与最近 push 活动。
  7. GitHub，blakeblackshear/frigate releases —— 最近 release 节奏，包括 v0.17.1 与 v0.17.0。
  8. Heise online，《NVR for self-hosting: Frigate now recognizes license plates and faces》—— 对 Frigate 作为 self-hosted 替代方案、本地处理与 accelerator support 的独立描述。
  9. Wikimedia Commons 文件页《Security Camera-01-PTZ.jpg》—— 本文题图所用 PTZ 安防摄像机照片来源页。