BrowserAI: LLM-Inferenz im Browser-Tab statt auf dem Server

Welches Problem BrowserAI adressiert

Der übliche Weg, ein Sprachmodell in eine Webanwendung zu bringen, führt über einen Server: GPU mieten, Modellgewichte dort halten, Requests weiterleiten, Antworten streamen. Das kostet laufend Geld und bringt jeden Prompt auf fremde Hardware. BrowserAI dreht das um. Die Bibliothek lädt die Gewichte in den Browser-Tab und führt die Inferenz dort aus. Die README formuliert das als "100% Private" und "Zero Server Costs", was in dieser Absolutheit eine Marketingzusage ist, in der Sache aber den Kern trifft: Es gibt keinen Inferenz-Endpunkt, den man betreiben muss.

Die Zielgruppe benennt das Repository selbst: Webentwickler, die KI-Funktionen einbauen, Unternehmen mit Datenschutzauflagen, Forschende, die ohne Infrastruktur experimentieren wollen, und Anbieter von No-Code-Plattformen. Für alle vier gilt dieselbe Bedingung: Das Modell muss klein genug sein, um in einen Browser zu passen. Die dokumentierte Liste reicht von SmolLM2-135M bis DeepSeek-R1-Distill-Llama-8B, deckt also den Bereich kleiner und mittlerer Modelle ab, nicht Frontier-Größen.

Vier Engines unter einer API

Der interessanteste Teil von BrowserAI ist nicht die Chat-Oberfläche, sondern die Engine-Abstraktion. Die README listet MLC, Transformers, Flare und Demucs als austauschbare Backends, und die API bleibt über den Wechsel hinweg gleich: loadModel, dann generateText. Ein Modellname wie llama-3.2-1b-instruct läuft über MLC, llama-3.2-1b-flare über die WASM-Variante, whisper-tiny-en und kokoro-tts über Transformers. Der Aufrufer wählt das Backend also implizit über den Modellnamen, nicht über eine explizite Engine-Option. Das ist bequem und gleichzeitig die Stelle, an der man aufpassen muss: Welche Quantisierung ein Modell tatsächlich bekommt, ist an den Namen gebunden, nicht an einen Parameter.

Für die Audio-Trennung fällt die Abstraktion weg. Demucs wird über einen eigenen Importpfad @browserai/browserai/demucs geladen und bringt eine eigene Klasse DemucsEngine mit, die separate() statt generateText() anbietet. Das ist konsequent, weil die Ausgabe keine Token sind, sondern vier AudioBuffer für drums, bass, other und vocals. Wer die Bibliothek nur für Text nutzt, lädt diesen Pfad nie.

Unter der Haube läuft alles über WebGPU, sofern der Browser es bereitstellt. Die README nennt Web Worker als Option für nicht blockierende UI. Beide Punkte sind relevant, weil Inferenz im Hauptthread die Oberfläche einfriert, und genau das ist bei einem Modell mit mehreren hundert Millionen Parametern der Regelfall, nicht die Ausnahme.

Installation und die ersten Aufrufe

Die Installation ist ein einzelner Befehl: npm install @browserai/browserai oder yarn add @browserai/browserai. Danach folgt das Muster, das die README durchgängig verwendet. Zuerst wird eine Instanz erzeugt, dann ein Modell geladen, dann generiert.

const browserAI = new BrowserAI(); await browserAI.loadModel('llama-3.2-1b-instruct', { quantization: 'q4f16_1', onProgress: (progress) => console.log('Loading:', progress.progress + '%') }); const response = await browserAI.generateText('Hello, how are you?');

Der onProgress-Callback ist hier nicht Kosmetik. Der erste Aufruf lädt Gewichte aus dem Netz, und ohne Fortschrittsanzeige hat man eine Oberfläche, die minutenlang nichts tut. Die README verspricht Offline-Fähigkeit nach diesem ersten Download, was bedeutet, dass die Gewichte im Browser-Cache landen und der zweite Start ohne Netz funktioniert.

generateText nimmt entweder einen String oder ein Array aus role/content-Objekten. Die Optionen heißen temperature, max_tokens und system_prompt. Für strukturierte Ausgaben gibt es json_schema zusammen mit response_format: { type: 'json_object' }. Das ist der praktisch nützlichste Teil der API, weil er das Nachparsen von Freitext ersetzt. Für Sprache gibt es startRecording und stopRecording, die ein AudioBlob liefern, das an transcribeAudio mit return_timestamps und language geht. Für TTS wird textToSpeech mit voice und speed aufgerufen, das Ergebnis ist ein AudioBuffer für die Web Audio API. Flare-Nutzer können zusätzlich loadAdapter mit einer URL auf eine .safetensors-Datei aufrufen.

