WebLLM 0.2.83: LLM-Inferenz produktionsreif im Browser

WebLLM: LLM-Inferenz direkt im Browser mit WebGPU und OpenAI-API

WebLLM ist eine Open-Source-JavaScript-Engine, die Inferenz großer Sprachmodelle vollständig im Webbrowser ausführt. Statt Anfragen an einen Server zu senden, lädt die Engine Modellgewichte lokal und beschleunigt die Berechnung über die WebGPU-Schnittstelle. Ein Server-Backend entfällt; sämtliche Prompts und Antworten bleiben auf dem Gerät des Nutzers. Entwickelt wird WebLLM vom MLC-AI-Team als Begleitprojekt zu MLC LLM und basiert auf dem ML-Compiler-Framework Apache TVM.

Die API ist kompatibel zur OpenAI-Schnittstelle: Streaming, JSON-Modus und Funktionsaufrufe (letztere als Work-in-Progress) werden unterstützt. Damit lässt sich WebLLM als Drop-in-Ersatz für Cloud-Aufrufe in bestehende Anwendungen integrieren – eine Zeile zur Initialisierung der Engine genügt nach Angaben der Dokumentation.

Die im April 2026 veröffentlichte Version 0.2.83 bringt zwei zentrale Neuerungen: Unterstützung für Web Worker und Service Worker, sodass die Generierung den Haupt-Thread nicht mehr blockiert, sowie vorkompilierte MLC-Gewichte für Llama 3, Phi 3, Gemma, Mistral und die vollständige Qwen3-Familie. Strukturierte JSON-Ausgabe und Token-Streaming sind im selben Paket enthalten. Damit positioniert sich WebLLM als ernsthafte Alternative zu serverbasierten Inferenzdiensten – zumindest für kleinere, quantisierte Modelle.

Technische Basis: WebGPU, WASM und Quantisierung

WebLLM nutzt zwei Ausführungswege: WebGPU für GPU-beschleunigte Berechnung und WebAssembly (WASM) für CPU-basierte Inferenz. Die WebGPU-Kernel werden vom MLC-AI-Compiler-Framework auf Apache-TV M-Basis vorkompiliert; bei kleinen Modellgrößen ist der Durchsatz damit kompiliert und nicht emuliert. WASM dient als universeller Fallback, läuft auf praktisch allen Browsern und übernimmt auch Teile der Modellbibliothek, etwa die strukturierte JSON-Generierung.

Ein zentraler Hebel ist die 4-Bit-Quantisierung nach dem Schema q4f16_1. Sie reduziert ein 4-Milliarden-Parameter-Modell von rund 8 GB (FP16) auf etwa 2,2 GB – eine Speicherersparnis von 75 Prozent. Die Gewichte werden als 4-Bit-Integer gespeichert, die Aktivierungen bleiben in FP16. Dadurch passt ein Modell wie Qwen3-4B in den GPU-Speicher eines handelsüblichen Rechners und lädt nach Herstellerangaben in unter 30 Sekunden. Auf moderner Hardware in einem Chrome-Tab werden 60 bis über 90 Tokens pro Sekunde generiert.

Die Leistungsangaben des WebLLM-Teams aus einem arXiv-Paper nennen bis zu 80 Prozent der nativen Leistung auf demselben Gerät. Unabhängige Messungen zeichnen ein anderes Bild: Der Browser-Durchsatz liegt demnach um den Faktor 4 bis 8 unter nativer Inferenz mit llama.cpp. Die Diskrepanz erklärt sich teilweise durch den WebGPU-Dispatch-Overhead, der je nach Plattform 24 bis 71 Mikrosekunden pro Aufruf beträgt und bei vielen kleinen Operationen in der Inferenz stark ins Gewicht fällt.

Widersprüche: Leistungsversprechen und Browser-Unterstützung

Zwei Widersprüche prägen die öffentliche Wahrnehmung von WebLLM. Erstens die Leistung: Das WebLLM-Team gibt in seinem Fachpapier an, bis zu 80 Prozent der nativen Performance zu erreichen. Die unabhängige 9bench-Messung hingegen dokumentiert auf identischer Hardware einen 4- bis 8-fachen Durchsatzverlust. Konkret: Auf einer RTX 4090 liefert der Browser-Test 15 bis 25 Tokens pro Sekunde, während llama.cpp 100 bis 160 Tokens pro Sekunde erreicht. Der Unterschied liegt in der Methodik: Die 80-Prozent-Angabe bezieht sich vermutlich auf die theoretische Obergrenze der kompilierten WebGPU-Kernel unter optimalen Bedingungen. 9bench misst dagegen den End-to-End-Durchsatz inklusive WASM-Overhead, WebGPU-Dispatch-Overhead und Browser-JIT-Kompilierung. Beide Zahlen sind korrekt, beschreiben aber unterschiedliche Szenarien.

