Outputs and Metrics

Overview

Neural Technology workflows produce standardized MLIA results from either:

• model-based estimation with nx-performance-estimator; or
• measured structured captures or ETRecord/ETDump pairs with neural-technology-profiling-data.

Both modes use the same metric, breakdown, entity, and provenance structure. Conversion and estimator artifacts may also be written to the run output directory for diagnostics.

Standardized result shape

Metrics are objects in a list rather than a name-to-value mapping. Detailed figures are stored in breakdowns linked to result-local entities:

{
  "backends": [
    {"id": "nx-performance-estimator"}
  ],
  "results": [
    {
      "kind": "performance",
      "producer": "nx-performance-estimator",
      "metrics": [
        {"name": "total_cycles", "value": 456789, "unit": "cycles"},
        {"name": "inference_time", "value": 1.23, "unit": "ms"},
        {
          "name": "inferences_per_second",
          "value": 813.01,
          "unit": "inferences/s"
        }
      ],
      "entities": [
        {
          "id": "chain/segment_0/1",
          "kind": "chain",
          "name": "segment_0/Chain 1",
          "child_ids": ["source_operator/segment_0/spirv-17"],
          "placement": "NX"
        },
        {
          "id": "source_operator/segment_0/spirv-17",
          "kind": "source_operator",
          "name": "conv2d",
          "parent_ids": ["chain/segment_0/1"],
          "placement": "NX"
        }
      ],
      "breakdowns": [
        {
          "entity_id": "chain/segment_0/1",
          "metrics": [
            {
              "name": "op_cycles",
              "value": 400000,
              "unit": "cycles",
              "aggregation": "sum"
            },
            {
              "name": "internal_read_bytes",
              "value": 8192,
              "unit": "bytes",
              "aggregation": "sum"
            }
          ]
        }
      ]
    }
  ]
}

The complete output also contains schema, run, target, model, context, and tool metadata owned by the shared MLIA schema.

Model-level metrics

Model-level metrics are stored in results[].metrics. They summarize the complete model rather than any individual layer or scheduling entity.

Estimator output includes backend-native metrics and standardized MLIA metrics. When the backend cannot provide a standardized metric, the result still contains an unavailable entry with a reason.

Metric	Unit	Meaning
total_cycles	cycles	Estimated end-to-end execution cycles.
compute_cycles	cycles	Estimated cycles spent performing NX compute.
cache_cycles	cycles	Estimated cycles attributed to traffic on the L1/cache path.
dram_cycles	cycles	Estimated cycles attributed to DRAM traffic.
inference_time	ms	Estimated time for one inference.
infs_per_sec	inferences/s	Estimator-native throughput field.
inferences_per_second	inferences/s	Standardized MLIA throughput, derived as 1000 / inference_time.
target_utilization	%	Compute utilization, calculated as compute_cycles / total_cycles * 100.
compiled_size	bytes	Size reported for the compiled network.
cache_read_bytes	bytes	Estimated data traffic read through the L1/cache path.
cache_write_bytes	bytes	Estimated data traffic written through the L1/cache path.
dram_read_bytes	bytes	Estimated data traffic read from DRAM.
dram_write_bytes	bytes	Estimated data traffic written to DRAM.
dram_footprint	bytes	Estimated DRAM storage required by the network.
accelerator_operator_percentage	%	Percentage of model operators placed on the accelerator, when placement data is available.
cpu_utilization	%	CPU utilization, when the backend provides it.
model_weight_memory	bytes	Standardized model-weight memory metric. The NX estimator currently reports it as unavailable.
peak_activation_memory	bytes	Highest activation-memory usage during one inference, when the backend provides it.
average_memory	bytes	Average memory usage over the measurement window, when the backend provides it.

The estimator calls the L1/cache fields cache1 in its network performance summary. MLIA exposes the model totals with the cache_ prefix.

When the backend does not provide a model-level value, the metric is represented as unavailable with a reason rather than with a fabricated number. Measured captures therefore leave fields such as compiled size and inference time unavailable when the capture does not contain them.

Layer breakdown metrics

