spinny:~/writing $ less webgpu-on-device-ai-browser.md
12Per 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.34Questo 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.56Ecco 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.78## Non tutto deve diventare locale910La versione infantile del discorso è: "cloud contro device". La versione utile è ibrida.1112Alcuni task stanno benissimo sul dispositivo: riassunti brevi, rilevamento lingua, riscritture leggere, classificazioni semplici, filtri immagine, piccoli modelli vision, esperienze creative con feedback immediato.1314Altri task restano migliori nel cloud: ragionamento complesso, modelli frontier, dati server-side, audit centralizzato, qualità uniforme, workflow dove devi controllare bene ogni passaggio.1516L'architettura sana decide a runtime:1718```mermaid19flowchart TD20 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 --> UX26 UX --> Metrics[Metriche e qualità]27```2829Il browser non deve vincere contro il cloud. Deve evitare al cloud il lavoro che non serve fare lì.3031## Perché WebGPU conta3233WebGPU è 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.3435Per 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.3637La prima cosa da scrivere, però, non è uno shader. È una feature detection sobria:3839```typescript40export async function requestWebGpuDevice() {41 if (!('gpu' in navigator)) {42 return null;43 }4445 const adapter = await navigator.gpu.requestAdapter({46 powerPreference: 'high-performance',47 });4849 if (!adapter) {50 return null;51 }5253 return adapter.requestDevice();54}55```5657Questa 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.5859## Built-in AI: quando il browser porta il modello6061Chrome 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.6263Se funziona bene, cambia parecchio:6465- 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.7071Ma va trattata come progressive enhancement. Alcune API sono stabili, altre in origin trial o preview, altre ancora dipendono da versione, lingua e dispositivo.7273```typescript74type LocalCapability = 'available' | 'downloadable' | 'unsupported';7576export async function getLocalSummarizerCapability(): Promise<LocalCapability> {77 const SummarizerApi = (globalThis as any).Summarizer;7879 if (!SummarizerApi?.availability) {80 return 'unsupported';81 }8283 const availability = await SummarizerApi.availability();8485 if (availability === 'available') return 'available';86 if (availability === 'downloadable') return 'downloadable';8788 return 'unsupported';89}90```9192Il codice specifico cambierà, ma il pattern resta: controlli disponibilità, spieghi eventuali download, offri fallback e misuri la qualità.9394## Il fallback non è un piano B triste9596Il fallback cloud non è una sconfitta. È parte del prodotto.9798```typescript99interface AiRequest {100 task: 'summarize' | 'rewrite' | 'classify';101 input: string;102}103104interface AiResult {105 output: string;106 runtime: 'local' | 'cloud';107}108109export async function runAiTask(request: AiRequest): Promise<AiResult> {110 const local = await tryLocalAi(request);111112 if (local) {113 return { output: local, runtime: 'local' };114 }115116 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());121122 return { output: cloud.output, runtime: 'cloud' };123}124```125126Questa 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.127128Senza metriche, l'on-device AI diventa una scelta estetica. Con le metriche, diventa una leva di prodotto.129130## La UX del modello conta131132Se 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".133134Una buona esperienza:135136- 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.142143La cosa peggiore è una feature "intelligente" che sembra rotta perché sta scaricando qualcosa in silenzio.144145## Privacy: meglio, non automaticamente sicuro146147Elaborare 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.148149Però locale non significa automaticamente sicuro. Devi comunque pensare a:150151- 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.157158Se 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.159160## Dove diventa davvero interessante161162Il testo è solo l'inizio. WebGPU rende credibili esperienze web che fino a poco tempo fa sembravano da app nativa:163164- 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.172173Qui 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.174175## Checklist prima della produzione176177Prima di mettere una feature on-device davanti agli utenti, controllerei:1781791. 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.188189È una lista concreta perché il problema è concreto. Una feature AI lenta, fragile o opaca non diventa migliore solo perché gira nel browser.190191## Il compromesso giusto192193Io 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.194195WebGPU, 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.196197## Fonti utili198199- [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
:WebGPU e AI on-device: il browser sta diventando un runtime seriolines 1-204 (END) — press q to close