---
title: "KI im Browser 2026: Modelle mit WebGPU und LiteRT.js on-device ausführen"
description: "KI-Modelle direkt im Browser auszuführen ist endlich schnell genug, um real zu sein. Ein praktischer Leitfaden 2026 für On-Device-Inferenz mit WebGPU und Googles neuem LiteRT.js — was sich geändert hat, wie es funktioniert und wann man es einsetzt."
author: Aleksei Aleinikov
date: 2026-07-10
lang: de
tags: [browser-ai, webgpu, litert-js, on-device-ai, edge-ai, tensorflow-js, web-machine-learning]
canonical: https://www.alekseialeinikov.com/de/blog/topics/ai/ki-im-browser-webgpu-litert-js-2026
source: alekseialeinikov.com
---

# 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**](https://developers.google.com/edge/litert/web), 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.

![KI-Modelle on-device im Browser ausführen mit WebGPU und LiteRT.js.](https://www.alekseialeinikov.com/blog/litert-js-browser-ai-2026.webp)

## 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.

![Server-Inferenz gegenüber On-Device-Inferenz im Browser mit LiteRT.js.](https://www.alekseialeinikov.com/blog/litert-js-server-vs-ondevice-2026.webp)

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:

| Backend | Angetrieben von | Am besten für |
|---|---|---|
| **CPU** | XNNPACK | Universeller Fallback, kleine Modelle |
| **GPU** | ML Drift via **WebGPU** | Echtzeit-Vision, Audio, die meisten Workloads |
| **NPU** | **WebNN** (experimentell) | Energieeffiziente Inferenz auf neuen Geräten |

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](https://developers.google.com/edge/litert/web) 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](https://developers.google.com/edge/litert/web) laufen lassen.

![LiteRT.js-Inferenz-Stack: deine Web-App ruft das Runtime auf, das an CPU-, GPU- oder NPU-Backends verteilt.](https://www.alekseialeinikov.com/blog/litert-js-inference-stack-2026.webp)

> Neu darin, Modelle gegen Live-Daten laufen zu lassen? Dieselbe On-Device-Denke gilt auch serverseitig — siehe [eine Echtzeit-RAG-Pipeline in Python bauen](https://www.alekseialeinikov.com/de/blog/topics/ai/echtzeit-rag-pipeline-python-bright-data-serp-api-2026) 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:

```js
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](https://www.kaggle.com/models?framework=tfLite) und in der [LiteRT-Hugging-Face-Community](https://huggingface.co/collections/litert-community/web-classical-models).

**Wenn dein Modell in PyTorch vorliegt**, konvertiere es in einem Schritt mit [LiteRT Torch](https://github.com/google-ai-edge/ai-edge-torch), das ein PyTorch-Modell nach `.tflite` überführt. Für zusätzliche Einsparungen erlaubt dir der [AI Edge Quantizer](https://github.com/google-ai-edge/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](https://docs.ultralytics.com/integrations/litert)-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**](https://github.com/google-ai-edge/LiteRT-LM) 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](https://www.alekseialeinikov.com/de/blog/topics/programming/es-toolkit-2026-die-lodash-alternative-2x-schneller-97-kleiner) 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](https://developers.google.com/edge/litert/web), schnapp dir ein `.tflite`-Modell und führe deine erste Inferenz dort aus, wo deine Nutzer wirklich sind — im Browser.