WebGPU und On-Device-KI: Der Browser wird zu einer ernstzunehmenden Laufzeitumgebung

Jahrelang war der Browser das nette Gesicht der Anwendung und die Cloud der Ort, an dem die schwierigen Dinge passierten. Der Benutzer schreibt, klickt, lädt eine Datei hoch; das Frontend sendet alles an den Server; Der Server ruft ein Modell auf. Die Antwort kommt zurück.

Dieses Schema bleibt sehr nützlich, aber es ist nicht kostenlos. Jeder Anruf bringt Fragen zu Latenz, Kosten, Netzwerkabhängigkeit und Datenschutz mit sich. Wenn der Benutzer einen Satz schreibt und eine Anregung möchte, wiegt eine halbe Sekunde. Wenn Sie Tausende kleiner Eingaben klassifizieren, werden Pennys zu echtem Geld. Wenn der Text vertraulich ist, ist das Versenden vom Gerät aus keine neutrale Entscheidung.

Deshalb sind WebGPU und On-Device AI im Hype. Nicht, weil wir morgen jedes Modell im Browser ausführen werden. Denn einige der intelligenten Funktionen können näher an den Benutzer heranrücken.

Nicht alles muss lokal werden

Die kindische Version des Arguments lautet: „Cloud versus Device“. Die nützliche Version ist Hybrid.

Einige Aufgaben sehen auf dem Gerät großartig aus: kurze Zusammenfassungen, Spracherkennung, leichte Umschreibungen, einfache Klassifizierungen, Bildfilter, kleine Visionsmodelle, kreative Erlebnisse mit sofortigem Feedback.

Andere Aufgaben bleiben in der Cloud besser: komplexe Argumentation, Grenzmodelle, serverseitige Daten, zentralisierte Prüfung, einheitliche Qualität, Arbeitsabläufe, bei denen Sie jeden Schritt sorgfältig kontrollieren müssen.

Die gesunde Architektur entscheidet zur Laufzeit:

Der Browser muss nicht gegen die Cloud gewinnen. Es muss die Cloud vor Arbeiten bewahren, die dort nicht erledigt werden müssen.

Warum WebGPU wichtig ist

WebGPU ist eine moderne API zur Nutzung der GPU aus dem Browser. Es geht nicht nur um schönere 3D-Grafiken. Dies ist auch wichtig, weil dadurch für die Datenverarbeitung geeignete Grundelemente verfügbar gemacht werden: parallele Workloads, Shader, Pipelines, die näher an dem liegen, was GPUs gut können.

Bei KI, wissenschaftlicher Visualisierung, 3D-Editoren, Videofiltern und kreativen Tools ist dieser Unterschied spürbar. WebGL hat viel für das Web getan, aber WebGPU wurde mit einem Modell geboren, das besser für die Gegenwart geeignet ist.

Das erste, was zu schreiben ist, ist jedoch kein Shader. Es ist eine nüchterne Merkmalserkennung:

export async function requestWebGpuDevice() {
  if (!('gpu' in navigator)) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter({
    powerPreference: 'high-performance',
  });

  if (!adapter) {
    return null;
  }

  return adapter.requestDevice();
}

Diese Funktion sagt etwas Wichtiges aus: WebGPU ist kein Recht, das auf jedem Gerät gewährt wird. Es ist eine Fähigkeit, die überprüft werden kann. Einige Browser unterstützen es nicht vollständig, einige GPUs haben Einschränkungen, einige Unternehmensumgebungen deaktivieren Funktionen, einige Benutzer verwenden bescheidene Hardware.

Integrierte KI: wenn der Browser das Modell bringt

Chrome drängt auf integrierte APIs für Aufgaben wie lokale Eingabeaufforderungen, Zusammenfassung, Schreiben, Umschreiben, Übersetzung, Spracherkennung und Korrekturlesen. Die Idee ist sehr interessant: Der Browser verwaltet Modell, Verfügbarkeit und Updates; Die App verwendet eine API, die näher an der Plattform liegt.

Wenn es gut funktioniert, ändert es viel:

• weniger Serveraufrufe für einfache Aufgaben;
• Daten, die möglicherweise auf dem Gerät verbleiben;
• geringere Latenz;
• Offline- oder Semi-Offline-Erlebnisse;
• Natürlicheres UX für das Schreiben und Übersetzen.

Aber es sollte als progressive Verbesserung behandelt werden. Einige APIs sind stabil, andere befinden sich in der ursprünglichen Test- oder Vorschauversion, andere sind immer noch von Version, Sprache und Gerät abhängig.

type LocalCapability = 'available' | 'downloadable' | 'unsupported';

export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
  const SummarizerApi = (globalThis as any).Summarizer;

  if (!SummarizerApi?.availability) {
    return 'unsupported';
  }

  const availability = await SummarizerApi.availability();

  if (availability === 'available') return 'available';
  if (availability === 'downloadable') return 'downloadable';

  return 'unsupported';
}

Der spezifische Code wird sich ändern, aber das Muster bleibt bestehen: Sie prüfen die Verfügbarkeit, erklären etwaige Downloads, bieten Fallbacks an und messen die Qualität.

Fallback ist kein trauriger Plan B

Cloud-Fallback ist keine Niederlage. Es ist Teil des Produkts.

interface AiRequest {
  task: 'summarize' | 'rewrite' | 'classify';
  input: string;
}

interface AiResult {
  output: string;
  runtime: 'local' | 'cloud';
}

