1. 课程导入：多流并发的价值、应用场景与学习路径

在深度学习推理的工程化落地中，我们经常遇到这样的困惑：GPU 的利用率明明不高，但单路请求的延迟却已经无法满足业务要求；或者，当多路视频流同时接入时，推理服务的吞吐量急剧下降，甚至出现抖动。这些问题的根源，往往不在于模型本身的算力消耗，而在于我们如何组织 GPU 上的计算任务。TensorRT 作为 NVIDIA 官方的高性能推理引擎，其底层执行模型天然支持异步与并发，但绝大多数开发者仍然停留在"单流（Single Stream）"的思维定式中。本章作为《TensorRT 多流并发》的开篇，将系统阐述多流并发的核心价值、典型应用场景，并为你规划一条从原理到实战的清晰学习路径。

上图展示了从单流执行到多流并发的核心演进逻辑。左侧是当前大多数推理服务的真实状态：请求按到达顺序排队，GPU 依次执行每个请求的预处理、推理和后处理。这种模式的问题在于，当某个请求正在进行耗时的 Host-to-Device（H2D）数据拷贝时，GPU 计算单元处于空闲状态；而当 GPU 执行 Kernel 计算时，PCIe 总线又闲置了。多流并发的本质，就是通过多个 CUDA Stream 让不同请求的拷贝、计算、同步阶段在时间上重叠，从而"填满"GPU 的每一个执行单元。

1.1 多流并发的核心价值：从"算得快"到"用得满"

要理解多流并发的价值，我们首先要打破一个常见的认知误区：GPU 推理的瓶颈往往不是算力，而是数据搬运和任务调度。以一张典型的 ResNet-50 推理为例，在 FP16 精度下，GPU 计算本身可能只需要 1-2 毫秒，但加上输入图像的 H2D 拷贝、输出结果的 Device-to-Host（D2H）拷贝、以及 CPU 端的预处理，整个端到端延迟可能达到 5-8 毫秒。在这 5-8 毫秒中，GPU 计算单元的实际利用率可能不足 50%。

多流并发通过以下三个机制解决这个问题：

• 计算与拷贝重叠：当一个 Stream 在执行 Kernel 计算时，另一个 Stream 可以同时进行 H2D 数据拷贝。PCIe 总线和 GPU 计算单元是独立的硬件资源，它们可以并行工作。
• 多任务并行调度：GPU 的 SM（Streaming Multiprocessor）可以被多个 Kernel 分时共享。当单个 Kernel 的线程数不足以占满所有 SM 时，多个 Stream 的小 Kernel 可以同时驻留，提高 SM 利用率。
• 延迟隐藏：对于在线推理服务，多流并发可以将单个请求的等待时间"隐藏"在其他请求的处理时间中，从而在宏观上降低平均响应时间。

1.2 典型应用场景：哪里需要多流并发？

并非所有推理场景都需要多流并发。对于单请求、大模型、极低延迟（如 <5ms）的场景，多流并发可能反而增加调度开销。但在以下三类场景中，多流并发是刚需：

场景类型	业务特征	并发需求	多流收益
实时交互推理	在线推荐、智能客服、图像搜索	高并发（100-1000 QPS），低延迟（P99 < 50ms）	通过多流隐藏单请求的拷贝延迟，提升吞吐
多路视频分析	安防监控、智慧交通、工业质检	16-64 路视频流同时接入	每路视频分配独立 Stream，互不阻塞
批量离线服务	内容审核、图像生成、离线特征提取	吞吐量最大化，延迟不敏感	多 Stream 配合动态 Batch，榨干 GPU 算力

以多路视频分析为例，假设一台服务器需要处理 32 路 1080p 视频流，每路视频经过解码后产生 25 FPS 的帧。如果使用单流模式，所有帧必须排队等待，当某一路视频出现场景复杂度突增时，会导致后续所有视频帧的推理延迟飙升。而采用多流并发，每路视频独占一个 CUDA Stream，即使某一路发生计算高峰，其他 Stream 的推理任务也能正常调度，实现了故障隔离和延迟稳定。

1.3 课程目标与学习路径：从原理到实战的四个阶段

本课程的目标是让你不仅"会用"TensorRT 的多流 API，更能"设计"出适合自己业务场景的并发架构。整个学习路径分为四个阶段，每个阶段都对应着不同的能力要求：

1. 阶段一：理解 CUDA Stream 与异步执行模型（第 1-5 章）。掌握 Stream 的本质、事件（Event）同步机制、以及 TensorRT 的 IExecutionContext 如何与 Stream 绑定。这是所有并发设计的地基。
2. 阶段二：掌握 TensorRT 多流编程范式（第 6-15 章）。学习如何创建多个 ExecutionContext、如何为每个 Stream 分配独立的 GPU 显存池、以及如何通过 enqueueV3 等异步 API 提交推理任务。重点解决"多流之间如何共享权重"和"如何避免显存冲突"两个核心问题。
3. 阶段三：进阶优化与性能调优（第 16-25 章）。深入探讨动态 Shape 下的多流适配、多流与 CUDA Graph 的结合、以及如何通过 Nsight Systems 分析多流执行的时间线。这一阶段的目标是让你能够定位并发瓶颈，并做出针对性优化。
4. 阶段四：工程化落地与案例实战（第 26-30 章）。以真实项目为背景，完成从单流到多流的改造、多路视频推理服务的搭建、以及高吞吐批量服务的压测与调优。最终形成一套可复用的多流并发设计模式。

1.4 常见误区与总结复盘

在开始正式学习之前，我们先澄清几个常见的认知误区，这些误区会在后续章节中反复出现：

• 误区一：Stream 越多越好。实际上，Stream 数量超过 GPU 的并发执行能力后，反而会增加上下文切换和调度开销。一般建议 Stream 数量不超过 GPU 上 SM 数量的 2-4 倍。
• 误区二：多流并发等于多线程。CUDA Stream 是 GPU 端的执行队列，与 CPU 线程没有直接对应关系。一个 CPU 线程可以管理多个 Stream，一个 Stream 也可以被多个 CPU 线程提交任务。
• 误区三：只要用了多流，延迟就会降低。多流并发主要提升的是吞吐量和 GPU 利用率，对于单个请求的延迟，如果 GPU 资源已经饱和，多流反而可能增加排队延迟。需要根据业务指标（QPS 优先还是延迟优先）来权衡。
• 误区四：忽略同步开销。多流之间的同步（Event 等待、Stream 依赖）是有代价的。过度同步会抵消并发收益，而同步不足则可能导致数据竞争。找到"恰到好处"的同步点，是并发设计的艺术。

本章总结：多流并发是 TensorRT 高性能推理的核心手段，它通过让 GPU 的拷贝引擎、计算单元、调度器并行工作，将硬件资源利用率推向极限。在实时推理、多路视频、批量服务三大场景中，多流并发都是不可或缺的技术底座。接下来的课程，我们将从 CUDA Stream 的底层原理开始，一步步构建你的多流并发知识体系。