使用执行提供者（Execution Providers）构建 ONNX Runtime

目录

• 执行提供者共享库
• CUDA
• TensorRT
• NVIDIA Jetson TX1/TX2/Nano/Xavier/Orin
• TensorRT-RTX
• oneDNN
• OpenVINO
• QNN
• DirectML
• Arm 计算库
• Arm NN
• RKNPU
• AMD Vitis AI
• AMD MIGraphX
• AMD ROCm
• NNAPI
• CoreML
• XNNPACK
• CANN
• Azure

执行提供者共享库

oneDNN、TensorRT、OpenVINO™、CANN 和 QNN 提供者被构建为共享库，而不是静态链接到主 onnxruntime 中。这使得它们只在需要时才被加载，并且如果提供者的依赖库未安装，onnxruntime 仍能正常运行，只是无法使用该提供者。对于非共享库提供者，必须存在提供者的所有依赖项才能加载 onnxruntime。

构建文件

在 Windows 上，共享提供者库将命名为“onnxruntime_providers_*.dll”（例如 onnxruntime_providers_openvino.dll）。在 Unix 上，它们将命名为“libonnxruntime_providers_*.so”。在 Mac 上，它们将命名为“libonnxruntime_providers_*.dylib”。

还有一个共享库，共享提供者依赖于它，名为 onnxruntime_providers_shared（应用上述相同的命名约定）。

注意：不建议将这些库放置在系统位置或添加到库搜索路径（如 Unix 上的 LD_LIBRARY_PATH）。如果系统上安装了多个版本的 onnxruntime，这可能会导致它们找到错误的库并导致未定义行为。

加载共享提供者

共享提供者库由 onnxruntime 代码加载（不要在客户端代码中加载或依赖它们）。注册共享或非共享提供者的 API 是相同的，不同之处在于共享提供者将在运行时将其添加到会话选项时加载（通过调用 C API 中的 OrtSessionOptionsAppendExecutionProvider_OpenVINO 或 SessionOptionsAppendExecutionProvider_OpenVINO）。如果共享提供者库无法加载（如果文件不存在，或者其依赖项不存在或不在路径中），则将返回错误。

onnxruntime 代码将在 onnxruntime 共享库所在的位置（或静态链接到静态库版本的可执行文件）查找提供者共享库。

---

CUDA

先决条件

• 安装 CUDA 和 cuDNN
  • ONNX Runtime 的 CUDA 执行提供者是使用 CUDA 12.x 和 cuDNN 9 构建和测试的。有关更多版本信息，请查看此处。
  • CUDA 安装路径必须通过 CUDA_HOME 环境变量或 --cuda_home 参数提供。安装目录应包含 bin、include 和 lib 子目录。
  • 必须将 CUDA bin 目录的路径添加到 PATH 环境变量中，以便找到 nvcc。
  • cuDNN 安装路径必须通过 CUDNN_HOME 环境变量或 --cudnn_home 参数提供。在 Windows 中，安装目录应包含 bin、include 和 lib 子目录。
  • cuDNN 8.* 需要 ZLib。请按照 cuDNN 8.9 安装指南 在 Linux 或 Windows 中安装 zlib。
  • 在 Windows 中，必须将 cuDNN bin 目录的路径添加到 PATH 环境变量中，以便找到 cudnn64_8.dll。

构建说明

Windows

.\build.bat --use_cuda --cudnn_home <cudnn home path> --cuda_home <cuda home path>

Linux

./build.sh --use_cuda --cudnn_home <cudnn home path> --cuda_home <cuda home path>

Dockerfile 可在此处获取。

构建选项

要指定 GPU 架构（参见计算能力），您可以附加参数，例如 --cmake_extra_defines CMAKE_CUDA_ARCHITECTURES=80;86;89。

使用 --cmake_extra_defines onnxruntime_USE_CUDA_NHWC_OPS=ON，CUDA EP 可以用额外的 NHWC 操作符编译。此选项默认不启用，因为支持的 NHWC 操作符数量较少。

另一个非常有用的 CMake 构建选项是构建时支持 NVTX（--cmake_extra_defines onnxruntime_ENABLE_NVTX_PROFILE=ON），这将使用 Nsight Systems 启用更简单的性能分析，并将 CUDA 内核与其实际 ONNX 操作符关联起来。

--enable_cuda_line_info 或 --cmake_extra_defines onnxruntime_ENABLE_CUDA_LINE_NUMBER_INFO=ON 将启用 NVCC 生成设备代码的行号信息。这在您在 CUDA 内核上运行 Compute Sanitizer 工具时可能会有所帮助。

如果您的 Windows 机器安装了多个版本的 CUDA，并且您想使用旧版本 CUDA，则需要附加参数，例如 --cuda_version <cuda version>。

当您的构建机器拥有大量 CPU 核心但内存少于 64 GB 时，可能会出现内存不足错误，例如 nvcc error : 'cicc' died due to signal 9。解决方案是使用参数 --parallel 4 --nvcc_threads 1 限制并行 NVCC 线程的数量。