Layer breakdown metrics are stored in results[].breakdowns[].metrics. Each breakdown is linked through entity_id to an entry in results[].entities.

The backend attaches its authoritative breakdowns to Graph Compiler chain and cascade entities. Core MLIA may project those breakdowns to related entities, such as source operators and provenance entities. It may also produce a segment breakdown when the segment has complete, compatible coverage. Therefore, a breakdown does not always correspond one-to-one with a framework layer. Use the linked entity and its parent or child relationships to identify the source operator or operators represented by the breakdown.

Layer breakdowns can include:

Metrics	Unit	Meaning
op_cycles	cycles	Sum of the estimator-provided opCycles values for the underlying stripes. This value is not necessarily the largest of all reported hardware-section cycle counts.
total_cycles	cycles	Sum of the total estimated cycles for the underlying stripes.
l1_read_bytes, l1_write_bytes	bytes	Estimated data traffic through the L1 path.
l2_read_bytes, l2_write_bytes	bytes	Estimated data traffic through the L2 path.
system_cache_read_bytes, system_cache_write_bytes	bytes	Estimated data traffic through the system-cache path.
dram_read_bytes, dram_write_bytes	bytes	Estimated data traffic through the DRAM path.
l1_traffic_cycles, l2_traffic_cycles, system_cache_traffic_cycles, dram_traffic_cycles	cycles	Estimated cycles attributed to traffic on each memory path.
input_reader_cycles	cycles	Estimated cycles for the input-reader section.
convolution_engine_cycles	cycles	Estimated cycles for the convolution-engine section.
vector_engine_cycles	cycles	Estimated cycles for the vector-engine section.
transform_unit_cycles	cycles	Estimated cycles for the transform-unit section.
weight_decoder_cycles	cycles	Estimated cycles for the weight-decoder section.
output_writer_cycles	cycles	Estimated cycles for the output-writer section.

Memory and hardware-section names are normalized to lowercase snake case. For example, SystemCache becomes the system_cache_ prefix. In estimator mode, breakdown values are estimates from the performance model rather than hardware measurements. In measured profiling mode, breakdown values are derived from captured hardware counters. Their interpretation depends on the statistics format; see the aggregation rules for mode 0 statistics and mode 1 statistics.

Do not add breakdowns from related entities together. Authoritative and projected breakdowns at different hierarchy levels can describe overlapping views of the same work.

ETRecord/ETDump adds stripe and compiler backend_operator entities to measured VGF observations. Ordinary ETDump runtime observations have source-operator breakdowns in milliseconds, with unavailable model-cycle and latency metrics when those cannot be measured. See ETRecord and ETDump for cycle summaries, repeated executions, runtime statistics and mapping confidence.

Interpreting L1/cache write bytes

At model level, cache_write_bytes is the total estimated traffic passing through the L1 path. At layer-breakdown level, the corresponding metric is l1_write_bytes.

These metrics do not mean that the compiler allocated data in L1 or generated an output that is stored there. The performance model counts the following traffic as L1 writes:

• writes whose destination is L2, because those writes pass through L1; and
• partial writes whose destination is DRAM, because those writes also pass through L1.

Consequently, an L1/cache write metric can be nonzero even when no output is stored in L1. Memory-level byte counters describe traffic through a path, not allocation or residency at that memory level.

Entity provenance

NX results describe several related views of the analyzed work:

• segment identifies a graph segment from the original VGF sequence when a VGF model is supplied. Capture-only profiling instead synthesizes segment 0 to represent the selected captured pipeline.
• cascade and chain identify estimator scheduling groups.
• performance_group connects an aggregate estimator record to multiple source operators when it cannot be attributed to one operation.
• source_operator identifies a canonical source operation.
• nn_module and code_stack preserve framework-module and source-code provenance when debug information provides it.

Core MLIA normalizes and validates these relationships. It may derive source-line entities and project missing breakdowns to related views without replacing an existing authoritative breakdown.

Breakdown aggregation

NX cycle, byte, traffic, and hardware-section counters use aggregation: "sum". This declares that compatible breakdowns from distinct accounting origins may be combined when core projects figures across the entity graph. Existing breakdowns remain authoritative.

