Ein LLM komplett im Browser ausführen: eine Live-WebGPU-Demo

Zwei Jahre lang war die Geschichte großer Sprachmodelle eine Geschichte über Rechenzentren — Racks voller GPUs, API-Keys und jede Eingabe, die durchs Internet auf den Server eines anderen reist. Dieser Artikel erzählt eine andere Geschichte und beweist sie auf der Stelle: ein echtes Sprachmodell, das in diesen Browser-Tab lädt und vollständig auf deinem eigenen Rechner läuft. Kein Server. Kein API-Key. Nichts, was du eingibst, verlässt dein Gerät. Scroll zum nächsten Abschnitt und probier es aus.

1. Ein ganzes KI-Modell — in diesem Tab

Die Idee klingt zunächst unwahrscheinlich. Sprachmodelle sollen riesige, teure Dinge sein, die in der Cloud leben. Aber ein Modell muss nicht riesig sein, um nützlich zu sein, und dein Laptop oder Smartphone enthält bereits einen bemerkenswert fähigen Parallelprozessor: seine GPU.

Was sich 2026 geändert hat: Zwei Bausteine passten endlich zusammen. Browser bekamen WebGPU, einen standardisierten Weg, schwere Berechnungen auf dieser GPU auszuführen. Und die Open-Source-Community brachte wirklich kleine, instruktionsoptimierte Modelle hervor — in der Größenordnung hunderter Millionen Parameter — die kohärent genug sind, um interessant zu sein. Kombiniere das mit einem Compiler, der ein Modell in GPU-Code verwandelt, und der Browser wird zur Inferenz-Engine.

Die Folgen sind nicht subtil. Inferenz, die lokal läuft, ist per Konstruktion privat, funktioniert offline, antwortet ohne Netzwerklatenz und kostet nichts pro Anfrage. Genau das sind die Eigenschaften, die für sensible Dokumente, regulierte Branchen und alles zählen, das nicht von einer Drittanbieter-API abhängen sollte. Die Demo unten ist bewusst klein — aber die Architektur, die sie zeigt, skaliert bis hinauf zu On-Device-Assistenten.

2. Selbst testen: das Local-AI-Playground

Wähle eines der kleinsten brauchbaren Modelle, lade es in diesen Tab und chatte damit. Der erste Ladevorgang lädt das Modell einmal herunter (du siehst den Fortschritt); danach ist es auf deinem Gerät zwischengespeichert und startet sofort. Alles, was du eingibst, wird lokal verarbeitet — du kannst das gleich beweisen, indem du dein Netzwerk-Tab beobachtest oder den Stecker ziehst.

Eine Anmerkung zur Erwartung: Das sind winzige Modelle — von 135 Millionen bis 1,5 Milliarden Parametern, ein Bruchteil der Größe eines Spitzenmodells. Das kleinste (SmolLM2-135M) ist eine englisch-zentrierte Kuriosität, die Fehler macht, den Faden verliert und gelegentlich etwas charmant Falsches sagt; die mehrsprachigen Qwen-Modelle sind spürbar kohärenter. Genau dieser Kontrast ist der Punkt. Genau das ist der Punkt. Du siehst die Untergrenze dessen, was bequem in einem Browser läuft, auf Hardware, die du bereits besitzt, kostenlos. Der Rest des Artikels erklärt, wie es funktioniert und wo diese Untergrenze wirklich nützlich ist.

3. Wie es funktioniert: WebGPU macht deine GPU zur Inferenz-Engine

Ein Sprachmodell ist mechanisch betrachtet eine lange Folge von Matrixmultiplikationen. GPUs existieren, um genau das zu tun — tausende Multiplikationen und Additionen parallel. Das historische Problem war, dass Webseiten keinen Weg hatten, die GPU für allgemeine Mathematik zu erreichen; WebGL konnte Dreiecke zeichnen, war aber nie für Compute gedacht.

WebGPU ist der moderne Nachfolger. Es macht die GPU über Compute-Shader zugänglich — kleine Programme, die massiv parallel laufen — und gibt einer Webseite präzise, explizite Kontrolle über Buffer und Pipelines. Es ist der browser-native Verwandte nativer APIs wie Vulkan, Metal und Direct3D 12.

Die Demo oben wird von WebLLM angetrieben, das auf dem MLC-/Apache-TVM-Compiler-Stack aufsetzt. Die Operationen des Modells werden vorab in WebGPU-Shader-Code kompiliert — beim Laden eines Modells schickt der Browser also diese Shader an deine GPU und speist die quantisierten Gewichte durch sie hindurch. Es gibt kein Python, kein CUDA und entscheidend keinen Server im Spiel — die JavaScript-Laufzeit orchestriert nur; die Arithmetik macht die GPU.

