AI on‑device: modelli, runtime e backend per tenere i dati in locale

Un turno di reperibilità, un muro di log, nessuna voglia di copiare righe in un prompt remoto. logwhisper legge il file, usa Llama 3.2 con Ollama, spiega cosa è successo senza inviare nulla fuori dal computer. È una CLI in Go, non chiede chiavi API. La diagnosi resta in locale¹. Tesi: l’esecuzione on‑device non è più un esperimento. Sta diventando un’opzione concreta grazie a modelli aperti, motori multipiattaforma e backend nativi. Porta privacy e latenza sotto controllo, ma impone scelte operative chiare su modelli, contratti di coda e integrazione hardware.

Modelli open e pratici per l’esecuzione locale

Hugging Face ha pubblicato Carbon‑X, 14,8 miliardi di parametri, decoder‑only. Unifica DNA e testo nello stesso flusso di token. Parte da Qwen3‑14B, licenza Apache 2.0, contesto fino a 40.960 token⁴. L’inferenza gira su una sola GPU da 80 GB in bfloat16 con vLLM o Transformers. Sono disponibili file GGUF ufficiali: Q8_0 da 15,8 GB e Q4_K_M da 9,6 GB⁴. La fonte lega licenza e possibilità di esecuzione su GPU proprie alla tutela di sequenze sensibili, in sede⁴. Il punto non è solo il laboratorio: è il segnale che modelli utili e aperti arrivano pronti per girare dove servono, senza passaggi obbligati nel cloud.

Sul fronte “fare oggi”, logwhisper mostra un uso mirato. Legge righe di produzione, organizza eventi con etichette come “Slow query” e durate in millisecondi. Esegue Llama 3.2 tramite Ollama, in locale. Gli esempi indicano modelli llama3.2:3b e llama3.2:1b. Nel repository c’è un production.log di prova per riprodurre l’esperienza con un comando minimo¹. Qui la leva non è il benchmark, è la frizione rimossa: niente copia‑incolla su servizi esterni, niente chiavi, nessuna uscita dei dati dalla macchina¹.

Questa coppia di casi, Carbon‑X e logwhisper, mette insieme due aspetti. Da un lato modelli open con formati e quantizzazioni ufficiali. Dall’altro flussi concreti che girano davvero su macchine degli utenti. Il vincolo operativo diventa scegliere un modello che stia in memoria e che risponda nel tempo previsto dal compito.

Runtime e motori multipiattaforma per inferenza on‑device

Il modello non basta se l’hardware cambia a ogni dispositivo. ML Drift nasce per questo. Google ha aperto il motore GPU che alimenta LiteRT, licenza Apache 2.0. Astrazione sopra API eterogenee: OpenGL ES, OpenCL, Metal e WebGPU compaiono tra le interfacce supportate. Obiettivo dichiarato: portabilità e prestazioni per inferenza on‑device, sia per pipeline classiche sia per generative AI⁵. Chi sviluppa su edge device conosce il problema: driver e versioni di API cambiano da prodotto a prodotto. Un motore comune riduce il codice da riscrivere, isola dai dettagli del target⁵.

Qui c’è un filo con i modelli quantizzati. Se puoi passare da OpenCL a Metal senza rifare il grafo, testare Carbon‑X in Q4_K_M o un piccolo Llama locale diventa lavoro ripetibile. Ma la promessa di portabilità non elimina la verifica. Latenza e qualità vanno misurate sul device reale, non su un unico reference.

Backend nativi per acceleratori e semplicità del porting

Sul training e sull’inferenza accelerata, la semplificazione arriva dai backend nativi. Google e Meta hanno presentato TorchTPU il 21 ottobre alla PyTorch Conference North America 2026 a San Jose. È un backend PyTorch nativo per le TPU di Google. Sostituisce PyTorch/XLA, il bridge del 2020 basato su lazy tensor che, secondo l’annuncio, richiedeva modifiche intrusive al codice³. L’obiettivo è chiaro: portare un modello su TPU con un cambio di device, da model.to("cuda") a model.to("tpu"). “Con TorchTPU, le TPU si uniscono a GPU e CPU come opzione nativa per PyTorch”, ha scritto Google Cloud. L’annuncio è cofirmato da Bill Jia, vicepresidente dell’ingegneria per Core ML/AI³.

