2、环境搭建：CUDA、cuDNN、TensorRT版本选择与安装、开发机配置、验证TensorRT基本功能

TensorRT插件自定义开发的第一道门槛，并非代码编写，而是构建一套版本严格匹配、功能可验证的软件栈。CUDA、cuDNN与TensorRT三者之间存在紧密的编译期与运行期依赖关系，版本错配往往导致API符号找不到、算子执行结果错误甚至驱动崩溃。本章将围绕版本选型原则、安装验证流程、开发机配置要点以及TensorRT基本功能验证四个维度展开，帮助学员建立一套可复现、可排障的环境搭建方法论。

2.1 版本选型：理解CUDA、cuDNN与TensorRT的依赖矩阵

核心原理：TensorRT作为推理优化引擎，其编译产物（engine文件）与运行环境强绑定。TensorRT的API头文件在编译期引用了CUDA运行时头文件（cuda_runtime.h）和cuDNN头文件（cudnn.h），因此插件开发时使用的CUDA版本必须与TensorRT构建时使用的CUDA版本一致或兼容。同时，TensorRT运行时会动态加载libcudnn.so和libcublas.so等库，这些库的版本必须满足TensorRT的依赖声明。版本不匹配的典型症状包括：加载engine时提示"could not load library: libcudnn.so.8"、插件注册时出现"undefined symbol"错误，或者推理结果出现NaN。

判断方法：首先确认GPU架构。以当前主流为例，Ampere架构（A100/A30/A10）推荐CUDA 11.8，Ada架构（L40S/RTX 4090）推荐CUDA 12.2，Hopper架构（H100/H800）推荐CUDA 12.0+。然后查阅NVIDIA官方文档《TensorRT Support Matrix》，该表格列出了每个TensorRT版本对应的CUDA、cuDNN、Python版本以及硬件架构支持范围。例如TensorRT 8.6 GA版本支持CUDA 11.0~12.0，cuDNN 8.9.x；TensorRT 10.0支持CUDA 11.8和12.x，cuDNN 8.9.5+。务必以官方矩阵为准，不要凭经验猜测。

操作流程：第一步，运行nvidia-smi查看驱动版本和GPU型号；第二步，根据GPU架构和业务需求（如是否使用FP8、是否支持动态shape）确定TensorRT主版本；第三步，对照Support Matrix选择CUDA和cuDNN版本；第四步，记录所有版本号，写入项目的requirements.txt或Dockerfile中，确保团队环境一致。

2.2 安装实战：从驱动到TensorRT的完整安装流程

核心原理：安装顺序必须遵循"驱动→CUDA→cuDNN→TensorRT"的依赖方向。驱动是基础，CUDA Toolkit提供编译工具链（nvcc）和运行时库，cuDNN是深度神经网络的加速库，TensorRT依赖前两者。如果先装TensorRT再装CUDA，TensorRT的安装脚本可能无法正确检测CUDA路径，导致后续插件编译时找不到头文件。

操作流程（以Ubuntu 20.04 + CUDA 11.8为例）：

1. 安装GPU驱动：使用sudo apt install nvidia-driver-535或从NVIDIA官网下载runfile安装。安装后运行nvidia-smi确认驱动版本≥525.60.13。
2. 安装CUDA Toolkit：从NVIDIA官网下载CUDA 11.8 runfile，执行sudo sh cuda_11.8.0_520.61.05_linux.run，安装时取消驱动安装选项（避免覆盖已有驱动）。安装完成后配置环境变量：

export PATH=/usr/local/cuda-11.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH

3. 安装cuDNN：从NVIDIA官网下载cuDNN 8.9.2 for CUDA 11.x的deb包，执行sudo dpkg -i libcudnn8_8.9.2.26-1+cuda11.8_amd64.deb和sudo dpkg -i libcudnn8-dev_8.9.2.26-1+cuda11.8_amd64.deb。
4. 安装TensorRT：下载TensorRT 8.6 GA的tar包，解压后将lib和include路径加入环境变量：

export LD_LIBRARY_PATH=/path/to/TensorRT-8.6.1.6/lib:$LD_LIBRARY_PATH
export PATH=/path/to/TensorRT-8.6.1.6/bin:$PATH

案例拆解：某学员在安装时跳过了cuDNN的dev包，只安装了runtime包。结果在编译插件时，#include <cudnn.h>报错找不到头文件。排查过程：首先检查/usr/include下是否有cudnn.h，发现没有；然后检查dpkg -l | grep cudnn，发现只有libcudnn8（runtime）没有libcudnn8-dev。补装dev包后编译通过。这个案例说明，插件开发需要的是cuDNN的开发包（包含头文件和静态库），而不仅仅是运行库。

2.3 开发机配置：硬件、系统与编译工具链

