AI On-Device
Cooking from your fridge with Gemini Nano, MobileCLIP and Gemma
Salvatore Matrisciano · Stefano Soriano · Mobile Developers
Cosa succede quando decidi di far girare tutta l’AI della tua app direttamente sul telefono?
Niente cloud. Niente API key. Nessuna foto della cucina dei tuoi utenti su un server.
Oggi, quando aggiungiamo una feature AI a un’app, ci viene quasi in automatico: prendo una API key, chiamo un modello nel cloud, mando la richiesta, aspetto la risposta. Ogni richiesta che mandi a un server è una cosa in più da proteggere, da giustificare, da spiegare all’utente nella privacy policy, e anche, soprattutto, da pagare.
AI Pantry: scansiona il frigo, ottieni la cena
L’app si chiama AI Pantry: Dispensa AI, e l’idea è molto semplice: fai una foto al frigo e ottieni un’idea di ricetta per cena.
Fotografi il frigo, riconosce gli ingredienti
Funziona così. Prima fai una o più foto al tuo frigo, e l’app riconosce gli ingredienti che vede. Quello che sta succedendo adesso è la parte di percezione: l’app sta capendo quali ingredienti ci sono nella foto, zona per zona, e li vedete comparire appena li trova. Nel corso del talk vi spieghiamo perché questa parte, all’inizio, ci metteva minuti, e come l’abbiamo portata a pochi secondi.
Gli ingredienti trovati, con la confidenza
Eccoli. . Ognuno ha la sua confidenza, e quelli sotto una certa soglia vengono già scartati. Se qualcosa è sbagliato, lo tolgo con la X. E guardate questa riga: l’app vi dice quale motore ha fatto il lavoro. Su questo telefono è . Tenetelo a mente, perché è il cuore del talk.
Si ricorda la tua dispensa
Poi con quelle foto costruisce l’inventario della tua dispensa. Quindi l’app si ricorda cos'hai. Faccio lo stesso con la dispensa. Le due scansioni si sommano. Aggiungo tutto. E questo è l’inventario, salvato in locale sul telefono.
Ti propone cosa cucinare e scrive la ricetta
Qui entra in gioco un modello diverso, un LLM vero e proprio, Gemma, perché inventare una ricetta è un compito completamente diverso dal riconoscere un’anguria. Anche questo lo vedremo nel dettaglio. Ecco quattro idee per la cena, con tempo e difficoltà. Sono ordinate in base a quanto usano quello che ho davvero: quelle che richiedono di comprare qualcosa finiscono in fondo, e l’app mi dice cosa mi manca. E se non mi convincono, “Altre ricette” me ne propone altre quattro.
La ricetta completa, scritta sul momento
Apro questa. Quantità e passaggi non esistevano finché non l’ho aperta: li sta scrivendo adesso, qui sul telefono.
100% on-device: foto e prompt non escono dal telefono
E il punto centrale è che è tutto al 100% on-device. E vi ricordo: modalità aereo. Nessuna chiamata di rete. Nessun costo per chiamata. Nessuna foto di questo frigo è finita su un server.
Dall'inizio alla fine, dal telefono
La registrazione dello schermo usata come piano B del talk: scansione del frigo e della dispensa, quattro ricette, il procedimento che si scrive passo dopo passo.
Circa 3 minuti e mezzo, app in italiano. Le schermate di questa pagina sono fotogrammi dello stesso video.
Perché on-device?
Privacy, prima di tutto
E una foto del frigo racconta molto più di quanto si possa pensare: abitudini alimentari, allergie, magari condizioni di salute, e a volte anche un pezzo di casa sullo sfondo.
Nessun server che vede le foto
Le foto della cucina non escono dal telefono.
Nessun Data Processing Agreement (DPA)
Nessun fornitore riceve le foto: niente da firmare.
Nessun problema di data retention
Se non memorizzi mai dati, la retention non è un problema.
Nessun log da far trapelare
Il dato più sicuro è quello che non hai mai raccolto.
…poi resilienza e costi
E un frigo si trova in cucina, magari in una casa vecchia, magari in una taverna o in un seminterrato, o comunque può trovarsi in posti dove internet non prende. Più l’app ha successo, più costa.
Funziona anche senza internet
Senza rete, in modalità aereo, con segnale debole (anche in cucine seminterrate)
Nessun round-trip verso il server
Niente latenza di rete: il “backend” è già in tasca.
Il costo del cloud cresce con l’uso
Ogni foto si paga, per ogni utente, ogni giorno.
On-device ribalta il costo
L’inferenza gira sul telefono dell’utente: bolletta cloud a zero.
Quindi: privacy, resilienza e costi.
Due strade, e nessuna delle due andava bene
La scelta ovvia: Gemini Nano
✓ Già nel sistema operativo, multimodale
✓ Una dipendenza, zero megabyte nell’APK
✓ Accelerazione hardware e aggiornamenti gestiti da Google
Perfetto. Tranne che…
Gira solo sui flagship più recenti.
Pixel 10/11, Galaxy S26 e pochi altri top di gamma:
non i telefoni che la maggior parte della gente ha davvero.
Quindi abbiamo capito subito: Gemini Nano poteva essere un bonus, ma non poteva essere la base della nostra app.
Un solo LLM multimodale per fare tutto
Gemma 4 E2B · Il modello open di Google: lo porti tu, gira anche dove Nano non c’è (con abbastanza RAM).
Ha funzionato. Ingredienti corretti, JSON valido, ricette vere.
Ma ci metteva 5-10 minuti per scansione
Su un Pixel 7, un telefono di quattro anni fa. Nessuno aspetta 10 minuti per un’idea per cena.
Quindi avevamo due strade (Gemini Nano e Gemma) e nessuna delle due andava bene: una veloce ma solo per pochi, e una per tutti ma inutilizzabile.
Come l’abbiamo risolto, in cinque capitoli
Vi spoilero già il finale, così non c’è suspense: alla fine abbiamo usato tutti e 3 i modelli. Ma ognuno per un compito diverso, e il punto principale è capire perché.
Il protagonista: Gemini Nano
Il modello vive in AICore, non nella tua app
E c’è un vantaggio da non sottovalutare: se 10 app sullo stesso telefono usano Gemini Nano, il modello sul disco è uno solo. Non dieci copie da qualche gigabyte ciascuna
AICore è un servizio di sistema Android
Gestisce pesi, storage, aggiornamenti e accelerazione hardware, la tua app non tocca mai un file del modello.
Prompt multimodali:
foto + testo in, testo out
Gira su pesi che non devi mai distribuire, scaricare o aggiornare.
Come la fotocamera o il GPS
È una capability del sistema, non una cosa da impacchettare nell’app. Ma proprio perché è una capability del sistema, può esserci o non esserci.
Una dipendenza, una regola: verifica, poi chiama
Si controlla a ogni chiamata: la disponibilità cambia a runtime.
La cosa più importante è che lo stesso telefono può rispondere in modo diverso nel tempo. Quindi quel check non si fa una volta all’avvio: si fa ogni volta.
Il protagonista: Gemma 4 E2B
Chiedi all’LLM di guardare, e di scrivere
Poi mandiamo foto e prompt nella conversazione, prendiamo il testo, facciamo il parsing del JSON, e se è malformato riproviamo in silenzio. Ci torneremo, su questo. Da notare anche il limite di quindici elementi: non è casuale.
Il rilevamento come problema di prompting: nessun dataset, nessun training. Basta chiedere. Cosa potrebbe andare storto?
Il costo a due fasi degli LLM multimodali
Prima di scrivere anche solo una parola, il modello deve leggere tutto l’input. E la nostra foto non è “un’immagine”: per il modello diventa qualche centinaio di token immagine.
Fase 1: prefill
La foto diventa centinaia di token immagine, tutti elaborati prima che compaia qualsiasi output.
Fase 2: decode
La risposta è generata un token alla volta attraverso un modello da 2 miliardi di parametri.
Scansione di 5-10 minuti su fascia media
L’aritmetica, non la qualità del modello, decide tra secondi e minuti.
Conosci questo modello di costo
Prima di promettere qualsiasi UX multimodale.
Sul telefono, con memoria condivisa, limiti termici e una batteria da non prosciugare, ogni token si sente. Prima di dire al product owner “facciamo scattare una foto e l’AI capisce tutto”, fate questo conto.
Il protagonista: MobileCLIP-S2
Il riconoscimento non richiede un modello che scrive, ma uno che confronta
Sono stati addestrati su milioni di coppie immagine–didascalia, in modo che una foto e la frase che la descrive finiscano vicine nello stesso spazio vettoriale. La foto di un’arancia e la frase “una foto di un’arancia” diventano due vettori che puntano più o meno nella stessa direzione.
E il bello della similarità del coseno è che è un numero: da meno uno a uno. Niente JSON da parsare, niente allucinazioni in forma di testo: al massimo un punteggio basso.
Il vocabolario l’abbiamo costruito noi, ed è un file di testo
Il “classificatore” è un file di testo: vuoi un ingrediente in più? Aggiungi una riga.
Calcolati una volta, sul laptop
Per ogni etichetta usiamo quattro template, tipo “una foto di un’arancia”, e facciamo la media dei vettori, che rende il risultato più robusto. Il risultato sono circa 4,5 megabyte di vettori, inclusi nell’APK.
Sul telefono gira solo l’image encoder
Il flusso è: ritagliamo la foto in tanti crop, a due scale diverse, calcoliamo l’embedding di ogni crop, confrontiamo col coseno contro tutte le etichette, e vincono le corrispondenze migliori, sopra una soglia di confidenza.
Stesso telefono. Stessa foto del frigo.
Ed è la lezione più importante di tutto il talk: prima di ottimizzare il modello, chiedetevi se è il modello giusto per quel compito.
Il protagonista: Gemma, il ritorno
Quindi il costo a due fasi, che prima ci aveva ucciso, adesso gioca a nostro favore: prefill minuscolo, e decode che produce proprio quello che vogliamo. Nel rilevamento la creatività era un difetto; qui diventa il prodotto.
Le ricette sono creazione, non riconoscimento
Da un inventario a idee per la cena È per questo che esistono i modelli generativi, nessun vocabolario chiuso può farlo.
Prompting a due stadi
Prima una lista economica, poi la ricetta completa su richiesta, prompt più corti, meno attesa. Prima chiediamo una lista di cinque ricette, con titolo, tempo, difficoltà e ingredienti usati, ma senza procedimento.
Parsing JSON difensivo con retry silenziosi
I modelli piccoli rompono i contratti di formato, prevedilo, non scusarti. In pratica: togliamo i blocchi markdown, estraiamo tutti gli oggetti JSON che troviamo, accettiamo anche nomi dei campi scritti in modo diverso, e se una sola ricetta è rotta scartiamo quella, non tutta la lista.
La generazione solo testo va a 15–25 tok/s
Senza foto, niente prefill dell’immagine: si aspetta solo il testo. E siccome la lista è leggera, e i passaggi li generiamo solo per la ricetta che aprite, l’attesa resta breve.
E così si vede, sul telefono, una ricetta che arriva token dopo token (il testo è quello della demo):
Ogni modello viaggia in modo diverso
Perché avere tre modelli è bello, ma poi bisogna farli arrivare sul telefono.
AI pack tramite Play for On-device AI
Google Play gestisce la consegna, la distribuzione smette di essere un tuo problema.
E potete scegliere quando consegnarlo: all’installazione, in modalità fast-follow, cioè subito dopo l’installazione, in background, oppure on demand. Noi usiamo fast-follow. E siccome Play ha un limite di dimensione per singolo pack, abbiamo diviso Gemma in tre AI pack: al primo avvio l’app li riassembla nel modello, e poi i pack vengono rimossi per non occupare spazio 2 volte.
Questo ha un vantaggio enorme: il rilevamento funziona subito dopo l’installazione, anche offline, anche al primo avvio. E c’è anche un tema di esperienza utente: non potete chiedere a qualcuno di scaricare 2,6 giga al primo avvio, magari in 4G.
Tre modelli, tre compiti, un’app
Tutti i motori di rilevamento implementano lo stesso contratto.
Gemini Nano: l’acceleratore
Rilevamento multimodale gratuito sui flagship, protetto da checkStatus().
MobileCLIP-S2: la base
Rilevamento zero-shot in secondi, su ogni telefono.
Gemma: il creatore
Ricette generate on-device: il compito che solo un LLM sa fare.
Una sola interfaccia nel codice
La UI non sa mai quale motore ha risposto.
In pratica è un pattern che conosciamo benissimo: un’interfaccia, più implementazioni, e una piccola strategia che sceglie a runtime la migliore disponibile. Questo permette di aggiungere, togliere o sostituire modelli senza toccare una riga di UI.
Punti chiave
Prima di chiedervi come renderlo più veloce, chiedetevi se è il modello giusto.
Tutti questi punti non valgono solo per un’app di ricette. Il pattern è sempre lo stesso: percezione economica come base, generazione dove serve davvero, e piattaforma come upgrade.
Avevamo detto cinque…
Il protagonista: EmbeddingGemma 2
Per ora, su un Pixel 7, è più lento di MobileCLIP: circa 40 secondi foto, contro circa 20. Ma è uscito martedì: diamogli tempo.
DevFest Milano 2026, in foto
Tutte le foto del talk, nell’ordine in cui sono state scattate, e uno spezzone di 35 secondi. Tocca una foto per aprirla in grande e scorrere la galleria.