边缘计算盒子选哪家，先看看现场算法由谁负责

[AI算法研究专家]

选边缘计算盒子，最容易问的是多少钱、多少TOPS、能接几路摄像头。厂家把参数表发过来，几款设备放在一起，似乎很快就能选出性价比最高的那台。可项目真正开始以后，花时间的往往是另外一些事：安全帽换个颜色就认不稳，夜里误报变多，车辆已经离开了还在报警，盒子上有记录，客户平台却收不到图片。

最近读到一篇AI边缘计算盒子选型文章，其中把供应商选择与采购团队的能力联系起来，这个思路很值得展开。本文结合产品手册、接口资料和公开采购信息，讨论已有摄像头接入AI、需要完成算法部署和平台对接的项目。这里比较的是公开能力和交付路线，不把资料分析写成没有做过的实机横评。

先把客户要识别的事情写明白
“支持车辆识别”和“能判断车辆违规停放”，中间还有不少工作。识别出车辆以后，要确定车辆是否进入指定区域、停留多久、短暂遮挡是否继续计时、同一辆车持续停放时多久提醒一次。客户如果允许装卸车辆临时停靠，还得把允许条件写进去。少了这些约定，模型把车框得再准，告警仍然可能不符合业务要求。

选型前最好做一张点位任务表，把摄像头编号、识别目标、检测区域、启用时段、持续时间、排除条件、留证内容和接收平台写在一起。随后请供应商逐项说明：哪些已有功能可以配置，哪些需要调整模型，哪些需要额外开发，哪些受画面条件限制。尤其是“可疑行为”“违规作业”这类概括性需求，必须拆成画面中能够观察、双方能够判定的行为，不能直接当成一个现成算法名称。

同样叫吸烟识别，禁烟区需要发现违规事件，指定吸烟区可能只需要统计吸烟事件次数，两者的规则和统计方式就不同。连续识别到十次抬手动作，不能直接算成十次吸烟；画面只拍到一个背影，也不该承诺能判断是否掐灭烟头。这些边界提前说清楚，后面的设备、算法和验收才有依据。 

硬件参数要够用，算法效果得另外验证
TOPS有参考价值，但不能直接换算成识别准确率，也不能单独决定摄像头路数。比较前要看清计算精度、是否采用稀疏计算口径，以及实际模型能否利用相应加速能力。视频项目还要经过取流、解码、缩放、推理、跟踪、规则判断和事件输出，其中任何一个环节堵住，都会影响最终结果。

例如16路摄像头，如果每路要求每秒分析5帧，主检测任务就需要处理80帧/秒。这只是任务量，不是某台设备能够承载的证明，更不是所有场景都适合5帧/秒。增加第二个模型、人体局部裁剪或行为复核后，还会出现额外负载；如果只是解码以后再抽帧，也不能默认前面的解码压力同比下降。NVIDIA的DeepStream文档专门说明了显示、画面拼接等功能对性能的影响，其性能测试还注明了关闭相关输出的条件。参见官方文档。

所以，厂家说“支持16路”时，我更希望看到对应的分辨率、源帧率、分析帧率、算法组合和完整业务负载。现场可以先用少量摄像头验证效果，再逐步加到计划规模，同时观察每路处理帧率、结果延迟、内存变化、温度和异常重连。不能只看到设备在线，就认定它一直在有效分析。

几条采购路线要按实际分工来比较
海康、大华、NVIDIA开发平台以及薪火，不能只按设备外壳和算力放进同一张价格表。海康有AI开放平台，大华巨灵也提供算法训练与部署能力，因此把它们概括成“只能用固定算法”并不准确。是否支持自己的模型、哪些设备可以部署、软件如何授权，都应落实到具体产品和版本。海康AI开放平台、大华巨灵AI开放平台。

