Google's Model Explorer starts debugging custom on-device AI compilers with Arm adapters

Anyone who optimizes AI models to run on constrained hardware knows the problem: the model that works well on a laptop goes through quantization, graph lowering, operator fusion, and hardware delegation before reaching the final device, and any one of these steps can introduce a silent regression. Until now, debugging this pipeline meant reading raw flatbuffers or combing through text logs, a slow process especially for large models.

On October 20, 2026, Google published, in a post signed by Eric Yang and Alan Ma on the Google Developers Blog, how Arm used Google AI Edge Model Explorer, a free model graph visualization tool, to solve this problem. Arm built open-source adapters that plug its own intermediate formats directly into the Model Explorer interface, opening up the black box of compilation for edge hardware.

The problem Arm was trying to solve

According to the post, every time a framework changes or an operation hits a hardware constraint, the exported execution graph can change unexpectedly. This leaves three open questions for anyone optimizing the deployment:

• Structural integrity: did graph lowering introduce unwanted operators, such as extra layout transposes?
• Hardware delegation: is the model fully delegated to the NPU or GPU, or do unsupported subgraphs fall back to the CPU?
• Cycle-level bottlenecks: which nodes in the compiled graph consume the most compute cycles?

Answering these questions by reading flatbuffers or text logs works, but it doesn't scale for LLMs and large neural networks. That was the motivation for Arm to build a dedicated visual layer on top of Model Explorer.

Three formats, one visualizer

Arm developed adapters for three intermediate representation formats used in its own compilation pipelines: TOSA, VGF, and PTE. Each one addresses a different stage of the path between the trained model and the binary that runs on silicon.

The adapters are either built-in (LiteRT, PyTorch, and Hugging Face Transformers) or Arm plugins (TOSA, VGF, and PTE), and are available via PyPI or GitHub, according to the documentation linked in the original post.

Case 1: the regression that only showed up in the exported graph

The post's first practical example involves a Neural Super Sampling (NSS) model trained in PyTorch and exported by the Arm ExecuTorch backend as a VGF file for Vulkan ML Extensions. When inspecting the graph in Model Explorer, the Arm team found TRANSPOSE operators that shouldn't have been there, introduced by a change in the Arm ExecuTorch backend itself.

The relevant point here isn't the bug itself, but how it was found: by clicking on the graph node (in this example, a rescale operator), Model Explorer shows the attributes and SPIR-V tensor connections for that specific node. This eliminates the step of opening the raw file and manually cross-referencing offsets, which is how this kind of regression is usually hunted down today in pipelines without visualization.

Case 2: NPU or CPU fallback, side by side

The second case uses Model Explorer's split-pane view, which compares two graphs simultaneously. Arm used this feature to place side by side the graph of an Ultralytics YOLO model running on CPU and the same model delegated to the Arm Ethos-U85 NPU.

The structural difference shows up immediately: the CPU graph shows each layer individually, while the NPU-delegated graph groups the entire network into a single EthosUBackend block, between quantize and dequantize nodes. For models partially supported in LiteRT or ExecuTorch, this view identifies exactly which operators were left out of delegation and where the subgraph was fragmented, something that normally requires tracing separate compilation logs for CPU and NPU.

Case 3: the heatmap that pinpoints the real bottleneck

The third example is the most interesting one for anyone dealing with performance on low-power hardware. Arm ran the model on the Ethos-U Fixed Virtual Platform (FVP) simulator and used Model Explorer's node data plugin to overlay the cycle-by-cycle execution trace directly on the graph, as a heatmap colored by node.

The result, according to the post, pointed to a single TRANSPOSE node as the main latency bottleneck for the entire pipeline. It's the kind of finding that traditional profiling delivers as an isolated number in a table, but that only truly makes sense when visualized on top of the graph topology, showing exactly where that node sits relative to the rest of the execution.

How to install and test

The process described in the post involves a few steps:

1. Install Google AI Edge Model Explorer.
2. Install the adapter corresponding to your model's format (LiteRT, PyTorch, and Hugging Face Transformers come built in; TOSA, VGF, and PTE are Arm plugins).
3. Open Model Explorer pointing to the model file.
4. Use graph navigation and the split view to compare versions or backends.

The adapters and Model Explorer itself are available via PyPI and GitHub, and the documentation covers graph navigation and side-by-side comparison in more detail than the post summarizes.

What changes for teams optimizing on-device AI in Brazil

For Brazilian teams working with edge inference, whether in embedded computer vision, industrial automation, or consumer products with a dedicated NPU, the practical gain lies in cutting the time between "the model got slow" and "I know exactly which node is to blame." This matters especially for small teams that don't have an engineer dedicated to reading flatbuffers and already use ExecuTorch or LiteRT as their deployment path.

A scope caveat is worth noting: the TOSA, VGF, and PTE adapters are most useful for those already in the Arm ecosystem (Ethos-U, accelerated Cortex-M) or using Vulkan ML Extensions as an export target. Those working only with plain TFLite or running everything on generic server CPUs won't gain much from this specific part of the announcement, though the built-in adapters for LiteRT, PyTorch, and Hugging Face Transformers remain worthwhile for any on-device AI pipeline that already exports models in those formats.