Arm Adds Visual Graph Debugging for Edge Compilers to Model Explorer

Why edge deployment needs visual inspection

Machine learning models now run locally on hardware ranging from low-power edge devices to gaming graphics and physical AI systems. According to Google, running models efficiently on these targets requires compilation steps such as quantization, graph lowering, operator fusion and hardware delegation.

Each of those steps can change the exported execution graph. Google lists three questions engineers often face: whether graph lowering introduced unintended operators such as extra layout transposes, whether a model is fully delegated to the NPU or GPU or whether unsupported subgraphs fall back to the CPU, and which nodes in the lowered graph take the most compute cycles.

Answering them by reading raw flatbuffers or text logs takes time, the post says, especially for large language models (LLMs) and neural networks. Arm needed a visual tool for its own intermediate representations and hardware profiling traces.

Three workflows built on Model Explorer

Using Model Explorer's hierarchical graph visualization and plugin architecture, Arm developed custom adapters for the TOSA, VGF and PTE model formats. Google describes three uses.

• Catching export regressions in VGF: Arm engineers validated a PyTorch-trained Neural Super Sampling (NSS) model exported through the ExecuTorch Arm backend as a VGF file for Vulkan ML Extensions. Inspecting the graph revealed unintended TRANSPOSE operators introduced by a change in the ExecuTorch Arm backend. Model Explorer showed individual node attributes and SPIR-V tensor connections, which helped the team resolve the regression without manual analysis of raw log files.
• Verifying NPU delegation: For an Ultralytics YOLO model targeting the Arm Ethos-U85 NPU, engineers used the split-pane view to compare CPU and NPU-delegated graphs side by side. The CPU graph shows each individual layer, while the NPU graph groups the network into a single EthosUBackend block between quantize and dequantize nodes. For partially supported models in LiteRT or ExecuTorch, Google says this view helps identify un-delegated operators and split subgraphs.
• Finding hardware bottlenecks: Arm ran a model on its Fixed Virtual Platform (FVP) simulator and used Model Explorer's node data plugin to overlay cycle-accurate execution traces onto the graph. Color-coded heatmaps showed that a single TRANSPOSE node was the main latency bottleneck.

Getting started

Google says developers can use Model Explorer with Arm's open-source adapters today to inspect and optimize their own on-device models locally, via PyPI or GitHub. After installing Model Explorer, users install the adapter for their model format and launch the tool.

The LiteRT, PyTorch and Hugging Face Transformers adapters are built in. The TOSA, VGF and PTE adapters are Arm plugins. The post points to a User Guide covering features such as graph navigation and side-by-side split view.

What it means for developers

For teams deploying models to edge accelerators, the case studies show a way to check exported graphs, delegation and performance in one visual environment instead of parsing logs. Two of the three examples involved unexpected TRANSPOSE operators, one as a regression and one as a latency bottleneck, which illustrates the kind of issue the tooling is meant to surface. Because the adapters are open source and plug into Model Explorer's architecture, the approach is available to developers working with the supported formats.