LiteRT.js: L'AI nel browser cambia i costi e la tecnica

LiteRT.js: l’AI nel browser cambia i costi, non solo la tecnica

Google ha rilasciato LiteRT.js, una libreria che esegue modelli di intelligenza artificiale direttamente nel browser dell’utente, senza passare per un server. Per chi costruisce prodotti digitali con funzioni visive o audio, cambia il calcolo economico prima ancora di quello tecnico.

In sintesi

LiteRT.js usa WebGPU, un’interfaccia che permette al browser di accedere direttamente alla scheda grafica del dispositivo, per eseguire modelli AI sul client, cioè sul dispositivo dell’utente.
Rispetto ai metodi precedenti basati sul processore del browser, raggiunge velocità fino a 60 volte superiori su carichi in tempo reale; fino a 3 volte più veloce rispetto ad altri ambienti web per modelli visivi e audio.
Funziona su Chrome e Safari. Firefox non supporta ancora WebGPU in modo stabile: limite reale per chi mette in produzione oggi.
Nessun dato dell’utente lascia il dispositivo durante l’elaborazione: vantaggio concreto per applicazioni mediche, legali, o dove la riservatezza è un requisito contrattuale.
Il costo di calcolo si sposta dal tuo server al dispositivo dell’utente: meno fattura cloud, ma più dipendenza dall’hardware del cliente.

Cosa vuol dire “inferenza nel browser” per chi non programma

Partiamo da come funziona oggi la maggior parte delle applicazioni AI.

L’utente carica una foto, parla in un microfono, o carica un documento. Quel dato viaggia verso un server remoto, il server lo elabora con un modello di intelligenza artificiale, e restituisce il risultato. Ogni passaggio ha un costo: banda, latenza, e soprattutto la fattura mensile al fornitore cloud. Un e-commerce con migliaia di sessioni al giorno sente questo peso in modo diretto.

LiteRT.js inverte lo schema. Il modello AI viene scaricato una volta sul dispositivo dell’utente. Da quel momento, l’inference (esecuzione del modello su una richiesta concreta, ovvero il momento in cui il modello “ragiona” su un input e produce un risultato) avviene localmente. Il server non vede i dati durante l’uso.

Non è una differenza sottile. Per uno studio legale che analizza contratti, per una clinica che elabora immagini diagnostiche, o per un hotel che vuole riconoscere un documento al check-in, il fatto che i dati non transitino su server terzi cambia la conversazione con il cliente prima ancora di cambiare il codice.

Cosa fai oggi: se stai valutando un nuovo strumento AI per il tuo prodotto, chiedi esplicitamente dove avviene l’elaborazione. “Sul nostro server” e “sul dispositivo dell’utente” hanno implicazioni molto diverse rispetto alla privacy e ai costi.

Il punto tecnico che conta davvero: WebGPU

WebGPU è uno standard recente che permette al browser di comunicare direttamente con la GPU (Graphics Processing Unit, ovvero l’unità di elaborazione grafica, la scheda grafica del dispositivo). Prima di WebGPU, i browser potevano usare solo il processore principale, la CPU (Central Processing Unit, l’unità di calcolo centrale del computer), per operazioni di questo tipo.

Il problema è che la CPU è pensata per fare poche cose in sequenza, molto bene. La GPU, invece, è progettata per eseguire migliaia di calcoli in parallelo. I modelli AI ne hanno bisogno. È per questo che LiteRT.js raggiunge velocità fino a 60 volte superiori rispetto al percorso su processore tradizionale per carichi impegnativi in tempo reale.

Bene. Ma WebGPU non è ancora universale. Chrome lo supporta in modo stabile su desktop e mobile. Safari lo ha introdotto nelle versioni recenti. Firefox non ce l’ha ancora in produzione stabile.

Tradotto in pratica: se il tuo prodotto deve funzionare per tutti gli utenti, indipendentemente dal browser, oggi non puoi affidarti solo a LiteRT.js. Devi prevedere un percorso alternativo, un cosiddetto fallback (soluzione di riserva automatica), per chi usa Firefox o browser aziendali datati. Non è un problema insormontabile, ma va progettato.

Cosa fai oggi: prima di adottare LiteRT.js in produzione, chiedi al tuo team di sviluppo quale percentuale degli utenti attuali usa Chrome o Safari. Se è sopra l’80%, il rischio è gestibile con un fallback su API server per il resto.

Dove ha senso usarlo adesso, settore per settore

La domanda giusta non è “questa tecnologia è matura?”. È “per quale caso d’uso è già abbastanza matura oggi?”.

Sono tre i contesti in cui LiteRT.js porta valore concreto adesso.

Strutture ricettive. Un hotel che vuole offrire check-in autonomo con riconoscimento documento può farlo senza che l’immagine del passaporto dell’ospite lasci il telefono. Si riduce il rischio di trattamento dati non conforme al GDPR (Regolamento Generale sulla Protezione dei Dati, la normativa europea sulla privacy) e si abbattono i costi di API esterne per il riconoscimento ottico.

Studi professionali. Un commercialista o consulente che usa strumenti di analisi documentale può dire al cliente, con fondamento tecnico, che i file non transitano su server terzi durante l’elaborazione. In una trattativa con un cliente bancario o assicurativo, questo argomento vale più di molti altri.

