ONNX Runtime mit Execution Providern erstellen

Inhalt

Execution Provider Shared Libraries

Die oneDNN-, TensorRT-, OpenVINO™-, CANN- und QNN-Provider werden als Shared Libraries erstellt und nicht statisch in die Haupt-onnxruntime integriert. Dies ermöglicht es ihnen, nur bei Bedarf geladen zu werden. Wenn die abhängigen Bibliotheken des Providers nicht installiert sind, läuft onnxruntime trotzdem, kann diesen Provider nur nicht nutzen. Für Nicht-Shared-Library-Provider müssen alle Abhängigkeiten des Providers vorhanden sein, um onnxruntime zu laden.

Erstellte Dateien

Unter Windows heißen Shared Provider Libraries ‘onnxruntime_providers_*.dll’ (z. B. onnxruntime_providers_openvino.dll). Unter Unix heißen sie ‘libonnxruntime_providers_*.so’. Auf Mac heißen sie ‘libonnxruntime_providers_*.dylib’.

Es gibt auch eine Shared Library, von der Shared Provider abhängen, namens onnxruntime_providers_shared (mit der gleichen Namenskonvention wie oben).

Hinweis: Es wird nicht empfohlen, diese Bibliotheken an einem Systemort abzulegen oder zu einem Bibliotheks-Suchpfad (wie LD_LIBRARY_PATH unter Unix) hinzuzufügen. Wenn mehrere Versionen von onnxruntime auf dem System installiert sind, können diese die falschen Bibliotheken finden und zu undefiniertem Verhalten führen.

Laden der Shared Provider

Shared Provider Libraries werden vom onnxruntime-Code geladen (laden oder von ihnen in Ihrem Client-Code abhängen Sie nicht). Die API zum Registrieren von Shared oder Nicht-Shared Providern ist identisch. Der Unterschied besteht darin, dass Shared Provider zur Laufzeit geladen werden, wenn der Provider zu den Session-Optionen hinzugefügt wird (durch einen Aufruf wie OrtSessionOptionsAppendExecutionProvider_OpenVINO oder SessionOptionsAppendExecutionProvider_OpenVINO in der C-API). Wenn eine Shared Provider Library nicht geladen werden kann (wenn die Datei nicht existiert oder ihre Abhängigkeiten nicht existieren oder nicht im Pfad sind), wird ein Fehler zurückgegeben.

Der onnxruntime-Code sucht nach den Provider Shared Libraries am selben Ort wie die onnxruntime Shared Library (oder die ausführbare Datei, die statisch mit der statischen Bibliotheksversion verknüpft ist).

CUDA

Voraussetzungen

  • Installieren Sie CUDA und cuDNN
    • Der CUDA Execution Provider für ONNX Runtime wird mit CUDA 12.x und cuDNN 9 erstellt und getestet. Weitere Versionsinformationen finden Sie hier.
    • Der Pfad zur CUDA-Installation muss über die Umgebungsvariable CUDA_HOME oder den Parameter --cuda_home angegeben werden. Das Installationsverzeichnis sollte die Unterverzeichnisse bin, include und lib enthalten.
    • Der Pfad zum bin-Verzeichnis von CUDA muss zur PATH-Umgebungsvariable hinzugefügt werden, damit nvcc gefunden wird.
    • Der Pfad zur cuDNN-Installation muss über die Umgebungsvariable CUDNN_HOME oder den Parameter --cudnn_home angegeben werden. Unter Windows sollte das Installationsverzeichnis die Unterverzeichnisse bin, include und lib enthalten.
    • cuDNN 8.* benötigt ZLib. Befolgen Sie die Installationsanleitung für cuDNN 8.9, um zlib unter Linux oder Windows zu installieren.
    • Unter Windows muss der Pfad zum cuDNN bin-Verzeichnis zur PATH-Umgebungsvariable hinzugefügt werden, damit cudnn64_8.dll gefunden wird.

Bauanleitungen

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>

Ein Dockerfile ist hier verfügbar.

Build-Optionen

Um GPU-Architekturen anzugeben (siehe Compute Capability), können Sie Parameter wie --cmake_extra_defines CMAKE_CUDA_ARCHITECTURES=80;86;89 hinzufügen.

Mit --cmake_extra_defines onnxruntime_USE_CUDA_NHWC_OPS=ON kann der CUDA EP mit zusätzlichen NHWC-Operationen kompiliert werden. Diese Option ist standardmäßig nicht aktiviert, da nur eine geringe Anzahl von NHWC-Operatoren unterstützt wird.

