LLMs im Browser mit WebAssembly und WebGPU ausführen

Sie öffnen eine Webseite – ohne Installation, ohne Konto und ohne Verbindung zu irgendeinem KI-Server – und chatten mit einem Bot, dessen Antworten komplett auf Ihrem eigenen Laptop entstehen. Nichts verlässt Ihren Rechner, es gibt keine API-Rechnung, und Sie können das Netzwerkkabel direkt nach dem Laden der Seite ziehen, ohne dass der Chatbot es merkt.

Das ist keine Vision für in fünf Jahren. Es läuft schon heute, im selben Tab, in dem Sie Ihre E-Mails lesen. Zwei Technologien machen das möglich, und meist werden sie getrennt besprochen, obwohl sie gemeinsam am stärksten sind: WebAssembly und WebGPU.

Wer den Großteil seiner Tage mit JavaScript verbringt, verbindet diese Namen vielleicht mit Game-Engines oder hält sie für ein Thema des Grafikteams. Tatsächlich verändern sie, was ein Browser ist: Aus einem Seiten-Renderer wird eine Plattform für echte Berechnungen und zunehmend auch für lokale KI-Inferenz.

Warum JavaScript Unterstützung braucht

JavaScript ist gut in dem, wofür es gebaut wurde: DOM-Arbeit, Event-Handling und Anwendungslogik. Geben Sie ihm etwas wirklich Schweres – Videodekodierung, Bildverarbeitung, Physiksimulation oder ein neuronales Netz –, und die Risse werden sichtbar. Garbage Collection und dynamische Typisierung machen die Sprache angenehm zu schreiben, schaden aber, wenn jede Millisekunde CPU-Zeit zählt.

Die übliche Antwort war früher, die schwere Arbeit auf einen Server auszulagern. Bild hochladen, entfernt verarbeiten, Ergebnis herunterladen. Dieses Muster hat seinen Preis. Die Serverkosten wachsen mit jedem neuen Nutzer, die Netzwerklatenz macht die Oberfläche träge, und die Daten der Nutzer müssen ihr Gerät verlassen – ein Datenschutzproblem für sich.

WebAssembly und WebGPU ersetzen JavaScript nicht. Sie geben dem Browser Kraft, die er nie hatte.

WebAssembly in Kürze

Wasm, kurz für WebAssembly, definiert ein kompaktes Binärformat, das von einer stackbasierten virtuellen Maschine ausgeführt wird. Die Idee: Hochsprachen bekommen ein portables Kompilierziel, damit Webanwendungen an native Geschwindigkeit herankommen.

Gedacht war es nie nur fürs Web. Es läuft in einer speichersicheren Sandbox und hält sich in einer Seite eingebettet an die Same-Origin-Regeln des Browsers, kann aber auch in Umgebungen laufen, die mit dem Web nichts zu tun haben.

In der Praxis sieht der Ablauf so aus:

• Sie starten mit C, C++, Rust oder einer anderen Sprache, für die es einen Wasm-fähigen Compiler gibt.
• Daraus wird eine .wasm-Datei – binärer Bytecode statt JavaScript, deutlich näher an Maschinensprache.
• Der Browser führt diesen Bytecode in seiner eigenen Sandbox aus, schneller, als JIT-kompiliertes JavaScript es schafft.
• Wasm ruft JavaScript auf und umgekehrt, Sie schreiben also nicht die ganze App neu, sondern verlagern nur die schweren Teile.

Figma nutzt Wasm für seine Rendering-Engine – ein wichtiger Grund, warum sich Design-Bearbeitung im Browser so flüssig anfühlt wie in einer Desktop-App. Auch die Webversion von Google Earth läuft damit, und mehrere Game-Engines auf AAA-Niveau können direkt nach Wasm exportieren.

Merken sollten Sie sich: Wasm ist für Berechnung zuständig. Es macht schwere Logik schnell, gibt Ihnen aber keinen direkten GPU-Zugriff. Für massive Parallelität und Grafik braucht es einen weiteren Partner.

