LiteRT.js sta superando TensorFlow.js

LiteRT.js con WebGPU esegue un'inferenza MobileNetV2 in 0,41 ms, raggiungendo 2.439 FPS su una GPU desktop M2 Max — oltre 25 volte più veloce di TensorFlow.js sullo stesso hardware. Il divario si amplia per i modelli più grandi, portando il machine learning basato sul web in un livello di prestazioni un tempo riservato alle app native.

Perché il benchmark è importante

Gli sviluppatori hanno utilizzato TensorFlow.js per l'inferenza on-device, solitamente tramite il backend WebGL. WebGL mappa le operazioni tensoriali sulla pipeline grafica 2D del browser; funziona ovunque, ma non è stato progettato per il massiccio parallelismo di cui hanno bisogno i modelli di deep learning. WebGPU, la API grafica di nuova generazione, offre l'accesso diretto alle unità di calcolo della GPU. LiteRT.js è la prima libreria a esporre un motore di inferenza basato su WebGPU per i modelli TensorFlow-Lite, e Google riporta un incremento di velocità di tre volte. Test indipendenti mostrano un guadagno ancora maggiore, sollevando il dubbio che WebGPU possa diventare il percorso predefinito per il machine learning sul web.

Come è stato eseguito il test

Abbiamo testato due modelli di classificazione delle immagini — MobileNetV2 ed EfficientNet-Lite4 — entrambi convertiti in TensorFlow-Lite. I test sono stati eseguiti su un chip Apple-silicon M2 Max. Per ogni modello abbiamo misurato la latenza di un singolo passaggio in avanti (forward pass) su molte iterazioni e riportato i fotogrammi al secondo (FPS). Abbiamo eseguito gli stessi modelli con TensorFlow.js sul backend WebGL e registrato il tempo di avvio a freddo (cold-start) di ciascuna libreria.

Risultati: velocità e avvio

  • MobileNetV2

    • LiteRT.js (WebGPU): latenza di 0,41 ms → 2.439 FPS
    • TensorFlow.js (WebGL): latenza di 10,82 ms → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): latenza di 0,62 ms → 1.623 FPS
    • TensorFlow.js (WebGL): non riportato, ma MobileNetV2 mostra già un vantaggio di oltre 25 volte.

TensorFlow.js ha impiegato circa 10 secondi (10.014 ms) per compilare i suoi shader WebGL prima della prima inferenza. LiteRT.js era pronto in 4,3 ms, eliminando essenzialmente la penalità del cold-start per le applicazioni interattive.

Quando abbiamo quintuplicato la dimensione del modello, la latenza è aumentata solo del 50%, confermando che il parallelismo della GPU assorbe la maggior parte del lavoro extra. Il risultato è una frontiera delle prestazioni che consente a un browser di gestire flussi video in tempo reale, overlay di realtà aumentata (AR) o prototipazione rapida di modelli di visione senza dover ricorrere a chiamate al server.

Cosa nascondono i numeri

  • Batching – La maggior parte dei modelli TensorFlow-Lite blocca la dimensione del batch a 1. L'inserimento di più immagini in una singola chiamata non è supportato nativamente, costringendo gli sviluppatori a creare Web Worker o a gestire manualmente la pipeline degli input.
  • Gestione della memoria – LiteRT.js non esegue automaticamente il garbage collection dei tensori GPU. Gli sviluppatori devono chiamare .delete() su ogni tensore creato, pena il rischio di esaurire la memoria della GPU dopo poche centinaia di inferenze.
  • Copertura hardware – WebGPU è stabile su Chrome e Firefox per desktop. I browser mobili — inclusi Chrome su Android e Safari su iOS — espongono l'API solo tramite flag sperimentali o non la espongono affatto. Su queste piattaforme, il backend WASM rimane l'unica via universalmente disponibile, ma è notevolmente più lento per i modelli più grandi.

Questi vincoli significano che, sebbene la velocità pura sia impressionante, l'impegno ingegneristico necessario per raggiungerla può non essere banale.

Limitazioni e compromessi

Il backend WebGL di TensorFlow.js offre ancora una compatibilità quasi universale. Uno sviluppatore che si rivolge a un pubblico misto — desktop, Android, iOS — può fare affidamento su un unico percorso di codice che funziona ovunque, sebbene con un throughput inferiore. Il backend WASM funziona su quasi tutti gli hardware, ma resta indietro rispetto a WebGPU per i modelli più grandi misurati in questo test.

LiteRT.js eccelle quando l'obiettivo è un ambiente desktop con WebGPU abilitato. Esegue direttamente i modelli .tflite, consentendo agli sviluppatori di prelevare modelli da Hugging Face o Kaggle senza conversione, preservando la quantizzazione e le prestazioni originali. Il compromesso è un ambito di distribuzione più ristretto e la necessità di una gestione attenta delle risorse.

Cosa dovrebbero considerare gli sviluppatori

  • Piattaforma di destinazione – Per uno strumento desktop esclusivamente web (ad esempio, un'app di design che applica il trasferimento di stile in tempo reale), WebGPU con LiteRT.js è probabilmente la scelta migliore.
  • Dimensione del modello – I modelli più grandi e pesanti dal punto di vista computazionale beneficiano maggiormente del parallelismo della GPU; i modelli più piccoli potrebbero non giustificare l'impegno ingegneristico extra.
  • Disciplina della memoria – Pianificare la cancellazione esplicita dei tensori o racchiudere le chiamate di inferenza in uno scope che liberi automaticamente le risorse.
  • Strategia di fallback – Prevedere un fallback WASM o WebGL per i browser che non possono abilitare WebGPU, mantenendo l'app funzionale per un pubblico più ampio.

In sintesi

LiteRT.js dimostra che WebGPU può spingere l'inferenza basata sul web nel regime dei sub-millisecondi, offrendo una velocità superiore a 25 × quella di TensorFlow.js sulle GPU desktop. La tecnologia è ancora in fase di maturazione e gli sviluppatori devono gestire i limiti del batching, la pulizia manuale della memoria e il supporto limitato per i dispositivi mobili. Per le esperienze desktop-first che richiedono prestazioni in tempo reale, la nuova libreria offre un percorso promettente; per una portata cross-platform, i più datati backend WebGL e WASM rimangono essenziali.