4. TensorRT模型构建：Builder、Config、Network、Engine、Context五大核心对象详解
说实话，刚接触TensorRT那会儿，我被这五个对象搞得有点晕。Builder、Config、Network、Engine、Context……名字长得像，功能又相互关联。后来我花了整整一周，把每个对象的生命周期和职责理清楚了。今天咱们就掰开揉碎了讲。
这五个对象，说白了就是一条流水线：你告诉Builder要做什么，Builder拿着Config去构建Network，Network编译成Engine，Engine再实例化出Context来真正干活。嗯，就是这么个链条。
4.1 Builder：总指挥
Builder是TensorRT的入口。我个人习惯叫它“包工头”——它不亲自干活，但所有事情都得它点头。
核心职责：创建Network、加载模型、调用编译流程。
// 创建Builder
nvinfer1::IBuilder* builder = nvinfer1::createInferBuilder(logger);
// 创建Network
nvinfer1::INetworkDefinition* network = builder->createNetworkV2(flags);
// 创建Config
nvinfer1::IBuilderConfig* config = builder->createBuilderConfig();
// 构建Engine
nvinfer1::IHostMemory* serializedModel = builder->buildSerializedNetwork(*network, *config);你看，Builder就像个调度中心。它创建了Network和Config，然后调用buildSerializedNetwork把两者揉在一起，生成最终的Engine。
避坑指南：我曾经在项目中同时创建了多个Builder，结果内存直接爆了。Builder是重量级对象，一个进程里只创建一个就够了。别学我犯傻。
4.2 Config：配置清单
Config就是Builder的“配置清单”。你告诉Builder：我要用FP16、我要设置工作空间大小、我要开启DLA……这些全写在Config里。
| 配置项 | 说明 | 我的建议 |
|---|---|---|
| setFlag(BuilderFlag::kFP16) | 启用FP16推理 | 精度允许就开，速度提升明显 |
| setMemoryPoolLimit | 设置工作空间上限 | 别设太小，否则层融合会受限 |
| setMaxWorkspaceSize | （旧版API） | 新版用setMemoryPoolLimit替代 |
| setProfilingVerbosity | 控制日志详细程度 | 调试时开kVERBOSE，上线用kLAYER_NAMES_ONLY |
你想想看，Config就像做菜的调料单。同样的食材（Network），调料不同（Config），做出来的菜（Engine）味道天差地别。
注意：Config必须在调用buildSerializedNetwork之前设置完毕。一旦开始构建，Config就变成只读了。我刚开始不知道，改了半天Config发现没生效，排查了一下午……
4.3 Network：模型蓝图
Network就是你的模型结构。它记录了每一层的输入输出、权重、偏置、激活函数……说白了，就是模型的“骨架”。
构建Network有两种方式：
- 解析器方式：用ONNX解析器或UFF解析器直接加载模型文件
- 手动构建：用addConvolution、addPooling等API一层层搭
// 方式一：ONNX解析器（推荐）
nvinfer1::IOnnxParser* parser = nvinfer1::createOnnxParser(*network, logger);
parser->parseFromFile("model.onnx", 1);
// 方式二：手动构建（不推荐，除非你有特殊需求）
auto convLayer = network->addConvolutionNd(*input, 32, {3, 3}, weight, bias);
convLayer->setStrideNd({1, 1});
convLayer->setPaddingNd({1, 1});我个人强烈建议用ONNX解析器。手动构建太容易出错了——我记得有一次手动搭ResNet，搭到第50层时发现前面某层的维度算错了，那叫一个崩溃。
关键点：Network只是“蓝图”，不是“房子”。它不负责推理，只负责描述模型长什么样。
4.4 Engine：编译后的可执行体
Engine是TensorRT最核心的产出。它把Network和Config融合在一起，经过层融合、精度校准、内存优化等一系列操作，生成一个高度优化的推理引擎。
Engine有两个特点：
- 可序列化：可以保存为文件，下次直接加载，省去重新编译的时间
- 平台相关：不同GPU架构生成的Engine不通用（比如T4和A100的Engine不能互换）
// 序列化保存
nvinfer1::IHostMemory* serializedModel = builder->buildSerializedNetwork(*network, *config);
std::ofstream file("model.engine", std::ios::binary);
file.write((char*)serializedModel->data(), serializedModel->size());
// 反序列化加载
nvinfer1::IRuntime* runtime = nvinfer1::createInferRuntime(logger);
nvinfer1::ICudaEngine* engine = runtime->deserializeCudaEngine(serializedModel->data(), serializedModel->size());经验之谈：我曾经在项目上线前忘了保存Engine，每次启动都要重新编译。你知道ResNet-152编译一次多久吗？整整15分钟！后来我学乖了，编译完立刻序列化保存，启动时直接加载，秒级完成。
4.5 Context：真正的执行者
Context是Engine的“实例”。一个Engine可以创建多个Context，每个Context独立管理自己的推理状态和内存。
为什么需要Context？因为Engine是只读的、线程安全的。但推理需要读写操作——分配输入输出缓冲区、执行推理、同步CUDA流……这些都得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);多流并发：一个Engine + 多个Context = 多流并发推理。每个Context绑定一个CUDA流，就能同时处理多个请求。这是TensorRT高性能推理的核心玩法，后面章节会详细讲。
4.6 五者关系总结
最后，我用一张图来总结这五个对象的关系：
Builder (包工头)
├── 创建 Network (蓝图)
├── 创建 Config (配置单)
└── 调用 buildSerializedNetwork
└── 生成 Engine (可执行体)
└── 实例化 Context (执行者)
└── 执行 enqueueV2 (真正干活)你想想看，这五个对象各司其职，缺一不可。Builder负责统筹，Config负责配置，Network负责描述，Engine负责优化，Context负责执行。搞清楚了它们的职责边界，TensorRT的整个推理流程就清晰了。
生命周期管理：记得按顺序释放资源。先销毁Context，再销毁Engine，最后销毁Builder和Runtime。顺序反了会报错，我亲眼见过同事因为这个导致cudaErrorInvalidValue，排查了整整两天。
嗯，这五个对象讲完了。下一章咱们聊聊如何用这些对象搭建一个完整的推理流水线，到时候我会手把手带你写一个可用的推理示例。