📚 课程目录第3章 TensorRT核心概念

3、TensorRT核心概念：TensorRT的构建期与运行期、引擎（Engine）、上下文（Context）、执行模式（同步/异步）

在开始编写调度代码之前，必须先厘清TensorRT的运行时模型。很多初学者将“构建引擎”和“执行推理”混为一谈，导致在多模型共享GPU时出现显存泄漏、上下文冲突或CUDA流使用错误。本章从构建期与运行期的职责划分出发，深入解析引擎（Engine）与上下文（Context）的生命周期关系，并对比同步与异步执行模式在资源占用和延迟表现上的本质差异。理解这些概念是后续实现多模型并发调度的地基。

上图展示了TensorRT两个阶段的完整生命周期。构建期负责将训练好的模型（如ONNX）转换为高度优化的推理引擎，这个过程包括层融合、精度校准（FP16/INT8）、内核自动调优等耗时操作。运行期则负责加载引擎并执行推理。需要特别注意的是，引擎（Engine）是线程安全的、可共享的只读对象，而上下文（Context）是每个执行流独立的状态容器。理解这一区别，是设计多模型调度器的前提。

3.1 构建期与运行期的职责边界

核心原理

构建期（Build Phase）的输入是模型定义和权重，输出是一个经过深度优化的ICudaEngine对象。在这个阶段，TensorRT会执行以下关键操作：

图优化：将网络中的卷积、BN、激活层融合为单一内核，减少kernel启动开销。
精度选择：根据配置使用FP32、FP16或INT8，其中INT8需要额外的校准数据集。
显存规划：分析各层张量的生命周期，复用显存池，减少峰值显存占用。
内核自动调优：为每个算子选择最适合当前GPU架构的kernel实现。

运行期（Runtime Phase）则相对轻量：它反序列化引擎文件，创建执行上下文，绑定输入输出张量，然后通过同步或异步方式提交计算任务。运行期不涉及任何图优化，因此启动速度极快。

  关键判断方法：如果模型结构或权重发生变化，必须重新走构建期；如果只是输入数据变化，则只需在运行期重复执行。在多模型共享GPU场景中，通常的做法是在服务启动时一次性构建所有引擎，然后常驻显存，运行期只负责调度执行。

案例拆解：构建期耗时与显存峰值

假设我们有一个ResNet-50模型，使用TensorRT 8.6在NVIDIA A10 GPU上构建FP16引擎。构建过程耗时约15秒，峰值显存占用约2.3GB（包括临时张量和调优缓存）。而引擎文件本身只有约105MB。如果每次请求都重新构建引擎，显然不可接受。因此，生产环境必须将构建产物序列化到磁盘（.engine文件），运行时直接反序列化加载。

阶段	耗时	显存占用	是否可序列化	线程安全
构建期（Builder）	秒级~分钟级	高（临时缓冲）	否	否（单线程）
引擎（Engine）	毫秒级加载	中（权重+元数据）	是（.engine文件）	是（只读）
上下文（Context）	微秒级创建	低（工作空间）	否	否（每线程独立）

常见误区：不要试图在多个线程中共享同一个ExecutionContext。Context内部保存了中间张量地址、动态形状信息等可变状态，并发调用会导致数据竞争和CUDA错误。正确做法是：一个Context绑定一个线程（或一个CUDA流），引擎可以全局共享。

3.2 引擎（Engine）与上下文（Context）的生命周期管理

核心原理

ICudaEngine是构建期的最终产物，它包含了网络的计算图、权重、算子内核以及显存池的分配策略。引擎本身不保存任何输入输出数据，也不包含执行状态。你可以将引擎理解为“一份静态的施工图纸”。

IExecutionContext则是基于引擎创建的“施工队”。每次执行推理时，Context负责分配工作空间、绑定输入输出地址、维护动态形状的维度信息，并实际调用CUDA内核。同一个引擎可以创建多个Context，每个Context独立执行，互不干扰。

操作流程：多模型共享GPU的标准初始化

