2. YOLO检测模型基础

在进入 TensorRT 部署实战之前，必须首先建立对 YOLO 模型本身的深度认知。很多部署工程师在转换模型时遇到“输出维度对不上”“后处理结果错位”等问题，根源往往不在于 TensorRT 的 API 使用，而在于对 YOLO 模型输出张量的语义理解不够精确。本章将系统梳理 YOLO 系列从 v5 到 v9 的演进脉络，剖析其“单阶段、锚点/无锚点、多尺度预测”的核心思想，并重点拆解模型输出张量的结构与解析方法——这是后续编写高效后处理代码的理论基石。

YOLO 模型演进与输出张量结构总览 YOLOv5 锚点+FPN YOLOv8 无锚点+解耦头 YOLOv9 PGI+可逆分支 YOLOv10 NMS-Free 输出张量结构（以 YOLOv8 为例，输入 640×640） P3 / 80×80 小目标 · 通道数 64 P4 / 40×40 中目标 · 通道数 128 P5 / 20×20 大目标 · 通道数 256 每个尺度输出形状: [1, 4+1+80, H, W] = [1, 85, H, W] 4 (bbox) + 1 (obj) + 80 (COCO类) = 85 通道

上图展示了 YOLO 系列从 v5 到 v10 的核心演进路径，以及以 YOLOv8 为代表的输出张量结构。可以看到，虽然不同版本的网络结构有所差异，但其输出层设计都遵循“多尺度特征图 + 通道维度编码检测信息”的统一范式。理解这一范式，是后续在 TensorRT 中正确解析模型输出的关键。

2.1 YOLO 系列演进：从 v5 到 v9 的关键技术跃迁

YOLO（You Only Look Once）系列模型自 2016 年诞生以来，始终在“实时性”与“准确性”之间寻找最佳平衡点。对于部署工程师而言，了解各版本的技术差异，有助于根据实际业务场景（如边缘设备算力限制、目标尺寸分布、实时性要求）选择最合适的模型版本。

2.1.1 YOLOv5：工业部署的基石

YOLOv5 虽然不是官方 Ultralytics 团队（YOLOv8 的开发团队）的正式版本，但因其工程化程度极高，成为工业界应用最广泛的检测模型之一。其核心贡献在于：

  • 锚点机制（Anchor-Based）：在训练前通过 K-Means 聚类算法在训练集上统计出预设的锚点框尺寸，每个尺度特征图对应 3 组锚点。例如在 COCO 数据集上，P3 层锚点为 [10,13]、[16,30]、[33,23]。
  • CSPDarknet 骨干网络：借鉴 CSPNet 的跨阶段局部连接设计，在减少计算量的同时保持梯度信息流动，有效缓解了深层网络的梯度消失问题。
  • 输出结构：每个尺度特征图的输出通道数为 3 × (5 + num_classes)，其中 3 表示锚点数量，5 表示边界框的 4 个坐标参数（x, y, w, h）加 1 个目标置信度（objectness）。
部署提示：YOLOv5 的输出需要结合锚点信息进行解码。在 TensorRT 部署时，通常将解码过程写入自定义插件或使用 GPU 并行计算，避免在 CPU 上进行逐锚点循环，否则会严重拖慢推理速度。

2.1.2 YOLOv8：无锚点与解耦头的革新

YOLOv8 是当前工业界应用最广泛的版本之一，其架构设计对部署非常友好，主要体现在以下三点：

  • 无锚点（Anchor-Free）：彻底摒弃了预设锚点框，改为直接预测目标中心点到特征图网格左上角的偏移量（x, y）以及目标的宽高（w, h）。这一改动大幅简化了后处理逻辑，减少了超参数调优的工作量。
  • 解耦检测头（Decoupled Head）：将分类分支和回归分支分离为两个独立的卷积分支。在 YOLOv5 中，分类和回归共享同一组特征通道，而 YOLOv8 使用两个并行分支，分别输出分类 logits 和边界框回归值，提升了收敛速度和精度。
  • 输出结构：每个尺度特征图的输出通道数为 4 + num_classes（无目标置信度分支）。以 COCO 80 类为例，每个尺度输出 84 个通道。模型直接输出的是解码后的边界框参数（中心点坐标和宽高），无需锚点解码。

2.1.3 YOLOv9：可逆分支与信息瓶颈缓解

YOLOv9 引入了 Programmable Gradient Information（PGI）和 Generalized Efficient Layer Aggregation Network（GELAN）架构，核心目标是解决深层网络中信息丢失的问题。其创新点包括：

  • 可逆分支（Reversible Branch）：在训练时增加一个可逆分支来保留完整的梯度信息，但在推理时该分支可以被移除，因此不会增加部署时的计算量。
  • GELAN 结构：通过高效的层聚合网络设计，在保持轻量级的同时提升了特征融合能力。
  • 部署视角：YOLOv9 的推理图结构与 YOLOv8 类似，输出张量格式也保持一致（无锚点 + 解耦头），因此从 v8 迁移到 v9 的部署代码改动成本较低。