关于旧版本 ONNX Runtime、CUDA 和 Visual Studio 的说明

• 根据您使用的 CUDA、cuDNN 和 Visual Studio 版本之间的兼容性，您可能需要显式安装早期版本的 MSVC 工具集。
• 对于旧版本 ONNX Runtime 和 CUDA，以及 Visual Studio
  • CUDA 10.0 已知与 14.11 到 14.16 的工具集（Visual Studio 2017 15.9）兼容，并且应继续与未来的 Visual Studio 版本兼容。
  • CUDA 9.2 已知与 14.11 MSVC 工具集（Visual Studio 15.3 和 15.4）兼容
    • 要安装 14.11 MSVC 工具集，请参见此页面。
    • 要在更高版本的 Visual Studio 2017 中使用 14.11 工具集，您有两种选择

      1. 在运行构建脚本之前，通过运行 vcvarsall.bat 设置 Visual Studio 环境变量以指向 14.11 工具集。例如，如果您有 VS2017 Enterprise，x64 构建将使用以下命令 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64 -vcvars_ver=14.11 为方便起见，.\build.amd64.1411.bat 将执行此操作，并且可以与 .\build.bat 以相同的方式使用。例如，` .\build.amd64.1411.bat –use_cuda`

      2. 或者，如果您有 CMake 3.13 或更高版本，您可以通过 --msvc_toolset 构建脚本参数指定工具集版本。例如，.\build.bat --msvc_toolset 14.11

• 如果您的 Windows 机器上安装了多个 CUDA 版本，并且您正在使用 Visual Studio 构建，CMake 将使用它在 BuildCustomization 文件夹中找到的最高版本 CUDA 的构建文件。例如，C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\BuildCustomizations。如果您想使用早期版本构建，则必须暂时从该目录中删除更高版本的“CUDA x.y.*”文件。

---

TensorRT

有关 TensorRT 执行提供者的更多信息，请参阅此处。

先决条件

• 遵循CUDA 执行提供者说明安装 CUDA 和 cuDNN，并设置环境变量。
• 遵循TensorRT 安装说明
  • ONNX Runtime 的 TensorRT 执行提供者是使用 TensorRT 10.9 构建和测试的。
  • TensorRT 安装路径必须通过 --tensorrt_home 参数提供。
  • ONNX Runtime 默认使用 tensorrt_home 中的 TensorRT 内置解析器。
  • 要改用开源的 onnx-tensorrt 解析器，请在下面的构建命令中添加 --use_tensorrt_oss_parser 参数。
    • 开源 onnx-tensorrt 解析器的默认版本在 cmake/deps.txt 中指定。
    • 要指定不同版本的 onnx-tensorrt 解析器
      • 选择您偏好的 onnx-tensorrt 提交；
      • 使用下载的 onnx-tensorrt zip 文件运行 sha1sum 命令以获取 SHA1 哈希
      • 使用更新的 onnx-tensorrt 提交和哈希信息更新 cmake/deps.txt。
    • 请确保 cmake/deps.txt 中指定的 TensorRT 内置解析器/开源 onnx-tensorrt **版本匹配**，如果启用 --use_tensorrt_oss_parser。
      • 例如，如果将 tensorrt_home 分配给 TensorRT-10.9 内置二进制文件的路径，并且 cmake/deps.txt 中指定了 onnx-tensorrt 10.9-GA 分支，则版本匹配。

[致 ORT 1.21/1.22 开源解析器用户]

• ORT 1.21/1.22 链接到 onnx-tensorrt 10.8-GA/10.9-GA，这需要新发布的 onnx 1.18。
  • 在构建 ORT 1.21/1.22 时，有一个临时修复方案来预览 onnx-tensorrt 10.8-GA/10.9-GA
    • 将 cmake/deps.txt 中的 onnx 行替换为 onnx;https://github.com/onnx/onnx/archive/e709452ef2bbc1d113faf678c24e6d3467696e83.zip;c0b9f6c29029e13dea46b7419f3813f4c2ca7db8
    • 下载此文件作为原始文件，并将其保存到 cmake/patches/onnx/onnx.patch（不要从浏览器复制/粘贴，因为它可能会更改换行符类型）
    • 使用上述 trt 相关标志（包括 --use_tensorrt_oss_parser）构建 ORT
  • onnx 1.18 受最新 ORT 主分支支持。请 checkout 主分支并使用 --use_tensorrt_oss_parser 构建 ORT-TRT，以启用对 onnx 1.18 的完全 OSS 解析器支持。

构建说明

Windows

# to build with tensorrt built-in parser
.\build.bat --config Release --parallel  --cmake_extra_defines 'CMAKE_CUDA_ARCHITECTURES=native' --cudnn_home <path to cuDNN home> --cuda_home <path to CUDA home> --use_tensorrt --tensorrt_home <path to TensorRT home> --cmake_generator "Visual Studio 17 2022"

