2. GPU基础与视频推理特性
多路视频GPU部署的第一课，不是学会调用某个推理框架，而是先理解GPU的“脾气”。视频推理与传统的图片分类、文本生成有本质区别：它同时包含解码、预处理、推理三个计算特征完全不同的阶段。如果不理解GPU的流式多处理器（SM）调度方式、显存带宽的物理瓶颈，以及Batch（批处理）对计算效率的杠杆效应，后续的部署优化将无从下手。本章从硬件架构出发，剖析视频推理的计算特性，并解释为什么Batch推理是提升GPU利用率的核心手段。
2.1 GPU架构核心：SM与显存带宽
GPU并非一个“大号CPU”，而是一个由大量流式多处理器（Streaming Multiprocessor, SM）组成的并行计算阵列。以NVIDIA Ampere架构的A10为例，它拥有36个SM，每个SM包含128个CUDA Core和4个Tensor Core。CUDA Core负责通用的浮点/整数运算，而Tensor Core则专门加速矩阵乘加运算——这正是深度学习卷积和全连接层的核心操作。
理解SM的关键在于“占用率”（Occupancy）概念。每个SM能同时驻留一定数量的线程块（Thread Block），当某些线程因等待显存数据而阻塞时，SM会立即切换到其他就绪的线程块执行。这种“延迟隐藏”机制是GPU高吞吐量的基石。但这也意味着：如果程序中的访存指令过多，SM大部分时间都在等待数据而非计算，整体效率会急剧下降。
显存带宽是另一个决定性因素。以A10为例，其显存带宽为600GB/s，而PCIe 4.0 x16的带宽仅为32GB/s。视频推理中，每一帧原始图像（例如1920×1080的BGR数据）约6MB，如果每路视频25FPS，单路每秒就需要150MB的显存读写流量。10路视频同时解码并送入预处理，仅帧数据搬运就消耗1.5GB/s的带宽，这还不包括模型权重和中间特征图的访问。因此，显存带宽往往比算力更早成为瓶颈。
2.2 视频解码、预处理与推理的计算特征差异
视频推理链路包含三个计算特征截然不同的阶段，混淆它们会导致优化方向错误。
| 阶段 | 计算类型 | 主要瓶颈 | 典型耗时占比 | 优化手段 |
|---|---|---|---|---|
| 视频解码 | 熵编码、运动补偿、像素重建 | 显存带宽、解码器单元数量 | 20%-30% | NVDEC硬件解码、减少CPU-GPU拷贝 |
| 预处理 | 缩放、色彩空间转换、归一化 | 显存带宽、像素级访存 | 10%-15% | GPU上执行、合并操作、避免多次拷贝 |
| 模型推理 | 卷积、矩阵乘、激活函数 | SM算力、Tensor Core利用率 | 50%-60% | TensorRT优化、Batch推理、FP16/INT8量化 |
视频解码是内存密集型任务。H.264/H.265解码需要参考帧、运动矢量等大量数据，但计算密度低。NVDEC硬件解码器可以并行处理多路视频，但解码后的YUV帧必须写入显存，这直接消耗带宽。预处理阶段同样以访存为主：将YUV转换为RGB、缩放到模型输入尺寸（如640×640）、归一化到[0,1]区间，每一步都涉及全帧数据的读写。如果预处理在CPU上完成，还需要经过PCIe传输，延迟和带宽开销更大。
模型推理则是典型的计算密集型任务。卷积层的计算量（FLOPs）远高于访存量，Tensor Core能高效执行矩阵运算。但推理阶段对数据依赖性强，单帧推理时SM的空闲等待时间较长。Batch推理通过将多帧数据打包成高维张量，让Tensor Core在单位时间内处理更多数据，从而提升计算密度。
2.3 为什么需要Batch推理：从单帧到多帧并行
Batch推理的本质是提高GPU的计算密度。假设一个卷积层处理单张640×640×3的输入，需要执行约1.2 GFLOPs。如果一次处理8张图，总计算量为9.6 GFLOPs，但Tensor Core的矩阵运算单元可以复用权重数据，将计算效率提升近线性。更重要的是，Batch推理减少了内核启动次数和显存访问次数。
以TensorRT为例，当Batch Size从1增加到8时，推理吞吐量通常能提升3-5倍。原因有三：
- 权重复用：同一模型权重在Batch内被多次使用，减少了显存读取次数。
- 内核启动开销摊薄：每次内核启动有约5-10μs的固定开销，Batch越大，单帧分摊的启动成本越低。
- SM流水线填充：单帧推理时，SM中大量线程束（Warp）处于空闲状态；Batch提供了足够的并行度，让所有SM持续忙碌。
但Batch Size并非越大越好。过大的Batch会导致显存溢出，且延迟增加——对于实时视频分析，单帧延迟必须控制在33ms以内（25FPS）。因此，实际部署中需要根据模型大小、显存容量和延迟要求，动态调整Batch Size。
2.4 案例拆解：8路视频从“卡顿”到“流畅”的优化过程
背景与约束：某安防项目需要在单张NVIDIA T4 GPU（16GB显存，256GB/s带宽）上部署8路1080p@25FPS的实时行人检测。初始方案使用OpenCV CPU解码 + PyTorch GPU推理，结果GPU利用率仅35%，CPU满载，视频流频繁丢帧。
初始现象与指标：
- GPU利用率：35%-40%
- CPU利用率：95%以上
- 端到端延迟：120ms（远超33ms要求）
- 丢帧率：15%
分析判断过程：通过NVIDIA Nsight Systems分析发现，CPU解码占用了大量时间，且解码后的YUV帧通过PCIe拷贝到GPU显存，再转换为RGB，这一过程消耗了约40%的显存带宽。推理阶段Batch Size=1，Tensor Core利用率不足20%。
实际操作步骤：
- 将解码迁移到NVDEC硬件解码器，使用FFmpeg的cuvid接口，解码后的帧直接输出到GPU显存。
- 在GPU上使用CUDA核函数完成YUV→RGB转换和缩放，避免CPU参与。
- 将PyTorch模型转换为TensorRT FP16引擎，并设置Batch Size=8。
- 实现动态Batch调度：当视频帧到达时，按时间戳对齐，凑满8帧后统一推理。
结果对比：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| GPU利用率 | 35% | 82% | +134% |
| CPU利用率 | 95% | 20% | -79% |
| 端到端延迟 | 120ms | 28ms | -77% |
| 丢帧率 | 15% | 0% | 完全消除 |
风险与代价：NVDEC解码器在T4上最多支持3路1080p@30FPS，8路需要分两批解码，增加了调度复杂度。TensorRT FP16精度在行人检测任务中mAP下降约0.3%，在可接受范围内。
复盘经验：视频推理优化的核心是“让数据在GPU内部流动”。解码、预处理、推理三个环节必须全部在GPU上完成，并通过Batch推理填满SM流水线。任何一次CPU-GPU拷贝，都是性能杀手。
2.5 总结与部署要点
GPU视频推理的优化，本质上是计算与访存的平衡艺术。SM提供了强大的并行计算能力，但需要足够的数据供给；显存带宽是稀缺资源，必须精打细算。视频解码和预处理是带宽消耗大户，推理是算力消耗大户，Batch推理是连接两者的桥梁。
在实际部署中，建议遵循以下原则：
- 全链路GPU化：从解码到推理，避免CPU参与数据搬运。
- Batch Size动态调整：根据实时帧率波动，动态调整Batch大小，优先保证延迟上限。
- 监控三个核心指标：GPU利用率（反映SM忙碌程度）、显存带宽利用率（反映数据供给效率）、端到端延迟（反映用户体验）。
- 使用TensorRT等优化引擎：自动融合层、选择最优kernel、支持FP16/INT8量化，能额外提升30%-50%的推理性能。