Der Stand von On-Device-KI im Browser

KI direkt im Browser auszuführen klingt unkompliziert, bis man versucht, sie produktiv einzusetzen. Die APIs sind fragmentiert, die Hardwareanforderungen variieren stark, und was auf einem Gerät funktioniert, schlägt auf einem anderen stillschweigend fehl. Bevor Sie Ihren ersten Inference-Aufruf implementieren, hilft es zu verstehen, was tatsächlich verfügbar ist, wie die Schichten zusammenpassen und wo Anfang 2026 die echten Lücken liegen.

Drei unterschiedliche Schichten, nicht eine Sache

Die größte Quelle der Verwirrung bei On-Device-Browser-KI ist, alle Ansätze als austauschbar zu behandeln. Das sind sie nicht. Es gibt drei unterschiedliche Schichten, und die falsche für Ihren Anwendungsfall zu wählen, schafft echte Probleme.

Schicht 1: Vom Browser bereitgestellte KI-APIs

Chrome liefert integrierte KI-APIs aus, die von Modellen unterstützt werden, die es direkt im Browser bereitstellt und verwaltet, einschließlich Gemini Nano. Wie in der Chrome built-in AI Dokumentation beschrieben, werden diese Modelle von Chrome selbst heruntergeladen und verwaltet. Chrome hat APIs wie Summarizer, Translator und Language Detector in stabilen Versionen verfügbar gemacht, während andere eingeschränkter bleiben. Die Prompt API ist stabil für Chrome-Erweiterungen, aber die Nutzung auf Webseiten ist noch experimentell oder basiert auf Origin Trials. Writer und Rewriter sollten Sie ebenfalls nicht als universell produktionsreif behandeln.

Microsoft Edge verfolgt einen ähnlichen Ansatz mit Phi-4-mini und stellt eine eigene API-Oberfläche bereit. Das Modell ist direkt in den Browser integriert und kann über APIs wie die Prompt API aufgerufen werden, die derzeit in der Developer Preview in Edge Canary und Dev Builds verfügbar ist. Diese APIs sind jedoch noch experimentell und in Produktionsumgebungen nicht breit verfügbar. Firefox hat KI-Funktionen wie Chatbot-Integration und Smart-Window-Experimente, stellt aber derzeit keine Chrome-ähnliche integrierte KI-API-Oberfläche für Webentwickler bereit.

Der Reiz ist offensichtlich: kein Model-Hosting, keine Bundle-Size-Kosten, minimales Setup. Der Haken ist ebenso offensichtlich: Sie sind an eine spezifische Browser-Implementierung gebunden, das Modell ist fest vorgegeben, und Sie haben keine Kontrolle darüber, welche Version läuft. Diese APIs erfordern auch, dass das Modell zuerst heruntergeladen wird, was groß sein kann und asynchron geschieht. Sie müssen das elegant handhaben.

// Feature-Detection vor Verwendung einer integrierten Browser-KI-API
if ('Summarizer' in self) {
  const availability = await Summarizer.availability();

  if (availability !== 'unavailable') {
    const summarizer = await Summarizer.create();
    const summary = await summarizer.summarize(articleText);
  }
} else {
  // Fallback zur Cloud oder Feature überspringen
}

Schicht 2: JavaScript-basierte Inference mit Transformers.js und ONNX Runtime Web

Wenn Sie breitere Browser-Unterstützung benötigen oder Ihr eigenes Modell wählen möchten, ist Transformers.js derzeit eine der praktischsten Optionen. Es führt Hugging-Face-Modelle direkt im Browser im ONNX-Format aus und kann WebGPU-Beschleunigung nutzen, wenn verfügbar, mit Fallback auf WebAssembly, wo unterstützt.

ONNX Runtime Web bietet Ihnen ähnliche Reichweite mit mehr Kontrolle über Execution Provider. Beide sind vernünftige Optionen für Klassifizierung, Übersetzung, Sentiment-Analyse, Embeddings und leichtgewichtige Textgenerierungsaufgaben.

