【人工智能学习之MMdeploy部署踩坑总结】

以下是我在使用mmdeploy部署时踩过的坑，在此分享帮助大家，欢迎补充和指正。

报错1：TRTNet: device must be a GPU!

是说用tenserRT推理必须使用gpu，你应该在代码中选择的是cpu，需要改成cuda。注意！是：“cuda”，不是"gpu"写gpu是无效的。

列如：

self.recognizer = VideoRecognizer(model_path=onnx_path, device_name='cuda', device_id=int(gpu_id))

报错2：Failed to create Net backend: tensorrt

是因为没设置tensorrt环境变量，需要将trt路径写入到.bashrc中：

echo "export LD_LIBRARY_PATH=/root/TensorRT-8.6.1.6/lib:/root/cudnn/lib:$LD_LIBRARY_PATH" >> ~/.bashrc && \
source ~/.bashrc

报错3：Failed to load library libonnxruntime_providers_shared.so

完整的详细报错为：
[mmdeploy] [error] [ort_net.cpp:205] unhandled exception when creating ORTNet: /onnxruntime_src/onnxruntime/core/session/provider_bridge_ort.cc:1080 void onnxruntime::ProviderSharedLibrary::Ensure() [ONNXRuntimeError] : 1 : FAIL : Failed to load library libonnxruntime_providers_shared.so with error: libonnxruntime_providers_shared.so: cannot open shared object file: No such file or directory

是系统找不到 libonnxruntime_providers_shared.so 这个共享库文件，这通常与 ONNX Runtime 的安装不完整或环境配置问题有关。

1. 确认库文件是否存在

首先检查系统中是否实际存在 libonnxruntime_providers_shared.so：

# 在系统中搜索该文件
sudo find / -name "libonnxruntime_providers_shared.so" 2>/dev/null

• 如果找到该文件（例如路径为 /path/to/libonnxruntime_providers_shared.so），需要将其所在目录添加到系统库路径：

  # 临时生效（当前终端）
  export LD_LIBRARY_PATH=/path/to/directory-containing-the-file:$LD_LIBRARY_PATH# 永久生效（添加到 ~/.bashrc 或 ~/.zshrc）
  echo "export LD_LIBRARY_PATH=/path/to/directory-containing-the-file:\$LD_LIBRARY_PATH" >> ~/.bashrc
  source ~/.bashrc
  

2. 重新安装 ONNX Runtime

如果未找到该文件，说明 onnxruntime-gpu 安装不完整，重新安装：

# 先卸载现有版本
pip uninstall -y onnxruntime-gpu# 安装与 mmdeploy 兼容的版本 
pip install onnxruntime-gpu

注意：mmdeploy 对 ONNX Runtime 版本有一定兼容性要求，过新的版本（如 1.18.0）可能存在适配问题，降低版本通常能解决此类库缺失问题。

3. 检查系统依赖

libonnxruntime_providers_shared.so 可能依赖系统级的 CUDA 或 CUDNN 库，确保：

• 系统已安装与 onnxruntime-gpu 1.16.0 兼容的 CUDA（推荐 11.6+）和 CUDNN（推荐 8.4+）
• CUDA 和 CUDNN 的路径已正确添加到环境变量（如 LD_LIBRARY_PATH 包含 /usr/local/cuda/lib64 等）

4. 验证安装

重新安装后，通过以下命令验证 ONNX Runtime 是否正常工作：

import onnxruntime as ort
print("ONNX Runtime 版本:", ort.__version__)
print("可用执行 providers:", ort.get_available_providers())

如果输出包含 ['CUDAExecutionProvider', 'CPUExecutionProvider']，说明安装成功，此时再尝试运行 mmdeploy 相关代码即可。

如果以上步骤仍未解决，可能需要检查 mmdeploy 与 ONNX Runtime 的编译/安装匹配性（例如是否使用源码编译 mmdeploy 时指定了正确的 ONNX Runtime 路径）。

报错4：libcudnn.so.9: cannot open shared object file: No such file or directory

完整的详细报错为：
[mmdeploy] [error] [ort_net.cpp:205] unhandled exception when creating ORTNet: /onnxruntime_src/onnxruntime/core/session/provider_bridge_ort.cc:1131 onnxruntime::Provider& onnxruntime::ProviderLibrary::Get() [ONNXRuntimeError] : 1 : FAIL : Failed to load library libonnxruntime_providers_cuda.so with error: libcudnn.so.9: cannot open shared object file: No such file or directory [mmdeploy] [error] [net_module.cpp:54] Failed to create Net backend: onnxruntime
报错核心是系统找不到 libcudnn.so.9，这是 CuDNN 库的问题，结合你用 Conda 虚拟环境（mmdeploy_zhr），按以下步骤解决：