Eine weitere sehr hilfreiche CMake-Build-Option ist das Bauen mit NVTX-Unterstützung (--cmake_extra_defines onnxruntime_ENABLE_NVTX_PROFILE=ON), was ein wesentlich einfacheres Profiling mit Nsight Systems ermöglicht und CUDA-Kernel mit ihrem tatsächlichen ONNX-Operator korreliert.

--enable_cuda_line_info oder --cmake_extra_defines onnxruntime_ENABLE_CUDA_LINE_NUMBER_INFO=ON aktiviert die NVCC-Generierung von Zeileninformationsdaten für den Gerätcode. Dies kann hilfreich sein, wenn Sie Compute Sanitizer-Tools für CUDA-Kernel verwenden.

Wenn Ihr Windows-Computer mehrere CUDA-Versionen installiert hat und Sie eine ältere CUDA-Version verwenden möchten, müssen Sie Parameter wie --cuda_version <cuda version> hinzufügen.

Wenn Ihr Build-Computer über viele CPU-Kerne und weniger als 64 GB Speicher verfügt, besteht die Möglichkeit eines Speicherfehlers wie nvcc error : 'cicc' died due to signal 9. Die Lösung besteht darin, die Anzahl paralleler NVCC-Threads mit Parametern wie --parallel 4 --nvcc_threads 1 zu begrenzen.

Hinweise zu älteren Versionen von ONNX Runtime, CUDA und Visual Studio

  • Abhängig von der Kompatibilität zwischen den CUDA-, cuDNN- und Visual Studio-Versionen, die Sie verwenden, müssen Sie möglicherweise explizit eine frühere Version des MSVC-Toolsets installieren.
  • Für ältere Versionen von ONNX Runtime und CUDA sowie Visual Studio
    • CUDA 10.0 funktioniert bekanntermaßen mit Toolsets von 14.11 bis 14.16 (Visual Studio 2017 15.9) und sollte auch mit zukünftigen Visual Studio-Versionen funktionieren.
    • CUDA 9.2 funktioniert bekanntermaßen mit dem MSVC-Toolset 14.11 (Visual Studio 15.3 und 15.4).
      • Um das MSVC-Toolset 14.11 zu installieren, siehe diese Seite.
      • Um das Toolset 14.11 mit einer neueren Version von Visual Studio 2017 zu verwenden, haben Sie zwei Möglichkeiten:

        1. Konfigurieren Sie die Visual Studio-Umgebungsvariablen so, dass sie auf das Toolset 14.11 verweisen, indem Sie vcvarsall.bat ausführen, bevor Sie das Build-Skript ausführen. Beispiel: Wenn Sie VS2017 Enterprise haben, würde ein x64-Build den folgenden Befehl verwenden: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" amd64 -vcvars_ver=14.11. Zum Bequemlichkeit halber erledigt .\build.amd64.1411.bat dies und kann auf die gleiche Weise wie .\build.bat verwendet werden. z. B. ` .\build.amd64.1411.bat –use_cuda`

        2. Alternativ können Sie, wenn Sie CMake 3.13 oder neuer haben, die Toolset-Version über den Build-Skript-Parameter --msvc_toolset angeben. Beispiel: `.\build.bat --msvc_toolset 14.11`

  • Wenn Sie mehrere CUDA-Versionen auf einem Windows-Computer installiert haben und mit Visual Studio bauen, verwendet CMake die Build-Dateien für die höchste CUDA-Version, die es im Verzeichnis BuildCustomizations findet. Beispiel: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\BuildCustomizations. Wenn Sie mit einer früheren Version bauen möchten, müssen Sie die Dateien 'CUDA x.y.*' für spätere Versionen vorübergehend aus diesem Verzeichnis entfernen.

TensorRT

Weitere Informationen zum TensorRT Execution Provider finden Sie hier.