// 伪代码：多模型引擎加载与上下文创建
// 1. 构建期（仅一次）
for (model_path : model_list) {
    IBuilder* builder = createInferBuilder(logger);
    INetworkDefinition* network = builder->createNetwork();
    // ... 解析ONNX，填充network ...
    IBuilderConfig* config = builder->createBuilderConfig();
    config->setFlag(BuilderFlag::kFP16);
    ICudaEngine* engine = builder->buildSerializedNetwork(*network, *config);
    // 保存到磁盘：engine->serialize()
}

// 2. 运行期（服务启动时）
std::vector<ICudaEngine*> engines;
std::vector<IExecutionContext*> contexts;
for (auto& path : engine_files) {
    ICudaEngine* eng = runtime->deserializeCudaEngine(data, size);
    engines.push_back(eng);
    // 为每个引擎创建2个Context（对应2个CUDA流）
    contexts.push_back(eng->createExecutionContext());
    contexts.push_back(eng->createExecutionContext());
}

经验提醒：在显存充足的情况下，可以为每个模型创建多个Context，配合多个CUDA流实现模型内部的并发。但要注意，每个Context会额外占用约几十到几百MB的工作空间（取决于模型大小和动态形状范围）。在显存受限时，优先保证每个模型至少一个Context，再考虑并发度。

案例拆解：显存不足时的Context复用策略

某AI平台需要同时部署YOLOv5（目标检测）和BERT（文本分类）。GPU为T4（16GB显存）。初始方案为每个模型创建4个Context，结果发现显存溢出。分析后发现：YOLOv5的Context工作空间约800MB，BERT约1.2GB，4+4个Context共占用8GB，加上引擎权重和CUDA上下文，已接近极限。

优化方案：将Context数量调整为YOLOv5×2、BERT×2，并采用请求级调度——当检测请求密集时，BERT的Context空闲等待；反之亦然。同时开启CUDA内存池复用（cudaMemPoolSetAttribute），将Context工作空间从显存池中分配，而非每次独立申请。调整后峰值显存降至13.8GB，且吞吐量仅下降约7%。

方案	Context数量	峰值显存	吞吐量（QPS）	结论
初始方案	4+4	16.2GB（溢出）	—	不可行
优化方案	2+2	13.8GB	215	可行，延迟P99=42ms
极端方案	1+1	11.2GB	168	显存安全但并发不足

风险提示：Context的创建不是免费的。每个Context创建时会在GPU上分配工作空间，如果频繁创建/销毁Context（例如每次请求都新建），会导致CUDA内存碎片化，并增加延迟。推荐使用Context池技术，预先创建固定数量的Context，用队列管理空闲/忙碌状态。

3.3 同步执行模式（Synchronous Execution）

核心原理

同步执行使用executeV3()方法（旧版为execute()或executeV2()）。调用后，CPU线程会阻塞，直到GPU完成所有计算并返回。同步模式的特点是：

简单可靠：无需管理CUDA流和事件，代码逻辑清晰。
隐式同步：TensorRT内部会调用cudaStreamSynchronize，确保所有内核执行完毕。
低吞吐：在等待GPU计算时，CPU处于空闲状态，无法同时准备下一批数据。

适用场景

同步模式适合单模型、低并发、延迟敏感的场景，例如实时交互式推理（单次请求延迟要求<50ms）。在多模型共享GPU时，如果使用同步模式，必须为每个模型分配独立线程，否则一个模型的执行会阻塞其他模型的启动。

// 同步执行示例
void* inputBuffer;  // 已分配的GPU显存
void* outputBuffer;
context->setTensorAddress("input", inputBuffer);
context->setTensorAddress("output", outputBuffer);
context->executeV3(stream);  // 注意：同步模式也需要传入流
cudaStreamSynchronize(stream);  // 确保完成
// 此时outputBuffer中的数据可用

  关键细节：即使使用executeV3，TensorRT仍然要求传入一个CUDA流。同步模式只是说CPU会等待，但计算仍然在指定的流上执行。如果传入的是默认流（0号流），则与设备上其他操作存在隐式同步。

3.4 异步执行模式（Asynchronous Execution）

核心原理

异步执行使用enqueueV3()方法。调用后立即返回，CPU线程可以继续执行其他任务，GPU在后台异步计算。异步模式的核心优势在于流水线并行：CPU可以提前准备下一批输入数据、执行预处理、或调度其他模型的推理任务。