2.1.4 YOLOv10：端到端无 NMS 的探索

YOLOv10 的最大卖点是实现了“无 NMS 推理”（NMS-Free），通过双标签分配策略和一致匹配度量，在训练阶段消除了对 NMS 的依赖。这意味着在部署时可以直接取模型输出的 Top-K 个预测框作为最终结果，省去了 NMS 后处理步骤，进一步提升了端到端推理速度。但需要注意的是，该特性对训练数据的分布较为敏感，在特定场景下精度可能略有下降。

版本 锚点机制 检测头结构 输出通道数（COCO 80类） 后处理复杂度
YOLOv5 Anchor-Based（3组/尺度） 耦合头（共享特征） 3 × (5 + 80) = 255 高（需锚点解码 + NMS）
YOLOv8 Anchor-Free 解耦头（分类/回归分离） 4 + 80 = 84 中（直接解码 + NMS）
YOLOv9 Anchor-Free 解耦头 4 + 80 = 84 中（同 v8）
YOLOv10 Anchor-Free 解耦头 + 一致匹配 4 + 80 = 84 低（可跳过 NMS）

2.2 核心思想：单阶段、多尺度与标签分配

无论 YOLO 版本如何迭代，其核心思想始终围绕“单阶段直接回归”展开。与两阶段检测器（如 Faster R-CNN）先产生候选区域再分类不同，YOLO 将目标检测视为一个端到端的回归问题，在单个卷积神经网络中同时预测所有边界框的位置和类别。

2.2.1 多尺度特征图预测

YOLO 系列采用特征金字塔（FPN/PAN）结构，从骨干网络的不同阶段提取三个不同分辨率的特征图，分别负责检测不同尺寸的目标：

  • P3 层（80×80）：感受野最小，擅长捕捉小目标细节，对应原图中 8×8 像素的区域。
  • P4 层（40×40）：中等感受野，负责中尺寸目标，对应原图中 16×16 像素的区域。
  • P5 层（20×20）：感受野最大，负责大目标，对应原图中 32×32 像素的区域。

这种多尺度设计使得 YOLO 能够同时处理不同大小的物体，但也带来了后处理的复杂性——需要将三个尺度的预测结果合并，并去除重复检测。

2.2.2 标签分配策略

在训练阶段，模型需要知道“哪个锚点/位置负责预测哪个目标”。YOLOv5 使用基于 IoU 的静态分配策略，而 YOLOv8 引入了 TaskAligned Assigner，根据分类得分和回归质量的加权分数动态分配正样本。这一策略虽然主要影响训练过程，但也会间接影响模型输出的分布特性（例如置信度分数的校准程度），部署时需注意。

2.3 输出张量结构深度解析

输出张量的解析是部署中最容易出错的环节。不同框架导出的模型，其输出张量的维度顺序可能不同（NCHW vs NHWC），且不同版本的 YOLO 输出语义也有差异。以下以 YOLOv8 为例，给出标准解析流程。

2.3.1 张量形状与维度含义

假设输入图像为 640×640，经过模型前向推理后，TensorRT 输出的原始张量形状为：

输出张量 1: [1, 84, 80, 80]  # P3 层
输出张量 2: [1, 84, 40, 40]  # P4 层
输出张量 3: [1, 84, 20, 20]  # P5 层

其中：

  • 维度 0（1）：Batch Size，即一次推理的图片数量。
  • 维度 1（84）：通道数，由 4 个边界框回归参数（cx, cy, w, h）和 80 个类别得分组成。
  • 维度 2 和 3（H, W）：特征图的空间尺寸。

在解析时，需要将张量从 NCHW 格式转换为 NHWC 格式（或直接在 GPU 上通过 TensorRT 的 IShuffleLayer 进行重排），以便按空间位置逐像素读取数据。

2.3.2 解码逻辑与坐标映射

YOLOv8 的输出是相对于特征图网格的偏移量，需要转换为原图坐标系下的坐标。转换公式如下：

// 假设特征图尺寸为 grid_h × grid_w，原图尺寸为 img_w × img_h
// 对于特征图上的每个位置 (i, j)，其中 i ∈ [0, grid_h), j ∈ [0, grid_w)

// 1. 计算中心点坐标（相对于特征图）
float cx = (j + output[0][0][i][j]) * stride;  // stride = 原图宽 / grid_w
float cy = (i + output[0][1][i][j]) * stride;