export async function runAiTask(request: AiRequest): Promise<AiResult> {
  const local = await tryLocalAi(request);

  if (local) {
    return { output: local, runtime: 'local' };
  }

  const cloud = await fetch('/api/ai', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(request),
  }).then((res) => res.json());

  return { output: cloud.output, runtime: 'cloud' };
}

Diese Architektur ermöglicht es Ihnen, sich schrittweise zu verbessern. Diejenigen mit lokalem Support profitieren von einer besseren Latenz und Privatsphäre. Wer es nicht hat, nutzt die Funktion trotzdem. Sie können den Prozentsatz lokaler Anfragen, Zeiten, Fehler, Speicher, wahrgenommene Qualität und Kosten messen.

Ohne Metriken wird die KI auf dem Gerät zu einer ästhetischen Wahl. Mit Metriken wird es zum Produkthebel.

Die UX des Modells ist wichtig

Wenn der Browser ein Modell herunterladen muss, nimmt der Benutzer dies wahr. Verstecken Sie es nicht hinter einem vagen Spinner. Um es klarer zu sagen: „Wir bereiten das Modell darauf vor, diese Funktion schneller und sogar offline zu nutzen.“

Eine gute Erfahrung:

• zeigt den Vorbereitungsstatus an;
• blockiert nicht die gesamte Seite;
• ermöglicht es Ihnen, mit dem Cloud-Fallback fortzufahren;
• Vermeiden Sie Überraschungen bei Akku und Speicher;
• Erinnern Sie sich nach Möglichkeit an das Modell.
• Erläutern Sie den Nutzen in einem konkreten Satz.

Das Schlimmste ist eine „intelligente“ Funktion, die kaputt zu sein scheint, weil sie stillschweigend etwas herunterlädt.

Datenschutz: besser, nicht automatisch sicher

Die Verarbeitung der Daten auf dem Gerät kann ein großer Vorteil sein. Ein E-Mail-Entwurf, ein internes Dokument oder eine persönliche Notiz müssen Ihren Browser nicht verlassen, um einen Vorschlag zu erhalten.

Allerdings bedeutet lokal nicht automatisch sicher. Sie müssen jedoch Folgendes bedenken:

• XSS;
• versehentliche Protokolle;
• im Speicher gespeicherte Daten;
• sofortige Einschleusung von nicht vertrauenswürdigen Inhalten;
• dem Modell erteilte Berechtigungen;
• Ausgänge, die in automatischen Aktionen verwendet werden.

Wenn ein lokales Modell eine Webseite lesen und dann ein Formular ausfüllen kann, kann diese Seite versuchen, es zu manipulieren. Wenn das Tool aufgerufen werden kann, ist eine Bestätigung erforderlich. Wenn es eine strukturierte Ausgabe erzeugt, muss es validiert werden. Die Tatsache, dass es auf dem Gerät ausgeführt wird, verringert einige Datenschutzrisiken, beseitigt jedoch nicht das Sicherheitsmodell.

Wo es richtig interessant wird

Der Text ist erst der Anfang. WebGPU macht Web-Erlebnisse glaubwürdig, die bis vor Kurzem wie eine native App wirkten:

• komplexe 3D-Editoren;
• Gaußsches Splatting im Browser;
• Echtzeit-Videofilter;
• Leichtes CAD;
• wissenschaftliche Visualisierungen;
• kreative Tools mit sofortiger Vorschau;
• Sichtschlussfolgerung in der Nähe der Benutzeroberfläche;
• anspruchsvollere Browsergames.

Hier beginnen sich Frontend, Grafik und maschinelles Lernen zu vermischen. Es ist ein etwas schwieriges, aber auch fruchtbares Gebiet: Der Browser wird wieder zu einer ernstzunehmenden Anwendungsplattform und nicht nur zu einem Ort, an dem wir Formulare und Dashboards ablegen.

Checkliste vor der Produktion

Bevor ich Benutzern eine Funktion auf dem Gerät zur Verfügung stelle, würde ich Folgendes überprüfen:

1. Zielen Sie auf Browser und Geräte ab.
2. Cloud-Fallback oder elegante Verschlechterung.
3. Downloadzeit und Modell-Cache.
4. Speicher und Akku auf durchschnittlicher Hardware.
5. Qualität im Vergleich zur Cloud-Version.
6. Datenschutzrichtlinie und Benutzernachrichten.
7. Testen mit feindlichen Eingaben.
8. Separate Metriken für lokale und Cloud-Laufzeit.
9. Planen Sie, die Vorlage zu aktualisieren oder zu deaktivieren.

Es ist eine konkrete Liste, weil das Problem konkret ist. Eine langsame, fragile oder undurchsichtige KI-Funktion wird nicht besser, nur weil sie im Browser ausgeführt wird.

Der richtige Kompromiss

Ich glaube nicht, dass die Zukunft „alles auf dem Gerät“ ist. Und ich glaube auch nicht, dass die Cloud der einzig vernünftige Ort für Schlussfolgerungen bleiben wird. Die wahrscheinlichste Zukunft ist eine Mischung: lokal, wenn dadurch Latenz, Datenschutz oder Kosten verbessert werden; Cloud, wenn Qualität, aktualisierte Daten und eine zentrale Steuerung erforderlich sind.

WebGPU, WebNN und integrierte KI-APIs machen den Browser nicht allmächtig. Sie machen ihn erwachsener. Und für diejenigen, die Webprodukte entwickeln, sind das große Neuigkeiten.

Nützliche Quellen

• WebGPU-API – MDN
• WebGPU-Spezifikation – W3C
• Integrierte KI – Chrome für Entwickler
• Integrierte KI-APIs – Chrome für Entwickler
• WebNN-API