WebGPU e AI on-device: il browser sta diventando un runtime serio

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

1~
2Per anni il browser è stato la faccia gentile dell'applicazione e il cloud il posto dove succedevano le cose difficili. L'utente scrive, clicca, carica un file; il frontend manda tutto al server; il server chiama un modello; la risposta torna indietro.
3~
4Questo schema resta utilissimo, ma non è gratis. Ogni chiamata porta latenza, costo, dipendenza dalla rete e domande di privacy. Se l'utente sta scrivendo una frase e vuole un suggerimento, mezzo secondo pesa. Se stai classificando migliaia di piccoli input, i centesimi diventano soldi veri. Se il testo è sensibile, mandarlo fuori dal dispositivo non è una scelta neutra.
5~
6Ecco perché WebGPU e AI on-device sono in hype. Non perché domani faremo girare ogni modello nel browser. Perché una parte delle feature intelligenti può avvicinarsi all'utente.
7~
8## Non tutto deve diventare locale
9~
10La versione infantile del discorso è: "cloud contro device". La versione utile è ibrida.
11~
12Alcuni task stanno benissimo sul dispositivo: riassunti brevi, rilevamento lingua, riscritture leggere, classificazioni semplici, filtri immagine, piccoli modelli vision, esperienze creative con feedback immediato.
13~
14Altri task restano migliori nel cloud: ragionamento complesso, modelli frontier, dati server-side, audit centralizzato, qualità uniforme, workflow dove devi controllare bene ogni passaggio.
15~
16L'architettura sana decide a runtime:
17~
18```mermaid
19flowchart TD
20    User[Utente] --> Browser[Browser]
21    Browser --> Detect[Feature detection]
22    Detect -->|Supportato| Local[Inferenza locale]
23    Detect -->|Non supportato| Cloud[Fallback cloud]
24    Local --> UX[Risposta veloce]
25    Cloud --> UX
26    UX --> Metrics[Metriche e qualità]
27```
28~
29Il browser non deve vincere contro il cloud. Deve evitare al cloud il lavoro che non serve fare lì.
30~
31## Perché WebGPU conta
32~
33WebGPU è una API moderna per usare la GPU dal browser. Non serve solo per grafica 3D più bella. È importante anche perché espone primitive adatte al compute: workload paralleli, shader, pipeline più vicine a quello che le GPU sanno fare bene.
34~
35Per AI, visualizzazione scientifica, editor 3D, filtri video e strumenti creativi, questa differenza si sente. WebGL ha fatto tantissimo per il web, ma WebGPU nasce con un modello più adatto al presente.
36~
37La prima cosa da scrivere, però, non è uno shader. È una feature detection sobria:
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~
57Questa funzione dice una cosa importante: WebGPU non è un diritto acquisito su ogni dispositivo. È una capacità da verificare. Alcuni browser non lo supportano pienamente, alcune GPU hanno limiti, alcuni ambienti aziendali disabilitano feature, alcuni utenti sono su hardware modesto.
58~
59## Built-in AI: quando il browser porta il modello
60~
61Chrome sta spingendo API built-in per task come prompt locali, riassunto, scrittura, riscrittura, traduzione, rilevamento lingua e proofreading. L'idea è molto interessante: il browser gestisce modello, disponibilità e aggiornamenti; l'app usa una API più vicina alla piattaforma.
62~
63Se funziona bene, cambia parecchio:
64~
65- meno chiamate server per task semplici;
66- dati che possono restare sul dispositivo;
67- latenza più bassa;
68- esperienze offline o semi-offline;
69- UX più naturale per scrittura e traduzione.
70~
71Ma va trattata come progressive enhancement. Alcune API sono stabili, altre in origin trial o preview, altre ancora dipendono da versione, lingua e dispositivo.
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~
92Il codice specifico cambierà, ma il pattern resta: controlli disponibilità, spieghi eventuali download, offri fallback e misuri la qualità.
93~
94## Il fallback non è un piano B triste
95~
96Il fallback cloud non è una sconfitta. È parte del prodotto.
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~
126Questa architettura ti permette di migliorare progressivamente. Chi ha supporto locale ottiene latenza e privacy migliori. Chi non ce l'ha usa comunque la feature. Tu puoi misurare percentuale di richieste locali, tempi, errori, memoria, qualità percepita e costo.
127~
128Senza metriche, l'on-device AI diventa una scelta estetica. Con le metriche, diventa una leva di prodotto.
129~
130## La UX del modello conta
131~
132Se il browser deve scaricare un modello, l'utente lo percepisce. Non nasconderlo dietro uno spinner vago. Meglio essere chiari: "Prepariamo il modello per usare questa funzione più velocemente e anche offline".
133~
134Una buona esperienza:
135~
136- mostra lo stato di preparazione;
137- non blocca tutta la pagina;
138- permette di continuare con il fallback cloud;
139- evita sorprese su batteria e memoria;
140- ricorda il modello quando possibile;
141- spiega il beneficio in una frase concreta.
142~
143La cosa peggiore è una feature "intelligente" che sembra rotta perché sta scaricando qualcosa in silenzio.
144~
145## Privacy: meglio, non automaticamente sicuro
146~
147Elaborare dati sul dispositivo può essere un grande vantaggio. Una bozza email, un documento interno o una nota personale non devono per forza lasciare il browser per ricevere un suggerimento.
148~
149Però locale non significa automaticamente sicuro. Devi comunque pensare a:
150~
151- XSS;
152- log accidentali;
153- dati salvati in storage;
154- prompt injection da contenuti non fidati;
155- permessi concessi al modello;
156- output usati in azioni automatiche.
157~
158Se un modello locale può leggere una pagina web e poi compilare un form, quella pagina può provare a manipolarlo. Se può chiamare tool, servono conferme. Se produce output strutturato, va validato. Il fatto che giri sul device riduce alcuni rischi di privacy, ma non cancella il security model.
159~
160## Dove diventa davvero interessante
161~
162Il testo è solo l'inizio. WebGPU rende credibili esperienze web che fino a poco tempo fa sembravano da app nativa:
163~
164- editor 3D complessi;
165- Gaussian splatting nel browser;
166- filtri video in tempo reale;
167- CAD leggero;
168- visualizzazioni scientifiche;
169- strumenti creativi con anteprima immediata;
170- inferenza vision vicino alla UI;
171- giochi browser più ambiziosi.
172~
173Qui frontend, grafica e machine learning iniziano a mescolarsi. È una zona un po' scomoda, ma anche fertile: il browser torna a essere una piattaforma applicativa seria, non solo il posto in cui mettiamo form e dashboard.
174~
175## Checklist prima della produzione
176~
177Prima di mettere una feature on-device davanti agli utenti, controllerei:
178~
1791. Browser e dispositivi target.
1802. Fallback cloud o degradazione elegante.
1813. Tempo di download e cache del modello.
1824. Memoria e batteria su hardware medio.
1835. Qualità rispetto alla versione cloud.
1846. Privacy policy e messaggi utente.
1857. Test con input ostili.
1868. Metriche separate per runtime locale e cloud.
1879. Piano per aggiornare o disabilitare il modello.
188~
189È una lista concreta perché il problema è concreto. Una feature AI lenta, fragile o opaca non diventa migliore solo perché gira nel browser.
190~
191## Il compromesso giusto
192~
193Io non credo che il futuro sia "tutto sul device". E non credo nemmeno che il cloud resterà l'unico posto ragionevole per l'inferenza. Il futuro più probabile è una miscela: locale quando migliora latenza, privacy o costo; cloud quando servono qualità, dati aggiornati e controllo centralizzato.
194~
195WebGPU, WebNN e le API AI integrate non rendono il browser onnipotente. Lo rendono più adulto. E per chi costruisce prodotti web, questa è una notizia enorme.
196~
197## Fonti utili
198~
199- [WebGPU API - MDN](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API)
200- [WebGPU specification - W3C](https://www.w3.org/TR/webgpu/)
201- [Built-in AI - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in)
202- [Built-in AI APIs - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in-apis)
203- [WebNN API](https://webnn.io/)
204~

NORMAL · webgpu-on-device-ai-browser.md [readonly]204 lines · :q to close

2Per anni il browser è stato la faccia gentile dell'applicazione e il cloud il posto dove succedevano le cose difficili. L'utente scrive, clicca, carica un file; il frontend manda tutto al server; il server chiama un modello; la risposta torna indietro.

4Questo schema resta utilissimo, ma non è gratis. Ogni chiamata porta latenza, costo, dipendenza dalla rete e domande di privacy. Se l'utente sta scrivendo una frase e vuole un suggerimento, mezzo secondo pesa. Se stai classificando migliaia di piccoli input, i centesimi diventano soldi veri. Se il testo è sensibile, mandarlo fuori dal dispositivo non è una scelta neutra.

6Ecco perché WebGPU e AI on-device sono in hype. Non perché domani faremo girare ogni modello nel browser. Perché una parte delle feature intelligenti può avvicinarsi all'utente.

8## Non tutto deve diventare locale

10La versione infantile del discorso è: "cloud contro device". La versione utile è ibrida.

11~

12Alcuni task stanno benissimo sul dispositivo: riassunti brevi, rilevamento lingua, riscritture leggere, classificazioni semplici, filtri immagine, piccoli modelli vision, esperienze creative con feedback immediato.

13~

14Altri task restano migliori nel cloud: ragionamento complesso, modelli frontier, dati server-side, audit centralizzato, qualità uniforme, workflow dove devi controllare bene ogni passaggio.

15~

16L'architettura sana decide a runtime:

17~

18```mermaid

19flowchart TD

20 User[Utente] --> Browser[Browser]

21 Browser --> Detect[Feature detection]

22 Detect -->|Supportato| Local[Inferenza locale]

23 Detect -->|Non supportato| Cloud[Fallback cloud]

24 Local --> UX[Risposta veloce]

25 Cloud --> UX

26 UX --> Metrics[Metriche e qualità]

27```

28~

29Il browser non deve vincere contro il cloud. Deve evitare al cloud il lavoro che non serve fare lì.

30~

31## Perché WebGPU conta

32~

33WebGPU è una API moderna per usare la GPU dal browser. Non serve solo per grafica 3D più bella. È importante anche perché espone primitive adatte al compute: workload paralleli, shader, pipeline più vicine a quello che le GPU sanno fare bene.

34~

35Per AI, visualizzazione scientifica, editor 3D, filtri video e strumenti creativi, questa differenza si sente. WebGL ha fatto tantissimo per il web, ma WebGPU nasce con un modello più adatto al presente.

36~

37La prima cosa da scrivere, però, non è uno shader. È una feature detection sobria:

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~

57Questa funzione dice una cosa importante: WebGPU non è un diritto acquisito su ogni dispositivo. È una capacità da verificare. Alcuni browser non lo supportano pienamente, alcune GPU hanno limiti, alcuni ambienti aziendali disabilitano feature, alcuni utenti sono su hardware modesto.

58~

59## Built-in AI: quando il browser porta il modello

60~

61Chrome sta spingendo API built-in per task come prompt locali, riassunto, scrittura, riscrittura, traduzione, rilevamento lingua e proofreading. L'idea è molto interessante: il browser gestisce modello, disponibilità e aggiornamenti; l'app usa una API più vicina alla piattaforma.

62~

63Se funziona bene, cambia parecchio:

64~

65- meno chiamate server per task semplici;

66- dati che possono restare sul dispositivo;

67- latenza più bassa;

68- esperienze offline o semi-offline;

69- UX più naturale per scrittura e traduzione.

70~

71Ma va trattata come progressive enhancement. Alcune API sono stabili, altre in origin trial o preview, altre ancora dipendono da versione, lingua e dispositivo.

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~

92Il codice specifico cambierà, ma il pattern resta: controlli disponibilità, spieghi eventuali download, offri fallback e misuri la qualità.

93~

94## Il fallback non è un piano B triste

95~

96Il fallback cloud non è una sconfitta. È parte del prodotto.

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~

126Questa architettura ti permette di migliorare progressivamente. Chi ha supporto locale ottiene latenza e privacy migliori. Chi non ce l'ha usa comunque la feature. Tu puoi misurare percentuale di richieste locali, tempi, errori, memoria, qualità percepita e costo.

127~

128Senza metriche, l'on-device AI diventa una scelta estetica. Con le metriche, diventa una leva di prodotto.

129~

130## La UX del modello conta

131~

132Se il browser deve scaricare un modello, l'utente lo percepisce. Non nasconderlo dietro uno spinner vago. Meglio essere chiari: "Prepariamo il modello per usare questa funzione più velocemente e anche offline".

133~

134Una buona esperienza:

135~

136- mostra lo stato di preparazione;

137- non blocca tutta la pagina;

138- permette di continuare con il fallback cloud;

139- evita sorprese su batteria e memoria;

140- ricorda il modello quando possibile;

141- spiega il beneficio in una frase concreta.

142~

143La cosa peggiore è una feature "intelligente" che sembra rotta perché sta scaricando qualcosa in silenzio.

144~

145## Privacy: meglio, non automaticamente sicuro

146~

147Elaborare dati sul dispositivo può essere un grande vantaggio. Una bozza email, un documento interno o una nota personale non devono per forza lasciare il browser per ricevere un suggerimento.

148~

149Però locale non significa automaticamente sicuro. Devi comunque pensare a:

150~

151- XSS;

152- log accidentali;

153- dati salvati in storage;

154- prompt injection da contenuti non fidati;

155- permessi concessi al modello;

156- output usati in azioni automatiche.

157~

158Se un modello locale può leggere una pagina web e poi compilare un form, quella pagina può provare a manipolarlo. Se può chiamare tool, servono conferme. Se produce output strutturato, va validato. Il fatto che giri sul device riduce alcuni rischi di privacy, ma non cancella il security model.

159~

160## Dove diventa davvero interessante

161~

162Il testo è solo l'inizio. WebGPU rende credibili esperienze web che fino a poco tempo fa sembravano da app nativa:

163~

164- editor 3D complessi;

165- Gaussian splatting nel browser;

166- filtri video in tempo reale;

167- CAD leggero;

168- visualizzazioni scientifiche;

169- strumenti creativi con anteprima immediata;

170- inferenza vision vicino alla UI;

171- giochi browser più ambiziosi.

172~

173Qui frontend, grafica e machine learning iniziano a mescolarsi. È una zona un po' scomoda, ma anche fertile: il browser torna a essere una piattaforma applicativa seria, non solo il posto in cui mettiamo form e dashboard.

174~

175## Checklist prima della produzione

176~

177Prima di mettere una feature on-device davanti agli utenti, controllerei:

178~

1791. Browser e dispositivi target.

1802. Fallback cloud o degradazione elegante.

1813. Tempo di download e cache del modello.

1824. Memoria e batteria su hardware medio.

1835. Qualità rispetto alla versione cloud.

1846. Privacy policy e messaggi utente.

1857. Test con input ostili.

1868. Metriche separate per runtime locale e cloud.

1879. Piano per aggiornare o disabilitare il modello.

188~

189È una lista concreta perché il problema è concreto. Una feature AI lenta, fragile o opaca non diventa migliore solo perché gira nel browser.

190~

191## Il compromesso giusto

192~

193Io non credo che il futuro sia "tutto sul device". E non credo nemmeno che il cloud resterà l'unico posto ragionevole per l'inferenza. Il futuro più probabile è una miscela: locale quando migliora latenza, privacy o costo; cloud quando servono qualità, dati aggiornati e controllo centralizzato.

194~

195WebGPU, WebNN e le API AI integrate non rendono il browser onnipotente. Lo rendono più adulto. E per chi costruisce prodotti web, questa è una notizia enorme.

196~

197## Fonti utili

198~

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

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

201- [Built-in AI - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in)

202- [Built-in AI APIs - Chrome for Developers](https://developer.chrome.com/docs/ai/built-in-apis)

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

204~