Browser-LLMs in PWAs – Praxistest, Speichersilos und die 400-MB-Hürde

Du baust eine Progressive Web App und willst das Versprechen echter Offline-KI einlösen: kein Server, keine API-Kosten, vollständiger Datenschutz auf dem Smartphone. Doch beim ersten echten Feldtest folgt die Ernüchterung: 480 Megabyte Download allein für das kleinste noch halbwegs verständliche Modell, spürbare Hitzeentwicklung und Antworten, die selbst bei einfachen Fachfragen versagen. Warum klafft zwischen der Demo-Euphorie und dem Produktiveinsatz im Browser eine so fundamentale Lücke?

Lokale Sprachmodelle in PWAs scheitern in der Praxis an drei physikalischen und architektonischen Barrieren: Der Same-Origin-Isolation des Webs, die jedes Modell pro Domain dupliziert, dem Mindestspeicherbedarf multilingualer Modelle ab 400 Megabyte und fehlenden nativen Browser-APIs auf Mobilgeräten. Während Embeddings für semantische Suche mit 25 Megabyte offline exzellent funktionieren, machen hoher Speicherverbrauch, Cache-Eviction und schwache Kontextverarbeitung lokale generative Chatbots in mobilen Web-Apps derzeit unwirtschaftlich.

Warum scheitert die Vision an der Speicherarchitektur des Webs?

Das fundamentale Sicherheitsmodell des Webs basiert auf der Same-Origin-Policy (Ein Sicherheitsmechanismus in Browsern, der verhindert, dass Skripte einer Domain auf Daten, Speicher oder Cookies einer fremden Domain zugreifen.). Jede Web-App lebt in einer hermetisch abgeriegelten Sandbox. Was für Passwörter und Nutzerdaten unverzichtbar ist, erweist sich bei riesigen Binärdateien als architektonische Sackgasse:

Wenn du drei verschiedene Progressive Web Apps (PWAs) (Webanwendungen, die moderne Browser-APIs nutzen, um sich wie native Apps zu installieren und über Service Worker offline lauffähig zu sein.) installierst, die alle ein lokales Sprachmodell für Chat oder Notizen anbieten, darf keine dieser Apps auf den Modell-Cache der anderen zugreifen.

Origin-Isolation: Die Multi-App-Speicherfalle

Im nativen Betriebssystem teilen sich Anwendungen gemeinsame Systembibliotheken oder greifen auf ein zentrales KI-Modell des Betriebssystems zu (wie Apple Intelligence oder Windows Copilot Runtime). Im Webbrowser existiert diese gemeinsame Ebene für Drittanbieter nicht:

1. Origin A (notizen-app.de) lädt ein quantisiertes Qwen-Modell (483 MB) in ihre eigene Cache Storage API (Eine browserinterne Schnittstelle zur persistenten Speicherung von Netzwerk-Requests und Antworten, meist gesteuert durch Service Worker.).
2. Origin B (lukiluki.me) lädt exakt dieselben 483 MB Gewichtsdateien in ihr eigenes isoliertes Cache-Verzeichnis herunter.
3. Origin C (task-tracker.com) lädt das Modell ein drittes Mal herunter.

Bei drei installierten Web-Apps belegen identische Gewichtsmatrizen rund 1,45 Gigabyte Flash-Speicher auf dem Endgerät. Auf Smartphones, auf denen Nutzer regelmäßig um Speicherplatz für Fotos und Betriebssystem-Updates kämpfen, führt dieser unkoordinierte Speicherhunger zu sofortigem Unmut und App-Deinstallationen.

Cache-Eviction auf Mobilgeräten

Verschärft wird das Speicherproblem durch die automatischen Bereinigungsmechanismen moderner Mobil-Browser:

• WebKit (iOS Safari): Safari unterwirft clientseitigen Speicher strikten Löschregeln. Wird eine Web-App nicht zum Home-Bildschirm hinzugefügt oder längere Zeit nicht aktiv genutzt, greift die ITP-Bereinigung und löscht IndexedDB- sowie Cache-Storage-Bestände. Der Nutzer öffnet die App im Flugmodus und steht vor einem leeren Modellverzeichnis.
• Chromium (Android): Bei niedrigem Gesamtspeicherplatz des Geräts wirft das System flüchtige Browser-Caches nach dem LRU-Prinzip (Least Recently Used) unangekündigt aus dem Speicher. Ein Modell-Download von 500 MB ist somit keineswegs dauerhaft garantiert.