WebGPU ist die stille Voraussetzung

Die README nennt WebGPU als Beschleuniger und spricht von "Near-native performance". Das ist eine Einschätzung, kein Messwert, und das Repository liefert keine Zahlen, die man dagegen halten könnte. Wer die Bibliothek evaluiert, muss diesen Teil selbst messen. Die relevante Frage ist ohnehin nicht die Spitzenleistung, sondern die Streuung: WebGPU ist auf Desktop-Chrome und -Edge breit verfügbar, auf Safari und in mobilen Browsern deutlich eingeschränkter, und die tatsächliche Geschwindigkeit hängt vom GPU-Treiber des Endgeräts ab.

Für eine Anwendung mit heterogener Nutzerschaft ist das ein Problem. Ein Modell, das auf einem Entwickler-Laptop flüssig antwortet, kann auf einem älteren Notebook unbenutzbar langsam sein. BrowserAI bietet laut README keine dokumentierte Laufzeit-Erkennung, die ein kleineres Modell nachlädt, wenn die Hardware nicht mithält. Der Rückfall auf Flare mit GGUF-Quantisierung wie Q4_K_M ist ein manueller Schritt, den die Anwendung selbst entscheiden muss. Wer Latenz vertraglich zusichert, sollte diesen Punkt vor der Architekturentscheidung klären.

Die Modellliste ist der eigentliche Engpass

Die Liste der MLC-Modelle umfasst rund zwanzig Einträge, darunter Qwen3 in vier Größen, Phi-3.5-mini, Gemma-2B und zwei DeepSeek-R1-Distill-Varianten mit 7B und 8B. Dazu kommen vier Embedding-Modelle aus der Snowflake-Arctic-Reihe, was auf Retrieval-Nutzung hindeutet. Für Sprache stehen drei Whisper-Größen bereit, für TTS Kokoro, für Audio-Trennung HTDemucs.

Das ist eine kuratierte Auswahl, keine offene Modellplattform. Die README sagt es selbst: "More models will be added soon. Request a model by creating an issue." Wer ein Modell braucht, das nicht auf der Liste steht, ist auf diesen Prozess angewiesen. Die Flare-Engine mildert das teilweise, weil sie GGUF-Dateien über WASM lädt und damit theoretisch ein breiteres Feld öffnet. Die dokumentierten Flare-Modelle sind aber auf SmolLM2, Qwen2.5-0.5B und Llama-3.2-1B beschränkt, also auf den kleinsten Bereich. Die Lücke zwischen "GGUF ist ein offenes Format" und "diese vier Modelle sind getestet" ist genau die Stelle, an der Adoptionsrisiko entsteht.

Ein zweiter Engpass ist das Kontextfenster. Die README nennt keine Kontextlängen pro Modell. Bei 1B- und 3B-Modellen mit aggressiver Quantisierung sind lange Gesprächsverläufe und große Dokumente ohnehin unrealistisch. Wer RAG über umfangreiche Textkorpora plant, sollte das nicht als gegeben annehmen; die Roadmap führt "Simple RAG implementation" noch als Phase-1-Punkt.

Wann BrowserAI das falsche Werkzeug ist

Es gibt Fälle, in denen der Ansatz strukturell nicht passt. Der erste ist Qualität. Ein 1B-Modell mit q4f16_1-Quantisierung ist kein Ersatz für ein Modell mit zweistelligen Milliarden Parametern, und die Quantisierung kostet zusätzlich Genauigkeit. Für Klassifikation, kurze Zusammenfassungen oder Formularausfüllung reicht das oft. Für mehrstufiges Schlussfolgern über lange Dokumente nicht.

Der zweite Fall ist Konsistenz. Eine serverseitige Bereitstellung liefert allen Nutzern dieselbe Latenz, weil die Hardware bekannt ist. BrowserAI liefert jedem Nutzer die Latenz seines eigenen Geräts. Bei einem Modell mit mehreren hundert Megabyte Downloadgröße kommt der erste Eindruck hinzu: Der Nutzer wartet, bevor er irgendetwas sieht.

