LiteRT.js: Lokale KI im Browser belastbar einsetzen

Eine Upload-Seite soll vor dem Absenden erkennen, ob ein Foto stark verwackelt oder zu dunkel ist. Statt jedes Bild für diese Vorprüfung an einen Server zu senden, kann ein kleines Modell direkt im Browser einen Qualitätswert berechnen. Wir verfolgen diesen Ablauf von der Geräteerkennung bis zum sichtbaren Fallback.

Google stellte LiteRT.js am 9. Juli 2026 als Web-Laufzeit für kompatible LiteRT-Modelle vor. Die offizielle Dokumentation beschreibt Ausführung über WebAssembly, WebGPU und WebNN, doch tatsächliche Verfügbarkeit und Leistung hängen von Browser, Gerät und Modell ab.

Den lokalen Foto-Flow klar begrenzen

Die Funktion beantwortet nur eine Frage: Ist die Aufnahme wahrscheinlich gut genug für den nächsten Schritt? Sie soll weder Personen erkennen noch Inhalte dauerhaft speichern. Nach der Auswahl zeigt die Seite „geeignet“, „bitte neu aufnehmen“ oder „Prüfung auf diesem Gerät nicht verfügbar“.

Diese enge Aufgabe hält Modell, Oberfläche und Tests überschaubar. Wie bei Vibe Coding entsteht zuerst ein kleiner, überprüfbarer Nutzen, bevor zusätzliche Bildanalyse hinzukommt.

Fähigkeiten vor dem Modellstart erkennen

Die App darf WebGPU oder WebNN nicht einfach voraussetzen. Sie prüft verfügbare APIs, unterstützte Umgebung und ausreichend Ressourcen, bevor sie einen Beschleuniger wählt. Gleichzeitig zeigt sie einen neutralen Ladezustand, weil der erste Modellabruf spürbar dauern kann.

LiteRT.js akzeptiert laut Dokumentation webgpu, webnn und wasm als Beschleuniger. Accelerator-Listen können einen CPU-Fallback ausdrücken; die aktuelle Dokumentation warnt jedoch davor, beliebige Nicht-CPU-Ketten als unterstützt anzunehmen. Prüfe die konkret eingesetzte Version und Zielumgebung.

Modell laden, kompilieren und wiederverwenden

Der Einstieg erfolgt in der Dokumentation über loadAndCompile, zum Beispiel mit einem Modellpfad und dem gewünschten Beschleuniger. Diese Operation gehört nicht in jeden Button-Klick. Lade und kompiliere einmal kontrolliert, halte den Zustand sichtbar und verwende die Instanz für weitere Fotos wieder.

Plane Fehler beim Download, eine beschädigte Modelldatei und zu wenig Speicher ein. Ein abgebrochener Start darf die Seite nicht dauerhaft sperren; biete erneutes Laden oder den vereinbarten Ersatzweg an.

const model = await loadAndCompile('/models/photo-quality.tflite', {
  accelerator: ['webgpu', 'wasm'],
});

Das Beispiel zeigt nur die Auswahlidee. Eingabeform, Vorverarbeitung und Ergebnisinterpretation müssen zum tatsächlich verwendeten Modell passen und anhand seiner Dokumentation implementiert werden.

Das Foto lokal vorverarbeiten

Die App liest die ausgewählte Datei in einen lokalen Bildpuffer, richtet Größe und Farbwerte so aus, wie das Modell sie erwartet, und startet die Inferenz. Das Originalfoto muss dafür nicht automatisch hochgeladen werden. Nach dem Lauf wird nur der benötigte Qualitätsstatus im UI angezeigt.

Vorverarbeitung ist eine häufige Fehlerquelle. Vertauschte Farbkanäle, falsche Skalierung oder gedrehte Smartphone-Fotos können ein korrektes Modell unbrauchbar wirken lassen. Testbilder mit bekannten Eigenschaften helfen, den Datenpfad unabhängig von der Oberfläche zu prüfen.

Einen transparenten Fallback gestalten

Wenn WebGPU fehlt, kann WebAssembly auf der CPU eine breitere Basis bieten, ist aber möglicherweise langsamer. Reicht auch dieser Pfad auf einem Gerät nicht aus, darf die App die Prüfung überspringen und eine manuelle Sichtkontrolle anbieten. Ein optionaler Server-Fallback braucht eine ausdrückliche Information und Zustimmung, weil das Foto dann das Gerät verlässt.

