简介YOLOv5、YOLOv6与YOLOv7是目标检测领域热度颇高的三类模型如何权衡速度与精度常让开发者在实际选型时陷入纠结。这份DOCX文档正是针对这一痛点围绕平均精度mAP与每秒帧数FPS两大指标对比了三者在i7-6850K CPU、NVIDIA RTX 4090、Tesla V100/P100、GTX 1080 Ti等平台上的实测性能并剖析了Tiny、Nano、中型及大型模型在不同硬件下的适用边界配有图表与排序可视化适合算法工程师、深度学习研究者及入门学习者参考。资源包共1个文件类型为docx大小仅408KB结构紧凑下载后即可直接阅读。已有4927人学习/下载。文档针对“哪个模型在CPU/GPU上最快”“为何Tiny/Nano在部分GPU上FPS下降”“哪些模型适合小物体检测”“需要多少GPU显存”等高频问题给出了数据化解答可帮助读者结合应用场景和资源预算快速锁定最合适的YOLO版本。1. 为什么YOLOv5、YOLOv6、YOLOv7的性能比较值得反复做在目标检测模型选型时YOLOv5、YOLOv6、YOLOv7 三个版本经常被放进同一张表里比速度和准确度但真正落地时你会发现公开的 FPS 数据换了硬件、换了 batch size、换了推理后端之后几乎不可比。一个反直觉的事实是YOLOv7 未必比 YOLOv5 快YOLOv6 也未必在精度上落后很多。这三个版本虽然同属 YOLO但内部结构已经从 anchor-based 走到 anchor-free从传统卷积走到重参数化、从单向特征聚合走到扩展高效聚合性能曲线因此完全不同。这篇文章会从网络设计的取舍讲起接着给出一套可复现的速度与准确度测试流程最后落到如何用脚本自动验收三个模型让选型结论建立在数据而不是榜单截图上。2. 从网络结构上拆解三者的速度与准确度倾向2.1 YOLOv5的CSPNet与多尺度配置是精度的地基YOLOv5 延续了 CSPDarknet 思路用跨阶段局部网络把梯度和特征图拆分再合并减少重复计算同时保持特征复用。以 YOLOv5s 为例它的结构由 Focus/Slice 下采样、多个 C3 模块构成neck 侧用 PANet 做自上而下的路径聚合head 仍是三分支 anchor-based 预测。实际开源仓库里的 yolov5s.yaml 是最能看出这种版本特点的地方# yolov5s.yaml节选 depth_multiple: 0.33 width_multiple: 0.50 anchors: - [10,13,16,30,33,23] - [30,61,62,45,59,119] - [116,90,156,198,373,326]depth_multiple和width_multiple分别控制 backbone 内部 C3 重复次数和通道数这组系数把同一个模型定义扩展成 n/s/m/l/x 五个规格。这也是很多人对比 YOLOv5 时最容易踩的坑拿 YOLOv5x 去对比 YOLOv6-N完全不公平。anchor 是在训练前用 k-means 在数据集聚类出来的COCO 和自定义数据集的最优 anchor 不同所以实际训练时通常需要重开--autoanchor。YOLOv5 的训练技巧同样影响基准结果mosaic 数据增强、多尺度训练、EMA 权重平均、CIoU 损失都会让 mAP 更稳。推理阶段没有 skill 分支也没有额外辅助 head因此结构相对整洁这也让它在 TensorRT 等后端上的支持程度最好。它的速度瓶颈主要来自 anchor 解码和 PANet 的 concat 数量但工程生态完善很多部署框架都把它作为默认支持的 YOLO。2.2 YOLOv6的重参数化和anchor-free是延迟优先的杀招YOLOv6 的核心思路是“训练时用复杂结构推理时用精简结构”。backbone 和 neck 中大量使用 RepVGG 风格的重参数化卷积训练时一个 3x3 分支可以等价拆成多分支推理前通过fuse操作把 BN 和 1x1 分支合并成单个卷积层从结构上压缩计算路径。head 部分 YOLOv6 把 YOLOv5 的 anchor-based 改成 anchor-free 的 decoupled head分类和回归预测分离训练时使用 TALTaskAlign Learning分配正样本损失函数用 GIoU 或 SIoU 变体。TAL 会根据分类分数和 IOU 的综合情况动态选择正样本比 v5 的静态匹配更灵活对不均匀小目标更友好。从性能倾向来看YOLOv6 从设计之初就考虑了工业部署官方提供了不同规模的 n/s/m/l 型号也做了量化感知训练支持。它不强行追求最高精度而是把“同样精度下延迟更低”作为目标。在实测中常见表现是YOLOv6-N 的参数和 FLOPs 小于 YOLOv5s但 mAP 差距在 1 到 2 个点以内推理延迟却能低 20% 左右。代价是重参数化结构对训练初期的学习率比较敏感训练时需要额外关注 warmup 策略否则收敛不稳定。2.3 YOLOv7的E-ELAN和辅助训练头把精度推到高点YOLOv7 是这几个版本里结构最“堆料”的。它提出的 E-ELAN 扩展高效聚合网络对通道做 expand、shuffle、merge 多次处理让网络能学习到更多组合特征而不单单是加深加宽。这种结构让 YOLOv7 在 COCO 上的 mAP 可以达到很高水平但同时也让特征图 concat 次数明显增加算子是碎片化的。训练阶段YOLOv7 引入了辅助训练头aux head和深度监督。主 head 和辅助 head 共同参与损失计算让网络浅层也能拿到梯度推理阶段删除辅助头只保留主 head。这和 YOLOv5 的一体化 head 不同训练师需要调整辅助 head 的损失权重否则可能出现过拟合。损失函数采用变体后训练后期通常能观察到 mAP50-95 的明显抬升。YOLOv7 在速度上不占绝对优势因为 E-ELAN 的复杂连接会带来更高的内存访问开销但它在给定计算量下能把 mAP 推到更上限。也就是说如果你的目标是“在这个 GPU 上尽量跑到最高的 mAP”YOLOv7 通常能赢但如果目标是“在边缘设备上保证实时的前提下达到基本可用精度”YOLOv7 可能不是最优解。2.4 三个版本的结构设计与推理策略对比表对比维度YOLOv5YOLOv6YOLOv7骨干网络CSPDarknetEfficientRep / RepBlockE-ELAN特征融合PANetPANet RepBlockE-ELAN PANet预测方式anchor-basedanchor-freeanchor-based正样本分配静态匹配TAL 动态匹配主/辅助头动态匹配推理阶段特殊层无可融合 RepConv删除辅助头精度上限中高中最高延迟优化程度中等最激进中等部署生态最成熟对量化/重参数化友好需要配套脚本这个表说明三者根本不在同一条技术路线上。比较速度不能只看 FPS 数字还要看是否经过结构融合、是否用同一个 batch size、是否开启 TensorRT 的 FP16 或 INT8。下一章就是如何把这些变量固定下来做一次能说服自己的复测。3. 标准化基准测试方法从val.py到ONNX延迟3.1 固定公平前提硬件、软件栈、输入尺寸我一般会在同一台 GPU 服务器上做横向对比至少固定以下变量GPU 型号、CPU 型号、CUDA 和 cuDNN 版本、PyTorch 版本、ONNX Runtime 或 TensorRT 版本、输入尺寸 640x640、batch size。为什么强调 CPU因为数据预处理 pipeline 里的 letterbox 和归一化也会计进端到端延迟如果不统一测出来的差距会包含无关因素。推荐使用 Linux 环境因为 TensorRT 和多进程数据处理在 Linux 下更稳。PyTorch 用 2.x配合 CUDA 11.x 以上推理后端优先使用 ONNX Runtime 的 CUDAEP 或 TensorRT EP避免直接对 PyTorch 模型计时。PyTorch 的 eager mode 每次前向都带调度开销和自动求导图的构建成本和真实部署环境差异太大。3.2 用官方val.py复现COCO mAP准确度测试必须使用各自官方代码仓库内的评估脚本因为它们后处理逻辑不同。YOLOv5 的评估命令python val.py \ --data coco.yaml \ --weights yolov5s.pt \ --batch-size 32 \ --img 640 \ --conf-thres 0.001 \ --iou-thres 0.65 \ --task val这里--conf-thres必须设置为 0.001 而不是默认的 0.25因为 COCO 官方评估会在 0.001 到 0.1 之间扫描置信度阈值得到更合理的 PR 曲线。--iou-thres是 NMS 时的 IoU 阈值0.65 是 YOLOv5 评估 mAP 时常用的配置。--task val表示只跑验证集。YOLOv6 和 YOLOv7 的脚本文件名不同YOLOv6 是tools/eval.pyYOLOv7 是test.py参数名也略有差异但核心字段一致# YOLOv7 评估 python test.py \ --data data/coco.yaml \ --img 640 \ --batch 32 \ --conf 0.001 \ --iou 0.65 \ --weights yolov7.pt跑完之后记录mAP50-95和mAP50不要只记mAP50因为两个小目标数据集上的mAP50区分度不够。mAP50-95对边框定位精度更敏感更接近真实业务体验。3.3 用ONNX Runtime统一测延迟我推荐的延迟测量方式不是直接把.pt模型 forward而是把三个模型全部导出为 ONNX关闭动态 batch固定 1x3x640x640 输入然后用下面这套脚本计时import onnxruntime as ort import numpy as np import time onnx_path yolov7.onnx input_shape (1, 3, 640, 640) sess ort.InferenceSession( onnx_path, providers[CUDAExecutionProvider, CPUExecutionProvider], ) input_name sess.get_inputs()[0].name x np.random.rand(*input_shape).astype(np.float32) # 预热 CUDA context / cuDNN autotune for _ in range(10): sess.run(None, {input_name: x}) # 连续测量并截尾求均值 times_ms [] for _ in range(100): t0 time.perf_counter() sess.run(None, {input_name: x}) times_ms.append((time.perf_counter() - t0) * 1000) times_ms.sort() stable times_ms[5:-5] avg_ms sum(stable) / len(stable) p50 stable[len(stable) // 2] print(favg{avg_ms:.2f}ms p50{p50:.2f}ms)这段脚本只测了模型前向的耗时不包括预处理/NMS/后处理所以是“纯模型延迟”。如果要测完整流程需要在计时区域内加入图片读取、letterbox、归一化和 NMS。我先用这个脚本的原因是把模型结构差异放到最大排除不同仓库后处理代码的干扰。ONNX Runtime 的CUDAExecutionProvider能比较好地兼容三个模型的导出图实测中趋势稳定而且跑一次只要几分钟。导出 ONNX 的命令各仓库都有YOLOv5 是python export.py --weights yolov5s.pt --include onnx --opset 12 --halfYOLOv6 使用python deploy/ONNX/export_onnx.pyYOLOv7 使用python export.py --grid --end2end。导出后建议用 Netron 打开看一眼确认 batch 维度是固定1这样可以避免动态 shape 带来的额外耗时。3.4 记录哪些指标才有说服力整理一套完整的对比指标表至少包含下面几列记录项具体说明模型配置如 YOLOv5s / YOLOv6-N / YOLOv7-tiny参数量可通过torchinfo或模型 summary 得到输入尺寸通常 640也可以记录 416 / 960 的曲线mAP50-95REPEAT 三次去除随机波动GPU 纯前向延迟同一 ONNX Runtime 脚本测出端到端延迟包含 letterbox NMS吞吐量batch32 时每秒可处理图片数表格里的每一项都比单纯一个“FPS”可信。尤其是 batch1 的延迟和 batch32 的吞吐可能给出相反的排序因为某些模型对 batch 更友好某些模型单张延迟低但批量吞吐上不去。记录时尽量保留原始日志不要只写修好的均值。4. 真实趋势解读与三个调优方向4.1 官方结果汇总mAP与速度的相对关系在三套模型均在 COCO val2017、输入 640、TensorRT 或 ONNX Runtime FP16 条件下通常能观察到的相对趋势是YOLOv7 的 mAP50-95 最高YOLOv5 中等YOLOv6 在最小规格里速度领先但 mAP 略低。以接近的“小模型档”为例YOLOv5s 的 mAP 量级在 37% 左右YOLOv6-N 约 36%YOLOv7-tiny 约 35%但同一批 ONNX 延迟数据里 YOLOv6-N 通常明显更短。这个结果的底层逻辑是YOLOv7 把更多算力花在特征聚合和训练深监督上得到的是精度收益YOLOv6 把结构折叠成单路卷积得到的是端侧推理收益YOLOv5 则处在中间结构简单但 anchor 解码和 PANet 仍有优化空间。如果看大模型档差距会更大YOLOv7 可以跑到 51% 以上的 mAPYOLOv5x 约 50.7%YOLOv6-L 则更偏向速度。所以我一般不会直接告诉你“谁更强”而是建议先定一个目标 mAP。例如你的业务需要 mAP50-95 在 40% 以上那就把 YOLOv5m、YOLOv6-M、YOLOv7 拉出来对比如果只需要实时检测不追求 mAP则 YOLOv6-N 可能是最稳的起点。4.2 为什么不能只看最高精度版本很多对比帖直接用 YOLOv7 和 YOLOv5x 比然后说 YOLOv7 更强这在选型里没有意义。最高精度版本意味着最大参数和最大延迟而实际项目往往限制在某个时延预算内。正确做法是以同样的 mAP 为横轴找一个 YOLOv5 的某个规格再去对照 YOLOv6 或 YOLOv7 的同等 mAP 规格比较延迟差距。我常用“mAP/Latency”曲线来表示例如 YOLOv5m 达到 45% mAP 时延迟为 8msYOLOv6-L 达到接近精度时延迟可能只有 6msYOLOv7 可能用更小的模型就达到 46% mAP但延迟是 7ms。这种交叉规律才值得记录。你不需要在文章里精确写出几十个数据点但至少要画出趋势否则得出的结论换个硬件就失效。4.3 调优方向输入尺寸、量化、batch size复测中如果发现速度不理想优先调输入尺寸。很多模型在 416 下 mAP 下降不超过 2 个点但延迟能下降 30% 以上。YOLOv7 对输入分辨率更敏感因为 E-ELAN 的 concat 在低分辨率时收益减少YOLOv6 在 416 下表现相对稳定适合直接部署。量化也是性能比较中的重要变量YOLOv6 的 RepVGG 融合后对 INT8 量化更友好YOLOv7 在量化后精度掉点往往稍大。如果目标设备是 GPU建议先用 FP16 比较如果目标是移动端或 FPGA则必须加入 INT8 calibration 后的数据不能拿 FP16 结论直接套。batch size 的影响常被忽略。YOLOv5 在 batch16 时能利用更大矩阵乘提高 GPU 利用率但边缘设备只跑 batch1因此对比时必须区分“延迟优先”和“吞吐优先”两种场景。我给出的 ONNX 计时脚本先测 batch1再跑一个 batch32 的压力实验这样选型时不会因为某一项优势而误判。5. 用统一脚本验收YOLOv5/v6/v7选型不再靠传闻最后一章给一个可落地的验收技巧写一个独立脚本循环三个已经导出的 ONNX 模型统一输入、统一计时、统一解析输出。脚本不依赖各仓库的 Python 环境只依赖 onnxruntime、numpy 和 pycocotools。import onnxruntime as ort import numpy as np import time models { yolov5s: yolov5s.onnx, yolov6n: yolov6n.onnx, yolov7tiny: yolov7-tiny.onnx, } # 固定测试条件 N_WARMUP 10 N_REPEAT 100 INPUT_SIZE 640 BATCH 1 for name, path in models.items(): sess ort.InferenceSession( path, providers[CUDAExecutionProvider, CPUExecutionProvider], ) input_name sess.get_inputs()[0].name x np.zeros((BATCH, 3, INPUT_SIZE, INPUT_SIZE), dtypenp.float32) for _ in range(N_WARMUP): sess.run(None, {input_name: x}) latencies [] for _ in range(N_REPEAT): start time.perf_counter() sess.run(None, {input_name: x}) latencies.append((time.perf_counter() - start) * 1000) latencies.sort() stable latencies[N_WARMUP // 2:N_REPEAT - N_WARMUP // 2] avg sum(stable) / len(stable) p50 stable[len(stable) // 2] p95 stable[int(len(stable) * 0.95)] print(f{name}: avg{avg:.2f}ms p50{p50:.2f}ms p95{p95:.2f}ms)调用时先让三个模型都导出成同一个 opset 的 ONNX用onnxruntime-GPU跑。脚本里的N_WARMUP保证 GPU 完成 autotune截尾均值去掉头尾偶然抖动。这一步做完之后把 mAP 的 val.py 日志也塞到同一个循环里用文件路径映射模型名就能生成一份格式统一的验证表。这套脚本的价值不只是跑数字而在于把三个模型放进同一套工程约束里迫使你面对预处理输入尺寸、输出张量形状、NMS 后处理这些细节。实际选型时你还会发现 YOLOv7 的 ONNX 若不开--end2end后处理会多种不同分支端到端耗时反而更高。这些差异不通过统一脚本对比很难在公告栏的性能表里看出来。本文还有配套的精品资源点击获取