Ein praktisches Detail ist für das Deployment wichtig: Weil WebGPU seine Arbeit eigenständig auf der GPU erledigt, braucht dieser Ansatz keine Cross-Origin-Isolation-Header (COOP/COEP), die mehrthreadige WebAssembly-Engines benötigen. Das heißt, er läuft auf einer gewöhnlichen statischen Website ganz ohne spezielle Server-Konfiguration.

4. Winzige Modelle, quantisiert: SmolLM2 und Qwen2.5 in 4-Bit

Die Modelle im Playground sind offene Releases, ausgewählt, weil sie klein genug sind, um in Sekunden bis Minuten zu laden, und trotzdem Anweisungen folgen:

• SmolLM2-135M (Hugging Face) — das winzigste Modell, erstaunlich klein, aber englisch-zentriert und ausgesprochen eigenwillig (gut für „Wie klein geht es?”, schwach im Deutschen).
• Qwen2.5-0.5B und 1.5B (Alibaba) — stark mehrsprachig, beherrschen Deutsch und Englisch gut. Das 0,5B ist der verlässliche Sweet Spot (die Voreinstellung); das 1,5B ist die „klügste” Option gegen etwas mehr Download.

Selbst „1,5B” wäre bei voller Präzision zu groß zum bequemen Ausliefern. Der Trick ist Quantisierung. Die Qwen-Varianten hier sind q4f16_1: Die Gewichte werden mit 4 Bit je Wert gespeichert (statt 16- oder 32-Bit-Gleitkomma), während die Berechnung in 16 Bit läuft. Vier Bit pro Gewicht reduzieren den Download grob um das Vierfache gegenüber fp16 — so passt ein Modell mit 1,5 Milliarden Parametern in ~1,1 GB statt in mehrere. SmolLM2-135M ist klein genug, dass es nur in 16 Bit ausgeliefert wird (~270 MB; einen 4-Bit-Build gibt es dafür nicht). Quantisierung hat einen Qualitätspreis, aber für diese Größen ist das ein sinnvoller Kompromiss. Zur tieferen Mechanik siehe QLoRA und Quantisierung und Small Language Models und Edge AI.

5. Einmal laden, für immer offline nutzen

Beim ersten Laden eines Modells holt WebLLM dessen Gewichte von einem öffentlichen CDN und speichert sie in der Cache-API / IndexedDB des Browsers. Dieser erste Download ist der einzige Moment, in dem das Netzwerk berührt wird. Bei jedem weiteren Besuch lädt das Modell direkt aus dem lokalen Speicher — der Fortschrittsbalken erscheint kaum noch, und das Abzeichen „auf diesem Gerät zwischengespeichert” leuchtet auf.

Das macht den Datenschutz-Anspruch konkret statt rhetorisch. Sind die Gewichte einmal zwischengespeichert, kannst du dein WLAN ausschalten und das Modell antwortet weiter. Probier es: Lade ein Modell, trenne die Verbindung und chatte weiter. Nichts bricht ab, weil es nie etwas zu senden gab.

(Browser können zwischengespeicherten Speicher unter starkem Druck verwerfen, dann werden die Gewichte einmal neu geladen — die ehrliche Formulierung lautet also „sofort und offline, sobald zwischengespeichert”, nicht „für immer, egal was passiert”.)

6. Den Tokens-pro-Sekunde-Zähler lesen

Nach jeder Antwort zeigt das Playground eine kleine Statistikzeile, gemessen auf deiner Hardware. Zwei Zahlen sind wichtig:

• Prefill — wie schnell das Modell deine Eingabe liest und verarbeitet.
• Decode — wie schnell es die Antwort schreibt, Token für Token.

Ein Token ist ein Textstück, meist ein kurzes Wort oder Wortteil; „Tokens pro Sekunde” ist schlicht die Erzeugungsrate. Auf einer aktuellen dedizierten GPU kann ein 0,5B-Modell Dutzende bis über hundert Tokens pro Sekunde decodieren; auf einer integrierten Laptop-GPU oder einem Smartphone ist es langsamer. Der Sinn des Zählers ist Ehrlichkeit: Du siehst die echte Geschwindigkeit deines Geräts, nicht einen Benchmark aus einem Rechenzentrum. Mehr zu Tokens und Kontext: Tokenisierung und Kontextfenster; zum größeren Bild der Inferenzgeschwindigkeit: LLM-Inferenz-Performance.

