3、Batch推理核心概念：Batch Size、吞吐量（Throughput）、延迟（Latency）、并发（Concurrency）的定义与权衡
在多路视频GPU部署场景中，Batch推理是提升硬件利用率的核心手段。视频流通常以多路并发形式接入，每一路视频帧在解码后形成独立的推理请求。如果每一帧都单独触发一次GPU推理，不仅会造成GPU计算资源的大量闲置，还会因频繁的kernel启动和显存分配而引入额外开销。Batch推理的核心思想是将多个独立请求在时间上对齐、在数据维度上拼接，形成一次批量计算，从而摊薄固定开销、提升单位时间内的处理能力。然而，Batch Size的增大并非没有代价——它会直接影响延迟、吞吐量和并发能力，四者之间存在复杂的权衡关系。理解这些概念的本质及其相互制约，是设计高效多路视频推理系统的前提。
3.1 核心概念精确定义
Batch Size指一次GPU推理中并行处理的样本数量。在多路视频场景中，一个样本通常对应一帧图像或一个视频片段。例如，Batch Size=8意味着GPU同时处理8帧来自不同或相同视频流的图像。Batch Size直接决定了计算矩阵的维度，影响GPU中Tensor Core、CUDA Core的利用率。
吞吐量（Throughput）衡量系统在单位时间内完成的推理次数或处理的帧数，常用FPS（Frames Per Second）或路数×帧率表示。在多路视频系统中，吞吐量通常表述为“同时处理多少路视频且每路达到多少帧率”，例如“16路1080p@25fps”。吞吐量是系统整体能力的体现，受GPU算力、显存带宽、Batch Size、数据预处理效率共同影响。
延迟（Latency）指从单个推理请求进入系统到获得结果之间的时间间隔，通常以毫秒（ms）为单位。在多路视频场景中，延迟包括：图像解码时间、预处理时间、排队等待时间、GPU计算时间、后处理时间。其中排队等待时间与Batch策略密切相关——如果为了凑满一个Batch而等待更多帧，就会增加延迟。
并发（Concurrency）指系统同时承载的推理请求数量或视频路数。并发与Batch Size不同：并发描述的是系统“同时服务多少独立任务”，而Batch Size描述的是“一次计算合并了多少任务”。高并发可以通过多Batch、多Stream、多进程等方式实现，但受限于GPU显存容量和计算资源。
关键区别：并发是“系统层面”的指标，描述同时服务的请求数；Batch Size是“单次计算层面”的指标，描述一次kernel启动处理的数据量。两者可以相互配合：高并发系统通常需要较大的Batch Size来摊薄开销，但也可以通过多个小Batch并行（如CUDA Stream）实现。
3.2 四者权衡关系与判断方法
在实际部署中，四者并非独立变量，而是相互制约的。核心权衡关系如下：
| 关系对 | 影响方向 | 原因分析 | 典型场景 |
|---|---|---|---|
| Batch Size → 吞吐量 | 正相关（非线性） | 固定开销（kernel启动、显存分配）被摊薄，计算密集型算子利用率提升 | Batch从1增至8，吞吐量可能提升3-5倍 |
| Batch Size → 延迟 | 负相关（延迟增大） | 需要等待更多帧凑批，且单次计算时间随Batch增大而增加 | Batch=1延迟5ms，Batch=16延迟25ms |
| Batch Size → 显存占用 | 正相关 | 中间激活值、临时缓冲区随Batch线性增长 | Batch=4占用2GB，Batch=16占用6GB |
| 并发 → 吞吐量 | 正相关（受限于资源） | 更多路视频提供更多可合并的帧，GPU利用率提升 | 4路提升至8路，吞吐量接近翻倍 |
| 并发 → 延迟 | 负相关（延迟增大） | 排队竞争加剧，每路等待时间变长 | 8路时延迟10ms，32路时延迟30ms |
判断方法：在实际项目中，建议按以下步骤确定最优Batch Size：
- 明确约束条件：确定延迟上限（如≤50ms）、显存预算（如10GB）、目标路数（如16路）。
- 测量单帧延迟：在Batch=1时测量基础延迟，作为基准。
- 逐步增大Batch：以2的幂次递增（2、4、8、16、32），记录每个Batch下的吞吐量和延迟。
- 绘制曲线：找到吞吐量增长趋缓的拐点，该点附近即为最优Batch。
- 验证显存：使用
nvidia-smi监控显存占用，确保峰值不超过预算。
3.3 案例拆解：16路视频推理的Batch策略优化
背景与约束：某安防平台需要在一张NVIDIA A10（24GB显存）上部署16路1080p@25fps的视频分析任务，模型为YOLOv5s（FP16精度）。延迟要求：单帧从输入到输出不超过80ms。初始方案采用Batch=1逐帧推理，实测吞吐量仅约120 FPS，远低于16路×25fps=400 FPS的需求。
初始现象：GPU利用率仅35%，显存占用3.2GB，但延迟已高达45ms。分析发现，瓶颈不在计算而在kernel启动开销和CPU预处理瓶颈——每帧独立推理时，CPU需要频繁调用CUDA API，导致GPU大部分时间处于空闲等待状态。
分析过程：通过NVIDIA Nsight Systems分析，发现GPU空闲时间占比达60%，其中约70%的空闲来自kernel启动间隙。将Batch Size从1提升至4后，吞吐量提升至280 FPS，GPU利用率升至70%，延迟增至55ms。继续提升至Batch=8，吞吐量达到420 FPS，GPU利用率85%，延迟68ms。Batch=16时，吞吐量仅450 FPS（增长趋缓），但显存占用飙升至11GB，延迟达到95ms，超出约束。
实际操作步骤：
- 将Batch Size设为8，采用动态batching策略：每积累8帧或等待5ms即触发推理，避免延迟过大。
- 使用CUDA Stream将预处理（解码、缩放）与GPU计算重叠，隐藏部分延迟。
- 开启TensorRT的FP16优化，进一步降低单Batch计算时间。
结果对比：最终方案在Batch=8+动态batching下，吞吐量稳定在400-420 FPS，满足16路@25fps需求，延迟控制在72ms以内，显存占用8.5GB，GPU利用率82%。相比初始方案，吞吐量提升3.5倍，延迟仅增加27ms，在可接受范围内。
风险与代价：动态batching引入了调度复杂度，需要处理帧到达不均匀的情况；同时，Batch=8时显存占用接近预算的70%，后续若需增加路数需考虑模型压缩或使用更小Batch。
经验总结：Batch Size并非越大越好。当吞吐量增长趋缓而延迟和显存仍在上升时，即达到“收益递减点”。对于视频分析场景，建议将延迟预算的60%分配给GPU计算，40%留给排队和预处理，以此反推Batch Size上限。
3.4 常见误区与总结复盘
误区一：盲目追求大Batch。许多开发者认为Batch越大吞吐量越高，忽略了延迟和显存约束。在实时视频分析中，过大的Batch会导致帧等待时间过长，造成“旧帧”分析结果失去时效性。例如，Batch=32时延迟可能超过200ms，对于需要实时告警的场景完全不可接受。
误区二：混淆并发与Batch。并发是系统同时服务的请求数，Batch是单次计算合并的请求数。高并发不一定需要大Batch——可以通过多CUDA Stream实现多个小Batch并行，但这种方式对GPU利用率提升有限，且增加了调度复杂度。
误区三：忽略CPU预处理瓶颈。在多路视频场景中，图像解码、缩放、归一化等操作通常在CPU上完成。如果CPU处理速度跟不上GPU推理速度，即使增大Batch也无法提升整体吞吐量。此时需要优化预处理管线（如使用NVDEC硬件解码、JPEG解码加速）或采用异步流水线。
误区四：静态Batch策略。视频流的帧到达速率是波动的（场景切换、网络抖动），固定Batch会导致空闲等待或队列积压。推荐使用动态batching：设置最大Batch Size和最大等待时间，两者先到先触发，兼顾吞吐与延迟。
风险提示：在调整Batch Size时，务必监控显存峰值。某些模型（如Transformer-based检测器）的中间激活值随Batch增长呈超线性增长，可能导致OOM。建议使用torch.cuda.max_memory_allocated()或nvidia-smi的显存历史曲线进行监控。
总结复盘：Batch推理的核心在于“以时间换空间、以空间换吞吐”。在实际部署中，应遵循以下原则：
- 先测量后调优：使用Profiler工具获取GPU利用率、kernel耗时、显存曲线，避免拍脑袋决定Batch Size。
- 延迟预算驱动：根据业务需求设定延迟上限，反推最大可接受的Batch Size和排队时间。
- 动态优于静态：采用动态batching策略，在帧到达不均匀时自动调整Batch大小，平衡吞吐与延迟。
- 全链路优化：Batch推理只是其中一环，需与硬件解码、预处理流水线、后处理并行化协同设计。