On-Device-KI im Browser: private Shop-Features mit WebGPU

On-Device-KI verlagert die Sprachverarbeitung dorthin, wo die Daten entstehen: in den Browser des Kunden. Möglich macht das WebGPU - die Schnittstelle, die Webseiten direkten Zugriff auf die Grafikkarte gibt und im Januar 2026 in allen großen Browsern den Baseline-Status erreicht hat (web.dev/MDN). Rund 83 % aller Browser-Sitzungen unterstützen WebGPU inzwischen (caniuse). Damit lassen sich kleine Sprachmodelle mit 1 bis 3 Milliarden Parametern direkt auf dem Endgerät ausführen - ohne dass Suchanfragen, Warenkorbdaten oder Chatverläufe je einen fremden Server erreichen. Für Online-Shops eröffnet das drei konkrete Anwendungen: datenschutzfreundliche KI-Assistenten, semantische On-Site-Suche und Textbausteine, die auch offline und ohne laufende API-Kosten funktionieren. Dieser Leitfaden ordnet Technik, Grenzen und einen realistischen Hybrid-Ansatz ein.

Was WebGPU 2026 möglich macht

WebGPU ist der Nachfolger von WebGL und wurde von der W3C GPU for the Web Working Group (gpuweb) als offener Web-Standard spezifiziert (W3C). Der entscheidende Unterschied: Während WebGL auf Grafik-Rendering ausgelegt war, stellt WebGPU zusätzlich Compute-Shader bereit - genau die Bausteine, die für die Matrixmultiplikationen eines neuronalen Netzes gebraucht werden. Chrome liefert WebGPU seit Version 113 (Mai 2023) standardmäßig aus, Edge ebenfalls ab 113, Safari ab Version 26 auf macOS Tahoe, iOS und iPadOS, und Firefox seit Version 141 unter Windows (MDN/caniuse). Im Januar 2026 erreichte die Schnittstelle Baseline-Status - das formale Signal, dass ein Web-Feature breit und stabil verfügbar ist (web.dev).

Für Shop-Betreiber ist das mehr als eine technische Randnotiz. Jede Millisekunde Reaktionszeit wirkt sich messbar auf Umsatz aus: Eine von Google beauftragte Deloitte-Studie über 30 Millionen Nutzersitzungen fand, dass bereits 0,1 Sekunden schnellere mobile Ladezeit die Conversion im Handel um 8,4 % und den durchschnittlichen Bestellwert um 9,2 % steigern (Deloitte). On-Device-Inferenz kann Antworten ohne Netzwerk-Roundtrip liefern - der Latenzvorteil ist strukturell, nicht nur eine Optimierung.

Wie ein Sprachmodell im Browser läuft

Der Ablauf ist in drei Schritten erklärt. Erstens wird das Modell einmalig heruntergeladen und im Browser-Speicher (Cache API oder Origin Private File System) abgelegt, sodass spätere Besuche keinen erneuten Download brauchen. Zweitens sind die Gewichte quantisiert - meist auf 4 Bit statt 16 oder 32 Bit, was Dateigröße und Speicherbedarf drastisch senkt, bei nur geringem Qualitätsverlust. Drittens übernimmt WebGPU die eigentliche Berechnung auf der Grafikkarte, während WebAssembly die Verwaltungslogik im Browser ausführt. Open-Source-Engines wie WebLLM vom MLC-AI-Projekt kapseln diesen Aufbau hinter einer OpenAI-kompatiblen Schnittstelle (WebLLM/MLC AI).

Wie schnell das ist, zeigt das WebLLM-Paper: Auf einem MacBook Pro mit M3 Max erreicht Phi-3.5-mini (3,8B) rund 71 Token pro Sekunde, ein Llama-3.1-8B-Modell etwa 41 Token pro Sekunde (WebLLM). Insgesamt behält die Browser-Ausführung rund 80 % der Geschwindigkeit einer nativen Installation auf identischer Hardware (WebLLM). Kleinere 1-3B-Modelle, die für klar umrissene Shop-Aufgaben ausreichen, laufen entsprechend flüssiger. Die technische Einbindung in ein bestehendes Frontend übernimmt in der Praxis unsere Web-Entwicklung.

import { CreateMLCEngine } from "@mlc-ai/web-llm";

