sperimentare l’API di Cross-Origin Storage proposta con Transformers.js

Transformers.js offre una piattaforma semplice per sfruttare la potenza dei transformer all’interno delle applicazioni Web tramite pipeline dedicate a determinati compiti. Per eseguire infezioni nel browser, gli sviluppatori creano un'istanza di pipeline() e specificano il compito che desiderano utilizzare.

Ad esempio, il seguente frammento mostra come configurare una pipeline per il riconoscimento automatico della voce.

Noterete nel codice che ho specificato Xenova/whisper-tiny.en come modello, una scelta eccellente per compiti comuni di riconoscimento automatico del parlato in inglese. Infatti, è perfino il modello predefinito di Transformers.js, come indicato nell'estratto collegato in materia di risoluzione predefinita di modello.

Quando esegui questo esempio nel browser, Transformers.js scarica automaticamente e memorizza in cache le risorse relative al modello e i file WasM. La seguente immagine mostra la sezione Storage delle cache di Chrome DevTools dopo aver visitato l’app. Al momento del caricamento della pagina, le risorse vengono sfruttate da Cache API e il modello restituisce i risultati quasi istantaneamente.

Tuttavia, considerando che Xenova/whisper-tiny.en è un modello popolare (ed è anche il modello predefinito per riconoscimento automatico del parlato in Transformers.js), facilmente si può capire che non solo un’app che visitiamo potrebbe usarlo.

Per simulare questa situazione, ecco lo stesso esempio di app, ma servito da un origine diversa. Quando visiti questa app da un’altra origine, invece di essere utilizzabile quasi istantaneamente, il browser deve scaricare e memorizzare in cache nuovamente tutte le risorse del modello, anche se sono byte a byte identiche. Anche in questo semplice esempio, si accumulano 177 MB di download duplicati e memoria, che puoi controllare nella sezione Storage del pannello Applicazione di Chrome DevTools. Immagina come si accumulerebbero in modelli più complessi.

Benché peggio ancora, aggiungiamo una seconda pipeline all’esempio: l’analisi del sentiment. Per l’analisi del sentiment, il modello predefinito è Xenova/distilbert-base-uncased-finetuned-sst-2-english. Specificando questo modello, Transformers.js usa la sua risoluzione per preselezionarlo automaticamente.

Due modelli di AI del tutto diversi, ma che condividono un file di runtime WebAssembly (Wasm) di 4,733 kB chiamato ort-wasm-simd-threaded.asyncify.wasm. Questo file è parte della libreria ONNX Runtime sottostante su cui si basa Transformers.js. Apri la demo estesa da un’origine diversa e noterai come anche il file Wasm venga scaricato e memorizzato in cache nuovamente.

Quindi, persino se stai eseguendo applicazioni non condividono gli stessi modelli AI, il tuo browser esegue richieste ridondanti per risorse Wasm condivise che hai già, e memorizza di nuovo le risorse nella cache, che occupa spazio sul tuo disco.

Le risorse dei modelli di AI proveniamo, in genere, dal Hugging Face Hub, che a sua volta usa la CDN di Hugging Face. Il browser fa una richiesta per una risorsa tipo https://huggingface.co/.../config.json, che viene reindirizzata su URL CDNs tipo https://huggingface.co/.../config.json?%.

Le risorse Wasm, invece, sono generalmente prese dal CDN di jsDelivr. Ad esempio, il file ort-wasm-simd-threaded.asyncify.wasm si trova in https://cdn. jsDelivr/.../ort-wasm....

Probabilmente penserai che, se due app diverse (sebbene sull’origin differente) usano le stesse URL di CDN alla fine, la memorizzazione in cache non dovrebbe essere un problema, fin tanto che le URL finali sono identiche. Purtroppo, non è così che funzionano le cache in browser. L’articolo Gaining security and privacy by partitioning the cache va nei dettagli, ma in sintesi, le cache sono isolate per origine per prevenire attacchi di timing: il tempo che un sito impiega a rispondere è un rischio per la privacy e la sicurezza.

La concreta implementazione può variare in base al browser, tuttavia in Chrome le risorse cache sono chiave utilizzando una chiave di isolamento di rete, aggiunta all'URL risorsa. La chiave di isolamento di rete è composta dal sito a livello superiore e dal sito del frame corrente. Prendiamo in esame gli esempi di demo precedenti ospitati sugli origini https://googlechrome.github.io e https://rawcdn.rawgit.net. Se entrambi usano lo stesso file Wasm da un CDN, le loro chiavi di memoria saranno simili a quelle elencate nella tabella seguente.

Quindi, persino se gli URL delle risorse sono esattamente gli stessi, dato che le chiavi di isolamento di rete non corrispondono, non c’è cache match, il che significa download duplicato e storage duplicato. Questo è il tipo di problematica che l’API proposta di Cross-Origin Storage cerca di affrontare.

Come funziona API Cross-Origin Storage

L’API proposta Cross-Origin Storage (COS) introduce un interfaccia navigator.crossOriginStorage dedicata, attraverso la quale l’applicazione Web potrà salvare e recuperare grandi file tra confini diversi di origini, individuati non da un URL ma da un hash crittografico.

Più specificamente il punto cruciale è che COS identifica i file utilizzando un hash e non URL o origin. Questo permette a risorse come ort-wasm-simd-threaded.asyncify.wasm scaricate da https://googlechrome.github. io di essere riconosciute identiche a quelle che https://rawcdn.rawgit.net richiede, per qualsiasi origine in cui venga caricato il file. Il seguente snippet mostra come si usa il flusso base.

Se la risorsa è presente in COS, riceverai un oggetto FileSystemFileHandle da cui puoi leggere il blob direttamente tramite getFileHandle() (il risultante File eredita da Blob). Se la risorsa non è presente in COS, il fallback cade su di