Arm bringt visuelles Graph-Debugging für Edge-Compiler in den Model Explorer

Warum der Edge-Einsatz visuelle Inspektion braucht

Modelle des maschinellen Lernens laufen heute lokal auf Hardware, die von stromsparenden Edge-Geräten über Grafik für Spiele bis zu Physical-AI-Systemen reicht. Laut Google erfordert ein effizienter Betrieb auf diesen Zielplattformen Compilerschritte wie Quantisierung, Graph Lowering, Operator Fusion und Hardware-Delegation.

Jeder dieser Schritte kann den exportierten Ausführungsgraphen verändern. Google nennt drei Fragen, mit denen Ingenieure häufig konfrontiert sind: ob das Graph Lowering unbeabsichtigte Operatoren wie zusätzliche Layout-Transpositionen eingeführt hat, ob ein Modell vollständig an die NPU oder GPU delegiert wird oder ob nicht unterstützte Teilgraphen auf die CPU ausweichen, und welche Knoten im gelowerten Graphen die meisten Rechenzyklen benötigen.

Diese Fragen durch das Lesen von rohen Flatbuffers oder Textlogs zu beantworten, kostet laut dem Beitrag viel Zeit, besonders bei großen Sprachmodellen (LLMs) und neuronalen Netzen. Arm brauchte daher ein visuelles Werkzeug für die eigenen Zwischenrepräsentationen und Hardware-Profiling-Traces.

Drei Workflows auf Basis von Model Explorer

Auf Grundlage der hierarchischen Graphvisualisierung und der Plugin-Architektur von Model Explorer hat Arm eigene Adapter für die Modellformate TOSA, VGF und PTE entwickelt. Google beschreibt drei Einsatzszenarien.

• Export-Regressionen in VGF aufspüren: Arm-Ingenieure validierten ein in PyTorch trainiertes Neural-Super-Sampling-Modell (NSS), das über das ExecuTorch-Arm-Backend als VGF-Datei für Vulkan ML Extensions exportiert wurde. Die Inspektion des Graphen offenbarte unbeabsichtigte TRANSPOSE-Operatoren, die durch eine Änderung im ExecuTorch-Arm-Backend entstanden waren. Model Explorer zeigte einzelne Knotenattribute und SPIR-V-Tensorverbindungen an, was dem Team half, die Regression ohne manuelle Analyse roher Logdateien zu beheben.
• NPU-Delegation überprüfen: Für ein Ultralytics-YOLO-Modell, das auf die Arm Ethos-U85 NPU zielt, verglichen Ingenieure in der Split-Pane-Ansicht den CPU-Graphen und den an die NPU delegierten Graphen nebeneinander. Der CPU-Graph zeigt jede einzelne Schicht, während der NPU-Graph das Netz zu einem einzigen EthosUBackend-Block zwischen Quantize- und Dequantize-Knoten zusammenfasst. Bei teilweise unterstützten Modellen in LiteRT oder ExecuTorch hilft diese Ansicht laut Google, nicht delegierte Operatoren und aufgespaltene Teilgraphen zu erkennen.
• Hardware-Engpässe finden: Arm ließ ein Modell auf seinem Simulator Fixed Virtual Platform (FVP) laufen und blendete mit dem Node-Data-Plugin von Model Explorer zyklusgenaue Ausführungs-Traces in den Graphen ein. Farblich codierte Heatmaps zeigten, dass ein einzelner TRANSPOSE-Knoten der wichtigste Latenzengpass war.

So gelingt der Einstieg

Entwickler können Model Explorer laut Google schon heute mit den Open-Source-Adaptern von Arm nutzen, um eigene On-Device-Modelle lokal zu untersuchen und zu optimieren, per PyPI oder GitHub. Nach der Installation von Model Explorer installieren Nutzer den Adapter für ihr Modellformat und starten das Tool.

Die Adapter für LiteRT, PyTorch und Hugging Face Transformers sind bereits integriert. Die Adapter für TOSA, VGF und PTE sind Arm-Plugins. Der Beitrag verweist auf einen User Guide, der Funktionen wie Graphnavigation und die nebeneinander angeordnete Split-Ansicht behandelt.

Was das für Entwickler bedeutet

Für Teams, die Modelle auf Edge-Beschleunigern einsetzen, zeigen die Fallstudien einen Weg, exportierte Graphen, Delegation und Performance in einer visuellen Umgebung zu prüfen, statt Logs zu durchforsten. Zwei der drei Beispiele betrafen unerwartete TRANSPOSE-Operatoren, einmal als Regression und einmal als Latenzengpass. Das zeigt, welche Art von Problemen das Tooling sichtbar machen soll. Da die Adapter Open Source sind und sich in die Architektur von Model Explorer einklinken, steht der Ansatz Entwicklern offen, die mit den unterstützten Formaten arbeiten.