# to build with specific version of open-sourced onnx-tensorrt parser configured in cmake/deps.txt
.\build.bat --config Release --parallel  --cmake_extra_defines 'CMAKE_CUDA_ARCHITECTURES=native' --cudnn_home <path to cuDNN home> --cuda_home <path to CUDA home> --use_tensorrt --tensorrt_home <path to TensorRT home> --use_tensorrt_oss_parser --cmake_generator "Visual Studio 17 2022" 

Linux

# to build with tensorrt built-in parser
./build.sh --config Release --parallel --cmake_extra_defines 'CMAKE_CUDA_ARCHITECTURES=native' --cudnn_home <path to cuDNN e.g. /usr/lib/x86_64-linux-gnu/> --cuda_home <path to folder for CUDA e.g. /usr/local/cuda> --use_tensorrt --tensorrt_home <path to TensorRT home>

# to build with specific version of open-sourced onnx-tensorrt parser configured in cmake/deps.txt
./build.sh --config Release --parallel --cmake_extra_defines 'CMAKE_CUDA_ARCHITECTURES=native' --cudnn_home <path to cuDNN e.g. /usr/lib/x86_64-linux-gnu/> --cuda_home <path to folder for CUDA e.g. /usr/local/cuda> --use_tensorrt --use_tensorrt_oss_parser --tensorrt_home <path to TensorRT home> --skip_submodule_sync

Dockerfile 说明可在此处获取。

注意 使用 TensorRT 8.X 和 --use_tensorrt_oss_parser 构建需要额外的标志 –cmake_extra_defines onnxruntime_USE_FULL_PROTOBUF=ON

---

NVIDIA Jetson TX1/TX2/Nano/Xavier/Orin

构建说明

这些说明适用于最新的 JetPack SDK。

1. 在 Jetson 主机上克隆 ONNX Runtime 仓库

   git clone --recursive https://github.com/microsoft/onnxruntime
   

2. 指定 CUDA 编译器，或将其位置添加到 PATH 中。

   1. JetPack 5.x 用户可以升级到最新的 CUDA 版本，而无需更新 JetPack 版本或 Jetson Linux BSP（板级支持包）。

      1. 对于 JetPack 5.x 用户，ONNX Runtime 1.17 及更高版本要求安装 CUDA>=11.8 和 GCC>9.4。

      2. 请查看此官方博客以获取 CUDA 升级说明（CUDA 12.2 已在 Jetson Xavier NX 上的 JetPack 5.1.2 中验证）。

         1. 如果 /usr/local/cuda-12.2/compat 下没有 libnvcudla.so：sudo apt-get install -y cuda-compat-12-2 并将 export LD_LIBRARY_PATH="/usr/local/cuda-12.2/lib64:/usr/local/cuda-12.2/compat:$LD_LIBRARY_PATH" 添加到 ~/.bashrc 中。

      3. 请查看此处以获取计算能力数据表。

   2. 如果 nvcc 不在 PATH 中，CMake 无法自动找到正确的 nvcc。nvcc 可以通过以下方式添加到 PATH

      export PATH="/usr/local/cuda/bin:${PATH}"
      

      或

      export CUDACXX="/usr/local/cuda/bin/nvcc"
      

   3. 更新 TensorRT 库

      1. Jetpack 5.x 支持到 TensorRT 8.5。Jetpack 6.x 配备 TensorRT 8.6-10.3。

      2. Jetpack 6.x 用户可以从 TensorRT SDK 网站下载最新的适用于 jetpack 的 TensorRT 10 TAR 包。

      3. 请查看此处以获取所有 ONNX Runtime 版本之间的 TensorRT/CUDA 支持矩阵。

3. 在 Jetpack 主机上安装 ONNX Runtime 构建依赖项

   sudo apt install -y --no-install-recommends \
     build-essential software-properties-common libopenblas-dev \
     libpython3.10-dev python3-pip python3-dev python3-setuptools python3-wheel
   

4. 构建 ONNX Runtime 需要 Cmake。请在此处查看所需的最低 CMake 版本。从 https://cmake.com.cn/download/ 下载并添加 cmake 可执行文件到 PATH 以使用它。

5. 构建 ONNX Runtime Python wheel

   1. 构建支持 CUDA 和 TensorRT 的 onnxruntime-gpu wheel（如有必要，更新 CUDA/CUDNN/TensorRT 库的路径）

      ./build.sh --config Release --update --build --parallel --build_wheel \
      --use_tensorrt --cuda_home /usr/local/cuda --cudnn_home /usr/lib/aarch64-linux-gnu \
      --tensorrt_home /usr/lib/aarch64-linux-gnu
      

​ 注意

• 默认情况下，onnxruntime-gpu wheel 文件将捕获在 path_to/onnxruntime/build/Linux/Release/dist/ 下（构建路径可以通过在上述构建命令中添加 --build_dir 后跟自定义路径来自定义）。