Zweitens die Browser-Unterstützung: Eine Quelle aus dem WebLLM-Umfeld behauptet, WebGPU sei inzwischen standardmäßig in Chrome, Edge, Firefox und Safari verfügbar. Eine andere, im September 2026 gegen die caniuse-Tabelle verifizierte Quelle widerspricht: Firefox bleibe die Lücke. Der Widerspruch dürfte auf unterschiedlichen Erhebungszeitpunkten oder Definitionen von "verfügbar" beruhen – teilweise Implementierung versus vollständige Unterstützung. Für Entwickler bedeutet das: Die Zielgruppe ist fragmentiert, und eine zuverlässige Feature-Erkennung ist unverzichtbar.

Wer profitiert, wer verliert: Auswirkungen auf Entwickler und Anbieter

Die Verschiebung der Inferenz in den Browser verändert die Kosten- und Datenschutzrechnung grundlegend. Webentwickler profitieren am deutlichsten: Sie benötigen keine Server-Infrastruktur für LLM-Aufrufe, zahlen keine Token-basierten Cloud-Gebühren und integrieren die Engine über ein einziges ES-Modul. Datenschutzbewusste Nutzer gewinnen, weil Prompts und Modellgewichte das Gerät nicht verlassen. Auch das Open-Source-Ökosystem um MLC-AI und Apache TVM wird gestärkt, da vorkompilierte Gewichte und Kernel öffentlich auf Hugging Face liegen.

Auf der Verliererseite stehen Cloud-LLM-Anbieter, deren Abonnement- und Nutzungsmodelle durch lokale Inferenz zumindest für kleinere Modelle substituiert werden. Nutzer ohne WebGPU-Unterstützung – etwa auf älteren Browsern oder Geräten ohne geeignete GPU – bleiben außen vor, sofern kein WASM-Fallback vorgesehen ist. Der Handlungsbedarf ist klar: Browser-Hersteller müssen WebGPU vollständig und konsistent implementieren, insbesondere Firefox. Entwickler benötigen Fallback-Strategien, etwa den Wechsel auf WASM-basierte Engines wie wllama, die 5 bis 20 Tokens pro Sekunde liefern, wenn WebGPU fehlt. Ohne solche Absicherungen droht ein Ausschluss eines erheblichen Teils der Nutzerbasis.

Vom Demo zur Produktion: Der Reifegrad von WebLLM

Mit den Versionen 0.2.82 und 0.2.83 hat WebLLM nach Einschätzung der Fachwelt die Schwelle von der Machbarkeitsstudie zur produktiven Nutzung überschritten. Entscheidend ist die Kombination aus vorkompilierten MLC-Gewichten, strukturierter JSON-Ausgabe, Token-Streaming und Worker-Support. Diese Bausteine adressieren genau die Lücken, die frühere browserbasierte LLM-Ansätze für reale Anwendungen unbrauchbar machten: blockierte UI-Threads, fehlende deterministische Ausgabeformate und umständliche Modellbeschaffung.

Der Pfad von einem HuggingFace-Checkpoint zur Browser-Inferenz ist nun in drei Stufen standardisiert – Konvertierung, Quantisierung, WebGPU-Kernel-Kompilierung – und vollständig auf Apache TVM aufgebaut. Für Entwickler bedeutet das: Eine Anwendung, die bisher einen Cloud-Endpunkt aufrief, kann mit minimalem Code-Umbau auf lokale Inferenz umgestellt werden. Die langfristige Bedeutung liegt in der Entkopplung von zentralisierten Inferenzdiensten. Ob WebLLM zum Standard für datenschutzkritische oder offline-fähige KI-Anwendungen wird, hängt davon ab, wie schnell Browser-Hersteller die WebGPU-Lücken schließen und wie stark die Leistungslücke zu nativer Inferenz weiter schrumpft.