Beachten Sie, dass Transformers.js v3 zum Package @huggingface/transformers gewechselt ist. Der unten gezeigte Import @xenova/transformers gilt für v2, das in bestehenden Projekten noch verbreitet ist:

// Transformers.js v2
import { pipeline } from '@xenova/transformers';

// Transformers.js v3+
// import { pipeline } from '@huggingface/transformers';

const classifier = await pipeline('sentiment-analysis');
const result = await classifier('This article is genuinely useful.');

Die Modellgröße ist die Haupteinschränkung. Ein quantisiertes Modell, das für Browser-Inference geeignet ist, kann je nach Aufgabe von einigen Dutzend bis zu Hunderten von Megabytes reichen. Größere Modelle werden ohne sorgfältiges Caching über IndexedDB oder die Cache API unpraktisch.

Schicht 3: WebGPU und WebAssembly als Beschleunigungsprimitive

WebGPU und WebAssembly sind keine KI-APIs. Sie sind Low-Level-Primitive, die Frameworks wie Transformers.js, ONNX Runtime Web und TensorFlow.js intern nutzen können, um Inference schneller auszuführen. Sie interagieren selten direkt mit ihnen, es sei denn, Sie bauen ein Framework oder führen benutzerdefinierte Berechnungsarbeiten durch.

WebGPU erschließt insbesondere bedeutsame GPU-Beschleunigung für Matrixoperationen, was für alles jenseits winziger Modelle wichtig ist. Die Unterstützung ist viel breiter als früher, erfordert aber immer noch Feature-Detection, da Browser, Betriebssystem, Gerät, Treiber und mobile Unterstützung variieren.

Was WebNN zum Bild hinzufügt

WebNN (Web Neural Network API) ist eine W3C-API, die entwickelt wurde, um hardwarebeschleunigte neuronale Netzwerkoperationen, einschließlich NPU-Zugriff auf unterstützten Geräten, über eine konsistente Browser-Schnittstelle bereitzustellen. Sie sitzt zwischen Ihrem Framework und der Hardware, ähnlich wie WebGPU, ist aber speziell für ML-Workloads konzipiert.

Die Browser-Unterstützung ist Anfang 2026 begrenzt. Chrome hat eine partielle Implementierung, und breitere Unterstützung in anderen Browsern ist noch in Arbeit. Frameworks wie ONNX Runtime Web fügen WebNN bereits als Execution-Backend hinzu, sodass Sie wahrscheinlich indirekt davon profitieren werden, bevor Sie es direkt nutzen.

Die ehrlichen Kompromisse

Datenschutzvorteile sind real, aber bedingt. Lokale Inference bedeutet, dass Eingabedaten das Gerät während der Verarbeitung nicht verlassen, aber die Website kann immer noch protokollieren, was Benutzer eingeben, bevor es das Modell erreicht. „Lokal” bedeutet nicht automatisch privat von Ende zu Ende.

Offline-Fähigkeit ist ähnlich bedingt. Sobald ein Modell gecacht ist, kann Inference ohne Verbindung funktionieren. Aber der initiale Download erfordert eine, und Modell-Updates erfordern eine erneute Verbindung.

Hybrid ist der realistische Standard

Die meisten Produktionsanwendungen werden nicht vollständig auf dem Gerät laufen. Das praktische Muster ist, lokale Inference zu versuchen, API-Verfügbarkeit und Hardware-Fähigkeit zu prüfen und dann auf einen Cloud-Endpoint zurückzufallen, wenn beides fehlt. Dies gibt leistungsfähigen Geräten eine schnellere, privatere Erfahrung, ohne die Funktion für alle anderen zu brechen.

Fazit

On-Device-KI im Browser ist heute für spezifische, begrenzte Aufgaben wirklich nützlich: ein Dokument zusammenfassen, eine Sprache erkennen, kurzen Text klassifizieren, Embeddings generieren oder einen leichtgewichtigen Assistenten ausführen. Vollständige LLM-Scale-Erfahrungen im Browser bleiben inkonsistent und hardwareabhängig. Bauen Sie für die realistische Mitte, und Sie werden etwas ausliefern, das tatsächlich funktioniert.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.