• 在构建命令中附加 --skip_tests --cmake_extra_defines 'CMAKE_CUDA_ARCHITECTURES=native' 'onnxruntime_BUILD_UNIT_TESTS=OFF' 'onnxruntime_USE_FLASH_ATTENTION=OFF' 'onnxruntime_USE_MEMORY_EFFICIENT_ATTENTION=OFF' 以选择退出可选功能并减少构建时间。

• 对于部分 Jetson 设备（如 Xavier 系列），更高的功耗模式涉及更多的核心（最多 6 个）进行计算，但在构建 ONNX Runtime 时会消耗更多资源。如果发生 OOM 并且系统挂起，请在构建命令中设置 --parallel 1。

TensorRT-RTX

有关 NV TensorRT RTX 执行提供者的更多信息，请参阅此处。

先决条件

• 遵循CUDA 执行提供者说明安装 CUDA 并设置环境变量。
• 从 nvidia.com 安装 TensorRT for RTX（TODO：可用时添加链接）

构建说明

build.bat --config Release --parallel 32 --build_dir _build --build_shared_lib --use_nv_tensorrt_rtx --tensorrt_home "C:\dev\TensorRT-RTX-1.1.0.3" --cuda_home "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.9" --cmake_generator "Visual Studio 17 2022" --use_vcpkg 将 –tensorrt_home 和 –cuda_home 替换为 CUDA 和 TensorRT-RTX 安装的正确路径。

oneDNN

有关 oneDNN（以前称为 DNNL）的更多信息，请参阅此处。

构建说明

DNNL 执行提供者可以为 Intel CPU 或 GPU 构建。要为 Intel GPU 构建，请安装 Intel SDK for OpenCL Applications 或从 Khronos OpenCL SDK 构建 OpenCL。将 OpenCL SDK 路径作为 dnnl_opencl_root 传递给构建命令。安装最新的 GPU 驱动程序 - Windows 图形驱动程序，Linux 图形计算运行时和 OpenCL 驱动程序。

对于 CPU

Windows

.\build.bat --use_dnnl

Linux

./build.sh --use_dnnl

对于 GPU

Windows

.\build.bat --use_dnnl --dnnl_gpu_runtime ocl --dnnl_opencl_root "c:\program files (x86)\intelswtools\sw_dev_tools\opencl\sdk"

Linux

./build.sh --use_dnnl --dnnl_gpu_runtime ocl --dnnl_opencl_root "/opt/intel/sw_dev_tools/opencl-sdk"

构建 Python Wheel

OneDNN EP 构建支持使用 –build_wheel 标志为 Windows 和 Linux 构建 Python wheel

.\build.bat --config RelWithDebInfo --parallel --build_shared_lib --cmake_generator "Visual Studio 16 2019" --build_wheel --use_dnnl --dnnl_gpu_runtime ocl --dnnl_opencl_root "C:\Program Files (x86)\IntelSWTools\system_studio_2020\OpenCL\sdk"

---

OpenVINO

有关 OpenVINO™ 执行提供者的更多信息，请参阅此处。

先决条件

1. 从 Intel^® Distribution of OpenVINO™^TM Toolkit Release 2024.3 安装 OpenVINO™ 离线/在线安装程序，适用于相应的操作系统和目标硬件
   • Windows - CPU, GPU, NPU.
   • Linux - CPU, GPU, NPU

   有关详细说明，请遵循文档。

2024.5 是当前推荐的 OpenVINO™ 版本。OpenVINO™ 2024.5 是最低 OpenVINO™ 版本要求。

1. 使用特定后续说明配置目标硬件
   • 要配置 Intel^® Processor Graphics(GPU)，请遵循以下说明：Windows，Linux
2. 通过运行 setupvars 脚本初始化 OpenVINO™ 环境，如下所示。这是必需的步骤
   • 对于 Windows

      C:\<openvino_install_directory>\setupvars.bat
     

   • 对于 Linux

      $ source <openvino_install_directory>/setupvars.sh
     

     注意： 如果您正在使用 dockerfile 来使用 OpenVINO™ Execution Provider，在 dockerfile 中 sourcing OpenVINO™ 将不可能。您必须明确设置 LD_LIBRARY_PATH 以指向 OpenVINO™ 库的位置。请参考我们的dockerfile。

构建说明

Windows

.\build.bat --config RelWithDebInfo --use_openvino <hardware_option> --build_shared_lib --build_wheel

注意：默认的 Windows CMake Generator 是 Visual Studio 2019，但您也可以通过向 .\build.bat 传递 --cmake_generator "Visual Studio 17 2022" 来使用更新的 Visual Studio 2022。

Linux

./build.sh --config RelWithDebInfo --use_openvino <hardware_option> --build_shared_lib --build_wheel

• --build_wheel 在 dist/ 文件夹中创建 python wheel 文件。从源码构建时启用它。
• --use_openvino 在 ONNX Runtime 中构建 OpenVINO™ 执行提供者。
• <hardware_option>：指定构建 OpenVINO™ 执行提供者的默认硬件目标。这可以在运行时通过另一个选项动态覆盖（有关动态设备选择的更多详细信息，请参阅OpenVINO™-ExecutionProvider）。以下是不同 Intel 目标设备的选项。

