简介：一份基于YOLOv8的行人检测项目资源，面向计算机相关专业学生与开发者，可用于课程设计、毕业设计或目标检测算法入门。项目代码已测试通过，不仅包含模型训练与检测推理脚本，还带有核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图，能直观展示模型效果，适合答辩展示或项目演示。压缩包共6个文件，包含3个PyTorch权重文件（.pt）、2个Python脚本（.py）和1个说明文档（.txt），整体大小约15.89MB，结构精简、开箱即用。目前已有36人学习下载，对于YOLO系列研究及行人检测应用具有一定的参考价值。资源附有部署说明与数据集引入提示，按README即可快速运行，也可在其基础上扩展改进。
1. 解压这份“行人检测项目”之前，先想清楚你要拿它做什么
刚拿到“基于YOLOv8的行人检测项目.rar”这种压缩包，多数人第一反应是双击解压、找README、把训练命令一粘贴就等结果。但作为看过几十份“号称能跑”的项目代码的人，我得先泼盆冷水：这类压缩包价值不在.rar里那几十兆代码，而在它帮你把“数据集、模型、训练、验证”这条链路提前串好了。你真正要做的不是跑通它，而是弄懂它每一层在干什么，否则换个场景、换台机器，代码立刻变成黑匣子。
这篇文章的目标很直接：把基于 YOLOv8 的行人检测项目从解压到跑通，再到改造成自己能用的东西，每一步给你能直接抄的参数、命令和排错思路，把这份压缩包彻底榨干。适合三类人：做毕业设计需要快速出一个可演示系统的学生、刚转算法岗想熟悉 YOLOv8 训练全流程的工程师，以及要把行人检测落到边缘设备（比如 RK3588、HI3516）上的嵌入式开发者。接下来我从包内结构讲起，一路带到训练、避坑和推理部署，全程按我实际做项目的顺序来。
2. 先把包里的底牌摸清：行人检测项目的目录结构与数据集准备
2.1 一个规范的 YOLOv8 检测项目，目录里应该有什么
拿到压缩包先别急着跑训练，用一棵树把目录结构看清楚。通常一个能完整交付的 YOLOv8 行人检测项目，至少包含这几块：代码入口、模型配置、数据集、训练输出、推理脚本和依赖清单。但压缩包不等于开源仓库——很多人在百度网盘里分享的 rar 往往只给了“能用的部分”，比如训练好的best.pt权重、标注好的数据集和一个简单的train.py，而不会把整个 ultralytics 仓库打包给你。所以先检查缺少什么，再决定怎么补。
我自己收到这种包后的标准动作是先确认三件事：
- 有没有标注好的数据集（
images和labels目录是否齐全，data.yaml是否指向正确路径）； - 有没有
best.pt或last.pt预训练权重； - 有没有写明训练命令的说明文件，哪怕是注释里的一行。
普通项目的典型目录结构长这样：
pedestrian-detection/ ├── data/ │ ├── images/ │ │ ├── train/ # 训练集图片 │ │ └── val/ # 验证集图片 │ ├── labels/ │ │ ├── train/ # 每个图片对应的txt标注 │ │ └── val/ │ ├── data.yaml # 数据集配置文件 │ └── pedestrian.yaml # 模型配置文件（可选） ├── runs/ │ ├── detect/ │ │ ├── train/ # 每次训练的输出目录 │ │ └── val/ ├── weights/ │ ├── yolov8n.pt # 初始权重（可能是下载来的） │ ├── yolov8s.pt │ └── best.pt # 训练好的权重 ├── scripts/ │ ├── train.py # 训练入口 │ ├── predict.py # 推理脚本 │ └── convert_labels.py # 标注格式转换脚本 └── requirements.txt看到weights/目录里同时有yolov8n.pt和yolov8s.pt，说明设计者考虑到了不同硬件条件的用户。这里就引出一个选型问题：YOLOv8 的 n/s/m/l/x 五个尺度版本，行人检测该选哪个？
我的经验是：追求实时性或部署到边缘设备，选yolov8n或yolov8s；追求精度并且有独立显卡（比如 GTX 1660 Ti 或以上）跑实验，选yolov8s或yolov8m。行人检测的目标相对单一（一个类别），不需要上到l或x，那个计算量换来的是边际收益极低的精度提升。压缩包里如果默认给的是yolov8s.pt，那基本属于“均衡且不犯大错”的选择。
2.2 行人检测数据集：格式、来源与你需要关心的统计量
再往深看，这个项目能否跑通的关键枢纽是数据集。YOLOv8 用的是 YOLO 格式的标注：每个.txt文件和图片同名，每一行代表一个目标，格式是class x_center y_center width height，四个坐标值都是相对图片宽高的归一化比例。行人检测因为类别只有person一类（有些会把rider也单独列一类），所以class索引通常是0。
一个典型标注文件内容是这样：
0 0.48203125 0.51015625 0.24140625 0.6140625 0 0.73203125 0.54765625 0.1875 0.6234375拿到数据集后，我建议先做一个分布统计，不要急着训练：图片的平均尺寸范围是多少、行人在图片里占比多大、有没有大量遮挡目标。如果行人普遍偏小（小于 32x32 像素），默认的 640 输入尺寸可能不够用，后面要做的是把imgsz调大到 1280 而非换模型。这一步用 OpenCV 跑个简单脚本就能看：
import cv2 import os from collections import Counter img_dir = "data/images/train" sizes = [] for fname in os.listdir(img_dir): img = cv2.imread(os.path.join(img_dir, fname)) h, w = img.shape[:2] sizes.append((w, h)) avg_w = sum(s[0] for s in sizes) / len(sizes) avg_h = sum(s[1] for s in sizes) / len(sizes) print(f"平均图片尺寸: {avg_w:.0f}x{avg_h:.0f}")这段代码统计的是训练集图片的分辨率分布，作用是帮你确定训练时imgsz的初始值。如果平均分辨率在 1280 以上，输入尺寸设 640 会丢掉一半细节；如果平均只有 480x640，用 640 反而做了上采样。默认拿 640 起步问题不大，但知道数据的长宽比分布能直接规避后续“小目标漏检”的坑。
数据集来源方面，公开行人检测数据集一般优先考虑CrowdHuman、CityPersons和Caltech。但压缩包里通常不会给你原始数据集（原始下载量太大），而是给一个已经转换好的 YOLO 格式子集。这时候你别纠结“这数据集是不是正版”，先看标注质量：随手抽 20 张图，用 LabelImg 或 Labelme 打开看标注框是不是贴合行人轮廓、有没有漏标和错标。标注质量差的数据集再加多少训练时间都救不回来——这是行人检测项目里最常见的血泪教训。
如果压缩包自带的数据集不够用，或者你要在这套代码上换自己的场景（比如厂区安防、十字路口车流统计），那就要自己标注。一般流程是：用 Labelme 画框，导出 JSON，再转成 YOLO 格式。这个转换脚本几乎每个项目都要用一遍，固定套路如下：
import json import os def labelme_to_yolo(json_path, save_dir, class_names): with open(json_path, "r", encoding="utf-8") as f: data = json.load(f) img_w = data["imageWidth"] img_h = data["imageHeight"] out_lines = [] for shape in data["shapes"]: label = shape["label"] if label not in class_names: continue cls_id = class_names.index(label) points = shape["points"] # [[x1, y1], [x2, y2]] x1, y1 = points[0] x2, y2 = points[1] # 归一化到 0~1 x_center = (x1 + x2) / 2 / img_w y_center = (y1 + y2) / 2 / img_h box_w = abs(x2 - x1) / img_w box_h = abs(y2 - y1) / img_h out_lines.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}") out_name = os.path.basename(json_path).replace(".json", ".txt") with open(os.path.join(save_dir, out_name), "w") as f: f.write("\n".join(out_lines)) class_names = ["person"] labelme_to_yolo("data/json/0001.json", "data/labels/train", class_names)这个脚本里要注意两个边界：一是 Labelme 的points是矩形两个对角点，但手工标注时可能是左上到右下，也可能是右下到左上，所以x1, x2之间要做abs取绝对值，上面的代码用abs(x2-x1)已经处理了；二是imageWidth和imageHeight要确保用的是 JSON 里的原图尺寸，不能拿标注时的显示尺寸，否则归一化坐标全偏。另外一个很容易翻车的点是：Labelme 默认导出的 JSON 里只有一个label字段，如果你的标注有多级标签（比如“被遮挡的行人”和“完整行人”分两个 label），记得在class_names里确保类别顺序和data.yaml里的names完全一致，否则训练时类别对不上，损失函数直接不收敛。
2.3 data.yaml 的路径陷阱：为什么你改了路径还是报错
把数据集整理好之后，核心就是data.yaml文件。这个文件是连接数据与模型的桥梁，YOLOv8 要求它包含train、val路径和类别名列表。大多数人在这里栽的第一个跟头是路径用了相对路径但工作目录在别处。
data.yaml里的路径默认是相对你执行命令时所在的工作目录的，不是相对 yaml 文件所在位置。这意味着如果你在项目根目录建了models/pedestrian.yaml然后cd models去跑命令，路径就全错了。YOLOv8 有个yaml解析机制，train路径可以是绝对路径，也可以用./开头，但最稳妥的做法是用绝对路径，特别是在 Windows 和 Linux 之间跨平台拷贝时。
一个通用能跑通的data.yaml长这样：
train: /home/user/pedestrian-detection/data/images/train val: /home/user/pedestrian-detection/data/images/val nc: 1 names: ["person"]这里nc: 1和后面names里的类别数必须严格对应，写多写少都会在训练启动时报维度错误。还有一点容易被忽略：YOLOv8 训练时会自动从train目录下的图片路径推导出同名的 label 路径，它默认在图片路径里把images替换成labels。所以数据集的目录名一定要带images和labels这两个关键字，否则 transform 机制找不到标注文件，报错又常被误读成“数据集为空”。这种行为属于框架内置的路径匹配逻辑，严格按照约定目录名组织数据，是少踩坑的第一原则。
3. 训练闭环跑通：Ubuntu 环境搭建与 YOLOv8 训练参数调整
3.1 从零搭建 YOLOv8 环境：CPU 版 Ubuntu 20.04 的可行路线
很多人拿到这类项目后，第一关居然不是代码而是环境。尤其是手头没有 NVIDIA 显卡、只有一台普通台式机或笔记本的用户，专门搜过“ubuntu20.04 搭建 yolov8 环境 cpu 版本”。这个诉求本身很实际：先把流程跑通、把代码看懂，显卡后面再借。CPU 训练 YOLOv8 不是不行，而是你要有耐心，并且把参数调得合理——拿 CPU 跑 300 轮 2000 张图要十几个小时，但如果只跑 50 轮验证代码正确性，半小时就能看到 loss 曲线在下降，这对前期排查价值巨大。
Ubuntu 20.04 上搭 CPU 版 YOLOv8 环境，固定顺序如下：
# 1. 安装 Python 虚拟环境管理 sudo apt update sudo apt install python3.10-venv python3-pip -y # 2. 创建项目专属虚拟环境，避免污染系统 Python cd ~/pedestrian-detection python3 -m venv venv source venv/bin/activate # 3. 安装 PyTorch CPU 版（关键：不要直接装默认的 CUDA 版本） pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 4. 安装 ultralytics（YOLOv8 的官方库） pip install ultralytics这里的核心逻辑在于第三步。如果你直接pip install torch，大概率会装上带 CUDA 的大几百 MB 版本，在 CPU-only 机器上能运行但白白占了空间，而且某些版本的 CUDA 依赖（比如nvidia-cublas）可能会在无 GPU 机器上触发 glibc 冲突。用--index-url指定 CPU 版 wheel 是干净的方案，这个安装包体积小了一半左右，而且完全不影响后续代码逻辑。然后ultralytics库会顺带把opencv-python、pandas、matplotlib这些依赖一起装上，省去手动逐个安装的麻烦。
装完验证一下是否正常：
python -c "import torch, ultralytics; print(torch.__version__); print(ultralytics.__version__)"能正常打印出版本号说明环境通了。CPU 环境下第一次运行 YOLOv8 时，PyTorch 会用 OpenMP 自动起多线程，但默认线程数经常不是最优的。你可以在代码里显式设置：
import torch torch.set_num_threads(8) # 按 CPU 物理核数调整，不是越大越好3.2 训练命令里的参数调整：epochs、batch、imgsz 和 freeze 的实践取值
环境搭好、数据集就位后，就可以开始训练了。YOLOv8 的 CLI 训练命令几乎是标准格式：
yolo detect train data=data.yaml model=yolov8s.pt epochs=100 batch=8 imgsz=640 patience=15 project=runs name=train_pedestrian这段命令里每个参数都有讲究，逐个拆开说：
model=yolov8s.pt既是模型结构定义也是预训练权重。如果你不想要预训练权重，可以写model=yolov8s.yaml，这时候会从头训练，需要的数据量和时间多一个量级，所以一般不建议凭空练；epochs=100是总训练轮数。行人检测这类单类目标，如果数据集质量好，50 轮左右就能看到效果收敛，100 轮属于预留空间；batch=8是批次大小。8GB 显存的 GTX 1660 Ti 上跑yolov8s用batch=8是安全的；只有 CPU 就用batch=4，不然内存先爆；imgsz=640是输入图像尺寸。如果数据集中行人大都是小目标，升到 960 或 1280 会显著提升查全率，但训练时间成倍增加；patience=15是早停耐心值。验证集 mAP 连续 15 轮不涨就自动停止，这是防过拟合和防时间浪费的好东西。
但这里还有个更值得讲的参数，就是热词里大家反复琢磨的freeze。freeze=10表示冻结前 10 层不更新梯度。这个参数在两种场景特别有效：一是你的数据集很小（比如只有几百张行人图），预训练特征足够通用，只训练最后检测头即可，能极大减少过拟合；二是你想先快速验证数据标注有没有问题，不跑完整的反向传播链路。
yolo detect train data=data.yaml model=yolov8s.pt epochs=50 batch=8 imgsz=640 freeze=10如果是行人检测这种与 COCO 预训练类别高度重合的任务，freeze=10的效果比较微妙——因为它预训练就识别过 person，你冻结浅层相当于只让深层适应你的特定场景。我自己的偏好是：先用freeze=10跑 30 轮看 loss 能不能降到一个合理区间，能降再解冻全模型精调。这个策略在标注质量不高的数据上特别管用，能避免模型前期就被噪声标注带偏。
3.3 画损失函数曲线图：别再截图训练日志了
训练跑起来之后，很多人喜欢盯着终端里的 loss 数字发呆。YOLOv8 其实在训练结束后会自动生成results.png存在runs/detect/train_pedestrian/目录下，里面包括训练 loss、验证 loss、mAP 等全套曲线。但这个图的问题在于它是全部训练完成后才画的，训练中途无法实时查看，且样式固定不方便写进论文或汇报。
我自己习惯在训练时直接用ultralytics提供的回调函数记录指标，再用 Matplotlib 画自己的损失曲线图。做法是在训练脚本里加上callbacks：
from ultralytics import YOLO import matplotlib.pyplot as plt import numpy as np train_loss_list = [] val_loss_list = [] def on_train_batch_end(trainer): train_loss_list.append(trainer.loss.item()) def on_val_end(trainer): val_loss_list.append(trainer.metrics.get("val/loss", 0)) model = YOLO("yolov8s.pt") model.add_callback("on_train_batch_end", on_train_batch_end) model.add_callback("on_val_end", on_val_end) model.train(data="data.yaml", epochs=100, batch=8, imgsz=640) plt.figure(figsize=(10, 5)) plt.plot(train_loss_list, label="train loss") plt.plot(val_loss_list, label="val loss") plt.xlabel("iteration") plt.ylabel("loss") plt.legend() plt.savefig("loss_curve.png", dpi=150)这段代码的细节在val/loss这个键上：不同版本的 ultralytics 对验证指标的命名有过变化，如果你打印trainer.metrics发现没有这个键，可以先print(trainer.metrics.keys())查看实际键名。trainer.loss.item()取的是当前 batch 的加权总损失（box loss + cls loss + dfl loss 之和），如果你想分别画三分量，需要拆开访问。这个脚本在你换数据集或调参时都要跑，写一次能一直复用。
3.4 训练中断了怎么办：断点续训与 yaml 权重加载
训练跑到一半断电、显存溢出或者被人 Ctrl+C，这种事情撞上一次就长记性。YOLOv8 默认每轮结束都会在runs/detect/train_pedestrian/weights/下存一份last.pt，这个文件就是后悔药。
yolo detect train data=data.yaml model=runs/detect/train_pedestrian/weights/last.pt epochs=100 batch=8 imgsz=640注意这里的逻辑：把model参数从${yolov8s.pt}换成last.pt，训练会从断点处继续，而且会保留优化器状态，不需要把这个文件当成从头预训练来用。epochs=100的意思是总轮数不是“还要跑 100 轮”，所以你得自己算好剩余轮数。这个细节很多人栽过：断点后续跑，发现没两轮就停了，因为总的epochs数已经跑满。训练中断时先看一眼runs/detect/train_pedestrian/args.yaml里记录的原参数，再把epochs改成合理值，这是标准操作。
4. 行人检测项目的坑比想象中多：避坑排查最常见的五个翻车点
4.1 训练 loss 不降反升：先查学习率，再查标注，最后查数据增强
现象：训练集 loss 前 10 轮降得还行，到第 20 轮开始震荡上升，验证集 mAP 纹丝不动。
原因：这个现象八成出在学习率上。YOLOv8 默认初始学习率是lr0=0.01，使用余弦退火调度。如果你的数据集很小、batch 又小，梯度噪声大，默认学习率直接让参数在最优解附近来回蹦，loss 自然不收敛。另一个隐蔽原因是标注类别与data.yaml的names对不上，比如标注文件里类别索引是1但names只有["person"]一项，索引越界后 PyTorch 不会直接报错，但 loss 会在某个值附近横盘。
解决：用小学习率起步，lr0=0.001配合warmup_epochs=5，先跑通再调大。标注问题用脚本检查所有 label 文件里的 class id 是否都在[0, nc-1]范围内：
import os label_dir = "data/labels/train" max_cls = 0 for fname in os.listdir(label_dir): with open(os.path.join(label_dir, fname), "r") as f: for line in f: cls = int(line.split()[0]) max_cls = max(max_cls, cls) print("最大类别索引:", max_cls)如果输出值等于或大于nc，说明标注文件里有脏数据，直接定位到文件修掉即可。这是我做数据集校验时一定先跑的脚本，成本两分钟但能省你一天排查时间。
4.2 小目标漏检严重：不是模型不行，是输入分辨率拖了后腿
现象：验证集 mAP > 50%，但实际测试图片里远处的小行人一个都没框出来。
原因：行人检测最典型的场景是监控摄像头，人离得远，在 640x640 的输入下可能只有 20x40 像素。YOLOv8s 的特征图下采样到 1/32，也就是 20x40 的目标在 40x40 的特征层上只剩一个点，特征信息几乎消失。
解决：把imgsz从 640 升到 1280，推理时用相同的imgsz参数。代价是训练时间和显存翻倍。如果机器扛不住 1280，另一个方案是限制目标尺度范围：统计你的标注里目标宽高的像素分布，把占多数的小目标区间找出来，训练时关闭大目标数据增强（scale=0.5），减少对大目标的过拟合。我在多个行人检测项目里反复验证过：提升输入分辨率是提升小目标最粗暴有效的手段，没有之一，比换任何注意力模块都稳。
4.3 CPU 训练慢到怀疑人生：瓶颈不在计算，在线程与内存分配
现象：Ubuntu CPU 机器上训练，epochs=100的预估时间显示 30 多个小时，CPU 占用率却只有 40%。
原因：PyTorch 默认只是用较少的线程跑算子，数据加载的num_workers在 YOLOv8 里默认是 8，如果 CPU 核数不够或内存不足，反而會卡在数据读取上，GPU 会等数据（CPU 环境上则是算子闲置）。“CPU 占用率低”的直接原因是线程数被限制住了。
解决：环境变量里开 OMP 线程数，并把数据加载进程调小：
OMP_NUM_THREADS=8 yolo detect train data=data.yaml model=yolov8s.pt epochs=50 batch=8 imgsz=640 workers=4这里workers=4比默认 8 更保守，避免内存瓶颈。CPU 环境下的通用取舍是：线程数开到物理核数的一半到三分之二，数据加载进程控制在 4 个以内。如果还嫌慢，减少batch到 4 或换yolov8n.pt起步会是更立竿见影的方案，n 型模型参数量只有 s 型的三分之一，推理速度差接近两倍。
4.4 推理时框的位置全偏了：OpenCV 读图与 YOLO 推理的通道顺序陷阱
现象：训练完成，模型精度正常，但用 OpenCV 读取图片直接送入模型，检测框全歪到左上角。
原因：YOLOv8 的 predict 接口对输入图片有预处理要求（RGB 格式和归一化），而cv2.imread读出来是 BGR。直接混用通道等于把 R 和 B 换了顺序，模型学到的颜色特征全部错位，输出置信度低且框偏移。
解决：推理统一用 YOLO 自带的predict传入图片路径，让它自己做预处理。如果非要自己写预处理循环，在送入前加一行img = cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。另一个更隐蔽的相关坑是：predict接口返回的boxes.xyxy坐标是基于原图尺寸的，而如果你做了imgsz=1280的缩放，拿到的坐标又会被缩放回原图，别自己再多乘一次比例。这个坑我见过不止一个人在博客里踩到，写了半天自定义后处理，结果发现框架全处理完了。
4.5 模型在 GPU 机器上训练的能在 CPU 上推理，但 CPU 上训的模型在 GPU 上表现异常
现象：在 CPU 环境训练完，换到带 CUDA 的机器上推理，精度反而掉了 1~2 个百分点。
原因：这不是玄学，大概率是你 CPU 训练时用了不同的batch，导致 BatchNorm 的 running mean/var 估计有偏移；或训练时解冻层数少，特征提取器与检测头的适配只对特定数据分布有效。本质是训练与推理环境不一致造成的 domain gap。
解决：在训练命令里加一个batch参数时遵循“推理时用训练时的 batch 约数”的原则，同时固定在训练完成的同一环境下做验证。跨机器评估模型时，导出 ONNX 固定网络结构再跑推理，能减少环境差异带来的随机性。
5. 推理验证与迭代方向：一次完整的检测链路能告诉你什么
5.1 拿视频逐帧跑推理：把模型放进真实场景的第一课
行人检测项目最终要面对的是视频流或者摄像头，而不是单张图片。所以训练完模型后的第一个验证动作，我用的一定是拿一段真实场景视频跑逐帧推理。这一步能把模型在连续帧上的稳定性暴露出来——单张图上看起来不错的检测框，放在视频里可能出现目标丢失、框抖动、误检闪烁。
下面这段代码是固定套路：
from ultralytics import YOLO import cv2 model = YOLO("runs/detect/train_pedestrian/weights/best.pt") cap = cv2.VideoCapture("test_video.mp4") fourcc = cv2.VideoWriter_fourcc(*"mp4v") out = cv2.VideoWriter("result.mp4", fourcc, 25, (int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)), int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)))) while True: ret, frame = cap.read() if not ret: break results = model.predict(frame, imgsz=640, conf=0.35, verbose=False) if results[0].boxes is not None: frame = results[0].plot() # 自带画框功能 out.write(frame) cap.release() out.release()这段代码的关键参数是conf=0.35，这也是行人检测场景里比较常用的阈值。阈值设太高（0.7 以上）会让远距离目标大量漏检；设太低（0.1）又会出现大量误检，尤其在背景复杂的户外场景。视频工程还涉及cap.read()读取不到帧时的退出条件——在真实项目里往往还需要加一个断线重连逻辑。代码里的results[0].plot()是 YOLOv8 自带的画框函数，返回叠加了检测结果的 BGR 图像，直接交给VideoWriter即可。
5.2 量化你的模型表现：mAP、精准率和召回率的正确阅读方式
验证环节除了肉眼观察视频效果，必须有量化指标。YOLOv8 训练结束后会在验证集上输出一组指标，常见的有mAP50、mAP50-95、precision和recall。行人检测这个场景，我一般更看重recall：漏掉一个行人比误检一个非行人严重得多。所以调试方向是尽量保证 confidence 阈值较低时也能稳定框出远处目标。
如果你跑验证命令：
yolo detect val model=runs/detect/train_pedestrian/weights/best.pt data=data.yaml imgsz=640输出里会有一行Speed: 0.6ms pre-process, 5.2ms inference, 1.8ms postprocess。这些时间值是部署到边缘设备前的心算依据：如果 5.2ms 的推理时间是在 RTX 3060 上测的，换到 RK3588 的 NPU 上通常乘以 10 到 20 倍。所以不要只看精度指标，速度指标决定了你的模型能不能做成实时系统。
5.3 后续改进方向：从行人检测到多类别检测的拓展路径
当你把行人检测这个单一类别跑通后，下一步大概率是往多类别延展，比如行人 + 车辆 + 非机动车。这里有个架构选择问题：是扩展nc让一个模型检测所有类别，还是为每个类别独立训练一个模型再融合结果？在算力充足的情况下，我的建议是直接扩展nc——多类别联合训练能让特征提取器学到更好的通用语义，尤其行人和车辆在空间分布上有关联，单一模型可以共享这些特征。如果你用的还是这份 rar 里的代码，只需改data.yaml的names和nc，重新标注数据即可。
具体到改造，一般保留原来的训练脚本，只调整数据加载部分以及输出层适配。YOLOv8 的检测头是解耦的，类别数变化只会影响最后一个分类分支的维度，内部的特征提取层不需要改动。这也正是 YOLOv8 相比 YOLOv5 在工程上更友好的一个点。
我自己在接收这类项目包时有个习惯：先跑一个epochs=3的迷你训练，确认代码链路通、loss 在降，再放大到完整训练。这个习惯帮我少踩了无数个“跑了一晚上发现数据集路径读错”的坑。遇到再复杂的项目包，记住核心方法论：数据先验证、环境再隔离、参数做记录、推理做量化。每一步都留好日志和 checkpoint，迭代才有据可依。
希望这套从解压到部署的思路能帮到你，少走点我当年走过的弯路。
本文还有配套的精品资源，点击获取
