AI on‑device: runtime GPU, API browser e quantizzazione rendono l'inferenza pratica

Negli ultimi mesi l'AI on‑device è diventata praticabile grazie a runtime GPU open e portabili, API browser che eseguono modelli in locale, quantizzazioni estreme che comprimono grandi LLM e progetti hardware che portano capacità di edge compute fuori dal cloud.

Chrome abilita Gemini Nano sul dispositivo da Chrome 148 sul web e da Chrome 138 nelle estensioni. Niente API key, niente fatturazione per token. La chiamata resta nel perimetro del client³. In parallelo, Google apre ML Drift con licenza Apache 2.0, un motore GPU che astrae backend diversi e alimenta LiteRT¹. Sul fronte dei modelli, Saluki 27B porta Qwen3.8‑27B a 7,9 GB mantenendo il function calling nei test degli autori⁵. Tesi: l’AI on‑device smette di essere un esercizio isolato. Sta diventando una filiera praticabile, dal runtime alle API, fino al packaging dei modelli e all’hardware di campo.

Un unico motore per GPU eterogenee

ML Drift promette un’unica base per eseguire modelli su GPU diverse. Astrae differenze tra hardware e API a basso livello. Supporta OpenGL ES, OpenCL, Metal e WebGPU¹. L’obiettivo è concreto: portabilità e prestazioni per inferenza multipiattaforma, senza riscrivere codice per ogni piattaforma¹. Google sintetizza il target così: stabilità per il machine learning tradizionale e picchi per la generative AI¹.

Per chi sviluppa su edge device, l’eterogeneità è la norma. Cambiano architetture GPU, driver, versioni delle API. ML Drift nasce per attraversare questo panorama con una base comune, riducendo la dipendenza dai dettagli di implementazione e dall’hardware di destinazione¹. Il codice aperto permette di costruire runtime e grafici personalizzati a partire dal motore GPU¹. È un passaggio tecnico, non di immagine. Sposta l’attenzione dal porting ad hoc alla definizione di pipeline di inferenza riutilizzabili.

Per i team, la conseguenza è operativa. Se il runtime isola i backend, test e QA devono coprire le superfici che restano: memoria disponibile, comportamenti dei driver, differenze tra API supportate. La promessa di portabilità regge se la si verifica con suite riproducibili su dispositivi reali.

Il browser come piattaforma per modelli locali

Con la Prompt API stabile, una pagina o un’estensione chiedono al browser di riassumere, classificare o riscrivere testo in locale con Gemini Nano³. L’inferenza avviene sul dispositivo. L’estensione o il sito inviano il prompt e ricevono la risposta. I dati dell’utente non devono più uscire per chiamare un modello linguistico³. Per chi sviluppa estensioni, è uno spostamento di categoria. L’intelligenza artificiale si aggiunge alle capacità del browser, come lo storage o le notifiche³.

Non è plug‑and‑play. Il modello si scarica al primo utilizzo. Può essere assente per limiti hardware o di spazio di archiviazione. L’API espone superfici diverse tra ambiente web ed estensioni³. Senza una rilevazione accurata delle funzionalità e un fallback, il pulsante “smart” diventa morto per una parte degli utenti³. Qui il legame con i runtime emerge: la disponibilità del modello e delle risorse locali diventa una condizione di esecuzione al pari della compatibilità GPU.

La novità riduce anche dipendenze organizzative. Se l’inferenza resta nel client, non serve gestire chiavi o quote per le operazioni base³. Cambia il disegno dei flussi dati. Cambiano anche le responsabilità: serve controllare la presenza del modello, la gestione dello spazio e i percorsi di degrado funzionale quando l’API non è disponibile³.

Quantizzazione estrema senza perdere tool‑calling

