去年装第三台摄像头的时候，我的NAS开始发出那种熟悉的、风扇即将起飞的声音。不是硬盘在转，是CPU在硬扛——四路1080p视频流，每秒30帧，全塞进一个Docker容器里跑目标检测。温度飙到78度，告警延迟从200ms变成2秒。我算了一笔账：要么加钱换i7，要么接受系统每隔三分钟给我推送"您的树又动了"的推送。
这几乎是所有自托管安防用户的必经之路。第一阶段，买几个便宜摄像头，插进NVR，觉得"本地存储真香"。第二阶段，发现存储里塞满了日出日落和野猫路过，开始研究AI过滤。第三阶段，意识到"本地AI"四个字背后藏着巨大的算力黑洞——解码、推理、编码、存储，四个环节全在抢同一块CPU。
我最后选的方案，听起来像把跑车引擎和电动自行车电机焊在一起：一张入门GPU，加一块Google Coral Edge TPU。前者处理视频解码和通用计算，后者专职跑神经网络推理。成本不到一块中高端CPU的一半，但帧率稳了，延迟降了，NAS风扇安静得像在装死。
为什么单一方案都差点意思
先说GPU。我手里这张是GTX 1650，老黄家的入门级产品，TDP 75W，不需要外接供电。它对视频解码极其友好——四路H.264硬解，CPU占用从60%掉到5%。但跑AI模型就是另一回事了。Frigate默认用的YOLOv5n，在GPU上能跑到40fps，可功耗直接拉满，风扇噪音穿透机柜。更麻烦的是延迟：GPU推理有批处理倾向，攒够一批帧才处理，实时性打折扣。
TPU则完全是另一种生物。Coral Edge TPU是一块USB加速器，功耗2.5W，价格不到GPU的十分之一。它专为TensorFlow Lite设计，跑MobileNet这类轻量模型时，单帧推理延迟能压到10ms以内。但TPU有个硬门槛：只认INT8量化的TFLite模型，且完全不碰视频解码。你把原始H.264流塞给它，它只会茫然地发热。
单独用GPU，电费账单和噪音会让你后悔。单独用TPU，你得先找个东西把视频变成帧，且模型选择极其受限。两者都想要？传统思路是"堆更强的CPU"，或者"买更贵的NVIDIA卡用TensorRT"。但我的预算和机柜空间都不允许。
混合架构的想法来自一个观察：安防场景的任务天然可拆分。解码是视频编解码的活，推理是矩阵乘法的活，两者对硬件的偏好完全不同。与其让一块芯片做所有事，不如让各司其职的硬件流水线作业。
Frigate的流水线设计
Frigate是这个方案的灵魂。它不是一个简单的NVR，而是一个专门为边缘AI设计的视频处理框架。核心架构分三层：ffmpeg负责拉流和解码，OpenCV做帧预处理，检测后端跑实际的目标识别。关键洞察在于——这三层可以绑定到不同的硬件。
我的配置里，ffmpeg的解码任务扔给GPU的NVENC/NVDEC引擎，这是它最擅长的。解码后的原始帧通过共享内存传递给TPU，TPU上的Edge TPU runtime跑量化后的MobileNet SSD模型。检测框画回帧上，再编码存储，这部分又回到GPU。
整个流水线用Python multiprocess实现，进程间通信靠共享内存而非拷贝，延迟控制在单帧50ms以内。Frigate的文档里有句很实在的话：「检测延迟不是由模型速度决定的，是由你把帧从A搬到B的方式决定的。」
实际跑起来的数据：四路摄像头，每路5fps采样检测，TPU占用率稳定在35%，GPU解码占用15%，CPU几乎闲置。对比纯CPU方案，同样负载下i5-10400的占用率是90%且风扇狂转。对比纯GPU方案，功耗从75W降到15W，噪音从45分贝变成环境底噪。
但数字之外有个更关键的体验变化：误报率断崖式下跌。
以前用基于运动的检测，树影、车灯、云层变化都会触发告警。现在TPU跑的是真正的目标检测模型，输出的是"人：0.92""车：0.87"这样的结构化标签。Frigate支持按标签过滤，我只订阅person和car，其他类别直接丢弃。结果很直观：日均告警从120条降到8条，且8条全是有效事件。
踩过的坑和妥协
这个方案并非开箱即用。第一个坑是模型转换。Coral只接受特定格式的TFLite，且对算子支持有限。Frigate官方提供了转换好的模型，但如果你想用YOLOv8或者自定义训练，得自己走TensorFlow的量化流程。我试过把YOLOv5s转过去，失败三次后放弃——有些层就是不被支持，这是硬件的硬边界。
第二个坑是USB带宽。Coral TPU走USB 3.0，理论5Gbps，但四路1080p@30fps的原始帧流已经逼近极限。实际表现是偶尔丢帧，检测出现"跳格"。解决方法是降低采样率到5fps——安防场景下，每秒5帧足够捕捉任何有意义的事件，这是用体验换稳定性的妥协。
第三个坑更隐蔽：Frigate的GPU加速依赖ffmpeg的硬件解码，而ffmpeg对各代N卡的支持参差不齐。GTX 10系和16系最稳，RTX 30系反而有驱动兼容问题。我的1650是Turing架构，恰好卡在甜点区，这有运气成分。
还有一个设计层面的限制：TPU是单向加速器，只能推理，不能训练。这意味着你无法在本地做迁移学习，比如"让我的系统认识我家的狗"。要更新模型，必须在上位机训练好，量化，再部署。对于安防这种相对标准化的场景这不是大问题，但如果你想做更个性化的视觉AI，TPU的封闭性会卡住你。
成本核算和替代方案
摊开账单：GTX 1650二手价400元，Coral TPU USB版350元，合计750元。作为对比，一块能硬解四路1080p且跑YOLOv5n@30fps的CPU，i5-12400起步，板U套装1500元以上。如果追求静音和低功耗，Intel NUC或AMD小主机再加外置显卡坞，成本直奔3000元。
更便宜的替代方案存在，但都有代价。树莓派5加AI HAT，总价500元内，但只能处理单路720p，延迟高到不适合实时告警。Intel N100小主机，纯CPU跑检测，四路就是幻灯片。海康威视的AI摄像头自带NPU，但那是黑盒系统，数据上云，和"自托管"的初衷相悖。
我的方案卡在中间地带：比纯ARM方案贵，比x86服务器便宜；比云端AI隐私，比端侧AI摄像头灵活。它适合那种"愿意折腾但预算有限"的用户——这个人群在自托管社区里占比极高。
Frigate的作者Blake Blackshear在GitHub讨论区说过一句话：「家庭安防的终极形态不是更多摄像头，是更聪明的过滤。」我理解这句话的语境：当算力成本降到足够低，我们可以把"理解画面"的任务从人转移到机器，而人只处理被筛选后的信息。GPU+TPU的组合，某种程度上是在家庭场景里复刻了这个逻辑——用异构计算把成本压到可接受的范围。
现在我的系统已经跑了八个月。最近一次迭代是给Frigate加了面部识别插件，跑在GPU上，TPU继续专职检测。识别准确率一般，但功耗没有明显上涨——因为GPU的解码单元和CUDA核心是独立的，解码负载不变的情况下，多余的CUDA算力可以接别的活。这种"榨干每一瓦"的感觉，大概是自托管用户共有的执念。
如果非要说这个方案有什么"教训"，可能是：别急着升级CPU。现代计算任务的瓶颈往往不在通用算力，而在特定操作的效率。视频解码、矩阵乘法、内存带宽，各有各的最优解。把任务拆给对的硬件，比堆一颗更强的通用芯片更划算——这个道理数据中心早就懂了，只是家庭场景里还没普及。
你的安防系统现在怎么处理AI检测？是硬扛CPU、上NVIDIA全家桶，还是已经摸索出更奇怪的硬件组合？
热门跟贴