Googles LiteRT Tensor API: On-Device-Modelle Operation für Operation in C++ bauen

Warum Google einen nativen Entwicklungsweg geschaffen hat

Laut Google besteht der gängigste Weg, Modelle in der Produktion einzusetzen, darin, ein trainiertes Modell zu konvertieren, etwa ein PyTorch-Modell mit LiteRT Torch, und es mit der LiteRT-Runtime auszuführen. Das Unternehmen bezeichnet dies als schnellsten und zuverlässigsten Weg und empfiehlt ihn weiterhin für die meisten Projekte.

Manche Entwickler wünschen sich jedoch mehr Kontrolle, zum Beispiel um neue Architekturen zu unterstützen oder neue Lowering-Logik auszuprobieren, ohne auf Updates der vorgelagerten Frameworks zu warten. Sie schreiben Berechnungen oft von Hand in nativem C++ oder in Shader-Sprachen. Google verweist auf Apples MLX und llama.cpp als Beispiele dafür, wie weit dieser Code-first-Ansatz tragen kann.

Der Preis, so der Beitrag: Solche Implementierungen sind eng an bestimmte Backends wie Metal, OpenCL oder Vulkan gekoppelt und müssen für jede neue Hardware neu geschrieben werden. Auch das Verwalten von Zero-Copy-Pufferinteroperabilität und Synchronisierung über CPU, GPU und NPU hinweg erfordert erheblichen manuellen Entwicklungsaufwand, ebenso das Zusammenführen von Vorverarbeitung, Inferenz und Nachverarbeitung.

Was die Tensor API bietet

Entwickler bauen den Berechnungsgraphen in C++ auf und legen genau fest, welche Operationen laufen und wie sie verbunden sind. Derselbe Graph kann über LiteRT auf CPU, GPU (auf Basis des Open-Source-Projekts ML Drift) und NPU laufen oder direkt auf der CPU über XNNPACK, ganz ohne Modelldatei und Runtime. Google nennt vier zentrale Funktionen:

• Volle Kontrolle über die Graphstruktur: Entwickler bestimmen jede Operation und jede Verbindung, von elementweiser Mathematik bis zu beschleunigeroptimierten zusammengesetzten LLM-Operationen wie Scaled Dot-Product Attention, RMSNorm und KV-Cache-Updates.
• Direktes Einlesen der Gewichte: Gewichte werden direkt aus Checkpoints wie Hugging-Face-Dateien im Format .safetensors geladen, ohne dazwischengeschaltete Konvertierungsskripte.
• Tensorzentrierte Pufferinteroperabilität: Vorverarbeitung, Modellpartitionen und Nachverarbeitung reichen Tensoren über gemeinsame Beschleunigerpuffer weiter, sodass Zwischendaten ohne Kopien auf dem Beschleuniger bleiben.
• Bausteine für KI-Agenten: Da Modelle schlichtes C++ aus klar definierten Operationen sind, können Coding-Agenten ein Modell aufbauen, seine Ergebnisse mit einer Referenz abgleichen und Varianten auf jedem Gerät benchmarken.

In den Codebeispielen ist jede Schicht eine C++-Funktion über Tensor-Werte. Das Backend wird als Template-Argument übergeben: TfLiteMixinTag exportiert eine .tflite-Datei, die LiteRT auf CPU, ML Drift (GPU) oder NPU ausführt, während XnnpackMixinTag denselben Code direkt über XNNPACK auf der CPU laufen lässt. Tensoren lassen sich mit beiden Tags versehen, um beide Optionen offenzuhalten.

Google empfiehlt einen Workflow, der beides nutzt: zunächst auf dem direkten XNNPACK-Pfad iterieren und die Gewichte aus dem .safetensors-Checkpoint laden, ohne dass eine Modelldatei neu gebaut werden muss. Zur Auslieferung wird dann eine .tflite-Datei exportiert, die mit LiteRT auf Mobilgeräten oder über LiteRT.js im Web läuft.

Segment-Anything-Demo und Leistungsangaben

Um die API in der Praxis zu zeigen, hat Google eine interaktive Segment-Anything-App gebaut, die vollständig auf dem Gerät im Browser über WebGPU läuft. Sie führt mit Metas Segment Anything Model 2 (SAM 2) eine Echtzeit-Segmentierung und -Verfolgung mehrerer Objekte durch, ausgelöst per Klick oder über Prompts in natürlicher Sprache, die Gemma 4 E2B verarbeitet.

Das SAM-2-Modell ist vollständig mit der Tensor API in C++ geschrieben. Laut Google hat es ein Coding-Agent verfasst und von unter 10 auf über 30 Bilder pro Sekunde bei 512x512 auf WebGPU weiterentwickelt. Die vollständige Implementierung und die Web-App sind im GitHub-Repository LiteRT Samples als Open Source verfügbar.

Google ließ denselben C++-Code außerdem auf den GPUs von drei Geräten laufen: einem macOS-Laptop (Metal), einem iOS-Smartphone (Metal) und einem Android-Smartphone (OpenCL). In den Tests auf einem MacBook Pro lief das Modell rund 1,5-mal schneller als Apple MLX (fp16, Bild-Encoder plus Masken-Decoder). Google weist darauf hin, dass Vor- und Nachverarbeitung etwa 0,34 ms hinzufügen und die Ausgabemasken Pixel für Pixel mit der PyTorch-Referenz von Meta übereinstimmen. Das Beispiel SAM 2.1 enthält Benchmark-Befehle, mit denen sich die Ergebnisse nachvollziehen lassen.

Die gesamte Pipeline auf dem Beschleuniger halten

Google betont, dass eine echte App mehr braucht als das Netzwerk selbst. In der Demo besteht der Weg von einem Kamerabild und einem Klick zur Maske aus vier Schritten: Vorverarbeitung, Bild-Encoder, Masken-Decoder und Nachverarbeitung. In einer typischen App läuft nur das Modell auf der GPU, während die CPU Bilder skaliert, die Encoder-Ausgabe an den Decoder übergibt und die Maske nachbearbeitet. Jeder dieser Wechsel kopiert Daten und bremst die GPU aus, heißt es in dem Beitrag.

Im Beispiel sam2 sind alle vier Schritte Tensor-API-Graphen auf der GPU. Sie werden beim Start einmalig so verbunden, dass sie Puffer teilen, und laufen dann für jedes Bild und jeden Klick.

Was das für Entwickler bedeutet

Google stellt klar, dass die Konvertierung für die meisten Modelle die beste Standardlösung bleibt. Die Tensor API richtet sich an Entwickler, die Low-Level-Kontrolle über den Graphen benötigen oder eine komplette Pipeline durchgängig auf dem Beschleuniger ausführen wollen, ohne sie für jede Zielhardware neu zu schreiben. Das Unternehmen sieht sie zudem als programmatische Grundlage für KI-Coding-Agenten, die Modellgraphen automatisch erzeugen, umverdrahten und optimieren.