WebGPU: KI im Browser – direkt auf Ihrer GPU
Wie eine Website ein Sprachmodell auf dem Gerät des Besuchers ausführen kann – ganz ohne Installation und ohne Cloud-Aufruf für jedes generierte Wort. Sie öffnen eine Seite, ein Fortschrittsbalken benötigt ein paar Minuten zum Laden, dann erscheint ein Textfeld. Sie tippen, und das Modell antwortet. Keine Programme zu installieren, keine Schlüssel einzufügen, keine entfernten Server, die Wörter produzieren: Die Arbeit erledigt die Grafikkarte des Computers vor Ihnen, gesteuert von einer Webseite. Beim nächsten Besuch ist der Ladebalken kaum zu sehen, da die Modellgewichte auf der Festplatte gespeichert blieben – in einem Bereich, den der Browser für diese Website reserviert.
Die Hauptrolle in diesem Szenario spielt WebGPU, und es lohnt sich sofort klarzustellen, was es nicht ist. Es ist kein Modell, kein Dateiformat, kein zu installierendes Programm. Es ist eine Schnittstelle, die der Browser Webseiten bietet, um mit der Grafikkarte zu kommunizieren – sowohl für Grafik-Rendering als auch für allgemeine parallele Berechnungen –, definiert durch die Spezifikation des W3C. Das Herunterladen der Gewichte, das Speichern, das Übersetzen von Text in Zahlen und zurück obliegt anderen Bausteinen der Kette. Dieser Artikel ordnet sie alle der Reihe nach ein, mit den heute verfügbaren Zahlen und einem ehrlichen Blick auf die Grenzen.
Die GPU betritt den Browser
Um zu verstehen, warum die Grafikkarte für künstliche Intelligenz unverzichtbar ist, hilft das Bild einer Küche. Der Prozessor ist ein hocherfahrener Chefkoch, der ein Gericht nach dem anderen mit perfekten Handgriffen zubereitet. Die GPU ist eine Küche mit Tausenden von Küchenhilfen, von denen jeder nur eine einzige einfache Aufgabe erledigen kann, die aber alle genau im selben Moment arbeiten. Ein Sprachmodell verbringt seine Zeit damit, Zahlentabellen zu multiplizieren – eine Aufgabe, die sich in Millionen unabhängiger Rechnungen zerlegen lässt: Es ist die ideale Schicht für die Küchenbrigade, nicht für den Chefkoch.
Jahrelang konnten Browser mit der GPU jedoch hauptsächlich sprechen, um Grafiken zu zeichnen. Mit WebGL musste jeder, der sie für andere Berechnungen nutzen wollte, Zahlen als Pixel und Rechnungen als Grafikeffekte tarnen. WebGPU ändert diesen Ansatz, da es den Grafiken Compute Shader zur Seite stellt: kleine Programme in einer Sprache namens WGSL, die die GPU für beliebige Berechnungen ausführt, nicht nur zum Einfärben von Dreiecken.
Zwischen der Webseite und dem Silizium verläuft ein Netz von Rohrleitungen, das jenem in Terry Gilliam-Film Brazil ähnelt, in dem jede Anfrage Abteilungen und Rohre durchquert, bevor sie eine Wirkung erzielt. Die Seite spricht WebGPU, der Browser übersetzt für Metal auf Apple, Vulkan auf Linux und Android, DirectX auf Windows; dafür zuständig sind verschiedene Engines: Dawn in Chromium-basierten Browsern, wgpu in Firefox und eine eigene WebKit-Implementierung in Safari, wie der später besprochene Preprint beschreibt.
Der Meilenstein, der dieses Thema heute aktuell macht, ist die Abdeckung der Browser. Wie web.dev in Erinnerung ruft, unterstützen Chrome und Edge WebGPU seit Version 113 auf Windows, macOS und ChromeOS, während unter Android Chrome 121 und mindestens Android 12 erforderlich sind. Firefox bietet es auf Windows seit Version 141 und auf ARM-Macs seit 145, Safari führte es mit Version 26 auf allen Apple-Systemen ein. Die Hinweise von Khronos verorten Firefox auf Windows im Juli 2025 und Safari im September 2025 und ergänzen, dass Chromium die Unterstützung auf Linux für Intel-GPUs der zwölften Generation und neuer im Januar 2026 erweitert hat. Rückständig bleiben Firefox auf Linux und Android, die sich laut web.dev noch in Arbeit befinden. Entwickler müssen daher einen Ausweichplan für jene vorsehen, die nicht in diesen Listen stehen.
Vom Download zu den Tokens
Der Ablauf der KI im Browser folgt einer präzisen Sequenz. Die Seite prüft, ob WebGPU vorhanden ist und die GPU geeignet ist; anschließend lädt sie das Modell von einem Server oder CDN herunter, speichert es im Bereich des Browsers und lädt es in den Grafikspeicher. Wenn der Nutzer tippt, wird der Text in Tokens (Wortfragmente) zerlegt, die Berechnungen laufen über WebGPU auf der GPU, und die erzeugten Tokens werden zu Sätzen zusammengesetzt. Ein Detail, das oft übersehen wird: WebGPU selbst lädt nichts herunter und speichert nichts; es führt ausschließlich die Berechnung aus. Den Rest erledigen die üblichen Netzwerk- und Speicherschnittstellen des Browsers.
JavaScript-Bibliotheken fügen die Bausteine zusammen. WebLLM, entstanden im MLC-Projekt, bietet eine Schnittstelle ähnlich jener der OpenAI-APIs und nutzt WebGPU für die Grafikkarte sowie WebAssembly für CPU-Aufgaben. Transformers.js stützt sich auf ONNX Runtime, und wllama bringt die Modelle von llama.cpp in den Browser – ursprunglich für CPU entwickelt und heute mit einem WebGPU-Backend ausgestattet. Der bereits zitierte web.dev-Beitrag bestätigt, dass ONNX Runtime und Transformers.js WebGPU für die lokale Inferenz nutzen.
Innerhalb der Berechnung unterscheiden sich zwei Phasen, und der Unterschied ist wesentlich. Im Prefill liest das Modell den gesamten Prompt auf einmal ein, wobei Matrizenmultiplikationen dominieren. Im Decode erzeugt es ein Token nach dem anderen, und die Arbeit verlagert sich auf die Multiplikation von Matrizen mit Vektoren. Die Messungen des Preprints auf einem Apple M3 mit einem 1-Milliarden-Parameter-Modell, komprimiert auf 4 Bit, zeigen, dass Erstere 92,6 Prozent der Prefill-Zeit ausmachen und Letztere 89,9 Prozent des Decode. Das Decode ist zudem vor allem durch die Geschwindigkeit begrenzt, mit der die Gewichte aus dem Speicher gelesen werden – weshalb Komprimierung hilft: Es müssen weniger Bytes bewegt werden.
Hier liegt der Unterschied zwischen Zugang und Leistung. WebGPU, so der Preprint, bietet funktionale Portabilität, aber keine Leistungsportabilität: Derselbe Code läuft überall, aber nicht überall gleich schnell. Es braucht komprimierte Gewichte, für jede GPU-Familie sorgfältig geschriebene Berechnungen und eine umsichtige Speicherverwaltung. Beim ersten Start fällt zudem ein einmaliger Aufwand an: die Kompilierung der Programme für die GPU, die die Autoren auf eine bis fünf Sekunden schätzen.
Wo die Gewichte bleiben
Nach dem Download verschwinden die Gewichte keineswegs. Die Chrome-Anleitung zur Modellspeicherung erinnert daran, wie sperrig sie sind: Eine 1,35 Gigabyte große Datei, etwa eine komprimierte Version von Gemma 2B, gilt für ein Sprachmodell als winzig. Um sie auf dem Gerät zu halten, gibt es drei Wege: die Cache API, das Origin Private File System und IndexedDB. Das Chrome-Team empfiehlt im Allgemeinen den ersten und hält IndexedDB für die schlechteste Wahl bei großen Dateien.
Es handelt sich also nicht um eine Datei, die man in einem gewöhnlichen Ordner sucht. Das Origin Private File System ist laut derselben Anleitung für die Website privat und für den Nutzer unsichtbar. Das bedeutet nicht, dass der Inhalt ein exotisches Format nutzt: wllama speichert in diesem Bereich beispielsweise Dateien im GGUF-Format von llama.cpp, wie der Preprint berichtet. Man sieht sie lediglich nicht im Dateimanager des Betriebssystems.
Das Schließen des Tabs gibt den System- und Videospeicher frei, aber die Dateien bleiben auf der Festplatte. Das Schließen des Browsers ändert nichts: Beim nächsten Besuch kann die Website das Modell direkt aus der lokalen Kopie laden. Gelöscht werden sie nur über die Browser-Einstellungen oder vom Browser selbst, wenn die Seite keine dauerhafte Speicherung beantragt hat und der Speicherplatz knapp wird.
Jede Website besitzt ihren eigenen isolierten Bereich. Die FAQ von webllm.io – ein unabhängiges Entwicklungskit, das auf der MLC-Engine aufbaut und nicht mit dem ursprünglichen Projekt verwechselt werden darf – stellen klar, dass Modelle pro Ursprung isoliert sind, für andere Seiten unzugänglich und über Einstellungen löschbar, mit Downloads zwischen 1,5 und 4,5 Gigabyte je nach Leistungsfähigkeit des Geräts. Daraus folgt, dass dasselbe Modell, wenn es von zwei verschiedenen Seiten heruntergeladen wird, doppelt Speicherplatz belegen kann. Der Browser ähnelt Miyazakis wandelndem Schloss: ein Gebäude, das umhergeht und viele Türen mit sich führt, von denen jede in einen anderen Ort führt und ein eigenes Schloss besitzt.
Wer die Rechnung zahlt
Damit kommen wir zum ökonomischen Knotenpunkt. Wenn die Inferenz auf dem Gerät stattfindet, stellt der Anbieter das Modell als statische Datei bereit und überlässt Strom, Wärme und Rechenzeit dem Besucher. Das ist eine logische Folgerung und keine direkte Messung, aber sie steht auf solidem Grund: Jede lokale Sitzung ist eine Sitzung weniger, die über gemietete Cloud-GPUs abgerechnet wird. Die Autoren des Preprints merken an, dass die lokale Ausführung Latenz und Energieeffizienz verbessern kann, und zitieren Studien Dritter – was die Frage offen lässt, die hier niemand beantwortet: Verbessert sich die Gesamtbilanz zwischen wenigen Rechenzentren und Millionen Laptops wirklich?
Der Server verschwindet jedoch nicht. Er bleibt Eigentümer der Seite, der Konten, der Updates und der Modelldateien – und diese Dateien wiegen schwer: Die Bandbreitenkosten für die Auslieferung mehrerer Gigabytes an jeden neuen Besucher lösen sich nicht in Luft auf, sondern verlagern sich von der Berechnung auf die Übertragung. Nicht ohne Grund beschreibt die Dokumentation von webllm.io eine hybride Architektur mit Cloud-Fallback, wenn WebGPU fehlt oder die Grafikkarte nicht ausreicht. Derselbe Text warnt, dass die lokale Ausführung Isolations-Header (COOP und COEP) erfordert, da sie geteilten Speicher nutzt: eine Konfigurationsanforderung an den Server, die Auswirkungen auf auf der Seite eingebundene externe Ressourcen haben kann.
Wer gewinnt also und wer verliert? Das sind Szenarien, keine Gewissheiten. Es gewinnen Anbieter schlanker Dienste, die ihre Cloud-Rechnung senken, Nutzer mit einer guten Grafikkarte, die sofortige Antworten und lokale Datensicherheit erhalten, und GPU-Hersteller, für die Grafikspeicher zum Verkaufsargument wird. Es verlieren Nutzer mit veralteter Hardware, die auf Cloud-Fallbacks oder eine langsame Erfahrung angewiesen sind, sowie Anbieter von Grafik-Infrastruktur, die von leichter Inferenz leben.
Grenzen schwarz auf weiß
Die vollständigsten heute verfügbaren empirischen Daten stammen aus dem Preprint Llamas on the Web, der im Mai 2026 von einer Gruppe der University of California in Santa Cruz zusammen mit einem Koautor von Microsoft Research auf arXiv veröffentlicht wurde. Er muss mit zwei Vorsichtsmaßregeln gelesen werden: Er durchlief noch kein Peer-Review, und die Autoren sind dieselben, die das WebGPU-Backend von llama.cpp geschrieben haben – sie messen also auch ihre eigene Arbeit. Der Umfang ist jedoch beträchtlich: sechzehn Geräte von acht Herstellern, zehn Modelle, etwa fünfundzwanzig Stunden automatisierte Tests.
Das erste Ergebnis bremst übertriebene Erwartungen. Gegenüber den nativen Backends von llama.cpp fällt WebGPU auf dedizierter Hardware deutlich zurück: Natives CUDA und Vulkan übertreffen es im Prefill um das bis zu 10-Fache und im Decode um das 2,5-Fache, dank Tensor-Cores und herstellerspezifischer Matrizenfunktionen. Auf Apple Silicon liegt natives Metal im Prefill um mehr als das Doppelte und im Decode um 50 Prozent vorne. Aber das Bild ist nicht einseitig: Auf dem Mac übertrifft WebGPU das über MoltenVK übersetzte Vulkan im Prefill um bis zu 59 Prozent und im Decode um 45 Prozent; und auf einer AMD-Karte hinkt natives Vulkan im Prefill um das Dreifache hinter WebGPU hinterher, obwohl es natives HIP im Decode schlägt. Auf Intel-GPUs übertrifft WebGPU SYCL im Prefill um 23 Prozent, allerdings nur bei deaktivierten Sicherheitsprüfungen – ein Zustand, der beim echten Surfen nicht existiert.
Diese Sicherheitsprüfungen haben ihren Preis. WebGPU-Kompilierer bauen Überprüfungen gegen Speicherzugriffe außerhalb der Grenzen und Divisionen durch Null ein. Schaltet man sie versuchsweise ab, zeigt sich ein durchschnittlicher Leistungseinbuße von 14 Prozent im Prefill bei komprimierten Modellen und 23 Prozent bei voller Präzision (bis zu 42 Prozent auf einer RTX 5080), während der Effekt im Decode zwischen 1 und 5 Prozent liegt. Das ist der Preis der Sandbox: Eine Webseite darf niemals Speicher außerhalb ihres Bereichs lesen können.
Auf der anderen Seite steht WebLLM. Dessen Paper behauptet, bis zu 80 Prozent der nativen Leistung halten zu können, während der MLC-Blog von bis zu 85 Prozent gegenüber Metal auf einem MacBook Pro M3 Max spricht, wenn beide Engines mit demselben Tool kompiliert werden. Sie widersprechen dem Santa-Cruz-Preprint nicht zwingend: Sie messen gegenüber unterschiedlichen Referenzen und müssen mit Vorsicht verglichen werden.
Unter den Browser-Runtimes fällt der Vergleich des Preprints für die Konkurrenz schlechter aus als für die Autoren selbst. Ihre Implementierung generiert Text im Decode auf vier GPUs verschiedener Hersteller um 45 bis 69 Prozent schneller und nutzt 29 bis 33 Prozent weniger Speicher. Im Prefill bleibt sie jedoch zurück (21 bis 51 Prozent langsamer), weil die schnellsten Matrizenbefehle, sogenannte Subgroup Matrix-Operationen, in den stabilen Browser-Versionen noch nicht freigeschaltet sind. Für WebLLM und Transformers.js melden die Autoren zudem Speicher-Peaks nahe 10 Gigabyte in manchen Konfigurationen, die sie auf mögliche Speicherlecks zurückführen.
Bei Smartphones ist der Rahmen enger. Auf einem iPhone steht einem Safari-Tab weniger als 500 Megabyte nutzbarer Speicher zur Verfügung, und schwächere GPU-Modelle unter iOS und Android konnten nur die vier kleinsten Testmodelle ausführen, mit 4 bis 17 Tokens pro Sekunde im Decode. Auf Highend-Mobil-GPUs übertreffen kleine Modelle 3.000 Tokens pro Sekunde im Prefill und 100 im Decode, während das größte getestete Modell (ein Gemma 4 mit etwa 3 Gigabyte) auf 65 und 30 abfällt.
Auch die Browserwahl wiegt schwer. Auf einem Mac mit M3-Chip läuft dasselbe Modell mit ~1 Token pro Sekunde auf Firefox gegenüber ~52 Tokens pro Sekunde auf Chrome; die Autoren haben Firefox aus den Hauptmessungen deshalb ausgeschlossen. Das ist ein Einzelwert und kein Gesetz, zeigt aber, dass „unterstützt WebGPU“ und „läuft so schnell wie Chrome“ zwei verschiedene Aussagen sind.
Schließlich die Grenzen der Sprache WGSL. WGSL beherrscht noch keine nativen Formate für bf16, int8, int16 oder int4, die moderne GPUs direkt ausführen, weshalb sie emuliert werden müssen. Daraus entsteht ein im Preprint dokumentierter unanschaulicher Effekt: In WebGPU dient das Komprimieren der Gewichte vor allem dazu, das Modell in den Speicher zu bekommen, nicht aber, es zu beschleunigen – der Schritt von 4 auf 2 Bit verringert auf Mittelklasse-Hardware die Decode-Geschwindigkeit sogar um 17 Prozent.
Datenschutz mit Vorbehalt
Der am häufigsten genannte Vorteil ist der Datenschutz – real, aber an Bedingungen geknüpft. Es lohnt sich, drei Aussagen zu trennen, die in Werbemitteilungen oft verschmelzen. Die erste ist, dass die Berechnung lokal erfolgt: Das garantiert WebGPU vollkommen. Die zweite ist, dass die Webanwendung keine Prompts, Antworten oder Telemetrie an Dritte sendet: Das hängt vom Seitenbetreiber ab, nicht von der API. Die Dokumentation von webllm.io versichert beispielsweise, dass im rein lokalen Modus keinerlei Daten übertragen werden, aber im selben Produkt koexistiert der Cloud-Fallback-Modus, womit der Datenschutz von der Konfiguration abhängt. Wenn Eingaben an Such-, Moderations- oder Protokollierungsdienste weitergeleitet werden, lösen sich lokale Garantien auf.
Die dritte ist, dass das Modell selbst vor Extraktion geschützt sei: Hier lautet die Antwort Nein. Die Chrome-Anleitung warnt, dass in der Cache API oder OPFS gespeicherte Gewichte über die Entwicklerwerkzeuge des Browsers mühelos ausgelesen werden können, und eine Verschlüsselung hilft nicht, da der Schlüssel zwangsläufig das Gerät erreichen muss. Wer ein proprietäres Modell schützen muss, sollte es auf dem Server belassen.
Browser oder nativ?
Wo liegt also der Nutzen? Das hängt vom Ziel ab, wie die folgende Tabelle zusammenfasst.
Beide Wege nähern sich unterdessen an: Das WebGPU-Backend von llama.cpp fand über mehr als hundert Beiträge der Community Eingang in das Hauptprojekt und bringt GGUF-Modelle nativer Apps direkt in den Browser. Auch die Webstandards entwickeln sich weiter: Khronos-Updates verweisen auf Subgroup-Erweiterungen in Chrome 144 und 145, die sich von den später erwarteten Matrizenbefehlen unterscheiden. Einen anderen Weg gehen die integrierten KI-APIs von Chrome (Prompt, Summarizer, Translator), die in der offiziellen Dokumentation beschrieben sind: Modelle, die der Browser selbst den Webseiten bereitstellt, statt dass jede Seite eigene Gewichte ausliefert. Wie dieser Pfad mit WebGPU koexistieren wird, bleibt eine offene Frage.
Ihr PC als Ihr Server
Die erste Schlussfolgerung fällt bescheiden aus: Wer maximale Geschwindigkeit, riesige Modelle und absolute Kontrolle sucht, für den ersetzt WebGPU weder llama.cpp noch LM Studio. Die Zahlen belegen, dass native Backends im Prefill um bis zu Faktor 10 führen und Smartphones nur Zwergmodelle verkraften. Die zweite Schlussfolgerung ist ungleich spannender: Zum ersten Mal können die wichtigsten Browser direkt mit der GPU sprechen, was ein neues Distributionsmodell plausibel macht – eine URL, ein einmaliger Modell-Download und eine Berechnung, die vollständig auf dem Rechner des Nutzers ausgeführt wird.
Es bleiben Herausforderungen: die Fragmentierung zwischen Browsern und Treibern, der Overhead der Sandbox, die Verfügbarkeit von Subgroup-Matrix-Befehlen in stabilen Versionen und die Energiebilanz von Millionen kleiner Client-GPUs anstelle weniger Rechenzentren. Man kann es auf eine Formel bringen: WebGPU macht den Browser nicht zu einem KI-Server – es macht ihn zu einer sicheren Sandbox, in der Ihr eigener Computer zum Server Ihrer KI werden kann.
Technischer Hinweis: Leistungsdaten stammen aus einem noch nicht begutachteten Preprint mit Stand Mai 2026. Browser- und Runtime-Versionen verändern sich rasch; Zahlen sollten vor der Verwendung in Produktionsumgebungen erneut geprüft werden.