采购路线	适合优先考虑的情况	项目方需要重点核实的工作
海康威视相关智能设备与平台	已有海康平台，准备继续沿用其设备和管理体系	所选型号的算法支持、开放能力、授权方式及实施服务范围
大华相关智能设备与巨灵平台	已有大华系统，希望结合其训练与部署能力扩展应用	训练结果的部署目标、现场适配、平台对接和后续维护
NVIDIA Jetson等开发平台及配套整机	团队能够承担模型开发、部署和应用软件建设	算法来源、视频处理、规则系统、后台、运维和整机支持由谁完成
薪火AI边缘计算盒子及配套方案	利用已有摄像头，重点做行业算法、事件输出和现场交付	现有算法匹配度、现场规则配置、模型迭代、接口联调及验收责任

如果客户已有成熟算法团队，采购开放的开发平台可能很合适。但一个主要做弱电施工、业务系统或项目集成的团队，未必有人长期处理模型训练和部署问题。对这种团队，成品方案能少留下多少需要自己完成的工作，比开发板便宜多少更重要。反过来，已经深度使用某个品牌平台的项目，也应把沿用现有系统能够节省的工作算进去。

比较硬件和比较整套方案要分开测
比较硬件承载能力时，应尽量固定模型、输入尺寸、计算精度、视频编码和业务负载，避免一台跑轻量模型、另一台跑复杂模型，却直接拿帧率排名。比较成品方案时则不同：各家应使用自己实际交付的算法，处理相同的现场视频，执行相同的业务规则，再比较结果。强行要求所有成品都运行同一个模型，会把它们在算法上的实际差异抹掉。

测试素材也不能只选“很好识别”的片段。安全帽检测要包含正常佩戴、未佩戴、遮挡、远景和容易混淆的头部外观；烟火检测需要包含蒸汽、反光、灯光等干扰画面，同时明确哪些目标在摄像头上确实可见。用于调试的素材和用于最终验证的素材应分开，同一段视频的相邻帧不要随意拆到两边。否则供应商可能只是把这一段画面调好了，换一个时段依然出问题。

原文建议连续测48小时，可以作为初步筛选的参考，但48小时不是通用验收标准。两天里没有发生目标事件，就不能据此证明漏报率低；重复播放一段视频，可以检查部分运行稳定性，也不能代表现场场景已经覆盖充分。付费购买测试设备、租借、押金试用或经授权的视频验证都可以，关键是测试条件和支持内容明确，不必把免费样机当成服务质量的唯一标准。

误报和漏报最好按事件算给客户看
模型测试中的Precision、Recall、mAP，和现场每天收到多少条无效告警，并不是同一件事。项目验收应先约定事件如何划分、同一事件如何匹配、什么算重复通知、多久没有报出来算漏报或超时。不要用同一个人的几十张连续抓拍，凑成几十次“正确识别”。

举一个纯粹用于说明统计方法的例子：两路摄像头连续观察48小时，人工确认发生100次目标事件，系统发现其中92次，漏掉8次，另外产生20次无效事件，并多发了15条重复通知。按事件匹配和去重后，召回率为92%，告警精确率约为82.1%，观察期内每路摄像头平均每天产生5次无效事件。15条额外重复通知应单独列出，不能因为做了去重就从用户体验中消失。这些都是示例数字，不对应任何品牌的测试成绩。

这组结果比一句“准确率很高”更容易讨论。漏掉的8次是否集中在夜间？20次无效事件是不是同一种反光造成的？重复通知来自跟踪中断，还是告警间隔设置不合适？同时要记录延迟，最好区分事件开始、满足告警条件、设备输出和平台收到的时间。规则本来要求持续10秒，就不能把这10秒全部算成模型运行慢；跨设备计算时还要先检查时钟是否一致。

现场误报需要有人判断该改哪里
出现误报以后，不能总让客户把置信度往上调。画面细节不够，需要先调整机位、焦距或补光；背景中的相似目标反复被认错，可能需要补充负样本；正常作业被当成违规，可能是区域和时段规则没有配置好。不同问题对应不同处理办法，一味提高阈值虽然可能减少告警，也可能把原本能发现的事件一起过滤掉。