Zwar existiert die Methode navigator.storage.persist(), um dauerhafte Speicherung zu erbitten, doch Browser gewähren diese Berechtigung nur restriktiv nach internen Heuristiken und Nutzerinteraktionswerten.

Der Modell-Flaschenhals: Warum 400 Megabyte die Schmerzgrenze für Deutsch sind

Warum binden wir nicht einfach ein winziges 50-Megabyte-Modell ein? Die Antwort liegt in den Gesetzen der Modellarchitektur und Tokenisierung. Für generative Sprachaufgaben im Browser kommen derzeit praktisch nur drei Modellfamilien infrage:

Die drei verbleibenden Modellfamilien im Browser

Der Qualitätsabsturz unterhalb von einer Milliarde Parametern

Modelle mit weniger als 500 Millionen Parametern (wie SmolLM2-135M oder 360M) besitzen schlicht nicht genügend Gewichtsdimensionen, um komplexe Weltmodelle, Grammatikregeln mehrerer Sprachen und strikte Instruktionsbefolgung abzubilden:

1. Sprachverzerrung: Der überwältigende Großteil der Trainingsdaten kleiner Modelle ist englischsprachig. Bei deutschen Prompts schrumpft die Token-Dichte dramatisch. Das Modell wechselt mitten im Satz ins Englische oder verliert die Substantiv-Verb-Kongruenz.
2. Kollaps bei System-Prompts: Übergibst du dem Modell einen RAG-Kontext (Retrieval-Augmented Generation: Dem Modell werden relevante gefundene Textabschnitte im Prompt mitgegeben, damit es daraus die Antwort ableitet.) mit redaktionellen Fachartikeln, ignoriert ein 360M-Modell regelmäßig die Vorgabe, nur aus den Quellen zu zitieren, und erfindet plausible Scheinbegriffe.
3. Puffergrenzen in WebGPU: WebGPU erzwingt Limits über maxBufferSize und maxStorageBufferBindingSize. Auf integrierten Smartphone-GPUs scheitert die Allokation von Arbeitsmatrizen für größere Kontextfenster häufig mit Fehlermeldungen wie requested maxBufferSize exceeds limit.

Wer deutschen Nutzern eine solide Sprachqualität bieten will, muss mindestens zur 1-Milliarden-Klasse greifen – und damit einen initialen Download von 700 Megabyte rechtfertigen.

Wo steht die Chrome Prompt API und warum fehlt der Standard?

Wäre es nicht naheliegend, wenn der Browser selbst ein KI-Modell bereitstellt, auf das alle Webseiten per Standard-JavaScript zugreifen können? Genau diesen Ansatz verfolgt Google mit der Prompt API (Eine experimentelle W3C-Community-Spezifikation (LanguageModel), über die Webseiten auf ein browserinternes KI-Modell zugreifen können.) und Gemini Nano.

Die Realität im Jahr 2026 zeigt jedoch, warum Web-Entwickler darauf keine Produktionsarchitektur für PWAs aufbauen können:

Das 22-Gigabyte-Hardware-Gate von Google

Die Prompt API (window.LanguageModel) wurde in Chrome 148 für Desktop-Systeme ausgeliefert. Doch die Systemvoraussetzungen schließen den eigentlichen mobilen PWA-Zielmarkt komplett aus:

• Keine Unterstützung für Android und iOS: Weder Chrome auf Android noch Chrome auf iOS unterstützen die Foundation-Model-APIs.
• 22 Gigabyte Speicherplatz-Gate: Chrome lädt Gemini Nano nur herunter, wenn auf dem Profil-Laufwerk mindestens 22 GB freier Speicherplatz verfügbar sind. Fällt der freie Speicherplatz später unter 10 GB, wird das Modell vom Browser automatisch gelöscht.
• Hardware-Anforderungen: Zwingend mehr als 4 GB VRAM für den GPU-Pfad oder mindestens 16 GB RAM und 4 CPU-Kerne für den CPU-Fallback.
• Kein Zugriff in Workern: Die APIs sind weder in Dedicated Web Workern noch in Service Workern verfügbar.

Warum Apple und Mozilla den Standard blockieren

Die Prompt API ist kein offizieller W3C-Standard, sondern ein Draft Community Group Report der Web Machine Learning Community Group. Die beiden anderen großen Browser-Hersteller lehnen die Schnittstelle ab:

• Mozilla (Firefox): Hat eine offizielle Haltung „Negative Standards Position“ eingenommen. Die Begründung: Ein proprietäres, modellspezifisches API zerstört die Interoperabilität des Webs. Eine Webseite, deren Prompts für Gemini Nano optimiert wurden, reagiert völlig unvorhersehbar, wenn ein anderer Browser ein alternatives Modell wie Phi-4-mini verwendet.
• Apple (WebKit/Safari): Hat eine offizielle Haltung „Oppose Position“ bezogen. Apple sieht erhebliche Datenschutz- und Portabilitätsprobleme und verweist darauf, dass Webseiten browserspezifische Weichen einbauen müssten.

Ohne Konsens zwischen Google, Apple und Mozilla gibt es im Web keine universelle Plattform-Schnittstelle. Wer lokale Chatbots heute anbietet, muss die 500 Megabyte schweren Gewichte selbst als Datei ausliefern.

Praxistest in Looki Looki Me: Messwerte und Code

Im Rahmen der PWA-Migration des Digital Gardens haben wir den praktischen Vergleichstest gewagt: Was passiert, wenn eine auf Geschwindigkeit und Schlankheit optimierte Dokumentations-App ein echtes lokales Sprachmodell integriert?

Messdaten: App-Code versus Modellgewicht

Die Zahlen unseres Produktions-Builds zeigen die Diskrepanz schonungslos:

• Gesamtes Offline-Manifest von lukiluki.me: 73,9 MB (enthält 49 vorgerenderte Seiten, 228 statische Assets, Schriften und die vollständige kompilierte ONNX-WebAssembly-Laufzeit).
• Zuschalten des kleinsten multilingualen Chatmodells (Qwen3-0.6B-q4f16_1): +483 MB zusätzlicher Download.
• Verhältnis: Das KI-Modell macht 86,7 % des gesamten Datenvolumens der installierten Web-App aus.
• Kaltstart bis zum ersten Token: Auf einem modernen Smartphone dauert das Dekomprimieren der Gewichte und das Initialisieren der WebGPU-Pipeline zwischen 9 und 16 Sekunden. Währenddessen blockiert die GPU spürbar das UI-Rendering anderer Tabs.

Robuster Download- und Quota-Check in TypeScript

Wer trotz aller Nachteile ein lokales Modell für geschlossene Spezialanwendungen einbinden will, darf die Gewichte niemals unkontrolliert über den Service Worker vorladen. Der Download muss zwingend in stornierbaren Chunks erfolgen und vorher das Speicherkontingent prüfen:

1/**
2 * Robuster Prüf- und Download-Ablauf für lokale Gewichtsdateien.
3 * Verhindert Out-of-Quota-Abbrüche und ermöglicht sauberes Abbrechen.
4 */
5interface ModelDownloadOptions {
6  modelUrl: string;
7  expectedBytes: number;
8  signal: AbortSignal;
9  onProgress: (ratio: number) => void;
10}
11
12export async function prepareLocalModelStorage({
13  modelUrl,
14  expectedBytes,
15  signal,
16  onProgress,
17}: ModelDownloadOptions): Promise<ArrayBuffer> {
18  // 1. Quota-Prüfung vor Beginn des Netzwerktransfers
19  if (navigator.storage && navigator.storage.estimate) {
20    const { quota, usage } = await navigator.storage.estimate();
21    const availableBytes = (quota ?? 0) - (usage ?? 0);
22
23    // Sicherheitsmarge von 200 MB für laufenden Browser-Betrieb
24    if (availableBytes < expectedBytes + 200 * 1024 * 1024) {
25      throw new DOMException(
26        `Nicht genügend Gerätespeicher: ${Math.round(availableBytes / (1024 * 1024))} MB frei, ` +
27        `benötigt werden ${Math.round(expectedBytes / (1024 * 1024))} MB.`,
28        "QuotaExceededError"
29      );
30    }
31  }
32
33  // 2. Download mit Unterstützung für Abbruchsignale
34  const response = await fetch(modelUrl, {
35    signal,
36    headers: { Accept: "application/octet-stream" },
37  });
38
39  if (!response.ok || !response.body) {
40    throw new Error(`Modell-Download fehlgeschlagen mit Status ${response.status}`);
41  }
42
43  const contentLength = Number(response.headers.get("Content-Length")) || expectedBytes;
44  const reader = response.body.getReader();
45  const chunks: Uint8Array[] = [];
46  let receivedBytes = 0;
47
48  while (true) {
49    const { done, value } = await reader.read();
50    if (done) break;
51
52    chunks.push(value);
53    receivedBytes += value.length;
54    onProgress(Math.min(1, receivedBytes / contentLength));
55  }
56
57  // 3. Konkatenation im Speicher
58  const result = new Uint8Array(receivedBytes);
59  let offset = 0;
60  for (const chunk of chunks) {
61    result.set(chunk, offset);
62    offset += chunk.length;
63  }
64
65  return result.buffer;
66}

