Backends and Analysis Modes

This package provides one estimator backend, one measured-profiling backend, and two internal conversion support integrations.

Backend	Role
nx-performance-estimator	Estimates compatibility and performance from a model
neural-technology-profiling-data	Produces measured performance results from structured captures or ETRecord/ETDump pairs
ml-sdk-model-converter	Converts supported model formats for Neural Technology tools
tosa-flatbuffers	Provides TOSA FlatBuffers serialization support

NX Performance Estimator

The Python integration outside the proprietary directories is licensed under Apache-2.0. All contents of the following directories are provided under LicenseRef-LICENSE:

• src/mlia/_vendor/artifacts/nx-performance-estimator/
• src/mlia/resources/nx-performance-estimator/

See LICENSES/LicenseRef-LICENSE.txt in the repository root.

nx-performance-estimator is the primary model-analysis backend. Use it for:

• Model-level compatibility and performance results.
• Per-chain and per-cascade cycle breakdowns.
• Memory traffic and hardware-section utilisation metrics.
• Canonical source-operator, module, and source-code provenance.
• Control over the packaged system and compiler configuration.

A straightforward estimator run uses an input that this package can process without an external framework converter:

mlia check my_model.tosa \
  --target-profile neural-technology \
  --performance \
  --backend nx-performance-estimator

LiteRT, PyTorch, and ExecuTorch inputs require their corresponding converter plugins. VGF inputs can be analyzed directly.

Configuration options

mlia check my_model.tosa \
  --target-profile neural-technology \
  --performance \
  --backend nx-performance-estimator \
  --nx-performance-estimator.system-config ./system.ini \
  --nx-performance-estimator.compiler-config ./compiler.ini

Option	Meaning
--nx-performance-estimator.system-config	Override the system configuration file
--nx-performance-estimator.compiler-config	Override the graph-compiler configuration file
--nx-performance-estimator.skip-trivial-ops	Exclude trivial TOSA operations (const, const_shape, etc.) from compatibility checks and accelerator operator percentages

--nx-performance-estimator.skip-trivial-ops is a boolean flag that takes no value and is disabled by default. It filters constants (CONST), shape constants (CONST_SHAPE), and reshapes (RESHAPE) during compatibility analysis of TOSA FlatBuffer, TOSA MLIR, and VGF inputs. Compiler records are retained when their types are unknown or include non-trivial operations. The flag does not change model compilation or performance estimation.

uv run mlia check -t neural-technology --compatibility \
  --nx-performance-estimator.skip-trivial-ops -- my_model.tosa

Measured profiling data

neural-technology-profiling-data analyzes schema-version 2 captures produced by VK_LAYER_LGL_neural_statistics. Supplying --profiling-data switches the run to measured mode and causes core MLIA to select this profiling-capable backend. The backend is built in and normally does not need to be named explicitly.

Structured-capture profiling supports performance analysis only. It accepts:

• one dispatch directory without a model;
• a capture root or dispatch anchor associated with a VGF model; or
• one explicitly ordered dispatch directory per VGF graph segment.

The measured path uses the same correlation, aggregation, entity provenance, and standardized-output construction as estimator mode. See CLI for the capture layout and selection rules. See Outputs and metrics for counter aggregation and the meaning and limitations of the reported cycle counts.

The same measured backend also accepts an ETRecord (.etrecord or .bin) and one matching ETDump (.etdp or .etdump). It reports runtime timings in milliseconds and, when present, decoded VGF cycles and hardware counters. See ETRecord and ETDump for installation, method selection, runtime-only and mixed observations, and decoder limits.

Conversion support integrations

ml-sdk-model-converter prepares supported inputs for the estimator, while tosa-flatbuffers supplies lower-level TOSA serialization support. They use the backend plugin mechanism for dependency integration, but they do not produce independently selectable analysis results.

A useful model of the estimator path is:

1. MLIA receives a model in a supported format.
2. A framework converter runs when the original format requires one.
3. For non-VGF inputs, the ML SDK conversion path produces an estimator-ready VGF artifact. Existing VGF inputs proceed directly to segment preparation.
4. The NX Performance Estimator produces standardized results.
5. Core MLIA validates, post-processes, and renders those results.

Cross-links

• See Outputs and metrics for result structure and entity provenance.
• See CLI for estimator and measured-profiling examples.
• See Troubleshooting for conversion, estimator, and capture-ingestion failures.