Wie man ein neuronales Netz plattformuebergreifend betreibt

Das Problem: gleiche App-Idee, verschiedene Hardware

Auf dem iPhone laufen Modelle typischerweise ueber Core ML, Metal/GPU und Apple Neural Engine. Auf Android haengt die Beschleunigung vom Geraet ab: Qualcomm Snapdragon kann Hexagon NPU und Adreno GPU nutzen, andere Hersteller bringen eigene NPUs und Treiber mit. Dazu kommen CPU- Fallbacks, unterschiedliche Android-Versionen und verschiedene Runtime-APIs.

Eine App sollte deshalb nicht davon ausgehen, dass "NPU" ueberall dasselbe bedeutet. Besser ist eine stabile App-Schnittstelle: predict(strokes) -> topK labels. Darunter darf die Implementierung je nach Plattform unterschiedlich sein.

Empfohlene Strategie fuer ein kleines QuickDraw-CNN

Fuer DrawLa ist die Aufgabe ueberschaubar: Strokes werden in ein 1 x 96 x 96-Bild gerastert, ein CNN berechnet 345 Logits, und die App zeigt die wahrscheinlichsten Begriffe. Dieses Modell ist klein genug, um auf beiden Mobilplattformen lokal zu laufen.

PyTorch training checkpoint
  -> neutraler Export: ONNX
  -> iOS: Core ML / .mlpackage
  -> Android: TFLite, LiteRT oder ONNX Runtime Mobile
  -> gemeinsame App-API: predict(strokes)

Der Kern bleibt gleich: Das Modell wurde einmal trainiert und getestet. Fuer die Auslieferung entstehen aber zwei oder mehr optimierte Artefakte. Das ist normal und meist besser als eine Minimal-Lösung, die auf beiden Plattformen laeuft, aber keine davon gut ausnutzt.

Option A: ONNX Runtime Mobile als gemeinsamer Nenner

ONNX Runtime Mobile kann ONNX-Modelle auf iOS und Android ausfuehren. Das ist attraktiv, wenn man ein einheitliches Modellformat behalten moechte. Fuer ein kleines CNN ist ONNX besonders naheliegend, weil die Operatoren einfach sind: Faltungen, Normalisierung, Aktivierung, Pooling und lineare Schicht.

Vorteil: ein neutraler Exportpfad aus PyTorch, eine Runtime-Familie fuer beide Plattformen. Nachteil: maximale Hardwarebeschleunigung und Binary-Groesse muessen trotzdem pro Plattform getestet werden.

Quelle: ONNX Runtime Mobile.

Option B: Native Artefakte fuer beste Plattformpassung

Fuer iPhone ist Core ML der native Weg. Mit coremltools lassen sich PyTorch-Modelle direkt in Core-ML-Formate konvertieren. Apple kann dann CPU, GPU und Neural Engine passend einsetzen, sofern das Modell und die Operatoren geeignet sind.

Auf Android sind TensorFlow Lite, LiteRT oder ONNX Runtime Mobile typische Wege. Fuer Qualcomm-Geraete koennen zusaetzliche SDKs oder Delegates interessant sein. Diese Variante erzeugt mehrere Artefakte, ist aber in Produktapps oft die robusteste Performance-Strategie.

Quellen: Core ML Tools, TensorFlow Lite Android.

Option C: ExecuTorch fuer PyTorch-nahe Deployments

ExecuTorch ist PyTorchs Deployment-Weg fuer On-Device-AI. Es zielt auf Mobiltelefone, Embedded-Systeme und Edge-Geraete und kann fuer Teams attraktiv sein, die Training, Export und Deployment moeglichst lange im PyTorch-Oekosystem halten wollen.

Fuer DrawLa waere ExecuTorch technisch plausibel, aber man muesste pruefen, ob der Overhead gegenueber ONNX Runtime Mobile oder Core ML / TFLite gerechtfertigt ist. Bei einem kleinen CNN ist die einfachere Runtime oft die bessere Wahl.

Quelle: ExecuTorch Documentation.

Wo NexaSDK hineinpasst

NexaSDK existiert weiterhin und bietet Android- sowie iOS/macOS-SDKs. Nach aktueller Doku ist der Android-Teil stark auf Qualcomm/Snapdragon, NPU/GPU/CPU und Modelle wie LLMs/VLMs ausgerichtet. Die iOS/macOS-Doku beschreibt NexaML, iOS 17/macOS 15 als Mindestziel und ANE-Support derzeit vor allem fuer ASR und Embeddings; andere Module laufen ueber GPU/CPU.

Fuer ein kleines QuickDraw-CNN ist Nexa deshalb eher ein interessanter Kontext als die erste Wahl. Wenn man LLM/VLM-Funktionen in derselben App plant, kann Nexa relevant werden. Fuer reine Skizzenklassifikation ist Core ML, TFLite/LiteRT, ONNX Runtime Mobile oder ExecuTorch direkter.

Quellen: Nexa Android SDK, Nexa iOS/macOS SDK.

Pragmatische Zielarchitektur fuer DrawLa

Die sauberste Architektur trennt drei Dinge: Training, Modellartefakte und App-Schnittstelle. Training bleibt in PyTorch. Der Export erzeugt getestete Artefakte fuer iOS und Android. Die App selbst kennt nur eine kleine Inferenzschnittstelle und muss nicht wissen, ob darunter Core ML, ONNX Runtime oder TFLite laeuft.

shared Dart/Swift/Kotlin API
  rasterize(strokes) -> Float32/UInt8 tensor
  predict(tensor) -> topK labels

iOS backend
  Core ML model

Android backend
  ONNX Runtime Mobile or TFLite/LiteRT model

So bleibt die Produktlogik plattformuebergreifend, waehrend jede Plattform ihren besten Inferenzpfad nutzen kann. Fuer eine schnelle Zeichenerkennung ist das meist wichtiger als ein einzelnes Framework, das auf dem Papier alles kann.