简介：面向行人目标检测算法训练的一套配套资源，适合目标检测开发者和算法初学者，可直接服务于公共场所监控场景下的行人检测项目，也可作为监控场景通用行人检测数据集的补充。数据集包含1000张真实场景图片，覆盖校园、街景、道路、遮挡及严重遮挡行人等多类情况，采用LabelImg标注且质量较高，提供VOC、COCO、YOLO三种标准格式，接入YOLO等框架即可开始训练。资源包共1个PDF文件，大小4.17MB，内附数据集缩略图与LabelImg标注截图，并说明百度网盘获取方式；同时附赠YOLO11一键训练脚本，覆盖GPU、CPU、Mac（M芯片）三平台运行，附带博主训练日志便于复现和调参。已有1045人浏览学习，适合需要补充监控场景行人数据并快速启动算法实验的开发者，也适用于课程设计与模型预研。
1. 从一份“行人目标检测数据集”到 YOLO11 三平台训练：这套打包方案解决什么问题
拿到一百张标注图不难，难的是当你准备拿它训练 YOLO11 时，发现数据标注格式跟训练框架的要求对不上。你手头可能是 LabelImg 导出的 VOC XML，或者网上爬来的 COCO JSON，而 YOLO 系列训练脚本偏偏只认它自己的 TXT 归一化坐标——单是格式转换就能耗掉一个周末。本文讲的这套“1000 张行人目标检测数据集 + VOC/COCO/YOLO 三种格式标签 + 三平台一键训练脚本”组合，本质是把数据准备和训练启动压缩成一条命令的事。
它适合谁？适合手里只有普通电脑、想在 CPU 或 Mac 上先验证模型能不能收敛的入门者，也适合在 GPU 服务器上做正式训练、但不想每次都被数据集预处理绊一跤的工程师。读者会从本文看到三套标签格式各自的组织逻辑、打开训练脚本后每个参数的含义、以及跨平台跑 YOLO11 时最容易翻车的地方。目标只有一个：让“训练一个行人检测模型”从折腾环境，变成纯粹看指标变化的事。
2. 三格式标签的底层逻辑：为什么一份数据要导成 VOC、COCO、YOLO 三套
2.1 三种格式不是重复劳动，而是对应三类工具链
第一次拿到三份标签的人往往会问：同样的框，存三遍不是浪费吗？实际用过才知道，它们服务的是完全不同的工作流。VOC 格式（XML）是多数开源标注工具的原生输出，单人小项目常用；COCO 格式（JSON）是学术论文和预训练模型榜单的事实标准，也是 Detectron2、MMDetection 等框架的默认输入；YOLO 格式（TXT）则是 ultralytics 训练管线直接读取的格式——每张图一个同名 txt，每行一个目标，写“class_id x_center y_center width height”，全部归一化到 0～1。
三种格式里，YOLO 的 TXT 最容易手写，但也最容易因为坐标归一化出错而“训练能跑、框全乱飞”。COCO 的 JSON 最复杂，因为它的结构是“images 列表 + annotations 列表 + categories 列表”三张表靠 id 关联，任何一条 id 对不上，加载数据时就会报 KeyError。VOC 的 XML 最直观，一个<object>节点就是一个目标，但也最啰嗦，训练框架一般不直接读它。所以这份三格式打包，本质是让使用者跳过转换环节：你用什么工具链，就选哪一套。
2.2 看清三套标签的文件组织：A 目录、命名规则和类目 id
一个能直接喂给训练脚本的数据集目录，结构上是有约定的。常见的组织方式是项目根目录下分images和labels两个大目录，再按 train/val 拆开，或者直接用一个 data.yaml 指向某一个大目录，由框架自己按比例划分。下面是我习惯的文件布局，也是这套“一键训练”约定的布局：
pedestrian/ ├── data.yaml ├── images/ │ ├── train/ │ │ ├── ped_0001.jpg │ │ ├── ped_0002.jpg │ └── val/ │ └── ped_0100.jpg ├── labels/ │ ├── train/ │ │ ├── ped_0001.txt │ │ └── ped_0002.txt │ └── val/ │ └── ped_0100.txt ├── annotations/ │ ├── voc_xmls/ │ │ ├── ped_0001.xml │ │ └── ped_0002.xml │ └── coco_annotations.json类别 id 的坑往往藏在细节里。VOC 里类名是字符串 “person”，COCO 里 person 的 id 是 1，而 YOLO 的 txt 里 class_id 是 0——因为 YOLO 从 0 计数。三套格式共存的正确对应关系是：VOC 的 name 字段 → COCO 的 categories 表 id → YOLO 的 class_id = COCO id − 1。如果你在 YOLO 的 txt 里写成 class_id 1，模型会把行人当成第二类目标来训练，推理时输出类别索引也会整体错位。
2.3 用校验脚本确认三套标签指向同一组坐标
拿到三格式标签后，我建议先跑一遍校验，再谈训练。下面这个 Python 脚本做的事很简单：随机抽几张图，分别读出三种格式里该图的第一个目标框，在图上画出来比对。这一步能一次性暴露“坐标没对齐”“类别 id 错位”“归一化后越界”三类问题。
# validate_labels.py import json import xml.etree.ElementTree as ET import cv2 import random from pathlib import Path img_dir = Path("pedestrian/images/train") img_files = list(img_dir.glob("*.jpg")) sample = random.sample(img_files, 5) for img_path in sample: # 读取原始图 img = cv2.imread(str(img_path)) h, w = img.shape[:2] stem = img_path.stem yoloboxes = [] yolo_txt = Path(f"pedestrian/labels/train/{stem}.txt") if yolo_txt.exists(): for line in yolo_txt.read_text().strip().splitlines(): parts = list(map(float, line.split())) # 将 YOLO 归一化坐标换算回像素坐标 cx, cy, bw, bh = parts[1], parts[2], parts[3], parts[4] x1 = int((cx - bw / 2) * w) y1 = int((cy - bh / 2) * h) x2 = int((cx + bw / 2) * w) y2 = int((cy + bh / 2) * h) yoloboxes.append((x1, y1, x2, y2, f"yolo_cls{int(parts[0])}")) voc_boxes = [] xml_file = Path(f"pedestrian/annotations/voc_xmls/{stem}.xml") if xml_file.exists(): root = ET.parse(xml_file).getroot() for obj in root.findall("object"): bnd = obj.find("bndbox") name = obj.find("name").text voc_boxes.append((int(bnd.find("xmin").text), int(bnd.find("ymin").text), int(bnd.find("xmax").text), int(bnd.find("ymax").text), name)) for box, label in yoloboxes: x1, y1, x2, y2, tag = box cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(img, tag, (x1, y1 - 6), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 2) for box in voc_boxes: x1, y1, x2, y2, name = box cv2.rectangle(img, (x1, y1), (x2, y2), (0, 0, 255), 1) cv2.putText(img, name, (x1, y2 + 16), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 0, 255), 1) cv2.imwrite(f"check_{stem}.jpg", img) print("done, check check_*.jpg")这段脚本的逻辑是先读取原始图片尺寸，然后把 YOLO 的归一化坐标乘回宽高得到像素框，用绿色画出；再把 VOC 的绝对坐标框，用红色画出。正常结果是红绿两框基本重合，类别名都能对上。如果 YOLO 框明显偏大或跑到图像外，一般是归一化时把 width 和 height 写反了，或者在换算时没有乘对方向。如果 class 名对不上，优先检查 data.yaml 里的 class 顺序和 txt 里的 class_id 是否一致。COCO 标签的校验建议单独做，因为 JSON 不会按图片散落，需要用 id 关联。
2.4 COCO 标签的单独校验：id 关联是最大黑匣子
COCO JSON 不像 XML 那样文件跟图一一对应，而是全部塞进一个大 JSON。因此校验它的正确性，重点看三张表之间的 id 能否闭合：
# check_coco_anns.py import json with open("pedestrian/annotations/coco_annotations.json") as f: coco = json.load(f) # 检查图片 id 是否重复 image_ids = [img["id"] for img in coco["images"]] assert len(image_ids) == len(set(image_ids)), "image id 有重复" # 检查 annotation 引用的 image_id 是否存在 img_id_set = set(image_ids) for ann in coco["annotations"]: assert ann["image_id"] in img_id_set, f"annotation 引用了不存在的 image_id: {ann['image_id']}" # 检查 categories 是否包含 person，并注意 COCO 的 id 从 1 开始 cat_ids = {cat["id"]: cat["name"] for cat in coco["categories"]} assert 1 in cat_ids and cat_ids[1] == "person", "COCO categories 里没有 id=1 的 person" print("COCO ann 基本检查通过, categories:", cat_ids)这段代码检查了三件事：图片 id 唯一性、标注数据引用完整性、categories 表中 person 的 id 是否为 1。跑过之后基本能排除 JSON 里常见的“image_id 悬空”和“类别 id 从 0 开始”两个坑。注意 COCO 官方规定 categories 的 id 从 1 开始，而 YOLO 的 class_id 从 0 开始，这个差异是跨格式使用中稳定出现的翻车点，每次都要检查。
3. 跨 GPU、CPU、Mac 三平台跑通 YOLO11：训练环境与一键脚本设计
3.1 三个平台的硬件差异决定了 device 参数怎么填
标题里写“GPU(GPUs)/CPU/Mac 三平台”，对应的是三种完全不同的计算后端。GPU 服务器上通常是 Linux + NVIDIA 显卡，走 CUDA 加速；普通 Windows 或 Linux 台式机没有独显，只能用 CPU 硬扛；Mac 则分两种——Intel 芯片只能走 CPU，M1/M2/M3 这类 Apple Silicon 芯片能走 MPS（Metal Performance Shaders）后端。YOLO11 是 ultralytics 框架兼容的模型系列，它本身不关心你在哪训练，只关心device参数传什么值。
最常见的错误是拿着 Mac 当 GPU 用，代码里写死device="cuda"，一运行就报AssertionError: CUDA unavailable。反过来，在 GPU 服务器上只用 CPU 单核跑，一个 epoch 要跑半小时。下面这套自动判断逻辑是跨三平台训练脚本的核心：不硬编码 device，而是运行时探测。
# select_device.py import torch def auto_device(): if torch.cuda.is_available(): # 返回所有可用 GPU 的 id，比如 "0,1" device = ",".join(str(i) for i in range(torch.cuda.device_count())) backend = "cuda" elif torch.backends.mps.is_available(): # Apple Silicon 专用后端 device = "mps" backend = "mps" else: # 纯 CPU 兜底 device = "cpu" backend = "cpu" print(f"[select_device] backend={backend}, device={device}") return device, backend if __name__ == "__main__": print(auto_device())这段逻辑的执行顺序是 CUDA 优先、MPS 其次、CPU 兜底。注意细节：torch.cuda.device_count()返回的是 GPU 数量，不是设备名。多卡机器上 YOLO11 会自己处理数据并行，所以这里只要把设备编号拼成字符串传进去即可。Mac 上用 MPS 时，一定要确认 PyTorch 是 M1/M2 编译的版本，否则torch.backends.mps.is_available()返回 False，会静默跌回 CPU。
3.2 三平台通用依赖安装：conda 环境与 ultralytics 包
不管哪个平台，YOLO11 的训练入口都是同一个 Python 包：ultralytics。安装它时会自动带出 torch、torchvision、opencv 等核心依赖。但 torch 本身在不同平台上有不同安装方式，这一点值得单独列出来。
| 平台 | torch 安装来源 | 注意事项 |
|---|---|---|
| Linux + NVIDIA GPU | pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 | 必须先装 NVIDIA 驱动和 CUDA 运行时 |
| Windows + CPU | pip install torch torchvision | 默认包自带 CPU 版，体积 200MB 左右 |
| Mac (Apple Silicon) | pip install torch torchvision | 新版 PyTorch 默认支持 MPS，无需额外配置 |
| Linux + CPU | pip install torch torchvision | 同上，但训练速度会比 GPU 慢 10～30 倍 |
我一般建议每个项目建独立的 conda 环境，Python 3.10 或 3.11 都行。一个干净的初始化流程是：conda create -n yolo11 python=3.11，然后激活环境，再装 ultralytics。注意不要用系统全局 Python 装，不然 opencv 和 torch 的版本冲突会让人疯掉，这属于做过一次就再也不想踩的坑。
为了做到“一键训练”，实际操作里我会把环境准备也写进启动脚本里，让脚本在检测到依赖缺失时执行安装，而不是报错退出。下面这个 bash 入口脚本可以放在项目根目录，Windows 上可以用 Git Bash 运行，Linux 和 Mac 直接bash train.sh即可。
#!/usr/bin/env bash # train.sh - YOLO11 三平台一键训练入口 set -e # 遇到错误立刻退出 # 1. 自动创建并激活 conda 环境（已存在则跳过） ENV_NAME="yolo11" if ! conda env list | grep -q "$ENV_NAME"; then echo "[setup] creating conda env: $ENV_NAME" conda create -y -n "$ENV_NAME" python=3.11 fi source "$(conda info --base)/etc/profile.d/conda.sh" conda activate "$ENV_NAME" # 2. 检查 ultralytics 是否存在，缺失则安装 python -c "import ultralytics" 2>/dev/null || pip install ultralytics # 3. 调用 Python 训练脚本 python train_yolo11.py这个入口脚本的关键设计是set -e：任何一步失败立即退出，避免在依赖不完整的情况下继续跑训练、最后报出更迷惑的错。第二步用 Python 探测 import 是否成功，比直接用pip show更可靠，因为即使包存在也可能因 Python 版本不匹配而 import 失败。执行完这个入口后，用户面对的就只有train_yolo11.py里的参数。
3.3 训练脚本内部：data.yaml 与关键训练参数拆解
train_yolo11.py 里最重要的一件事是告诉 ultralytics 数据集在哪、类别是什么。这个信息通过一个 YAML 文件传入，而不是在 Python 代码里写死。下面是针对行人单类检测的 data.yaml：
# pedestrian/data.yaml path: ./pedestrian # 数据集根目录，相对路径相对于运行脚本的位置 train: images/train # 训练图片目录 val: images/val # 验证图片目录 names: 0: person这个 YAML 有四行是必须的：path、train、val、names。它们的路径都是相对path的。names的键从 0 开始，这正好对上 YOLO txt 里的 class_id。很多人在这个文件上翻车：把train写成了绝对路径，导致换机器后目录失效；或者忘了写val，ultralytics 会在训练结束后报找不到验证集。在写数据集打包脚本时，最好让 data.yaml 跟着数据集走，而不是存在训练代码目录里，这样数据集本身可以整体拷贝到任何机器。
训练脚本则把 device 参数、模型规格、训练轮数等集中暴露出来：
# train_yolo11.py from ultralytics import YOLO from select_device import auto_device device, backend = auto_device() print(f"[train] using backend: {backend}, device: {device}") # 加载 YOLO11 预训练权重，n/s/m/l/x 对应不同规模 model = YOLO("yolo11n.pt") # results = model.train(...) 会返回训练指标 results = model.train( data="pedestrian/data.yaml", epochs=100, # 1000 张图，建议至少 100 轮 imgsz=640, # YOLO11 默认输入尺寸 batch=16, # CPU 上建议降到 8，Mac MPS 上建议 16 device=device, # 自动选择的设备 workers=4, # 数据加载线程数，Mac CPU 上降到 2 patience=20, # 早停：20 轮指标不提升就停 project="runs/pedestrian", name="yolo11n_baseline", exist_ok=True, verbose=True, )model.train()里最需要解释的参数是patience和batch。patience=20是早停机制，验证集上的 mAP 连续 20 轮不涨就终止训练，防止时间浪费在过拟合阶段。batch对三平台影响巨大：GPU 上可以开到 32 以上，但 CPU 和 Mac MPS 上 batch 太大不会提速，反而会因为内存交换拖慢整体速度。经验值是 CPU 上 batch=8、Mac MPS 上 batch=16。不要盲目抄作业，先跑 10 轮测一下每轮耗时，再缩放 batch 和 workers。
3.4 老平台、老显卡怎么选 YOLO11 规格：n/s 不是越小越好
YOLO11 有 n、s、m、l、x 五个规格，分别对应网络宽度和深度递增。很多人拿到的一份三平台打包，默认给的往往是 yolo11n（nano 版），因为它在 CPU 上也能跑。但“能跑”和“跑得好”是两回事。在 1000 张行人图上，nano 模型参数量虽小，对遮挡和小目标的拟合能力也弱；如果追求精度且手里有 GPU，直接换yolo11s.pt或yolo11m.pt效果提升非常明显。
判断瓶颈是算力还是显存，看训练日志就行。如果 GPU 利用率跑到 90% 以上，说明算力是瓶颈，换大模型会明显变慢；如果利用率只有 40% 以下，多半卡在数据读入或 batch 太小，这时加大 workers 或 batch，而不是换模型。CPU 和 Mac 上训练，日志里最该看的是 “Epoch gpu_time” 这一列——如果数值接近零，说明计算发生在 CPU 上，MPS 没有生效。
4. 行人数据集三平台训练避坑指南：5 条血泪经验
4.1 训练了 30 轮 loss 不降，先查标签而不是调模型
- 现象：loss 前几轮从 2.0 降到 1.8 之后就不动了，验证集 mAP 始终接近 0。
- 原因：YOLO 标签的归一化坐标错误——比如把图片宽高对调了，或者 txt 里分隔符用了逗号而不是空格。检测任务里，标签错误时模型学到的不是“行人在哪”，而是“噪音长什么样”。
- 解决：先回退到数据校验阶段，用 2.3 节的画框脚本抽查 20 张图。如果抽查后确认标签没问题，再依次排查学习率（是否太大）和数据增强（是否过于激进，把行人裁成了碎片）。
4.2 Mac 上训练比 CPU 还慢，且风扇狂转
- 现象：在 M1 Mac 上明明
torch.backends.mps.is_available()返回 True，但训练一个 epoch 的时间比同配置的 Intel CPU 还长。 - 原因：
device="mps"设置后，部分数据增强算子不支持 MPS，ultralytics 会把它们放回 CPU 执行，导致每步训练都要做一次 GPU/CPU 数据拷贝。尤其是 mosaic 增强在 MPS 上非常慢。 - 解决：训练脚本里加一句
model.train(..., mosaic=0.5)，把 mosaic 概率降到 0.5 或直接关掉；或者把workers提高，让数据预处理和训练重叠执行。如果还不行，接受现实——Mac 适合调参数和验证流程，不适合长训练。
4.3 GPU 显存爆掉，不是显卡不够好而是 batch 太大
- 现象：调到 batch=64 后训练刚开始就报
CUDA out of memory，但总显存明明有 24GB。 - 原因：YOLO11 的显存占用不只看 batch，还要看 imgsz。imgsz=640 时单张图占用约 2GB（含特征图和多尺度训练缓存），imgsz=1280 时直接翻 4 倍。多尺度训练开启时，占用会动态波动。
- 解决：先固定
imgsz=640，把 batch 减半重试。如果显存有空余但训练很慢，可以开cache=True让 ultralytics 把图片缓存到内存，减少磁盘读入压力。注意 GPU 利用率低不等于显存不够，先用nvidia-smi看实际占用率。
4.4 COCO 标签加载报错 “negative image id” 或 “categories not found”
- 现象：用 COCO 格式做训练输入时，loader 抛异常说找不到对应的图片文件或某个 annotation 的 id 是负数。
- 原因：COCO JSON 里 annotation 的
image_id必须指向 images 表中的某个 id，而大多数数据集打包时犯的错是：png 和 jpg 混用，但 JSON 里只写了 jpg 文件名；或者复制 JSON 时把 image 的id字段改坏了。 - 解决：重新核对 JSON 里的
file_name是否真实存在于磁盘上。实际项目中这类问题多出在 Windows 上，因为路径分隔符是反斜杠，JSON 里却按正斜杠写了。统一用 2.4 节的校验脚本检查，别裸跑训练。
4.5 1000 张图训练 mAP 到 0.7 但泛化很差，新场景全漏检
- 现象：验证集上 mAP 有 0.7，但拿手机在大街上拍了几张照片测试，几乎一个行人没测出来。
- 原因：典型的“数据集偏置”——1000 张图如果都来自同一个摄像头角度或同一时间段，模型学到的其实是背景和环境特征，而不是行人本身的特征。数据增强对这类问题的缓解有限。
- 解决：训练时启用更强的增强参数，比如
hsv_h=0.015, hsv_s=0.7, hsv_v=0.4，并加入degrees=10做小角度旋转。另外把 train/val 划分改成按“场景来源”划分，而不是随机打散，让验证集真正代表未见场景。
5. 从跑通到能用的最后一步：用预训练权重、回调与导出踩稳 YOLO11 的尾巴
1000 张行人图从零训练注定效果有限，真正可用的做法是站在 COCO 预训练权重上做迁移学习。上面脚本里YOLO("yolo11n.pt")做的就是这件事——它会自动下载 COCO 上训好的权重，把输出头替换成你的类别数（1 类 person），然后冻结骨干网络做微调。但有个参数值得单独强调：freeze。模型规模越小，冻结层数越要少。yolo11n 建议freeze=10，只冻结前 10 层，保留骨干的底层纹理特征同时让高层充分适配行人数据。
训练收尾阶段，我给自己的硬性要求是必须看一眼三个东西：验证集上的 PR 曲线、混淆矩阵、以及每张测试图的置信度分布。PR 曲线能告诉你该把推理阈值设成 0.25 还是 0.4——行人检测场景漏检比误检更不可接受，所以阈值宁可在 0.2～0.3 之间；混淆矩阵里如果 person 那一行有大量目标分到 background，就要回头检查标签里的“密集行人遮挡”框是不是画太小了。推理脚本里还有一个极易被忽略的参数是conf和iou：conf=0.3控制的是“低于这个置信度就扔掉”，iou=0.5控制的是 NMS 去重。街拍场景行人间互相遮挡时，把 iou 从 0.5 调到 0.4 能保住更多被压制的重叠框。
验证完之后，导出模型往往是最后一道坑。ultralytics 的导出接口一行代码就能生成多种平台格式，但不同设备对输入尺寸的约束不同：
from ultralytics import YOLO model = YOLO("runs/pedestrian/yolo11n_baseline/weights/best.pt") model.export(format="onnx", imgsz=640, simplify=True)导出 ONNX 时simplify=True会用 onnx-simplifier 重构图，消除部分冗余算子。如果你要部署到端侧芯片，建议在导出前先用训练集的统计信息确定输入尺寸，而不是盲用 640。行人目标在街拍原图里通常占不到 1/10，直接下采样到 640 会让小行人变成 20×40 像素的小块，mAP 再高也白搭。常见做法是训练时就用imgsz=960或1280，并用rect=True保持长宽比。这个习惯救过我好几次——在一套室内数据上把输入从 640 提到 960 后，小目标的召回率直接涨了 12 个点。
最后说个我自己的教训：刚开始用这份打包方案时，我在 Mac 上为了省事把 device 写死成mps，结果换回 GPU 服务器跑时报 CUDA 不可用，排查了半天才发现是torch.device("mps")被序列化进了 checkpoint。现在我的习惯是永远让auto_device()动态探测，并且每次训练前打印后端信息——为的是让日志里留下“当时跑在什么设备上”的痕迹，免得事后猜。跨平台训练脚本的价值不是省那一次敲命令的时间，而是省掉换环境后第一轮训练报废的半天。希望这一套组合能让你从数据集到 YOLO11 的路走得痛快一点。
本文还有配套的精品资源，点击获取
