Browser-AI lief auf dem Desktop gut. Dann fror auf dem Smartphone die UI ein.

Die erste Version funktionierte. Genau das war das Gefährliche daran.

Auf einem Desktop-Browser wirkte es akzeptabel, ein ONNX-Modell direkt in der App zu laden und session.run() aufzurufen. Das Ergebnis kam, das Feature sah fertig aus und man konnte leicht zum nächsten Punkt weitergehen. Dann traf derselbe Ablauf auf ein schwächeres Smartphone—und die Oberfläche fühlte sich plötzlich nicht mehr wie ein Produkt an.

Buttons reagierten spät. Fortschrittsanzeigen wurden zäh. Ein schwerer Inference-Lauf konnte die Seite eingefroren wirken lassen, obwohl das Modell am Ende das richtige Ergebnis lieferte.

Lokale AI ist keine gute User Experience, wenn die Oberfläche verschwindet, während das Modell nachdenkt.

Das Modell war lokal, die Arbeit blockierte trotzdem das Erlebnis

AI im Browser spart den Server-Roundtrip und kann private Eingaben auf dem Gerät halten. Der Workload wird dadurch nicht automatisch billig. Modellinitialisierung, Tensor-Vorbereitung, WebAssembly-Arbeit und Inference konkurrieren weiterhin mit der Oberfläche, wenn zu viel im Main Thread passiert.

Desktop-Hardware kann diesen Fehler verstecken. Mobile Hardware macht ihn schnell sichtbar. Selbst bei akzeptabler Gesamtdauer fühlt sich die Wartezeit länger an, wenn Feedback und Kontrolle fehlen.

Die sinnvolle Grenze war ein Web Worker

Die Lösung war keine neue Ladeanimation. Der Inference-Lifecycle brauchte eine eigene Ausführungsspur.

Wir verschoben das Laden von ONNX Runtime, die Erstellung der Model Session und session.run() in einen Web Worker. Der Main Thread übernahm die Oberfläche und ein kleines Message-Protokoll. Der Worker übernahm die schwere Modellarbeit.

• Die UI erstellt einen Client und bittet den Worker, ein Modell vorzuladen.
• Der Worker lädt ONNX Runtime und hält eine Model Session im Cache.
• Inputs überqueren die Grenze als serialisierbare Tensor-Daten.
• Der Worker führt die Inference aus und sendet serialisierte Output-Tensoren zurück.
• Fortschritt, Fehler, Timeouts und Dispose laufen durch dasselbe Protokoll.

Das Modell wurde dadurch nicht kleiner und Inference nicht kostenlos. Entscheidend war, dass die Seite weiter rendern, Status anzeigen und auf Nutzer reagieren konnte, während der Worker beschäftigt war.

Warum der Worker im public-Ordner liegt

Die wiederverwendbare Version nutzt einen klassischen Worker und importScripts(), um das ONNX-Runtime-Bundle zu laden. Dafür sind stabile statische URLs wichtig.

Ein vom Bundler verwalteter Worker mit new URL(..., import.meta.url) wirkt eleganter, doch Framework-Tooling kann Development und Production unterschiedlich behandeln. Gehashte Pfade oder injizierter Dev-Code werden besonders unangenehm, wenn der Worker klassische Syntax erwartet.

Worker, ONNX Runtime, WebAssembly-Dateien und Modell unter bekannten public-URLs auszuliefern ist weniger clever. Dafür ist es leichter zu verstehen und zu debuggen. Bei dieser Infrastruktur ist langweilig eine Stärke.

Der kleine Client-Wrapper ist genauso wichtig wie der Worker

Direkte postMessage-Aufrufe sind simpel, bis mehrere Requests, Progress-Events, Fehler und Cleanup-Regeln gleichzeitig existieren. Der Starter kapselt das Protokoll in einem Promise-basierten OnnxWorkerClient, sodass preload() und run() wie normale asynchrone Funktionen wirken.

Zusätzlich gibt es einen optionalen React Hook für Status, Fortschritt, Fehler, Preload, Run und Dispose. Der Kern bleibt trotzdem unabhängig von React und kann direkt in einer Plain-JavaScript-App genutzt werden.

Was im Starter enthalten ist

Wir haben die wiederverwendbare Infrastruktur aus Lumli herausgelöst und als kleinen MIT-lizenzierten Starter veröffentlicht. Ein Modell, Bild-Preprocessing und Produkt-UI sind bewusst nicht enthalten.

• Ein klassischer ONNX Worker, der die Runtime lädt und eine Session cached.
• Ein Promise-basierter Client für das Worker-Protokoll.
• Ein optionaler React Hook für den App-State.
• Eine minimale Demo-Komponente.
• Protokolltests für Requests, Responses, Fehler und Dispose.

Den ONNX Web Worker Starter auf GitHub öffnen

Ein Worker ist kein Performance-Wunder

Inference aus dem UI Thread zu verschieben schützt die Responsivität. Es entfernt keine Speichergrenzen, langsame Modellinitialisierung, große Downloads oder teures Preprocessing. Mobile Browser bleiben enger begrenzt als Desktop-Systeme.

Bei Bildmodellen ist ein kleinerer Input vor der Inference oft die wertvollste Optimierung. Schneide auf den relevanten Bereich zu, skaliere auf die tatsächlich benötigte Modellgröße, vermeide unnötige Kopien und teste mit dem echten Execution Provider auf echten Geräten.

Das Ziel ist nicht, Browser-AI mühelos klingen zu lassen. Jeder Teil des Produkts soll den richtigen Job haben: Die UI bleibt responsiv, der Worker übernimmt Inference und das Modell bleibt klein genug für die Geräte der Nutzer.

Warum wir die Infrastruktur veröffentlicht haben

Dieses Pattern zuverlässig zu machen dauerte länger, als es sollte. Sobald es funktionierte, wirkte es verschwenderisch, es in nur einem Produkt zu verstecken.

Das Repository ist bewusst klein genug, um es in einer Sitzung zu lesen, und auf nützliche Weise unvollständig: Bring dein eigenes Modell, Inputs, Preprocessing und UI mit. Worker-Grenze und Client-Protokoll sind bereits da, damit das nächste Browser-AI-Experiment näher am interessanten Problem startet.