Voraussetzungen

  • Befolgen Sie die Anweisungen für den CUDA Execution Provider, um CUDA und cuDNN zu installieren und Umgebungsvariablen einzurichten.
  • Befolgen Sie die Anweisungen zur Installation von TensorRT
    • Der TensorRT Execution Provider für ONNX Runtime wird mit TensorRT 10.9 erstellt und getestet.
    • Der Pfad zur TensorRT-Installation muss über den Parameter --tensorrt_home angegeben werden.
    • ONNX Runtime verwendet den TensorRT integrierten Parser aus tensorrt_home standardmäßig.
    • Um stattdessen den Open-Source-Parser onnx-tensorrt zu verwenden, fügen Sie den Parameter --use_tensorrt_oss_parser zu den unten stehenden Build-Befehlen hinzu.
      • Die Standardversion des Open-Source onnx-tensorrt Parsers ist in cmake/deps.txt angegeben.
      • Um eine andere Version des onnx-tensorrt Parsers anzugeben
        • Wählen Sie den Commit von onnx-tensorrt, den Sie bevorzugen;
        • Führen Sie den Befehl sha1sum mit der heruntergeladenen onnx-tensorrt ZIP-Datei aus, um den SHA1-Hash zu erhalten.
        • Aktualisieren Sie cmake/deps.txt mit dem aktualisierten onnx-tensorrt Commit und den Hash-Informationen.
      • Bitte stellen Sie sicher, dass der TensorRT integrierte Parser/Open-Source onnx-tensorrt, der in cmake/deps.txt angegeben ist, *versionstechnisch abgestimmt* ist, wenn --use_tensorrt_oss_parser aktiviert ist.
        • D. h. es ist versionstechnisch abgestimmt, wenn tensorrt_home mit dem Pfad zu TensorRT-10.9 integrierten Binärdateien und onnx-tensorrt 10.9-GA Branch in cmake/deps.txt zugewiesen wird.

**[Hinweis für ORT 1.21/1.22 Open-Source-Parser-Benutzer]**

  • ORT 1.21/1.22 verknüpfen mit onnx-tensorrt 10.8-GA/10.9-GA, was das neu veröffentlichte onnx 1.18 erfordert.
    • Hier ist eine vorübergehende Korrektur zur Vorschau auf onnx-tensorrt 10.8-GA/10.9-GA beim Erstellen von ORT 1.21/1.22
      • Ersetzen Sie die onnx-Zeile in cmake/deps.txt mit onnx;https://github.com/onnx/onnx/archive/e709452ef2bbc1d113faf678c24e6d3467696e83.zip;c0b9f6c29029e13dea46b7419f3813f4c2ca7db8
      • Laden Sie dies als Rohdatei herunter und speichern Sie die Datei in cmake/patches/onnx/onnx.patch (kopieren/einfügen nicht aus dem Browser, da dies den Zeilenumbruchtyp ändern könnte)
      • Bauen Sie ORT mit den oben genannten trt-bezogenen Flags (einschließlich --use_tensorrt_oss_parser)
    • Das onnx 1.18 wird vom neuesten ORT-Hauptzweig unterstützt. Bitte überprüfen Sie den Hauptzweig und erstellen Sie ORT-TRT mit --use_tensorrt_oss_parser, um den OSS-Parser mit voller onnx 1.18-Unterstützung zu aktivieren.

Bauanleitungen

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-Anweisungen sind hier verfügbar

**Hinweis:** Das Erstellen mit --use_tensorrt_oss_parser mit TensorRT 8.X erfordert das zusätzliche Flag –cmake_extra_defines onnxruntime_USE_FULL_PROTOBUF=ON

NVIDIA Jetson TX1/TX2/Nano/Xavier/Orin

Build-Anweisungen

Diese Anweisungen gelten für das neueste JetPack SDK.

  1. Klonen Sie das ONNX Runtime Repository auf dem Jetson Host.

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

  2. Geben Sie den CUDA-Compiler an oder fügen Sie seinen Speicherort zum PATH hinzu.

    1. JetPack 5.x-Benutzer können auf die neueste CUDA-Version aktualisieren, ohne die JetPack-Version oder das Jetson Linux BSP (Board Support Package) zu aktualisieren.

      1. Für JetPack 5.x-Benutzer sind CUDA>=11.8 und GCC>9.4 erforderlich, die ab ONNX Runtime 1.17 installiert werden müssen.

      2. Schauen Sie in diesem offiziellen Blog nach Anweisungen zum CUDA-Upgrade (CUDA 12.2 wurde auf JetPack 5.1.2 auf Jetson Xavier NX verifiziert).

        1. Wenn unter /usr/local/cuda-12.2/compat kein libnvcudla.so vorhanden ist: sudo apt-get install -y cuda-compat-12-2 und fügen Sie export LD_LIBRARY_PATH="/usr/local/cuda-12.2/lib64:/usr/local/cuda-12.2/compat:$LD_LIBRARY_PATH" zu ~/.bashrc hinzu.

      3. Sehen Sie hier nach dem Datenblatt zur Compute Capability.

    2. CMake kann nvcc nicht automatisch finden, wenn es nicht im PATH ist. nvcc kann über

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

      oder

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

    3. TensorRT-Bibliotheken aktualisieren

      1. Jetpack 5.x unterstützt bis zu TensorRT 8.5. Jetpack 6.x ist mit TensorRT 8.6-10.3 ausgestattet.

      2. Jetpack 6.x-Benutzer können das neueste TensorRT 10 TAR-Paket für *jetpack* auf der TensorRT SDK-Website herunterladen.

      3. Prüfen Sie hier auf die TensorRT/CUDA-Supportmatrix aller ONNX Runtime-Versionen.

  3. Installieren Sie die ONNX Runtime Build-Abhängigkeiten auf dem Jetpack Host.

    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. Cmake wird benötigt, um ONNX Runtime zu erstellen. Bitte prüfen Sie die minimal erforderliche CMake-Version hier. Herunterladen von https://cmake.org/download/ und Hinzufügen der cmake-ausführbaren Datei zum PATH, um sie zu verwenden.

  5. Erstellen Sie das ONNX Runtime Python Wheel.

    1. Erstellen Sie das onnxruntime-gpu Wheel mit CUDA- und TensorRT-Unterstützung (aktualisieren Sie die Pfade zu CUDA/CUDNN/TensorRT-Bibliotheken bei Bedarf).

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

