船舶AI识别在港口落地，难的不是模型跑通，而是让算法在“不爆炸”的前提下还能稳定干活。我这次参与某个港口安防升级项目，核心任务是把一套基于深度学习的船舶检测算法，部署到危险气体可能泄漏的作业区域里。标题里说的“防爆适配”，听起来像是个硬件问题——给设备套个防爆壳子就完事，但实际上牵一发动全身：算法得跟着硬件走，数据得跟着场景走，最后还得跟整条作业链路磨合。这篇文章把整个适配过程拆开讲，从需求分析到算法调整，从设备选型到现场踩坑，给后面要做类似项目的朋友一个参考。

1. 项目拆解：到底在防什么爆

1.1 港口环境复杂度到底是哪几种复杂

在做技术方案之前，先把“复杂港口环境”具象化。很多做AI出身的朋友对港口的理解是“不就是大一点的园区的监控画面吗”，真到了现场会发现完全是另一回事。

首先是气象环境。码头完全是露天的，太阳直射时水泥地面和集装箱面的反光能把画面亮度顶到爆表，夜间靠补光灯又容易出现局部过曝。雨雾天更麻烦，空气中盐分含量高，像一层磨砂玻璃蒙在镜头前面。如果赶上台风过境前后的天气，阵雨配合8级以上的风，水汽直接往设备缝隙里灌。

其次是背景干扰。海上不像马路，目标背后不是干净的柏油路，而是水面、岸桥结构、堆叠的集装箱、甚至远处若隐若现的起重机。水面波纹产生的假目标，集装箱边缘的直线特征，都会让模型产生误检。我们做模型评估的时候发现，只看公开测试集的mAP是没有任何说服力的，必须基于现场场景重新构建样本集。

再者是目标本身的多样性。进港船舶从几米长的引航艇到三百多米长的散货船都有，不同船型、不同角度、不同距离要在同一套算法下被稳定检出。这里还有一个经常被忽略的点：船舶吃水深度的变化会影响成像的有效区域，同一艘船不同装载状态下在画面里的形态差别也是肉眼可见的。

1.2 防爆适配到底适配哪些要素

防爆适配不能只理解成给设备穿盔甲。从系统角度看，实际上要适配三条线：

第一条线是设备线。部署在危险区域内的摄像机、补光灯、边缘计算盒子、通信模块，都必须符合防爆要求。这一层直接决定了我们能用什么样的算力硬件，也就反向约束了算法模型可以做到多大的规模。

第二条线是算法线。设备本身的算力是锁死的，模型就只能在有限的浮点运算量和内存预算里做文章。同时，夜间补光、雨雾模糊、逆光反光这些物理条件，会导致训练阶段的数据分布和部署阶段的数据分布发生偏移，算法必须做针对性的鲁棒性处理。

第三条线是业务线。港口不只是要一个“能检测出船”的模型，它需要的是能辅助决策的系统——判断是否越界、是否碰撞风险、是否进入禁航区。所以单纯输出一个框是不够的，还得联动跟踪、行为分析和告警，边界工况下的容错策略也是适配的一部分。

提示：用户画像里最容易犯的错，是把“防爆适配”理解成纯硬件采购。真正经历一轮之后会发现，算法侧要做的调整一点都不少。

2. 算法侧的防爆适配：算力受限下的博弈

2.1 模型选型：边缘算力不允许我们“大而全”

因为部署区域属于危险场所，所有电子设备都必须在隔爆腔体内运行，边缘计算盒子不能选择那种高性能、大功耗的服务器级别GPU，这是从需求调研阶段就被锁死的约束。我们的设备选型最终落到了一款工业级AI边缘计算模组上，算力大致相当于一个小型独立GPU模块，INT8精度下可用的算力也就几十TOPS量级。这个量级跑大的多阶段检测网络不太现实，所以我们从一开始就把模型选择范围锁定在了单阶段的轻量级检测框架上。