Der Ersatzweg darf nicht heimlich wechseln. Zeige etwa: „Lokale Prüfung ist nicht verfügbar. Du kannst das Foto ohne automatische Prüfung fortsetzen oder es zur Serverprüfung senden.“ Damit bleibt die Nutzerentscheidung mit dem tatsächlichen Datenweg verbunden.

Beschreibe diesen Zustand schon im Implementierungsauftrag und lege fest, welcher Weg ohne Zustimmung erlaubt ist. Die Struktur aus Dein erster guter Prompt hilft, lokale Verarbeitung, UI-Text und Abnahmefälle gemeinsam zu formulieren. Teste anschließend jede Capability-Kombination gezielt, statt den Fallback nur aus dem Code abzuleiten.

Datenschutz über den gesamten Datenweg prüfen

Lokale Inferenz kann die Übertragung des Bildinhalts vermeiden. Trotzdem können Modell-Download, Analytics, Fehlerberichte oder andere Dienste Netzwerkanfragen erzeugen. Dokumentiere deshalb, welche Daten jede Komponente verarbeitet, wie lange sie bestehen und ob sie das Gerät verlassen.

Vermeide Fotoausschnitte oder Modellinputs in Telemetrie. Für technische Fehler reichen oft Ereignisart, Browserklasse und anonyme Laufzeitwerte. Eine Aussage wie „Fotos bleiben lokal“ ist erst dann belastbar, wenn Netzwerkprüfung und Konfiguration sie im gesamten Flow bestätigen.

Auf echten Zielgeräten messen

Googles Blog nennt Leistungswerte aus kontrollierten Anbieterbenchmarks. Diese Zahlen sind keine Garantie für deine App, weil Modell, Browser, Hardware, Temperatur und Speicherdruck variieren. Miss erste Ladezeit, wiederholte Inferenz, Spitzenspeicher und Abbruchrate auf repräsentativen Mobil- und Desktopgeräten.

Das offizielle Model Tester-Werkzeug kann unterstützte Pfade mit zufälligen Eingaben prüfen und Benchmark-Läufe unterstützen. Ergänze diese technische Messung durch echte Testfotos und den vollständigen UI-Ablauf.

Fehler- und Randfälle abdecken

Teste sehr große Bilder, unbekannte Dateiformate, gedrehte Aufnahmen, mehrere schnelle Auswahlen und einen Tabwechsel während der Berechnung. Der zuletzt gewählte Datensatz muss zum angezeigten Ergebnis gehören; ein verspäteter älterer Lauf darf ihn nicht überschreiben. Begrenze parallel laufende Inferenz, damit die Oberfläche responsiv bleibt.

Auch ein Qualitätsmodell kann falsch liegen. Formuliere den Hinweis als Unterstützung und lasse eine Aufnahme wiederholen oder manuell akzeptieren. Für folgenreiche Entscheidungen ist eine automatische Browserbewertung ohne fachliche Prüfung nicht ausreichend.

Berücksichtige außerdem Modellaktualisierungen. Eine neue Datei kann andere Eingabeformen, Schwellenwerte oder Leistungsprofile haben und muss deshalb wie eine Funktionsänderung getestet werden. Versioniere Modell und Vorverarbeitung gemeinsam, damit ein gemeldetes Ergebnis später reproduzierbar bleibt.

Checkliste für lokale Browser-KI

• Aufgabe, Modelloutput und ausdrücklich ausgeschlossene Verwendungen sind dokumentiert.
• Browserfähigkeiten werden vor Laden und Ausführung geprüft.
• Modellstart, Downloadfehler und Speichermangel besitzen verständliche Zustände.
• Vorverarbeitung wird mit bekannten Testbildern separat validiert.
• CPU-, Server- oder manueller Fallback ist sichtbar und bewusst gewählt.
• Netzwerk, Analytics und Fehlertelemetrie werden als Gesamtdatenweg geprüft.
• Ladezeit, Laufzeit und Speicher sind auf repräsentativen Geräten gemessen.
• Falsche Modellurteile, parallele Läufe und Abbrüche sind im UI beherrscht.