简介一份针对行人检测任务的高质量数据集内含1000张真实场景图片覆盖校园、街景、道路及严重遮挡等丰富场景适用于公共场所监控下的行人检测项目也可作为监控通用行人数据集的有力补充。整个资源包为1个PDF文件约4.17MBPDF中详细介绍了数据集构成、标注规范以及百度网盘下载地址便于用户快速获取原图。所有图片均通过LabelImg精细标注并同时提供VOC(xml)、COCO(json)、YOLO(txt)三种标准格式无论是经典R-CNN系列还是YOLO系列均可直接读取训练省去繁琐的格式转换工作。随资源附赠的YOLO11一键式训练脚本覆盖GPU(GPUs)、CPU、Mac(M芯片)三大平台用户可根据本机环境直接运行另有博主实测训练日志可供对比调参尤其适合刚接触目标检测的开发者快速跑通完整流程也方便研究者做多种数据集的对照试验。当前已有1043人学习下载对于想要积累行人检测实战经验的学习者而言值得一试。1. 这个行人目标检测数据集为什么值得拿来当 YOLO11 的练手项目手头有 1000 张行人目标检测图还配好了 VOC / COCO / YOLO 三种格式标签外加一个能跨 GPU / CPU / Mac 跑的 YOLO11 一键训练脚本——这个组合在视觉入门里不多见多数人拿到的要么是裸图要么只有一种标注格式。它的价值不在规模而在把“数据格式—训练脚本—硬件适配”这条最容易翻车的链路预先踩平了。1000 张图做正式产线太小但拿来验证算法流程、跑通部署、给导师或客户看 demo刚刚好。适合两类人刚接触目标检测、想在一周内跑通一个完整项目的学生以及要在本地快速验证模型效果、又不愿意花时间折腾数据格式的工程师。2. 拿到 1000 张行人图先别训三种标签格式的核对顺序2.1 VOC 的 XML先看 folder 和 bndbox 是否需要归一化VOC 格式的标签是一个和图片同名的 XML 文件根节点是 annotation里面逐个 object 描述目标。object 下的 name 是类别名bndbox 给出 xmin、ymin、xmax、ymax 四个坐标单位是像素。很多从网上找的 VOC 数据集会把 folder 写成 VOC2007但实际图片在别的目录训练脚本如果依赖 folder 字段定位图片就会直接报文件不存在。所以拿到标签后我先不看可视化效果而是用脚本把前 5 个 XML 的 filename 和 bndbox 打出来确认路径和坐标范围是真实像素还是已经归一化的小数。import xml.etree.ElementTree as ET from pathlib import Path voc_dir Path(labels/voc) for xml_path in list(voc_dir.glob(*.xml))[:5]: root ET.parse(xml_path).getroot() filename root.findtext(filename) boxes [] for obj in root.findall(object): name obj.findtext(name) bndbox obj.find(bndbox) xmin float(bndbox.findtext(xmin)) ymin float(bndbox.findtext(ymin)) xmax float(bndbox.findtext(xmax)) ymax float(bndbox.findtext(ymax)) boxes.append((name, xmin, ymin, xmax, ymax)) print(filename, boxes)这段代码只做了解析和打印没有改任何文件适合在训练前做一次“体检”。关键看两点一是 bndbox 的四个数是否都大于 1如果全是 0.3 这种小数说明不是标准 VOC 像素坐标后续转 YOLO 时不能直接除以图像宽高二是图片尺寸要与实际图像一致因为 VOC 的 XML 里有 width 和 height但有些标注工具写错了转换时用 XML 里的尺寸会导致框整体偏移。我一般会同时用 PIL 读一下对应图片的真实宽高两边比对差 1 到 2 像素可以忽略差几十像素就得检查图片是否被缩放或旋转过。VOC 这种格式本身不要求框的宽高大于 0但实际行人检测中经常出现 xmin 和 xmax 相等或者 ymin 大于 ymax 的脏数据通常是因为标注员在打点时手抖或者导出脚本把坐标取整取错了。这样的框在 YOLO 训练里不会直接报错但会变成面积为零的负样本让 loss 出现奇怪波动。为了避免后面排查困难这段核对脚本可以顺手加一个判断把 bndbox 中 xmin 小于 xmax 且 ymin 小于 ymax 的框保留下来不符合的单独输出 warning不要静默跳过。2.2 COCO 的 JSONcategories 的 id 不能跳不然训练时类别对不上COCO 格式的核心是一个 JSON 文件包含 images、annotations、categories 三个数组。images 数组记录每张图的 file_name、width、heightannotations 数组记录每个框的 image_id、category_id、bbox、areacategories 数组把类别 id 和名字对应起来。行人数据集通常只有一个 person 类很多人觉得这太简单了直接开始训练结果 mAP 一直是 0最后发现是 category_id 从 1 开始而 YOLO 内部要求类别索引从 0 开始两个标注系统之间差了一位。更隐蔽的问题是 categories 的 id 不连续。比如有的导出脚本会把 person 定义成 id1背景 id0后来清理类别时删掉 id0但 annotations 里残留了 category_id0 的框。这种情况在 YOLO 加载时会当作不存在或背景导致一个行人框被丢弃。我拿到 COCO 标签后做的第一件事不是打开可视化软件而是统计一下实际用到的 category_id 集合。import json from pathlib import Path coco_path Path(labels/coco/annotations.json) data json.loads(coco_path.read_text()) cat_ids {c[id]: c[name] for c in data[categories]} used_ids set(a[category_id] for a in data[annotations]) print(categories:, cat_ids) print(used ids:, used_ids)这段代码只输出 categories 定义和实际出现过的 id。正常情况应该一致比如{1: person}和{1}。如果出现{1: person}但 used_ids 是{0, 1}说明 annotation 里有脏数据需要先清洗。另一个要核对的是 images 里的 width 和 height很多 COCO 子集为了兼容旧版本会把原图缩小后没有同步更新尺寸结果训练时按旧尺寸归一化标签推理时按新尺寸加载图片所有框都偏到左下角。核对方式也很简单取前 5 张图用 PIL 读取真实宽高和 JSON 里的宽高做比较不一致就说明图片被处理过了。COCO 的 bbox 字段是 x、y、width、heightx、y 是框左上角。它和 VOC 的 xmin、ymin、xmax、ymax 不一样转换时不要把 width 直接当成 xmax。area 字段本来用于计算 mAP 时按面积分层但很多导出工具并不认真填如果你不想在评估时被小目标统计干扰可以在分析时忽略 area只在转换 YOLO 格式后自己用框的宽乘高算面积。2.3 YOLO 的 txt每行 class_id x_center y_center width heightYOLO 格式最简洁一张图片对应一个同名 txt每行五个数字类别 id、框中心点 x 归一化坐标、中心点 y 归一化坐标、框宽度归一化、框高度归一化。归一化的意思是除以图片宽高所以五个数里除了类别 id 外其余全部落在 0 到 1 之间框的宽高还必须是正数。这个格式看起来简单实际踩坑率最高因为很多标注工具导出的 YOLO 坐标是未归一化的像素值或者把 xyxy 格式的 xmin、ymin 当成了中心点。from pathlib import Path label_dir Path(labels/yolo) names [person] for txt_path in list(label_dir.glob(*.txt))[:5]: for line in txt_path.read_text().strip().splitlines(): parts line.split() cid int(parts[0]) x, y, w, h map(float, parts[1:]) assert cid len(names), fclass id {cid} out of range in {txt_path} assert 0 x 1, fcenter x out of [0,1] in {txt_path} assert 0 y 1, fcenter y out of [0,1] in {txt_path} assert 0 w 1, fwidth not normalized in {txt_path} assert 0 h 1, fheight not normalized in {txt_path} print(txt_path.name, cid, x, y, w, h)注意断言只是临时检查如果数据量超过 10000 张逐行打印会很烦可以把 print 改成统计异常文件数量。类别 id 必须和 classes.txt 对应的顺序一致这个数据集的 classes.txt 里只写了 person所以正常情况下每一行的第一列都应该是 0如果你发现第一列是 1而你只有一个类别说明导出的 COCO 或 VOC 转换脚本没有处理 id 偏移需要统一减 1。空白的 txt 文件不要删除它表示这张图里没有目标训练时可以提供负样本防止模型把所有区域都预测成行人。还有一个容易忽略的点是图片文件名和 txt 文件名必须完全一样包括后缀前的名称和大小写。Windows 下文件名大小写不敏感但训练一般跑在 Linux 容器或云服务器上Img_0001.jpg 和 img_0001.txt 会匹配不上。如果你是从 Mac 上把数据集打包发给别人Mac 文件系统通常也区分大小写但很多人没注意这个细节到 GPU 服务器上一跑就发现训练集图片数量为 0。2.4 用一个 20 行的 Python 脚本交叉核对三种格式VOC、COCO、YOLO 三种格式从不同侧面对同一个目标做描述理论上框的数量和位置应该完全一致。与其分别信任三种标签不如直接对同一张图做交叉核对把 VOC 的像素框转成归一化 YOLO 中心点格式再和 YOLO txt 里的解析结果比较COCO 的 bbox 也转换成同一形式。框的数量不一致时优先看漏检坐标不一致时优先看转换时是否忘了除以图片宽高。import xml.etree.ElementTree as ET from pathlib import Path from PIL import Image def voc_boxes(xml_path): root ET.parse(xml_path).getroot() boxes [] for obj in root.findall(object): bb obj.find(bndbox) boxes.append((float(bb.findtext(xmin)), float(bb.findtext(ymin)), float(bb.findtext(xmax)), float(bb.findtext(ymax)))) return boxes def yolo_boxes(txt_path, img_w, img_h): boxes [] for line in txt_path.read_text().strip().splitlines(): _, xc, yc, bw, bh map(float, line.split()) xmin (xc - bw / 2) * img_w ymin (yc - bh / 2) * img_h xmax (xc bw / 2) * img_w ymax (yc bh / 2) * img_h boxes.append((xmin, ymin, xmax, ymax)) return boxes sample img_0001 img Image.open(fimages/{sample}.jpg) print(VOC :, voc_boxes(flabels/voc/{sample}.xml)) print(YOLO:, yolo_boxes(flabels/yolo/{sample}.txt, img.width, img.height))这段代码没有计算 IoU但打印出的坐标可以直接用肉眼对比。如果你处理的图片超过 1000 张建议在里面补一个循环把所有文件名的三种标签逐一读取统计框数量不一致的文件再单独抽取 10 个样本检查坐标误差。实际经验是VOC 和 COCO 之间经常出现个位数像素的舍入差这是正常的因为不同导出脚本对 xmax、ymax 是否包含边缘的处理不一样但 YOLO 归一化坐标反推回像素时如果误差超过 10 个像素就要怀疑图像尺寸读错了。框数量不一致更严重通常是 COCO 的 annotations 里漏了某些框或者 YOLO txt 里有多行重复这种情况只能回源头标注工具里查不要指望训练时自动纠错。这里再补充一个文件层面的检查三种格式的标签文件命名是否都对应上了图片。最简单的方法是用 Python 的 set 对比图片文件名集合与标签文件名集合找出多余和缺失的文件。1000 张图的数据集不大但手工核对很浪费时间这个交叉检查脚本以后换任何数据集都能复用。3. YOLO11 一键训练脚本三平台跑通的最小步骤3.1 目录结构长什么样数据、标签、脚本各放哪拿到数据集后第一件事不是写训练代码而是把目录结构调整成 YOLO 能认出来的样子。Ultralytics YOLO 默认会从图片路径推导标签路径如果图片在 images/ 下标签就在同级的 labels/ 下并且 txt 文件与图片同名。这个数据集里标签分散在 labels/voc、labels/coco、labels/yolo 三个子目录训练时直接用 labels/yolo 里内容即可但要先把它复制成标准的 labels 目录否则训练脚本会显示训练图片 0 张。pedestrian_dataset/ |-- images/ # 1000 张行人图片 |-- labels/ | |-- voc/ # VOC XML核对用 | |-- coco/ # COCO JSON核对用 | |-- yolo/ # YOLO txt训练用 |-- train.txt # 训练图片绝对路径列表 |-- val.txt # 验证图片绝对路径列表 |-- pedestrian.yaml # 模型数据配置 |-- train_yolo11.py # 一键训练脚本 |-- requirements.txt # 依赖列表在真正训练前我会先写一个划分脚本把 1000 张图按 8:2 拆成训练集和验证集。不要手动复制图片到两个文件夹最好用生成 train.txt 和 val.txt 的方式因为 YOLO 的 data.yaml 支持文本列表也可以把图片按 train/、val/ 子目录组织。文本列表的好处是图片不动改动划分只改 txt 内容不会产生大量重复文件。from pathlib import Path import random random.seed(42) images sorted(Path(images).glob(*.jpg)) random.shuffle(images) val_count 200 val_set set(images[:val_count]) with open(train.txt, w) as tf, open(val.txt, w) as vf: for img in images: line str(img.resolve()) if img in val_set: vf.write(line \n) else: tf.write(line \n) print(train:, len(images) - val_count, val:, val_count)固定 random.seed(42) 是很重要的细节。如果不固定种子每次跑这个脚本生成的验证集都不一样训练结果就无法横向比较。这里的 val_count 设成 200是因为 1000 张图如果验证集只有 50 张mAP 的波动会非常大一个误检框就可能让指标掉几十个百分点200 张是一个折中既保证训练数据足够多又让验证集能覆盖多种场景。如果你只是做快速实验也可以把验证集缩到 100 张但指标只当参考不要用它做最终发布结论。3.2 一键脚本做了什么从检查依赖到调用 train所谓一键训练脚本本质就是把原来需要手敲的环境检查、设备选择、模型初始化、参数设置和训练启动打包成一个 Python 文件。这个数据集对应的脚本我一般会做成命令行入口支持 weights、data、device、epochs、imgsz、batch 这些常见参数默认值按这个 1000 张行人数据集来设。import argparse import torch from ultralytics import YOLO parser argparse.ArgumentParser() parser.add_argument(--weights, defaultyolo11n.pt) parser.add_argument(--data, defaultpedestrian.yaml) parser.add_argument(--device, defaultauto) parser.add_argument(--epochs, typeint, default50) parser.add_argument(--imgsz, typeint, default640) parser.add_argument(--batch, typeint, default16) parser.add_argument(--workers, typeint, default4) args parser.parse_args() if args.device auto: if torch.cuda.is_available(): device 0 elif torch.backends.mps.is_available(): device mps else: device cpu else: device args.device model YOLO(args.weights) model.train( dataargs.data, epochsargs.epochs, imgszargs.imgsz, batchargs.batch, devicedevice, workersargs.workers, projectruns/pedestrian, nameyolo11n, )这里最关键的是设备选择逻辑。在 auto 模式下脚本会优先用 NVIDIA GPU然后尝试 Mac 的 MPS最后退回 CPU。很多人以为 torch.cuda.is_available() 为 True 就一定能用 GPU其实如果显卡驱动和 PyTorch 版本不匹配这个函数会返回 False这种情况下脚本会自动落到 CPU不会报错但会很慢。如果你在 Windows 上看到训练日志里没有 CUDA 字样可以先在终端敲一句python -c import torch; print(torch.cuda.is_available())确认环境而不是怀疑脚本写错了。yolo11n.pt 是预训练权重第一次运行时需要联网下载到缓存目录1000 张图的小数据集强烈建议保留预训练权重否则从零训练几十张很难收敛。3.3 GPU / CPU / Mac 三平台分别怎么启动三平台的启动差异只在 device 和显存相关参数。GPU 服务器上可以直接用--device 0如果机器有多张卡先用nvidia-smi看一下哪张卡空闲再指定卡号。CPU 机器上--device cpu即可但要控制 workers不要以为 workers 越大越好Windows 上 workers 大于 0 时必须在if __name__ __main__:保护下执行脚本否则会递归启动进程。Mac 上优先试--device mps但小显存机器很容易爆后面避坑章节会专门讲。# GPU 机器单卡 python train_yolo11.py --device 0 --batch 16 --imgsz 640 # CPU 机器显存不足时用 python train_yolo11.py --device cpu --batch 8 --imgsz 640 --workers 0 # Mac 使用 Metal 加速 python train_yolo11.py --device mps --batch 4 --imgsz 640如果是在远程服务器上跑建议用 nohup 或 tmux 把训练放到后台防止 SSH 断开导致训练中断。训练过程中可以随时打开 runs/pedestrian/yolo11n/ 目录下的 results.png 和 results.csv 看曲线不需要等训练结束。1000 张图加 yolo11n 在小 GPU 上大约 30 到 60 分钟能跑完 50 轮CPU 上可能要三到五个小时所以有时间预算的话先用 GPU 调一轮确认参数合理再全量训练。3.4 训练完先看 weight 和 results.csv别急着吹指标训练结束后很多人只看终端最后打印的 mAP然后直接拿 best.pt 去做 demo。终端显示的是训练结束时的指标不是验证集上的最佳指标两者可能差不少。Ultralytics 训练过程中会保存两个权重last.pt 是最后一轮的权重best.pt 是验证集指标最好的权重用的时候应该优先选 best.pt。results.csv 里记录了每一轮的训练损失和验证指标是排查过拟合和判断训练是否稳定的第一手材料。import pandas as pd results pd.read_csv(runs/pedestrian/yolo11n/results.csv) val_cols [c for c in results.columns if c.startswith(val/)] print(results[[epoch] val_cols].tail(5))这段代码读取出最近 5 轮的验证指标。行人数据集只有 person 一个类主要看metrics/mAP50(B)和metrics/mAP50-95(B)这两列。mAP50 是 IoU 阈值 0.5 下的平均精度对工程 demo 足够mAP50-95 更严格适合衡量模型在小目标和遮挡行人上的真实能力。如果验证集 mAP50 一直在 0.8 以上但 mAP50-95 只有 0.2说明模型框的位置不够准下一步应该提高 imgsz 或者检查标注框是否偏大偏小。results.csv 还能帮你判断有没有过拟合train 损失下降但 val 损失回升就是把训练轮数拉太多了。4. 把 mAP 从 0.3 拉到 0.6行人检测必调的四个参数4.1 epochs1000 张图不是越大越好模型训练中第一个要动的参数是 epochs很多人觉得反正数据少直接训 300 轮比较稳。1000 张行人图对 YOLO11 来说属于小样本300 轮极大概率在 100 轮左右就过拟合val 损失不再下降train loss 却持续走低。我一般从 50 轮开始配合早停参数让模型在验证指标连续 10 到 15 轮不提升时自动停止这样即使你设了 300 轮也不会浪费时间。model.train( datapedestrian.yaml, epochs100, patience15, seed42, )patience 是 Ultralytics 自带早停的窗口大小单位是轮。1000 张图训练时指标曲线会有波动patience 设太短容易提前停在一个局部最优设太长又失去了早停意义。15 轮是一个常见起点如果你发现模型在第 40 轮还在明显上升说明 100 轮不够可以把 epochs 加到 150如果第 30 轮就开始反复不涨说明数据集噪声大回看是否有标签错位。还要注意早停依赖验证集如果 data.yaml 只提供了 train 没有 val早停不会生效整个训练会按 epochs 跑满。对于这种单类别的行人检测任务epochs 的选择也可以参考 loss 曲线。如果 box_loss 降得很慢但 cls_loss 已经很低说明模型定位能力弱提升 epochs 帮助不大应该考虑 imgsz 或数据增强。一个容易踩的误区是拿别人在 COCO 上训练的最好轮数来套自己的数据集COCO 有十几万张图1000 张图的收敛速度和它完全不是一个量级照搬只会得到一个人为拔高的 train loss 和一个在验证集上惨不忍睹的模型。4.2 imgsz行人目标小不要照搬 640YOLO 官方示例默认 imgsz640但对行人检测来说640 不一定是最优。行人目标的特点是整体形状细长在画面里可能只占几十个像素特别是监控视角下的人宽度可能只有 20 到 30 像素。小目标经过网络多次下采样后特征几乎消失所以这种情况下适当提高输入分辨率比增加训练轮数更有效。如果原图本身是 1280x720imgsz 拉到 960 通常能明显提升 mAP50-95如果原图只有 640x480强行设 960 只是把图像放大不会增加细节还浪费显存。model.train( imgsz960, batch8, )不要孤立地调 imgsz它和 batch 是连锁的。显存占用几乎按分辨率平方增加640 到 960 会占用大约 2.25 倍的显存如果你原来 batch 16现在可能要降到 8 或 4。在 8GB 显存的笔记本 GPU 上yolo11n 配 960 加 batch 8 通常能跑但如果再叠加数据增强和混合精度之前的缓存也可能爆这时候优先保 imgsz 而不是 batch因为 batch 小一点只是 BN 统计不稳imgsz 不够则是直接丢失小目标信息。反过来如果是 CPU 训练960 会让推理速度明显变慢建议先用 640 把流程跑通再在 GPU 上做一轮 960 的对比实验。4.3 batchGPU 显存和 CPU 内存之间的取舍batch 的默认值在 YOLO11 里按显存大小有自动调整机制但自动调整有时候很保守有时候又过于激进。1000 张图的小数据集batch 太大并不会带来明显的训练加速反而会让 BN 统计过于平滑模型过早收敛。你可以在脚本里手动固定 batch比如 GPU 8GB 显存设 816GB 设 16CPU 设 4 到 8。注意 batch 是 per GPU 的数值如果用多卡训练总 batch 等于 batch 乘以卡数但这个项目完全没有必要多卡。model.train( batch8, cacheFalse, workers4, )workers 不是 batch但经常和 batch 一起被误解。workers 表示数据加载进程数它影响的是 CPU 读取图片的速度不会直接占 GPU 显存但每个 worker 会复制一份数据到内存如果同时开 8 个 worker 且 cacheTrue内存占用会直线上升。1000 张图的数据量不大用 cacheTrue 把图片全缓存到内存反而能加快训练但 1280x720 的 RGB 图片一千张大约要占 2.7GB 内存如果你的机器只有 8GB 内存建议 cacheFalse。训练时如果 GPU 利用率低但 CPU 占用率很高多半是 worker 太少或者数据读取阻塞后面避坑章节会单独讲。还有一个和 batch 关系很大的现象是 BN 崩溃当 batch 很小且没有预训练权重时BN 层统计量会被少数样本带着跳loss 突然变成 NaN这个项目里有预训练权重所以风险低但如果有人把 weights 换成 yolo11s.pt 且 batch 设为 2就要小心了。4.4 数据增强行人遮挡场景怎么救小数据集最大的问题是增强策略容易失衡。YOLO11 默认开了 mosaic、flip 等增强mosaic 可以把四张图拼在一起训练增加目标尺度和上下文多样性但在 1000 张图这种小数据上mosaic 过头会让模型看到大量拼接边界验证时真实图片反而表现不好。行人遮挡是另一个高频场景两个行人挨得很近时默认的随机裁剪会把一个人裁掉一半标签还是原来的完整框模型就会被误导。这种情况下我一般会调低 mosaic并且保持水平翻转。model.train( mosaic0.5, fliplr0.5, hsv_h0.01, hsv_s0.5, hsv_v0.4, )hsv_h、hsv_s、hsv_v 是颜色增强参数行人检测对颜色变化不需要太敏感hsv_h 调太大会让肤色和衣服颜色失真反而不利于泛化。如果你是做夜间行人检测不要只靠颜色增强还是需要真实夜间图增强只能辅助。fliplr0.5 表示 50% 概率水平翻转行人左右对称这个增强是安全的如果数据集里有文字或方向性标志才需要关掉。除了这些内置参数还可以在标注工具里对图片做二次处理比如把原图放大 1.2 倍再切一部分生成额外的训练样本但这不在训练脚本范围内属于数据扩充。5. 常见训练事故排查行人数据集最容易翻车的 5 条踩坑记录5.1 data.yaml 路径写错训练集图片数量变 0现象启动脚本后日志里打印train: 0 images或者AssertionError: train: No images in ...但目录里明明有 1000 张图。原因data.yaml 里的 path 字段用了相对路径例如path: .或path: pedestrian_dataset而训练脚本是从不同目录启动的Python 进程的工作目录和项目目录不一致导致 YOLO 找不到图片。更隐蔽的是train.txt 里写的图片路径是相对路径YOLO 会以当前工作目录为基准去解析。解决在脚本里用Path(__file__).resolve().parent把项目根目录固定下来再拼出 data.yaml 的绝对路径不要相信终端当前目录。from pathlib import Path BASE_DIR Path(__file__).resolve().parent data_yaml str(BASE_DIR / pedestrian.yaml) model.train(datadata_yaml, ...)判断这个问题的方法是打印出 data_yaml 和 train.txt 的前几行内容确认路径前缀是否指向真实存在的图片。如果图片在 images/ 下但 train.txt 里写的是 ./datasets/pedestrian/images/xxx.jpg也要同步检查。这条坑在第一次跑项目时最容易出现因为大多数人习惯双击脚本或从 IDE 输出窗口运行工作目录经常改变。5.2 标签越界训练报 IndexError现象训练开始后很快抛出IndexError: index 1 is out of bounds for axis 0 with size 1或者 CUDA error 表面信息实际堆栈在标签加载。原因YOLO 的 txt 第一列是类别 id当前数据集只有一个 person 类所以 id 只能是 0。但制作 VOC/COCO 的转换工具可能沿用了 COCO 的 category_idperson 在 COCO 里是 1转换时没减 1导致训练脚本在读标签时访问不存在的第二类。解决先遍历所有 YOLO txt检查第一列的最大值再和 classes.txt 的行数对比。这个检查要在训练前做不要在报错之后做。from pathlib import Path bad [] for txt in Path(labels/yolo).glob(*.txt): for line in txt.read_text().splitlines(): cid int(line.split()[0]) if cid ! 0: bad.append((str(txt), cid)) print(bad count:, len(bad)) if bad: print(bad[:10])如果确实存在非 0 的 id用脚本把所有 txt 的第一列改写成 0前提是你确认这个数据集只有行人类别。如果以后要多类别训练不要机械改成 0而是建立类别名字和 id 的映射表。另一个相关问题是坐标值本身超过 1比如 1.2这通常是因为归一化时用了错误的图片宽高处理方式不是截断而是要回原始标注重新计算。5.3 GPU 显存溢出训练跑到一半被杀死现象训练正常开始几分钟后终端弹出RuntimeError: CUDA out of memory.有时 Intel 核显和 NVIDIA 独显同时存在时PyTorch 选错 GPU报错信息里显示的还不是 cuda:0。原因imgsz、batch、workers 三个参数叠加把显存瞬时占满。另一个常见原因是 Windows 笔记本上 PyTorch 虽然装着 CUDA 版但实际调用的是核显或者被其他程序占用的显存。很多笔记本 GPU 是 RTX 4060 Laptop 这类 8GB 显存卡实际可用的也就 7GB。解决先降到最保守的组合--imgsz 640 --batch 4 --workers 0确认能跑起来再逐步往上加。workers0 会去掉数据预取用 CPU 现读现传虽然慢但不会造成显存峰值。同时用 nvidia-smi 监控显存如果进程开始前已有多块显存被占用就换卡。nvidia-smi --query-gpuindex,memory.used,memory.total --formatcsv python train_yolo11.py --device 0 --imgsz 640 --batch 4 --workers 0如果 batch4 也爆可以检查是不是开了 cacheTrue把整张数据集都缓存进显存。YOLO 官方文档里 cache 有三种值False、True、ram默认 False但有人为了加速会设成 ram如果设成了 True 在 Ultralytics 里会尝试缓存到显存小显存直接翻车。我自己的经验是1000 张图不值得用 cache提速有限风险不小。5.4 Mac 上 MPS 不稳定训练中断或速度极慢现象在 MacBook 上用--device mps训练有时能跑前几轮随后提示MPS backend out of memory有时直接卡死和 Windows 用 GPU 的表现完全不同。原因MPS 是 PyTorch 的 Metal 后端对部分算子支持还不完整YOLO11 的一些模块在 MPS 上会退化成低效率实现甚至触发内存分配问题。1000 张图的数据量虽然小但数据加载的临时张量也会累积在共享内存里。解决如果只是想快速验证数据集和脚本有没有问题直接用 CPU 跑最多把 epochs 降到 20。如果一定要用 MPS把 batch 降到 2、workers 降到 0并且不要开 cache。还可以在脚本里加一层回退当 device 是 mps 且出现一次 OOM 时自动换成 CPU 重启训练但这种容错逻辑在正式环境里会让结果不可复现我一般不推荐只用来救急。try: model.train(...) except RuntimeError as e: if MPS in str(e) or out of memory in str(e): print(mps failed, fallback to cpu) model.train(..., devicecpu)这个回退写法的缺点很明显前一个设备上已经跑了 n 轮换到 CPU 后权重状态需要重新构建日志里的曲线也会断裂。所以更靠谱的做法是第一次跑之前先用torch.backends.mps.is_available()确认支持再用小 batch 测试 3 轮没问题再正式训练。Mac 不是做目标检测训练的主力平台跑通脚本和做小规模实验可以大规模训练还是租一台 GPU 服务器更省时间。5.5 GPU 利用率只有 20%训练时间被数据读取拖死现象用 nvidia-smi 看训练进程GPU-Util 一直在 20% 上下跳动显存占用正常但 epoch 时间比同配置的 Linux 服务器慢很多。原因数据加载线程成了瓶颈。Windows 上 workers 大于 0 时PyTorch 会启动多个进程读图但如果图片存储在机械硬盘或网络盘上每个 worker 都在等 I/O或者 workers 数量超过 CPU 核数线程切换开销反而拉低速度。另一个原因是图像解码在 CPU 上完成而 CPU 本身还在做数据增强和归一化处理不过来。解决先看 CPU 占用率。如果 CPU 已经跑满就把 workers 从 4 降到 2 或 1如果 CPU 还有很多空余但 GPU 利用率低可能是图片读取延迟可以试试 cacheram把图片提前读到内存但这需要足够内存。还有一个被低估的参数是 rect它让同 batch 的图片按宽高比分组减少 resize 造成的计算浪费但会打乱图片顺序小数据集上对训练影响不大。model.train( workers2, cacheram, rectFalse, )如果你的图片分辨率不统一还可以先把所有图片缩放到统一尺寸再训练减少运行时 resize 的波动。1000 张图手动批量 resize 也很简单用一段 Python 循环 img.resize((640, 640)) 输出到新目录但注意要同步修改标签归一化坐标因为原图宽高比值变了直接将长图压成方形会导致行人变扁。我一般不会在数据集层面强行统一尺寸而是让 YOLO 的 letterbox 处理这种预处理在脚本里是自动完成的。6. 训练结束后的两个收尾技巧混淆矩阵与 ONNX 导出6.1 用验证结果里的混淆矩阵判断漏检还是误检训练结束后不要只盯 mAP去 runs/pedestrian/yolo11n/ 目录找 confusion_matrix.png。单类行人检测的混淆矩阵只有两行两列加一个 background 类能直接看出模型是把行人错分成背景也就是漏检还是把背景错分成行人也就是误检。如果 background 行里有很多样本说明模型的置信度阈值设得太低推理时把大量背景框留了下来如果 person 行里真实行人大量落到 background说明模型特征没学到需要回看标注质量和输入分辨率。from ultralytics import YOLO model YOLO(runs/pedestrian/yolo11n/weights/best.pt) metrics model.val(datapedestrian.yaml, splitval, plotsTrue) print(mAP50:, metrics.box.map50, mAP50-95:, metrics.box.map)这段代码会重新跑一次验证并重新生成 plots。有人发现混淆矩阵里的数字总和不是 1实际上每一行是独立归一化的background 这一行加起来是 1其他行也各自归一化所以不能拿整张表的数字做概率解释。看到 mAP 低但不知道为什么时先看这个矩阵比猜参数高效得多。6.2 导出 ONNX 并用 10 张没见过的图做烟雾测试验证指标只是数字部署前我还会把 best.pt 导出成 ONNX再拿训练时没有见过的 10 张图做一次推理。导出的目的不是立刻上生产而是确认 PyTorch 模型和部署框架之间的输出一致避免模型结构里用了自定义算子导致转换后行为不同。model.export(formatonnx, imgsz640, dynamicTrue)dynamicTrue 允许输入尺寸动态变化方便部署时不用固定 640。导出后可以用 onnxruntime 或直接用 YOLO 的 predict 接口做烟雾测试把 conf 调成 0.5看哪些图出现漏检、哪些图出现重复框。我自己的习惯是每次换数据集都把这 10 张图留在一个单独的 demo 目录里不参与训练只用来做最终验收。因为 mAP 是平均指标但能不能上线往往取决于一张雨天、逆光、人群拥挤的图上会不会漏检。这套 1000 张行人图加三格式标签和一键训练脚本正好让我能在半天内把这些事全部验证一遍。希望帮到你。本文还有配套的精品资源点击获取