YOLOv5目标检测全解析：从网络结构到TensorRT部署实战

我记起来做目标检测那阵子最焦头烂额的阶段不是调参而是数据标到凌晨三点发现标错了一百多张图。后来项目上了 YOLOv5流程图和结构图在我脑子里过了无数遍踩过的坑也一个没落下。这篇就跟大家从原理拆到实战把 YOLOv5 从网络结构、训练配置到部署落地的完整链路说透特别是那些文档里不写、但实际一跑就翻车的细节。YOLOv5 是 Ultralytics 在 2020 年 6 月开源的目标检测框架以速度快、精度高、部署友好著称。它解决的痛点是多数科研模型停留在“精度不错但根本跑不动”的阶段而 YOLOv5 在普通 GPU 上就能训练在 CPU 甚至嵌入式设备上也能推理几乎成了工业级目标检测的事实标准。这篇适合谁看刚入门目标检测、想训练自己数据集的学生或者在 Jeston Nano 这类边缘设备上做落地开发的工程师都会从这里得到一张可直接照抄的路线图。1. 整体架构设计思路从输入端到输出端的全链路拆解1.1 一条数据怎么在 YOLOv5 里走完全程理解 YOLOv5 最快的方式是跟着一条图片数据从头走到尾。输入一张 640x640 的图片第一步不是进网络而是先进一个数据增强流水线。这里有个很多人不知道的细节Mosaic 增强会把 4 张图拼成一张相当于把 batch size 翻了 4 倍这也是 YOLOv5 在较小 batch 下依然能训出较好效果的底气之一。增强之后图片会按比例缩放剩余部分用灰度值 114 填充而不是简单拉伸这一步对保持目标长宽比例很关键。数据进网络后先经过 Backbone主干网络提取特征。YOLOv5s 的 Backbone 核心是 Focus 模块加 CSPNet 结构。Focus 模块做的操作很朴素——把图像的相邻像素切开来重组比如把 640x640x3 变成 320x320x12再用 32 个卷积核压成 320x320x32。这么做不是为了省参数而是为了在不下采样的前提下扩大感受野信息损失比直接 stride 卷积更小。CSPNet 则是把特征图分成两条路一条走主卷积一条直接过 shortcut最后再拼起来。这种设计让梯度反向传播时有一条高速公路避免深层网络梯度消失同时省内存。特征提取完成后进入 Neck 部分即 PANet 结构。这里做的事情是两个方向的特征融合自顶向下把高层语义信息传给低层让大目标更清晰自底向上把低层纹理信息传给高层让小目标也能被召回。这就是FPN PAN双塔结构的设计逻辑。最后融合后的特征被送到 Head 部分做预测。YOLOv5 的 Head 在不同尺寸的特征图上各做一次预测分别是 80x80 的小目标分支、40x40 的中目标分支和 20x80 的大目标分支每个分支上每个格子会预设 3 个 anchor。1.2 为什么 YOLOv5 不用 Anchor-Free反而继续保留 AnchorYOLOv5 从一开始就选了 Anchor-Based 路线这和当时很多号称免锚的模型形成鲜明对比。Anchor 可以理解为预设的参考框网络要做的事情不是直接预测目标的宽高而是预测相对预设框的偏移量和缩放系数。打个比方如果一个人站在你面前 10 米处Anchor-Based 策略是先猜他大概在 8~12 米位置再去修正Anchor-Free 则是完全没有参考点直接预测距离。有参考物其实是一种先验约束。COCO 数据集的标注框经过聚类之后能得到比较集中的宽高模式比如人往往是高大于宽汽车往往接近方形。YOLOv5 在训练前会先对自定义数据集的标注框做 K-Means 聚类重新计算这 3x39 个锚框的尺寸。这就是为什么官方预训练权重不能直接在自己的数据集上生效的原因之一——锚框不匹配收敛很慢。保留 Anchor 的另一个现实理由是部署友好。TensorRT、OpenVINO 这些推理引擎对 Anchor-Based 的算子优化得比较成熟而一些 Anchor-Free 模型需要额外实现 DCN 等复杂算子在 Jetson 这类设备上优化难度很高。这在工业落地上是个不能忽视的隐性成本。2. 核心网络机制解析你必须吃透的 4 个关键模块2.1 CSPDarknetYOLOv5 的主干核心为何能省内存Backbone 用的 CSPDarknet 是整张网络最省钱的设计。它把输入特征图在通道维度上分成 two parts一部分经过若干个 Bottleneck 堆叠另一部分直接走一个 1x1 卷积保持通道数。最后将两条支路拼接起来再经过一个 1x1 卷积调整通道数。这里有个极其容易理解错的细节CSP 结构省内存不是因为分叉这个动作本身而是因为网络最深处的特征只需要在一条支路上计算。另一条跳接支路不经过 Bottleneck所以深层特征的通道数不会在每一层都被完整复制一遍。这直接降低了显存占用也减少了梯度反传时的计算量。官方数据是 CSP 结构比普通 ResNet 风格的 Backbone 在同等精度下能缩减约 20%~30% 的浮点运算量。实际测试中同样的 2080Ti 显卡用 YOLOv5s 训练自己数据集显存占用能控制在 8GB 以内而换用同等规模的 ResNet 系列做检测头至少要多占 2~3GB。这个差距在服务器上不明显但换到 Jetson Nano 或者树莓派上就是能用和不能用的区别。2.2 SPPF为什么能把 SPP 的池化层全部串起来YOLOv5 在主干网络的最后接的是 SPPF 模块和 YOLOv4 时代的 SPP 不同它把三个 MaxPool 层全部串联起来而不是并联。这里可能有人会有疑问串联和并联的输出不是一样吗如果你仔细算一下一个 5x5 的 MaxPool 之后再做 5x5 MaxPool等效感受野就是 9x9再做一次就是 13x13。所以串联结构可以得到 5x5、9x9、13x13 三种不同尺度的特征和并联结构表达能力一样但计算量少了很多。这个模块的作用是通过多尺度池化把主干输出的高维特征映射到多个感受野尺度上从而增强网络对多尺寸目标的适应性。在后来的 YOLOv8 中这个模块被保留了下来也说明它的设计确实经得住检验。实际工程中我一般不建议随手改 SPPF 的池化核大小因为太小会让深层特征失去全局信息太大会显著增加计算量默认 5 在绝大多数场景下是最平衡的配置。2.3 Neck 的 CSP 设计何必这么重PANet 是 YOLOv5 的 Neck 主体它由两个 CSP 模块构成一个做自顶向下的特征金字塔融合另一个做自底向上的路径聚合。自顶向下的逻辑很好理解——深层特征分辨率低但语义信息强把它上采样后与浅层特征拼接就能让浅层也懂目标是什么类别。自底向上的逻辑则相反浅层分辨率高空间信息精确把它向后传播能让高层分支在定位时不至于太糊涂。这里有个工程上非常典型的坑很多人在自定义数据集时发现模型对小型目标的检测效果特别差就在 Neck 里拼命堆小目标分支比如把 160x160 的特征图也加进来。但这样做的直接后果是显存暴涨、训练速度骤降而精度提升往往只有 1~2 个点。其实更值得先检查的是数据集的标注质量和小目标样本数量而不是网络的宽度。YOLOv5 的 Neck 在设计上倾向于轻量高效它用的 CSP 结构比 Backbone 的浅、通道数更少这保证了特征融合的代价不会超过主干提取的代价。记住一个原则特征融合网络的宽度不应超过主干网络否则会出现融合处理不过来、特征被压缩的情况。2.4 Head 的预测逻辑如何从 3 个分支得到最终结果YOLOv5 的 Detection Head 在每个尺度的特征图上做三件事分类、回归框坐标、回归置信度。以 COCO 80 类为例每个锚框的输出维度是 5坐标 80类别 1置信度乘上 3 个锚框每个格子的输出维度是 258。推理阶段网络输出的是带 anchor 的原始张量需要做一次解码。坐标解码公式是bx 2 * sigmoid(tx) - 0.5 cx 表示中心点横坐标的偏移by 同理。这里用 2 * sigmoid 而不是直接 sigmoid是为了让中心点可以跑出当前格子一小段范围增强靠近网格边界的预测能力。宽高解码公式是 bw pw * (2 * sigmoid(tw))^2bh 同理。这里用平方项是为了让小目标的宽高变化更加灵敏不至于在数值上被大目标淹没。做个简单计算你就明白了当 tw0 时2*sigmoid(0)1此时 bw 正好等于预设 anchor 的宽度 pw说明网络在初始状态下预测的就是锚框本身。这保证了训练初期 loss 的数值不会瞬间爆炸。解码之后还要做 NMS非极大值抑制把同一目标上的多个候选框合并成一个。这一步是整条链路里最耗 CPU 的部分部署时通常会改用 TensorRT 的 EfficientNMS 插件来加速。3. 训练自己的数据集完整流程及超参数详解3.1 从零开始的数据准备与标注训练 YOLOv5 的第一步是准备数据集。如果你要做的是水果识别先去拍不同角度、不同光照、不同成熟度的水果照片至少每类要 300 张以上如果你要做车牌识别那么蓝牌、绿牌、黄牌单双层都要覆盖到。数据集的丰富度决定了模型上限网络设计和训练技巧只是在逼近这个上限。标注工具方面个人最推荐 LabelImg 或 X-anyLabeling。前者老牌稳定后者支持自动标注和交叉标注配合 YOLOv5 的预训练模型做人工复核可以节省一半以上的标注时间。标注结果推荐直接导出为 YOLO 格式也就是每张图片对应一个同名的 txt 文件每一行表示一个目标格式是class_id center_x center_y width height注意这里全部是归一化到 0~1 之间的相对坐标不是像素坐标。我自己早期就吃过一次亏用 LabelImg 导出了 Pascal VOC 格式没转成 YOLO 格式结果训练时反复报 no labels found。现在我会用 Ultralytics 附带的转换脚本统一处理。数据集目录结构建议如下dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/配套的 data yaml 文件内容如下train: dataset/images/train val: dataset/images/val nc: 2 names: [apple, banana]一个我在实操中总结的经验验证集的划分不要用随机抽样而是按采集场景来分。比如同一棵树上的苹果一部分进训练集一部分进验证集这样验证结果会虚高。更严格的做法是整棵树、整块地的照片只进训练集或只进验证集这样评估出来的泛化能力才真实。3.2 超参数配置lr、batch size 到底怎么调YOLOv5 的超参数配置集中在 hyp.scratch-low.yaml 文件里默认是 COCO 上炼丹出来的底座。很多教程直接告诉你用默认超参就行但实操中往往不是那么回事。先说最关键的两个参数学习率和 batch size。YOLOv5 用的是 SGD 优化器初始学习率 lr0 默认 0.01。这个值在 COCO 这种超大、超复杂的数据集上是合理的但在自定义的小数据集上0.01 会导致 loss 震荡甚至发散。我自己的经验是当训练集少于 5000 张图时把 lr0 调到 0.001~0.005 之间收敛明显更稳。很多人一上来就复现官方最佳精度却忽略了大模型在小数据上的不适应性。batch size 的选择受限于显存但很多新手的误区是可劲往上加。YOLOv5 的 loss 组成有三块box_loss、cls_loss、obj_loss。batch 太大时如果数据集里小目标多obj_loss 反而会不稳定。这里提供一个我自己常用的方案batch size 设为 16 起步显存不够就降到 8此时学习率也要等比降低即 lr 0.01 * (batch / 64)。这个线性缩放规则在 YOLOv5 的 SGD 优化器下基本好用。3.3 训练命令与过程监控训练命令可以直接从官方仓库 Copy 改参数我自己常用的命令是python train.py \ --data data/custom.yaml \ --weights yolov5s.pt \ --img 640 \ --batch 16 \ --epochs 100 \ --cache \ --device 0这里 --cache 表示把图片预加载到内存如果数据集总量不超过 10GB推荐开启训练速度能提升 30% 以上。如果显存紧张可以在 --cache 后面改成 --cache disk只把图片缓存到磁盘也能减少 I/O 阻塞。训练过程中我会重点盯三个曲线train/box_loss 和 val/box_loss两者都下降则正常若出现 val loss 回升而 train loss 继续下降说明过拟合了。metrics/mAP_0.5 和 mAP_0.5:0.95前者是粗粒度指标IOU 大于 0.5 就算对后者是细粒度指标要 0.5 到 0.95 的平均更考验定位精度。出现 WARNINGOverfitting 或者 early stopping 建议就得考虑加数据增强、加 dropout 或提前停止。训练结束后weights/best.pt 就是最推荐的模型文件它保存的是在验证集上 mAP 最高的权重而不是最后一个 epoch 的权重。这一点说过无数次但总有人踩直接用 last.pt 做部署结果精度不如预期一查才知道 best.pt 早就不更新了。4. 部署落地从 PyTorch 到 TensorRT 的完整转换链路4.1 导出为 ONNX 与 TensorRT 引擎YOLOv5 训练完的模型是 PyTorch 格式的 .pt 文件但真实项目部署几乎不会直接用 PyTorch 跑推理。最主流的部署路线是 PyTorch → ONNX → TensorRTNVIDIA 平台或 OpenVINOIntel 平台。导出 ONNX 的命令很简单python export.py \ --weights best.pt \ --include onnx \ --opset 12 \ --dynamic这里 --dynamic 表示允许动态输入尺寸但如果考虑部署稳定性我建议直接固定输入尺寸为 640x640性能更优且不容易出奇怪的尺寸不匹配问题。值得一提的是在导出时 YOLOv5 会自动把 NMS 模块剥离ONNX 模型只负责前向推理NMS 留给部署框架实现。TensorRT 的转换推荐直接用 trtexec 工具命令如下trtexec --onnxbest.onnx \ --saveEnginebest.trt \ --fp16 \ --minShapesimages:1x3x640x640 \ --optShapesimages:1x3x640x640 \ --maxShapesimages:1x3x640x6404.2 Jetson Nano 上的部署实测算力不够优化来凑Jetson Nano 只有 128 个 CUDA 核心算力约 0.5 TFLOPS FP16和桌面显卡完全不在一个量级。在这上面跑 YOLOv5s 原版 FP32帧率大概只有 3~5 FPS基本不可用。但做两步优化之后可以稳定跑到 15~20 FPS。第一步是转换成 TensorRT FP16 引擎这一步大概能带来 2 倍提速。第二步是缩小输入尺寸从 640x640 降到 416x416虽然 mAP 会掉 1~2 个点但推理速度能再翻一翻。如果你做的是车牌识别车牌本身在画面里占比较大缩到 416 影响不大。还有一招是装 JetPack 4.6 后使用 TensorRT 8.2 的 EfficientNMS 插件替换普通 NMS。这个插件把 NMS 直接编译进推理引擎避免 CPU 和 GPU 之间频繁拷贝数据。实测这一项就能再省 2~4ms。最终单帧延迟可以控制在 50ms 以内对于车牌识别、简单的物料分拣等应用场景这个性能完全够用。4.3 边端部署的内存与显存优化细节在 Jetson 这类嵌入式设备上显存优化比速度优化更需要优先考虑。TensorRT 默认会用固定显存池如果和图形界面共用显存可能会出现 Cuda Error: out of memory。解决方法是启动时加环境变量export CUDA_MODULE_LOADINGLAZY sudo nvpmodel -m 0另外YOLOv5 的推理代码里有个容易忽略的 trick把 cv2 读取的图像直接转成 RGB 再归一化这一步如果用 numpy 实现会占 CPU 和内存。更推荐用 CUDA 上的 tensor 操作一次性完成写法是img torch.from_numpy(img).permute(2, 0, 1).float() img img / 255.0 img img.unsqueeze(0).to(device)这样省去了多次 numpy 拷贝在小内存设备上非常见效。实测在 Jetson Nano 2GB 版本上这么改之后内存占用能降低 15% 左右。5. 实战场景扩展水果识别与车牌识别的落地差异5.1 基于 YOLOv5 的水果识别数据增强优先于网络调参水果识别这类任务核心难点不在网络结构而在数据多样性。YOLOv5 官方给的预训练权重是在 COCO 上训练的其中已经包含了水果类别迁移到自己的水果数据集时即便只有几百张图也能很快收敛到不错的效果。这背后是迁移学习的思维网络低层已经学会了普遍适用的边缘、纹理、颜色特征只需要微调高层语义映射。在水果识别里最有用的数据增强是 HSV 随机扰动即随机调整色调、饱和度、明度。因为水果颜色在不同光照下差异极大模型要学的是颜色不变性而不是死记硬背某种固定 RGB 值。实操中我会把 hsv_h 设为 0.02hsv_s 设为 0.7hsv_v 设为 0.5效果立竿见影。另一个关键点是叶片遮挡。果树上的水果往往被叶子挡掉一截这会导致标注框里混入大量背景。针对这个可以给标签加一点不完全可见类或者用随机擦除增强模拟遮挡YOLOv5 的 hyp 文件里没有直接对应项需要自己在 dataloader 里改。5.2 基于 YOLOv5 的车牌识别检测与识别如何无缝配合车牌识别项目一般分两段先用 YOLOv5 把车牌区域从整图中框出来再用 OCR 模型如 LPRNet、PaddleOCR做字符识别。这里检测精度的高低直接决定 OCR 的输入质量所以比水果识别更依赖检测模型的稳定性。车牌检测的一个独特难点是车牌尺寸在画面中差异极大。近处大车牌的像素宽度可能超过 400远处小车牌可能只有 30 像素。应对方法有几个一是用 YOLOv5m 或 YOLOv5l 而不是 s因为大模型在极小目标上表现更好二是保证训练集中包含多个距离尺度的样本三是训练时开启多尺度训练YOLOv5 默认会在每个 epoch 随机缩放输入尺寸这一步能显著增强尺度适应性。在部署上车牌识别通常需要同时跑检测和 OCR 两个模型Jetson Nano 上二合一性能会很紧张。我的做法是用 TensorRT 把检测模型和 OCR 模型都转成 FP16 引擎然后做两阶段流水线处理检测模型刚一帧输出OCR 模型立刻吃进上一帧的车牌区域通过双线程隐藏延迟最终能做到整体端到端 15 FPS 以上能满足停车场出入口这类低速场景的需求。6. 常见问题与排查技巧实录6.1 训练时提示 No labels found 的排查这是新手最常遇到、也最容易劝退的报错。通常原因是标签文件目录和图片目录不匹配。先用这个命令验证标签和图片是否一一对应python -c import os imgs os.listdir(dataset/images/train) labels os.listdir(dataset/labels/train) print(len(imgs), len(labels)) 如果两个数量差异巨大多半是标注导出格式选错了或者转换脚本没有把 Pascal VOC 的坐标归一化。还有一种情况是数据集里混入了没有标注信息的图片YOLOv5 会直接忽略这些图片并打印提示而不是中断训练。请务必检查 data yaml 的路径YOLOv5 要求路径是相对 data yaml 所在目录的不能写绝对路径前加 / 否则会在根目录找这一点官方文档没有强调。6.2 训练曲线正常但 mAP 很低的常见原因训练过程看起来一切正常loss 在下降但 mAP 就是上不去这类问题通常是数据标注不一致引起的。比如不同标注员对水果边界框的画法差异较大有人框住了整个果实有人只框住可见部分这会导致模型学到平均框定位既不准确也不稳定。另一类是类别不平衡问题。车牌识别场景里蓝牌样本可能有 10 万张新能源绿牌只有 2000 张模型会严重偏向多数类。常规解法是给少数类加复制增强或者用 YOLOv5 的 class weights 参数。后者可以在 data yaml 里这样配# class weights, 少样本类权重大 class_weights: [1.0, 5.0]此外验证集的评估指标如果只看 mAP_0.5很容易忽略定位精度的不足。实际部署中 IoU 0.5 的框可能偏大导致后续 OCR 拿到的车牌区域含过多背景。一定要同时关注 mAP_0.5:0.95它才是定位精度的真正体现。6.3 漏检小目标的系统化排查思路YOLOv5 默认针对 COCO 数据集设计其中小目标占比不高所以默认配置在极端小目标场景下表现一般。排查思路按照数据—模型—后处理三层递进数据层统计训练集中目标面积占比中位数如果低于 2%说明小目标严重不足。此时优先做切片增强即把大图切块后放大训练这是见效最快的方法。模型层检查是否用了 P2 输出层。YOLOv5 支持 --p2 参数能额外输出 160x160 的特征图专门检测小目标代价是显存和延迟各增加 30% 左右。后处理层如果目标本身非常接近NMS 的 IoU 阈值也调。默认的 IoU 阈值是 0.45对于靠近的小目标可以降到 0.3避免两个靠近的框被 NMS 误删成一个。6.4 显存不足怎么办梯度累积与显存节约技巧显存不足是最常见的训练报错尤其是在 6GB 显存的卡上训练自定义数据集。第一反应是调小 batch size很多人会直接降到 2 或者 1但这会让 BatchNorm 的统计量不稳定。更优雅的解法是梯度累积batch size 设为 8但每训练 2 个 batch 做一次梯度更新等效于 batch 16 的效果。python train.py \ --batch 8 \ --accumulate 2另外YOLOv5 的 --image-weights 参数可以根据训练中图片的 loss 动态给难例加权采样。这个功能对显存占用几乎没影响但对小目标、复杂背景的样本提升明显推荐在训练中后期开启。如果显存实在紧张到 batch size 1 都跑不动就得考虑降低输入分辨率。从 640 降到 512 通常 mAP 只掉 1~3 个点但显存占用下降大约 35%。在数据集允许的前提下这是一个性价比非常高的取舍。7. 个人实操经验之谈最后分享一个我多次踩坑后沉淀下来的经验永远不要直接照搬官方仓库的默认配置到自己的项目里但也不要一上来就魔改网络结构。YOLOv5 最强的设计恰恰是它的中庸——在精度、速度、显存占用、部署难度之间取得了极佳的平衡。多数实际项目先用 YOLOv5s 从零到一打通全流程再用 YOLOv5m 或 l 微调对比远比一开始就研究如何在主干里加注意力机制更有价值。我遇到过不少朋友问为什么我的 YOLOv5 精度总是达不到博客里的效果答案往往不在网络层而在数据质量、超参数适配和验证集划分上。网络结构是显式的知识数据治理是隐式的功夫后者才是拉开差距的地方。如果你正卡在某个训练异常或部署报错上不妨拿本文的排查清单对照一下很可能就省下一整天的调试时间。