ONNX Runtime在ARM64架构下的部署问题与解决方案

问题背景

在将ONNX Runtime部署到ARM64架构设备（特别是NVIDIA Jetson Orin平台）时，开发者可能会遇到模型初始化失败的问题。具体表现为当尝试创建InferenceSession实例时，应用程序会突然终止，并输出标准模板库(STL)的断言错误，而不会抛出任何.NET可捕获的异常。

错误现象

典型的错误输出如下：

/opt/rh/gcc-toolset-12/root/usr/include/c++/12/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned int; _Alloc = std::allocator<unsigned int>; reference = unsigned int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted

这表明在底层C++代码中发生了数组越界访问，导致程序异常终止。值得注意的是，这种情况在x86_64架构下运行完全相同的代码时不会出现。

问题根源分析

经过深入调查，发现这个问题与ONNX Runtime官方发布的预编译二进制文件在特定ARM64平台上的兼容性有关。虽然官方二进制文件是在AlmaLinux 8环境下使用gcc-toolset-12编译的，理论上应该与Ubuntu 20.04兼容，但在某些特定的ARM64设备（如NVIDIA Jetson Orin）上却出现了兼容性问题。

解决方案

方法一：本地编译ONNX Runtime

最可靠的解决方案是在目标设备上本地编译ONNX Runtime：

1. 获取ONNX Runtime源代码
2. 使用以下命令进行编译：

./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync

3. 编译完成后，用生成的libonnxruntime.so替换项目中原有的库文件

方法二：调整编译参数

如果本地编译遇到问题，可以尝试使用与官方发布版本更接近的编译参数：

python3 tools/ci_build/build.py --enable_lto --build_java --build_nodejs --build_dir /build --config Release --skip_submodule_sync --parallel --use_binskim_compliant_compile_flags --build_shared_lib

技术建议

1. 调试符号：建议在编译时包含调试符号（RelWithDebInfo配置），这样在出现问题时可以获得更详细的堆栈信息。

2. 运行时环境：确保目标设备的运行时环境（如glibc版本）与编译环境兼容。

3. 异常处理：虽然在这种情况下无法捕获原生异常，但在生产环境中仍应实现完善的日志记录和异常处理机制。

总结

ARM64架构下的ONNX Runtime部署可能会遇到特定的兼容性问题，特别是在使用预编译二进制文件时。通过在目标设备上本地编译运行时库，可以有效解决这些问题。这也提醒我们，在跨平台部署机器学习模型时，考虑目标环境的特定性是非常重要的。

对于政府项目或关键任务系统，建议建立完整的本地编译和测试流程，以确保系统的稳定性和可靠性。同时，密切关注ONNX Runtime的版本更新，因为未来的版本可能会解决这些平台特定的兼容性问题。