E-commerce con configuratore visivo. Chi vende arredamento, abbigliamento, o prodotti personalizzabili conosce il problema: il configuratore visivo è lento su mobile, e l’utente abbandona. L’elaborazione locale elimina la latenza del server. Risultato: esperienza più fluida, specialmente su connessioni instabili.

Cliniche e studi medici. Per strumenti di supporto all’analisi di immagini, il fatto che i dati non lascino il dispositivo è rilevante rispetto agli obblighi del GDPR in ambito sanitario. La decisione clinica resta sempre al professionista. Il supporto computazionale, però, può avvenire in modo più controllato.

Quando non conviene ancora: prodotti rivolti a un pubblico generico, non segmentato, dove non puoi controllare quale browser usa l’utente. Lì la frammentazione del supporto a WebGPU rende LiteRT.js un componente aggiuntivo, non la base su cui costruire.

Il calcolo economico che cambia

Ogni richiesta che non passa per il tuo server è una riga in meno sulla fattura cloud. Per prodotti con volumi alti, il risparmio è reale. Un configuratore usato diecimila volte al giorno su API cloud a pagamento a consumo è un costo fisso mensile significativo. Spostarlo sul dispositivo dell’utente lo azzera.

Il rovescio è che scarichi il lavoro computazionale sull’hardware del cliente. Su un laptop recente o uno smartphone di fascia media degli ultimi due anni, le prestazioni sono accettabili per modelli leggeri. Su dispositivi più datati, l’esperienza può degradarsi. Devi sapere chi sono i tuoi utenti e con quali dispositivi ti accedono.

C’è anche la questione della dipendenza da fornitore. LiteRT.js è un progetto Google. I modelli supportati usano il formato TFLite, ovvero TensorFlow Lite, una versione ridotta del framework di machine learning TensorFlow ottimizzata per dispositivi con risorse limitate. Adottarlo significa costruire su un ecosistema specifico. Oggi ha senso. Va monitorato nel tempo come qualsiasi altra dipendenza infrastrutturale, esattamente come si fa con un fornitore cloud o un gateway di pagamento.

Cosa fai oggi: chiedi al tuo team un’analisi dei costi API attuali su base mensile. Se elabori immagini o audio su volumi significativi, il confronto con un’architettura LiteRT.js vale il tempo di un’analisi tecnica di mezza giornata.

Vale la pena muoversi adesso?

Risposta onesta: dipende da cosa costruisci e per chi.

Se sviluppi uno strumento interno o un prodotto verticale dove controlli l’ambiente, browser aziendale standardizzato su Chrome, dispositivi recenti, puoi valutare LiteRT.js in produzione oggi su casi specifici: analisi visiva, trascrizione audio locale, classificazione di immagini.

Se costruisci un prodotto consumer con base utenti eterogenea, la mossa giusta è integrare LiteRT.js come percorso ottimizzato per chi ha il supporto, con fallback su API server per chi non ce l’ha. Non è una scelta binaria.

I numeri da benchmark, 3x o 60x di velocità, non si replicano identici su ogni dispositivo in produzione reale. Il segnale che conta è un altro: il browser sta diventando un ambiente di esecuzione AI serio. Chi capisce questo cambiamento architetturale oggi avrà un vantaggio concreto su chi lo scoprirà tra due anni, quando sarà già ovvio a tutti.

Domande correlate

Quali browser supportano WebGPU in modo stabile oggi?

Chrome lo supporta in modo stabile su desktop e mobile. Safari ha introdotto il supporto nelle versioni recenti. Firefox non ha ancora WebGPU in produzione stabile. Per un prodotto in produzione oggi, è necessario prevedere un percorso alternativo per gli utenti Firefox, con elaborazione su server come soluzione di riserva.

I dati degli utenti sono al sicuro con l’elaborazione nel browser?

L’elaborazione locale significa che i dati non transitano su server durante l’uso del modello. Questo riduce i punti di esposizione, ma non elimina altri rischi. Il modello stesso viene scaricato sul dispositivo, e la sicurezza complessiva dipende da come è costruita l’intera applicazione, non solo da dove avviene il calcolo.

Che tipo di modelli AI funzionano con LiteRT.js?

LiteRT.js supporta modelli nel formato TFLite, ottimizzati per dispositivi con risorse limitate. Funziona bene per modelli visivi, riconoscimento immagini e rilevamento oggetti, e per l’audio. Non è adatto a modelli linguistici di grandi dimensioni come quelli usati per generare testo articolato.

Serve un team di sviluppo specializzato per integrarlo?

Un team con competenze web standard può integrare LiteRT.js. La curva di apprendimento principale riguarda la scelta e l’ottimizzazione del modello AI, non l’integrazione della libreria. La parte più delicata è gestire il fallback per browser senza supporto WebGPU.

Questo approccio è compatibile con le normative europee sulla privacy?

L’elaborazione locale riduce il trattamento di dati su server terzi, il che può semplificare alcuni aspetti della conformità al GDPR. Non è una soluzione automatica: dipende da come l’intera applicazione gestisce i dati e da quali obblighi specifici si applicano al tuo settore.

Fonti:

TechTimes, “Browser AI Gains Native Inference: Google LiteRT.js Cuts Server Dependency”, 16 luglio 2026 — https://www.techtimes.com/articles/320695/20260716/browser-ai-gains-native-inference-google-litertjs-cuts-server-dependency.htm