Der dritte Fall ist Nebenläufigkeit. Im Browser gibt es keinen Batch-Betrieb über mehrere Anfragen. Wer tausende Dokumente verarbeiten will, braucht einen Server, und dann ist der Vorteil der lokalen Verarbeitung ohnehin dahin. BrowserAI ist ein Werkzeug für interaktive Anwendungen mit einem Nutzer pro Tab, nicht für Offline-Pipelines.

Der Unterschied zu Transformers.js

Der naheliegende Vergleich ist Transformers.js von Hugging Face. Beide führen Modelle im Browser aus, beide stützen sich auf WebGPU, beide sind in TypeScript geschrieben und unter permissiven Lizenzen veröffentlicht. Der Unterschied liegt in der Breite gegen die Kuratierung.

Transformers.js zielt auf das Hugging-Face-Ökosystem: Der Nutzer wählt einen Modellbezeichner, konvertiert bei Bedarf selbst nach ONNX, und die Bibliothek deckt Text, Vision, Audio und Multimodalität ab. BrowserAI geht den umgekehrten Weg. Es liefert eine feste Liste vorkonfigurierter Modelle, hinter denen unterschiedliche Laufzeiten stehen: MLC für die kompilierten LLMs, Transformers für Whisper und Kokoro, Flare für GGUF über WASM, Demucs für die Stems. Die README nennt das "Pre-configured popular models ready to use".

Für den Anwendungsfall bedeutet das: Mit BrowserAI kommt man schneller zu einem laufenden Chat, weil die Modell- und Engine-Zuordnung schon getroffen wurde. Mit Transformers.js hat man mehr Auswahl, trägt aber die Konvertierung und die Kompatibilitätsprüfung selbst. Wer ohnehin nur ein Standardmodell braucht, fährt mit der kuratierten Variante kürzer. Wer ein bestimmtes Modell aus einer bestimmten Familie braucht, stößt bei BrowserAI früher an die Grenze.

Wartung, Versionen und Lizenz

Die Veröffentlichungshistorie zeigt ein Muster, das man kennen sollte. Zwischen v2.0.4 im Mai 2025 und v2.2.0 im April 2026 liegt fast ein Jahr ohne Release, unterbrochen nur von v2.0.2 im April 2025. Der letzte Push ins Repository datiert auf Juli 2026, also nach dem letzten Release. Das spricht für laufende Arbeit, aber gegen einen festen Release-Takt. Wer die Bibliothek produktiv einsetzt, sollte einen konkreten Tag oder Commit pinnen statt auf den main-Branch zu zeigen, und vor einem Upgrade die Modellliste erneut prüfen, weil ein Engine-Wechsel die Ausgabequalität verändern kann, ohne dass sich die API ändert.

Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, solange der Copyright-Hinweis und der Lizenztext erhalten bleiben. Wichtig ist die Abgrenzung: Die MIT-Lizenz des Repositorys gilt für den Code, nicht automatisch für die Modellgewichte, die zur Laufzeit geladen werden. Llama-Modelle unterliegen der Llama-Community-Lizenz, Gemma-Modelle haben eigene Nutzungsbedingungen. Wer BrowserAI ausliefert, muss die Bedingungen jedes tatsächlich verwendeten Modells separat prüfen. Das ist keine Rechtsberatung, aber der Punkt wird beim schnellen Blick auf die MIT-Angabe im Repository leicht übersehen.

Kosten entstehen auf zwei Wegen: beim Download der Gewichte und beim Rechenaufwand auf dem Endgerät. Der zweite Posten taucht in keiner Rechnung auf, ist aber real, weil er als Akkuverbrauch und Lüftergeräusch beim Nutzer landet.

Redaktionelles Fazit

BrowserAI passt zu Webentwicklern, die eine Chat-, Transkriptions- oder TTS-Funktion ohne eigenen GPU-Server ausliefern wollen, und zu Teams, deren Datenschutzvorgaben keine Prompts an eine API erlauben. Wer Modelle jenseits der dokumentierten Liste braucht, große Kontextfenster fährt oder reproduzierbare Latenz zusagen muss, sollte zuerst die Modellliste und die Engine-Zuordnung prüfen. Vor dem Adoptionsentscheid ist der Test auf der Zielhardware mit dem tatsächlich benötigten Modell die einzige belastbare Grundlage, denn die README nennt keine Latenz- oder Speicherwerte.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. sauravpanda/BrowserAI on GitHub