请参阅Intel GPU 设备命名约定，以在集成和独立 GPU 共存的情况下指定正确的硬件目标。

硬件选项	目标设备
CPU	英特尔® CPU
GPU	英特尔® 集成显卡
GPU.0	英特尔® 集成显卡
GPU.1	英特尔® 独立显卡
NPU	英特尔® 神经网络处理器单元
HETERO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3...	上述所有英特尔® 芯片
MULTI:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3...	上述所有英特尔® 芯片
AUTO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3...	上述所有英特尔® 芯片

为 HETERO 或 Multi 或 AUTO 设备构建指定硬件目标

HETERO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3... DEVICE_TYPE 可以是此列表中的任何设备['CPU', 'GPU', 'NPU']

有效的 HETERO 或 MULTI 或 AUTO 设备构建应至少指定两个设备。

Example's: HETERO:GPU,CPU or AUTO:GPU,CPU or MULTI:GPU,CPU

禁用子图分区功能

• 构建 ONNX Runtime 中的 OpenVINO™ 执行提供者时禁用子图分区。

• 启用此选项后。完全支持的模型在 OpenVINO 执行提供者上运行，否则它们将完全回退到默认的 CPU EP。

• 要在构建时启用此功能。使用 --use_openvino <hardware_option>_NO_PARTITION

Usage: --use_openvino CPU_FP32_NO_PARTITION or --use_openvino GPU_FP32_NO_PARTITION or
       --use_openvino GPU_FP16_NO_PARTITION 

有关 OpenVINO™ 执行提供者的 ONNX 层支持、拓扑支持和启用的 Intel 硬件的更多信息，请参阅文档 OpenVINO™-ExecutionProvider

---

QNN

有关 QNN 执行提供者的更多信息，请参阅此处。

先决条件

• 安装 Qualcomm AI Engine Direct SDK (Qualcomm Neural Network SDK) Linux/Android/Windows

• 安装 cmake-3.28 或更高版本。

• 安装 Python 3.10 或更高版本。
  • 适用于 Windows Arm64 的 Python 3.12
  • 适用于 Windows x86-64 的 Python 3.12
  • 注意：Windows on Arm 通过仿真支持 x86-64 Python 环境。确保 Arm64 Python 环境已激活，以便进行原生 Arm64 ONNX Runtime 构建。

• 签出源码树

   git clone --recursive https://github.com/Microsoft/onnxruntime.git
   cd onnxruntime
  

• 安装 ONNX Runtime Python 依赖项。

   pip install -r requirements.txt
  

构建选项

• --use_qnn [QNN_LIBRARY_KIND]：构建 QNN 执行提供者。QNN_LIBRARY_KIND 是可选的，用于指定是构建 QNN 执行提供者为共享库（默认）还是静态库。
  • --use_qnn 或 --use_qnn shared_lib：将 QNN 执行提供者构建为共享库。
  • --use_qnn static_lib：将 QNN 执行提供者构建为静态库并链接到 ONNX Runtime 中。这是 Android 构建所必需的。
• --qnn_home QNN_SDK_PATH：Qualcomm AI Engine Direct SDK 的路径。
  • Windows 示例：--qnn_home 'C:\Qualcomm\AIStack\QAIRT\2.31.0.250130'
  • Linux 示例：--qnn_home /opt/qcom/aistack/qairt/2.31.0.250130
• --build_wheel：启用 Python 绑定并构建 Python wheel。
• --arm64：交叉编译为 Arm64。
• --arm64ec：交叉编译为 Arm64EC。Arm64EC 代码以原生性能运行，并与在 Windows on Arm 设备上同一进程中在仿真下运行的 x64 代码互操作。请参阅 Arm64EC 概述。

运行 python tools/ci_build/build.py --help 以获取所有可用构建选项的说明。

构建说明

Windows (原生 x86-64 或原生 Arm64)

.\build.bat --use_qnn --qnn_home [QNN_SDK_PATH] --build_shared_lib --build_wheel --cmake_generator "Visual Studio 17 2022" --config Release --parallel --skip_tests --build_dir build\Windows

注意

• 并非所有 Qualcomm 后端（例如 HTP）都支持在原生 x86-64 构建上执行模型。有关更多信息，请参阅 Qualcomm SDK 后端文档。
• 即使 Qualcomm 后端不支持在 x86-64 上执行，QNN 执行提供者也可能能够为 Qualcomm 后端生成编译后的模型。

Windows (Arm64 交叉编译目标)

.\build.bat --arm64 --use_qnn --qnn_home [QNN_SDK_PATH] --build_shared_lib --build_wheel --cmake_generator "Visual Studio 17 2022" --config Release --parallel --build_dir build\Windows

Windows (Arm64EC 交叉编译目标)

.\build.bat --arm64ec --use_qnn --qnn_home [QNN_SDK_PATH] --build_shared_lib --build_wheel --cmake_generator "Visual Studio 17 2022" --config Release --parallel --build_dir build\Windows

