Google ha rilasciato LiteRT.js, il binding JavaScript di LiteRT, la libreria di inference on-device dell’azienda (in passato TensorFlow Lite). La novità pratica è che lo stesso artefatto .tflite usato su Android e iOS ora gira localmente nel browser, tramite WebAssembly, WebGPU e la API WebNN ancora sperimentale. Poiché l’inference resta sul dispositivo, Google cita maggiore privacy per l’utente, zero costi server e latenza molto bassa.
Non si tratta di un nuovo formato di modello. Google ha compilato il proprio runtime nativo in WebAssembly e lo ha esposto a JavaScript. La conseguenza è che le web app ereditano il lavoro fatto altrove: ottimizzazioni hardware, miglioramenti di quantizzazione e performance costruiti per mobile e desktop arrivano anche sul web, senza riscrivere i kernel in JavaScript come faceva TensorFlow.js.
Un runtime, tre backend
LiteRT.js indirizza tre backend. Su CPU usa XNNPACK, la libreria ottimizzata di Google, con supporto multi-thread e build SIMD. Su GPU usa ML Drift attraverso WebGPU. Su NPU si appoggia alla WebNN API, per ora sperimentale in Chrome ed Edge. Due regole governano il dispatch: non esiste delega parziale (un grafo non può essere diviso tra CPU e GPU) e la delega è tutto-o-niente per modello. Se un modello non può essere delegato interamente all’acceleratore scelto, LiteRT ricade sull’esecuzione wasm, che ha la copertura di operatori più ampia.
Performance dichiarate e un dettaglio da non ignorare
Google riporta due risultati distinti. Rispetto ad altri runtime web, LiteRT.js è fino a 3x più veloce su inference CPU e GPU, per modelli classici di computer vision e audio. Rispetto alla propria esecuzione su CPU, GPU o NPU offrono uno speedup di 5–60x su carichi real-time come object tracking e trascrizione audio. I benchmark sono stati eseguiti in ambiente browser controllato su un MacBook Pro 2024 con Apple Silicon M4; Google nota che i risultati variano con GPU locale, throttling termico e ottimizzazioni dei driver. Il valore \”10x\” circolato al lancio non compare nell’annuncio.
Il dettaglio più importante per chi scrive codice: LiteRT.js non fa garbage-collection dei tensori. Ogni Tensor va eliminato esplicitamente con .delete(), altrimenti l’app perde memoria del dispositivo. Per portare un modello PyTorch, LiteRT Torch converte in .tflite in un solo passo, ma con vincoli stretti: il modello deve essere esportabile con torch.export.export, senza branch condizionali dipendenti da valori runtime dei tensori e senza dimensioni dinamiche di input o output, batch inclusa.
Cosa cambia per chi lavora con data stack e AI
Google posiziona LiteRT.js come sostituto dei Graph Models di TensorFlow.js, non dell’intera libreria: TF.js resta lo strumento consigliato per pre e post-processing, con interop via @litertjs/tfjs-interop. Al lancio sono state mostrate quattro demo: object detection real-time con YOLO26, depth da webcam con Depth-Anything-V2, upscaling immagini con Real-ESRGAN e ricerca semantica con EmbeddingGemma in-page.
- LiteRT.js esegue modelli
.tflitenel browser riutilizzando il runtime nativo compilato in WebAssembly, senza upload al server. - Guadagni dichiarati: fino a 3x rispetto ad altri runtime web e 5–60x per GPU/NPU rispetto alla CPU; WebGPU è oggi il target pratico, WebNN resta sperimentale.
- La memoria è manuale: senza
.delete()su ogni tensore l’applicazione perde memoria del dispositivo.
Fonte: Google Releases LiteRT.js: A JavaScript Binding of LiteRT That Runs .tflite Models in Browsers via WebGPU — https://www.marktechpost.com/2026/07/15/google-releases-litert-js-a-javascript-binding-of-litert-that-runs-tflite-models-in-browsers-via-webgpu/
Hai qualcosa da aggiungere? Unisciti alla discussione.