Per chi mantiene una base PyTorch e deve scegliere dove far girare il carico, questo riduce il costo del porting. La semplificazione tecnica però non risolve da sola i nodi operativi. Serve compatibilità con librerie e runtime scelti per l’on‑device. E, soprattutto, servono misure di latenza e affidabilità in linea con il servizio che si espone.

Prompt API e capacità browser‑side: opportunità e limiti

Da Chrome 148 sul web e 138 nelle estensioni, una pagina o un’estensione può chiedere al browser di riassumere, classificare o riscrivere testo in locale con Gemini Nano. Senza API key e senza fatturazione per token⁶. La chiamata resta sul dispositivo: la pagina invia il prompt, riceve la risposta, non spedisce i dati al server. Per gli sviluppatori di estensioni cambia la categoria: l’IA si aggiunge alle capacità del browser, come storage e notifiche, quando l’ambiente la supporta⁶.

Il dettaglio operativo è cruciale. Il modello si scarica al primo utilizzo. Può essere assente per limiti hardware o di spazio. L’API espone superfici diverse tra web ed estensioni. Senza una rilevazione seria delle funzionalità e un fallback, il pulsante “smart” diventa morto per una parte degli utenti⁶. Qui il contratto non è più solo tra server e runtime. È tra interfaccia e capacità del client.

Implicazioni operative: contratti di servizio, latenza e affidabilità

Un’immagine splendida in notebook non salva una coda inceppata. Il rischio operativo tipico, racconta chi ha messo in produzione un sistema che genera materiale visivo da testo di fatture fornitore, è la lentezza e la duplicazione dei job. Il problema scatta con un timeout, un limite di richiesta. Il demo non era una prova di prontezza. Mancava il contratto della coda². La regola è secca: la scelta del modello parte da una soglia di qualità misurata che stia dentro budget di latenza e retry della tua app. Se non ci sta, si scarta. DALL‑E 3, SDXL e Flux sono candidati da mettere alla prova, non decisioni. Il confine applicativo va tenuto portabile, così cambi dipendenza senza rifare l’app².

Questa è la cartina di tornasole anche per l’on‑device. Log in locale, modelli GGUF, motori multipiattaforma, Prompt API: riducono dipendenza dal cloud e l’esposizione dei dati. Impongono però nuovi vincoli. Disponibilità di risorse locali. Tempi di download del modello. Compatibilità con API grafiche. Assenza del modello sul device dell’utente. Senza test end‑to‑end su questi punti, la bella idea resta un rischio. Le fonti lo dicono in chiaro: servono misure di latenza, piani di retry e idempotenza nelle code. Altrimenti anche un modello in locale può generare duplicazioni e blocchi^1,2,5,6.

Il quadro che emerge lega scelte tecniche e contratti operativi. Carbon‑X mostra che si può portare in sede modelli di dominio con licenza aperta e supporto a quantizzazione. TorchTPU promette porting più lineare su acceleratori. ML Drift prova a stendere un tappeto unico sulle GPU di molti dispositivi. La Prompt API inserisce un modello nel browser, come una funzione di sistema. La decisione su cosa usare, e dove, resta vincolata da una domanda semplice: cosa garantisco all’utente in termini di tempo e affidabilità, e con quali risorse presenti sul dispositivo.

L’ultima implicazione tocca l’organizzazione del codice. Se il confine applicativo resta portabile, come suggerisce l’esperienza in produzione sul generatore di immagini, si può sostituire il modello o il backend senza rifare l’app². Oggi questo significa scrivere feature detection seria per il client, astrarre le dipendenze da API grafiche, prevedere file di modello e formati supportati, e misurare sempre latenza e retry su dispositivi reali. Domani, significa avere margine per spostare carichi tra locale e acceleratori nativi quando le condizioni cambiano, senza rinegoziare il servizio ogni volta.