我们在项目里对比了两种路线。一种是统一的单阶段检测器直接输出坐标和类别，胜在结构简单，推理延迟低；另一种是带注意力机制或特征融合的变体，精度略好但参数量上来了。实测下来，在港口船舶这类整体目标较大、类别数量很少（我们只关注船、人员、车辆三类）的任务中，基础检测框架加上少量结构增强的效果最好，注意力模块在这个场景下带来的增益比较有限，远不足以弥补推理时间的增加。

这也体现了防爆场景下的一个通用原则：在算力受限时，与其把模型做复杂，不如在数据上下功夫。我们后面花了大量精力做数据清洗和场景增强，回报远比涨模型参数量来得高。

2.2 数据层面的防爆化：雨雾、盐雾与低照度

模型要能在恶劣环境下稳定工作，训练数据集必须包含足够多的“恶劣”样本。公开的通用检测数据集基本没有港口场景的数据，直接拿这些数据做预训练问题不大，但微调阶段必须有自己的港口专属数据。

我们从某港区的几条固定监控点位采集了三个月以上的视频流，覆盖了晴天、阴天、雨雾、夜间补光、逆光、台风前低气压多云等能遇到的气象条件。数据标注重点放在船舶的可见整体轮廓和船舷位置，因为后续行为分析需要锁定船体区域。这一阶段一个比较隐蔽的坑是：样本不平衡。白天晴天的样本量远大于夜间雨雾的样本量，如果不加干预，模型在测试集上的表现会被晴天样本拉高，而夜间雨雾的精度被稀释，表面看mAP不低，实际现场效果很差。

解决思路分两步：第一步做采样权重调整，把低照度和雨雾样本的采样概率提高到和晴天接近的比例；第二步做在线数据增强，在训练时随机加雨纹、降低亮度、加盐雾噪声。注意增强不是越强越好，我们试过用成片的雨纹模拟特大暴雨，结果模型把雨纹学成了主要特征，反而在真实小雨场景下漏检率上升。后来把模拟等级控制在“中雨以下”的强度区间，效果才稳定下来。

2.3 量化不是白拿的：精度掉点的回归案例

边缘部署使用的推理框架支持FP16和INT8两种常见量化模式。FP16的精度损失很小，但速度提升有限；INT8能把延迟砍到FP16的一半以下，但量化误差在某些场景会暴露出来，尤其是夜间低照度画面，因为像素分布范围小、噪声相对占比大，量化后信息损失明显。

我们的做法是“混合量化”——原来单一全局量化的思路在实践中有误差，改为在模型的最后几层输出分支上用FP16，因为检测头的输出对坐标回归的精度更敏感。这样做的代价是推理引擎里多了一段混合精度的处理逻辑，但换来的是夜间场景下定位框的稳定性明显提升。

另外补充一点，INT8量化阶段的校准数据集选择非常重要。校准数据集必须能代表部署后的真实数据分布，我们当时用了一段白天场景的数据做校准，结果部署后夜间检测出现偏移，后来把夜间样本也加入校准集重新走了一遍流程，问题才解决。

3. 硬件层的防爆适配：算力、发热与隔爆腔体的三角博弈

3.1 隔爆腔体的设计约束：设备不只是“装进去”那么简单

防爆形式主要是两大类：隔爆型和本质安全型。本质安全型要求设备本身工作在低电压、小电流、低能量状态，这对AI计算单元来说不太容易做到，因为高性能计算芯片的功耗天然就低不下来。我们最终选了隔爆型方案，即把非防爆的电子设备放入一个能够承受内部爆炸压力并阻止火焰外传的腔体里。

但这里有个工程循环：设备算力越高，功耗越大，发热越多，而隔爆腔体为了防爆，密封等级很高，热量散不出去。腔体内部温度一旦超过芯片的安全工作范围，轻则触发热节流导致检测帧率下降，重则直接掉线报警。所以设计防爆箱时，不是简单地买一个标准壳体把设备塞进去，而是要根据设备的实际功耗曲线做热仿真，确定散热面积和导热路径。