核心原理：TensorRT插件开发涉及CUDA C++编译、动态库链接和GPU调试，开发机配置直接影响编译效率和调试体验。硬件方面，GPU显存建议≥16GB（用于加载大模型和生成engine），内存≥32GB（编译大型插件时内存不足会导致OOM），磁盘建议SSD且剩余空间≥50GB（CUDA Toolkit约3GB，TensorRT约2GB，加上模型和日志）。系统方面，Ubuntu 20.04/22.04是社区支持最好的选择，CentOS 7的GLIBC版本过低，可能导致TensorRT运行时报错。

判断方法：检查系统是否满足要求：gcc --version需要≥7.5；cmake --version需要≥3.18；python3 --version需要≥3.8。如果使用PyTorch进行模型转换，还需要安装PyTorch的CUDA版本，且PyTorch的CUDA版本必须与TensorRT的CUDA版本一致，否则在torch2trt或onnx-tensorrt转换时会出现版本冲突。

操作流程：推荐配置如下：

• GPU：NVIDIA RTX 3090/4090或A10（Ampere/Ada架构，支持FP16和INT8）
• CPU：8核以上，编译时make -j$(nproc)可并行加速
• 内存：32GB DDR4/DDR5
• 存储：NVMe SSD 1TB
• 系统：Ubuntu 22.04 LTS
• 编译工具：gcc 11.4、cmake 3.22、python 3.10

常见误区：很多学员在Windows上使用Visual Studio进行插件开发，但TensorRT的官方支持以Linux为主，Windows下的插件编译需要额外处理DLL导出符号和CUDA运行时路径问题。建议课程统一使用Linux环境，如果学员只有Windows机器，可以使用WSL2（Windows Subsystem for Linux 2）安装Ubuntu 22.04，WSL2支持CUDA和GPU直通，可以满足开发需求。

2.4 验证TensorRT基本功能：从trtexec到Plugin API

核心原理：环境搭建成功的标志不仅是安装无报错，更重要的是TensorRT的核心功能可以正常运行。验证分为三个层次：第一层是trtexec工具能否成功构建并运行一个简单的engine；第二层是C++ API能否加载engine并执行推理；第三层是自定义插件能否被TensorRT识别并调用。只有三层全部通过，才能确认环境完全可用。

操作流程：

1. 验证trtexec：运行trtexec --onnx=/path/to/model.onnx --saveEngine=test.engine，如果模型转换成功且生成engine文件，说明TensorRT核心功能正常。如果没有ONNX模型，可以使用trtexec --help查看帮助信息，或使用trtexec --buildOnly测试一个随机输入的网络。
2. 验证C++ API：编写一个简单的C++程序，使用nvonnxparser或nvinfer API加载engine并执行推理。核心代码片段：

#include <NvInfer.h>
#include <cuda_runtime_api.h>
using namespace nvinfer1;
// 创建runtime和engine
IRuntime* runtime = createInferRuntime(gLogger);
ICudaEngine* engine = runtime->deserializeCudaEngine(engineData, engineSize);
IExecutionContext* context = engine->createExecutionContext();
// 分配输入输出缓冲区
void* buffers[2];
cudaMalloc(&buffers[0], inputSize);
cudaMalloc(&buffers[1], outputSize);
// 执行推理
context->enqueueV2(buffers, stream, nullptr);
cudaStreamSynchronize(stream);

3. 验证插件API：创建一个最简单的插件类（继承IPluginV2DynamicExt），实现getPluginType、getPluginVersion、initialize、enqueue等纯虚函数，然后通过REGISTER_TENSORRT_PLUGIN宏注册。编译成动态库后，使用trtexec --plugins=libmyplugin.so加载，如果插件被成功识别，说明插件开发环境就绪。

案例拆解：某学员在验证插件时，编译动态库成功，但运行时提示"Plugin creator not found"。排查过程：首先检查插件注册宏是否写对，发现REGISTER_TENSORRT_PLUGIN的命名空间与插件类命名空间不一致；其次检查动态库是否被正确加载，使用ldd libmyplugin.so发现缺少libnvinfer.so的依赖路径；最后检查插件版本号是否与TensorRT期望的版本匹配。修复后插件正常加载。这个案例说明，插件验证需要同时关注编译期（宏注册）和运行期（动态库加载）两个环节。

总结复盘：环境搭建的核心是版本匹配和路径配置。建议学员在完成安装后，创建一个env_check.sh脚本，自动检查以下内容：nvcc --version、dpkg -l | grep cudnn、trtexec --version、echo $LD_LIBRARY_PATH，并将输出保存为日志。这样在后续开发中遇到问题时，可以快速定位是环境问题还是代码问题。同时，建议将整个环境配置过程记录为Dockerfile或shell脚本，便于团队协作和复现。