在Ubuntu 20.04上，用RTX 3090从零部署CUDA-BEVFusion：一份避坑踩坑全记录
在Ubuntu 20.04上，用RTX 3090从零部署CUDA-BEVFusion：一份避坑踩坑全记录
当我在个人工作站上第一次尝试部署CUDA-BEVFusion时，完全没想到这会成为一场持续三天的技术拉锯战。作为一款针对自动驾驶场景优化的高性能感知算法，BEVFusion确实展现了令人惊艳的多传感器融合能力，但它的部署过程却像是一场精心设计的障碍赛——特别是当你手头只有一块RTX 3090显卡和Ubuntu 20.04系统时。这篇文章将带你完整经历我从环境配置到成功推理的全过程，重点不是教科书式的步骤罗列，而是那些让我抓狂又最终解决的现实问题。
1. 环境准备：显卡驱动的暗礁
在开始克隆项目之前，我建议先花半小时彻底检查基础环境。我的RTX 3090最初安装的是525版本驱动，这看似符合要求，却埋下了第一个隐患。
1.1 驱动与CUDA工具链的微妙关系
通过以下命令验证驱动版本：
nvidia-smi | grep "Driver Version"但真正关键的是CUDA工具链的兼容性。我最初选择了CUDA 11.1，因为这是PyTorch 1.10官方推荐的版本，却忽略了TensorRT 8.5.2.2对CUDA 11.6的隐性依赖。这个决定后来导致了著名的"cuBLAS版本冲突"。
关键发现：当同时需要PyTorch和TensorRT时，应该以TensorRT的CUDA要求为准。以下是经过验证的版本组合：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| NVIDIA驱动 | 525.85.12 | 最低要求525系列 |
| CUDA | 11.6 | 必须完整安装cudnn配套版本 |
| cuDNN | 8.6.0 | 需与CUDA版本严格匹配 |
| TensorRT | 8.5.2.2 | 必须从NVIDIA官网下载tar包安装 |
1.2 Conda环境的构建技巧
创建conda环境时，直接克隆现有环境可能带来隐性问题。更可靠的方式是从零构建：
conda create -n bevfusion python=3.8 -y conda activate bevfusion pip install torch==1.10.0+cu116 torchvision==0.11.1+cu116 -f https://download.pytorch.org/whl/torch_stable.html特别注意：这里的cu116后缀表示必须使用CUDA 11.6编译的PyTorch版本，这是避免后续cuBLAS冲突的关键。
2. TensorRT 8.5.2.2的安装陷阱
官方文档看似简单的TensorRT安装流程，在实际操作中却暗藏杀机。
2.1 二进制包与Python绑定的版本匹配
从NVIDIA官网下载的TensorRT 8.5.2.2 Linux x86_64 TAR包包含多个组件，但最容易被忽视的是Python绑定的版本匹配问题：
tar -zxvf TensorRT-8.5.2.2.Linux.x86_64-gnu.cuda-11.8.cudnn8.6.tar.gz cd TensorRT-8.5.2.2/python pip install tensorrt-8.5.2.2-cp38-none-linux_x86_64.whl致命细节：如果系统默认Python版本不是3.8，必须使用对应版本的whl文件。我曾在Python 3.9环境下错误安装了cp38的包，导致后续无法导入tensorrt模块。
2.2 动态链接库的路径配置
安装完成后，必须正确设置LD_LIBRARY_PATH，否则会出现各种神秘的"找不到符号"错误：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/TensorRT-8.5.2.2/lib验证安装是否成功的可靠方法是运行自带样例：
cd TensorRT-8.5.2.2/samples/sampleOnnxMNIST make && ./sample_onnx_mnist3. 项目克隆与环境变量配置
Lidar_AI_Solution项目的递归克隆需要特别注意子模块的完整性。
3.1 递归克隆的正确姿势
使用以下命令确保所有子模块都被完整拉取：
git lfs install git clone --recursive https://github.com/NVIDIA-AI-IOT/Lidar_AI_Solution.git cd Lidar_AI_Solution/CUDA-BEVFusion常见陷阱：如果网络中断导致子模块不完整，后续构建时会报各种"找不到文件"错误。此时需要手动初始化子模块：
git submodule update --init --recursive3.2 环境变量配置的艺术
environment.sh文件的配置直接影响后续所有构建步骤。以下是我的最终有效配置：
export TensorRT_Lib=/path/to/TensorRT-8.5.2.2/lib export TensorRT_Inc=/path/to/TensorRT-8.5.2.2/include export CUDA_Lib=/usr/local/cuda-11.6/lib64 export CUDA_Inc=/usr/local/cuda-11.6/include export CUDNN_Lib=/usr/local/cuda-11.6/lib64关键点：所有路径必须使用绝对路径，且CUDA版本号(11.6)必须与之前安装的完全一致。
4. 构建与运行时的高频错误
实际构建过程中遇到的错误往往比文档描述的复杂得多。
4.1 cuBLAS版本冲突的终极解决方案
当看到以下报错时：
Compiled against cuBLASLt 11.9.2.0 but running against cuBLASLt 11.2.1.0这表明TensorRT和PyTorch使用了不兼容的cuBLAS版本。经过多次尝试，我发现最彻底的解决方案是：
- 完全卸载现有CUDA：
sudo apt-get purge --auto-remove cuda*- 重新安装CUDA 11.6和对应版本的cuDNN：
sudo apt-get install cuda-11-6 cudnn8.6.0- 确保conda环境中没有安装cudatoolkit：
conda uninstall cudatoolkit4.2 libmyelin.so.1加载失败的修复
另一个令人头疼的问题是：
error while loading shared libraries: libmyelin.so.1: cannot open shared object file解决方法是将TensorRT的lib目录加入链接路径：
sudo ldconfig /path/to/TensorRT-8.5.2.2/lib4.3 ONNX模型转换的注意事项
构建TRT引擎时，ONNX模型的版本兼容性至关重要：
./tool/build_trt_engine.sh需要确保：
- ONNX版本为1.12.0
- Protobuf版本为3.20.0
- ONNX Runtime版本为1.10.0
可以通过以下命令验证：
pip list | grep -E "onnx|protobuf"5. Python接口的隐藏关卡
成功构建C++部分后，Python接口的配置又有其独特的挑战。
5.1 环境变量的动态加载
直接运行pybev.py会报错：
ModuleNotFoundError: No module named 'libpybev'因为Python需要动态加载生成的.so文件。正确做法是：
source tool/environment.sh python tool/pybev.py5.2 编译选项的微妙影响
在environment.sh中开启Python支持：
export USE_python=ON重新构建时，必须清除之前的构建缓存：
rm -rf build/ ./tool/run.sh6. 性能优化与实时推理
最终模型在我的RTX 3090上达到了38FPS，比官方Orin芯片的25FPS更优。以下是关键优化点：
- 在build_trt_engine.sh中添加--fp16标志启用混合精度：
--fp16- 调整BEVPooling的网格大小，平衡精度和速度：
voxel_size = [0.1, 0.1, 0.2] # 原始值 voxel_size = [0.15, 0.15, 0.25] # 优化后- 使用TensorRT的profile功能找到计算瓶颈：
nsys profile -o bevfusion_report ./tool/run.sh