WebLLM: LLM-Inferenz im Browser über WebGPU
High-performance In-browser LLM Inference Engine
Auf einen Blick
- Was ist das?
- WebLLM führt Sprachmodelle direkt im Browser aus und stellt dafür eine OpenAI-kompatible Schnittstelle bereit. Der Ansatz passt für Anwendungen, die ohne Server auskommen müssen, stößt aber dort an Grenzen, wo Modellgröße, Downloadvolumen und WebGPU-Verfügbarkeit den Rahmen setzen.
- Für wen ist es gedacht?
- Wer eine Chat- oder Assistenzfunktion ohne Serverbetrieb und ohne Datenabfluss aus dem Browser heraus braucht, findet in WebLLM eine tragfähige Grundlage, sofern die Zielgeräte WebGPU unterstützen und der Erstdownload eines Modells von mehreren hundert Megabyte akzeptabel ist. Für Anwendungen, die auf älteren Browsern, in Safari ohne WebGPU oder auf schwachen Mobilgeräten laufen müssen, ist das Projekt die falsche Wahl.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem WebLLM löst und für wen es gedacht ist
Der übliche Weg, ein Sprachmodell in eine Webanwendung zu bringen, führt über einen Server: Die Anfrage geht an eine API, die Antwort kommt zurück. Das kostet Infrastruktur, verursacht laufende Kosten pro Token und bedeutet, dass jede Eingabe der Nutzer das Gerät verlässt. WebLLM dreht das um. Laut README läuft alles im Browser, ohne Serverunterstützung, beschleunigt über WebGPU. Die Zielgruppe sind damit Entwickler, die eine Chat-, Assistenz- oder Klassifikationsfunktion in eine Webseite einbetten wollen, ohne Inferenz-Hosting zu betreiben. Interessant ist das besonders dort, wo Daten das Gerät nicht verlassen dürfen oder wo eine Offline-Funktion nach dem ersten Laden gewünscht ist. Das Projekt ist ausdrücklich als Begleitprojekt zu MLC LLM angelegt, das LLMs über verschiedene Hardwareumgebungen hinweg deploybar macht. Wer bereits MLC-Modelle nutzt, findet hier den Browser-Pfad; wer nur schnell einen Chatbot prototypen will, kann mit den Beispielen auf JSFiddle und Codepen starten, die das README verlinkt.
WebGPU, WASM und der Weg der Token durch den Browser
Die eigentliche Rechenarbeit liegt nicht in TypeScript. WebLLM ist die JavaScript- und TypeScript-Oberfläche; die Modellbibliothek selbst stammt aus dem MLC-Stack und wird über WebAssembly eingebunden. Das README nennt das an einer konkreten Stelle: Der JSON-Modus für strukturierte Generierung ist in the WebAssembly portion of the model library implementiert, ausdrücklich mit dem Ziel optimaler Performance. Das ist ein Hinweis darauf, wo die Grenze zwischen Komfort-API und Rechenkern verläuft. Die Beschleunigung übernimmt WebGPU, die noch junge Grafik- und Compute-Schnittstelle des Browsers. Modelle werden nicht als PyTorch- oder GGUF-Dateien geladen, sondern im MLC-Format, das für die jeweilige Zielumgebung kompiliert wurde. Daraus folgt ein Datenfluss, den man beim Deployment einplanen muss: Beim ersten Aufruf lädt der Browser die Gewichte und den WASM-Code aus dem Netz, danach liegt die Inferenz lokal. Das README empfiehlt, die Berechnung in Web Worker oder Service Worker auszulagern, um die UI nicht zu blockieren und den Lebenszyklus des Modells zu verwalten. Wer das nicht tut, blockiert den Hauptthread während der Generierung.
Installation und der erste Engine-Aufruf
Die Einbindung erfolgt wahlweise über einen Paketmanager oder per CDN. Für npm lautet der Befehl npm install @mlc-ai/web-llm, für yarn entsprechend yarn add @mlc-ai/web-llm, für pnpm pnpm install @mlc-ai/web-llm. Anschließend importiert man entweder das gesamte Modul mit import * as webllm from "@mlc-ai/web-llm" oder nur den benötigten Teil mit import { CreateMLCEngine } from "@mlc-ai/web-llm". Ohne Build-Schritt geht es über jsdelivr: import * as webllm from "https://esm.run/@mlc-ai/web-llm", alternativ dynamisch per await import derselben URL. Das README verweist darauf, dass dieses Vorgehen auf Cloud-Entwicklungsplattformen wie jsfiddle.net, Codepen.io und Scribbler direkt funktioniert. Der zentrale Einstiegspunkt ist die Klasse MLCEngine. Laut README erzeugt man eine Instanz und lädt das Modell durch den Aufruf von CreateMLCEngine; der README-Ausschnitt endet an dieser Stelle mitten im Satz, ein vollständiges Codebeispiel für den Aufruf lässt sich daraus nicht rekonstruieren. Welche Modelle ohne eigene Kompilierung verfügbar sind, steht in prebuiltAppConfig.model_list in src/config.ts. Dort finden sich unter anderem Llama 3, Phi 3, Gemma-2B, Mistral-7B-v0.3 und Qwen2 in den Größen 0.5B, 1.5B und 7B.
OpenAI-Kompatibilität als Integrationsstrategie
Der auffälligste Entwurfsentscheid ist die Kompatibilität zur OpenAI-Chat-API. Das README formuliert es so, dass man dieselbe API mit jedem Open-Source-Modell lokal verwenden kann, einschließlich Streaming, JSON-Modus und Logit-Kontrolle. Für Teams bedeutet das einen konkreten Vorteil: Wer bereits gegen die OpenAI-API entwickelt hat, kann den Endpunkt austauschen, ohne die Aufruflogik neu zu schreiben. Die Einschränkung steht im selben Satz: Function-Calling ist als WIP markiert, also noch in Arbeit. Wer darauf angewiesen ist, sollte das nicht als vorhandene Funktion einplanen. Der JSON-Modus dagegen wird im README als ausgereift beschrieben, mit einem eigenen Playground auf HuggingFace, in dem man ein eigenes JSON-Schema testen kann. Bemerkenswert ist, dass die strukturierte Generierung nicht im JavaScript-Teil, sondern im WASM-Teil der Bibliothek umgesetzt ist. Das ist eine bewusste Entscheidung für Durchsatz auf Kosten der Nachvollziehbarkeit im Quellcode der Anwendung.
Modellgröße, Download und die Grenzen des Ansatzes
Die offensichtlichste Einschränkung ist die Größe. Ein Mistral-7B-Modell im MLC-Format liegt im Bereich mehrerer Gigabyte an Gewichten, die der Browser vor der ersten Antwort herunterladen muss. Das README nennt keine Zahlen zum Downloadvolumen oder zur Ladezeit, und ohne eigene Messung lässt sich hier nichts Belastbares sagen. Klar ist nur die Konsequenz: Der erste Besuch einer Seite ist langsam, und die Inferenzqualität hängt davon ab, ob der Nutzer diesen Download abwartet. Die zweite Einschränkung ist WebGPU selbst. Ohne WebGPU-Unterstützung im Browser fällt die Hardwarebeschleunigung weg, und das README nennt keine Fallback-Strategie. Wer Nutzer auf älteren Browsern oder auf Geräten mit schwacher GPU bedienen muss, sollte WebLLM nicht als einzigen Pfad einplanen. Drittens die Modellauswahl: Das README nennt eine Reihe von Familien, aber es ist ausdrücklich ein Subset der MLC-Modelle. Fehlt das gewünschte Modell, muss man es selbst kompilieren, was den MLC-Toolchain voraussetzt und den Aufwand deutlich erhöht. Und schließlich die Worker-Frage: Ohne Auslagerung in einen Web Worker blockiert die Generierung die Oberfläche, was bei längeren Antworten spürbar wird.
Wann Transformers.js die passendere Wahl ist
Die naheliegende Alternative ist Transformers.js von Hugging Face. Der Unterschied liegt nicht in der Zielsetzung, sondern im Unterbau: Transformers.js lädt Modelle im ONNX-Format und kann auf WebGPU zurückgreifen, aber auch auf WebAssembly zurückfallen, wenn WebGPU fehlt. WebLLM setzt dagegen auf den MLC-Stack mit im MLC-Format kompilierten Modellen und bindet die Rechenkerne über WebAssembly ein. Für Entwickler bedeutet das einen anderen Modellkatalog: Wer ein bestimmtes HuggingFace-Modell im ONNX-Format bereits nutzt, bleibt bei Transformers.js, weil die Konvertierung nach MLC ein eigener Schritt ist. Umgekehrt spricht für WebLLM die OpenAI-kompatible Schnittstelle, die bei Transformers.js nicht in dieser Form vorhanden ist. Wer seine Anwendung bereits gegen die Chat-Completions-API geschrieben hat, spart mit WebLLM die Anpassung. Wer dagegen maximale Browserabdeckung braucht und bereit ist, die Modellkonvertierung selbst zu übernehmen, fährt mit Transformers.js breiter.
Wartung, Versionierung und Lizenzfragen
Das Projekt wird aktiv gepflegt: Die letzte Veröffentlichung ist v0.2.85 vom 8. September 2026, davor v0.2.83 im April und v0.2.82 im März 2026. Die Versionsnummern bleiben im 0.2.x-Bereich, was auf eine noch nicht als stabil deklarierte API hindeutet. Wer WebLLM einsetzt, sollte damit rechnen, dass sich Schnittstellen zwischen Minor-Versionen ändern können, und die Version im package.json festnageln, statt einen Versionsbereich zu verwenden. Das Paket steht unter Apache-2.0. Diese Lizenz deckt den Code ab, nicht die Modellgewichte: Die im README genannten Modelle wie Llama 3, Gemma oder Qwen haben eigene Lizenzen, die teils Nutzungsbedingungen oder Einschränkungen für kommerzielle Verwendung enthalten. Wer ein Modell in einem Produkt einsetzt, muss dessen Lizenz separat prüfen; das README behandelt diesen Punkt nicht. Das ist eine Lücke, die bei einem Projekt, dessen Kernwert in der Modellverteilung liegt, auffällt.
Redaktionelles Fazit
Wer eine Chat- oder Assistenzfunktion ohne Serverbetrieb und ohne Datenabfluss aus dem Browser heraus braucht, findet in WebLLM eine tragfähige Grundlage, sofern die Zielgeräte WebGPU unterstützen und der Erstdownload eines Modells von mehreren hundert Megabyte akzeptabel ist. Für Anwendungen, die auf älteren Browsern, in Safari ohne WebGPU oder auf schwachen Mobilgeräten laufen müssen, ist das Projekt die falsche Wahl. Vor der Übernahme sollte man prüfen, ob das gewünschte Modell in prebuiltAppConfig.model_list auftaucht, ob CreateMLCEngine auf dem Zielgerät tatsächlich initialisiert, und ob die Apache-2.0-Lizenz des Pakets zu den eigenen Modellgewichten passt, denn diese bringt WebLLM nicht automatisch mit.
Community-Notizen