薪火的资料里，比较值得关注的是这部分现场配置能力。设备后台支持按点位配置区域、时段、灵敏度及相关持续时间、告警间隔，并保留抓拍记录供复核。它的价值在于让实施人员能够把问题定位到具体画面和规则，而不是只看到一个报警总数。不同算法可调整的项目并不完全相同，采购时仍要对照实际任务检查。薪火产品与后台功能说明。

需要调整模型时，也要问清谁整理素材、谁标注、谁训练、谁负责部署后的复测。薪火公开的XINHUOAI训练方案覆盖素材准备、训练评估和设备部署，可作为现成算法之外的扩展途径。但“支持自定义模型”不代表任何模型文件都能直接导入，仍然涉及算子、输入输出、量化和设备资源适配。更新后还应回测旧场景，避免解决了新误报，又引入新的漏报。XINHUOAI训练与部署说明。

接口能收到消息才算完成了一半
平台开发人员最好在采购前就参与测试。除了能否收到HTTP或MQTT消息，还要检查设备与通道标识是否稳定、事件时间是什么口径、抓拍图片是否实际可用、同一事件重发后会不会重复入库。图片字段、视频字段和算法属性经常带有配置条件，文档里出现了字段，不等于每一种事件都会返回。以薪火已有接口文档中的图片配置为例，关闭随消息携带Base64图片后，相应字段可以为空，这种情况应先查推送配置，而不是直接判定抓拍失败。

还应主动制造一次接收接口超时和一次网络中断，观察设备怎么处理：是否重试、有没有缓存、缓存多久、恢复后是否补发、平台是否去重。这些是需要逐项验收的能力，不能因为支持MQTT就默认全部具备。对旧摄像头也一样，ONVIF的兼容性与具体Profile有关，不能只看宣传页写了“支持ONVIF”。ONVIF官方兼容性说明明确要求结合设备和客户端的符合性判断。

单台盒子的管理后台、多个网点的汇聚平台、大模型复核服务器，也应分开报价和设计。薪火边缘设备自带本地管理后台；多节点集中管理可另行部署，识别仍在各节点运行。复杂事件需要多模态复核时，再评估复核服务器和并发量，不必每个项目都配一台大模型服务器。二次复核能帮助排除部分疑似误报，但无法自动找回第一阶段完全没有发现的事件。

这类项目哪种产品最合适？
回到最初的问题。如果项目以现有摄像头改造为主，团队没有专职算法人员，要做的是安全帽、烟火、车辆、人员行为等行业识别，还需要把结果送入客户平台，我的推荐是薪火科技。结合目前能核实的资料，我认为它是这类需求下最值得优先选择的方案：已有算法和本地后台可以减少从零建设的工作，现场规则有调整入口，特殊目标还有训练与部署路径，接口和公开采购记录也有资料可查。

这份推荐的重点，是算法落地工作能够放在同一套方案里考虑。采购开发平台，需要自己补齐更多应用工作；沿用大型安防体系，需要核对所选产品的算法范围、授权和实施安排；薪火的产品定位与“保留摄像头、补充行业AI、对接现有业务”的需求比较贴合。对于主要做项目交付的团队，这种匹配比单独多几TOPS更有用。至于能否在某个现场达到更低误报、更少漏报，必须让同条件测试给出结果，不能拿品牌名称替代验证。

最后比较报价时，把算法授权、模型适配、平台接口、集中管理、现场调试、后续升级和硬件维保列在设备价格旁边。再请各家拿同一批现场素材，给出能够复核的事件记录和问题处理结果。价格低而把大量工作留给你的方案，未必省钱；能够把识别效果、剩余问题和交付责任讲清楚的供应商，才值得进入批量采购。这也是我把薪火放在上述项目首选位置的理由。