家里几个摄像头一直是”能录但不能查”的状态。硬盘转个不停，真出事了想找一段画面，只能靠时间轴慢慢拖。移动侦测倒是有，可树叶晃一下、光线变一下就报警，报得多了自然就没人看了。
所以我一直想给这堆画面加一层”理解”——不是记录像素，而是知道画面里出现了什么。前两天翻到 clearcam 这个项目，思路挺对我胃口的：不换摄像头，不装厂商 App，给已有的 RTSP 流套一层本地推理，识别人、车、动物，只在真的有东西时才推消息。
它到底做了什么
clearcam 的定位是”给任意安防摄像头加上物体检测、追踪、手机通知和搜索”。作者 roryclear，GPL-3.0 协议，Python 写的，GitHub 上 971 星，最近一次推送在 2026 年 8 月 2 日，还在活跃迭代。
它自己就是一个 NVR（录像服务端）+ 推理引擎的组合体。你把 RTSP 地址喂给它，它负责拉流、逐帧跑检测模型、切事件片段、存下来、建索引。浏览器打开 8080 端口就是完整的管理界面，能看实时画面、翻事件列表、回放片段。
真正让我停下来多看两眼的是它的技术选型。检测模型用的是 YOLOv9，但推理框架不是 PyTorch，也不是 ONNX Runtime，而是 tinygrad。这个选择很关键——tinygrad 体积极小，跨后端能力强，Metal、CUDA、ROCm 都能跑。翻了下它的 requirements.txt，整个项目的 Python 依赖只有三行：
git+https://github.com/tinygrad/tinygrad.git@fe39cf1
numpy==2.0.0
opencv-python-headless==4.10.0.84就这三个。没有 PyTorch 那两三个 G 的运行时，没有一堆传递依赖。对于想把它塞进 NAS 或者小主机的人来说，这个体积差距是决定性的。
几个我觉得有意思的功能
区域框选。可以在画面上画多边形，只在指定区域内触发告警。门口那一小块要报，马路对面来来往往的车不报。这是干掉误报最直接的办法，比调灵敏度阈值靠谱得多。
CLIP 语义搜索。项目集成了 CLIP，也就是说事件片段是带语义向量的。理论上你可以用自然语言去搜历史录像，而不是靠”8 月 3 号下午”这种时间坐标翻找。这个功能对我来说是最有吸引力的部分——录像的价值不在录，在能查得到。
Qwen3 VL 生成通知摘要。这是比较新的一个变化。传统告警推送就一句”检测到人”，配一张缩略图。clearcam 现在可以接一个视觉语言模型，让它看一眼画面，用一句话描述发生了什么再推给你。从 README 的示例截图看，推送内容确实是具体的场景描述而不是干巴巴的标签。
这个方向我很认同。安防告警的核心痛点从来不是”检测不到”，而是”检测到太多、无法判断哪条值得看”。让模型先做一层语义压缩，用户只需要读一行字就能决定要不要点开，这个体验差距很大。commit 记录里能看到 Qwen 开关在设置界面里做了反复调整，说明是个正在打磨的功能，不是贴上去的噱头。
另外从提交历史看，7 月还加了人脸识别开关（use_face）、YOLO 输入分辨率可调，并且把原本的 DETR 模型移除了。整体在往”配置项收敛到设置界面、CLI 参数减少”的方向走。
怎么跑起来
官方文档给的是源码方式，没有现成的 Docker 镜像，步骤本身很短：
pip install -r requirements.txt
python3 clearcam.py然后浏览器开 localhost:8080。系统要求是 Mac 或 Linux，需要 ffmpeg 和 Python 3.11 以上。Windows 目前不行，README 里标注了需要修 ffmpeg 相关的问题。
性能上有两个环境变量值得注意。如果发现它在用 CPU 而不是 GPU，可以用 DEV=AMD 或 DEV=NV 显式指定后端。另外 BEAM=2 能开启 tinygrad 的 kernel 搜索优化，性能会更好，但首次运行要等一段时间——tinygrad 会在本机实测各种 kernel 配置找最优解，这个过程不快，好在结果有缓存。
手边没有 RTSP 摄像头也能试。README 里给了一个公开的隧道监控流地址，直接填进去就能看效果，这点比那些”先买设备再体验”的方案友好。
需要想清楚的地方
它有商业版，而且核心的远程能力在商业版里。本地部署是完全免费开源的，但”远程看实时画面””收手机推送””远程看事件片段”这几项归在 Clearcam Premium 下，需要在网页或 iOS App 里订阅，用一个 userID 关联本地服务端。官方说这些数据是端到端加密的。
怎么看这个设计，取决于你的需求。如果只想在家里局域网内用，本地那份完全够，功能不缺。如果你已经有成熟的内网穿透方案，远程看画面这事自己也能解决，那付费的必要性就不大。真正需要掏钱的场景是想要开箱即用的移动推送——毕竟 iOS 的推送通道确实绕不过去。这里我建议按需评估，别默认买单。
tinygrad 依赖 pin 在了一个具体 commit 上。这是双刃剑：好处是复现性有保证，坏处是从 git 直接装依赖比走 PyPI 慢，网络不好的环境要有心理准备。
没有官方 Docker 镜像。对习惯 compose 一把梭的人来说，得自己写 Dockerfile，还要处理好 GPU 透传。这也是项目还比较早期的信号——issue 数是 0，主要靠作者一个人在推。
算力还是要给够。逐帧跑 YOLOv9，路数上去之后开销是实打实的。低功耗设备上跑多路是要降帧或降分辨率的，别指望白嫖。tinygrad 省的是依赖体积和部署复杂度，不是计算量。
和 Frigate 比呢
绕不开这个问题。Frigate 在这个领域是既成事实的标准，生态成熟、文档齐全、Home Assistant 集成完善、Docker 部署顺滑，还支持 Coral TPU 等各种加速硬件。功能广度上 clearcam 目前明显不如。
但 clearcam 有两个差异点：一是依赖极简，三个 Python 包搞定，不用为了跑个检测拖进来几个 G 的运行时；二是 CLIP 语义搜索和视觉模型摘要走得比较靠前，这是”让录像变得可查、可读”的路子，而不只是”多录几路、录得更清楚”。
所以结论其实很清楚：要稳、要生态、要接入家庭自动化，选 Frigate 不会错。想看看安防录像和多模态模型结合能到什么程度，或者单纯讨厌臃肿依赖，clearcam 值得占一块盘去试。
写在最后
我对这个项目感兴趣，主要不是因为它的检测有多准——YOLO 系列跑到今天，检测本身早就不是难点了。真正有意思的是它在尝试改变录像的使用方式：从”存一堆看不完的视频”，变成”一个能用语言查询、能读摘要的事件库”。
这个方向早晚会成为标配。现在的问题只是本地算力够不够、模型够不够小。至少从 clearcam 的依赖清单来看，成本正在快速下降。