​ Hinweise

  • Standardmäßig wird die onnxruntime-gpu Wheel-Datei unter path_to/onnxruntime/build/Linux/Release/dist/ erfasst (der Build-Pfad kann durch Hinzufügen von --build_dir gefolgt von einem benutzerdefinierten Pfad zum obigen Build-Befehl angepasst werden).

  • Fügen Sie --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' zum Build-Befehl hinzu, um optionale Funktionen auszuschließen und die Build-Zeit zu reduzieren.

  • Für einen Teil der Jetson-Geräte wie die Xavier-Serie verbraucht der Hochleistungsmodus mehr Ressourcen beim Erstellen von ONNX Runtime, da er mehr Kerne (bis zu 6) zur Berechnung verwendet. Setzen Sie --parallel 1 im Build-Befehl, wenn OOM auftritt und das System hängt.

TensorRT-RTX

Weitere Informationen zum NV TensorRT RTX Execution Provider finden Sie hier.

Voraussetzungen

Build-Anweisungen

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" Ersetzen Sie --tensorrt_home und --cuda_home durch die korrekten Pfade zu den CUDA- und TensorRT-RTX-Installationen.

oneDNN

Weitere Informationen zu oneDNN (früher DNNL) finden Sie hier.

Build-Anweisungen

Der DNNL Execution Provider kann für Intel CPU oder GPU erstellt werden. Um für Intel GPU zu bauen, installieren Sie das Intel SDK for OpenCL Applications oder bauen Sie OpenCL aus dem Khronos OpenCL SDK. Übergeben Sie den Pfad zum OpenCL SDK als dnnl_opencl_root an den Build-Befehl. Installieren Sie den neuesten GPU-Treiber – Windows-Grafiktreiber, Linux-Grafik-Compute-Laufzeitumgebung und OpenCL-Treiber.

Für CPU

Windows

.\build.bat --use_dnnl

Linux

./build.sh --use_dnnl

Für 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 erstellen

Der OneDNN EP-Build unterstützt das Erstellen von Python Wheels sowohl für Windows als auch für Linux mit dem Flag –build_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

Weitere Informationen zum OpenVINO™ Execution Provider finden Sie hier.

Voraussetzungen

  1. Installieren Sie den OpenVINO™ Offline/Online-Installer von der **Release 2024.3** der Intel® Distribution of OpenVINO™ Toolkit für das entsprechende Betriebssystem und die Zielhardware.

    Befolgen Sie die Dokumentation für detaillierte Anweisungen.

2024.5 ist die derzeit empfohlene OpenVINO™-Version. OpenVINO™ 2024.5 ist die minimale OpenVINO™-Versionsanforderung.

  1. Konfigurieren Sie die Zielhardware mit spezifischen nachfolgenden Anweisungen.
    • Um Intel® Processor Graphics (GPU) zu konfigurieren, befolgen Sie bitte diese Anweisungen: Windows, Linux.
  2. Initialisieren Sie die OpenVINO™-Umgebung, indem Sie das setupvars-Skript wie unten gezeigt ausführen. Dies ist ein erforderlicher Schritt.
    • Für Windows
       C:\<openvino_install_directory>\setupvars.bat
    • Für Linux
       $ source <openvino_install_directory>/setupvars.sh

      **Hinweis:** Wenn Sie ein Dockerfile zur Verwendung des OpenVINO™ Execution Provider verwenden, ist das Sourcing von OpenVINO™ im Dockerfile nicht möglich. Sie müssen den LD_LIBRARY_PATH explizit festlegen, um auf den Speicherort der OpenVINO™-Bibliotheken zu verweisen. Sehen Sie sich unser Dockerfile an.