Windows (Arm64X 交叉编译目标)

使用 build_arm64x.bat 脚本构建 Arm64X 二进制文件。Arm64X 二进制文件捆绑了 Arm64 和 Arm64EC 代码，使 Arm64X 与 Windows on Arm 设备上的 Arm64 和 Arm64EC 进程兼容。请参阅 Arm64X PE 文件概述。

.\build_arm64x.bat --use_qnn --qnn_home [QNN_SDK_PATH] --build_shared_lib --cmake_generator "Visual Studio 17 2022" --config Release --parallel

注意

• 不要指定 --build_dir 选项，因为 build_arm64x.bat 设置了特定的构建目录。
• 上述命令将 Arm64X 二进制文件放置在 .\build\arm64ec-x\Release\Release\ 目录下。

Linux (x86_64)

./build.sh --use_qnn --qnn_home [QNN_SDK_PATH] --build_shared_lib --build_wheel --config Release --parallel --skip_tests --build_dir build/Linux

Android (交叉编译)

请参考为 Android 构建 OnnxRuntime

# on Windows
.\build.bat --build_shared_lib --android --config Release --parallel --use_qnn static_lib --qnn_home [QNN_SDK_PATH] --android_sdk_path [android_SDK path] --android_ndk_path [android_NDK path] --android_abi arm64-v8a --android_api [api-version] --cmake_generator Ninja --build_dir build\Android

# on Linux
./build.sh --build_shared_lib --android --config Release --parallel --use_qnn static_lib --qnn_home [QNN_SDK_PATH] --android_sdk_path [android_SDK path] --android_ndk_path [android_NDK path] --android_abi arm64-v8a --android_api [api-version] --cmake_generator Ninja --build_dir build/Android

---

DirectML

有关 DirectML 执行提供者的更多信息，请参阅此处。

Windows

.\build.bat --use_dml

注意

DirectML 执行提供者支持为 x64 和 x86 架构构建。DirectML 仅在 Windows 上受支持。

---

Arm 计算库

有关 ACL 执行提供者的更多信息，请参阅此处。

构建说明

您必须首先按照文档中所述，为您的平台构建 Arm Compute Library 24.07。有关为基于 Arm® 的设备构建的信息，请参见此处。

向 build.sh 添加以下选项以启用 ACL 执行提供者

--use_acl --acl_home=/path/to/ComputeLibrary --acl_libs=/path/to/ComputeLibrary/build

Arm NN

有关 Arm NN 执行提供者的更多信息，请参阅此处。

先决条件

• 支持的后端：i.MX8QM Armv8 CPU
• 支持的 BSP：i.MX8QM BSP
  • 安装 i.MX8QM BSP：source fsl-imx-xwayland-glibc-x86_64-fsl-image-qt5-aarch64-toolchain-4*.sh
• 设置构建环境

source /opt/fsl-imx-xwayland/4.*/environment-setup-aarch64-poky-linux
alias cmake="/usr/bin/cmake -DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake"

• 有关为基于 Arm 的设备构建的信息，请参见此处

构建说明

./build.sh --use_armnn

Relu 操作符默认设置为使用 CPU 执行提供者以获得更好的性能。要使用 Arm NN 实现，请使用 –armnn_relu 标志构建

./build.sh --use_armnn --armnn_relu

批归一化操作符默认设置为使用 CPU 执行提供者。要使用 Arm NN 实现，请使用 –armnn_bn 标志构建

./build.sh --use_armnn --armnn_bn

要在正常环境之外使用库，您可以通过提供 –armnn_home 和 –armnn_libs 参数来定义 Arm NN 主目录和构建目录的路径来设置自定义路径。Arm Compute Library 主目录和构建目录也必须可用，如果需要，可以使用 –acl_home 和 –acl_libs 分别指定。

./build.sh --use_armnn --armnn_home /path/to/armnn --armnn_libs /path/to/armnn/build  --acl_home /path/to/ComputeLibrary --acl_libs /path/to/acl/build

---

RKNPU

有关 RKNPU 执行提供者的更多信息，请参阅此处。

先决条件

• 支持平台：RK1808 Linux
• 有关为基于 Arm 的设备构建的信息，请参见此处
• 使用 gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu 而不是 gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf，并修改 tool.cmake 中的 CMAKE_CXX_COMPILER & CMAKE_C_COMPILER

set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)

构建说明

Linux

1. 下载 rknpu_ddk 到任意目录。

2. 构建 ONNX Runtime 库并测试

    ./build.sh --arm --use_rknpu --parallel --build_shared_lib --build_dir build_arm --config MinSizeRel --cmake_extra_defines RKNPU_DDK_PATH=<Path To rknpu_ddk> CMAKE_TOOLCHAIN_FILE=<Path To tool.cmake> ONNX_CUSTOM_PROTOC_EXECUTABLE=<Path To protoc>
   

3. 在 RK1808 开发板上部署 ONNX runtime 和 librknpu_ddk.so

    libonnxruntime.so.1.2.0
    onnxruntime_test_all
    rknpu_ddk/lib64/librknpu_ddk.so
   

