边缘视频推理：把模型塞进盒子的现实约束

边缘视频推理听起来只差一个「把模型部署上去」的动作，实际做过的人都知道，模型只占工作量的一小部分。

这篇按我自己的项目顺序，写清哪几个数字要先算、哪几个坑最容易踩。

先算三个数：帧率、分辨率、并发路数

这三个数相乘就是最低算力需求，而现场需求永远比纸面高。

常见的错是拿实验室单路高清的结果去推算现场：现场是十六路、每路还要抽帧、夜间还要开增强。需求一放大，方案就得重做。

算的时候留足余量，因为光照、遮挡和场景复杂度都会让实际耗时比测试时更高。

模型压缩：量化、剪枝、蒸馏怎么选

量化最省事，收益也最直接，代价是精度损失；剪枝需要对网络结构有把握；蒸馏要重新训练，成本最高但往往最灵活。

多数项目的顺序是：先量化跑通，效果不够再换更小的骨干网络，最后才动剪枝和蒸馏。

算子支持比模型大小更容易卡住

在 PC 上跑得通的模型，到了专用加速器上常常卡在某个算子上，只能退回 CPU 执行，速度立刻掉一个数量级。

所以选型时要先确认目标硬件支持哪些算子，再挑模型结构，而不是先挑模型再想办法适配。

盒子的热和电

边缘设备大多没有风扇，长期满载会降频，降频就意味着帧率下滑。

真实机柜里的温度往往比办公室高不少。压测要在接近现场的温度下做，否则上线后才发现撑不住。

端云分工：什么该在本地，什么该回传

高频、低价值的判断留在本地，比如有没有人、有没有移动；需要跨摄像头、跨时间的分析再回传。

这样带宽和存储的压力都会小很多。反过来，什么都往云上传，链路成本和隐私风险都会一起上去。

落地顺序

先用几台真实设备跑一个月，把误报、漏报和运维成本摸清楚，再谈规模化。规模化之后最难的不是算法，是几百台设备的版本一致性和远程排障。

版本一致性是个长期问题

盒子一多，最大的运维难题不是算法精度，而是「现场跑的到底是哪个版本」。

常见的情况是：新模型只更新了一部分设备，出问题时两边报的现象完全不同，排查时间成倍增加。

所以我要求每台设备都上报三项：模型版本、配置版本、固件版本。三者不一致就先告警，而不是等业务方反馈画面异常。

远程升级也要能被中止和回滚，尤其是在没有现场人员的情况下。

数据回传与隐私

画面里可能包含人脸、车牌和门牌号。回传之前先做脱敏，或者只回传结构化结果。

这件事在方案阶段就要定下来，因为它决定了带宽预算、存储策略，以及这份数据后面能不能被复用。

结论

边缘推理的难点不在模型，而在于把一整套约束同时满足：算力、功耗、散热、带宽，以及现场环境。

先把数算清，再挑模型。次序反了，改起来就是重做。

本文不构成任何技术建议，具体方案请结合自身场景与实测结果评估。