WebGPU, der Nachfolger von WebGL

Wenn Sie WebGL kennen: WebGPU ist sein Nachfolger, und zwar mehr als ein inkrementelles Upgrade. Es wurde von Grund auf so entworfen, dass es auf moderne GPU-APIs wie Vulkan, Metal und Direct3D 12 abbildet. WebGL dagegen ist ein Wrapper um das in die Jahre gekommene OpenGL ES.

Laut MDN-Dokumentation ermöglicht die API Webentwicklern, die GPU des Systems für Hochleistungsberechnungen und für das Rendern komplexer Grafik im Browser zu nutzen. Die Unterschiede zu WebGL reichen tief:

• WebGL war auf das Zeichnen in ein Canvas ausgelegt und kam mit allgemeinen GPU-Berechnungen (GPGPU) nie gut zurecht.
• Bei WebGPU sind Compute-Shader vollwertiger Bestandteil statt nachträglich angeflanscht.
• Es bietet Low-Level-Kontrolle über Konzepte wie GPUAdapter, GPUDevice und GPUQueue und ist damit viel näher an nativen Grafik-APIs.
• Weil es direkt auf moderne GPU-APIs abbildet, ist der Overhead weit geringer als bei WebGL, das alles durch eine alte OpenGL-Schicht übersetzt.

Praktisch heißt das: Eine GPU, die früher nur 3D-Szenen in Browserspielen gerendert hat, kann nun viel mehr leisten – kleine Modelle trainieren, Inferenz neuronaler Netze ausführen, Bilder parallel verarbeiten und große Physiksimulationen berechnen, alles über Compute-Shader im Browser.

Zwei Schichten, die zusammenpassen

Leicht übersehen wird, dass Wasm und WebGPU keine Konkurrenten sind. Sie ergänzen sich.

• Wasm übernimmt die Orchestrierung und schwere Logik auf der CPU. Dazu gehören Modell-Parsing, Tokenisierung, Speicherverwaltung und all der komplexe Code, den Machine-Learning-Tools meist in C++ oder Rust schreiben.
• WebGPU übernimmt die massiv parallele Ausführung. Das sind die großen Matrixoperationen im Kern jedes neuronalen Netzes, die allein auf der CPU kriechen würden.

Gemeinsam machen sie ein LLM im Browser-Tab technisch machbar. Ohne WebGPU wäre das Modell auf der CPU quälend langsam. Ohne Wasm ließe sich die Laufzeitlogik in reinem JavaScript kaum optimieren.

WebLLM als funktionierendes Beispiel

Eine der anschaulichsten Demonstrationen ist WebLLM vom Team MLC AI. Es ist eine LLM-Inferenz-Engine im Browser, beschleunigt durch WebGPU, ganz ohne Server. Außerdem ist sie vollständig kompatibel mit dem OpenAI-API-Format: Wenn Sie bereits chat.completions aufrufen, gibt es kaum etwas Neues zu lernen. Vereinfacht sieht die Nutzung so aus:

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

// Callback to track model download & loading progress
const initProgressCallback = (progress) => {
  console.log(progress.text);
};

// A small model already compiled into MLC format
const selectedModel = "Llama-3-8B-Instruct-q4f32_1-MLC";
async function main() {
  const engine = await CreateMLCEngine(selectedModel, {
    initProgressCallback,
  });
  const reply = await engine.chat.completions.create({
    messages: [
      { role: "user", content: "Explain WebGPU in one sentence" },
    ],
  });
  console.log(reply.choices[0].message.content);
}

main();

Das passiert hinter den Kulissen:

• CreateMLCEngine lädt die bereits komprimierten und quantisierten Modellgewichte sowie die Wasm-Bibliothek mit der Inferenzlogik herunter.
• Die Wasm-Schicht übernimmt die Tokenisierung, verwaltet den Gesprächskontext und orchestriert den gesamten Inferenzprozess.
• Die schweren Matrixoperationen im Herzen jedes Forward-Passes laufen als WebGPU-Compute-Shader und nutzen die Parallelität der GPU Ihres Geräts.
• Alles bleibt in der Browser-Sandbox, kein Prompt und keine Nutzerdaten verlassen das Gerät.

