简介本资源为基于YOLOv8-OBB的芯片引脚缺陷检测完整项目采用TensorRT进行推理加速面向计算机、人工智能、电子信息等专业的在校学生、教师及企业开发者可用于毕业设计、课程设计、项目立项或算法进阶学习。压缩包共394个文件约4.7MB以C头文件与源文件为主辅以CUDA核函数、ONNX解析与TensorRT部署相关代码并包含少量说明文档、配置文件与预览图整体结构清晰便于按模块查阅与二次开发。项目已通过导师评审答辩成绩达95分代码经测试可正常运行。内容涵盖旋转框目标检测、模型转换、TensorRT推理加速及缺陷识别流程读者可据此掌握从训练到部署的完整链路并在此基础上修改以适配其他检测任务。目前已有63人学习下载适合具备一定深度学习基础、希望深入理解工业缺陷检测与推理优化的读者参考使用。1. 芯片引脚缺陷检测为什么值得用 YOLOv8-OBB 重做一遍芯片引脚缺陷检测这个场景传统做法是模板匹配加形态学规则写得越多越脆。引脚歪一点、氧化一点、背景光变一点阈值就得重调产线换批次就是一场玄学。YOLOv8-OBB 的价值在于把「框」换成「带角度的旋转框」引脚这种细长目标用水平框标注会引入大量背景OBB 直接贴合引脚走向分类和定位一起学泛化比手写规则稳得多。再叠上 TensorRT 加速单张推理从几十毫秒压到几毫秒才够得上产线节拍。这套「源码文档全部资料」的组合适合两类人一类是想把检测模型真正推到工控机或边缘盒子上跑起来的算法工程师另一类是做课程设计、毕业设计需要一份能跑通、能讲清楚全流程的完整工程的人。下面我按自己落地的顺序把数据、训练、导出、加速、排错一条线讲透。2. 从标注到 OBB 数据集引脚检测的数据准备与格式转换2.1 为什么引脚必须用旋转框而不是水平框引脚在芯片图像里是细长条长宽比经常到 8:1 甚至更高。用水平框标注框里塞进去的绝大部分是背景和相邻引脚模型学到的特征被稀释密集引脚还会出现框重叠、NMS 互相压制。旋转框用中心点、宽、高、角度五个量描述目标框和引脚几乎重合分类头拿到的特征干净回归头也不用在角度上瞎猜。YOLOv8-OBB 的角度定义是重点踩过坑的都懂。它用的是「角度在 [0, 90) 区间、宽高按长边短边归一」的表示也就是 DOTA 那套定义。你自己标数据时如果角度从 -90 到 90 随便给训练时 loss 会震荡mAP 上不去。常见做法是标注阶段就统一让宽始终对应较长的那条边角度取锐角。标注工具用 roLabelImg 或 X-AnyLabeling 都行导出格式选 DOTA 或 YOLO-OBB。2.2 DOTA 转 YOLO-OBB 的转换脚本与四个边界坑DOTA 格式是每行八个坐标加类别名YOLO-OBB 是class x y w h angle归一化。转换脚本不长但边界情况特别多。import os import cv2 import numpy as np def dota_to_yolo_obb(dota_line, img_w, img_h, class_map): parts dota_line.strip().split() # DOTA: x1 y1 x2 y2 x3 y3 x4 y4 class_name difficult coords np.array(parts[:8], dtypenp.float32).reshape(4, 2) cls_name parts[8] cls_id class_map[cls_name] # 用 minAreaRect 反推中心点、宽高、角度避免自己算角度出错 rect cv2.minAreaRect(coords) (cx, cy), (w, h), angle rect # 关键统一成长边为宽、角度落在 [0, 90) if w h: w, h h, w angle 90 angle angle % 180 if angle 90: angle - 180 w, h h, w angle angle % 90 # 归一化 cx / img_w cy / img_h w / img_w h / img_h return f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f} {angle:.6f}逻辑说明用cv2.minAreaRect而不是手写向量叉积算角度是因为 OpenCV 内部对角度和宽高的约定和 YOLOv8-OBB 接近少一层换算就少一层错。参数上class_map是类别名到 id 的字典必须和训练时的data.yaml顺序一致顺序错了模型会把「缺脚」认成「弯脚」。四个边界坑第一minAreaRect返回的角度在不同 OpenCV 版本里范围不一样老版本是 [-90, 0)新版本是 (0, 90]所以上面用取模加判断兜底。第二坐标越界标注时框超出图像边界的转换后 cx、cy 会大于 1训练直接报错转换前要 clip。第三空行和 difficult 标记DOTA 里 difficult1 的样本建议直接丢弃别喂给模型。第四类别名大小写pin_bent和Pin_Bent会被当成两类统一小写最省事。2.3 data.yaml 与目录结构怎么摆YOLOv8-OBB 对目录结构不挑但data.yaml里路径写错是新手第一翻车点。推荐结构dataset/ images/ train/ val/ labels/ train/ val/path: /home/user/dataset train: images/train val: images/val names: 0: normal 1: bent 2: missing 3: offset注意names用字典还是列表都行但 id 必须从 0 连续。标签文件名要和图片同名、只换后缀img_001.jpg对应img_001.txt对不上会被静默跳过训练时 loss 正常但 mAP 是 0这种黑匣子现象八成是路径或文件名问题。3. YOLOv8-OBB 训练参数怎么设、指标怎么看3.1 从预训练权重起步的最小训练命令别从零训OBB 的预训练权重能省掉大量收敛时间。yolo obb train \ modelyolov8n-obb.pt \ datadataset/data.yaml \ epochs200 \ imgsz1024 \ batch8 \ device0 \ workers4 \ patience50 \ lr00.01 \ cos_lrTrue \ projectruns/obb \ namepin_v1逻辑说明model选 n 还是 s 看你的算力和精度要求引脚缺陷这种细粒度任务n 在 1024 输入下通常够用s 更稳但慢。imgsz1024是关键引脚太细640 下小目标特征基本丢光我一般直接上 1024 甚至 1280。batch受显存限制8G 显存跑 1024 大概只能到 8。patience50是早停OBB 后期容易过拟合早停能救回最优权重。cos_lr配合lr00.01比固定学习率收敛更平滑。3.2 必调的四个参数与它们对引脚检测的影响参数建议值作用与调法imgsz1024 / 1280决定小目标可见度引脚细必须加大代价是显存和耗时batch显存允许的最大值太小 BN 统计不稳太大会 OOM先试 8 再上下调lr00.01太大 loss 炸太小收敛慢配合 cos_lr 用degrees0默认OBB 自带角度回归别开 Mosaic 的旋转增强去干扰角度学习degrees这条是血泪经验。有人习惯性开旋转增强结果 OBB 的角度回归和增强后的角度打架mAP 反而降。OBB 任务里角度是标签的一部分增强要谨慎mosaic、mixup可以留旋转类增强建议关掉或调很小。3.3 训练日志里该盯哪几个指标box_loss、cls_loss、dfl_loss三条曲线正常是同步下降。如果cls_loss降但box_loss不降多半是角度标注不统一如果dfl_loss一直高是框回归没学好检查标注框是否贴合引脚。验证集看mAP50和mAP50-95OBB 的 mAP 普遍比水平框低几个点别拿水平框的 0.9 去要求 OBB0.75 以上在引脚场景就算能用。混淆矩阵重点看bent和offset有没有互相混这两类角度接近混了说明角度特征没学出来回去查标注。4. 导出 ONNX 再转 TensorRTpt 文件转换 tensorrt 的完整链路4.1 为什么不能直接从 pt 转 engineUltralytics 支持formatengine直接导出但生产环境我强烈建议走 ONNX 中转。原因有三ONNX 是中间表示出问题能单独验证TensorRT 版本和 CUDA 版本耦合ONNX 让你换环境时不用重训OBB 的输出头结构特殊直接转 engine 有时输出维度对不上ONNX 能先看清楚。# 第一步pt 转 onnx注意 opset 和 simplify yolo export \ modelruns/obb/pin_v1/weights/best.pt \ formatonnx \ imgsz1024 \ opset12 \ simplifyTrue \ dynamicFalse逻辑说明opset12是兼容性最好的选择太高有些 TensorRT 版本不认。simplifyTrue会跑 onnx-simplifier 去掉冗余节点对 OBB 的旋转框解码尤其有用。dynamicFalse固定输入尺寸TensorRT 能针对固定 shape 做最优优化产线上图片尺寸固定没必要开动态。4.2 trtexec 转 engine 与精度选择trtexec \ --onnxbest.onnx \ --saveEnginebest_fp16.engine \ --fp16 \ --workspace4096 \ --minShapesimages:1x3x1024x1024 \ --optShapesimages:8x3x1024x1024 \ --maxShapesimages:16x3x1024x1024逻辑说明--fp16在支持 fp16 的卡上几乎无损提速引脚检测对精度敏感度中等fp16 通常够。--workspace4096是 4G 显存给优化器用太小会 fallback 到慢的 kernel。shape 三个档位是给动态 batch 用的如果你固定 batch1直接--shapesimages:1x3x1024x1024更省事。转完看 trtexec 打印的Throughput和GPU Compute Time这才是真实性能。4.3 TensorRT 10.x 在 GTX1070 上到底能不能跑这是热搜里问得最多的问题。结论能装能跑但有限制。GTX1070 是 Pascal 架构compute capability 6.1TensorRT 10.x 官方支持列表里 Pascal 还在但 fp16 的加速收益比 Turing 之后的卡小很多因为 Pascal 的 fp16 吞吐是 fp32 的 1/64消费级卡被砍过。所以 1070 上跑 fp16 engine 可能比 fp32 还慢建议直接--fp32或者--int8int8 需要校准麻烦。另外 TensorRT 10.x 对 CUDA 版本要求高1070 能装的驱动版本有限装之前先确认驱动支持的 CUDA 上限别硬上最新版。我一般在这种老卡上就用 TensorRT 8.x稳定且资料多。5. 推理部署与避坑从 engine 到产线节拍5.1 Python 端加载 engine 并做 OBB 后处理import tensorrt as trt import pycuda.driver as cuda import numpy as np import cv2 class OBBInfer: def __init__(self, engine_path): logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f, trt.Runtime(logger) as runtime: self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() # 绑定输入输出TensorRT 10 用 get_tensor_name 遍历 self.bindings [] for i in range(self.engine.num_io_tensors): name self.engine.get_tensor_name(i) shape self.engine.get_tensor_shape(name) dtype trt.nptype(self.engine.get_tensor_dtype(name)) self.bindings.append((name, shape, dtype)) def preprocess(self, img, size1024): # letterbox 保持比例OBB 对形变敏感别直接 resize h, w img.shape[:2] scale min(size / h, size / w) nh, nw int(h * scale), int(w * scale) resized cv2.resize(img, (nw, nh)) canvas np.full((size, size, 3), 114, dtypenp.uint8) canvas[:nh, :nw] resized blob canvas[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 return np.ascontiguousarray(blob[None]), scale逻辑说明OBB 对图像形变比水平框更敏感因为角度会被拉伸改变所以预处理必须 letterbox 而不是直接 resize。114是 YOLO 系列惯用的填充灰度。后处理部分要把 TensorRT 输出的[1, 4nc1, num_anchors]解码成旋转框再做旋转 NMS这部分建议直接复用 Ultralytics 的non_max_suppression里 OBB 分支自己写容易在角度周期上出错。5.2 避坑与排查五条产线级踩坑记录现象engine 推理结果和 pt 推理对不上框位置偏移。原因预处理不一致pt 推理时 Ultralytics 内部做了 letterbox你手写的预处理没对齐 padding 比例。解决把 pt 推理的预处理参数打印出来逐项对齐尤其是 scale 和 pad 的计算方式。现象TensorRT 转换报 unsupported op。原因ONNX 里有些算子 TensorRT 版本不支持OBB 的旋转框解码里常见GridSample或自定义 op。解决升级 TensorRT 到支持该 op 的版本或在导出时用simplify把 op 融合掉实在不行把后处理挪到 CPU 用 numpy 做。现象fp16 engine 精度掉得厉害mAP 掉 10 个点。原因Pascal 或老架构卡 fp16 吞吐被砍且部分层 fp16 溢出。解决改 fp32或对敏感层用--precisionConstraints强制 fp32TensorRT 支持逐层精度设置。现象batch 加大后显存 OOM。原因workspace 和 activation 显存叠加1024 输入下 activation 很大。解决降 workspace或改用--optShapes让 TensorRT 按实际 batch 优化别一上来就 maxShapes 拉满。现象产线跑几小时后推理变慢。原因显存碎片或 context 没复用每帧新建 context。解决engine 和 context 全局只建一次输入输出 buffer 预分配复用别在循环里反复 allocate。5.3 节拍估算与硬件选型1024 输入、YOLOv8n-OBB、fp16在 RTX 3060 上单张大概 4-6ms加上预处理和后处理端到端 10ms 左右100 FPS 够大多数产线。GTX1070 上 fp32 大概 20-30ms30-50 FPS如果产线节拍是每秒 10 个芯片够用要更快就得上 Turing 之后的卡。选型原则先算清产线节拍要求再倒推需要的 FPS别盲目堆卡。6. 把 OBB 检测做稳的一个进阶技巧角度一致性校验模型训完、engine 转完不代表能上产线。引脚检测最隐蔽的问题是角度抖动同一个引脚连续几帧检测出来的角度在 0 和 90 附近跳后处理算偏移量时就会误判。根因是 OBB 的角度回归在边界处不连续0 度和 90 度物理上是同一个方向但数值上差 90。我的做法是加一层角度一致性校验在推理后处理里做def normalize_angle(angle, w, h): # 把角度统一到 [0, 90)并保证宽是长边 if w h: w, h h, w angle 90 angle angle % 180 if angle 90: angle - 180 w, h h, w return angle % 90, w, h def angle_stable(prev_angle, cur_angle, threshold5.0): # 角度差超过阈值就认为抖动用上一帧平滑 diff abs(prev_angle - cur_angle) diff min(diff, 90 - diff) # 角度周期是 90 if diff threshold: return prev_angle return cur_angle逻辑说明normalize_angle和训练时的标注约定保持一致保证推理和训练同分布。angle_stable利用角度 90 度周期性算最小差超过阈值就用上一帧角度相当于一个轻量卡尔曼。threshold5.0是我在引脚场景试出来的太小会跟不住真实变化太大抖动滤不掉按你的引脚尺寸和相机帧率调。验证这套是否有效别只看 mAP。我会单独统计连续帧的角度方差方差降下来才算稳。另外准备一批「边界样本」——引脚刚好水平或垂直的图专门看这些样本的角度输出有没有跳变这是 OBB 最容易翻车的地方。最后说个习惯每次改完标注或增强策略我都会把同一批图在 pt 和 engine 上各跑一遍逐框对比角度和坐标差超过 1 个像素就查预处理。这个后悔药比上线后返工便宜太多。希望帮到你。本文还有配套的精品资源点击获取
YOLOv8-OBB芯片引脚缺陷检测：从标注、训练到TensorRT部署全流程
简介本资源为基于YOLOv8-OBB的芯片引脚缺陷检测完整项目采用TensorRT进行推理加速面向计算机、人工智能、电子信息等专业的在校学生、教师及企业开发者可用于毕业设计、课程设计、项目立项或算法进阶学习。压缩包共394个文件约4.7MB以C头文件与源文件为主辅以CUDA核函数、ONNX解析与TensorRT部署相关代码并包含少量说明文档、配置文件与预览图整体结构清晰便于按模块查阅与二次开发。项目已通过导师评审答辩成绩达95分代码经测试可正常运行。内容涵盖旋转框目标检测、模型转换、TensorRT推理加速及缺陷识别流程读者可据此掌握从训练到部署的完整链路并在此基础上修改以适配其他检测任务。目前已有63人学习下载适合具备一定深度学习基础、希望深入理解工业缺陷检测与推理优化的读者参考使用。1. 芯片引脚缺陷检测为什么值得用 YOLOv8-OBB 重做一遍芯片引脚缺陷检测这个场景传统做法是模板匹配加形态学规则写得越多越脆。引脚歪一点、氧化一点、背景光变一点阈值就得重调产线换批次就是一场玄学。YOLOv8-OBB 的价值在于把「框」换成「带角度的旋转框」引脚这种细长目标用水平框标注会引入大量背景OBB 直接贴合引脚走向分类和定位一起学泛化比手写规则稳得多。再叠上 TensorRT 加速单张推理从几十毫秒压到几毫秒才够得上产线节拍。这套「源码文档全部资料」的组合适合两类人一类是想把检测模型真正推到工控机或边缘盒子上跑起来的算法工程师另一类是做课程设计、毕业设计需要一份能跑通、能讲清楚全流程的完整工程的人。下面我按自己落地的顺序把数据、训练、导出、加速、排错一条线讲透。2. 从标注到 OBB 数据集引脚检测的数据准备与格式转换2.1 为什么引脚必须用旋转框而不是水平框引脚在芯片图像里是细长条长宽比经常到 8:1 甚至更高。用水平框标注框里塞进去的绝大部分是背景和相邻引脚模型学到的特征被稀释密集引脚还会出现框重叠、NMS 互相压制。旋转框用中心点、宽、高、角度五个量描述目标框和引脚几乎重合分类头拿到的特征干净回归头也不用在角度上瞎猜。YOLOv8-OBB 的角度定义是重点踩过坑的都懂。它用的是「角度在 [0, 90) 区间、宽高按长边短边归一」的表示也就是 DOTA 那套定义。你自己标数据时如果角度从 -90 到 90 随便给训练时 loss 会震荡mAP 上不去。常见做法是标注阶段就统一让宽始终对应较长的那条边角度取锐角。标注工具用 roLabelImg 或 X-AnyLabeling 都行导出格式选 DOTA 或 YOLO-OBB。2.2 DOTA 转 YOLO-OBB 的转换脚本与四个边界坑DOTA 格式是每行八个坐标加类别名YOLO-OBB 是class x y w h angle归一化。转换脚本不长但边界情况特别多。import os import cv2 import numpy as np def dota_to_yolo_obb(dota_line, img_w, img_h, class_map): parts dota_line.strip().split() # DOTA: x1 y1 x2 y2 x3 y3 x4 y4 class_name difficult coords np.array(parts[:8], dtypenp.float32).reshape(4, 2) cls_name parts[8] cls_id class_map[cls_name] # 用 minAreaRect 反推中心点、宽高、角度避免自己算角度出错 rect cv2.minAreaRect(coords) (cx, cy), (w, h), angle rect # 关键统一成长边为宽、角度落在 [0, 90) if w h: w, h h, w angle 90 angle angle % 180 if angle 90: angle - 180 w, h h, w angle angle % 90 # 归一化 cx / img_w cy / img_h w / img_w h / img_h return f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f} {angle:.6f}逻辑说明用cv2.minAreaRect而不是手写向量叉积算角度是因为 OpenCV 内部对角度和宽高的约定和 YOLOv8-OBB 接近少一层换算就少一层错。参数上class_map是类别名到 id 的字典必须和训练时的data.yaml顺序一致顺序错了模型会把「缺脚」认成「弯脚」。四个边界坑第一minAreaRect返回的角度在不同 OpenCV 版本里范围不一样老版本是 [-90, 0)新版本是 (0, 90]所以上面用取模加判断兜底。第二坐标越界标注时框超出图像边界的转换后 cx、cy 会大于 1训练直接报错转换前要 clip。第三空行和 difficult 标记DOTA 里 difficult1 的样本建议直接丢弃别喂给模型。第四类别名大小写pin_bent和Pin_Bent会被当成两类统一小写最省事。2.3 data.yaml 与目录结构怎么摆YOLOv8-OBB 对目录结构不挑但data.yaml里路径写错是新手第一翻车点。推荐结构dataset/ images/ train/ val/ labels/ train/ val/path: /home/user/dataset train: images/train val: images/val names: 0: normal 1: bent 2: missing 3: offset注意names用字典还是列表都行但 id 必须从 0 连续。标签文件名要和图片同名、只换后缀img_001.jpg对应img_001.txt对不上会被静默跳过训练时 loss 正常但 mAP 是 0这种黑匣子现象八成是路径或文件名问题。3. YOLOv8-OBB 训练参数怎么设、指标怎么看3.1 从预训练权重起步的最小训练命令别从零训OBB 的预训练权重能省掉大量收敛时间。yolo obb train \ modelyolov8n-obb.pt \ datadataset/data.yaml \ epochs200 \ imgsz1024 \ batch8 \ device0 \ workers4 \ patience50 \ lr00.01 \ cos_lrTrue \ projectruns/obb \ namepin_v1逻辑说明model选 n 还是 s 看你的算力和精度要求引脚缺陷这种细粒度任务n 在 1024 输入下通常够用s 更稳但慢。imgsz1024是关键引脚太细640 下小目标特征基本丢光我一般直接上 1024 甚至 1280。batch受显存限制8G 显存跑 1024 大概只能到 8。patience50是早停OBB 后期容易过拟合早停能救回最优权重。cos_lr配合lr00.01比固定学习率收敛更平滑。3.2 必调的四个参数与它们对引脚检测的影响参数建议值作用与调法imgsz1024 / 1280决定小目标可见度引脚细必须加大代价是显存和耗时batch显存允许的最大值太小 BN 统计不稳太大会 OOM先试 8 再上下调lr00.01太大 loss 炸太小收敛慢配合 cos_lr 用degrees0默认OBB 自带角度回归别开 Mosaic 的旋转增强去干扰角度学习degrees这条是血泪经验。有人习惯性开旋转增强结果 OBB 的角度回归和增强后的角度打架mAP 反而降。OBB 任务里角度是标签的一部分增强要谨慎mosaic、mixup可以留旋转类增强建议关掉或调很小。3.3 训练日志里该盯哪几个指标box_loss、cls_loss、dfl_loss三条曲线正常是同步下降。如果cls_loss降但box_loss不降多半是角度标注不统一如果dfl_loss一直高是框回归没学好检查标注框是否贴合引脚。验证集看mAP50和mAP50-95OBB 的 mAP 普遍比水平框低几个点别拿水平框的 0.9 去要求 OBB0.75 以上在引脚场景就算能用。混淆矩阵重点看bent和offset有没有互相混这两类角度接近混了说明角度特征没学出来回去查标注。4. 导出 ONNX 再转 TensorRTpt 文件转换 tensorrt 的完整链路4.1 为什么不能直接从 pt 转 engineUltralytics 支持formatengine直接导出但生产环境我强烈建议走 ONNX 中转。原因有三ONNX 是中间表示出问题能单独验证TensorRT 版本和 CUDA 版本耦合ONNX 让你换环境时不用重训OBB 的输出头结构特殊直接转 engine 有时输出维度对不上ONNX 能先看清楚。# 第一步pt 转 onnx注意 opset 和 simplify yolo export \ modelruns/obb/pin_v1/weights/best.pt \ formatonnx \ imgsz1024 \ opset12 \ simplifyTrue \ dynamicFalse逻辑说明opset12是兼容性最好的选择太高有些 TensorRT 版本不认。simplifyTrue会跑 onnx-simplifier 去掉冗余节点对 OBB 的旋转框解码尤其有用。dynamicFalse固定输入尺寸TensorRT 能针对固定 shape 做最优优化产线上图片尺寸固定没必要开动态。4.2 trtexec 转 engine 与精度选择trtexec \ --onnxbest.onnx \ --saveEnginebest_fp16.engine \ --fp16 \ --workspace4096 \ --minShapesimages:1x3x1024x1024 \ --optShapesimages:8x3x1024x1024 \ --maxShapesimages:16x3x1024x1024逻辑说明--fp16在支持 fp16 的卡上几乎无损提速引脚检测对精度敏感度中等fp16 通常够。--workspace4096是 4G 显存给优化器用太小会 fallback 到慢的 kernel。shape 三个档位是给动态 batch 用的如果你固定 batch1直接--shapesimages:1x3x1024x1024更省事。转完看 trtexec 打印的Throughput和GPU Compute Time这才是真实性能。4.3 TensorRT 10.x 在 GTX1070 上到底能不能跑这是热搜里问得最多的问题。结论能装能跑但有限制。GTX1070 是 Pascal 架构compute capability 6.1TensorRT 10.x 官方支持列表里 Pascal 还在但 fp16 的加速收益比 Turing 之后的卡小很多因为 Pascal 的 fp16 吞吐是 fp32 的 1/64消费级卡被砍过。所以 1070 上跑 fp16 engine 可能比 fp32 还慢建议直接--fp32或者--int8int8 需要校准麻烦。另外 TensorRT 10.x 对 CUDA 版本要求高1070 能装的驱动版本有限装之前先确认驱动支持的 CUDA 上限别硬上最新版。我一般在这种老卡上就用 TensorRT 8.x稳定且资料多。5. 推理部署与避坑从 engine 到产线节拍5.1 Python 端加载 engine 并做 OBB 后处理import tensorrt as trt import pycuda.driver as cuda import numpy as np import cv2 class OBBInfer: def __init__(self, engine_path): logger trt.Logger(trt.Logger.WARNING) with open(engine_path, rb) as f, trt.Runtime(logger) as runtime: self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() # 绑定输入输出TensorRT 10 用 get_tensor_name 遍历 self.bindings [] for i in range(self.engine.num_io_tensors): name self.engine.get_tensor_name(i) shape self.engine.get_tensor_shape(name) dtype trt.nptype(self.engine.get_tensor_dtype(name)) self.bindings.append((name, shape, dtype)) def preprocess(self, img, size1024): # letterbox 保持比例OBB 对形变敏感别直接 resize h, w img.shape[:2] scale min(size / h, size / w) nh, nw int(h * scale), int(w * scale) resized cv2.resize(img, (nw, nh)) canvas np.full((size, size, 3), 114, dtypenp.uint8) canvas[:nh, :nw] resized blob canvas[:, :, ::-1].transpose(2, 0, 1).astype(np.float32) / 255.0 return np.ascontiguousarray(blob[None]), scale逻辑说明OBB 对图像形变比水平框更敏感因为角度会被拉伸改变所以预处理必须 letterbox 而不是直接 resize。114是 YOLO 系列惯用的填充灰度。后处理部分要把 TensorRT 输出的[1, 4nc1, num_anchors]解码成旋转框再做旋转 NMS这部分建议直接复用 Ultralytics 的non_max_suppression里 OBB 分支自己写容易在角度周期上出错。5.2 避坑与排查五条产线级踩坑记录现象engine 推理结果和 pt 推理对不上框位置偏移。原因预处理不一致pt 推理时 Ultralytics 内部做了 letterbox你手写的预处理没对齐 padding 比例。解决把 pt 推理的预处理参数打印出来逐项对齐尤其是 scale 和 pad 的计算方式。现象TensorRT 转换报 unsupported op。原因ONNX 里有些算子 TensorRT 版本不支持OBB 的旋转框解码里常见GridSample或自定义 op。解决升级 TensorRT 到支持该 op 的版本或在导出时用simplify把 op 融合掉实在不行把后处理挪到 CPU 用 numpy 做。现象fp16 engine 精度掉得厉害mAP 掉 10 个点。原因Pascal 或老架构卡 fp16 吞吐被砍且部分层 fp16 溢出。解决改 fp32或对敏感层用--precisionConstraints强制 fp32TensorRT 支持逐层精度设置。现象batch 加大后显存 OOM。原因workspace 和 activation 显存叠加1024 输入下 activation 很大。解决降 workspace或改用--optShapes让 TensorRT 按实际 batch 优化别一上来就 maxShapes 拉满。现象产线跑几小时后推理变慢。原因显存碎片或 context 没复用每帧新建 context。解决engine 和 context 全局只建一次输入输出 buffer 预分配复用别在循环里反复 allocate。5.3 节拍估算与硬件选型1024 输入、YOLOv8n-OBB、fp16在 RTX 3060 上单张大概 4-6ms加上预处理和后处理端到端 10ms 左右100 FPS 够大多数产线。GTX1070 上 fp32 大概 20-30ms30-50 FPS如果产线节拍是每秒 10 个芯片够用要更快就得上 Turing 之后的卡。选型原则先算清产线节拍要求再倒推需要的 FPS别盲目堆卡。6. 把 OBB 检测做稳的一个进阶技巧角度一致性校验模型训完、engine 转完不代表能上产线。引脚检测最隐蔽的问题是角度抖动同一个引脚连续几帧检测出来的角度在 0 和 90 附近跳后处理算偏移量时就会误判。根因是 OBB 的角度回归在边界处不连续0 度和 90 度物理上是同一个方向但数值上差 90。我的做法是加一层角度一致性校验在推理后处理里做def normalize_angle(angle, w, h): # 把角度统一到 [0, 90)并保证宽是长边 if w h: w, h h, w angle 90 angle angle % 180 if angle 90: angle - 180 w, h h, w return angle % 90, w, h def angle_stable(prev_angle, cur_angle, threshold5.0): # 角度差超过阈值就认为抖动用上一帧平滑 diff abs(prev_angle - cur_angle) diff min(diff, 90 - diff) # 角度周期是 90 if diff threshold: return prev_angle return cur_angle逻辑说明normalize_angle和训练时的标注约定保持一致保证推理和训练同分布。angle_stable利用角度 90 度周期性算最小差超过阈值就用上一帧角度相当于一个轻量卡尔曼。threshold5.0是我在引脚场景试出来的太小会跟不住真实变化太大抖动滤不掉按你的引脚尺寸和相机帧率调。验证这套是否有效别只看 mAP。我会单独统计连续帧的角度方差方差降下来才算稳。另外准备一批「边界样本」——引脚刚好水平或垂直的图专门看这些样本的角度输出有没有跳变这是 OBB 最容易翻车的地方。最后说个习惯每次改完标注或增强策略我都会把同一批图在 pt 和 engine 上各跑一遍逐框对比角度和坐标差超过 1 个像素就查预处理。这个后悔药比上线后返工便宜太多。希望帮到你。本文还有配套的精品资源点击获取