7. Der Datenschutz-Beweis: null Netzwerk während der Inferenz

Die meisten „Private-KI”-Versprechen bitten dich, einer Datenschutzerklärung zu vertrauen. Dieses hier kannst du in unter einer Minute überprüfen:

• Beobachte das Netzwerk. Öffne die Entwicklertools deines Browsers, geh zum Tab „Netzwerk” und sende eine Eingabe. Nach dem einmaligen Download der Gewichte feuern keine Anfragen, während das Modell generiert. Der Text entsteht aus reiner lokaler Berechnung.
• Zieh den Stecker. Trenne dich vollständig vom Internet (sobald das Modell zwischengespeichert ist) und chatte weiter. Würde etwas an einen Server gesendet, würde es aufhören zu funktionieren. Tut es nicht.

Das ist eine kategorisch andere Garantie als „wir versprechen, deine Eingaben nicht zu protokollieren”. Es gibt keinen Endpunkt, keine Anfrage, keine Kopie deines Textes irgendwo außer im Tab vor dir. Für regulierte Daten — Gesundheit, Recht, HR, interne Dokumente — ist dieser Unterschied das Entscheidende. Siehe Sichere KI-Integration, wie sich das in eine breitere Datenschutzstrategie einfügt.

8. Grenzen — und Ehrlichkeit

Browser-Modelle sind keine Zauberei, und etwas anderes vorzugeben würde den Punkt untergraben. Die echten Grenzen:

• Fähigkeit. Ein derart kleines Modell (135M–1,5B) hat flaches Weltwissen und schwaches mehrstufiges Reasoning. Es ist gut in kurzen Umformulierungen, einfachen Fragen, Klassifizierung und Tonänderungen — nicht in Recherche, Mathematik oder langen Logikketten.
• Gewicht des ersten Ladens. Der anfängliche Download (≈270 MB bis 1,1 GB) ist auf einer langsamen Verbindung echte Reibung. Caching behebt den zweiten Besuch, nicht den ersten.
• Hardware-Varianz. Die WebGPU-Abdeckung ist hoch, aber nicht universell, und ein Gerät mit wenig Speicher kann beim größeren Modell an die GPU-Speichergrenze stoßen — deshalb schlägt die Demo dann das kleinste Modell vor.
• Kontextlänge. Winzige Modelle behalten nur ein kurzes Gespräch im Blick, bevor die Qualität nachlässt.

Nichts davon ist ein Fehler der Demo; es ist die ehrliche Form der Technologie. Die Untergrenze zu kennen, ist genau das, was erlaubt, dafür zu entwerfen.

9. Wann On-Device-Inferenz die richtige Architektur ist

Browser-native Inferenz ist kein Ersatz für Spitzenmodelle — sie ist ein anderes Werkzeug für eine andere Aufgabe. Sie ist die richtige Wahl, wenn:

• Datenschutz nicht verhandelbar ist — sensibler Text, der nie einen Drittanbieter-Server erreichen darf.
• Die Aufgabe eng ist — Autovervollständigung, Schwärzung, Klassifizierung, Tonänderung, strukturierte Extraktion, einfache On-Page-Assistenten.
• Offline oder niedrige Latenz zählt — Außendienst-Tools, Kioske, In-App-Helfer, die sofort reagieren müssen.
• Die Kosten auf null skalieren sollen — Millionen kleiner Interaktionen, bei denen Preise pro API-Aufruf absurd wären.

In der Produktion ist das stärkste Muster meist hybrid: Ein kleines On-Device-Modell übernimmt die häufigen, privaten, latenzkritischen Fälle, und ein größeres Cloud-Modell wird nur für die seltenen schweren gerufen — mit einer Routing-Schicht, die zwischen beiden entscheidet. Die Browser-Demo, die du gerade benutzt hast, ist die kleinstmögliche Version dieser Idee, ausgeführt auf Hardware, die du bereits besitzt. Wie sich On-Device-Inferenz in eine vollständige, datensouveräne Architektur einfügt, zeigt der souveräne AI-Stack 2026.

Die Erkenntnis ist einfach. KI muss nicht im Rechenzentrum eines anderen leben. 2026 kann ein bedeutender Teil davon in einem Browser-Tab leben — privat, offline-fähig und am Nutzungspunkt kostenlos. Das verändert, welche Produkte möglich sind und wohin sensible Daten gehen müssen. Wenn das die Art System ist, die du bauen willst, ist es genau die Art, die wir bauen.