KI im Browser 2026: Modelle mit WebGPU und LiteRT.js on-device ausführen

Jahrelang bedeutete „KI im Browser“ eine von zwei Sachen: eine langsame Demo, die den Laptop-Lüfter aufheulen ließ, oder ein fetch()-Aufruf an den Server von jemand anderem. Das Modell lief nie wirklich auf der Seite — es lief in einem Rechenzentrum, und die Daten der Nutzer gingen mit.

Das änderte sich 2026. Browser liefern jetzt eine GPU-API, die reif genug für echte Inferenz ist, und am 9. Juli 2026 veröffentlichte Google LiteRT.js, ein Runtime, das genau darauf aufbaut. Kombiniert man beides, lassen sich echte Modelle — Objekterkennung, Audio-Verarbeitung, Tiefenschätzung — vollständig auf dem Gerät des Nutzers ausführen, ganz ohne Server dazwischen.

Das ist ein praktischer Blick darauf, was „KI im Browser“ heute wirklich bedeutet: was es schnell gemacht hat, wie LiteRT.js funktioniert und — ehrlich — wann du es einsetzen solltest und wann nicht.

Warum On-Device-Inferenz plötzlich zählt

Ein Modell im Browser statt auf einem Server auszuführen ist kein Partytrick. Es bringt dir drei Dinge, die eine gehostete API grundsätzlich nicht kann:

• Privacy durch Architektur. Die Eingabe — ein Foto, ein Sprach-Clip, ein Dokument — verlässt das Gerät nie. Kein Upload, kein Log, kein auszuhandelnder Auftragsverarbeitungsvertrag. Für alles, was personenbezogene Daten berührt, ist das eine Compliance-Geschichte, die du anders nicht bekommst.
• Extrem niedrige Latenz. Kein Netzwerk-Round-Trip heißt, Vorhersagen landen in Millisekunden. Echtzeit-Anwendungen — Live-Objektverfolgung, Webcam-Effekte, spontane Transkription — funktionieren nur mit lokaler Inferenz.
• Null Serverkosten. Die Hardware des Nutzers erledigt die Arbeit. Du lieferst eine Modelldatei einmal vom CDN und zahlst nichts pro Inferenz. Keine GPU-Flotte, kein Autoscaling, keine mit der Nutzung wachsende Rechnung.

Der Haken war bis vor Kurzem die Geschwindigkeit. JavaScript-ML-Runtimes waren langsam, weil sie auf JavaScript-basierten Kerneln liefen. Das ist die Wand, die 2026 endlich durchbrochen wurde.

Der Durchbruch: WebGPU

Das wichtigste Puzzleteil ist WebGPU — die moderne Browser-API, die JavaScript Low-Level-Zugriff direkt auf die GPU gibt. Sie ersetzt den alternden WebGL-Pfad durch etwas, das für General-Purpose-Compute entworfen wurde — genau das, was ML-Inferenz braucht.

Warum das alles ändert: Ein Modell über die GPU statt die CPU zu leiten, liefert in Googles eigenen Benchmarks einen 5-60x Speedup für anspruchsvolle Echtzeit-Aufgaben. Ein Tiefenschätzungs-Modell, das auf der CPU ruckelt, läuft auf der GPU flüssig. Und webgpu gehört zu den seltenen Themen mit echter, steigender Suchnachfrage und noch fast keiner ernsthaften Konkurrenz — ein Zeichen, dass das Ökosystem noch jung ist.

Für neuere Hardware gibt es eine dritte Stufe: Die WebNN-API (experimentell in Chrome und Edge) adressiert dedizierte NPUs — die neuronalen Beschleuniger, die jetzt in Laptops und Smartphones stecken — für energieeffiziente Inferenz mit ultraniedriger Latenz.

Die Hardware-Leiter im Browser sieht damit jetzt so aus:

WebGPU ist die API. Du brauchst trotzdem ein Runtime, das sie ansteuern kann. Genau hier kommt LiteRT.js ins Spiel.

Was LiteRT.js genau ist

LiteRT.js ist ein JavaScript-Binding von LiteRT — Googles bewährter On-Device-Inferenz-Bibliothek, dasselbe Runtime, das ML auf Android, iOS und Desktop antreibt. Es führt .tflite-Modelle über WebAssembly direkt im Browser aus und stellt dieses native, plattformübergreifende Runtime — mit all seinen CPU-, GPU- und NPU-Optimierungen — zum ersten Mal Web-Entwicklern zur Verfügung.

Die zentralen Aussagen zum Launch:

• Bis zu 3x schneller als bestehende Web-Runtimes bei CPU- und GPU-Inferenz.
• Ein einheitlicher Stack mit LiteRT auf Mobile und Desktop, sodass deine Web-App künftige Quantisierungs- und Hardware-Verbesserungen automatisch erbt.
• Native Beschleunigung über CPU (XNNPACK), GPU (ML Drift/WebGPU) und NPU (WebNN).

Wenn du je TensorFlow.js genutzt hast, ist das die wichtige Einordnung: Google positioniert LiteRT.js als die Performance-Evolution von TensorFlow.js für das Ausführen von .tflite-Modellen. Wo TF.js auf JavaScript-Kernel setzte, gibt dir LiteRT.js das native Runtime. Bestehende TF.js-Nutzer können .tflite-Inferenz sogar über LiteRT.js in ihren aktuellen Pipelines laufen lassen.

