1. 环境准备从零搭建Mask2Former转ONNX的完整工具链第一次尝试将Mask2Former模型转为ONNX格式时我花了整整三天时间在环境配置上。各种版本冲突、依赖缺失的问题接踵而至甚至一度让我怀疑人生。后来才发现关键在于从一开始就构建正确的工具链组合。这里分享我验证过的稳定环境方案基础环境推荐使用Ubuntu 20.04 LTS系统这是大多数深度学习框架官方测试最充分的环境。我试过在CentOS上折腾光是解决glibc版本问题就浪费了半天。Python版本Python 3.8是最稳妥的选择。3.9及以上版本可能会遇到mmcv-full的兼容性问题而3.7以下又缺少某些新特性支持。CUDA驱动必须与PyTorch版本严格匹配。比如PyTorch 1.12.1需要CUDA 11.6如果装了CUDA 11.7就会出问题。可以通过nvcc --version和python -c import torch; print(torch.version.cuda)双重验证。安装MMDeploy时最容易踩的坑是依赖顺序。正确的姿势应该是# 先装PyTorch pip install torch1.12.1cu116 torchvision0.13.1cu116 --extra-index-url https://download.pytorch.org/whl/cu116 # 再装mmcv-full注意指定版本 pip install mmcv-full1.7.1 -f https://download.openmmlab.com/mmcv/dist/cu116/torch1.12.0/index.html # 最后安装MMDeploy pip install mmdeploy1.3.1 mmdeploy-runtime1.3.1 mmdeploy-runtime-gpu1.3.1注意千万不要直接pip install mmdeploy这可能会安装最新版导致与现有代码不兼容。我曾在三个不同项目里验证过1.3.1版本与Mask2Former的兼容性最好。2. 模型转换避开ONNX导出时的那些天坑当我第一次看到Mask2Former成功导出ONNX模型时差点激动得从椅子上跳起来——毕竟之前已经失败了七次。最大的教训是默认配置往往不能直接用。这里有几个关键调整点2.1 ONNX配置文件修改在configs/_base_/onnx_config.py中必须调整以下参数onnx_config dict( typeonnx, export_paramsTrue, keep_initializers_as_inputsFalse, opset_version12, # 关键修改默认11会导致某些算子不支持 save_fileend2end.onnx, input_names[input], output_names[output], input_shapeNone, optimizeTrue)opsets版本是个大坑。Mask2Former使用的某些高级算子如GridSample在opset11中实现不完整会报Unsupported ONNX opset version: 11错误。实测opset12最稳定。2.2 自定义算子处理遇到NYI: Named tensors are not supported with the tracer错误时需要修改mmdeploy/pytorch/functions/copy.py。这个问题的本质是PyTorch的深拷贝操作在ONNX导出时不兼容。我的解决方案是FUNCTION_REWRITER.register_rewriter(func_namecopy.deepcopy) def copy__default(tensor: Tensor, *args, **kwargs) - Tensor: 重写深拷贝逻辑 if isinstance(tensor, Tensor) and not args and not kwargs: return tensor.clone() # 用clone代替深拷贝 # 其他情况保持原样 ctx FUNCTION_REWRITER.get_context() return ctx.origin_func(tensor, *args, **kwargs)2.3 实际导出命令完整的导出命令应该包含三个关键要素部署配置、模型配置和权重文件。例如python ./tools/deploy.py \ configs/mmseg/segmentation_onnxruntime_static-1024x2048.py \ /path/to/mask2former/config.py \ /path/to/checkpoints/best_mIoU_iter_75000.pth \ /path/to/test_image.png这里有个小技巧测试图片最好用验证集中的真实样本不要用纯色图片。我试过用全黑图片导出虽然成功了但后续推理时出现了数值溢出。3. 推理优化让ONNX模型飞起来导出的ONNX模型如果直接使用推理速度可能比原生PyTorch慢2-3倍。经过两周的调优我总结出这几个加速技巧3.1 图优化配置在segmentation_onnxruntime_static-1024x2048.py中添加图优化选项onnx_config dict( # ...其他参数... optimizerdict( typeonnx_optimizer, optimizers[ eliminate_unused_initializer, fuse_bn_into_conv, fuse_consecutive_transposes ]))这三个优化器组合能提升约30%推理速度。但要注意fuse_bn_into_conv在某些自定义层上可能导致数值误差建议先用测试集验证精度。3.2 动态输入尺寸支持默认静态尺寸会限制应用场景。修改导出配置支持动态输入onnx_config[input_shape] { min: [1, 3, 512, 512], opt: [1, 3, 1024, 2048], max: [1, 3, 1536, 3072] }这样同一个模型可以处理不同分辨率的输入。实测在1080Ti上1024x2048输入推理时间从87ms降到52ms。3.3 混合精度推理ONNXRuntime支持FP16推理只需在创建会话时指定import onnxruntime as ort sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess_options.enable_cpu_mem_arena True providers [ (CUDAExecutionProvider, { device_id: 0, arena_extend_strategy: kNextPowerOfTwo, cudnn_conv_algo_search: EXHAUSTIVE, do_copy_in_default_stream: True, }), CPUExecutionProvider ] ort_session ort.InferenceSession( end2end.onnx, sess_optionssess_options, providersproviders )这套配置在我的测试环境下将吞吐量提升了2.4倍从原来的45 FPS提升到108 FPS。4. 疑难排错那些让人抓狂的报错与解决方案4.1 经典错误libonnxruntime.so缺失当看到libonnxruntime.so.1.15.1: cannot open shared object file时别急着重装系统。我找到两种解决方案方案1修改wrapper.py路径# 在mmdeploy/backend/onnxruntime/wrapper.py中修改 def load_ort_library(): lib_path /your/custom/path/libonnxruntime.so # 指定绝对路径 if os.path.exists(lib_path): return cdll.LoadLibrary(lib_path)方案2推荐建立符号链接# 找到实际库位置通常在conda环境内 find ~/miniconda3 -name libonnxruntime.so* # 建立软链接 ln -s /path/to/actual/libonnxruntime.so.1.15.1 /usr/local/lib/ ldconfig4.2 自定义算子加载失败遇到Failed to load library libmmdeploy_onnxruntime_ops.so时首先检查文件是否存在ls -lh /path/to/libmmdeploy_onnxruntime_ops.so依赖是否完整ldd /path/to/libmmdeploy_onnxruntime_ops.so我常用的解决步骤# 1. 复制到当前目录 cp /path/to/libmmdeploy_onnxruntime_ops.so . # 2. 设置环境变量 export LD_LIBRARY_PATH$(pwd):$LD_LIBRARY_PATH # 3. 在Python中显式指定路径 session_options.register_custom_ops_library(./libmmdeploy_onnxruntime_ops.so)4.3 内存泄漏排查ONNXRuntime偶尔会出现内存缓慢增长的问题。我的诊断方案import onnxruntime as ort import gc # 启用内存分析 ort.set_default_logger_severity(3) # 3INFO级别日志 # 每次推理后强制垃圾回收 with torch.no_grad(): outputs ort_session.run(None, inputs) gc.collect()如果发现内存仍然增长可能是模型中有未释放的缓存。这时候需要检查ONNX模型是否包含循环结构这类结构在ONNX中处理不够完善。