WebGPU och on-device AI: Webbläsaren håller på att bli en seriös runtime

spinny:~/writing $ less webgpu-on-device-ai-browser.md

1 
2I flera år var webbläsaren applikationens trevliga ansikte utåt och molnet var platsen där de svåra sakerna hände. Användaren skriver, klickar, laddar upp en fil; gränssnittet skickar allt till servern; servern anropar en modell; svaret kommer tillbaka.
3 
4Detta schema är fortfarande mycket användbart, men det är inte gratis. Varje samtal medför fördröjning, kostnader, nätverksberoende och integritetsfrågor. Om användaren skriver en mening och vill ha ett förslag väger en halv sekund. Om du klassificerar tusentals små insatser, blir öre riktiga pengar. Om texten är känslig är det inte ett neutralt val att skicka den från enheten.
5 
6Det är därför WebGPU och on-device AI är i hype. Inte för att vi kommer att köra alla modeller i webbläsaren imorgon. Eftersom några av de intelligenta funktionerna kan komma närmare användaren.
7 
8## Allt måste inte bli lokalt
9 
10Den barnsliga versionen av argumentet är: "moln kontra enhet". Den användbara versionen är hybrid.
11 
12Vissa uppgifter ser bra ut på enheten: korta sammanfattningar, språkdetektering, lätta omskrivningar, enkla klassificeringar, bildfilter, små visionmodeller, kreativa upplevelser med omedelbar feedback.
13 
14Andra uppgifter förblir bättre i molnet: komplexa resonemang, gränsmodeller, data på serversidan, centraliserad revision, enhetlig kvalitet, arbetsflöde där du noggrant måste kontrollera varje steg.
15 
16Den sunda arkitekturen avgör vid körning:
17 
18```mermaid
19flowchart TD
20    User[Användare] --> Browser[Webbläsare]
21    Browser --> Detect[Funktionsdetektering]
22    Detect -->|Stöds| Local[Lokal slutledning]
23    Detect -->|Stöds inte| Cloud[Moln fallback]
24    Local --> UX[Snabb respons]
25    Cloud --> UX
26    UX --> Metrics[Mått och kvalitet]
27```
28 
29Webbläsaren behöver inte vinna mot molnet. Det måste rädda molnet från att utföra arbete som inte behöver göras där.
30 
31## Varför WebGPU är viktigt
32 
33WebGPU är ett modernt API för att använda GPU från webbläsaren. Det är inte bara för snyggare 3D-grafik. Det är också viktigt eftersom det avslöjar primitiver som är lämpliga för datoranvändning: parallella arbetsbelastningar, shaders, pipelines närmare vad GPU:er gör bra.
34 
35För AI, vetenskaplig visualisering, 3D-redigerare, videofilter och kreativa verktyg känns denna skillnad. WebGL har gjort mycket för webben, men WebGPU föddes med en modell bättre anpassad till nutiden.
36 
37Det första man ska skriva är dock inte en shader. Det är en sober funktionsdetektering:
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 
57Den här funktionen säger en viktig sak: WebGPU är inte en rättighet som beviljas på varje enhet. Det är en förmåga att verifieras. Vissa webbläsare stöder det inte fullt ut, vissa GPU:er har begränsningar, vissa företagsmiljöer inaktiverar funktioner, vissa användare använder blygsam hårdvara.
58 
59## Inbyggd AI: när webbläsaren tar med modellen
60 
61Chrome driver inbyggda API:er för uppgifter som lokala uppmaningar, sammanfattningar, skrivning, omskrivning, översättning, språkidentifiering och korrekturläsning. Idén är mycket intressant: webbläsaren hanterar modell, tillgänglighet och uppdateringar; appen använder ett API närmare plattformen.
62 
63Om det fungerar bra förändras det mycket:
64 
65- färre serveranrop för enkla uppgifter;
66- data som kan finnas kvar på enheten;
67- lägre latens;
68- offline eller semi-offline upplevelser;
69- Mer naturlig UX för skrivande och översättning.
70 
71Men det bör behandlas som progressiv förbättring. Vissa API:er är stabila, andra i ursprungstest eller förhandsgranskning, andra beror fortfarande på version, språk och enhet.
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 
92Den specifika koden kommer att ändras, men mönstret består: du kontrollerar tillgänglighet, förklarar eventuella nedladdningar, erbjuder reservdelar och mäter kvalitet.
93 
94## Fallback är ingen sorglig plan B
95 
96Cloud fallback är inte ett nederlag. Det är en del av produkten.
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 
126Denna arkitektur tillåter dig att successivt förbättra. De med lokal support får bättre latens och integritet. De som inte har det använder fortfarande funktionen. Du kan mäta procentandel av lokala förfrågningar, tider, fel, minne, upplevd kvalitet och kostnad.
127 
128Utan mätvärden blir AI på enheten ett estetiskt val. Med mätvärden blir det en produktspak.
129 
130## Modellens användarupplevelse spelar roll
131 
132Om webbläsaren behöver ladda ner en modell uppfattar användaren den. Göm det inte bakom en vag spinner. Bättre att vara tydlig: "Vi förbereder modellen för att använda den här funktionen snabbare och till och med offline."
133 
134En bra upplevelse:
135 
136- visar beredningsstatus;
137- blockerar inte hela sidan;
138- låter dig fortsätta med molnfallback;
139- undvik batteri- och minnesöverraskningar;
140- kom ihåg modellen när det är möjligt;
141- förklara nyttan i en konkret mening.
142 
143Det värsta är en "smart" funktion som verkar trasig eftersom den laddar ner något tyst.
144 
145## Sekretess: bättre, inte automatiskt säker
146 
147Att bearbeta data på enheten kan vara en stor fördel. Ett utkast till e-post, internt dokument eller personlig anteckning behöver inte lämna din webbläsare för att få ett förslag.
148 
149Lokal betyder dock inte automatiskt säker. Du måste dock tänka på:
150 
151- XSS;
152- oavsiktliga loggar;
153- data sparade i lagring;
154- snabb injektion från opålitligt innehåll;
155- tillstånd som beviljats modellen;
156- utgångar som används i automatiska åtgärder.
157 
158Om en lokal modell kan läsa en webbsida och sedan fylla i ett formulär, kan den sidan försöka manipulera den. Om det kan anropa verktyget krävs bekräftelse. Om den producerar strukturerad produktion måste den valideras. Det faktum att den körs på enheten minskar vissa integritetsrisker, men eliminerar inte säkerhetsmodellen.
159 
160## Där det blir riktigt intressant
161 
162Texten är bara början. WebGPU gör webbupplevelser trovärdiga som tills nyligen verkade som en inbyggd app:
163 
164- komplexa 3D-redigerare;
165- Gaussiska stänk i webbläsaren;
166- realtidsvideofilter;
167- Lätt CAD;
168- vetenskapliga visualiseringar;
169- kreativa verktyg med omedelbar förhandsvisning;
170- vision slutledning nära UI;
171- mer ambitiösa webbläsarspel.
172 
173Här börjar frontend, grafik och maskininlärning blandas. Det är ett lite besvärligt område, men också ett bördigt sådant: webbläsaren återgår till att vara en seriös applikationsplattform, inte bara platsen där vi lägger formulär och instrumentpaneler.
174 
175## Checklista före produktion
176 
177Innan jag lägger en funktion på enheten framför användarna, skulle jag kontrollera:
178 
1791. Rikta in webbläsare och enheter.
1802. Molntillbakagång eller elegant nedbrytning.
1813. Ladda ner tid och modellcache.
1824. Minne och batteri i genomsnitt hårdvara.
1835. Kvalitet jämfört med molnversionen.
1846. Sekretesspolicy och användarmeddelanden.
1857. Testa med fientliga ingångar.
1868. Separat mätvärde för lokal och molnkörning.
1879. Planera att uppdatera eller inaktivera mallen.
188 
189Det är en konkret lista eftersom problemet är konkret. En långsam, ömtålig eller ogenomskinlig AI-funktion blir inte bättre bara för att den körs i webbläsaren.
190 
191## Rätt kompromiss
192 
193Jag tror inte att framtiden är "allt på enheten". Och jag tror inte heller att molnet kommer att förbli den enda rimliga platsen för slutsatser. Den mest troliga framtiden är en blandning: lokal när den förbättrar latens, integritet eller kostnad; moln när kvalitet, uppdaterad data och centraliserad kontroll behövs.
194 
195WebGPU, WebNN och inbyggda AI API:er gör inte webbläsaren allsmäktig. De gör honom mer vuxen. Och för dem som bygger webbprodukter är detta enorma nyheter.
196 
197## Användbara källor
198 
199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [WebGPU-specifikation - W3C](https://www.w3.org/TR/webgpu/)
201- [Inbyggd AI - Chrome för utvecklare](https://developer.chrome.com/docs/ai/built-in)
202- [Inbyggda AI API:er - Chrome för utvecklare](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN API](https://webnn.io/)
204

:WebGPU och on-device AI: Webbläsaren håller på att bli en seriös runtimelines 1-204 (END) — press q to close

2I flera år var webbläsaren applikationens trevliga ansikte utåt och molnet var platsen där de svåra sakerna hände. Användaren skriver, klickar, laddar upp en fil; gränssnittet skickar allt till servern; servern anropar en modell; svaret kommer tillbaka.

4Detta schema är fortfarande mycket användbart, men det är inte gratis. Varje samtal medför fördröjning, kostnader, nätverksberoende och integritetsfrågor. Om användaren skriver en mening och vill ha ett förslag väger en halv sekund. Om du klassificerar tusentals små insatser, blir öre riktiga pengar. Om texten är känslig är det inte ett neutralt val att skicka den från enheten.

6Det är därför WebGPU och on-device AI är i hype. Inte för att vi kommer att köra alla modeller i webbläsaren imorgon. Eftersom några av de intelligenta funktionerna kan komma närmare användaren.

8## Allt måste inte bli lokalt

10Den barnsliga versionen av argumentet är: "moln kontra enhet". Den användbara versionen är hybrid.

12Vissa uppgifter ser bra ut på enheten: korta sammanfattningar, språkdetektering, lätta omskrivningar, enkla klassificeringar, bildfilter, små visionmodeller, kreativa upplevelser med omedelbar feedback.

14Andra uppgifter förblir bättre i molnet: komplexa resonemang, gränsmodeller, data på serversidan, centraliserad revision, enhetlig kvalitet, arbetsflöde där du noggrant måste kontrollera varje steg.

16Den sunda arkitekturen avgör vid körning:

18```mermaid

19flowchart TD

20 User[Användare] --> Browser[Webbläsare]

21 Browser --> Detect[Funktionsdetektering]

22 Detect -->|Stöds| Local[Lokal slutledning]

23 Detect -->|Stöds inte| Cloud[Moln fallback]

24 Local --> UX[Snabb respons]

25 Cloud --> UX

26 UX --> Metrics[Mått och kvalitet]

27```

29Webbläsaren behöver inte vinna mot molnet. Det måste rädda molnet från att utföra arbete som inte behöver göras där.

31## Varför WebGPU är viktigt

33WebGPU är ett modernt API för att använda GPU från webbläsaren. Det är inte bara för snyggare 3D-grafik. Det är också viktigt eftersom det avslöjar primitiver som är lämpliga för datoranvändning: parallella arbetsbelastningar, shaders, pipelines närmare vad GPU:er gör bra.

35För AI, vetenskaplig visualisering, 3D-redigerare, videofilter och kreativa verktyg känns denna skillnad. WebGL har gjort mycket för webben, men WebGPU föddes med en modell bättre anpassad till nutiden.

37Det första man ska skriva är dock inte en shader. Det är en sober funktionsdetektering:

39```typescript

40export async function requestWebGpuDevice() {

41 if (!('gpu' in navigator)) {

42 return null;

43 }

45 const adapter = await navigator.gpu.requestAdapter({

46 powerPreference: 'high-performance',

47 });

49 if (!adapter) {

50 return null;

51 }

53 return adapter.requestDevice();

54}

55```

57Den här funktionen säger en viktig sak: WebGPU är inte en rättighet som beviljas på varje enhet. Det är en förmåga att verifieras. Vissa webbläsare stöder det inte fullt ut, vissa GPU:er har begränsningar, vissa företagsmiljöer inaktiverar funktioner, vissa användare använder blygsam hårdvara.

59## Inbyggd AI: när webbläsaren tar med modellen

61Chrome driver inbyggda API:er för uppgifter som lokala uppmaningar, sammanfattningar, skrivning, omskrivning, översättning, språkidentifiering och korrekturläsning. Idén är mycket intressant: webbläsaren hanterar modell, tillgänglighet och uppdateringar; appen använder ett API närmare plattformen.

63Om det fungerar bra förändras det mycket:

65- färre serveranrop för enkla uppgifter;

66- data som kan finnas kvar på enheten;

67- lägre latens;

68- offline eller semi-offline upplevelser;

69- Mer naturlig UX för skrivande och översättning.

71Men det bör behandlas som progressiv förbättring. Vissa API:er är stabila, andra i ursprungstest eller förhandsgranskning, andra beror fortfarande på version, språk och enhet.

73```typescript

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

76export async function getLocalSummarizerCapability(): Promise<LocalCapability> {

77 const SummarizerApi = (globalThis as any).Summarizer;

79 if (!SummarizerApi?.availability) {

80 return 'unsupported';

81 }

83 const availability = await SummarizerApi.availability();

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

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

88 return 'unsupported';

89}

90```

92Den specifika koden kommer att ändras, men mönstret består: du kontrollerar tillgänglighet, förklarar eventuella nedladdningar, erbjuder reservdelar och mäter kvalitet.

94## Fallback är ingen sorglig plan B

96Cloud fallback är inte ett nederlag. Det är en del av produkten.

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

126Denna arkitektur tillåter dig att successivt förbättra. De med lokal support får bättre latens och integritet. De som inte har det använder fortfarande funktionen. Du kan mäta procentandel av lokala förfrågningar, tider, fel, minne, upplevd kvalitet och kostnad.

127

128Utan mätvärden blir AI på enheten ett estetiskt val. Med mätvärden blir det en produktspak.

129

130## Modellens användarupplevelse spelar roll

131

132Om webbläsaren behöver ladda ner en modell uppfattar användaren den. Göm det inte bakom en vag spinner. Bättre att vara tydlig: "Vi förbereder modellen för att använda den här funktionen snabbare och till och med offline."

133

134En bra upplevelse:

135

136- visar beredningsstatus;

137- blockerar inte hela sidan;

138- låter dig fortsätta med molnfallback;

139- undvik batteri- och minnesöverraskningar;

140- kom ihåg modellen när det är möjligt;

141- förklara nyttan i en konkret mening.

142

143Det värsta är en "smart" funktion som verkar trasig eftersom den laddar ner något tyst.

144

145## Sekretess: bättre, inte automatiskt säker

146

147Att bearbeta data på enheten kan vara en stor fördel. Ett utkast till e-post, internt dokument eller personlig anteckning behöver inte lämna din webbläsare för att få ett förslag.

148

149Lokal betyder dock inte automatiskt säker. Du måste dock tänka på:

150

151- XSS;

152- oavsiktliga loggar;

153- data sparade i lagring;

154- snabb injektion från opålitligt innehåll;

155- tillstånd som beviljats modellen;

156- utgångar som används i automatiska åtgärder.

157

158Om en lokal modell kan läsa en webbsida och sedan fylla i ett formulär, kan den sidan försöka manipulera den. Om det kan anropa verktyget krävs bekräftelse. Om den producerar strukturerad produktion måste den valideras. Det faktum att den körs på enheten minskar vissa integritetsrisker, men eliminerar inte säkerhetsmodellen.

159

160## Där det blir riktigt intressant

161

162Texten är bara början. WebGPU gör webbupplevelser trovärdiga som tills nyligen verkade som en inbyggd app:

163

164- komplexa 3D-redigerare;

165- Gaussiska stänk i webbläsaren;

166- realtidsvideofilter;

167- Lätt CAD;

168- vetenskapliga visualiseringar;

169- kreativa verktyg med omedelbar förhandsvisning;

170- vision slutledning nära UI;

171- mer ambitiösa webbläsarspel.

172

173Här börjar frontend, grafik och maskininlärning blandas. Det är ett lite besvärligt område, men också ett bördigt sådant: webbläsaren återgår till att vara en seriös applikationsplattform, inte bara platsen där vi lägger formulär och instrumentpaneler.

174

175## Checklista före produktion

176

177Innan jag lägger en funktion på enheten framför användarna, skulle jag kontrollera:

178

1791. Rikta in webbläsare och enheter.

1802. Molntillbakagång eller elegant nedbrytning.

1813. Ladda ner tid och modellcache.

1824. Minne och batteri i genomsnitt hårdvara.

1835. Kvalitet jämfört med molnversionen.

1846. Sekretesspolicy och användarmeddelanden.

1857. Testa med fientliga ingångar.

1868. Separat mätvärde för lokal och molnkörning.

1879. Planera att uppdatera eller inaktivera mallen.

188

189Det är en konkret lista eftersom problemet är konkret. En långsam, ömtålig eller ogenomskinlig AI-funktion blir inte bättre bara för att den körs i webbläsaren.

190

191## Rätt kompromiss

192

193Jag tror inte att framtiden är "allt på enheten". Och jag tror inte heller att molnet kommer att förbli den enda rimliga platsen för slutsatser. Den mest troliga framtiden är en blandning: lokal när den förbättrar latens, integritet eller kostnad; moln när kvalitet, uppdaterad data och centraliserad kontroll behövs.

194

195WebGPU, WebNN och inbyggda AI API:er gör inte webbläsaren allsmäktig. De gör honom mer vuxen. Och för dem som bygger webbprodukter är detta enorma nyheter.

196

197## Användbara källor

198

199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)

200- [WebGPU-specifikation - W3C](https://www.w3.org/TR/webgpu/)

201- [Inbyggd AI - Chrome för utvecklare](https://developer.chrome.com/docs/ai/built-in)

202- [Inbyggda AI API:er - Chrome för utvecklare](https://developer.chrome.com/docs/ai/built-in-apis)

203- [WebNN API](https://webnn.io/)

204