Wie verhält sich dein eigener Browser?

Prüfe mit dem folgenden Auditor, welche Voraussetzungen dein aktuelles Endgerät erfüllt und wie sich das fehlende plattformübergreifende Modell-Sharing auf deinen Gerätespeicher auswirken würde.

Der Auditor verdeutlicht die Kernproblematik: Selbst wenn dein aktueller Browser WebGPU unterstützt und über ausreichend Quota verfügt, skaliert der Speicherbedarf linear mit jeder weiteren installierten Web-App. Es existiert keine softwareseitige Deduplizierung zwischen Origins.

Die pragmatische Alternative: Was offline wirklich funktioniert

Bedeutet das das Ende für Offline-KI in Web-Apps? Keineswegs. Es bedeutet lediglich, dass generative Chatbots das falsche Werkzeug für mobile PWAs sind.

Die Lösung, die in lukiluki.me mit hervorragender Resonanz im Einsatz ist, trennt semantische Filterung von generativer Sprachsynthese:

Wie das Zusammenspiel schlanker Zahlenvektoren ohne gigantischen Modell-Ballast funktioniert, beschreibt die Kachel Embeddings – Ähnliche Inhalte finden.

Entscheidungsprüfung für PWA-Architekten

Bevor du entscheidest, ein generatives Sprachmodell lokal in deine Web-App oder PWA zu integrieren, beantworte folgende Fragen:

• Speicher-Budget geprüft: Überschreitet die Modelldatei zusammen mit den App-Assets das vertretbare Cache-Budget von maximal 50 Megabyte für mobile Webnutzer?
• Sprachraum verifiziert: Wurde das Zielmodell auf echten deutschen Fachfragen getestet, ohne in Halluzinationen oder Sprachmischung zu verfallen?
• Eviction-Resilienz sichergestellt: Funktioniert die Kernanwendung fehlerfrei weiter, wenn iOS Safari oder Android den Modell-Cache nach sieben Tagen Inaktivität automatisch löscht?
• Embeddings als Alternative evaluiert: Lässt sich das fachliche Problem (z. B. Dokumentenfilterung, Ähnlichkeitssuche, Klassifikation) mit einem 25-MB-Vektormodell statt eines 500-MB-Chatbots lösen?
• Plattform-Transparenz gewahrt: Wird dem Nutzer vor Beginn des Downloads die exakte Megabyte-Zahl und der Akkuverbrauch transparent offengelegt?

Quellen und nächste Schritte

Die folgenden Primärquellen belegen die technischen Speichergrenzen und die aktuellen Standardisierungsdebatten der Browserhersteller:

• W3C Prompt API Explainer – Spezifikationsentwurf der WICG und Status der LanguageModel-Schnittstelle.
• Chrome for Developers: Built-in AI Requirements – Offizielle Google-Dokumentation zu den 22-GB-Speicherhürden und Desktop-Einschränkungen von Gemini Nano.
• Mozilla Standards Positions: Issue #1213 – Mozillas offizielle Ablehnung der Prompt API wegen Interoperabilitäts- und Fragmentierungsbedenken.
• WebKit Standards Positions: Issue #495 – Apples ablehnende Haltung zur Prompt API im Safari-Browser.
• WebLLM Paper (ArXiv:2412.15803) – Technische Evaluation der Speicher- und Shaderpuffer-Grenzen bei WebGPU-Inferenz im Browser.
• MDN Web Docs: Storage Quotas and Eviction Criteria – Bereinigungs- und Persistenzregeln für Web-Speicher.

Erkunde als theoretische Grundlage die Architektur in Offline-KI in Web-Apps, vertiefe Embeddings – Ähnliche Inhalte finden für ressourcenschonende Vektorsuche und lies WebNN – Maschinelles Lernen im Browser für den kommenden hardwarebeschleunigten NPU-Standard.