1. 确认 Conda 环境内的 CuDNN 路径

先找到虚拟环境中 CuDNN 库的位置：

# 激活环境（确保已激活 mmdeploy_zhr）
conda activate mmdeploy# 查找 libcudnn.so.9 所在目录
find $CONDA_PREFIX -name "libcudnn.so.9"

正常情况下，会输出类似：
/root/miniconda3/envs/mmdeploy_zhr/lib/libcudnn.so.9
记住这个路径的父目录（比如上面的路径，父目录是 /root/miniconda3/envs/mmdeploy_zhr/lib ）。

2. 设置环境变量（临时生效）

在运行脚本前，手动设置 LD_LIBRARY_PATH 包含 CuDNN 库路径：

# 替换成你实际的 CuDNN 库父目录
export LD_LIBRARY_PATH=/root/miniconda3/envs/mmdeploy/lib:$LD_LIBRARY_PATH# 再次运行脚本
python onnx_run.py

如果临时设置后不报错，说明环境变量配置有效，继续看步骤 3 永久配置。

3. 永久配置环境变量（虚拟环境内）

为了让虚拟环境每次激活时自动加载 CuDNN 路径，在 Conda 环境中配置：

# 激活环境
conda activate mmdeploy_zhr# 添加环境变量到虚拟环境的 activate.d 目录
echo "export LD_LIBRARY_PATH=$CONDA_PREFIX/lib:\$LD_LIBRARY_PATH" >> $CONDA_PREFIX/etc/conda/activate.d/cudnn.sh# 添加取消环境变量到 deactivate.d 目录（可选，退出环境时清理）
echo "unset LD_LIBRARY_PATH" >> $CONDA_PREFIX/etc/conda/deactivate.d/cudnn.sh# 重新激活环境使配置生效
conda deactivate
conda activate mmdeploy_zhr

这样每次激活 mmdeploy_zhr 环境时，LD_LIBRARY_PATH 会自动包含 CuDNN 库路径，无需每次手动设置。

4. 检查 CuDNN 版本兼容性（关键！）

你的报错里是 libcudnn.so.9，说明当前环境用的是 CuDNN 9.x，但要注意：

• ONNX Runtime GPU 版本（尤其是旧版，如你之前用的 1.15.1）对 CuDNN 9.x 兼容性可能不佳，容易出现段错误。
• 建议降级 CuDNN 到 8.x 版本（更稳定，适配大多数框架）：

  # 先卸载当前 CuDNN
  conda uninstall -y cudnn# 安装 CuDNN 8.9（适配 CUDA 11/12，兼容性好）
  conda install -y -c nvidia cudnn=8.9.2
  

  安装后重新运行 find $CONDA_PREFIX -name "libcudnn.so.8" 确认路径，再回到步骤 2/3 配置环境变量。

5. 验证环境

完成上述步骤后，通过以下命令验证：

# 激活环境
conda activate mmdeploy_zhr# 检查 CuDNN 库是否能被找到
ldd $CONDA_PREFIX/lib/libonnxruntime_providers_cuda.so | grep cudnn

如果输出类似：
libcudnn.so.8 => /root/miniconda3/envs/mmdeploy_zhr/lib/libcudnn.so.8 (0x00007f...)
说明 CuDNN 路径已正确配置，再运行 onnx_run.py 应该能解决 libcudnn.so.9 找不到的问题。

总结：核心是让系统找到 CuDNN 库文件，优先通过 Conda 环境配置 LD_LIBRARY_PATH，并检查 CuDNN 版本（推荐 8.x）与 ONNX Runtime、mmdeploy 的兼容性，避免因版本过高导致段错误。

报错5：Inconsistency detected by ld.so: dl-version.c: 205: _dl_check_map_versions: Assertion `needed != NULL’ failed!

是动态链接器（ld.so）检测到库版本不兼容 的错误，通常是因为不同库对系统底层依赖（如 glibc、CUDA 库）的版本要求冲突，或虚拟环境内的库与系统全局库混用导致。
一般重装就可以解决。最可能的原因是 CUDA 版本 与 ONNX Runtime 版本 不兼容导致的。

报错6：mismatched data type FLOAT vs HALF

是模型的数据类型和输入的数据类型不匹配，要么增加前处理，要么重新导出所需数据类型的模型。

版本对应表

以下是官网的版本对应表：