Neu darin, Modelle gegen Live-Daten laufen zu lassen? Dieselbe On-Device-Denke gilt auch serverseitig — siehe eine Echtzeit-RAG-Pipeline in Python bauen für die Retrieval-Hälfte moderner KI-Apps.

Ein Modell zum Laufen bringen

Zwei Wege bringen ein Modell in LiteRT.js.

Wenn du bereits ein .tflite-Modell hast, lädst und führst du es direkt aus. Die API ist klein — Runtime initialisieren, Modell gegen einen Beschleuniger kompilieren, Tensor einspeisen, Ergebnis lesen:

import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';

// 1. WebAssembly-Runtime initialisieren.
await loadLiteRt('path/to/wasm/directory/');

// 2. Modell gegen die GPU via WebGPU kompilieren.
const model = await loadAndCompile('path/to/your/model.tflite', {
  accelerator: 'webgpu',
});

// 3. Input-Tensor bauen (hier: ein 1×3×224×224 Bild-Batch).
const inputTypedArray = new Float32Array(1 * 3 * 224 * 224);
const inputTensor = new Tensor(inputTypedArray, [1, 3, 224, 224]);

// 4. Inferenz ausführen. Das Ergebnis liegt auf der GPU…
const results = await model.run(inputTensor);

// …also in den CPU-Speicher verschieben, um die Werte auszulesen.
const resultArray = (await results[0].moveTo('wasm')).toTypedArray();

Installiere es via npm mit @litertjs/core. Vortrainierte .tflite-Modelle gibt es auf Kaggle und in der LiteRT-Hugging-Face-Community.

Wenn dein Modell in PyTorch vorliegt, konvertiere es in einem Schritt mit LiteRT Torch, das ein PyTorch-Modell nach .tflite überführt. Für zusätzliche Einsparungen erlaubt dir der AI Edge Quantizer, maßgeschneiderte Quantisierung pro Layer anzuwenden — spürbare Größen- und Geschwindigkeitsgewinne bei erhaltener Qualität.

Was Leute bereits bauen

Der Launch kam mit echten Demos, nicht mit Spielzeug-Beispielen — ein gutes Signal, was das Runtime heute leisten kann:

• Objekterkennung — offizieller Ultralytics-YOLO-Export nach LiteRT, YOLO26 läuft im Browser.
• Tiefenschätzung — ein Live-Webcam-Feed wird mit Depth-Anything-V2 in Echtzeit zu einer interaktiven 3D-Punktwolke, via WebGPU.
• Bild-Upscaling — 4x-Upscaling im Browser mit Real-ESRGAN.
• Vektorsuche — semantische Suche vollständig client-seitig mit EmbeddingGemma.

Und die Roadmap zielt auf die naheliegende nächste Grenze: LiteRT-LM.js bringt Browser-Support für LLMs — und dort wird generative KI on-device wirklich spannend.

Wann KI im Browser die falsche Wahl ist

Ehrlich zu sein ist nützlicher, als Cheerleader zu spielen. On-Device-Inferenz ist in drei Fällen ein schlechter Default:

1. Das Modell ist zu groß. Wenn es nicht bequem laden und im Browser-Speicher liegen kann, ist der Client das falsche Zuhause. Sehr große Sprachmodelle gehören weiter auf einen Server. Und denk daran: Das Modell ist nur die Hälfte der Payload — jedes Kilobyte JavaScript konkurriert damit, also zählt ein schlankes Bundle auf dem Client genauso.
2. Du brauchst zentrale Kontrolle. Wenn das Verhalten des Modells eine einzige, verwaltete Single Source of Truth sein muss — auditiert, rate-limitiert, sofort für alle aktualisiert — ist serverseitige Inferenz leichter beherrschbar.
3. Die Client-Hardware ist zu schwach. Nicht jeder Nutzer hat eine WebGPU-fähige GPU oder eine NPU. Plane immer einen CPU-Fallback ein und miss auf echten schwachen Geräten, nicht nur auf deinem M4-MacBook.

KI im Browser gewinnt klar bei kleinen bis mittleren Modellen, wo Privacy, Latenz oder Kosten Priorität haben — Vision, Audio, Embeddings, interaktive Effekte. Das ist ein großer und wachsender Teil realer Anwendungen.

Das Fazit

Die Geschichte von 2026 ist, dass KI im Browser aufgehört hat, eine Demo zu sein. WebGPU machte die Hardware aus JavaScript erreichbar, und LiteRT.js machte Googles natives Runtime im Web nutzbar — bis zu 3x schneller als bisher, mit einem sauberen Migrationspfad von TensorFlow.js. Wenn du fürs Web baust und bisher Nutzerdaten an einen Server geschickt hast, nur um ein kleines Modell auszuführen, lohnt die Frage, ob dieses Modell jetzt aufs Gerät gehört.

Starte mit der LiteRT.js-Dokumentation, schnapp dir ein .tflite-Modell und führe deine erste Inferenz dort aus, wo deine Nutzer wirklich sind — im Browser.