1 
2Jahrelang 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.
3 
4Dieses 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.
5 
6Deshalb 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.
7 
8## Nicht alles muss lokal werden
9 
10Die kindische Version des Arguments lautet: „Cloud versus Device“. Die nützliche Version ist Hybrid.
11 
12Einige Aufgaben sehen auf dem Gerät großartig aus: kurze Zusammenfassungen, Spracherkennung, leichte Umschreibungen, einfache Klassifizierungen, Bildfilter, kleine Visionsmodelle, kreative Erlebnisse mit sofortigem Feedback.
13 
14Andere 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.
15 
16Die gesunde Architektur entscheidet zur Laufzeit:
17 
18```mermaid
19flowchart TD
20    User[Benutzer] --> Browser[Browser]
21    Browser --> Detect[Merkmalserkennung]
22    Detect -->|Unterstützt| Local[Lokale Schlussfolgerung]
23    Detect -->|Nicht unterstützt| Cloud[Cloud-Fallback]
24    Local --> UX[Schnelle Reaktion]
25    Cloud --> UX
26    UX --> Metrics[Kennzahlen und Qualität]
27```
28 
29Der Browser muss nicht gegen die Cloud gewinnen. Es muss die Cloud vor Arbeiten bewahren, die dort nicht erledigt werden müssen.
30 
31## Warum WebGPU wichtig ist
32 
33WebGPU 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.
34 
35Bei 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.
36 
37Das erste, was zu schreiben ist, ist jedoch kein Shader. Es ist eine nüchterne Merkmalserkennung:
38 
39```typescript
40export async function requestWebGpuDevice() {
41  if (!('gpu' in navigator)) {
42    return null;
43  }
44 
45  const adapter = await navigator.gpu.requestAdapter({
46    powerPreference: 'high-performance',
47  });
48 
49  if (!adapter) {
50    return null;
51  }
52 
53  return adapter.requestDevice();
54}
55```
56 
57Diese 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.
58 
59## Integrierte KI: wenn der Browser das Modell bringt
60 
61Chrome 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.
62 
63Wenn es gut funktioniert, ändert es viel:
64 
65- weniger Serveraufrufe für einfache Aufgaben;
66- Daten, die möglicherweise auf dem Gerät verbleiben;
67- geringere Latenz;
68- Offline- oder Semi-Offline-Erlebnisse;
69- Natürlicheres UX für das Schreiben und Übersetzen.
70 
71Aber 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.
72 
73```typescript
74type LocalCapability = 'available' | 'downloadable' | 'unsupported';
75 
76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {
77  const SummarizerApi = (globalThis as any).Summarizer;
78 
79  if (!SummarizerApi?.availability) {
80    return 'unsupported';
81  }
82 
83  const availability = await SummarizerApi.availability();
84 
85  if (availability === 'available') return 'available';
86  if (availability === 'downloadable') return 'downloadable';
87 
88  return 'unsupported';
89}
90```
91 
92Der 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.
93 
94## Fallback ist kein trauriger Plan B
95 
96Cloud-Fallback ist keine Niederlage. Es ist Teil des Produkts.
97 
98```typescript
99interface AiRequest {
100  task: 'summarize' | 'rewrite' | 'classify';
101  input: string;
102}
103 
104interface AiResult {
105  output: string;
106  runtime: 'local' | 'cloud';
107}
108 
109export async function runAiTask(request: AiRequest): Promise<AiResult> {
110  const local = await tryLocalAi(request);
111 
112  if (local) {
113    return { output: local, runtime: 'local' };
114  }
115 
116  const cloud = await fetch('/api/ai', {
117    method: 'POST',
118    headers: { 'Content-Type': 'application/json' },
119    body: JSON.stringify(request),
120  }).then((res) => res.json());
121 
122  return { output: cloud.output, runtime: 'cloud' };
123}
124```
125 
126Diese 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.
127 
128Ohne Metriken wird die KI auf dem Gerät zu einer ästhetischen Wahl. Mit Metriken wird es zum Produkthebel.
129 
130## Die UX des Modells ist wichtig
131 
132Wenn 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.“
133 
134Eine gute Erfahrung:
135 
136- zeigt den Vorbereitungsstatus an;
137- blockiert nicht die gesamte Seite;
138- ermöglicht es Ihnen, mit dem Cloud-Fallback fortzufahren;
139- Vermeiden Sie Überraschungen bei Akku und Speicher;
140- Erinnern Sie sich nach Möglichkeit an das Modell.
141- Erläutern Sie den Nutzen in einem konkreten Satz.
142 
143Das Schlimmste ist eine „intelligente“ Funktion, die kaputt zu sein scheint, weil sie stillschweigend etwas herunterlädt.
144 
145## Datenschutz: besser, nicht automatisch sicher
146 
147Die 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.
148 
149Allerdings bedeutet lokal nicht automatisch sicher. Sie müssen jedoch Folgendes bedenken:
150 
151- XSS;
152- versehentliche Protokolle;
153- im Speicher gespeicherte Daten;
154- sofortige Einschleusung von nicht vertrauenswürdigen Inhalten;
155- dem Modell erteilte Berechtigungen;
156- Ausgänge, die in automatischen Aktionen verwendet werden.
157 
158Wenn 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.
159 
160## Wo es richtig interessant wird
161 
162Der Text ist erst der Anfang. WebGPU macht Web-Erlebnisse glaubwürdig, die bis vor Kurzem wie eine native App wirkten:
163 
164- komplexe 3D-Editoren;
165- Gaußsches Splatting im Browser;
166- Echtzeit-Videofilter;
167- Leichtes CAD;
168- wissenschaftliche Visualisierungen;
169- kreative Tools mit sofortiger Vorschau;
170- Sichtschlussfolgerung in der Nähe der Benutzeroberfläche;
171- anspruchsvollere Browsergames.
172 
173Hier 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.
174 
175## Checkliste vor der Produktion
176 
177Bevor ich Benutzern eine Funktion auf dem Gerät zur Verfügung stelle, würde ich Folgendes überprüfen:
178 
1791. Zielen Sie auf Browser und Geräte ab.
1802. Cloud-Fallback oder elegante Verschlechterung.
1813. Downloadzeit und Modell-Cache.
1824. Speicher und Akku auf durchschnittlicher Hardware.
1835. Qualität im Vergleich zur Cloud-Version.
1846. Datenschutzrichtlinie und Benutzernachrichten.
1857. Testen mit feindlichen Eingaben.
1868. Separate Metriken für lokale und Cloud-Laufzeit.
1879. Planen Sie, die Vorlage zu aktualisieren oder zu deaktivieren.
188 
189Es 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.
190 
191## Der richtige Kompromiss
192 
193Ich 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.
194 
195WebGPU, 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.
196 
197## Nützliche Quellen
198 
199- [WebGPU-API – MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [WebGPU-Spezifikation – W3C](https://www.w3.org/TR/webgpu/)
201- [Integrierte KI – Chrome für Entwickler](https://developer.chrome.com/docs/ai/built-in)
202- [Integrierte KI-APIs – Chrome für Entwickler](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN-API](https://webnn.io/)
204