---

AMD Vitis AI

有关 Vitis AI 执行提供者的更多信息，请参阅此处。

Windows

从 Visual Studio Developer Command Prompt 或 Developer PowerShell，执行以下命令

.\build.bat --use_vitisai --build_shared_lib --parallel --config Release

如果您希望利用 Python API，请包含 --build_wheel 标志

.\build.bat --use_vitisai --build_shared_lib --parallel --config Release --build_wheel

您还可以通过 cmake_extra_defines 参数指定 CMAKE_INSTALL_PREFIX 来覆盖安装位置。例如：

.\build.bat --use_vitisai --build_shared_lib --parallel --config Release --cmake_extra_defines CMAKE_INSTALL_PREFIX=D:\onnxruntime

Linux

目前，Linux 支持仅限于 AMD Adapable SoC。请参考此处的 SoC 目标指南。

---

AMD MIGraphX

有关 MIGraphX 执行提供者的更多信息，请参阅此处。

先决条件

• 安装 ROCm
  • ONNX Runtime 的 MIGraphX 执行提供者是使用 ROCm6.3.1 构建和测试的。
• 安装 MIGraphX
  • MIGraphX 安装路径必须通过 --migraphx_home parameter 提供。

构建说明

Linux

./build.sh --config <Release|Debug|RelWithDebInfo> --parallel --use_migraphx --migraphx_home <path to MIGraphX home>

Dockerfile 说明可在此处获取。

构建 Python Wheel

./build.sh --config Release --build_wheel --parallel --use_migraphx --migraphx_home /opt/rocm

然后可以在 ./build/Linux/Release/dist 中找到 python wheels(*.whl)。

---

AMD ROCm

有关 ROCm 执行提供者的更多信息，请参阅此处。

先决条件

• 安装 ROCm
  • ONNX Runtime 的 ROCm 执行提供者是使用 ROCm6.3.1 构建和测试的。

构建说明

Linux

./build.sh --config <Release|Debug|RelWithDebInfo> --parallel --use_rocm --rocm_home <path to ROCm home>

Dockerfile 说明可在此处获取。

构建 Python Wheel

./build.sh --config Release --build_wheel --parallel --use_rocm --rocm_home /opt/rocm

然后可以在 ./build/Linux/Release/dist 中找到 python wheels(*.whl)。

---

NNAPI

在 Android 平台上使用 NNAPI 是通过 NNAPI 执行提供者（EP）实现的。

有关更多详细信息，请参阅 NNAPI 执行提供者文档。

适用于 Android 的预构建 ONNX Runtime Mobile 包包含 NNAPI EP。

如果执行 ONNX Runtime 的自定义构建，则必须在构建时启用对 NNAPI EP 或 CoreML EP 的支持。

创建支持 NNAPI EP 的最小构建

请参阅说明以设置构建所需的 Android 环境。Android 构建可以在 Windows 或 Linux 上进行交叉编译。

设置所有必要的组件后，请遵循创建自定义构建的说明，并进行以下更改

• 将 --minimal_build 替换为 --minimal_build extended 以启用对在运行时动态创建内核的执行提供者的支持，这是 NNAPI EP 所需的。
• 添加 --use_nnapi 以在构建中包含 NNAPI EP

启用 NNAPI EP 的构建命令示例

Windows 示例

<ONNX Runtime repository root>.\build.bat --config MinSizeRel --android --android_sdk_path D:\Android --android_ndk_path D:\Android\ndk\21.1.6352462\ --android_abi arm64-v8a --android_api 29 --cmake_generator Ninja --minimal_build extended --use_nnapi --disable_ml_ops --disable_exceptions --build_shared_lib --skip_tests --include_ops_by_config <config file from model conversion>

Linux 示例