Build-Anweisungen

Windows

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

Hinweis: Der Standard-Windows-CMake-Generator ist Visual Studio 2019, aber Sie können auch das neuere Visual Studio 2022 verwenden, indem Sie --cmake_generator "Visual Studio 17 2022" an .\build.bat übergeben.

Linux

./build.sh --config RelWithDebInfo --use_openvino <hardware_option> --build_shared_lib --build_wheel
  • --build_wheel: Erstellt eine Python-Wheel-Datei im dist/-Ordner. Aktivieren Sie diese Option beim Erstellen aus der Quelle.
  • --use_openvino: Erstellt den OpenVINO™ Execution Provider in ONNX Runtime.
  • <hardware_option>: Gibt das Standard-Hardwareziel für die Erstellung des OpenVINO™ Execution Provider an. Dies kann zur Laufzeit dynamisch mit einer anderen Option überschrieben werden (siehe OpenVINO™-ExecutionProvider für weitere Details zur dynamischen Geräteselection). Nachfolgend sind die Optionen für verschiedene Intel-Zielgeräte aufgeführt.

Beachten Sie die Benennungskonvention für Intel-GPU-Geräte, um das richtige Hardwareziel anzugeben, wenn integrierte und diskrete GPUs koexistieren.

Hardware-Option Zielgerät
CPU Intel® CPUs
GPU Intel® integrierte Grafik
GPU.0 Intel® integrierte Grafik
GPU.1 Intel® diskrete Grafik
NPU Intel® Neural Processor Unit
HETERO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3... Alle oben genannten Intel® Siliziumchips
MULTI:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3... Alle oben genannten Intel® Siliziumchips
AUTO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3... Alle oben genannten Intel® Siliziumchips

Festlegen des Hardwareziels für HETERO-, Multi- oder AUTO-Geräte-Builds

HETERO:DEVICE_TYPE_1,DEVICE_TYPE_2,DEVICE_TYPE_3… Die DEVICE_TYPE kann eines dieser Geräte aus dieser Liste sein [‘CPU’,’GPU’, ‘NPU’]

Mindestens zwei Geräte müssen für einen gültigen HETERO-, MULTI- oder AUTO-Geräte-Build angegeben werden.

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

Untergraph-Partitionierungsfunktion deaktivieren

  • Erstellt den OpenVINO™ Execution Provider in ONNX Runtime mit deaktivierter Untergraph-Partitionierung.

  • Mit aktivierter Option. Vollständig unterstützte Modelle laufen auf dem OpenVINO Execution Provider, andernfalls fallen sie vollständig auf den Standard-CPU-EP zurück.

  • Um diese Funktion während der Erstellung zu aktivieren. Verwenden Sie --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

Weitere Informationen zur ONNX Layer-Unterstützung, Topologie-Unterstützung und Intel-Hardware-Unterstützung des OpenVINO™ Execution Provider finden Sie im Dokument OpenVINO™-ExecutionProvider.

QNN

Weitere Informationen zum QNN Execution Provider finden Sie hier.

Voraussetzungen

  • Installieren Sie das Qualcomm AI Engine Direct SDK (Qualcomm Neural Network SDK) Linux/Android/Windows

  • Installieren Sie cmake-3.28 oder höher.

  • Installieren Sie Python 3.10 oder höher.

  • Source-Baum auschecken

     git clone --recursive https://github.com/Microsoft/onnxruntime.git
 cd onnxruntime
  • Installieren Sie ONNX Runtime Python-Abhängigkeiten.
     pip install -r requirements.txt

Build-Optionen

  • --use_qnn [QNN_LIBRARY_KIND]: Erstellt den QNN Execution Provider. QNN_LIBRARY_KIND ist optional und gibt an, ob der QNN Execution Provider als Shared Library (Standard) oder statische Library erstellt werden soll.
    • --use_qnn oder --use_qnn shared_lib: Erstellt den QNN Execution Provider als Shared Library.
    • --use_qnn static_lib: Erstellt den QNN Execution Provider als statische Library, die in ONNX Runtime integriert wird. Dies ist für Android-Builds erforderlich.
  • --qnn_home QNN_SDK_PATH: Der Pfad zum Qualcomm AI Engine Direct SDK.
    • Beispiel unter Windows: --qnn_home 'C:\Qualcomm\AIStack\QAIRT\2.31.0.250130'
    • Beispiel unter Linux: --qnn_home /opt/qcom/aistack/qairt/2.31.0.250130
  • --build_wheel: Aktiviert Python-Bindungen und erstellt eine Python Wheel.
  • --arm64: Cross-Compile für Arm64.
  • --arm64ec: Cross-Compile für Arm64EC. Arm64EC-Code läuft mit nativer Leistung und ist mit x64-Code, der unter Emulation innerhalb desselben Prozesses auf einem Windows on Arm-Gerät läuft, interoperabel. Siehe die Arm64EC Übersicht.