// Modell wird einmalig geladen und im Browser-Cache gehalten
const engine = await CreateMLCEngine(
  "Llama-3.2-1B-Instruct-q4f16_1-MLC",
  {
    initProgressCallback: (p) => console.log(p.text) // Download-Fortschritt
  }
);

// OpenAI-kompatible Schnittstelle - alles lokal, kein Netzwerk
const reply = await engine.chat.completions.create({
  messages: [
    { role: "system", content: "Du bist ein Produktberater für unseren Shop." },
    { role: "user", content: "Welche Größe passt bei 182 cm und 78 kg?" }
  ],
  temperature: 0.6
});

Drei datenschutzfreundliche Shop-Features

Nicht jede KI-Aufgabe braucht ein großes Cloud-Modell. Gerade wiederkehrende, klar umrissene Shop-Funktionen lassen sich On-Device sinnvoll umsetzen - mit dem Zusatznutzen, dass sensible Eingaben das Gerät nicht verlassen.

Besonders die Suche hat Hebelwirkung: Baymard-Untersuchungen zeigen, dass 41 % der E-Commerce-Seiten zentrale Suchanfrage-Typen ihrer Kunden nicht vollständig unterstützen und 70 % an Synonymen für Produkttypen scheitern (Baymard). Eine semantische Suche, die Bedeutungen statt nur Zeichenketten vergleicht, adressiert genau diese Lücke. Wie sich das konkret aufbauen lässt, zeigt unser Leitfaden zur KI-gestützten Produktsuche.

Datenschutz: Warum On-Device ein echter Vorteil ist

Der zentrale Vorteil ist rechtlich wie technisch derselbe: Was das Gerät nicht verlässt, muss nicht übertragen, gespeichert oder von einem Auftragsverarbeiter verarbeitet werden. Damit reduziert On-Device-Inferenz die Angriffsfläche und den Dokumentationsaufwand rund um Drittland-Transfers, die bei Cloud-KI regelmäßig zu klären sind. Nutzer sind hier sensibler, als viele Shops annehmen: Laut Bitkom stimmen 79 % der Internetnutzer Datenschutzerklärungen zu, ohne sie wirklich zu verstehen, und 68 % fühlen sich schlecht darüber informiert, wie sie ihre Daten schützen können (Bitkom).

Der datensparsamste Datensatz ist der, der nie das Endgerät verlässt. On-Device-KI verschiebt die Vertrauensfrage von der Übertragung zur Nicht-Übertragung.

XICTRON Entwicklungsteam

On-Device ergänzt bestehende Cookieless-Strategien. Wer bereits an einer Erste-Party-Datenstrategie arbeitet oder das Cookie-Banner reduzieren möchte, fügt mit lokaler KI einen weiteren datensparsamen Baustein hinzu. Wichtig bleibt eine ehrliche Kommunikation - keine Absolutversprechen, sondern die nachvollziehbare Aussage, welche Verarbeitung lokal und welche serverseitig stattfindet.

Grenzen ehrlich einordnen: Modellgröße, Erstdownload, Geräte

On-Device-KI ist kein Ersatz für große Cloud-Modelle, sondern eine Ergänzung für den richtigen Aufgabenzuschnitt. Ein 1-3B-Modell versteht Anweisungen und formuliert brauchbare Kurzantworten, kommt aber bei komplexem Fachwissen oder langen Kontexten an Grenzen. Dazu kommen drei praktische Hürden: der Erstdownload des Modells, die Geräteabhängigkeit (schwache Smartphones und ältere GPUs) und eine höhere Anfangslatenz, bis das Modell geladen ist.

Die Anforderungen zeigt Chromes eingebaute KI besonders deutlich: Die Prompt API mit dem Modell Gemini Nano ist seit Chrome 138 stabil und läuft über WebAssembly und WebGPU vollständig auf dem Gerät (Chrome for Developers). Chrome nennt als Voraussetzung unter anderem 22 GB freien Speicher auf dem Profil-Laufwerk, mehr als 4 GB VRAM und mindestens 16 GB RAM (Chrome for Developers). Nicht jedes Gerät erfüllt das - weshalb eine Feature-Erkennung und ein Fallback Pflicht sind.

Hybrid-Ansatz: On-Device plus Server-Fallback