<ONNX Runtime repository root>./build.sh --config MinSizeRel --android --android_sdk_path /Android --android_ndk_path /Android/ndk/21.1.6352462/ --android_abi arm64-v8a --android_api 29 --minimal_build extended --use_nnapi --disable_ml_ops --disable_exceptions --build_shared_lib --skip_tests --include_ops_by_config <config file from model conversion>`

CoreML

在 iOS 和 macOS 平台上使用 CoreML 是通过 CoreML EP 实现的。

有关更多详细信息，请参阅 CoreML 执行提供者文档。

适用于 iOS 的预构建 ONNX Runtime Mobile 包包含 CoreML EP。

创建支持 CoreML EP 的最小构建

请参阅说明以设置构建所需的 iOS 环境。iOS/macOS 构建必须在 Mac 机器上执行。

设置所有必要的组件后，请遵循创建自定义构建的说明，并进行以下更改

• 将 --minimal_build 替换为 --minimal_build extended 以启用对在运行时动态创建内核的执行提供者的支持，这是 CoreML EP 所需的。
• 添加 --use_coreml 以在构建中包含 CoreML EP

XNNPACK

在 Android/iOS/Windows/Linux 平台上使用 XNNPACK 是通过 XNNPACK EP 实现的。

有关更多详细信息，请参阅 XNNPACK 执行提供者文档。

适用于 Android 的预构建 ONNX Runtime 包（onnxruntime-android）包含 XNNPACK EP。

适用于 iOS 的预构建 ONNX Runtime Mobile 包，在 CocoaPods 中的 onnxruntime-c 和 onnxruntime-objc，包含 XNNPACK EP。（带 XNNPACK 的 onnxruntime-objc 包将从 1.14 版开始提供。）

如果执行 ONNX Runtime 的自定义构建，则必须在构建时启用对 XNNPACK EP 的支持。

构建用于 Android

创建支持 XNNPACK EP 的最小构建

请参阅说明以设置构建所需的 Android 环境。Android 构建可以在 Windows 或 Linux 上进行交叉编译。

设置所有必要的组件后，请遵循创建自定义构建的说明，并进行以下更改

• 将 --minimal_build 替换为 --minimal_build extended 以启用对在运行时动态创建内核的执行提供者的支持，这是 XNNPACK EP 所需的。
• 添加 --use_xnnpack 以在构建中包含 XNNPACK EP

启用 XNNPACK EP 的构建命令示例

Windows 示例

<ONNX Runtime repository root>.\build.bat --config MinSizeRel --android --android_sdk_path D:\Android --android_ndk_path D:\Android\ndk\21.1.6352462\ --android_abi arm64-v8a --android_api 29 --cmake_generator Ninja --minimal_build extended --use_xnnpack --disable_ml_ops --disable_exceptions --build_shared_lib --skip_tests --include_ops_by_config <config file from model conversion>

Linux 示例

<ONNX Runtime repository root>./build.sh --config MinSizeRel --android --android_sdk_path /Android --android_ndk_path /Android/ndk/21.1.6352462/ --android_abi arm64-v8a --android_api 29 --minimal_build extended --use_xnnpack --disable_ml_ops --disable_exceptions --build_shared_lib --skip_tests --include_ops_by_config <config file from model conversion>`

如果您不介意 MINIMAL 构建，可以使用以下命令为 Android 构建 XNNPACK EP：Linux 示例

./build.sh --cmake_generator "Ninja" --android  --android_sdk_path /Android --android_ndk_path /Android/ndk/21.1.6352462/ --android_abi arm64-v8a --android_api 29 --use_xnnpack

构建用于 iOS（从 1.14 版开始可用）

构建 iOS 包需要 Mac 机器。请首先遵循此指南设置环境。

创建支持 XNNPACK EP 的最小构建

设置所有必要的组件后，请遵循创建自定义构建的说明，并进行以下更改

• 将 --minimal_build 替换为 --minimal_build extended 以启用对在运行时动态创建内核的执行提供者的支持，这是 XNNPACK EP 所需的。
• 添加 --use_xnnpack 以在构建中包含 XNNPACK EP

<ONNX Runtime repository root>./build.sh --config <Release|Debug|RelWithDebInfo|MinSizeRel> --use_xcode \
           --ios --ios_sysroot iphoneos --osx_arch arm64 --apple_deploy_target <minimal iOS version> --use_xnnpack --minimal_build extended --disable_ml_ops --disable_exceptions --build_shared_lib --skip_tests --include_ops_by_config <config file from model conversion>

构建用于 Windows

<ONNX Runtime repository root>.\build.bat --config <Release|Debug|RelWithDebInfo> --use_xnnpack

构建用于 Linux

<ONNX Runtime repository root>./build.sh --config <Release|Debug|RelWithDebInfo> --use_xnnpack

---

CANN

有关 CANN 执行提供者的更多信息，请参阅此处。

先决条件

1. 请遵循文档，安装适用于相应操作系统和目标硬件的 CANN 工具包，以获取详细说明。

2. 通过运行以下脚本初始化 CANN 环境。

   # Default path, change it if needed.
   source /usr/local/Ascend/ascend-toolkit/set_env.sh
   

构建说明

Linux

./build.sh --config <Release|Debug|RelWithDebInfo> --build_shared_lib --parallel --use_cann

注意

• CANN 执行提供者支持为 x64 和 aarch64 架构构建。
• CANN 执行提供者目前仅支持 Linux。

Azure

有关 Azure 执行提供者的更多详细信息，请参阅此处。

先决条件

对于 Linux，在构建之前，请

• 在系统中安装 openssl dev 包，对于 redhat 是 openssl-dev，对于 ubuntu 是 libssl-dev。
• 如果系统安装了多个 openssl dev 版本，请将环境变量“OPENSSL_ROOT_DIR”设置为所需版本，例如

set OPENSSL_ROOT_DIR=/usr/local/ssl3.x/

构建说明

Windows

build.bat --config <Release|Debug|RelWithDebInfo> --build_shared_lib --build_wheel --use_azure

Linux

./build.sh --config <Release|Debug|RelWithDebInfo> --build_shared_lib --build_wheel --use_azure