企业官网建设流程全解析

在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要求为准。以下是经过验证的版本组合：

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_mnist

3. 项目克隆与环境变量配置

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 --recursive

3.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版本。经过多次尝试，我发现最彻底的解决方案是：

1. 完全卸载现有CUDA：

sudo apt-get purge --auto-remove cuda*

2. 重新安装CUDA 11.6和对应版本的cuDNN：

sudo apt-get install cuda-11-6 cudnn8.6.0

3. 确保conda环境中没有安装cudatoolkit：

conda uninstall cudatoolkit

4.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/lib

4.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.py

5.2 编译选项的微妙影响

在environment.sh中开启Python支持：

export USE_python=ON

重新构建时，必须清除之前的构建缓存：

rm -rf build/ ./tool/run.sh

6. 性能优化与实时推理

最终模型在我的RTX 3090上达到了38FPS，比官方Orin芯片的25FPS更优。以下是关键优化点：

1. 在build_trt_engine.sh中添加--fp16标志启用混合精度：

--fp16

2. 调整BEVPooling的网格大小，平衡精度和速度：

voxel_size = [0.1, 0.1, 0.2] # 原始值 voxel_size = [0.15, 0.15, 0.25] # 优化后

3. 使用TensorRT的profile功能找到计算瓶颈：

nsys profile -o bevfusion_report ./tool/run.sh