LLMs im Browser – Teil 1: Eine neue KI-Runtime

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:

• Schutz der persönlichen Daten: Alle Ein- und Ausgaben einschließlich der Inferenz bleiben im Client.
• Offlinefähigkeit: Der Browser lädt das Modell vollständig herunter. Damit ist eine KI-Anwendung unabhängig von einer Serverinfrastruktur.
• Zero-Cost-Inferenz: Für viele Modelle, die ein Browser ausführen kann, entstehen keine zusätzlichen Kosten.
• Nähe zum User-Kontext (Tabs, Inhalte, lokale Dateien): Das Modell ist dort eingebettet, wo Benutzer interagieren. Es ist an der Quelle der Benutzerintention und kann die Daten unverfälscht nutzen.
• Neue UX-Möglichkeiten: Das Modell kann mit den bestehenden Webtechnologien interagieren und bietet so neue Möglichkeiten der Oberflächengestaltung und Reaktion auf User-Interaktionen.

Was Browser-LLMs wirklich leisten können

LLMs im Browser spielen ihre Fähigkeiten in vielen unterschiedlichen Anwendungsfällen aus. Diese lassen sich in die folgenden Kategorien einteilen:

• Inhalte verstehen: LLMs sind sehr gut darin, Text zu verstehen und mit Text zu arbeiten. Im Browser können sie diese Fähigkeit unmittelbar anwenden, weil das Modell direkt im Kontext der Webseite eingebunden ist, auf der sich der Nutzer gerade befindet. Es sieht den aktuellen Anwendungskontext wie markierte Absätze, Tabellen oder UI-Elemente, ohne dass der Inhalt erst übertragen werden muss. Dadurch versteht das Modell den Text nicht nur, sondern kann ihn im Zusammenhang mit der aktuellen Aufgabe interpretieren und direkt darauf reagieren.
• Die Anwendung erklären: Das Modell schlüpft hier in die Rolle eines interaktiven Assistenten und hilft bei der Bedienung einer Anwendung. Das Modell kennt in diesem Fall die Anwendung über den ihm zur Verfügung stehenden Kontext und kann Hilfestellung im aktuellen Workflow oder bei Fehlermeldungen bieten.
  Beispiel: Warum ist der Speichern-Button deaktiviert? Was macht dieser Dialog?
• Aufgaben innerhalb der Anwendung erledigen: Das Modell kann nicht nur textuelle Antworten generieren, sondern mit entsprechender Unterstützung durch Tools auch mit seinem Ökosystem, also auch der Webanwendung, interagieren. Das Modell kann Formulare ausfüllen, Daten übernehmen, Filter setzen oder navigieren.
  Beispiel: Das Modell filtert eine Tabelle nach bestimmten Kriterien und wendet eine Sortierung an, sodass sie die für den Benutzer relevanten Informationen zeigt.
• Die Oberfläche dynamisch anpassen: Das Modell ist in der Lage, die Oberfläche anhand des aktuellen Kontexts so anzupassen, dass der Benutzer sich auf seine Aufgabe konzentrieren kann. Es kann bestimmte, nicht relevante Elemente ausblenden, Informationen hervorheben oder die Navigation vereinfachen.
  Beispiel: Das Modell gibt dem Benutzer zu Beginn einer Session einen Überblick über die wichtigsten Informationen und stellt eine Sammlung von Links zu den dringendsten Aufgaben zusammen.
• Proaktive Unterstützung: Ein Modell muss nicht immer auf Interaktion des Nutzers warten, sondern kann auch im Hintergrund agieren. Es erkennt Situationen und kann selbst drauf reagieren. Beispiele sind hier mehrfache fehlerhafte Formulareingaben, langes Suchen oder ungewöhnliche Aktionen.
  Beispiel: Wechselt der Benutzer häufig zwischen zwei Seiten und kopiert Inhalte zwischen ihnen, könnte das Modell vorschlagen, die Informationen automatisch zu übernehmen.

Wo liegen die Grenzen der lokalen KI?

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.

Built-in AI – der Browser stellt das LLM zur Verfügung

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:

const startButton = document.querySelector('#start'); const colorPicker = document.querySelector('#colorPicker'); const outputDiv = document.querySelector('#output'); const statusIndicator = document.querySelector('#statusIndicator'); const COLOR = { OK: 'green', PENDING: 'yellow', ERROR: 'red' }; startButton.addEventListener('click', async () => { if (typeof LanguageModel === 'undefined') { console.error('LanguageModel is not defined. Prompt API is not available.'); statusIndicator.style.backgroundColor = COLOR.ERROR; return; } startButton.disabled = true; const availability = await LanguageModel.availability(); if (availability === 'available') { statusIndicator.style.backgroundColor = COLOR.OK; } else if (availability === 'downloading') { statusIndicator.style.backgroundColor = COLOR.PENDING; } else { statusIndicator.style.backgroundColor = COLOR.ERROR; } try { const session = await LanguageModel.create({ monitor(m) { m.addEventListener('downloadprogress', () => { statusIndicator.style.backgroundColor = m.loaded < 1 ? COLOR.PENDING : COLOR.OK; }); }, initialPrompts: [ { role: 'system', content: 'Erkläre eine Farbe anhand ihres Farb Hashcodes in einem einzigen Satz. Antworte ausschließlich mit dem Farbnamen und einer kurzen Beschreibung der Farbe. Gib keine weitere Informationen aus.', }, ], }); colorPicker.addEventListener('change', async () => { outputDiv.textContent = await session.prompt(colorPicker.value); }); } catch (err) { console.error('Failed to create LanguageModel session:', err); statusIndicator.style.backgroundColor = COLOR.ERROR; startButton.disabled = false; } });

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:

• Summarizer: Erzeugt eine Zusammenfassung für einen Eingabetext.
• Writer: Schreibt einen Text auf Basis des übergebenen Prompts.
• Rewriter: Der Rewriter nimmt einen Text und schreibt ihn nach ausgewählten Kriterien um.
• Proofreader: Überprüft einen übergebenen Text auf Grammatik, Rechtschreibung und Zeichensetzung.
• Translator: Übersetzt einen Text in eine andere Sprache.
• LanguageDetector: Erkennt die Sprache eines übergebenen Texts und liefert dazu einen Confidence-Wert, der angibt, wie sicher sich der Detector dabei ist.

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.

Bring Your Own AI – die Anwendung bringt das LLM selbst mit

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.