Benutzerdefiniertes ONNX Runtime-Paket erstellen

Das ONNX Runtime-Paket kann angepasst werden, wenn die Anforderungen der Zielumgebung dies erfordern.

Das häufigste Szenario für die Anpassung des ONNX Runtime-Builds sind Bereitstellungen mit kleinerem Fußabdruck, wie z. B. mobile und Web-Umgebungen.

Und der häufigste Mechanismus zur Anpassung des Builds ist die Reduzierung der unterstützten Operatoren in der Laufzeitumgebung auf diejenigen, die im Modell oder in den Modellen, die in der Zielumgebung ausgeführt werden, vorhanden sind.

Zum Erstellen eines benutzerdefinierten ONNX Runtime-Pakets gelten die Anweisungen zum Erstellen aus dem Quellcode mit einigen zusätzlichen Optionen, die unten angegeben sind.

Inhalt

• Operator-Kernel reduzieren
• Minimaler Build
• Andere Anpassungen
• Build-Konfiguration
• Version von ONNX Runtime, aus der erstellt werden soll
• Beispiel-Build-Befehle
• Benutzerdefinierte Build-Pakete

Operator-Kernel reduzieren

Um die kompilierte Binärgröße von ONNX Runtime zu reduzieren, können die im Build enthaltenen Operator-Kernel auf diejenigen beschränkt werden, die von Ihrem Modell/Ihren Modellen benötigt werden.

Die enthaltenen Operatoren werden zur Build-Zeit in einer Konfigurationsdatei angegeben, die aus einem Modell oder einer Reihe von Modellen generiert werden kann.

Build-Option zur Reduzierung auf erforderliche Operator-Kernel

--include_ops_by_config

• Fügen Sie --include_ops_by_config <config file produced during model conversion> --skip_tests zu den Build-Parametern hinzu.

• HINWEIS: Beim Erstellen werden einige der ONNX Runtime-Quelldateien bearbeitet, um ungenutzte Kernel auszuschließen.

  Insbesondere wird diese Quellcode-Änderung während der standardmäßig aktivierten oder explizit mit dem Build-Parameter --update aktivierten "update"-Build-Phase durchgeführt.

  ONNX Runtime Version 1.10 und früher: Die Quelldateien werden direkt geändert. Wenn Sie zu einem vollständigen Build zurückkehren möchten oder die enthaltenen Operator-Kernel ändern möchten, müssen Sie git reset --hard oder git checkout HEAD -- ./onnxruntime/core/providers vom Stammverzeichnis Ihres lokalen ONNX Runtime-Repositorys ausführen, um diese Änderungen rückgängig zu machen.

  ONNX Runtime Version 1.11 und neuer: Aktualisierte Versionen der Quelldateien werden im Build-Verzeichnis generiert, sodass keine Änderungen an den Quelldateien rückgängig gemacht werden müssen.

Option zur Reduzierung der von den erforderlichen Operatoren unterstützten Typen

--enable_reduced_operator_type_support

• Aktiviert die Operator-Typ-Reduzierung. Erfordert ONNX Runtime Version 1.7 oder höher und dass die Typ-Reduzierung während der Modellkonvertierung aktiviert wurde.

Wenn die Konfigurationsdatei mit ORT-Format-Modellen erstellt wird, können die Eingabe-/Ausgabetypen, die einzelne Operatoren benötigen, verfolgt werden, wenn --enable_type_reduction angegeben ist. Dies kann verwendet werden, um die Build-Größe weiter zu reduzieren, wenn --enable_reduced_operator_type_support beim Erstellen von ORT angegeben wird.

ONNX-Format-Modelle enthalten nicht garantiert die erforderlichen Typinformationen pro Knoten und können daher nicht mit dieser Option verwendet werden.

Minimaler Build

ONNX Runtime kann so kompiliert werden, dass die Binärgröße weiter minimiert wird. Diese Builds mit reduzierter Größe werden als minimale Builds bezeichnet, und unten sind verschiedene Stufen von minimalen Builds beschrieben.

