Un modello che vede e gira sul telefono: 460 milioni di parametri, licenza Apache 2.0
7 min di lettura
Il 29 luglio 2026 Tether Data ha pubblicato in pesi aperti VisionPsy-Nano, famiglia di modelli vision-language da circa 460 milioni di parametri, licenza Apache 2.0, progettata per essere eseguita sul dispositivo. Il comunicato dell’azienda porta la data del 30 luglio, con dateline San Salvador. I pesi stanno su Hugging Face in due varianti — qvac/VisionPsy-Nano-460M e qvac/VisionPsy-Nano-460M-Flash — più le rispettive versioni GGUF quantizzate.
Per chi lavora in un’azienda o in un ente la notizia non è la classifica. È che un modello capace di leggere un’immagine e un documento possa stare dentro un telefono di servizio o un terminale di campo: se l’inferenza avviene lì, la fotografia del quadro elettrico, della bolla di consegna o del cartellino di collaudo non attraversa nessuna rete. È il caso d’uso che in manifattura chiedono più spesso, e finora richiedeva o una connessione o un armadio. Prima di metterlo in un capitolato conviene però leggere che cosa il produttore dichiara, e con quali riserve — che sono scritte nella scheda del modello, non nel comunicato.
Che cosa è stato pubblicato
- Architettura dichiarata: codificatore visivo SigLIP2 base, patch16, a 512×512; modello linguistico SmolLM2-360M; connettore pixel-shuffle. Il punto di partenza è nominato nella scheda:
lusxvr/nanoVLM-460M-8k. Finestra di contesto 8.192 token. - Licenza: Apache 2.0. Testo della scheda: il modello «is licensed by Tether Data, S.A. de C.V. under the Apache 2.0 license». Nessuna soglia di fatturato, nessun accordo separato.
- Due varianti, non una: la completa impiega 1.088 token visivi per immagine, la Flash 64. Sul punteggio complessivo normalizzato dichiarato il divario è 62,3 contro 61,4.
- Esecuzione:
transformerscontrust_remote_code, vLLM, SGLang, Docker Model Runner, più le build GGUF per l’esecuzione locale.
Il numero del titolo, e i tre che stanno sotto
Il dato che circola è «primo token in 0,3 secondi su iPhone 15». È esatto, e va letto con tre precisazioni che stanno nel post del produttore ma non nel titolo.
La prima: quel tempo riguarda la variante Flash, non la completa. La seconda: è il migliore di quattro misure. Nella stessa tabella il tempo al primo token è 0,3 s su iPhone 15, 2,6 s su Galaxy S25 Ultra, 5,9 s su Galaxy S23 e 6,1 s su Pixel 9 — venti volte di scarto fra il primo e l’ultimo. La terza: le condizioni sono dichiarate e sono strette, «measured on real phones with quantized GGUF builds at 512×512». Se il vostro parco terminali non è fatto di iPhone recenti, il numero utile alla vostra decisione è l’ultimo della riga, non il primo.
Stesso lavoro sul primato «su 16 benchmark su 17». Il confronto è con i modelli della stessa taglia — LFM2.5-VL-450M, SmolVLM2-500M e nanoVLM-460M-8k — ed è il produttore stesso a dichiarare che il terzo è il checkpoint da cui VisionPsy-Nano parte. Un modello messo a punto che supera il proprio punto di partenza è il risultato atteso, non una sorpresa. Il diciassettesimo test, quello perso, non viene nominato. Le valutazioni le ha eseguite il produttore: il post afferma che tutti i modelli sono stati misurati con un solo strumento, VLMEvalKit, con configurazioni e giudice pubblicati, «so the benchmark numbers are reproducible». Vero — e va distinto da «già riprodotti da altri»: al 29 luglio il supporto ai due modelli dentro VLMEvalKit era una pull request aperta sul repository pubblico, la #1613, non codice integrato.
Vale come regola generale, oltre questo caso. Di un numero dichiarato servono quattro informazioni prima di poterlo usare: chi ha eseguito la misura, contro quali concorrenti, in quali condizioni, e quale è il caso peggiore fra quelli misurati. Se ne manca una, quel numero non è una misura ma un argomento di vendita — lo stesso criterio con cui abbiamo scritto come si verifica che un sistema abbia funzionato davvero.
Le righe che pesano più dei punteggi
La sezione dei limiti della scheda è breve e va letta per intero, perché decide più dei benchmark.
«Primarily English; other languages are not officially supported yet.» Per chi deve leggere DDT, verbali, referti o schede di manutenzione in italiano, questa riga viene prima di ogni punteggio: la prova sui vostri documenti reali è l’unico test che conta.
«Single-image by design»: una immagine per richiesta, i prompt multi-immagine sono fuori dall’uso previsto. Poi l’ammissione sul comportamento: il modello «may occasionally hallucinate or miscount and is best suited to focused tasks rather than very dense documents or long multi-step math». E infine la riga che va copiata nel fascicolo: «Not intended for safety-critical or high-stakes automated decisions».
Quest’ultima non è una formula di stile. Se il vostro caso d’uso ricade fra i sistemi ad alto rischio, avete un documento del fornitore che dichiara che il modello non è destinato a quell’impiego: o l’uso cambia, o la dichiarazione va spiegata e compensata con controlli umani documentati. Su che cosa pretendere dalla documentazione di un modello prima di installarlo abbiamo scritto una nota dedicata.
Apache 2.0 sui pesi non copre tutto quello che c’è dietro
La scheda elenca i corredi usati per la messa a punto con la rispettiva licenza: FineVision (CC BY 4.0), NVIDIA Nemotron-Image-Training-v3 (CC BY 4.0), mPLUG TinyChartData (Apache 2.0), TabMWP (CC BY-NC-SA 4.0), PopVQA (MIT), InfoSeek (Apache 2.0), MMKU-Bench (Apache 2.0), VisionFoundry-10K (Apache 2.0), PKU-SafeRLHF-V (CC BY-NC 4.0).
Due portano la clausola NC, non commerciale. Se e in che misura una licenza sui dati di addestramento si estenda ai pesi che ne derivano è una questione aperta, e non risulta una pronuncia che la chiuda: i pesi restano pubblicati come Apache 2.0. Il punto operativo non è avere la risposta: è che la domanda esiste, sta scritta nella scheda del fornitore, e chi non se ne accorge oggi se la sente porre in una due diligence. Come si legge una licenza di pesi aperti l’abbiamo già spiegato: qui si aggiunge un passo, cioè leggere anche l’elenco dei dati dichiarati. E archiviare la scheda del giorno in cui scaricate, con la revisione esatta e l’impronta dei file: la scheda si può riscrivere, la vostra copia no.
Cosa fare adesso
- Provate il modello sui vostri documenti in italiano prima di qualunque altra valutazione: la scheda dichiara supporto primario all’inglese, e questo da solo può chiudere il caso d’uso.
- Non portate nel business case il numero del produttore: rimisurate il tempo al primo token sul terminale che userete davvero, con la stessa quantizzazione e la stessa risoluzione.
- Scrivete nel documento quale variante state adottando. Completa e Flash non hanno gli stessi tempi né gli stessi punteggi, e nei repository si somigliano.
- Fate valutare le due licenze non commerciali prima della produzione, non dopo. La risposta può essere «rischio accettabile»: deve essere una decisione scritta, non una dimenticanza.
- Trattate la riga sulle decisioni ad alto impatto come un requisito di progetto: stabilite dove il modello non decide, chi decide al suo posto e dove resta traccia.
Un modello da 460 milioni di parametri che gira su un telefono non è un sistema: è il pezzo che vede. Attorno serve il resto — indicizzazione dei documenti, regole di dominio, verifica umana, conservazione delle prove, aggiornamento controllato dei pesi — e quel resto gira dove decidete voi: on-premise nell’ambiente che già amministrate, oppure su cloud dedicato, ambiente riservato al singolo cliente, accesso via VPN dedicata, data center residente in Italia, locali presidiati direttamente da noi. Sono le due modalità in cui consegniamo, e la scelta resta vostra anche dopo la firma. Il ragionamento esteso su dove gira il calcolo, di chi sono i pesi e che cosa esce dal perimetro sta nella pagina su hardware e modelli a pesi aperti.
Valutate un modello sul dispositivo per un’ispezione in campo o per la lettura di documenti riservati? Parliamone in una sessione di trenta minuti: mettiamo alla prova i numeri dichiarati sui vostri documenti, prima che lo facciate in produzione.