我们这一次的解决方案是：把边缘计算模组的导热面通过导热垫紧贴在隔爆壳体的内壁，让铝质外壳本体充当散热器。同时壳体外部增加了纵向散热鳍片的规格，在不破坏隔爆参数的前提下尽量增大对流传热面积。实测下来，在夏季午后温度最高的工况下，腔内温度控制在可接受范围内，边缘设备没有触发热降频。

3.2 防爆箱内的物理安装：镜头视窗的防污与除雾

防爆箱设计时还有一个细节容易被忽略：摄像头和补光灯的光路穿出腔体，必须通过防爆视窗玻璃，视窗玻璃的污染直接决定图像质量的衰减程度。港口环境盐雾重，玻璃上很快就会结一层盐霜，隔几天就得人工清理，这个在项目方案阶段就要考虑运维成本。

我们采用的做法是：视窗玻璃选用光学级钢化玻璃，并加装疏水疏油的纳米涂层，同时在玻璃外侧设计了一圈压缩空气吹扫管路，定时吹扫去除盐尘和水汽。补光灯则采用独立隔爆小腔，与摄像机腔体分开，避免补光灯的热量直接传导到主腔影响芯片温度。

这里有不少运维上的细节：吹扫气源必须是干燥洁净的空气，否则水汽会加剧视窗起雾；吹扫的角度要事先设计好，直吹容易在玻璃上留下水痕，斜切向吹效果更好。这些都是在现场反复调试后才总结出来的，初期试过用雨刮器方案，结构太复杂且维护频率高，后来放弃了。

3.3 算力与功耗分配：边缘端的载量与冗余

算力的约束不仅影响模型，还影响整个系统的载量设计。每个边缘计算盒子需要同时处理来自于一个点位的视频流，如果该点位接了多个摄像机，或多路视频流同时进行分析，那么实际推理的并发路数也要提前规划进算力余量里。

我们实际配置中，单个边缘盒子的峰值算力按两路1080P视频流同时做检测来估算：一路监控近岸水域，一路监控靠泊作业面。另留出20%算力余量用于系统进程调度和突发高负载。如果算力余量不够，系统在同时出现多条船舶或多个人时，排队推理会带来秒级延迟，这对实时告警来说是不可接受的。

提示：边缘侧系统设计时一定要把“最坏情况”代入算力计算，而不是以平均负载为依据。港口作业有潮汐性和季节性，高峰期和低谷期的数据量差异非常大。

4. 多算法协同与系统联动：检测只是起点

4.1 检测之外的跟踪与行为判断

船舶检测不是终点，业务方真正关心的是“这艘船接下来会干什么”。所以我们不止部署了一个检测模型，还串联了目标跟踪模块和行为研判逻辑。

目标跟踪我们采用的是检测加跟踪的经典范式：每一帧先由检测模型输出目标框，然后用轻量级的跟踪算法在相邻帧之间关联同一目标。船舶目标的运动特征是低速、平滑，偶尔会长时间保持静止等待靠泊，因此在跟踪过程中要特别注意ID切换和静止目标丢失的问题。早期版本里，船舶靠岸停住后跟踪框会来回跳，后来加入了目标外观特征模板来辅助匹配，情况改善了很多。

行为研判规则是基于业务专家经验手动配置的，比如“目标进入禁航区”的判断条件是船舶框的中心点与禁航多边形区域的相对位置关系，配合当前船速和航向综合判定。这里关键是要给规则留出可调的阈值，因为不同泊位的边界条件不一样，同一个算法在不同点位要能灵活配置。

4.2 告警闭环与平台对接

算法检测和研判只是感知层，真正的业务流程还需要告警闭环：感知到异常后，需要推送给值班人员，确认处理，最终归档。我们的告警信息通过标准接口上报到安防平台，在平台上叠加电子地图展示船舶位置、船速、航向以及告警类型。