Saluki 27B dichiara circa due bit per peso. Comprimi Qwen3.8‑27B in 7,9 GB e, nei test degli autori, superi la build da 54 GB su 120 task di function calling presi dal Berkeley Function Calling Leaderboard⁵. La valutazione parte dai file GGUF in una copia di llama.cpp senza modifiche. Gli autori affiancano la loro build alla quantizzazione di riferimento, poi eseguono un diff degli header tensor per tensor e un confronto byte per byte del contenuto⁵. Passano al runtime. Caricano i modelli in llama.cpp su una singola GPU e leggono l’uso in esecuzione⁵.

La domanda che guida il lavoro è chiara: Saluki è un remix dei bit esistenti o modifica la rappresentazione? L’analisi tenta di rispondere con metodi riproducibili, non con benchmark opachi⁵. Per chi deve far girare LLM su device con risorse limitate, questo approccio è un modello. La riduzione del footprint ha senso se mantiene funzioni come il tool‑calling. Serve però un audit funzionale focalizzato sui casi d’uso reali, non solo sui punteggi sintetici.

Il quadro si lega agli altri tasselli. Un runtime portabile rende più facile sfruttare quantizzazioni aggressive su GPU diverse. Un’API client come la Prompt API chiarisce dove vive il modello e come gestire lo storage. Insieme, questi elementi spostano il perimetro dell’AI dal data center al client, quando i vincoli locali lo permettono.

Hardware e interfacce praticabili per l’edge

La computazione locale richiede un supporto fisico credibile. The Slurptop mostra un PC x86 alimentato da batterie per utensili, costruito in due mesi e documentato passo passo su Slurpburgers². L’autore scarta l’idea di una scheda mITX con Intel N50 o N100 e PicoPSU. I costi e l’assorbimento non lo convincono. Vira su un mini PC con CPU da laptop e su un case trasportabile². La scelta non è estetica. Nasce da vincoli di prestazioni per watt e dalla volontà di evitare una scheda nuda². Il nome, Slurptop, dichiara l’intento: un “laptop” autocostruito, pensato per andare in giro. L’alimentazione con batterie per utensili è parte del progetto, non un accessorio².

Sul fronte delle interfacce, la National University of Singapore mostra un tessuto elettronico lavabile. Resiste a cinquanta lavaggi in lavatrice e a mille piegature senza perdere funzionalità, secondo il resoconto giornalistico. Il prototipo trasforma una manica di lana in superficie interattiva. Richiede batterie e controller esterni. L’obiettivo è spostare l’elettronica verso architetture native del tessuto, con funzioni che visualizzano, rilevano, comunicano e calcolano. Il lavoro è guidato dal research engineer Fu Heng e viene riportato su Nature questa settimana⁴.

Il messaggio è coerente. L’edge non è solo modello e runtime. È alimentazione, robustezza d’uso, interazione fisica. Un PC a batterie per utensili e una manica che diventa interfaccia toccabile tracciano la stessa direzione: portare capacità computazionali vicino al gesto, fuori da un rack o da una chiamata remota.

Cosa cambia per sviluppo, QA e deployment

Combinare un motore GPU portabile come ML Drift, un’API client‑side come la Prompt API e una quantizzazione come Saluki riduce dipendenze da servizi esterni e introduce nuove condizioni locali di esecuzione^1,3,5.

Il nuovo stack introduce obblighi precisi:

Test cross‑GPU e cross‑API per verificare la promessa di portabilità del runtime¹.
Gestione del download, dello spazio e dei fallback per modelli che il browser può installare o negare per limiti hardware³.
Audit della qualità e delle funzioni dopo quantizzazione, con confronti riproducibili su file e in runtime, come mostrato da Saluki⁵.

Anche il packaging operativo conta. Slurptop ricorda che i profili di consumo e i costi reali cambiano le scelte di piattaforma². Il tessuto lavabile di Singapore segnala un’altra esigenza: interfacce robuste e native del contesto d’uso, anche quando l’alimentazione e il controllo restano esterni⁴. Quando i modelli si scaricano al primo utilizzo e i runtime astraggono l’hardware, il margine di miglioramento passa da più FLOPS a gestione locale, fallback affidabili e progettazione delle interfacce sul campo.