1、TensorRT基础概念：什么是TensorRT，为什么需要它，核心组件介绍（Builder、Engine、Context）
好，咱们直接开讲。很多刚接触TensorRT的同学，第一反应往往是——这玩意儿到底是个啥？我直接用PyTorch或者TensorFlow推理不行吗？
嗯，说实话，我刚开始也有这个疑问。直到我在一个自动驾驶项目里，发现模型在GPU上跑得挺欢，但帧率就是上不去，延迟还忽高忽低。后来一查，发现模型里各种动态shape、冗余算子，GPU根本没吃饱。这时候，TensorRT就派上用场了。
1.1 什么是TensorRT？
TensorRT，说白了，是NVIDIA推出的一个深度学习推理优化引擎。它不是用来训练模型的，而是专门负责把训练好的模型“调教”一番，让它在NVIDIA GPU上跑得更快、更省资源。
你可以把它想象成一个编译器。就像C++代码需要编译成机器码才能高效运行一样，你的模型也需要TensorRT“编译”一下，才能发挥GPU的真正实力。
核心目标： 在保证精度的前提下，最大化推理吞吐量，最小化延迟。
我个人习惯把TensorRT看作一个“性能榨干机”。它通过一系列技术手段，比如层融合、精度校准、内核自动调优，把模型里那些冗余、低效的部分统统干掉。
1.2 为什么需要TensorRT？
你可能会问：“我用原生框架推理不也挺好吗？” 好，但不够好。我举个例子。
我在一个安防项目中，需要同时处理16路视频流。如果用原生PyTorch，GPU利用率只有30%左右，显存却快爆了。换成TensorRT后，同样的硬件，GPU利用率飙到80%，延迟还降了一半。为什么会有这么大差距？
原因主要有几点：
- 框架开销大： PyTorch/TensorFlow在推理时，有很多动态图、调试信息、内存管理开销。这些在训练时是必要的，但在推理时就是累赘。
- 算子效率低： 很多框架的算子实现并不是针对特定GPU架构优化的。TensorRT会为你的显卡（比如A100、T4、Orin）选择最优的kernel实现。
- 内存浪费： 原生框架往往为每个张量分配独立内存，而TensorRT会做内存池化、复用，减少显存占用。
我的经验： 如果你做的是边缘端部署（比如Jetson系列），TensorRT几乎是必选项。因为边缘设备资源有限，不优化根本跑不动。
1.3 核心组件介绍
TensorRT有三个核心组件，你必须要搞明白：Builder、Engine、Context。它们之间的关系，有点像“工厂、产品、工人”。
1.3.1 Builder（构建器）
Builder是负责“生产”Engine的。它读取你的模型文件（比如ONNX），然后进行一系列优化，最后生成一个序列化的Engine。
Builder的配置非常关键。你想想看，同样的模型，不同的配置，出来的Engine性能可能天差地别。
// C++示例：创建Builder并配置
nvinfer1::IBuilder* builder = nvinfer1::createInferBuilder(logger);
nvinfer1::IBuilderConfig* config = builder->createBuilderConfig();
// 设置工作空间大小（显存上限）
config->setMemoryPoolLimit(nvinfer1::MemoryPoolType::kWORKSPACE, 1 << 30); // 1GB
// 设置精度模式
config->setFlag(nvinfer1::BuilderFlag::kFP16); // 启用FP16
// 设置动态shape优化范围
const int batchSize = 1;
const int inputH = 224;
const int inputW = 224;
nvinfer1::IOptimizationProfile* profile = builder->createOptimizationProfile();
profile->setDimensions("input", nvinfer1::OptProfileSelector::kMIN, nvinfer1::Dims4{1, 3, inputH, inputW});
profile->setDimensions("input", nvinfer1::OptProfileSelector::kOPT, nvinfer1::Dims4{1, 3, inputH, inputW});
profile->setDimensions("input", nvinfer1::OptProfileSelector::kMAX, nvinfer1::Dims4{1, 3, inputH, inputW});
config->addOptimizationProfile(profile);
注意： Builder的构建过程非常耗时，尤其是第一次。我建议你把生成的Engine序列化保存为.plan文件，下次直接加载，避免重复构建。
1.3.2 Engine（引擎）
Engine是Builder产出的“成品”。它是一个优化后的、可执行的推理模型。Engine是平台相关的，也就是说，你在A100上生成的Engine，不能直接拿到T4上用。
Engine里包含了什么？
- 优化后的网络结构（层融合后的计算图）
- 每个算子的最优kernel实现
- 权重数据（可能已经做了量化）
- 内存管理策略
Engine本身是线程安全的，但它的执行需要Context。
// 加载序列化的Engine
std::ifstream file("model.plan", std::ios::binary);
std::stringstream buffer;
buffer << file.rdbuf();
std::string plan = buffer.str();
nvinfer1::IRuntime* runtime = nvinfer1::createInferRuntime(logger);
nvinfer1::ICudaEngine* engine = runtime->deserializeCudaEngine(plan.data(), plan.size());
1.3.3 Context（执行上下文）
Context是Engine的“执行者”。它负责管理一次推理过程中的所有状态，包括输入输出缓冲区、CUDA流、临时内存等。
这里有个关键点：一个Engine可以创建多个Context。这意味着你可以用同一个优化好的Engine，同时处理多个推理请求，每个Context独立运行。
// 创建Context
nvinfer1::IExecutionContext* context = engine->createExecutionContext();
// 设置输入输出缓冲区
void* buffers[2];
cudaMalloc(&buffers[0], inputSize);
cudaMalloc(&buffers[1], outputSize);
// 执行推理
context->enqueueV2(buffers, stream, nullptr);
cudaStreamSynchronize(stream);
避坑指南： 我曾经犯过一个错误——在多个线程里共享同一个Context。结果发现推理结果时对时错，排查了半天。后来才意识到，Context不是线程安全的。正确的做法是：每个线程创建自己的Context，或者用线程池管理Context。
1.4 三者关系总结
咱们用一张表来理清它们的关系：
| 组件 | 角色 | 生命周期 | 线程安全 |
|---|---|---|---|
| Builder | 模型优化器，生成Engine | 构建阶段，用完可销毁 | 否（单线程构建） |
| Engine | 优化后的模型，可执行 | 长期存在，可序列化 | 是（可共享） |
| Context | 推理执行者，管理状态 | 每次推理创建或复用 | 否（每个线程独立） |
嗯，简单来说就是：Builder造车（Engine），Context开车。车可以给多个司机开，但每个司机得有自己的驾驶舱（Context）。
1.5 一个完整的推理流程
最后，我带你走一遍完整的流程，这样你心里就有谱了：
- 准备模型： 把训练好的模型导出为ONNX格式。
- 创建Builder： 配置优化参数（精度、工作空间、动态shape范围）。
- 构建Engine： Builder读取ONNX，进行优化，生成Engine。
- 序列化保存： 把Engine保存为.plan文件，下次直接加载。
- 创建Runtime： 反序列化加载Engine。
- 创建Context： 为每个推理线程创建独立的Context。
- 执行推理： 绑定输入输出缓冲区，调用enqueueV2。
- 后处理： 从输出缓冲区取结果。
你看，其实没那么复杂。核心就是理解Builder、Engine、Context这三个组件各自干什么活。搞清楚了，后面遇到各种坑，你也能快速定位问题出在哪个环节。
下一章，咱们会深入聊聊ONNX模型导出时那些容易踩的坑。到时候见。