Agenti on-device per il telefono: cosa portano davvero i mobile agent open (dopo OpenMobile-2)

Un mese fa un agente poteva usare il tuo telefono solo in teoria: esistevano modelli addestrati su screenshot, ma niente ambiente pubblico in cui provarli, niente dataset, niente benchmark confrontabile. Il paper OpenMobile-2, pubblicato a fine ottobre, cambia proprio questo: apre gli ambienti di training, le ricette di addestramento e i benchmark, e lo fa con numeri che valgono la pena di controllare.

Cosa è OpenMobile-2 e cosa ha reso aperto

OpenMobile-2 è un agente per smartphone vicino al livello frontier, con la differenza che l'intero ecosistema attorno è pubblico. I numeri chiave dal paper OpenMobile-2 (2610.14157):

• MobileGym++, l'ambiente di training: 35 app in stile commerciale più 110+ app totali, con oltre 300 tool distribuiti su 50+ app. Non è un set di demo minimali: è un ecosistema di app simulato in cui l'agente impara a fare davvero.
• ~12.000 traiettorie SFT e 2.000+ task RL verificabili: i dataset di post-training sono aperti, e i task RL sono verificabili, cioè il task dice da solo se è riuscito.
• Benchmark: AndroidWorld 79.9, MobileWorld 50.4, SPA-Bench da 31.9 a 59.6 — quasi raddoppiato dopo il training. SPA-Bench era il punto debole (composizione di azioni lunghe) ed è esattamente quello che i task RL hanno risolto.

La parte che conta per chi costruisce: il codice e gli ambienti sono su github.com/OpenMobile2. Se vuoi un agente per il telefono, non devi più partire da zero: parti da una ricetta che ha già prodotto un agente quasi frontier.

Il modello: 9B che stanno in 4,5GB

L'agente si basa su OpenMobile-2-9B, un modello image-text-to-text da 9 miliardi di parametri, derivato da Qwen3.5-9B e fine-tunato sui dati OpenMobile-2: screenshot Android e tool nativi delle app. Esiste anche un fratello da 27B, e il checkpoint supporta vLLM e SGLang.

Facciamo i conti di memoria, perché è la domanda che decide tutto. A 4-bit ogni parametro pesa mezzo byte:

Modello	Parametri	Pesi a 4-bit	+ KV cache	VRAM/RAM totale
OpenMobile-2-9B	9B	~4,5GB	~1-2GB (contesto lungo)	~5,5-6,5GB
LFM3-1.7B	1,73B	~0,9GB	~0,3-0,5GB	~1,2-1,5GB

Requisito hardware	9B a 4-bit	1,7B a 4-bit
RAM/VRAM minima	8GB (stretto)	4GB
Telefono realistico	flagship da 12-16GB	telefoni di fascia media
PC o GPU	qualsiasi GPU da 8GB (3060 in su)	CPU recente, senza GPU

Il 9B non sta su un telefono di fascia media, ma sta su una GPU consumer da 8GB: è il modello da far girare sul PC che pilota l'agente, o sui flagship da 16GB. Il 1,7B è quello che sta davvero in tasca.

E qui entra in scena il secondo pezzo della giornata, LiquidAI LFM3-1.7B: un modello da 1,73B parametri con 256K di contesto, 16 lingue — incluso l'italiano — e post-training agentico esplicito. A 4-bit sta in ~1GB di RAM, su licenza LFM Open v1.0. Non è un generalista: è ottimizzato per il loop agente (pensa → chiama tool → osserva → riprova), ed è proprio il loop che serve su un telefono, dove ogni token costa batteria.

Cosa significa "on-device" in pratica

Tre architetture, con un requisito diverso. La scelta cambia tutto:

1. Tutto sul telefono (1-3B). LFM3-1.7B o modelli della stessa classe: l'agente gira in locale, legge gli screenshot, chiama gli accessibility service di Android. Latenza bassissima, zero cloud, ma capacità limitata: compiti a passo corto, una o due app alla volta.

2. Agente sul PC, telefono come periferica (9B+). OpenMobile-2-9B su una GPU da 8GB, che osserva lo schermo del telefono e pilota il touch. È la via più solida oggi: hardware abbondante, modello capace, e il telefono resta il dispositivo che l'utente tiene in mano.

3. Ibrido: piccoli passi in locale, reasoning nel cloud. Il modello piccolo gestisce i passi ripetitivi (classificare, compilare, navigare) e manda al modello grande solo i passi che contano. Gartner stima che 9 passi agentici su 10 siano routinari e i modelli open-weight li gestiscano al pari dei frontier — è l'architettura che conviene anche alle aziende (ne parliamo nelle notizie di oggi).

E i limiti?

Sia onesti su cosa non funziona:

• Il telefono non è un server. 1,7B a 4-bit sta in 1GB, ma la batteria ne costa un'altra: un loop agente che gira per minuti scalda e scarica. I numeri di consumo reali non esistono ancora in pubblico.
• Gli screenshot hanno un costo. Ogni screenshot è un'immagine da processare: su un telefono a 1,7B significa secondi per osservazione. Per questo i task lunghi restano territorio del 9B o di più.
• Verificabilità ≠ generalizzazione. I 2.000 task RL verificabili sono un'ottima base, ma coprono gli ambienti del paper. Le app che usi tu, con i popup e le versioni di oggi, restano un test che devi fare da solo.
• AndroidWorld 79.9 non è il tuo telefono. I benchmark misurano compiti scriptati in ambiente controllato. Il salto verso un uso reale (contatti, calendario, messaggistica con i tuoi dati) è ancora aperto — ed è proprio perché i dati restano sul dispositivo che ha senso farlo in locale.

Da dove partire

Se vuoi toccare con mano, la sequenza minima:

1. Gioca con MobileGym++ dal repo OpenMobile2-Code: è un ambiente, non serve un telefono. Vedi cosa sa fare l'agente e dove sbaglia.
2. Scarica LFM3-1.7B da Hugging Face e giralo in locale: il checkpoint a 4-bit sta in ~1GB, e con Ollama o llama.cpp lo servi su un PC con 4-8GB di RAM anche senza GPU. Se non va: controlla di aver scaricato il checkpoint quantizzato (il BF16 pesa ~3,5GB) e che i driver siano aggiornati.
3. Prova il loop agente. Chiedigli un compito a due passi — "apri la calcolatrice e calcola 12×8" — e leggi i log: devi vedere pensiero, tool call, osservazione. Se salta il tool call, allarga il contesto e verifica che il prompt di sistema descriva i tool disponibili.
4. Per il 9B serve una GPU da 8GB (RTX 3060 in su): servi il checkpoint con vLLM, poi punta l'ambiente di OpenMobile-2 contro la tua endpoint. Setup da una sera, non da una settimana.

In sintesi

Dopo OpenMobile-2, gli agenti per telefono non sono più un esperimento da laboratorio: ambienti, dataset e benchmark sono aperti, e un agente quasi frontier ha una ricetta pubblica che puoi riusare. La divisione pratica è semplice: 1,7B (~1GB di RAM, in tasca) per i passi corti in locale, 9B a 4-bit (~4,5GB di pesi) per i task lunghi, su una GPU consumer da 8GB. I limiti restano energia, costo degli screenshot e generalizzazione fuori dagli ambienti del paper — ma la direzione è chiara: il telefono sta diventando il dispositivo dove l'IA locale si fa notare per prima, e ora puoi misurare tu stesso quanto è vera.

Fonti: OpenMobile-2 paper · OpenMobile-2-9B · LFM3-1.7B · OpenMobile2-Code

Articolo generato con IA