ONNX (Open Neural Network Exchange)

repository·main·Indexed 12 days ago

https://github.com/onnx/onnx

An open ecosystem providing a standardized, extensible computation graph format for AI models, supporting both deep learning and traditional machine learning to enable interoperability across different frameworks and hardware.

Tokens
198K
Snippets
475
Records
766
Agent score
92%

What's inside ONNX

  1. Overview of ONNX capabilities

    main

    Open Neural Network Exchange (ONNX) is an open ecosystem providing an open source format for AI models (both deep learning and traditional ML). It defines:

    • An extensible computation graph model.
    • Definitions of built-in operators.
    • Standard data types.

    Currently, the project focuses on capabilities required for inferencing (scoring).

  2. Overview of ONNX Core CI Workflows

    main

    The core CI pipelines ensure code quality through testing, linting, and compliance checks. Key workflows include:

    • CI: Runs C++ and Python tests across Linux, Windows, and macOS. It covers Python 3.10–3.14 (including free-threading variants), doc generation, proto generation, and node test generation. Code coverage is reported to Codecov.
    • Windows_No_Exception_CI: Executes C++ tests compiled without exceptions with selective schema loading.
    • Lint / Enforce style: A required workflow that runs lintrunner (including ruff, mypy, clang-format, etc.) and verifies that auto-generated files are up to date.
    • Require label: Ensures every PR has at least one topic: or module: label (except for Dependabot PRs).
    • DCO: A placeholder job required to enable the GitHub merge queue.
  3. Security and Supply Chain Monitoring in ONNX

    main

    ONNX implements several workflows to maintain security and supply chain integrity:

    • CodeQL: Performs static analysis of C++ and Python code to detect security vulnerabilities (runs on every PR, push to main/rel-*, and weekly).
    • Scorecard: Uses the OpenSSF supply-chain security scorecard to publish results to the code-scanning dashboard (runs on push to main and weekly).
    • Dependency Review: Automatically flags vulnerable or license-incompatible dependencies introduced in a PR.
  4. Validate ONNX models with onnx.checker

    main
    The onnx.checker module provides utilities to validate the correctness of ONNX models. It ensures that the model graph, operators, and data types conform to the ONNX specification. You can use the checker to verify that a model is structurally sound and ready for inference or further processing.
  5. Documentation and Maintenance Workflows

    main

    The following workflows manage the project's documentation and long-term maintenance:

    • Pages: Builds and publishes ONNX documentation to GitHub Pages.
    • Pixi CI: Builds, lints, and tests using the pixi environment manager on Linux, macOS, and Windows.
    • Check URLs: Periodically checks for broken URLs within the codebase.
    • Stale: Automatically warns and closes stale issues and PRs.
    • Dependabot: Automatically creates PRs for updated dependency versions.
  6. Create ONNX graph components with onnx.helper

    main

    The onnx.helper module provides a suite of utility functions designed to simplify the programmatic creation of ONNX graph components. Instead of manually constructing complex Protocol Buffer objects, you can use these helpers to build nodes, tensors, graphs, and models.

    Key component creation functions include:

    • Nodes & Attributes: make_node, make_attribute, and make_attribute_ref.
    • Tensors & Values: make_tensor, make_tensor_value_info, make_empty_tensor_value_info, and make_sparse_tensor.
    • Types: make_tensor_type_proto, make_sequence_type_proto, make_map_type_proto, and make_optional_type_proto.
    • Graph & Model Structure: make_graph, make_model, make_operatorsetid, and make_training_info.
  7. Understand ONNX converting libraries

    main

    To use a model in production with ONNX, you typically use a converting library to translate a framework-specific model (like PyTorch or TensorFlow) into an ONNX graph. These libraries rewrite the model's prediction function using ONNX operators.

    Key characteristics of converting libraries:

    • Specialization: Most libraries are dedicated to a single framework (e.g., tensorflow-onnx for TensorFlow, torch.onnx for PyTorch).
    • Compatibility: They are not interchangeable. You must use the library corresponding to your source framework.
    • Customization Challenges: If your model contains custom layers, the converter must be able to map those to ONNX primitives. Deep learning frameworks (PyTorch/TensorFlow) are generally easier to convert because they use primitives that map well to ONNX, whereas libraries like scikit-learn (which rely on NumPy/SciPy) may require you to manually implement transformers using ONNX primitives.
  8. Use the onnx.backend module for hardware abstraction

    main
    The onnx.backend module provides abstractions for interacting with different execution backends and hardware devices. It allows developers to define how ONNX models are represented and executed on specific hardware targets through the Backend and BackendRep classes.
  9. What is an Optional Type and how it works

    main

    An Optional type represents a reference to either an element (Tensor, Sequence, Map, or Sparse Tensor) or a null value. This is analogous to the Optional[X] type hint in Python (equivalent to Union[None, X]).

    Optional types can appear in model inputs, outputs, or as intermediate values. They enable dynamic typing scenarios where a value might be present or absent (null).

  10. What is ONNX and why use a common Intermediate Representation (IR)?

    main

    ONNX (Open Neural Network Exchange) provides a common Intermediate Representation (IR) for computation graphs used in deep learning. Instead of being locked into a single framework's proprietary stack (API, graph, and runtime), ONNX allows developers to:

    1. Select the best framework for any stage of development (e.g., research vs. production).
    2. Reduce conversion delays between research and deployment.
    3. Enable hardware optimization by providing a standardized format that hardware vendors can optimize for specific platforms (CPU, GPU, FPGA, etc.).
  11. What is Type Denotation in ONNX

    main

    Type Denotation is a mechanism used to describe semantic information about model inputs and outputs. It is stored within the TypeProto message.

    While standard tensor shapes define the structure of data, Type Denotation provides context about the nature of the data (e.g., whether a tensor represents an image, audio, or text). This allows model consumers to understand requirements such as color channel order, pixel bit depth, or normalization ranges without relying on external documentation.

  12. What is ONNX Backend Test

    main

    ONNX Backend Test is a verification suite designed for ONNX backend implementations to ensure they fulfill the ONNX standard. It serves two purposes: verifying backend correctness and defining the expected behavior of operators (complementing the official documentation).

    The suite consists of two testing levels:

    1. Node Tests: These verify individual operator computations. The backend is provided with a specific node and input, and the resulting output is compared against an expected value. This level checks how attributes for each operator are handled.
    2. Model Tests: These verify the backend at the model level. Instead of a single node, the backend is provided with an entire ONNX model to execute.