Sie bekommen einen Chatbot, der standardmäßig privat ist, nach dem Caching des Modells offline funktioniert und keinen Server belastet, für den Sie sonst zahlen müssten. Indie-Entwickler und kleine Teams können KI-Features ausliefern, ohne dass eine Cloud-GPU-Rechnung mit dem Traffic explodiert.

Mehr als Sprachmodelle

Wasm plus WebGPU reicht weit über LLMs hinaus. Einige weitere Bereiche nutzen die Kombination bereits:

• Bild- und Videobearbeitung: komplexe Filter, Hintergrundentfernung und Upscaling, die früher einen Umweg über den Server brauchten, laufen jetzt in Echtzeit auf dem Client.
• Computer Vision: Objekterkennung oder Gesichtserkennung direkt aus dem Kamerabild, ohne dass ein Videostream das Gerät verlässt.
• Interaktive Data Science: aufwendige numerische Berechnungen im NumPy-Stil direkt in Browser-Notebooks.
• 3D-Spiele und Simulationen: Unity und Unreal bauen beide WebGPU-Export aus, wodurch das Rendering im Browser deutlich näher an native Builds heranrückt.
• Browserbasiertes CAD und 3D-Design: komplexe 3D-Modelle bearbeiten, ganz ohne Desktop-Software.

Grenzen, die Sie einplanen sollten

Bevor Sie jedes KI-Backend auf den Client verlagern, behalten Sie diese Einschränkungen im Blick:

• Die Browserunterstützung ist nicht flächendeckend. WebGPU ist in Chrome, Edge und aktuellen Safari-Versionen standardmäßig aktiv, in Firefox aber noch experimentell und muss per Flag eingeschaltet werden.
• Der erste Download kann groß sein. Auch ein kleines Modell muss erst in den Browser des Nutzers gelangen. Gestalten Sie den ersten Start daher sorgfältig, meist mit einer klaren Fortschrittsanzeige.
• Die Hardware bestimmt weiterhin die Leistung. Ein Büro-Laptop mit integrierter Grafik kommt an eine starke dedizierte GPU nicht heran. Wählen Sie das Modell passend zu Ihrem tatsächlichen Publikum.
• Debugging verändert sich. Sie jagen keine Fehler mehr in Serverlogik, die Sie kontrollieren, sondern debuggen Code, der auf einer breiten, unberechenbaren Palette von Client-Geräten läuft.

Nichts davon ist ein Grund, die Technologie zu meiden. Es erinnert nur daran, dass auch Client-seitige Ausführung eine durchdachte Architektur braucht.

Warum dieser Schwung anders wirkt

Viele Webtrends verblassen, doch hier ziehen fast alle großen Browserhersteller an einem Strang. Google, Apple, Microsoft und Mozilla entwickeln diese Standards gemeinsam im W3C – es ist also keine Wette eines einzelnen Anbieters, die still und leise fallen gelassen werden könnte.

Die Grenze zwischen Web-App und nativer App verschwimmt weiter. Ein Browser, der einst nur Dokumente anzeigte, bewältigt heute ernsthafte Berechnungen und sogar KI-Inferenz – ohne Installation, ohne zusätzlichen Server und mit spürbar besserem Datenschutz, weil Nutzerdaten das Gerät nie verlassen müssen.

Wenn Sie Wasm und WebGPU bisher als Nischenthema für Grafik abgetan haben, probieren Sie ein kleines Experiment. Laden Sie in einem Nebenprojekt ein kompaktes Modell über WebLLM und erleben Sie, wie es sich anfühlt, wenn KI in Ihren eigenen Händen läuft statt auf dem Server eines anderen. Für die nächsten Schritte: Der Code liegt im WebLLM-Repo, der Standard selbst auf webassembly.org, und als Referenz dient die WebGPU-API-Seite auf MDN.