TensorRT核心组件：Builder、Network、Engine、Context

TensorRT 的推理生命周期由四个核心组件串联：Builder（构建器）、Network（网络定义）、Engine（引擎）和 Context（执行上下文）。理解这四个组件的职责边界与协作方式，是掌握 TensorRT 编程模型的关键。它们并非简单的“层层调用”关系，而是分别对应了编译期与运行期两个截然不同的阶段。

核心原理：两阶段四组件

TensorRT 将深度学习模型的部署拆分为两个阶段：构建阶段（离线）与推理阶段（在线）。Builder 和 Network 服务于构建阶段，负责将训练好的模型（如 ONNX、PyTorch 导出的权重）转换为优化后的推理引擎；Engine 和 Context 则服务于推理阶段，负责加载引擎并执行计算。

关键区别：Builder 和 Network 是“一次性”的，它们只在构建引擎时存在，构建完成后即可销毁。Engine 和 Context 则是“持久化”的，Engine 可序列化保存为 .trt 文件，Context 则每次推理时创建，负责管理 GPU 上的实际计算资源。

四个组件的协作关系如下图所示。构建阶段从 Network 定义开始，Builder 读取网络结构并执行层融合、精度校准、内核自动调优等优化，最终生成 Engine。推理阶段则从 Engine 创建 Context，Context 持有 GPU 显存中的权重和激活缓冲区，通过 enqueue 方法提交计算任务。

方法流程：从模型文件到推理引擎

构建一个可用的 TensorRT 推理程序，通常遵循以下流程。每一步都对应上述组件的具体操作：

创建 Builder：调用 createInferBuilder(logger) 获取 Builder 实例。Builder 负责查询设备能力、设置工作空间大小、选择精度策略。
创建 Network：通过 builder.createNetworkV2(EXPLICIT_BATCH) 创建网络定义对象。推荐使用显式批处理模式，以便处理动态形状。
解析模型：使用 ONNX Parser 或手动 API 将模型层添加到 Network 中。此时网络只是“图定义”，尚未分配任何 GPU 资源。
配置构建选项：设置 BuilderConfig，包括 FP16/INT8 精度、动态形状范围、工作空间大小（setMemoryPoolLimit）等。
构建引擎：调用 builder.buildSerializedNetwork(network, config) 生成序列化引擎。此过程耗时较长，可能涉及多次内核自动调优。
反序列化引擎：在推理程序中，通过 Runtime 加载 .trt 文件，得到 ICudaEngine 对象。
创建 Context：engine.createExecutionContext() 创建执行上下文。每个 Context 拥有独立的中间激活缓冲区，可并行处理多个输入流。

// 构建阶段核心代码（伪代码）
IBuilder* builder = createInferBuilder(logger);
INetworkDefinition* network = builder->createNetworkV2(1U);
// 使用 ONNX parser 填充 network
builder->setMaxBatchSize(1); // 旧接口，新版本推荐动态形状
builder->setFp16Mode(true);
builder->setMaxWorkspaceSize(1 << 30); // 1GB
ICudaEngine* engine = builder->buildCudaEngine(*network);
// 序列化保存
std::ofstream file("model.trt", std::ios::binary);
file.write(engine->serialize().data(), engine->serialize().size());

案例场景：动态形状与多 Context 并发

在实际部署中，最典型的场景是动态形状（Dynamic Shape）推理。例如，一个目标检测服务需要处理不同分辨率的输入图片。此时，Network 定义中需要将输入维度设置为 -1（动态维度），并在 BuilderConfig 中指定优化范围：

// 动态形状配置
config->setProfileStream(profile);
profile->setDimensions("input", OptProfileSelector::kMIN, Dims4(1, 3, 224, 224));
profile->setDimensions("input", OptProfileSelector::kOPT, Dims4(1, 3, 640, 640));
profile->setDimensions("input", OptProfileSelector::kMAX, Dims4(1, 3, 1280, 1280));

推理时，每次请求可能使用不同的输入尺寸。Context 需要根据实际输入形状调用 setInputShape() 重新绑定缓冲区。这里有一个重要陷阱：同一个 Engine 可以创建多个 Context，但每个 Context 在同一时刻只能处理一个形状。如果服务需要同时处理不同尺寸的请求，建议为每种常见尺寸创建独立的 Context，或者使用线程池串行化同尺寸请求。

性能建议：Context 的创建成本较低（毫秒级），但 GPU 显存分配成本较高。如果推理延迟敏感，建议在服务启动时预创建 2~4 个 Context 并复用，避免每次请求都重新分配显存。

误区与复盘：常见错误及规避

误区	后果	正确做法
将 Builder 和 Network 保留到推理阶段	浪费内存，且 Builder 占用大量 CPU 资源	构建完成后立即销毁 Builder 和 Network，只保留 Engine
多个线程共享同一个 Context	数据竞争导致推理结果错误或崩溃	每个线程创建独立的 Context，或使用互斥锁保护
忽略 Engine 的序列化版本兼容性	TensorRT 版本升级后无法加载旧引擎	使用 `deserializeCudaEngine` 时检查返回空指针，并保留构建时的 TensorRT 版本信息
动态形状下未调用 setInputShape	推理时使用默认形状，导致维度不匹配	每次 enqueue 前根据实际输入调用 `setInputShape`

复盘一个真实案例：某团队在部署 BERT 模型时，将 Engine 构建完成后未销毁 Builder，导致 GPU 显存被额外占用约 500MB。更严重的是，他们在多线程推理时共用了同一个 Context，导致约 5% 的请求返回错误结果。修复方案很简单：为每个线程创建独立 Context，并在构建完成后立即释放 Builder 和 Network 对象。

特别注意：Engine 对象本身是线程安全的，可以多个线程共享；但 Context 不是。如果使用 CUDA Graph 捕获推理过程，还需要确保 Context 在捕获期间不被其他线程干扰。

最后，理解这四个组件的生命周期管理是避免内存泄漏的关键。推荐使用 RAII 模式（如 std::unique_ptr 配合自定义 deleter）管理这些对象的释放。TensorRT 的 C++ API 中，所有对象都通过 destroy() 方法释放，但在现代 C++ 中，更推荐使用 nvinfer1::UniquePtr<T> 智能指针类型，它会在作用域结束时自动调用 destroy()，从而避免手动管理带来的遗漏风险。