简介：面向目标检测与计算机视觉开发者的YOLOv5行人检测训练资源包，聚焦街道、公路等交通场景下的行人识别任务，类别仅针对person，便于快速验证和落地。内含基于上万样本训练得到的检测权重，平均准确率可达90%以上，并附带训练曲线图，可直观评估收敛过程与检测效果；同时收录约3000张多行人图片，标签格式覆盖VOC与YOLO两种，兼顾模型训练与数据扩充需求。压缩包共2000个文件，主体包括jpg图像、txt标签文件、Python工程脚本、pt权重文件及yaml配置等，整体约378.52MB，结构清晰，适合直接调用、再训练或二次开发。已有6309人学习下载，适合需要快速获取行人检测基线模型、对比不同训练策略或补充数据集的深度学习者与工程开发者。
1. 这份 YOLOv5 行人检测权重为什么值得直接下
做街道和公路场景的行人检测，最耗时间的从来不是跑通模型，而是攒数据、标数据、调超参数这三件事，能把一个完整的周末全吃进去。这份资源把「一万多张真实场景训练出来的 YOLOv5 行人检测权重、90% 以上准确率、3000 张多行人数据、VOC 和 YOLO 双标签」打包在一起，拿到手就能直接跑 detect.py 推理，也可以当成预训练权重去微调你自己的监控画面。适合刚入门 YOLOv5、急需一份靠谱 baseline 做 demo 的人，也适合智慧交通、安防项目里想快速验证算法效果的从业者。省下的标数据时间，已经值回下载成本了。
2. 先拆资源：权重、训练曲线、单类模型的三重边界
2.1 压缩包结构：哪些文件直接决定你能跑通
拿到压缩包先别急着解压跑 detect.py，花五分钟看目录结构能省下后面一晚上的排查时间。这份资源保留了 YOLOv5 v6.0 官方仓库的骨架，README、CONTRIBUTING、GitHub issue 模板这些文档都在，同时把训练入口 train.py 和 utils 下的 datasets.py、general.py 这类辅助脚本也一并带上了。这意味着你不需要再去单独拉一个 YOLOv5 仓库，解压后直接在这个目录下执行命令就能跑通大部分流程。
按实际使用场景，压缩包里的内容可以分成四类：
| 内容大类 | 对应形式 | 用途 |
|---|---|---|
| 行人检测权重 | .pt 格式权重文件 | detect.py 推理、train.py 微调的基础 |
| 训练曲线图 | png 或 runs 目录下图表 | 判断训练过程和权重质量 |
| 三千张多行人数据 | images + labels，VOC 与 YOLO 双格式 | 微调训练、验证、格式转换练习 |
| 脚本与文档 | train.py、datasets.py、general.py、README 等 | 复现训练、辅助数据处理 |
其中最关键的是权重文件和数据集。权重文件是这份资源的核心资产，README 里写明是「一万多数据训练得到、准确率达 90% 以上」；数据集则给了你 3000 张图片和两套标签，你不需要再满网络找公开数据集，也不用自己写标注工具。datasets.py 和 general.py 这两个脚本看着不起眼，实际作用很大：datasets.py 负责训练时的数据加载和增强逻辑，general.py 收集了检查环境、格式转换、指标计算这些通用函数，很多你在推理或训练时报的错，最后定位到源码时都会落到这两个文件里。
2.2 classes: person 的单类模型为什么适合街道与公路场景
资源里明确写了classes: person，这是最重要的一个设计信息。很多人拿到权重的第一反应是「怎么只有一类」，但在真实项目里，把行人和车辆分开建模才是常见做法。街道、公路场景的行人检测本身就是一个独立任务，安防、交通、车路协同这些下游应用要的就是行人这一个类别，多类别模型反而会带来多余的处理和误报空间。
单类模型相比 COCO 80 类模型，在实际部署中有三个明显优势。第一是后处理更简单，NMS 阶段只需要对 person 这一类做去重，没有跨类别框重叠的争议；第二是误检率更容易压下去，模型无需在几十个类别之间做区分，把注意力集中在行人形态上；第三是数据效率更高，同样一万多张图，单类模型学到的是行人的全部特征分布，而多类别模型要把数据摊到 80 个类上。从训练曲线和验证结果看，90% 以上准确率放在单类任务里是一个相对可靠的水平，因为类别少，AP 指标的波动也小。
有人会担心单类模型在复杂场景下泛化不够，这种担心有一定道理，但要看场景边界。这套权重针对的是街道、公路场景，行人在这类画面里的形态相对固定，直立行走或骑行，遮挡相对可控。如果你要做的场景是商场密集人群、体育场观众席这种高遮挡高密度的极端画面，单类模型的上限确实会受限，这时候应该用这份权重做预训练，再补充目标场景数据微调，而不是直接裸用。
2.3 训练曲线图怎么读：判断这份权重「能不能打」
压缩包里附带的训练曲线图，是用来评估权重质量的直接证据，不要只盯着 README 里的准确率数字。YOLOv5 训练结束后会在 runs/train/exp 目录下生成 results.png，里面一般包含 box_loss、obj_loss、cls_loss、precision、recall、mAP@0.5、mAP@0.5:0.95 这几条曲线。判断这批曲线是否健康，我一般看三处：
| 检查点 | 健康的表现 | 异常的表现 |
|---|---|---|
| loss 曲线 | box_loss 和 obj_loss 单调下降后趋平，val 曲线不反弹 | val loss 尾部明显上扬，说明过拟合 |
| P/R 曲线 | precision 和 recall 同步稳定在高位 | 两者差距过大，说明阈值敏感 |
| mAP 曲线 | mAP@0.5 平滑爬到高位并稳定 | 曲线剧烈震荡，说明训练不稳定 |
对照这套标准去看压缩包里的曲线，如果 mAP@0.5 在高位趋平、val 的 box_loss 没有明显回升，那这份权重的「准确率 90% 以上」就有据可依。这里要提醒一句：YOLOv5 在验证时直接调用 val.py，输出的 mAP 和你自己在测试集上跑出来的数字会有出入，因为置信度阈值、IoU 阈值、图片分辨率的设置不同。我拿到任何权重都会先自己跑一遍 val.py，把指标复现出来，再决定要不要用它做 baseline。
3. 一小时跑通推理：环境配置与 detect.py 参数详解
3.1 环境准备：torch 版本、依赖与 CUDA 组合
这套资源沿用的是 YOLOv5 v6.0 的训练和推理代码，环境要求并不苛刻。先说 Python 版本，3.8 到 3.10 之间都行，太高的 3.12 某些依赖编译会有兼容问题，不建议折腾。解压后先看有没有 requirements.txt，有的话直接装上基础依赖，没有的话手动补全核心的 torch、torchvision、opencv-python、numpy、matplotlib。
关于 torch 与 torchvision 的组合，我一般会这么装：
# CPU 版本：先跑通流程，不追求速度 pip install torch==1.10.0 torchvision==0.11.0 --index-url https://download.pytorch.org/whl/cpu # GPU 版本：有 NVIDIA 显卡时使用，cu113 对应 CUDA 11.3 pip install torch==1.10.0+cu113 torchvision==0.11.0+cu113 -f https://download.pytorch.org/whl/torch_stable.html逻辑说明：YOLOv5 v6.0 时期官方推荐的组合就是 torch 1.10 这一档，后面更高的 torch 版本也能跑，但部分脚本涉及 checkpoint 的键名解析，跨大版本加载权重偶尔会报兼容警告，没必要徒增风险。参数说明里要注意，--index-url指定的是 CPU 版的下载源，-f指定的是带 CUDA 后缀的稳定版本列表；如果你机器上已经装了更高版本的 torch，也可以先直接跑，报错再回退版本。
装完依赖后跑一句python -c "import torch; print(torch.__version__)"确认安装成功。这一步是整条链路里最容易翻车的环节，很多人在推理时报AttributeError或ImportError，最后定位下来都是 torch 和 torchvision 版本不匹配，两个包的版本号必须严格对应。
3.2 detect.py 首次推理：从图片到视频的输出链路
环境就绪后，直接用自带的 detect.py 跑一次推理，这是验证权重能不能用的最快路径。完整命令如下：
python detect.py \ --weights person_detect.pt \ --source test.jpg \ --img 640 \ --conf-thres 0.4 \ --iou-thres 0.45 \ --save-txt \ --save-conf \ --project runs/detect \ --name person_test逻辑说明：--weights指定权重文件路径，--source可以换成单张图片、视频文件、目录或者摄像头编号；--img 640表示推理时缩放到的输入尺寸，这个值要和权重训练时的分辨率一致，否则精度会受影响。--conf-thres是置信度过滤阈值，低于这个分数的框会被丢掉；--iou-thres是 NMS 用的 IoU 阈值，用于消除重叠框。--save-txt会把检测结果保存成 YOLO 格式的 txt 标签文件，--save-conf会在标签文件里额外追加一个置信度列，方便后续做批量数据分析。
执行完后，结果会输出到runs/detect/person_test/exp目录里。每张输入图片会生成一张标注后的图像，如果是视频则生成标注后的视频文件，同时--save-txt开启后会生成对应的labels子目录，里面是每张图的目标坐标。第一次跑建议先用单张图片验证，确认环境没问题了再切视频，视频推理的速度取决于 GPU 性能和输入分辨率。
这里有一个容易忽略的点：--source如果传的是目录，detect.py 会扫描目录下所有图片按顺序推理，这个特性在批量验证时很好用。我一般会把验证集图片单独放一个文件夹，一次性跑完再统计结果，比一张张跑省事得多。
3.3 置信度与 NMS 阈值：后处理阶段怎么调才不翻车
--conf-thres和--iou-thres这两个参数，本质上控制的是 YOLOv5 后处理阶段的行为，很多人在推理时只改 confidence 不改 NMS，或者反过来，效果都不理想。confidence 阈值的作用是过滤低质量预测框，而 iou 阈值的作用是在重叠框中保留最优、去除冗余，两者是串行工作的。一份权重在后处理阶段怎么调，直接决定了你实际体验到的精度是高于还是低于 README 里的数字。
不同项目场景对这两个参数的取向完全不同，我通常按下面这组经验值起步：
| 应用场景 | conf-thres | iou-thres | 取舍倾向 |
|---|---|---|---|
| 街道监控、安防告警 | 0.25 | 0.5 | 漏检代价高，宁可多报几个框再做业务过滤 |
| 抓拍筛选、质量检查 | 0.5 | 0.45 | 误报代价高，优先保准确率 |
| 车路协同、边缘盒子 | 0.35 | 0.5 | 平衡漏检与误报，配合后续跟踪算法使用 |
调整方法并不是拍脑袋，而是拿一段真实场景视频跑多组参数，对比不同组合下的检测结果。如果你发现行人漏报多，说明 conf 阈值定太高，往 0.25 方向调；如果你发现柱子、树木、车窗反光都被框出来了，说明 conf 太低，往 0.5 方向提。iou 阈值一般保持在 0.45 到 0.5 之间，调得过高或者过低都会出现同一目标被重复框选或框位置不稳的问题。
后处理参数和训练参数是两个层面的事，不要混为一谈。权重优秀只能说明模型学得好，后处理没调对，模型的潜力发挥不出来，这也是很多人说「同一个权重别人跑出 90% 我跑出 70%」的原因所在。
4. 3000 张数据与双标签：从 VOC 转 YOLO 到训练复现
4.1 数据目录组织：train/val 划分与多行人目标特性
3000 张多行人数据和双标签格式是这份资源里仅次于权重的部分。多行人数据意味着单张图片里往往有多个目标，这对训练的实际影响是：一个 batch 里的锚框数量多，模型在正负样本上更容易过拟合，对数据增强的依赖更强。标签格式方面，VOC 是 XML 结构，YOLO 是 txt 文本结构，两者描述的是同一批目标但坐标格式完全不同，VOC 存的是左上角和右下角坐标，YOLO 存的是中心点、宽高且全部归一化。
拿到数据后第一件事不是训练，而是把目录整理成 YOLOv5 期望的结构。VOC 格式数据通常长这样：
dataset_person/ ├── VOC/ │ ├── JPEGImages/ # 原始图片 │ ├── Annotations/ # VOC 格式 xml 标签 │ └── ImageSets/Main/ # 训练/验证划分文件 └── YOLO/ ├── images/ │ ├── train/ # 训练集图片 │ └── val/ # 验证集图片 └── labels/ ├── train/ # YOLO 格式训练标签 └── val/ # YOLO 格式验证标签我一般会先跑一遍划分脚本，把 3000 张数据按 8:1:1 分成训练、验证、测试三部分，而不是用 VOC 原生的 ImageSets 划分。原因很简单：yolov5 训练时只认 train 和 val 两个路径，测试集需要你自己留出来做最终评估。划分时有一个经验值：多行人场景的单张图片目标数量集中在 3 到 10 个之间，训练时 batch-size 可以设小一点，因为单图的目标数量多，等效的梯度更新质量已经足够。
4.2 VOC 转 YOLO 标签：归一化脚本与 class 映射
资源里同时提供了 VOC 和 YOLO 两种标签，但很多时候你自己补充的数据只有 VOC 格式，学一遍转换脚本是有必要的，因为标签格式转换是训练自定义数据集时最高频的实操。转换的核心逻辑是：解析 XML 里的 bndbox 坐标，除以图片宽高得到归一化坐标，再换算成中心点和宽高的形式。
import os import glob import xml.etree.ElementTree as ET VOC_IMG = "VOC/JPEGImages" VOC_XML = "VOC/Annotations" OUT_IMG = "YOLO/images/val" OUT_LABEL = "YOLO/labels/val" CLASSES = ["person"] # class id 从 0 开始 ids = sorted([os.path.splitext(os.path.basename(p))[0] for p in glob.glob(f"{VOC_XML}/*.xml")]) for img_id in ids: tree = ET.parse(f"{VOC_XML}/{img_id}.xml") root = tree.getroot() w = int(root.find("size/width").text) h = int(root.find("size/height").text) lines = [] for obj in root.findall("object"): name = obj.find("name").text if name not in CLASSES: continue # 跳过 difficult 目标，这类样本训练时价值低且标注不可靠 diff = obj.find("difficult") if diff is not None and diff.text == "1": continue bnd = obj.find("bndbox") x1 = int(float(bnd.find("xmin").text)) y1 = int(float(bnd.find("ymin").text)) x2 = int(float(bnd.find("xmax").text)) y2 = int(float(bnd.find("ymax").text)) # YOLO 格式：中心点 + 宽高，全部除以图片宽高归一化到 [0,1] x_center = (x1 + x2) / 2 / w y_center = (y1 + y2) / 2 / h bw = (x2 - x1) / w bh = (y2 - y1) / h lines.append(f"0 {x_center:.6f} {y_center:.6f} {bw:.6f} {bh:.6f}") with open(f"{OUT_LABEL}/{img_id}.txt", "w", encoding="utf-8") as f: f.write("\n".join(lines))逻辑说明：脚本按 xml 文件遍历每一张图，读取 size 节点得到图像宽高，然后遍历所有 object 节点提取目标框坐标。关键步骤是最后一行的归一化换算，(x1 + x2) / 2 / w先求中心点像素坐标再除以宽度，得到的是 0 到 1 之间的浮点数，YOLO 训练时会把输入图缩放，所以标签必须是归一化的，否则框的位置会错位。参数说明里要注意CLASSES的顺序：这个列表的索引就是训练时的 class id，列表第一项对应类别编号 0，第二项对应编号 1，以此类推。如果你在 XML 中用的类别名是Pedestrian而不是person，把列表改成["Pedestrian"]即可，但训练 yaml 里的 names 必须同时改。
转换完成后一定要抽几张图做可视化检查，别偷懒看 txt 文件。用一个 10 行的 OpenCV 脚本把框画回原图，如果发现框整体偏移、被拉长、或者落在目标旁边，基本都是归一化时除错了图像尺寸，或者把 x 和 y 坐标搞混了。这个检查步骤会重复出现在每一个自己处理数据集的晚上，值得固化下来。
4.3 train.py 训练命令、超参数与微调策略
有了干净的 YOLO 格式数据后，就可以复现训练或者微调了。YOLOv5 的训练入口是 train.py，但训练前必须先准备一个数据配置文件，告诉训练脚本数据集路径和类别信息。这里给出一份 person.yaml 的配置：
train: ./YOLO/images/train val: ./YOLO/images/val nc: 1 names: ["person"]逻辑说明：train 和 val 路径指向上一节整理出的图片目录，YOLOv5 会自动在同级目录下找对应的 labels 目录，所以 labels 必须放在图片兄弟目录下，目录名严格叫labels，文件名必须和图片同名。nc: 1声明了类别数量是 1 类，names是类别名列表，里面索引 0 对应标签文件里每行开头的数字 0。这几个字段缺一不可，路径写错会在训练前就直接报错。
数据配置准备好后，训练命令如下：
python train.py \ --data person.yaml \ --weights person_detect.pt \ --epochs 100 \ --batch-size 16 \ --img 640 \ --patience 25 \ --hyp data/hyps/hyp.scratch-low.yaml \ --device 0逻辑说明：--weights传这份资源自带的权重，属于用预训练权重做微调，而不是从 COCO 随机初始化开始训练，收敛速度会快很多，这也是把这份权重当作「预训练模型」时的标准用法。--epochs 100是训练轮数，--batch-size 16取决于显存大小，8G 显存建议降到 8，--img 640和推理时保持一致。--patience 25是早停耐心值，连续 25 轮 val loss 不下降就停止训练，防止浪费算力。--hyp指定超参数文件，这是 YOLOv5 调参的核心入口。
超参数文件里最有价值的几个配置是lr0（初始学习率）、mosaic（马赛克增强概率）、copy_paste（复制粘贴增强概率）。微调时我会手动把lr0从默认的 0.01 改成 0.001，因为预训练权重已经接近最优解，学习率太大容易把已经学好的特征破坏掉，这属于微调场景下最常见的坑。数据增强方面，多行人场景建议保留 mosaic 和 mixup，这两项能显著提升模型对小目标遮挡目标的鲁棒性。
如果只是复现这份资源的指标，不需要做任何修改直接跑完 100 轮就行；如果你是拿它做自己场景的迁移学习，记住一个原则：先冻结 backbone 跑 20 轮，再解冻全部层微调，学习率逐步减小。具体操作用--freeze 10参数冻结前 10 层，之后再看曲线决定是否解冻。160 层的网络结构也可以在models/yolov5s.yaml里看depth_multiple和width_multiple这两个缩放因子来验证自己的理解，这就是常说看 YOLOv5 网络结构图的门道所在。
5. 核查与避坑：数据、标签、权重最容易翻车的五个点
5.1 高频踩坑记录：现象、原因、解决
坑一：推理结果全是 person，但标签编号对不上
现象：用训练好的权重跑验证集时，模型输出的类别没问题，但用--save-txt保存的标签文件里 class id 偶尔出现 1、2 等非 0 值，导致后续分析或训练时数据混乱。
原因：这份资源是单类模型，class id 只有 0 对应 person。如果 label 文件里出现了其他数字，通常是混入了 COCO 或其他多类别数据集的标签文件，那些数据集的 class id 不是从 person 开始编号的，直接套用就错位了。
解决：批量扫描所有 txt 标签，把不是 0 的行做映射或剔除。可以用awk快速检查：awk '$1 != 0 {print $1}' labels/*.txt | sort | uniq -c，查出来后再决定是重新标注还是删除脏样本。
坑二：检测框整体偏移，或者宽高明显被压缩
现象：跑推理时检测框能框住行人，但框不在目标正中心，偏左或者偏上；或者框的宽高比例明显不对，行人被框成一条竖线。
原因：VOC 转 YOLO 时归一化出错。常见的有三种：只除宽没除高、x_center用(x1 + x2)忘记除以 2、以及用图片的缩放尺寸而不是原图尺寸做归一化。
解决：回头跑一遍 4.2 节的转换脚本，并把输出可视化。我自己的排查流程是生成一张画框图，肉眼对一遍前 50 张图，确认没问题再批量继续。这种错误在训练时不会报错，因为 YOLOv5 读取标签时会做边界裁剪和过滤，你看到的只是训练出来的模型精度低，而不会看到具体的报错信息。
坑三：CPU 推理慢到没法用，600 张图跑了一个小时
现象：没有 GPU 的机器上跑 detect.py，一张 640 分辨率的图片推理耗时超过 1 秒，视频基本是一帧一帧卡着出图。
原因：YOLOv5 默认输入是 640 分辨率，卷积计算量在 CPU 上非常大。这不是权重的问题，是推理硬件的边界。
解决：CPU 上想提速，把--img降到 416 或 320，速度能提升一倍以上但精度会小幅下降；或者用--device cpu时同时开启--half，但 CPU 不支持 FP16 加速，意义不大。真正要落地，还是要走最后一步的模型导出路线。
坑四：远距离小目标行人大量漏检
现象：画面里 50 米外的行人只有十几个像素高，模型不报框，但近处行人检测正常。
原因：640 分辨率下小目标的特征在深层特征图里已经被压缩得只剩几个像素，模型没有足够信息判断这是不是人。这是所有目标检测模型的共性短板，不完全是这份权重的问题。
解决：训练和推理时把--img提到 960，小目标检测能力会明显改善，代价是显存占用和推理时间增加。如果场景固定是远距离监控，可以把图片做切片推理，把原图切成四块分别检测再合并结果，这也是工程上常见的 tiling 方案。
坑五：自己补充数据训练后，mAP 反而比原来更低
现象：往数据集里加了 500 张自己场景的图片重新微调，训练结束后验证 mAP 没有上升，反而掉了两三个点。
原因：最常见的有两个：微调学习率设太大，破坏了预训练权重已经学好的特征；或者划分数据时把同一批来源的图片同时分进训练集和验证集，验证指标失真。
解决：微调用 0.001 的学习率，训练轮数控制在 50 轮以内，先看 val 曲线是否还在下降，不要盲目跑满 100 轮。数据划分时按场景分组，比如同一摄像头拍的图全部进训练集或验证集，避免数据泄漏。
5.2 权重文件加载失败与版本不匹配排查
还有一个权重文件本身的问题，很多人第一次拿 .pt 文件 torch.load 就报错，这里给一个排查脚本：
import torch # 无论权重是在 GPU 上训练的，加载时强制映射到 CPU，避免跨设备加载报错 ckpt = torch.load("person_detect.pt", map_location="cpu") print("key 列表:", list(ckpt.keys())) if "model" in ckpt: # YOLOv5 checkpoint 里 model 是特征提取网络结构 print("模型信息:", ckpt["model"].yaml) if "ema" in ckpt and ckpt["ema"] is not None: print("包含 EMA 权重")逻辑说明：这段脚本把 checkpoint 里的键名打印出来，正常情况下 YOLOv5 权重里会有model、ema、optimizer、epoch等字段。model字段里存的是模型结构和参数，验证权重是否和代码版本匹配时可以用ckpt["model"].yaml查看模型的配置文件信息。ema是滑动平均权重，YOLOv5 推理时如果存在ema会优先使用它，因为 EMA 权重的泛化性通常更好。参数说明里map_location="cpu"是排查时的关键：只有在没有 GPU 的机器上加载 GPU 训练权重时才需要显式指定，有 GPU 时不需要。
如果这个脚本都跑不过，说明权重文件本身可能损坏，重新下载一份即可。另一种情况是权重文件正常但 detect.py 报num_classes相关的错误，这通常是你用了其他版本的 YOLOv5 代码加载 v6.0 权重，不同大版本的 checkpoint 结构不兼容，解决办法是把代码切到对应的 v6.0 版本。这种版本错位问题不会在报错里直接提示，而是以各种奇怪的键名错误呈现，遇到时先确认代码版本。
6. 部署前的最后一个动作：全量验证与导出
6.1 批量验证与部署前的导出检查
单张图片跑通不等于能交付，我会在部署前强制做一次全量验证。用这份资源自带的 3000 张数据里的验证集跑一遍批量推理，统计整体的目标检出数量、置信度分布和漏检情况，比看单张效果图靠谱得多。批量验证脚本如下：
import glob import torch # 加载自定义权重，force_reload 强制重新读取，避免使用旧缓存 model = torch.hub.load("ultralytics/yolov5", "custom", path="person_detect.pt", force_reload=True) model.conf = 0.4 model.iou = 0.45 imgs = sorted(glob.glob("YOLO/images/val/*.jpg")) results = model(imgs, size=640) df = results.pandas().xyxy # 每张图一个 DataFrame total_person = sum(len(d) for d in df) print("验证集图片数:", len(imgs)) print("总检出人数:", total_person) print("平均每张图检出:", round(total_person / len(imgs), 2))逻辑说明：torch.hub.load 会把 YOLOv5 当作一个 Hub 模型加载，custom指定的是本地训练权重文件。model.conf和model.iou相当于前面命令行的--conf-thres和--iou-thres，在脚本里直接赋值。results.pandas().xyxy把检测结果转成 DataFrame 结构，每个元素对应该图所有目标的坐标和置信度。这段脚本会输出三个核心数字：验证集图片数、总检出人数、平均每张图检出目标数，这三个数字和 README 里的描述对比，能快速判断这份权重在你的环境里是否达标。
如果目标是把模型部署到树莓派 4B 或者 RK3568 这类边缘设备，我建议在验证后顺手完成一步：把权重导出为 ONNX 格式，再在目标设备上做 INT8 量化。量化后置信度阈值要重新标定，不能直接沿用 FP32 时调好的数值，量化模型在低置信度区间的表现会和原模型有偏离。这样的流程走一遍之后，我心里才有底，而不是拿着压缩包看一眼 README 里的准确率就当项目完成了。从那以后我每次拿到一份新权重，都会先跑一遍这种全量验证再谈部署，希望帮到你。
本文还有配套的精品资源，点击获取
