2. 开发环境与工具链搭建

自定义Plugin开发对环境的敏感度远高于普通推理部署：Plugin的编译产物必须与TensorRT运行时的ABI、CUDA运行时、cuDNN版本严格对齐，否则会出现“编译通过、加载失败”或“推理结果错误”这类难以定位的问题。本节围绕版本选择、依赖匹配、工程组织与调试工具链四条主线展开，目标是搭建一套可复现、可调试、可扩展的Plugin开发环境。

一、版本选择：先定TensorRT，再倒推CUDA与cuDNN

TensorRT的版本决定了可用的Plugin API形态。TensorRT 8.x 与 10.x 在Plugin接口上有明显差异：8.x 主要使用 IPluginV2DynamicExt，而 10.x 引入了 IPluginV3 与 IPluginCreatorV3，并逐步弱化旧接口。若课程或项目以动态shape、多输入Plugin为主，建议选择 TensorRT 8.6 或 10.x 的稳定分支；若需要与已有旧Plugin代码兼容，则优先锁定 8.6。

确定TensorRT版本后，CUDA与cuDNN必须按官方对应关系倒推。以 TensorRT 8.6 为例，官方支持 CUDA 11.8 与 CUDA 12.x 两条线，cuDNN 需为 8.9.x；TensorRT 10.x 则通常要求 CUDA 12.x 与 cuDNN 9.x。这里的关键原则是：TensorRT、CUDA、cuDNN 三者必须来自同一官方兼容矩阵，不能只看“大版本号相同”。例如 CUDA 12.2 与 cuDNN 8.9 组合在部分TensorRT版本中并不被支持，强行使用会在 nvinfer1::createInferRuntime 阶段报符号缺失。

二、依赖匹配的验证方法

版本匹配不能只靠文档对照，必须做实际验证。推荐三步：

1. 驱动与CUDA运行时检查：执行 nvidia-smi 查看驱动版本，再用 nvcc --version 确认CUDA编译器版本。驱动版本必须满足CUDA Toolkit的最低要求。
2. TensorRT运行时检查：编写最小程序调用 nvinfer1::getInferLibVersion() 与 cudnnGetVersion()，打印实际加载的版本号，确认与编译期头文件一致。
3. Plugin加载检查：用 ldd 检查 libnvinfer_plugin.so 与自定义 .so 的依赖链，确认没有混用不同CUDA版本的 libcudart。

若出现 undefined symbol 或 version 'libnvinfer.so.8' not found，优先排查 LD_LIBRARY_PATH 中是否混入了多个TensorRT安装路径。建议在 ~/.bashrc 中显式导出：

export TRT_ROOT=/usr/local/TensorRT-8.6.1.6
export CUDA_HOME=/usr/local/cuda-11.8
export LD_LIBRARY_PATH=$TRT_ROOT/lib:$CUDA_HOME/lib64:$LD_LIBRARY_PATH

三、CMake工程组织

Plugin工程通常包含三部分：Plugin实现、Plugin注册与Creator、测试与导出工具。推荐目录结构如下：

trt-plugin-demo/
├── CMakeLists.txt
├── cmake/
│   └── FindTensorRT.cmake
├── include/
│   └── my_plugin.h
├── src/
│   ├── my_plugin.cpp
│   └── my_plugin_creator.cpp
├── test/
│   └── test_plugin.cpp
└── tools/
    └── export_plugin.cpp

CMake中需要显式链接 nvinfer、nvinfer_plugin、cudart、cudnn，并设置 CMAKE_CUDA_ARCHITECTURES 与目标GPU架构一致。例如针对 A100 与 RTX 4090 混合环境，可设置为 80;89。Plugin的 .so 必须使用 -fPIC 与 --no-undefined 编译，避免运行时符号解析失败。

四、调试与性能分析工具链

Plugin调试分为功能调试与性能分析两层。功能调试推荐使用 cuda-gdb 配合 compute-sanitizer，前者定位kernel内的越界与非法访问，后者检测内存泄漏与未初始化读取。对于Plugin的 enqueue 或 execute 阶段，可在代码中插入 cudaStreamSynchronize 与 cudaGetLastError，快速判断错误发生在哪个kernel。

性能分析使用 nsys 与 ncu：nsys profile 可查看Plugin在整条推理流水线中的时间占比，ncu 则用于分析单个kernel的占用率、访存效率与指令吞吐。TensorRT自身还提供 trtexec 与 polygraphy，前者用于端到端延迟与吞吐测试，后者用于逐层输出对比，验证Plugin输出是否与参考实现一致。

五、可复现的环境基线清单

为便于团队协作与问题复现，建议在项目初始化时填写并提交以下环境基线表。表中数值为示例，实际项目应按官方兼容矩阵替换。

完成上述配置后，建议先用一个最小Plugin（如仅实现 enqueue 的恒等变换）跑通“编译—加载—推理—对比”全流程，再逐步替换为真实算子。这样可以把环境问题与算法问题分离，避免在复杂Plugin中同时排查两类错误。