|
09.09.2026 09:10 Uhr |
Browser haben sich über die vergangenen Jahre stetig weiterentwickelt. Ursprünglich waren sie reine Anzeigewerkzeuge für HTML und Medien. Mit JavaScript, WebAssembly, WebGL und WebGPU wurden sie zu vollwertigen Anwendungsplattformen, die auch Bytecode ausführen und komplexe 3D-Grafik darstellen können.
KI im Browser ist die nächste Evolutionsstufe und ermöglicht neue Interaktionsmuster für Weboberflächen wie natürlichsprachliche Eingaben und das Streaming von Ausgaben. Ein Teil der Aufgaben lässt sich von serverseitigen Modellen zum Client verlagern, wodurch sich ganz neue Interaktionsmuster und architektonische Möglichkeiten eröffnen. Es gibt dabei zwei Bestrebungen: Built-in AI, bei der der Browserhersteller das Modell selbst über standardisierte Schnittstellen zur Verfügung stellt, und Bring Your Own AI, bei der das Modell Bestandteil des Web-Frontends ist.
Lokale LLMs im Browser bringen entscheidende Vorteile mit sich, die serverseitige Modelle nicht leisten können:
Agentische KI bringt eine neue Dynamik in die Webentwicklung. Erfahre am 22. Oktober 2026 auf der Online-Konferenz enterJS Agentic, wie du mit Agentic AI moderne JavaScript-/TypeScript-Projekte entwickelst, wie du Kosten vs. Performance abwägst und wobei dir KI wirklich weiterhilft. Frühbuchertickets sind im Online-Ticketshop erhältlich.
LLMs im Browser spielen ihre Fähigkeiten in vielen unterschiedlichen Anwendungsfällen aus. Diese lassen sich in die folgenden Kategorien einteilen:
LLMs sind ressourcenintensiv. Ihre internen Strukturen wie die Gewichte brauchen Speicherplatz, hinzu kommt der Speicher für den Kontext. Je mehr RAM zur Verfügung steht und je schneller ein Modell auf diesen Speicher zugreifen kann, desto schneller und stabiler läuft die Inferenz. Es lassen sich größere Modelle verwenden, mehr Kontext nutzen und das Modell antwortet schneller. Allerdings reicht die Spannbreite der Endgeräte von einfachen Smartphones bis zu leistungsfähigen stationären Rechnern. Modelle müssen also auch mit Geräten geringer Leistung funktionieren. In der Regel liegt eine sinnvolle Obergrenze bei etwa 4 GByte. Damit lassen sich Modelle zwischen drei und 7 Milliarden Parametern verwenden.
Nicht nur die Ressourcen des Endgeräts, sondern auch die Übertragungsbandbreite limitiert die Modellgröße. Bei einer schwachen Mobilfunkverbindung kann der initiale Download eines größeren Modells mehrere Minuten dauern oder sogar fehlschlagen, was die nutzbare Modellgröße begrenzt.
Die Größenbeschränkung der Modelle hat eine direkte Auswirkung auf ihre Leistungsfähigkeit und ihren Feature-Umfang. Kleinere Modelle brauchen eine klarere Rahmensetzung als große Modelle, da sie eher zu Halluzinationen tendieren, und sie besitzen ein kleineres Kontextfenster. Die großen Frontier-Modelle verfügen über Kontextfenster mit einer bis zehn Millionen Token. Kleinere Modelle liegen typischerweise bei etwa 128.000 Token, beispielsweise Gemma 4 E4B. Beim lokalen Einsatz wird der Kontext sogar noch weiter reduziert, da er wertvollen Speicher belegt. Auch die Fähigkeiten der Modelle unterscheiden sich. Das Reasoning ist bei den kleineren Modellen deutlich eingeschränkt und nur wenige von ihnen können visuelle Eingaben analysieren.
Die grundlegende Architektur der Modelle unterscheidet sich ebenfalls. Bei den kleineren handelt es sich meist um Dense Models, bei denen immer alle Parameter aktiv sind.
Die meisten dieser Einschränkungen lassen sich durch gezielte Rahmensetzungen und entsprechendes Prompting gut umgehen.
Bei der Built-in AI liefert der Browser das Modell aus und stellt es über eine standardisierte Schnittstelle der Frontend-Anwendung zur Verfügung. Dieser Ansatz befindet sich aktuell noch in den Kinderschuhen und wird hauptsächlich von Google getragen. Deshalb unterstützen Chrome und alle Browser, die sich aus Chrome ableiten, wie Microsoft Edge, die Schnittstelle vollständig, wohingegen Mozilla und Apple noch nicht mitziehen.
Der große Vorteil von Built-in AI ist, dass sich die Anwendung nicht um das Modell-Management, die Ausführung des Modells und den Download kümmern muss – diese Punkte übernimmt der Browser. Daraus ergibt sich jedoch der Nachteil, dass es keine Auswahl an Modellen gibt, sondern man auf das verfügbare Modell beschränkt ist. Chrome nutzt Gemini Nano, Microsoft Edge Phi-4-mini sowie zukünftig Aion-1.0-instruct.
Google arbeitet aktuell daran, die Built-in AI zum Browser-Standard zu machen. Dafür sind, wie in jedem Web-Standard, mindestens zwei voneinander unabhängige Implementierungen in unterschiedlichen Browser-Engines erforderlich. Mit der Integration in Chrome ist bereits eine dieser Implementierungen vorhanden.
Die Schnittstelle gliedert sich in drei Ebenen: Modell-Management, die Prompt-API und die High-Level-Schnittstellen.
Für das Verwenden der Prompt-API müssen Geräte die folgenden Mindestanforderungen erfüllen, was eine minimale Performance der Schnittstelle sicherstellen soll: Es werden bestimmte Versionen des Betriebssystems vorausgesetzt (zum Beispiel Windows 10 oder macOS 13), auf dem Gerät müssen mindestens 22 GByte Festplattenspeicher frei sein, die GPU muss mindestens 4 GByte VRAM haben, um den schnelleren GPU-Modus zu nutzen, und für den CPU-Modus muss das Gerät mindestens 16 GByte RAM sowie 4 CPU-Kerne besitzen.
Ob der Browser die Schnittstelle generell unterstützt, lässt sich anhand des Vorhandenseins der LanguageModel-Klasse prüfen. Anschließend gibt die availability-Methode Aufschluss über den Zustand der Verfügbarkeit. Dieser reicht von unavailable, weil beispielsweise die Voraussetzungen nicht erfüllt sind, über downloadable, wenn das Modell verfügbar, aber noch nicht heruntergeladen ist, über downloading, wenn das Modell aktuell heruntergeladen wird, bis available, sobald das Modell heruntergeladen und bereit ist.
Die create-Methode der Klasse erzeugt eine neue Session, die dann als Schnittstelle für die Kommunikation mit dem Modell dient. Ist das Modell noch nicht heruntergeladen, lädt es der Browser herunter. Die create-Methode akzeptiert zahlreiche Konfigurationsoptionen, beispielsweise initiale Prompts, die unter anderem den System-Prompt enthalten können, den Temperaturwert, der die Kreativität des Modells beeinflusst, oder den topK-Wert, der ähnlich zur Temperatur die Auswahl des nächsten Tokens bei der Generierung beeinflusst.
Die eigentliche Modellkommunikation erfolgt dann über die prompt-Methode. Sie sendet eine Nachricht an das LLM und erhält die generierte Antwort zurück.
Das Listing zeigt ein einfaches Beispiel, bei dem das Modell einen Farbcode aus einem Colorpicker entgegennimmt, die Farbe benennt, in einem Satz beschreibt und das Ergebnis in ein Ausgabeelement schreibt:
Listing 1: Verwenden der Prompt-API im Browser
Die prompt-Methode gibt das Ergebnis zurück, sobald alle Token der Antwort erzeugt sind. Die promptStreaming-Methode hingegen stellt die Token sofort zur Verfügung, sobald sie erzeugt sind. Mit einer for-await-of-Schleife lassen sich die einzelnen Token konsumieren und anzeigen.
Die LanguageModel-Klasse ist die grundlegende Schnittstelle. Sie ist flexibel und eignet sich für alle clientseitigen Aufgabenstellungen. Die Prompt-API stellt jedoch noch einige weitere Klassen für Spezialaufgaben zur Verfügung:
Jedes dieser Features ist über die entsprechende Klasse verfügbar. Die Grundlage ist jeweils die mit der create-Methode erzeugte Session. Darüber konfigurieren Entwicklerinnen und Entwickler die Session und teilen ihr zusätzliche Informationen mit. Anschließend setzen sie in der Session eine Methode ein, die das Feature auslöst, beispielsweise beim Summarizer die summarize-Funktion.
Die Built-in-Schnittstellen – Prompt-API, Rewriter, Proofreader und weitere – befinden sich aktuell noch in einem frühen Entwicklungsstadium, und ob sie sich als browserübergreifender Standard durchsetzen, ist noch offen. Die Anwendungsfälle für lokale KI im Browser sind jedoch schon vorhanden. Würde man mit deren Umsetzung bis zur Verabschiedung des Standards warten, ginge wertvolle Zeit verloren. Das Web ist schon immer von Übergangslösungen geprägt, die später durch Standards ersetzt wurden, wie Emscripten und asm.js, die als Vorläufer von WebAssembly das Ausführen von C- und C++-Code im Browser ermöglichten.