ONNX Runtime Web bereitstellen

Dieses Dokument bietet Anleitungen zur Bereitstellung von ONNX Runtime Web in einer Produktionsumgebung.

Inhalt

• Artefakte
  • JavaScript-Code-Bundle
    • Bedingte Importierung
    • Worker-Laden
  • WebAssembly-Binärdateien
    • Stellen Sie sicher, dass die WebAssembly-Binärdatei(en) korrekt ausgeliefert werden
    • WebAssembly-Dateipfad überschreiben
  • Modelldatei(en)
• Größenbetrachtungen
  • Benutzerdefinierte Erstellung
• Sicherheitsaspekte
  • Sicherer Kontext
  • Umgebungen mit eingeschränkter Content Security Policy (CSP)

Artefakte

Bei der Bereitstellung von ONNX Runtime Web in einer Produktionsumgebung sind die folgenden Artefakte erforderlich:

• JavaScript-Code-Bundle: Das JavaScript-Code-Bundle, das den Anwendungscode und möglicherweise auch den ONNX Runtime Web JavaScript-Code enthält, abhängig davon, wie die Anwendung erstellt wurde.

• WebAssembly-Binärdateien: Die WebAssembly-Binärdatei(en) der ONNX Runtime Web-Bibliothek.

• Modelldatei(en): Die ONNX-Modelldatei(en), die Sie im Browser ausführen möchten.

JavaScript-Code-Bundle

Das JavaScript-Code-Bundle ist normalerweise eine minimierte JavaScript-Datei, die den Anwendungscode enthält und von einem Bundler wie Webpack, Rollup oder ESBuild generiert wurde. Abhängig von der Konfiguration des Bundlers kann der ONNX Runtime Web JavaScript-Code im Bundle enthalten sein oder nicht (wenn er als externe Abhängigkeit angegeben ist).

Bedingte Importierung

Um die Größe des JavaScript-Code-Bundles zu reduzieren, können Sie die bedingte Importierung verwenden, um nur die notwendigen Teile der ONNX Runtime Web-Bibliothek zu importieren. Sie können beispielsweise onnxruntime-web/wasm importieren, wenn Sie nur den WebAssembly-Ausführungsanbieter verwenden, was die Größe des JavaScript-Code-Bundles reduzieren kann.

Worker-Laden

Es gibt 2 Worker in ONNX Runtime Web, die zur Laufzeit geladen werden können:

1. Der Web-Worker für die Proxy-Funktion. Der ONNX Runtime Web JavaScript-Code kann als Einstiegspunkt des Web-Workers für die Proxy-Funktion geladen werden.
2. Der Web-Worker für die WebAssembly-Multithreading-Funktion. Die von Emscripten generierten JavaScript-Dateien können als Einstiegspunkt des Web-Workers für die WebAssembly-Multithreading-Funktion geladen werden.

Wenn in Same-Origin-Umgebungen bereitgestellt wird, können die Worker direkt von der Skript-URL geladen werden. Dies ermöglicht das Laden der Worker in Umgebungen mit eingeschränkter Content Security Policy (CSP). Wenn in Cross-Origin-Umgebungen bereitgestellt wird, z. B. beim Laden der Worker von einem CDN, können die Worker aufgrund der Same-Origin-Policy nicht direkt von der Skript-URL geladen werden. In diesem Fall wird ein fetch durchgeführt und die Worker werden über die Objekt-URL geladen, die aus der Antwort des Fetch erstellt wurde.

WebAssembly-Binärdateien

Die Standard-ONNX Runtime Web-Bibliothek enthält die folgenden WebAssembly-Binärdateien:

Datei	SIMD	Multithreading	JSEP	Training
ort-wasm-simd-threaded.wasm	✔️	✔️	❌	❌
ort-wasm-simd-threaded.jsep.wasm	✔️	✔️	✔️	❌
ort-training-wasm-simd-threaded.wasm	✔️	✔️	❌	✔️

Die Spalten geben an, ob die Funktion vom WebAssembly-Artefakt unterstützt wird.

• SIMD: ob die Single Instruction, Multiple Data (SIMD)-Funktion unterstützt wird.
• Multithreading: ob die WebAssembly-Multithreading-Funktion unterstützt wird.
• JSEP: ob die JavaScript Execution Provider (JSEP)-Funktion aktiviert ist. Diese Funktion treibt die WebGPU- und WebNN-Ausführungsanbieter an.
• Training: ob die Trainingsfunktion aktiviert ist.

Bei der Bereitstellung von ONNX Runtime Web in einer Produktionsumgebung sollten Sie überlegen, welche WebAssembly-Binärdatei(en) in die Anwendung aufgenommen werden sollen. Hier sind einige Überlegungen:

• Bei Verwendung der Trainingsfunktion wird die Datei ort-training-wasm-simd-threaded.wasm verwendet.
• Bei Verwendung des WebGPU- oder WebNN-Ausführungsanbieters wird die Datei ort-wasm-simd-threaded.jsep.wasm verwendet.
• Andernfalls wird die Datei ort-wasm-simd-threaded.wasm verwendet.

Stellen Sie sicher, dass die WebAssembly-Binärdatei(en) korrekt ausgeliefert werden

Sie sollten sicherstellen, dass die WebAssembly-Binärdatei(en) korrekt auf dem Server ausgeliefert werden. Wenn Sie die notwendige(n) WebAssembly-Binärdatei(en) beim Erstellen der Anwendung nicht kopiert haben oder wenn die WebAssembly-Binärdatei(en) nicht im erwarteten Pfad liegen, wird ONNX Runtime Web nicht initialisiert.

WebAssembly-Dateipfad überschreiben

ONNX Runtime Web versucht, die WebAssembly-Binärdatei(en) anhand des relativen Pfads des JavaScript-Code-Bundles zu lokalisieren. Wenn die WebAssembly-Binärdatei(en) nicht im selben Verzeichnis wie das JavaScript-Code-Bundle liegen, können Sie den Dateipfad überschreiben, indem Sie den Wert von ort.env.wasm.wasmPaths festlegen.

Sie können ort.env.wasm.wasmPaths auch auf eine absolute URL eines öffentlichen CDNs wie jsdelivr oder unpkg setzen, wenn Sie eine Release-Version von ONNX Runtime Web verwenden.

// Set the WebAssembly binary file path to jsdelivr CDN for latest dev version
ort.env.wasm.wasmPaths = 'https://cdn.jsdelivr.net/npm/onnxruntime-web@dev/dist/';

// Set the WebAssembly binary file path to unpkg CDN for latest dev version
ort.env.wasm.wasmPaths = 'https://unpkg.com/onnxruntime-web@dev/dist/';

Weitere Informationen finden Sie in der API-Referenz: env.wasm.wasmPaths.

Modelldatei(en)

Wenn Ihre ONNX-Modelldateien groß sind und das Herunterladen einige Zeit in Anspruch nimmt, können Sie IndexedDB verwenden, um die Modelldateien zu cachen, um zu vermeiden, dass das Modell bei jeder Aktualisierung der Seite neu geladen wird.

Wenn das Modell externe Daten enthält, müssen Sie die Informationen zu den externen Daten an ONNX Runtime Web übergeben. Weitere Informationen finden Sie unter Externe Daten.

Größenbetrachtungen

Die Größe der Artefakte ist ein wichtiger Faktor, der bei der Bereitstellung von ONNX Runtime Web in einer Produktionsumgebung berücksichtigt werden muss. Die Reduzierung der Dateigröße kann die Ladezeit der Anwendung verbessern und den Speicherverbrauch auf dem Gerät des Clients reduzieren.

Um die Bereitstellungsgröße zu reduzieren, können Sie folgende Optionen in Betracht ziehen:

• Verwenden Sie die bedingte Importierung, um nur die notwendigen Teile der ONNX Runtime Web-Bibliothek zu importieren.
• Liefern Sie nur die notwendigen WebAssembly-Binärdateien aus oder verwenden Sie ort.env.wasm.wasmPaths, um den WebAssembly-Binärdateipfad auf ein öffentliches CDN zu setzen.

Wenn Sie die ultimative Kontrolle über die Größe der Artefakte haben möchten, können Sie auch einen benutzerdefinierten Build von ONNX Runtime Web durchführen.

Benutzerdefinierter Build

Durch die Verwendung eines benutzerdefinierten Builds von ONNX Runtime Web können Sie ONNX Runtime Web nur mit den für Ihr Modell erforderlichen Kernels erstellen, was die Größe der WebAssembly-Binärdatei(en) erheblich reduzieren kann. Die Schritte sind jedoch komplexer und erfordern Kenntnisse des ONNX Runtime Web-Build-Systems.

Der Inhalt dieses Teils befindet sich im Aufbau.

Sicherheitsaspekte

Sicherer Kontext

WebGPU ist nur für sichere Kontexte zugänglich. Kurz gesagt, eine Seite, die über HTTPS oder über HTTP von localhost/127.0.0.1 geladen wird, gilt als sicherer Kontext.

Weitere Informationen finden Sie unter Sichere Kontexte und WebGPU: Troubleshooting-Tipps und Fehlerbehebungen.

Umgebungen mit eingeschränkter Content Security Policy (CSP)

Seit ONNX Runtime Web v1.19 können die WebAssembly-Binärdatei(en) und Worker in CSP-beschränkten Umgebungen geladen werden. Um dies zu ermöglichen, müssen die notwendigen Artefakte ausgeliefert werden.