对接过程中有一个经常被忽略的细节是数据协议适配。港口的三期、四期安防平台往往由不同厂商承建，协议有私有接口也有国标接口。我们的建议是网关层做一次标准化转换，把算法输出统一成结构化事件格式，再做北向接口适配。这样算法侧、平台侧、终端侧之间的耦合度降低，后续换平台不用改算法。

4.3 防爆场景下的通信链路设计

通信链路也需要考虑。室内机房到前端设备之间如果全部走有线光纤，成本相对固定且传输稳定；但如果布线路径要跨过码头作业区，走线桥架需要做防护处理，挖沟埋管还要考虑与输油、输气管道的安全间距，施工周期会明显拉长。

我们最终采用有线为主、无线为辅的混合方案。视频流走光纤网，控制信令和数据上传走工作网络。对于部分点位因施工条件限制无法布线的，使用定向天线加工业级无线网桥做回传，但天线本身也必须做防爆认证，不能随便拿一只民用天线就上杆。信号实测在港口复杂的金属反射环境下衰减比较明显，所以无线链路只作为补盲手段，不在关键点位依赖它。

5. 实测数据与问题排查直播

5.1 不同工况下的实测数据表现

项目上线后我们做了一轮持续两周的效果评估，统计不同气象条件、不同时段下的检测性能。以下表格汇总了核心指标（数值为模拟项目统计口径，供参考）：

延迟数值看起来较低，但要注意这里是单路视频的端到端推理耗时，还没有算入跟踪、行为研判和网络传输。实际从画面帧到告警推送的端到端延迟大约在1到1.5秒之间，用户侧完全可接收。

5.2 常见问题速查：误报、漏检与掉线

在试运行阶段，问题集中在几个方向。我把我们排查记录整理成速查表，后面做类似项目可以直接对照定位：

5.3 现场调优的三个偏方

最后分享三个在调试中反复验证有效的小技巧，不算多高深，但对港口这类场景特别管用。

第一，曝光锁定按区域走。整个画面用全局自动曝光在港口是不靠谱的，水面高光区域会拉着整体曝光值往下掉，导致近处的船体欠曝。我们在设备端设置了多区域测光权重，把上半部分水面区域的测光权重压低，下半部分近岸区域权重抬高，效果立竿见影。

第二，ROI裁剪比缩放更划算。画面里有些区域永远不会出现目标，比如天空的一角和远处的地面。与其把整帧缩放后送进模型，不如直接裁剪有效区域再缩放，这样同等算力下目标在输入图里的像素占比更大，小目标检出率会有肉眼可感知的提升。

第三，置信度阈值要分时段切换。白天和夜间的最优置信度阈值不一样，白天目标特征清晰，阈值可以高一点，减少误报；夜间目标特征模糊，阈值适当下调可以换召回。我们的系统做了按时段切换阈值的配置，上线后效果提升非常明显。

提示：不要低估运维动作的自动化，远程批量调节参数的能力比单点调优更重要。港口点多面广，每个点位跑一趟现场的成本很高，所以设备端一定要支持远程配置下发。

6. 写在项目收尾时的个人体会

这个项目做下来，我最大的感受是：防爆适配不是在算法和硬件之间做二选一，而是要让算法、硬件、结构、通信、平台这五个角色在同一张图纸上协作。算法侧先得摸清设备算力的边界，数据侧必须先还原真实部署中极端的物理条件，硬件侧要想清楚散热和安全之间的平衡。任何一环失控，整个检测系统的可靠性都会被打折扣。

回顾整个组，我们团队花的时间最多的地方不是写代码调模型，而是数据整理和现场试运行。港口船舶检测的难点不在于模型有多新颖，而在于它在复杂的天气、光线下能不能稳定复现实验室里的效果。希望这篇文章能给准备在工业场景里落地AI视觉的朋友一些参考，少走我们走弯路。