1. 课程导入
随着城市治理、工业质检、智慧交通、安防监控等场景的规模化落地，视频分析已从“单路算法验证”走向“多路并发生产”。一个中等规模的智慧园区往往需要同时接入 32～128 路摄像头，每路视频以 25～30 FPS 持续产生数据流。若按每路视频每秒 2～4 次 AI 推理计算，单台 GPU 服务器需要承载每秒上百次的模型推理请求。这种量级下，单纯堆叠显卡或简单调用 API 已无法满足成本与延迟要求，必须从系统层面设计 Batch 推理策略与显存管理方案。本章作为全课程的开篇，将梳理多路视频 GPU 部署的行业背景、核心瓶颈与学习路径，帮助读者建立全局技术视图。
上图展示了多路视频 GPU 部署的三个核心维度：行业驱动、核心挑战与学习路径。行业侧，视频分析已从单路演示走向大规模生产；挑战侧，延迟、吞吐与显存三者相互制约；学习侧，需要从显存管理、Batch 策略到工程化部署层层递进。下面将逐一展开分析。
1.1 行业背景：为什么多路视频部署成为刚需
过去五年，视频数据量呈指数级增长。以一座中型城市为例，交通摄像头、治安监控、城管探头等各类视频源合计可达数万路。传统做法是将视频回传至中心服务器，由 CPU 集群进行解码和推理，但 CPU 的并行计算能力有限，单路 1080p 视频的 AI 推理（如目标检测）在 CPU 上可能需要 200～500ms，完全无法满足实时要求。GPU 的引入改变了这一局面——其数千个 CUDA 核心可同时处理多路视频的矩阵运算，将单路推理时间压缩到 10～30ms。然而，GPU 部署并非“插卡即用”，多路并发时显存带宽、Batch 大小、解码流水等都会成为新的瓶颈。
从行业实践看，典型的部署场景包括：
- 智慧安防：一个小区或园区部署 50～200 路摄像头，需要实时识别人员入侵、车辆违停、烟火事件等，对延迟要求极高（<100ms）。
- 工业质检：产线上多个工位同时拍摄产品图像，每路相机每秒触发 5～10 次检测，要求高吞吐且不能漏检。
- 自动驾驶测试：路测车辆搭载多路摄像头和激光雷达，需要在车载 GPU 上完成多传感器融合推理，功耗和显存受限。
- 直播与内容审核：视频平台需要对海量直播流进行实时审核，单台 GPU 服务器需处理 20～50 路流。
这些场景的共同特点是：路数多、并发高、资源有限。如果每路视频独占一个推理进程或独占显存，GPU 资源利用率极低。例如，一块 24GB 显存的 RTX 3090，单路模型推理仅占用 2GB 显存，若只跑一路，显存利用率不足 10%。多路部署的核心价值就在于通过 Batch 推理和显存复用，将 GPU 的算力与存储资源“榨干”。
1.2 核心挑战：延迟、吞吐与显存的三重博弈
多路视频 GPU 部署面临三个相互耦合的挑战，理解其内在关系是后续优化的基础。
| 挑战维度 | 定义 | 典型指标 | 与其它维度的关系 |
|---|---|---|---|
| 延迟（Latency） | 从视频帧到达 GPU 到推理结果输出的时间 | P50 ≤ 50ms，P99 ≤ 100ms | Batch 越大延迟越高（排队等待），但吞吐提升 |
| 吞吐（Throughput） | 单位时间内处理的视频帧数或路数 | 单卡 ≥ 200 FPS（检测模型） | 吞吐提升依赖 Batch 合并，但受显存容量限制 |
| 显存（Memory） | GPU 显存容量与带宽的占用情况 | 占用率 ≤ 80%，无 OOM | Batch 越大显存占用越高，需平衡 |
这三者构成了一个“不可能三角”：追求极低延迟会牺牲吞吐，追求高吞吐会推高延迟和显存占用，而显存不足则直接限制 Batch 大小。实际工程中，需要根据业务优先级做权衡。例如，安防场景更看重延迟（报警要快），而离线视频分析更看重吞吐（批量处理）。
具体到技术层面，挑战体现在：
- 视频解码与预处理瓶颈：多路视频流需要先解码为 YUV 或 RGB 帧，再缩放、归一化。CPU 软解会占用大量资源，GPU 硬解（NVDEC）虽快但需要显存缓冲，且解码输出与推理输入之间需要高效衔接。
- Batch 动态调度难度：各路视频帧到达 GPU 的时间不同步，若固定 Batch 大小，要么等待凑满 Batch 导致延迟增加，要么 Batch 不满导致算力浪费。需要设计动态 Batching 策略。
- 显存碎片化：频繁分配/释放不同大小的张量会导致显存碎片，长期运行后可用显存减少，甚至触发 OOM。
- 多路并发下的资源竞争：多路视频共享 GPU 的 SM（流多处理器）、显存带宽、PCIe 带宽，若不加控制，某一路的突发流量会影响其它路。
1.3 学习路径总览：从显存管理到 Batch 推理再到工程落地
本课程共 30 章，围绕“多路视频 GPU 部署”这一主题，按“基础→进阶→实战”三层递进设计。本章作为第 1 章，先给出整体地图，后续章节将逐一深入。
课程学习路径分为四个阶段：
- 阶段一：显存管理基础（第 2～8 章）——讲解 GPU 显存架构、张量内存分配、显存池化、碎片整理、内存复用等。这是多路部署的“地基”，没有合理的显存管理，Batch 再大也会 OOM。
- 阶段二：Batch 推理策略（第 9～16 章）——深入 Batch Size 对吞吐/延迟的影响、动态 Batching 算法、多流并发、CUDA Graph 等。这是提升 GPU 利用率的核心手段。
- 阶段三：工程化部署（第 17～24 章）——涵盖 TensorRT 优化、推理服务框架（Triton）、视频解码流水线、多卡负载均衡、容错与监控。
- 阶段四：综合实战与调优（第 25～30 章）——以真实项目为案例，从需求分析、方案设计、性能测试到上线运维，完整走一遍多路视频部署流程。
每一章都包含理论讲解、代码示例、性能对比和常见坑点，读者可按顺序学习，也可根据实际需求跳转。建议在学习过程中准备一块 NVIDIA GPU（≥8GB 显存），并安装好 CUDA、TensorRT 和 Python 环境，以便动手验证。
1.4 案例拆解：从单路到 32 路的性能演进
为了直观说明多路部署的必要性，这里给出一个简化案例。某安防项目需要部署 32 路 1080p 视频流，使用 YOLOv5s 模型（输入 640×640），单路推理延迟约 15ms（GPU：RTX 3080，10GB 显存）。
初始方案（单路独占）：为每路视频启动一个 Python 进程，每个进程加载一份模型权重（约 1.2GB），并独占 2GB 显存用于推理缓冲。32 路共需 32×2GB = 64GB 显存，远超 10GB 限制，方案不可行。
改进方案（Batch 推理）：将 32 路视频帧收集到共享队列，每凑满 8 帧组成一个 Batch 送入 GPU 推理。模型权重只加载一份（1.2GB），Batch 推理时显存占用约 3.5GB（含激活值）。32 路视频按 25 FPS 计算，总帧率 800 FPS，Batch=8 时每秒需 100 次推理，单次 Batch 推理耗时约 40ms（含预处理），GPU 利用率约 80%，显存占用 4.7GB，完全可行。
下表对比了两种方案的关键指标：
| 指标 | 单路独占（32进程） | Batch=8（共享模型） |
|---|---|---|
| 显存占用 | 64GB（不可行） | 4.7GB |
| GPU 利用率 | 约 15%（每路仅用少量算力） | 约 80% |
| 平均延迟 | 15ms（单路） | 40ms（Batch 排队+推理） |
| 系统吞吐 | 32×25=800 FPS（理论） | 800 FPS（实际） |
| 工程复杂度 | 低（但不可用） | 中（需队列与调度） |
这个案例揭示了多路部署的核心矛盾：单路独占虽然延迟低，但显存和算力浪费严重；Batch 推理虽然增加了单次延迟，但整体吞吐和资源利用率大幅提升。实际工程中，延迟增加可以通过优化预处理、使用异步推理、调整 Batch 大小来缓解。后续章节将详细讲解如何实现动态 Batch、如何管理显存池、如何用 TensorRT 加速。
1.5 常见误区与本章小结
在开始后续学习前，先澄清几个常见误区，避免走弯路：
- 误区一：显存越大越好——显存容量只是基础，显存带宽和利用率同样关键。一块 24GB 显存但利用率只有 20% 的卡，不如一块 12GB 但利用率 80% 的卡。
- 误区二：Batch 越大吞吐越高——当 Batch 超过一定阈值（如 32 或 64），GPU 计算资源饱和，继续增大 Batch 只会增加延迟和显存，吞吐不再提升。
- 误区三：多路视频就是多线程——Python 多线程受 GIL 限制，无法真正并行 GPU 推理。正确做法是使用多进程 + 队列，或直接使用 C++/CUDA 实现。
- 误区四：忽略视频解码——很多团队只优化推理，却忽略解码瓶颈。NVDEC 硬解虽然快，但解码输出到推理输入的拷贝（Device-to-Device）也可能成为瓶颈。