Führen Sie python tools/ci_build/build.py --help aus, um eine Beschreibung aller verfügbaren Build-Optionen zu erhalten.

Build-Anweisungen

Windows (native x86-64 oder native 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

Hinweise

  • Nicht alle Qualcomm-Backends (z.B. HTP) werden für die Modellausführung auf einem nativen x86-64-Build unterstützt. Informationen hierzu finden Sie in der Qualcomm SDK Backend-Dokumentation.
  • Auch wenn ein Qualcomm-Backend keine Ausführung auf x86-64 unterstützt, kann der QNN Execution Provider kompilierte Modelle für das Qualcomm-Backend generieren.

Windows (Arm64 Cross-Compile-Ziel)

.\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 Cross-Compile-Ziel)

.\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 Cross-Compile-Ziel)

Verwenden Sie das Skript build_arm64x.bat, um Arm64X-Binärdateien zu erstellen. Arm64X-Binärdateien bündeln sowohl Arm64- als auch Arm64EC-Code, wodurch Arm64X auf einem Windows on Arm-Gerät mit Arm64- und Arm64EC-Prozessen kompatibel ist. Siehe die Übersicht über Arm64X PE-Dateien.

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

Hinweise

  • Geben Sie keine --build_dir-Option an, da build_arm64x.bat spezifische Build-Verzeichnisse festlegt.
  • Der obige Befehl platziert Arm64X-Binärdateien im Verzeichnis .\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 (Cross-Compile)

Bitte beziehen Sie sich auf Build OnnxRuntime für Android.

# 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

Weitere Informationen zum DirectML Execution Provider finden Sie hier.

Windows

.\build.bat --use_dml

Hinweise

Der DirectML Execution Provider unterstützt das Erstellen für x64- und x86-Architekturen. DirectML wird nur unter Windows unterstützt.

Arm Compute Library

Weitere Informationen zum ACL Execution Provider finden Sie hier.

Build-Anweisungen

Sie müssen zuerst die Arm Compute Library 24.07 für Ihre Plattform erstellen, wie in der Dokumentation beschrieben. Informationen zur Erstellung für Arm®-basierte Geräte finden Sie hier.

Fügen Sie die folgenden Optionen zu build.sh hinzu, um den ACL Execution Provider zu aktivieren.

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

Arm NN

Weitere Informationen zum Arm NN Execution Provider finden Sie hier.

Voraussetzungen

  • Unterstütztes Backend: i.MX8QM Armv8 CPUs
  • Unterstütztes BSP: i.MX8QM BSP
    • Installieren Sie i.MX8QM BSP: source fsl-imx-xwayland-glibc-x86_64-fsl-image-qt5-aarch64-toolchain-4*.sh
  • Richten Sie die Build-Umgebung ein.
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"
  • Informationen zur Erstellung für Arm®-basierte Geräte finden Sie hier.

Build-Anweisungen

./build.sh --use_armnn

Der Relu-Operator ist standardmäßig so eingestellt, dass er den CPU-Execution-Provider für bessere Leistung verwendet. Um die Arm NN-Implementierung zu verwenden, erstellen Sie mit dem Flag –armnn_relu.

./build.sh --use_armnn --armnn_relu

Der Batch-Normalisierungs-Operator ist standardmäßig so eingestellt, dass er den CPU-Execution-Provider verwendet. Um die Arm NN-Implementierung zu verwenden, erstellen Sie mit dem Flag –armnn_bn.

./build.sh --use_armnn --armnn_bn

Um eine Bibliothek außerhalb der normalen Umgebung zu verwenden, können Sie einen benutzerdefinierten Pfad festlegen, indem Sie die Parameter –armnn_home und –armnn_libs angeben, um den Pfad zum Arm NN-Home-Verzeichnis bzw. Build-Verzeichnis zu definieren. Das Arm Compute Library Home-Verzeichnis und das Build-Verzeichnis müssen ebenfalls verfügbar sein und können bei Bedarf mit –acl_home und –acl_libs angegeben werden.

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

Weitere Informationen zum RKNPU Execution Provider finden Sie hier.