For ETDump, averages can be combined only when they cover the same recorded executions. Percentiles, minima, maxima and execution counts are non-additive. Shared or partially mapped runtime observations also have non-additive averages and event counts. See ETRecord and ETDump.

Estimator versus measured mode

Estimator results contain performance estimates and omit the optional mode field. Measured profiling results set mode to measured. Structured captures record capture device, statistics files, debug databases, and selected dispatches in backend and runtime metadata. ETRecord/ETDump results record input paths, the selected method and, for VGF profiling, effective decoder settings and fallback assumptions.

Estimator and structured-capture modes share per-segment correlation, totals, warnings, entity provenance, and breakdown aggregation. ETDump has additional execution-coverage and shared-timing rules described above. Compute-only VGF segments that are excluded from NX analysis are reported through warnings.

Aggregating mode 0 neural statistics

When analyzing a neural statistics capture with “mode 0” statistics, MLIA sums the section counters across all tasks in each stripe and uses that sum for both op_cycles and total_cycles. These values are accumulated further when stripes are combined.

The values represent accumulated section-active cycles, not elapsed execution time. These statistics provide neither core assignments nor timestamps, so MLIA does not correct for parallel tasks or overlapping section activity. The totals are not directly equivalent to the estimator’s cycle predictions. The result’s measured designation identifies the source of the counters, not a measurement of elapsed duration.

Aggregating mode 1 neural statistics

When analyzing a neural statistics capture with “mode 1” statistics, MLIA groups the tasks in each stripe by their captured core ID. It sums each counter within each group, then reports the maximum group total for that counter. This applies to all active and stall counters. Each counter is calculated independently, so the maxima can come from different cores. No core IDs or per-core figures are included in the output.

For each stripe, both op_cycles and total_cycles use the aggregated nx_active counter, including when it is zero. Other counters are reported independently. Stripe values are then summed when constructing chain, cascade and model totals.

This calculation treats activity on different cores as overlapping. The capture does not provide timestamps to reconstruct staggered starts, idle gaps or overlap between stripes. The resulting cycle values are derived from measured activity counters, not measurements of elapsed execution time. They are not directly equivalent to the estimator’s cycle predictions.

Generated artifacts

Depending on the input and mode, the output directory can contain:

• framework-conversion and ML SDK converter artifacts;
• NX Performance Estimator-compatible VGF segment files;
• estimator performance and debug databases;
• nx_performance_statistics.json; and
• an effective model copied from a capture-only profiling run.

Use these artifacts to determine whether a failure occurred during conversion, segment preparation, estimator execution, capture ingestion, or standardized result construction.

Static optimization advice

You may see an advice section advising to opt for a normal 3x3 convolution over a depthwise 3x3 convolution to 1x1 convolution chain. The "fewer than 64 output channels" refers to the 1x1 convolution's output channels - the first dimension of its weight shape.

Cross-links

• See Backends and analysis modes for backend ownership.
• See CLI for commands that produce estimator and measured results.
• See Troubleshooting for conversion, estimator, and profiling-data diagnostics.

Terminal compatibility reasons

NX compatibility uses the shared entity-linked check structure. Current estimator debug databases report NX, EE or NX/EE placement, not per-operator rejection diagnostics. Checks for those reported placements pass and have an empty details.reasons list:

{
  "id": "nx_support_0",
  "entity_id": "source_operator/example",
  "status": "pass",
  "details": {"reasons": []}
}

When a backend provides a reason, the shared representation is a details.reasons list of description/detail objects. NX does not currently populate these from its placement data. EE placement is supported execution, not CPU fallback. An operation omitted by the compiler is not evidence of an unsupported operation. Compiler failures remain whole-model errors with the available diagnostic; they are not converted into operator reasons.

The terminal retains Name, Kind, ID and Placement, and shows Reason only when a displayed entity has a reported reason. Consequently current NX placement results do not show that column. JSON retains kind and the explicit empty reasons lists. Supporting per-operator NX rejection reasons requires an attributable diagnostic source from the toolchain.