Basis

--minimal_build

RTTI ist in diesem Build standardmäßig deaktiviert, es sei denn, die Python-Bindungen (--build_wheel) sind aktiviert.

Ein grundlegender minimaler Build hat die folgenden Einschränkungen

• Keine Unterstützung für ONNX-Format-Modelle. Das Modell muss in ORT-Format konvertiert werden.
• Keine Unterstützung für Laufzeitoptimierungen. Optimierungen werden während der Konvertierung in das ORT-Format durchgeführt.
• Unterstützung nur für Ausführungs-Provider, die Kernel statisch registrieren (z. B. ONNX Runtime CPU Execution Provider).

Erweitert

--minimal_build extended

Ein erweiterter minimaler Build unterstützt mehr Funktionalität als ein grundlegender minimaler Build.

• Eingeschränkte Unterstützung für Laufzeitpartitionierung (Zuweisung von Knoten in einem Modell zu bestimmten Ausführungs-Providern).
• Zusätzliche Unterstützung für Ausführungs-Provider, die Kernel kompilieren, wie z. B. NNAPI und CoreML.
• ONNX Runtime Version 1.11 und neuer: Eingeschränkte Unterstützung für Laufzeitoptimierungen über gespeicherte Laufzeitoptimierungen und einige Graph-Optimierer, die zur Laufzeit aktiviert werden.

Andere Anpassungen

Ausnahmen deaktivieren

--disable_exceptions

• Alle Stellen, die eine Ausnahme ausgelöst hätten, protokollieren stattdessen die Fehlermeldung und rufen abort() auf.
• Erfordert --minimal_build.
• HINWEIS: Dies ist keine gültige Option, wenn Sie die Python-Bindungen (--build_wheel) benötigen, da das Python-Wheel die Aktivierung von Ausnahmen erfordert.
• Ausnahmen werden in ONNX Runtime nur für außergewöhnliche Dinge verwendet. Wenn Sie die zu verwendenden Eingaben validiert und das Laden des Modells validiert haben, ist es unwahrscheinlich, dass ORT eine Ausnahme auslöst, es sei denn, es liegt ein systemweites Problem vor (z. B. Arbeitsspeichermangel).

ML-Operator-Unterstützung deaktivieren

--disable_ml_ops

• Während das Skript zur Reduzierung von Operator-Kerneln alle ungenutzten ML-Operator-Kernel deaktiviert, können zusätzliche Einsparungen durch die Entfernung der Unterstützung für ML-spezifische Typen erzielt werden. Wenn Sie wissen, dass Ihr Modell keine ML-Operatoren oder keine ML-Operatoren enthält, die den Map-Typ verwenden, kann dieses Flag angegeben werden.
• Konsultieren Sie die Spezifikationen für die ONNX ML-Operatoren, wenn Sie unsicher sind.

Gemeinsame libc++ auf Android verwenden

--android_cpp_shared

• Die Erstellung mit der gemeinsamen libc++-Bibliothek anstelle der standardmäßigen statischen libc++-Bibliothek führt zu einer kleineren libonnxruntime.so-Bibliothek.
• Weitere Informationen finden Sie in der Android NDK-Dokumentation.

Build-Konfiguration

--config

Die Konfiguration MinSizeRel erzeugt die kleinste Binärgröße.

Die Konfiguration Release kann ebenfalls verwendet werden, wenn Sie die Leistung gegenüber der Binärgröße priorisieren möchten.

Version von ONNX Runtime, aus der erstellt werden soll

Verwenden Sie nicht den nicht freigegebenen main-Branch, es sei denn, Sie benötigen eine spezielle Funktion.

Sobald Sie das ONNX Runtime-Repository geklont haben, überprüfen Sie eines der Release-Tags, um daraus zu erstellen.

git clone --recursive https://github.com/microsoft/onnxruntime
cd onnxruntime
git checkout <release tag>