Der robusteste Weg für Produktivumgebungen ist selten entweder-oder, sondern ein Hybrid-Modell nach dem Prinzip Progressive Enhancement. Der Shop prüft zunächst per Feature-Erkennung, ob WebGPU und eine geeignete GPU vorhanden sind. Ist das der Fall, laufen einfache und datenschutzsensible Aufgaben lokal; fehlt die Hardware oder erfordert eine Anfrage ein größeres Modell, wird - mit klarer Nutzerinformation - serverseitig eskaliert.

// Feature-Erkennung: Ist On-Device-Inferenz möglich?
async function pickInferenceMode() {
  if (!("gpu" in navigator)) return "server"; // kein WebGPU
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) return "server"; // keine passende GPU

  // WebGPU vorhanden -> einfache, private Aufgaben lokal
  return "on-device";
}

// Datenschutz-sensible Aufgaben bevorzugt lokal, Rest optional serverseitig
const mode = await pickInferenceMode();

• Lokal zuerst: Suche, Textvorschläge und Standardfragen laufen On-Device, wenn die Hardware es hergibt.
• Server bei Bedarf: Komplexe oder wissensintensive Anfragen gehen - transparent und idealerweise mit Einwilligung - an ein größeres Modell.
• Graceful Degradation: Ohne WebGPU bleibt der Shop voll funktionsfähig; die KI-Funktion fällt nicht aus, sondern wechselt den Ausführungsort.
• Offline-Nutzen: Einmal geladen, arbeiten lokale Funktionen auch ohne Verbindung weiter - ein natürlicher Anknüpfungspunkt für Progressive Web Apps.

Diese Logik gehört in eine saubere Architektur, nicht in verstreute Inline-Skripte. Die Kapselung als wiederverwendbarer Baustein, das Lazy-Loading der Engine und die Fehlerbehandlung für ältere Geräte sind klassische Aufgaben unserer individuellen Entwicklung.

Browser-Support und Hardware 2026

Die Verfügbarkeit ist 2026 kein Blocker mehr, aber je nach Umgebung unterschiedlich. Für die reine Grafik- und Compute-Schnittstelle WebGPU gilt breite Unterstützung; die eingebauten KI-Modelle einzelner Browser haben zusätzliche Hardware-Anforderungen.

Zwei Wege stehen zur Wahl. WebLLM läuft browserübergreifend überall dort, wo WebGPU aktiv ist, und lädt das gewünschte Modell je Origin nach (WebLLM). Chromes eingebaute KI dagegen bringt das Modell mit dem Browser mit, ist aber vorerst auf Chrome und ausreichend ausgestattete Geräte beschränkt (Chrome for Developers). Weil die Erstlatenz und der Speicherbedarf spürbar sind, gehört On-Device-KI in eine Performance-Strategie eingebettet - so, wie wir es für Core Web Vitals generell empfehlen: messen, budgetieren, nur laden, was der Kontext braucht.

On-Device-KI schrittweise einführen

Ein pragmatischer Einstieg beginnt klein, misst den Nutzen und skaliert erst dann. Die folgende Reihenfolge hat sich für Shop-Projekte bewährt.

1. Anwendungsfall wählen: Mit einer klar umrissenen, datenschutzsensiblen Funktion starten - etwa der On-Site-Suche oder einem Produktberater - statt mit einem Allzweck-Assistenten.
2. Machbarkeit prüfen: Zielgeräte und Browser der eigenen Zielgruppe analysieren. Passt das Verhältnis aus WebGPU-Abdeckung und Geräteklasse zum Vorhaben?
3. Hybrid-Architektur festlegen: Feature-Erkennung, lokale Ausführung und Server-Fallback als wiederverwendbaren Baustein definieren - inklusive transparenter Nutzerkommunikation.
4. Wahrgenommene Performance sichern: Ladezustände und weiche Übergänge einplanen, damit die Erstlatenz nicht stört - hier hilft die View Transitions API für flüssige Wechsel.
5. Sauber integrieren: Die Engine als Modul kapseln und in die Shop-Plattform einbinden - bei Shopware im Zusammenspiel mit der modernen Plugin- und Vite-Architektur.
6. Messen und ausbauen: Nutzung, Antwortqualität und Abbruchraten beobachten, dann weitere Funktionen ergänzen. Bei Konzeption und Priorisierung unterstützt unsere KI-Beratung und Konzeptionsberatung.