异步模式必须配合CUDA流（cudaStream_t）使用。每个Context绑定一个流，所有内核在该流上按序执行。通过多流并发，可以实现多个模型（或多个Context）在GPU上的时间片重叠。

操作流程：异步多模型调度框架

// 异步执行示例（多模型共享GPU）
cudaStream_t streamA, streamB;
cudaStreamCreate(&streamA);
cudaStreamCreate(&streamB);

// 模型A的Context绑定streamA，模型B的Context绑定streamB
contextA->enqueueV3(streamA);
contextB->enqueueV3(streamB);

// CPU不等待，继续做其他工作
preprocessNextBatch();

// 在需要结果时同步
cudaStreamSynchronize(streamA);
cudaStreamSynchronize(streamB);
// 此时两个模型的结果都已就绪

维度	同步执行	异步执行
API	executeV3()	enqueueV3()
CPU阻塞	是（直到GPU完成）	否（立即返回）
CUDA流	必须传入，但内部同步	必须传入，且依赖流管理
多模型并发	需多线程，线程阻塞浪费	单线程可驱动多流
延迟	单请求延迟更低（无调度开销）	可能略高（有事件/同步开销）
吞吐量	低（CPU等待）	高（CPU与GPU重叠）
编程复杂度	低	高（需管理流、事件、内存屏障）

常见误区：异步不等于“更快”。如果只有一个模型且请求是串行的，异步模式不会提升单次延迟。异步的真正价值在于重叠——当GPU执行模型A时，CPU可以预处理模型B的输入，或者启动模型C的轻量计算。在多模型共享GPU场景中，异步是必须的，否则GPU空闲率会非常高。

3.5 多模型共享GPU的调度模式选择

核心原理

基于上述概念，多模型共享GPU有三种典型调度模式：

串行模式：所有模型共用一个CUDA流，按优先级排队执行。实现简单，但GPU利用率低。
多流并行模式：每个模型（或每个Context）绑定独立CUDA流，通过流事件实现依赖管理。GPU可以同时执行多个模型的内核，但需要注意资源竞争。
混合模式：将模型分为延迟敏感型和吞吐型，前者使用同步+高优先级流，后者使用异步+低优先级流。

案例拆解：混合调度实战

某自动驾驶公司需要在Orin平台上同时运行：感知模型（YOLOv5s，FP16，延迟要求<30ms）和定位模型（语义分割，INT8，延迟要求<100ms）。初始方案为两个模型各分配一个Context，使用默认流同步执行，结果感知模型延迟达到45ms，不达标。

分析过程：通过Nsight Systems分析发现，分割模型占用GPU时间过长，且与感知模型在同一流上串行执行。感知模型实际计算只需12ms，但等待分割模型完成导致总延迟45ms。

优化操作：

为感知模型创建高优先级流（cudaStreamCreateWithPriority，优先级-5）。
为分割模型创建低优先级流（优先级0）。
感知模型使用异步enqueueV3，分割模型使用异步enqueueV3。
在感知模型的输出事件上设置cudaStreamWaitEvent，确保分割模型不会抢占感知模型的关键内核。

结果对比：感知模型P99延迟降至22ms，分割模型P99延迟为85ms，均满足要求。GPU利用率从61%提升至78%。

复盘经验：多模型调度的核心不是“让所有模型同时跑”，而是控制时间片的分配。CUDA流优先级是粗粒度控制，更精细的控制需要借助CUDA Graph或TensorRT的setStream机制。在Orin这类嵌入式GPU上，显存带宽往往是瓶颈，盲目增加并发度可能导致内核互相等待内存访问，反而降低吞吐。

  总结：构建期与运行期的分离是TensorRT高性能的基础。引擎是静态资产，可序列化、可共享；上下文是动态执行环境，必须按并发度独立创建。同步模式适合低并发延迟敏感场景，异步模式是多模型共享GPU的必选方案。在实际工程中，推荐采用“引擎池 + Context池 + 多CUDA流”的组合架构，通过优先级流和事件机制实现精细调度。