Voraussetzungen

  • Unterstützte Plattform: RK1808 Linux
  • Informationen zur Erstellung für Arm®-basierte Geräte finden Sie hier.
  • Verwenden Sie gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu anstelle von gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf und ändern Sie CMAKE_CXX_COMPILER & CMAKE_C_COMPILER in tool.cmake.
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)

Build-Anweisungen

Linux

  1. Laden Sie rknpu_ddk in ein beliebiges Verzeichnis herunter.

  2. Bauen Sie die ONNX Runtime-Bibliothek und testen Sie sie.

     ./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. Stellen Sie ONNX Runtime und librknpu_ddk.so auf der RK1808-Platine bereit.

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

AMD Vitis AI

Weitere Informationen zum Vitis AI Execution Provider finden Sie hier.

Windows

Führen Sie von der Visual Studio Developer Command Prompt oder Developer PowerShell aus den folgenden Befehl aus.

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

Wenn Sie die Python-APIs nutzen möchten, fügen Sie bitte das Flag --build_wheel hinzu

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

Sie können auch den Installationsort überschreiben, indem Sie CMAKE_INSTALL_PREFIX über den Parameter cmake_extra_defines angeben. z.B.

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

Linux

Derzeit ist die Linux-Unterstützung nur für AMD Adaptive SoCs aktiviert. Weitere Informationen zu SoC-Zielen finden Sie hier.

AMD MIGraphX

Weitere Informationen zum MIGraphX Execution Provider finden Sie hier.

Voraussetzungen

  • Installieren Sie ROCm
    • Der MIGraphX Execution Provider für ONNX Runtime wird mit ROCm6.3.1 erstellt und getestet.
  • Installieren Sie MIGraphX
    • Der Pfad zur MIGraphX-Installation muss über den Parameter --migraphx_home angegeben werden.

Build-Anweisungen

Linux

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

Dockerfile-Anweisungen sind hier verfügbar.

Python-Wheel erstellen

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

Anschließend können die Python-Wheels (*.whl) unter ./build/Linux/Release/dist gefunden werden.

AMD ROCm

Weitere Informationen zum ROCm Execution Provider finden Sie hier.

Voraussetzungen

  • Installieren Sie ROCm
    • Der ROCm Execution Provider für ONNX Runtime wird mit ROCm6.3.1 erstellt und getestet.

Build-Anweisungen

Linux

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

Dockerfile-Anweisungen sind hier verfügbar.

Python-Wheel erstellen

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

Anschließend können die Python-Wheels (*.whl) unter ./build/Linux/Release/dist gefunden werden.

NNAPI

Die Nutzung von NNAPI auf Android-Plattformen erfolgt über den NNAPI Execution Provider (EP).

Weitere Details finden Sie in der Dokumentation zum NNAPI Execution Provider.

Das vorab erstellte ONNX Runtime Mobile-Paket für Android enthält den NNAPI EP.

Wenn Sie ONNX Runtime benutzerdefiniert erstellen, muss die Unterstützung für den NNAPI EP oder CoreML EP beim Erstellen aktiviert werden.

Erstellen eines minimalen Builds mit NNAPI EP-Unterstützung

Informationen zum Einrichten der erforderlichen Android-Umgebung zum Erstellen finden Sie hier. Der Android-Build kann unter Windows oder Linux cross-kompiliert werden.

Sobald Sie alle notwendigen Komponenten eingerichtet haben, folgen Sie den Anweisungen, um den benutzerdefinierten Build zu erstellen, mit den folgenden Änderungen:

  • Ersetzen Sie --minimal_build durch --minimal_build extended, um die Unterstützung für Execution Provider zu aktivieren, die zur Laufzeit dynamisch Kernel erstellen, was für den NNAPI EP erforderlich ist.
  • Fügen Sie --use_nnapi hinzu, um den NNAPI EP in den Build aufzunehmen.

Beispiel-Build-Befehle mit aktiviertem NNAPI EP

Beispiel für 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>

Beispiel für 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

Die Nutzung von CoreML auf iOS- und macOS-Plattformen erfolgt über den CoreML EP.

Weitere Details finden Sie in der Dokumentation zum CoreML Execution Provider.

Das vorab erstellte ONNX Runtime Mobile-Paket für iOS enthält den CoreML EP.

Erstellen eines minimalen Builds mit CoreML EP-Unterstützung

Informationen zum Einrichten der erforderlichen iOS-Umgebung zum Erstellen finden Sie hier. Der iOS/macOS-Build muss auf einem Mac-Rechner durchgeführt werden.

