Paket ai.onnxruntime

Eine Java-Schnittstelle für ONNX Runtime.

Bietet Zugriff auf dieselben Ausführungs-Backends wie die C-Bibliothek. In Java nicht darstellbare Typen (wie fp16) werden bei Zugriff über diese API in den nächstgelegenen Java-Primitivtyp konvertiert.

Es werden zwei gemeinsam genutzte Bibliotheken benötigt: onnxruntime und onnxruntime4j_jni. Der Lader befindet sich in OnnxRuntime und die Logik ist in dieser Reihenfolge:

  1. Der Benutzer kann das Laden einer gemeinsam genutzten Bibliothek überspringen, indem er eine Eigenschaft im Format onnxruntime.native.LIB_NAME.skip mit dem Wert true setzt. Dies bedeutet, dass der Benutzer beschlossen hat, die Bibliothek auf andere Weise zu laden.
  2. Der Benutzer kann einen expliziten Speicherort für alle nativen Bibliotheksdateien über eine Eigenschaft im Format onnxruntime.native.path angeben. Dies verwendet System.load(java.lang.String).
  3. Der Benutzer kann einen expliziten Speicherort für die gemeinsam genutzte Bibliotheksdatei über eine Eigenschaft im Format onnxruntime.native.LIB_NAME.path angeben. Dies verwendet System.load(java.lang.String).
  4. Die gemeinsam genutzte Bibliothek wird automatisch erkannt
    1. Wenn die gemeinsam genutzte Bibliothek in den Klassenpfadressourcen vorhanden ist, wird sie über eine temporäre Datei mit System.load(java.lang.String) geladen. Idealerweise sollte dies der Standardfall sein, wenn JARs/Abhängigkeiten, die die gemeinsam genutzten Bibliotheken enthalten, zu Ihrem Klassenpfad hinzugefügt werden.
    2. Wenn die gemeinsam genutzte Bibliothek nicht in den Klassenpfadressourcen vorhanden ist, wird sie über System.loadLibrary(java.lang.String) geladen, die normalerweise an anderer Stelle im Dateisystem nach der Bibliothek sucht. Die Semantik und das Verhalten dieser Methode sind system-/JVM-abhängig. Typischerweise wird die Eigenschaft java.library.path verwendet, um den Speicherort nativer Bibliotheken anzugeben.
Zur Fehlerbehebung werden alle Ladevorgänge von gemeinsam genutzten Bibliotheken auf der Java-Logging-Ebene FINE gemeldet.

Beachten Sie, dass CUDA, ROCM, DNNL, OpenVINO und TensorRT allesamt "gemeinsam genutzte Bibliotheksausführungsanbieter" sind und entweder im Verzeichnis gespeichert werden müssen, das die native ONNX Runtime-Kernbibliothek enthält, oder als Klassenpfadressource. Dies liegt daran, dass diese Anbieter von der nativen ONNX Runtime-Bibliothek selbst geladen werden und die Java-API den Ladespeicherort nicht steuern kann.