// 2. 计算宽高
float w = output[0][2][i][j] * stride;
float h = output[0][3][i][j] * stride;

// 3. 转换为左上角坐标（用于后续 NMS 或绘图）
float x1 = cx - w / 2.0f;
float y1 = cy - h / 2.0f;
float x2 = cx + w / 2.0f;
float y2 = cy + h / 2.0f;

其中 stride 对于 P3、P4、P5 层分别为 8、16、32。需要注意的是，YOLOv8 输出的宽高是直接预测的值（乘以 stride 后即为原图尺寸），而非像 YOLOv5 那样需要先对锚点宽高做指数变换。

常见陷阱：在 TensorRT 部署时，如果使用 FP16 精度，输出张量中的数值可能存在微小误差。对于边界框坐标，这种误差通常可以忽略；但对于类别得分，如果直接使用 argmax 获取类别 ID，在分数接近时可能产生误判。建议在解析时对类别得分使用 softmax 或直接比较原始 logits（因为 YOLO 训练时使用的是 BCE Loss，输出即为 sigmoid 后的概率值，无需再做 softmax）。

2.4 实战场景：从 PyTorch 导出到 TensorRT 的维度对齐

下面通过一个实际案例，展示在部署过程中如何验证和调整输出张量的解析逻辑。

案例背景：某安防项目需要将 YOLOv8s 模型部署到 Jetson Orin 设备上，使用 TensorRT FP16 推理。模型输入尺寸为 640×640，检测类别为 5 类（人、车、自行车、摩托车、狗）。在完成 TensorRT 引擎构建后，发现检测结果出现严重的坐标偏移，目标框位置明显错位。

排查过程：
  1. 第一步：检查输入预处理。确认图像缩放方式为 letterbox（保持宽高比填充），填充值为 114，且坐标映射时未考虑填充偏移。这是最常见的坐标偏移原因。
  2. 第二步：验证输出张量形状。在 TensorRT 中打印输出维度，确认形状为 [1, 84, 80, 80]、[1, 84, 40, 40]、[1, 84, 20, 20]，与预期一致。
  3. 第三步：对比 PyTorch 输出。使用同一张测试图片，分别运行 PyTorch 模型和 TensorRT 引擎，对比输出张量的数值差异。发现 TensorRT 输出的前 4 个通道（坐标）与 PyTorch 基本一致，但类别通道存在微小偏差。
  4. 第四步：定位问题。最终发现是坐标映射时未考虑 letterbox 的填充区域。原图中目标位于填充区域之外，但映射公式直接使用了特征图坐标乘以 stride，导致坐标偏移。

解决方案：在坐标映射前，先计算填充偏移量 pad_x 和 pad_y，并在最终坐标中减去该偏移量。修正后的映射公式为： 
float x1 = (cx - w / 2.0f - pad_x) / scale;
float y1 = (cy - h / 2.0f - pad_y) / scale;
float x2 = (cx + w / 2.0f - pad_x) / scale;
float y2 = (cy + h / 2.0f - pad_y) / scale;
其中 scale 为原图到 letterbox 后图像的缩放比例。

复盘经验：输出张量的解析必须与预处理流程严格对应。建议在部署初期，使用单张测试图片分别运行原始框架和 TensorRT，逐通道对比输出数值，确保完全一致后再进行后处理开发。

2.5 常见误区与总结复盘

在 YOLO 模型部署中，以下误区需要特别警惕：

  • 误区一：混淆不同版本的输出格式。YOLOv5 需要锚点解码，YOLOv8 不需要；YOLOv5 有 objectness 分支，YOLOv8 没有。直接套用 v5 的后处理代码到 v8 上必然出错。
  • 误区二：忽略 NCHW 与 NHWC 的转换。TensorRT 默认使用 NCHW 布局，但某些自定义插件或 CPU 后处理代码可能期望 NHWC。如果直接按 NHWC 方式读取 NCHW 数据，会导致通道错乱。
  • 误区三：坐标映射未考虑 letterbox 填充。这是导致检测框偏移的最常见原因，尤其是在输入尺寸不是 32 的整数倍时。
  • 误区四：类别得分直接使用 argmax。YOLO 使用 BCE Loss 训练，输出是 sigmoid 后的概率值，但不同类别之间并非互斥（一个目标可能同时属于多个类别）。如果业务场景允许多标签，应使用阈值过滤而非 argmax。

总结：YOLO 模型的部署核心在于“理解输出张量的语义”。建议在动手编写 TensorRT 代码之前，先用 Python 加载原始模型，打印输出张量的形状和数值，手动完成一次解码和 NMS 流程，验证逻辑正确后再迁移到 C++/CUDA 实现。这一前置步骤可以节省大量调试时间。

← 上一章 📖 返回目录 下一章 →