Sobald Sie alle notwendigen Komponenten eingerichtet haben, folgen Sie den Anweisungen, um den benutzerdefinierten Build zu erstellen, mit den folgenden Änderungen:

  • Ersetzen Sie --minimal_build durch --minimal_build extended, um die Unterstützung für Execution Provider zu aktivieren, die zur Laufzeit dynamisch Kernel erstellen, was für den CoreML EP erforderlich ist.
  • Fügen Sie --use_coreml hinzu, um den CoreML EP in den Build aufzunehmen.

XNNPACK

Die Nutzung von XNNPACK auf Android/iOS/Windows/Linux-Plattformen erfolgt über den XNNPACK EP.

Weitere Details finden Sie in der Dokumentation zum XNNPACK Execution Provider.

Das vorab erstellte ONNX Runtime-Paket (onnxruntime-android) für Android enthält den XNNPACK EP.

Das vorab erstellte ONNX Runtime Mobile-Paket für iOS, onnxruntime-c und onnxruntime-objc in CocoaPods, enthält den XNNPACK EP. (Paket onnxruntime-objc mit XNNPACK wird ab Version 1.14 verfügbar sein.)

Wenn Sie ONNX Runtime benutzerdefiniert erstellen, muss die Unterstützung für den XNNPACK EP beim Erstellen aktiviert werden.

Build für Android

Erstellen eines minimalen Builds mit XNNPACK EP-Unterstützung

Informationen zum Einrichten der erforderlichen Android-Umgebung zum Erstellen finden Sie hier. Der Android-Build kann unter Windows oder Linux cross-kompiliert werden.

Sobald Sie alle notwendigen Komponenten eingerichtet haben, folgen Sie den Anweisungen, um den benutzerdefinierten Build zu erstellen, mit den folgenden Änderungen:

  • Ersetzen Sie --minimal_build durch --minimal_build extended, um die Unterstützung für Execution Provider zu aktivieren, die zur Laufzeit dynamisch Kernel erstellen, was für den XNNPACK EP erforderlich ist.
  • Fügen Sie --use_xnnpack hinzu, um den XNNPACK EP in den Build aufzunehmen.
Beispiel-Build-Befehle mit aktiviertem XNNPACK EP

Beispiel für 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>

Beispiel für 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>`

Wenn Ihnen ein MINIMAL-Build ausreicht, können Sie den folgenden Befehl verwenden, um den XNNPACK EP für Android zu erstellen: Beispiel für 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

Build für iOS (verfügbar seit 1.14)

Ein Mac-Rechner ist erforderlich, um ein Paket für iOS zu erstellen. Folgen Sie bitte diesem Leitfaden, um die Umgebung zunächst einzurichten.

Erstellen eines minimalen Builds mit XNNPACK EP-Unterstützung

Sobald Sie alle notwendigen Komponenten eingerichtet haben, folgen Sie den Anweisungen, um den benutzerdefinierten Build zu erstellen, mit den folgenden Änderungen:

  • Ersetzen Sie --minimal_build durch --minimal_build extended, um die Unterstützung für Execution Provider zu aktivieren, die zur Laufzeit dynamisch Kernel erstellen, was für den XNNPACK EP erforderlich ist.
  • Fügen Sie --use_xnnpack hinzu, um den XNNPACK EP in den Build aufzunehmen.
<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>

Build für Windows

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

Build für Linux

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

CANN

Weitere Informationen zum CANN Execution Provider finden Sie hier.

Voraussetzungen

  1. Installieren Sie das CANN Toolkit für das entsprechende Betriebssystem und die Zielhardware, indem Sie die Dokumentation für detaillierte Anweisungen befolgen.

  2. Initialisieren Sie die CANN-Umgebung, indem Sie das unten gezeigte Skript ausführen.

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

Build-Anweisungen

Linux

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

Hinweise

  • Der CANN Execution Provider unterstützt das Erstellen für x64- und aarch64-Architekturen.
  • Der CANN Execution Provider wird derzeit nur unter Linux unterstützt.

Azure

Weitere Details finden Sie in der Dokumentation zum Azure Execution Provider.

Voraussetzungen

Für Linux, bevor Sie mit dem Erstellen beginnen, bitte:

  • Installieren Sie das openssl-dev-Paket im System, das ist openssl-dev für Red Hat und libssl-dev für Ubuntu.
  • Wenn mehrere openssl-dev-Versionen im System installiert sind, setzen Sie die Umgebungsvariable "OPENSSL_ROOT_DIR" auf die gewünschte Version, zum Beispiel:
set OPENSSL_ROOT_DIR=/usr/local/ssl3.x/

Build-Anweisungen

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