Release-Tag-Namen folgen dem Muster v<release version>. Zum Beispiel v1.13.1. Finden Sie sie hier.

Beispiel-Build-Befehle

Erstellung unter Windows mit reduzierter Operatorunterstützung und nur Unterstützung für ORT-Format-Modelle

<ONNX Runtime repository root>\build.bat ^
  --config=Release ^
  --cmake_generator="Visual Studio 16 2019" ^
  --build_shared_lib ^
  --minimal_build ^
  --disable_ml_ops --disable_exceptions --disable_rtti ^
  --include_ops_by_config <config file from model conversion> --enable_reduced_operator_type_support ^
  --skip_tests

Linux

<ONNX Runtime repository root>/build.sh \
  --config=Release \
  --build_shared_lib \
  --minimal_build \
  --disable_ml_ops --disable_exceptions --disable_rtti \
  --include_ops_by_config <config file from model conversion> --enable_reduced_operator_type_support \
  --skip_tests

Benutzerdefinierte Build-Pakete

In diesem Abschnitt ist ops.config eine Konfigurationsdatei, die die zu inkludierenden Opset-Sets, Op-Kernel und Typen angibt.

Web

[Dieser Abschnitt ist in Kürze verfügbar]

iOS

Um Pods für einen iOS-Build zu erstellen, verwenden Sie das Skript build_and_assemble_apple_pods.py aus dem ONNX Runtime-Repository.

1. Überprüfen Sie die Version von ONNX Runtime, die Sie verwenden möchten.

2. Führen Sie das Build-Skript aus.

   Zum Beispiel

    python3 tools/ci_build/github/apple/build_and_assemble_apple_pods.py \
      --staging-dir /path/to/staging/dir \
      --include-ops-by-config /path/to/ops.config \
      --build-settings-file /path/to/build_settings.json
   

   Dies führt einen benutzerdefinierten Build durch und erstellt die Pod-Paketdateien dafür in /path/to/staging/dir.

   Die Build-Optionen werden mit der Datei angegeben, die an die Option --build-settings-file übergeben wird. Sehen Sie sich die aktuellen Build-Optionen für das vordefinierte Paket unter tools/ci_build/github/apple/default_full_apple_framework_build_settings.json an. Sie können diese Datei direkt verwenden.

   Der reduzierte Satz von Ops im benutzerdefinierten Build wird mit der Konfigurationsdatei angegeben, die an die Option --include_ops_by_config übergeben wird. Dies ist optional.

   Das Standardpaket enthält nicht die Trainings-APIs. Um ein Trainingspaket zu erstellen, fügen Sie --enable_training_apis in die Build-Optionsdatei ein, die an --build-settings-file übergeben wird, und fügen Sie die Option --variant Training hinzu, wenn Sie build_and_assemble_apple_pods.py aufrufen.

   Zum Beispiel

    # /path/to/build_settings.json is a file that includes the `--enable_training_apis` option
       
    python3 tools/ci_build/github/apple/build_and_assemble_apple_pods.py \
      --staging-dir /path/to/staging/dir \
      --include-ops-by-config /path/to/ops.config \
      --build-settings-file /path/to/build_settings.json \
      --variant Training
   

3. Verwenden Sie die lokalen Pods.

   Zum Beispiel, aktualisieren Sie die Podfile, um den lokalen onnxruntime-objc Pod anstelle des veröffentlichten zu verwenden

    -  pod 'onnxruntime-objc'
    +  pod 'onnxruntime-objc', :path => "/path/to/staging/dir/onnxruntime-objc"
    +  pod 'onnxruntime-c', :path => "/path/to/staging/dir/onnxruntime-c"
   

   Hinweis: Der onnxruntime-objc Pod hängt vom onnxruntime-c Pod ab. Wenn der veröffentlichte onnxruntime-objc Pod verwendet wird, wird diese Abhängigkeit automatisch behandelt. Wenn jedoch ein lokaler onnxruntime-objc Pod verwendet wird, muss auch der lokale onnxruntime-c Pod, von dem er abhängt, in der Podfile angegeben werden.

