道路坑洼检测工程化落地：从CV竞赛到边缘部署的完整链路

1. 这不是“又一个CV项目”而是一次真实道路缺陷识别的工程化落地尝试2023年MathorCup大数据竞赛D题——“基于计算机视觉的坑洼道路检测和识别”表面看是个典型的图像分割目标检测任务但真正跑通它的过程远比调用现成YOLOv5或Mask R-CNN模型复杂得多。我带过三届MathorCup参赛队也参与过两个省级智慧交通路巡系统的算法模块开发很清楚这类题目最常被忽略的致命点它不考你模型精度的极限而是考你如何让算法在真实、混乱、低质的路面视频流里稳定输出可交付的结果。所谓“坑洼”在实际采集数据中可能是积水反光形成的伪影可能是沥青老化产生的细小龟裂也可能是施工后未压实的松散碎石堆——它们在像素层面形态差异极大却都属于“需预警”的同一类语义目标。这就决定了方案不能只堆叠SOTA模型而必须从数据源头开始设计闭环怎么定义“坑洼”怎么让标注员统一标准怎么处理雨雾天图像对比度崩塌怎么把检测框坐标映射到GPS地理坐标系这些细节恰恰是90%的开源代码仓库和论文里绝不会写的部分。本文不讲理论推导不列公式只呈现我们最终提交的完整技术链路从原始行车记录仪视频帧预处理到轻量化模型部署再到结果可视化与结构化输出。所有代码均基于PyTorch 1.12 OpenCV 4.8实现无任何第三方商业SDK依赖全部模块均可在RTX 3060级别显卡上完成训练与推理。如果你正准备参加2025年第十五届MathorCup尤其是新设的短途运输调度类题目或者正在做城市道路养护AI系统原型这篇复盘能帮你绕开至少7个团队踩过的深坑。2. 整体方案设计为什么放弃端到端大模型选择“检测分割几何校正”三级流水线2.1 核心矛盾学术指标与工程落地的撕裂竞赛初期我们团队也尝试过直接微调Swin Transformer Mask2Former的组合在公开数据集上mAP能达到0.72。但当接入主办方提供的真实行车记录仪视频分辨率1920×1080帧率30fps含大量逆光、雨痕、镜头污渍时模型在连续100帧内漏检率达38%且误报集中在车牌反光区域。这暴露了根本问题学术模型追求全局最优解而道路缺陷检测需要的是局部鲁棒性。一个坑洼可能只占画面0.3%面积但必须被100%捕获而一片云影覆盖半幅画面却必须被零误报过滤。我们最终放弃“一模型打天下”的思路转而构建三级流水线第一级动态ROI裁剪器——不靠CNN而用纯OpenCV逻辑先计算图像梯度幅值图再通过自适应阈值分割出“非天空非车辆非文字”的道路区域最后用霍夫变换拟合车道线将ROI约束在两条车道线夹角内。这步耗时仅8ms/帧却使后续模型输入尺寸从1920×1080压缩至平均640×320同时排除了90%的干扰区域。第二级双头轻量检测器——主干网采用MobileNetV3-Small参数量2.5M头部并行输出两类结果① 坑洼粗定位框YOLO-style regression head② 坑洼像素级掩膜U-Net style segmentation head。关键创新在于共享主干特征但分离损失函数定位框用GIoU Loss约束边界掩膜用Dice Loss强化边缘。实测证明这种设计比单独训练检测或分割模型对“浅表龟裂”类小目标召回率提升22%。第三级几何空间校正器——这是最容易被忽略的环节。原始检测框坐标是图像像素坐标但运维系统需要的是经纬度坐标。我们没有使用昂贵的激光雷达标定而是基于单目相机几何模型结合已知的道路标线宽度国内标准为15cm通过透视变换矩阵反推深度信息。具体做法在ROI内检测出连续3段标线计算其在图像中的长度衰减比代入公式z f * w_real / w_pixelf为焦距w_real为标线实际宽度w_pixel为图像中标线像素宽度从而获得该区域近似深度z再将像素坐标(x,y)转换为世界坐标(X,Y,Z)。这步使定位误差从±3.2米降至±0.8米。提示很多队伍在答辩时被问“如何验证检测结果准确性”答案不能只说“IoU0.65”。必须说明你的评估数据集是否包含夜间、雨天、隧道等场景以及是否用真实GPS轨迹做过空间对齐验证。我们团队在测试集上额外标注了500帧的GPS坐标锚点最终报告的空间定位误差RMSE为0.73米。2.2 为什么不用Transformer——算力与延迟的硬约束当前主流CV竞赛论文动辄使用ViT-L/16或Swin-L但在车载边缘设备上这类模型推理延迟超过200ms/帧无法满足实时预警需求行业要求≤100ms。我们做了明确对比测试模型架构参数量(M)RTX3060推理延迟(ms)小目标32×32召回率内存占用(MB)YOLOv5s7.2420.58185Swin-Tiny28.31560.67420MobileNetV3-Small U-Net3.1380.71162数据清晰显示在同等硬件条件下轻量模型不仅更快而且因更少的过拟合风险在小目标检测上反而更稳。Swin系列的优势在于大尺度全局建模而坑洼本质是局部纹理异常过度依赖长距离注意力反而会弱化细微裂缝的响应。我们的取舍逻辑很朴素宁可牺牲0.03的mAP也要确保99%帧率下延迟稳定在40ms以内——因为行车场景中100ms延迟意味着车辆已向前移动约2.8米按100km/h车速计算。2.3 数据策略不靠“数据增强”而靠“缺陷生成”竞赛提供的训练集仅含827张标注图像且存在严重分布偏移72%为晴天柏油路18%为水泥路阴雨天样本不足10%。常规的RandomRotation、ColorJitter等增强方式对模拟真实雨雾效果作用有限。我们采用物理引擎驱动的缺陷生成法材质建模用Blender搭建标准路面模型设置不同粗糙度Roughness0.1~0.9、反照率Albedo0.05~0.3参数渲染出基础路面贴图缺陷注入编写Python脚本在贴图上按泊松分布随机放置坑洼模板含深度、直径、边缘坡度参数再叠加水渍折射率1.33、油污菲涅尔效应等物理层成像模拟调用OpenCV的cv2.filter2D模拟镜头模糊高斯核σ1.2用cv2.addWeighted混合环境光色温5500K与直射光色温6500K最后添加运动模糊方向角随机长度3px。这套流程每天可生成2000张高保真合成图关键是所有生成图像都附带精确的深度图和法向量图用于监督第三级几何校正器的训练。最终训练集扩充至4120张其中合成数据占比63%但验证集仍使用纯真实数据确保泛化性。这个方法后来被某省交通厅采购用于其AI巡检系统因为他们发现人工标注一张真实坑洼图平均耗时17分钟而合成一张带全监督信号的图仅需2.3秒。3. 核心细节解析从数据标注到模型部署的12个关键决策点3.1 标注规范为什么“坑洼”必须定义为“深度≥1.5cm且直径≥5cm”这是整个项目最基础也最关键的定义。竞赛题目只说“坑洼”但未给出量化标准。我们查阅了《公路技术状况评定标准》JTG 5210-2018其中明确将“重度坑槽”定义为“深度≥1.5cm且影响行车安全”。因此我们在标注时强制执行所有标注框必须包裹坑洼最深点及其周边破损区域若多个小坑连成一片且中心间距30cm则合并为一个标注实例水渍、油污、落叶等临时遮盖物不标注除非其下存在真实坑洼需通过多帧对比确认。这个标准直接影响模型学习目标。曾有队伍将所有暗色斑块都标为坑洼导致模型学会识别“阴影”而非“凹陷”在逆光场景下误报率飙升。我们为此专门制作了标注指南PDF包含27个典型正/负样本示例并组织3名标注员进行交叉验证Kappa系数达0.89。3.2 图像预处理用CLAHE替代直方图均衡化的深层原因行车记录仪视频普遍存在两大问题① 动态范围压缩亮部过曝暗部死黑② 镜头畸变广角镜头导致道路边缘拉伸。常规做法是用cv2.equalizeHist做全局均衡化但这会放大噪声并扭曲纹理。我们改用CLAHE限制对比度自适应直方图均衡化关键参数设置为clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8,8)) lab cv2.cvtColor(img, cv2.COLOR_BGR2LAB) lab[...,0] clahe.apply(lab[...,0]) img_enhanced cv2.cvtColor(lab, cv2.COLOR_LAB2BGR)clipLimit2.0是经验值大于3.0会导致高频噪声爆炸小于1.5则增强不足。tileGridSize(8,8)确保每个8×8像素块独立均衡避免全局色调失真。实测表明该设置使坑洼边缘的梯度响应强度提升4.2倍而噪声增幅仅17%对比全局均衡化提升320%噪声。3.3 损失函数设计Dice Loss Focal Loss的加权组合分割头使用Dice Loss1 - 2*|A∩B|/(|A||B|)能有效缓解前景坑洼像素占比极小通常0.5%导致的类别不平衡。但单纯Dice Loss对难分样本如浅色沥青上的浅表龟裂区分力不足。因此我们引入Focal Loss-α*(1-p)^γ*log(p)其中α0.75, γ2.0。最终损失函数为L_total 0.6 * L_dice 0.4 * L_focal权重0.6:0.4来自消融实验当权重比为0.5:0.5时小目标召回率提升但整体精度下降0.7:0.3时大坑洼漏检率上升。0.6:0.4是精度与召回率的帕累托最优解。训练时我们还加入了在线困难样本挖掘OHEM每batch只取loss最大的50%像素参与反向传播进一步聚焦于难例。3.4 模型剪枝通道剪枝比层剪枝更适合移动端部署为适配边缘设备我们对MobileNetV3主干进行通道剪枝。不同于简单删除低重要性卷积核我们采用基于L1范数的结构化剪枝计算每个卷积层输出通道的L1范数即该通道所有权重绝对值之和对所有通道L1值排序剔除最低的30%重构网络被剪枝通道对应的下一层输入通道同步删除。这种方法比非结构化剪枝如权重稀疏化优势明显剪枝后模型无需专用推理引擎即可运行且内存占用降低34%。实测剪枝后模型在Jetson Nano上推理速度从18fps提升至27fps精度仅下降0.015 mAP。3.5 后处理逻辑NMS之外必须加入“空间邻近合并”标准NMS非极大值抑制会删除重叠框但真实坑洼常呈簇状分布如施工路段连续坑洞。若直接NMS可能将多个相邻小坑合并为一个大框丢失细节。我们设计了二级后处理一级NMSIoU阈值设为0.3低于常规0.5保留更多候选框二级空间合并对剩余框计算中心点欧氏距离若距离框宽均值的0.6倍则合并为多边形掩膜用OpenCV的cv2.convexHull生成最小凸包。该逻辑使簇状坑洼的检测完整性提升31%且输出掩膜更贴合实际破损轮廓。3.6 推理加速TensorRT优化的三个必做步骤将PyTorch模型转为TensorRT引擎时我们发现仅做基础转换trtexec --onnxmodel.onnx性能提升有限。必须执行以下三步输入动态shape配置坑洼大小变化极大固定输入尺寸会损失精度。在TensorRT中启用setOptimizationProfileAsync设置min320×180, opt640×320, max1280×720精度混合FP16INT8主干网用FP16保证特征提取精度检测头用INT8加速回归计算。通过calibrator校准INT8量化参数避免精度崩塌CUDA Graph固化对固定batch size1的推理流程录制CUDA Graph消除kernel launch开销。这一步使RTX3060上单帧延迟从42ms降至36ms。注意TensorRT 8.4之后版本对PyTorch 1.12的ONNX导出兼容性有坑。必须在导出时禁用opset_version11改用opset_version12否则torch.nn.functional.interpolate会转为不支持的ONNX op。3.7 结果可视化不只是画框更要体现“风险等级”竞赛提交要求包含可视化结果但很多队伍只画绿色框。我们设计了四级风险编码风险等级判定条件可视化样式语音提示词一级紧急深度≥5cm且直径≥20cm红色闪烁边框红色填充“前方严重坑洼立即减速”二级高危深度≥2.5cm且直径≥10cm橙色实线边框“前方高危坑洼请避让”三级中危深度≥1.5cm且直径≥5cm黄色虚线边框“前方中危坑洼注意颠簸”四级低危其他疑似缺陷蓝色点状边框“前方路面异常建议检查”风险等级由第三级几何校正器输出的深度值决定而非仅凭框大小。这使得可视化结果具备真正的工程指导价值。3.8 代码结构为什么坚持“模块化”而非“端到端脚本”最终提交的代码库严格遵循六层架构src/ ├── data/ # 数据加载、增强、合成 ├── models/ # 检测器、分割器、校正器定义 ├── utils/ # 几何变换、坐标转换、评估工具 ├── train/ # 训练循环、分布式训练封装 ├── infer/ # 推理pipeline含TensorRT加载 └── deploy/ # Docker镜像构建、Jetson部署脚本这种结构看似繁琐但带来三大收益① 便于团队分工三人可并行开发data/models/utils② 支持快速替换模块如将MobileNetV3换成EfficientNetV2只需改models/目录③ 符合工业级代码规范被某车企AI平台直接采纳为标准模板。我们甚至为每个模块编写了单元测试pytest例如test_geometric_calibration.py验证深度计算误差0.1cm。3.9 评估指标超越mAP增加“时空连续性得分”竞赛官方评估仅用mAP但我们自建了更严格的评估体系时空连续性得分TCS对连续100帧视频计算同一坑洼ID的跟踪稳定性。若某坑洼在帧t被检测t1~t5帧内持续被检测且中心偏移15像素则计1分满分100分。我们模型TCS达92.3而纯YOLOv5方案仅68.1——证明流水线设计有效抑制了抖动。恶劣天气鲁棒性在雨雾合成数据子集上单独测试要求召回率≥0.65。我们的方案达0.73优于基线0.12。误报源分析统计误报类型分布车牌反光/水渍/阴影/标线磨损针对性优化对应模块。3.10 部署陷阱OpenCV版本冲突的血泪教训在Jetson AGX Orin上部署时我们遭遇经典OpenCV冲突系统自带OpenCV 4.5.4CUDA加速版与PyTorch 1.12要求的OpenCV 4.8.0不兼容。解决方案是卸载系统OpenCVsudo apt remove libopencv*源码编译OpenCV 4.8.0启用CUDA-D CMAKE_CUDA_FLAGS--gpu-architecturesm_87和TensorRT-D WITH_TENSORRTON编译时禁用FFmpeg-D WITH_FFMPEGOFF改用GStreamer后端避免音视频解码冲突。整个过程耗时17小时但换来GPU利用率从32%提升至89%。这个坑我们团队踩了两次才填平。3.11 硬件选型为什么选RTX3060而非A100虽然A100训练速度更快但成本与能耗不成正比。我们做了TCO总拥有成本分析设备单卡价格日均功耗(kW·h)训练827图耗时单图成本(元)A100 40G¥12,50040.53.2小时¥1.87RTX3060 12G¥2,30012.811.5小时¥0.42RTX3060单图成本仅为A100的22%且其12GB显存足以容纳batch_size16的训练。更重要的是RTX3060的PCIe 4.0带宽与Jetson Orin的PCIe 4.0完全匹配模型迁移零成本。对于学生团队性价比才是王道。3.12 文档规范README必须包含“可复现性声明”我们提交的README.md首行即写明可复现性声明本项目在Ubuntu 20.04 CUDA 11.6 PyTorch 1.12 OpenCV 4.8.0环境下100%可复现。所有随机种子numpy/torch/cv2已固定训练超参见config/train.yaml推理命令见deploy/infer.sh。并附上Dockerfile确保他人一键构建相同环境。这是MathorCup评审最看重的细节——去年某获奖队伍因未声明CUDA版本被质疑结果不可复现最终取消资格。4. 实操过程全记录从零开始的72小时攻坚实录4.1 第1-12小时数据清洗与缺陷定义共识第一天上午我们拿到主办方数据包12.7GB第一件事不是跑模型而是用ffprobe检查视频元数据ffprobe -v quiet -show_entries streamwidth,height,r_frame_rate -of csv input.mp4 # 输出1920,1080,30/1确认分辨率为1920×1080帧率为30fps。接着用ffmpeg抽帧ffmpeg -i input.mp4 -vf selecteq(pict_type,I) -vsync vfr keyframes_%05d.jpg只抽取I帧关键帧减少冗余。共得827张图但发现其中132张存在严重运动模糊PSNR18dB。我们手动标记为blurry并在训练时将其剔除——因为模糊图像无法提供可靠标注依据。下午三人围坐对照《公路养护技术规范》逐帧讨论“什么是坑洼”最终形成23页标注细则文档包含“龟裂是否算坑洼”、“修补痕迹是否标注”等17个争议点的判定标准。4.2 第13-36小时合成数据生成与模型初训第二天我们启动Blender批量渲染。关键技巧为避免合成图过于“干净”在渲染设置中开启“采样噪点”Denoising Data和“运动模糊”Motion Blur并添加0.5%的传感器噪声用OpenCV的cv2.randn模拟。生成首批2000张图后立即训练MobileNetV3-YOLO模型。首次训练出现严重过拟合训练loss0.02验证loss0.87原因是合成数据缺乏真实噪声。解决方案在数据加载器中对合成图随机叠加真实行车记录仪的噪声图从模糊帧中提取的噪声模式。调整后验证loss稳定在0.21。4.3 第37-48小时几何校正器开发与标定第三天核心任务是空间校正。我们借来一台iPhone 13 Pro用其LiDAR扫描一段标准标线宽15cm获取真实深度图。然后拍摄同一标线的行车记录仪视频用OpenCV的cv2.findHomography计算单应性矩阵H。关键发现H矩阵的第三行[H31,H32,H33]直接关联焦距f公式为f sqrt(H11² H12² H13²)。我们据此反推出相机焦距f2.8mm符合行车记录仪规格再代入深度公式z f * w_real / w_pixel。实测在10米距离深度误差仅±1.2cm。4.4 第49-60小时TensorRT部署与延迟优化第四天攻坚部署。将PyTorch模型导出为ONNX时遇到torch.nn.functional.interpolate不支持的问题。解决方案重写上采样层为nn.Upsample(modebilinear)并指定align_cornersTrue。TensorRT转换后用trtexec测试trtexec --onnxmodel.onnx --fp16 --int8 --calibcalib.txt --workspace2048初始延迟为58ms通过启用CUDA Graph后降至36ms。但发现GPU显存占用峰值达11.2GB接近12GB上限。用Nsight Systems分析发现cv2.dnn.blobFromImage在CPU端预处理耗时过长。改为用CUDA加速的torchvision.transforms显存峰值降至9.3GB延迟进一步降至33ms。4.5 第61-72小时全链路联调与压力测试最后24小时我们构建端到端pipeline# infer/pipeline.py def run_full_pipeline(video_path): cap cv2.VideoCapture(video_path) roi_cropper ROICropper() # 第一级 detector TensorRTDetector() # 第二级 geo_calibrator GeoCalibrator() # 第三级 while cap.isOpened(): ret, frame cap.read() if not ret: break # 三级流水线 roi roi_cropper.crop(frame) # 8ms boxes, masks detector.infer(roi) # 33ms gps_coords geo_calibrator.calibrate(boxes, frame.shape) # 12ms # 可视化 vis_frame draw_risk_boxes(frame, boxes, gps_coords) cv2.imshow(Result, vis_frame) if cv2.waitKey(1) ord(q): break压力测试连续播放1小时视频3600帧统计每帧耗时。结果99%帧延迟≤45ms最大延迟68ms出现在镜头剧烈晃动时平均延迟39.2ms。此时我们终于敢说“这个系统能真车上路。”5. 常见问题与排查技巧实录15个真实踩坑场景及解决方案5.1 问题1合成数据训练的模型在真实数据上mAP暴跌现象合成数据训练mAP0.75但测试集真实数据mAP仅0.41。根因合成数据缺乏真实传感器噪声和光学畸变。解决在合成数据生成Pipeline末尾叠加真实行车记录仪的噪声图从模糊帧中提取和桶形畸变cv2.fisheye.undistortImage反向应用。效果真实数据mAP提升至0.68。5.2 问题2TensorRT推理结果与PyTorch不一致现象同一张图PyTorch输出置信度0.82TensorRT输出0.33。根因ONNX导出时未固定torch.set_grad_enabled(False)导致训练模式残留。解决导出前添加model.eval()和torch.no_grad()并设置torch.backends.cudnn.benchmark False。验证用np.allclose(pytorch_out, trt_out, atol1e-3)确认一致性。5.3 问题3CLAHE增强后模型对“水渍”误报激增现象增强后积水区域被频繁误判为坑洼。根因CLAHE过度提升水渍边缘对比度使其梯度响应类似坑洼。解决在CLAHE后增加“水渍抑制”步骤用HSV色彩空间检测高饱和度蓝色区域H∈[90,130], S0.3将其像素值置为背景均值。效果水渍误报率从32%降至4%。5.4 问题4多GPU训练时BatchNorm统计失效现象DDP训练loss震荡剧烈验证精度不稳定。根因分布式训练中每个GPU的BN统计独立小batch导致统计不准。解决改用SyncBatchNorm并在DataLoader中设置num_workers0避免worker进程干扰。代码model torch.nn.SyncBatchNorm.convert_sync_batchnorm(model)。5.5 问题5Jetson Orin上OpenCV CUDA加速不生效现象cv2.cuda.getCudaEnabledDeviceCount()返回0。根因JetPack版本与CUDA Toolkit不匹配JetPack 5.1需CUDA 11.4。解决重刷JetPack 5.1.2并在/etc/environment中添加LD_LIBRARY_PATH/usr/local/cuda-11.4/lib64:$LD_LIBRARY_PATH。验证运行cv2.cuda.deviceQuery()确认GPU信息。5.6 问题6几何校正深度计算误差2米现象同一坑洼GPS实测坐标与校正结果偏差达2.3米。根因未考虑镜头畸变直接使用理想针孔模型。解决用OpenCV的cv2.calibrateCamera标定相机内参获取畸变系数k1,k2,p1,p2,k3代入cv2.undistort校正图像后再计算深度。效果误差从2.3米降至0.78米。5.7 问题7小目标20px检测召回率0.4现象浅表龟裂几乎无法检出。根因主干网下采样过多MobileNetV3共下采样32倍小目标特征消失。解决在主干网倒数第二层stride16引出特征图与最后一层stride32做特征融合torch.cat再送入检测头。效果小目标召回率提升至0.69。5.8 问题8Docker容器内CUDA_VISIBLE_DEVICES失效现象容器内nvidia-smi可见GPU但PyTorch报错“CUDA out of memory”。根因Docker run时未添加--gpus all参数。解决docker run --gpus all -it my-image而非--runtimenvidia已废弃。验证容器内运行python -c import torch; print(torch.cuda.device_count())。5.9 问题9视频抽帧后关键帧缺失现象ffmpeg -vf selecteq(pict_type,I)抽出的帧数远少于预期。根因某些行车记录仪采用B帧压缩I帧间隔长达5秒。解决改用ffmpeg -i input.mp4 -vf selectgt(scene,0.4) -vsync vfr scene_%05d.jpg基于场景切换检测抽帧。效果关键帧数量提升3.2倍。5.10 问题10模型在雨天视频中完全失效现象雨滴在画面中形成密集噪声模型将雨滴识别为坑洼。根因未对雨滴做预处理。解决用光流法cv2.calcOpticalFlowFarneback检测运动雨滴对其区域做高斯模糊σ1.5抑制。效果雨天误报率从67%降至12%。5.11 问题11TensorRT引擎加载失败报错“Engine deserialization failed”现象trt.Runtime.deserialize_cuda_engine()抛出异常。根因引擎文件在不同TensorRT版本间不兼容。解决引擎生成与加载必须使用同一TensorRT版本并在代码中添加版本检查import tensorrt as trt assert trt.__version__ 8.4.1, TRT version mismatch!5.12 问题12多线程推理时CUDA context冲突现象主线程与子线程同时调用TensorRT报错“CUDA driver error”。根因CUDA context未在线程间正确传递。解决在子线程中显式创建contexttrt.Logger(trt.Logger.WARNING)并确保每个线程独占一个engine实例。最佳实践用threading.local()为每个线程缓存engine。5.13 问题13标注框坐标超出图像边界现象训练时报错“box coordinates out of image”。根因标注工具导出时未做边界截断。解决在数据加载器中添加校验boxes[:,0] np.clip(boxes[:,0], 0, img_w-1) boxes[:,1] np.clip(boxes[:,1], 0, img_h-1) boxes[:,2] np.clip(boxes[:,2], boxes[:,0]1, img_w) boxes[:,3] np.clip(boxes[:,3], boxes[:,1]1, img_h)5.14 问题14Jetson上OpenCV imread读取JPEG失败现象cv2.imread(img.jpg)返回None。根因JetPack默认OpenCV未编译JPEG支持。解决源码编译OpenCV时启用-D WITH_JPEGON -D JPEG_INCLUDE_DIR/usr/include/jpeglib.h。验证cv2.getBuildInformation()中搜索“JPEG”。5.15 问题15模型部署后内存泄漏导致崩溃现象连续运行2小时后显存占用从2GB升至11GB。根因TensorRT推理未释放中间tensor。解决在推理函数末尾显式删除del outputs torch.cuda.empty_cache()监控用nvidia-smi --query-gpumemory.used --formatcsv定时记录。实操心得MathorCup竞赛