YOLO 为什么能做到实时目标检测

打开一个目标检测演示，摄像头里的行人和汽车被方框圈住，画面还很流畅，很容易让人觉得：这不就是把图片分类模型跑快一点吗？

其实，分类只需要回答“图里有什么”，检测还得回答“有几个、分别在哪里”。一张照片里可能有十几辆车，大小不同，还互相遮挡。模型既要识别类别，又要给出每个目标的位置。

YOLO 能把这件事做得很快，关键不只是网络算得快，而是它把检测任务组织成了适合并行计算的形式。不过，“用了 YOLO”和“系统一定实时”之间，还隔着不少工程细节。

把找位置和认类别放进一次预测

一种直观办法是拿不同大小的窗口在图片上滑动，每个窗口都问一遍：这里有没有车？位置越细、尺度越多，重复计算就越多。

早期 R-CNN 的思路有所改进：先找候选区域，再分别提取特征、判断类别和修正位置。后来的 Faster R-CNN 已经共享了整图特征，不能简单说所有两阶段检测都在反复跑完整网络。两者更核心的区别，是是否保留“生成候选区域，再对候选区域处理”的阶段。

YOLO 把目标检测视为直接预测问题：输入整张图片，网络输出一批边界框及相应的类别信息。多个目标的位置和类别，在一次前向传播里一起计算。

这里的“一次”不是只做一次卷积，更不是完全没有后处理。网络内部仍有许多层，也会产生大量候选预测；它省掉的是独立的候选区域处理阶段，让主要计算形成一条紧凑的数据流。

同一张特征图上的不同位置可以同时参与预测，卷积和矩阵运算又很适合 GPU 并行执行。这才是“只看一次”背后真正有用的部分。

一张特征图，怎么找出多个目标？

可以先把特征图理解成一张保留空间位置的信息地图。原图中的边缘、纹理和物体局部，经过网络处理后，变成不同位置上的特征。

检测头根据这些特征预测边界框和类别。不同空间位置提供不同的预测机会，因此模型并不需要先知道“图片里一共有几个目标”。它先给出候选结果，再按规则筛选。

讲 YOLO 时经常出现“把图片切成网格，每个格子负责目标”的说法。它适合帮助理解原始 YOLO，但不宜当作所有版本的精确实现。原始方案用目标中心所在的网格承担预测责任；后续版本在预测方式、训练时的样本分配以及输出形式上都有变化。

同样，YOLO 也不等于必须使用锚框。部分版本借助预设宽高的 anchor 来预测偏移，另一些采用 anchor-free 设计。是否单独输出 objectness、置信度如何组合，也要看具体实现。

这些变化没有改变一个共同思路：从共享特征中，直接、并行地产生位置和类别预测。

大目标和小目标，不能只用一种尺度

把原图逐步下采样，计算会更省，特征也更容易表达完整物体。但空间细节会随之减少。远处的一辆车，在原图里可能只有十几像素，压缩到较小的特征图后，留下的信息就很有限了。

因此，许多现代 YOLO 使用多尺度特征：较高分辨率的特征图保留更多细节，较低分辨率的特征图具有更大的感受野，更适合表达较大范围的语义信息。不同尺度之间还会进行特征融合。

常见实现可以分成三个部分：

图中的三尺度结构只是常见示意，不代表所有 YOLO 都采用同一套结构。多尺度预测也不是免费提升：它增加了计算和候选数量，但通常比单纯增大整个网络更有针对性。

这也解释了为什么降低输入分辨率能提速，却可能明显损害小目标检测。省下的不只是像素，还包括目标本来就不多的细节。

预测出来的框，为什么还要筛？

同一辆车附近的多个位置，都可能预测出指向它的框。如果原样展示，画面上就会出现一圈重叠矩形。

许多常见 YOLO 实现会先过滤低置信度预测，再用非极大值抑制，也就是 NMS，减少重复框。它通常先保留高分框，再根据框之间的重叠程度，抑制相同类别下的重复预测。

重叠程度常用 IoU 衡量：

IoU = 两个框的交集面积 / 两个框的并集面积

NMS 并不天然知道两个框是不是同一个物体，只是按照分数和重叠关系作判断。人群拥挤时，阈值过严可能误删相邻目标，过松又可能留下重复框。

也不能把 NMS 写成 YOLO 永远必需的一步。有些端到端设计通过训练和输出机制减少重复预测，推理时可以不使用传统 NMS。实际部署时，应按所用模型确认后处理流程。

“实时”要看整条链路

30 FPS 意味着平均每 33.3 毫秒处理一帧。假设一个串行系统的耗时如下，注意这些只是计算示例，并非某个模型的实测成绩：

只看网络推理，12 毫秒似乎对应约 83 FPS；把其他环节算进去，整个系统才约 33 FPS。若再加入网络取流、设备间数据复制或视频编码，结果还会变。

流水线并行可以让多个环节重叠执行，提高吞吐量，但单帧延迟不等于吞吐量的倒数。批量推理也是类似：一次处理多张图片可能让 GPU 更忙，却可能让实时摄像头等待凑齐一批。

因此，看到“几百 FPS”时，至少要确认硬件、输入尺寸、模型规模、推理精度、batch size，以及计时是否包含预处理和后处理。缺少这些条件，数字很难比较。

真要跑快，通常改哪些地方？

实际项目里，模型规模和输入分辨率往往是最直接的两个旋钮。小模型运算更少，大模型通常有更强的表达能力；输入尺寸降低后，主要卷积计算量通常也会明显下降。但实际耗时还受内存访问和硬件利用率影响，不会严格按像素比例缩放。

部署端还可以使用适配硬件的推理引擎，通过算子融合、内存规划等方式减少开销。硬件支持时，FP16 往往能改善速度或显存占用；INT8 量化还需要关注校准数据和精度损失，不能只看文件缩小了多少。

另一个容易忽略的地方是数据搬运。如果每帧都在 CPU 和 GPU 之间来回复制，或者画框、编码占用了大量时间，继续换更小的网络未必能解决问题。

比较实用的做法，是在实际视频源上分别记录解码、预处理、推理、后处理和输出耗时。GPU 执行通常是异步的，独立测量时还要正确同步，否则可能只量到了提交任务的时间。正式统计前做预热，并观察持续运行时的延迟波动，才能看出系统是否稳定。

对实时预览来说，队列也很关键。摄像头每秒来 30 帧，系统只能处理 20 帧，如果一直排队不丢帧，画面可能还在更新，却越来越滞后。允许丢弃旧帧的场景，可以限制队列长度、优先处理新帧；要求逐帧留档分析的任务，则需要另一套吞吐方案。

快，是整套取舍的结果

YOLO 的速度来自几件事的配合：整图特征共享、直接预测、并行计算，以及围绕部署成本设计的网络结构。它不是凭空跳过了识别过程，而是让“找位置”和“认类别”在同一套特征上完成。

代价同样存在。小目标、密集遮挡和复杂背景仍然可能要求更高分辨率、更强模型或专门的数据训练。选型时，比起单独追求最高 FPS，更有意义的问题是：在自己的设备和画面里，检测质量是否够用，处理速度是否跟得上，结果是否足够及时。