Android

Um ein Android AAR-Paket zu erstellen, verwenden Sie das Skript build_custom_android_package.py aus dem ONNX Runtime-Repository.

Das Skript kann innerhalb oder außerhalb des Repositorys verwendet werden. Kopieren Sie das enthaltende Verzeichnis zur Verwendung außerhalb des Repositorys.

Hinweis: Ersetzen Sie in den folgenden Schritten <ORT version> durch die ONNX Runtime-Version, die Sie verwenden möchten, z. B. 1.13.1.

1. Führen Sie das Build-Skript aus.

   Zum Beispiel

    python3 tools/android_custom_build/build_custom_android_package.py \
      --onnxruntime_branch_or_tag v<ORT version> \
      --include_ops_by_config /path/to/ops.config \
      --build_settings /path/to/build_settings.json \
      /path/to/working/dir
   

   Dies führt einen benutzerdefinierten Build durch und erstellt das Android AAR-Paket dafür in /path/to/working/dir.

   Geben Sie die ONNX Runtime-Version, die Sie verwenden möchten, mit der Option --onnxruntime_branch_or_tag an. Das Skript verwendet eine separate Kopie des ONNX Runtime-Repositorys in einem Docker-Container, sodass dies unabhängig von der Version des enthaltenden ONNX Runtime-Repositorys ist.

   Die Build-Optionen werden mit der Datei angegeben, die an die Option --build_settings übergeben wird. Sehen Sie sich die aktuellen Build-Optionen für das vordefinierte Paket unter tools/ci_build/github/android/default_full_aar_build_settings.json an.

   Der reduzierte Satz von Ops im benutzerdefinierten Build wird mit der Konfigurationsdatei angegeben, die an die Option --include_ops_by_config übergeben wird.

   Die Optionen --build_settings und --include_ops_by_config sind beide optional und werden standardmäßig so gesetzt, wie sie für den Build des vordefinierten Pakets verwendet werden. Wenn keine davon angegeben wird, wird ein Paket wie das vordefinierte Paket erstellt.

2. Verwenden Sie das lokale benutzerdefinierte Android AAR-Paket.

   Zum Beispiel in einem Android Studio-Projekt

   a. Kopieren Sie die AAR-Datei von /path/to/working/dir/output/aar_out/<build config, e.g., Release>/com/microsoft/onnxruntime/onnxruntime-android/<ORT version>/onnxruntime-android-<ORT version>.aar in das Verzeichnis <module name, e.g., app>/libs des Projekts.

   b. Aktualisieren Sie den Abschnitt dependencies der Datei <module name>/build.gradle des Projekts.

    -    implementation 'com.microsoft.onnxruntime:onnxruntime-android:latest.release'
    +    implementation files('libs/onnxruntime-android-<ORT version>.aar')
   

Python

Wenn Sie die ONNX Runtime-Python-Bindungen mit einem minimalen Build verwenden möchten, müssen Ausnahmen aktiviert sein, da Python diese benötigt.

Entfernen Sie --disable_exceptions und fügen Sie --build_wheel zum Build-Befehl hinzu, um ein Python-Wheel mit den ONNX Runtime-Bindungen zu erstellen.

Eine .whl-Datei wird im Build-Ausgabeverzeichnis unter dem Ordner <config>/dist erstellt.

• Das Python-Wheel für einen Windows-Release-Build, der build.bat verwendet, befindet sich in <ONNX Runtime repository root>\build\Windows\Release\Release\dist\.
• Das Python-Wheel für einen Linux-Release-Build, der build.sh verwendet, befindet sich in <ONNX Runtime repository root>/build/Linux/Release/dist/.

Das Wheel kann mit pip installiert werden. Passen Sie den folgenden Befehl für Ihre Plattform und den Namen der .whl-Datei an.

pip install -U .\build\Windows\Release\Release\dist\onnxruntime-1.7.0-cp37-cp37m-win_amd64.whl