A type-safe, functional ONNX API and backend for deep learning and classical machine learning in Scala 3.
ONNX-Scala is a Scala 3 library that provides a type-safe, functional interface to the Open Neural Network Exchange (ONNX) standard for deep learning and classical machine learning. It enables cross-platform model inference with performance comparable to native ONNX Runtime, leveraging Scala's advanced type system for compile-time safety and expressiveness.
Scala developers, particularly those using Scala 3, who work with ONNX models and require type safety, functional programming patterns, and cross-platform deployment (JVM, Scala.js/JavaScript, Scala Native).
Developers choose ONNX-Scala for its typeful, functional API that enforces tensor shape and data type constraints at compile time, reducing runtime errors, while maintaining high performance and full interoperability with the ONNX ecosystem across multiple platforms.
An ONNX (Open Neural Network eXchange) API and backend for typeful, functional deep learning and classical machine learning in Scala 3
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses Scala 3's union types, match types, and literal types to enforce tensor shapes, axis labels, and data constraints at compile time, reducing runtime errors as highlighted in the type-safe tensor examples.
Provides backends for JVM (ONNX Runtime), Scala.js (ONNX Runtime Web), and Scala Native, enabling consistent model inference across multiple platforms with performance within 3% of native ONNX Runtime.
Offers a complete, type-safe API derived directly from ONNX Protobuf definitions, ensuring up-to-date compatibility and safety for deep learning workflows, as noted in the project details.
Benchmarks show run times within 3% of ONNX Runtime via Python, making it efficient for performance-critical scenarios while leveraging Scala's type system for safety.
The fine-grained API supports only 87 out of 178 ONNX operators, limiting advanced model usage without relying on the less type-safe full-model API, as admitted in the README.
The full-model API has untyped inputs, which can fail at runtime when models are loaded dynamically, a trade-off acknowledged in the documentation for supporting dynamic shapes.
Requires migration to Scala 3, which may be a barrier for teams with existing Scala 2.x codebases or dependencies, limiting adoption in enterprise environments.
Leveraging advanced Scala 3 features like singleton ops and match types increases the learning curve and code complexity, potentially slowing development for those new to functional or type-level programming.