Venticinque foto di pasti, un dataset pubblico e una domanda pratica: quale LLM multimodale riesce a stimare le calorie restando entro il 20% di errore? Il micro-benchmark pubblicato su Reddit da mr_tolkien non ha l'ambizione di un paper, ma è il tipo di esperimento che dice molto su come scegliamo i modelli quando l'obiettivo è un compito concreto, non un punteggio astratto.

L'autore ha usato le immagini di Nutrition5k e uno strumento con accesso ai dati calorici di USDA FoodData Central e MEXT. Ha valutato i modelli in base alla percentuale di pasti in cui la stima è rimasta sotto il 20% di errore, su 25 pasti identici scelti casualmente. I modelli troppo grandi per la sua macchina sono passati da OpenCode Go/OpenRouter. Il resto ha girato in locale.

I risultati rovesciano l'idea che più parametri equivalgano automaticamente a maggiore affidabilità. Muse Spark 1.3, modello che dovrebbe essere rilasciato con pesi aperti, centra l'obiettivo nel 48% dei casi, con un errore mediano di 45 kcal e una leggera sottostima media (-24 kcal). All'estremo opposto, Qwen 3.8 27b si ferma al 16%, con un bias medio di +64 kcal e un errore mediano di 148 kcal. In mezzo, modelli come GLM 5.3 Flash e DeepSeek v4 Flash Vision mostrano prestazioni intermedie ma non monotone rispetto alla taglia.

Modello % entro 20% Bias medio Errore mediano
Qwen 3.8 27b 16% +64 kcal 148 kcal
GLM 5.3 Flash 28% +18 kcal 65 kcal
Qwen 3.8 Max 32% -11 kcal 48 kcal
Muse Glimmer 30b 32% +25 kcal 92 kcal
Qwen 3.8 Flash 36% +2 kcal 91 kcal
DeepSeek v4 Flash Vision 40% +52 kcal 65 kcal
Muse Spark 1.3 48% -24 kcal 45 kcal

Il dato più interessante non è il vincitore assoluto, ma l'inversione tra Muse Glimmer 30b e Qwen 3.8 27b: il primo supera nettamente il secondo nonostante una differenza di parametri modesta. Per chi ragiona su hardware consumer con circa 32GB di VRAM, questo ha un peso specifico: un modello da 1,3 miliardi di parametri può girare in locale con margini di VRAM, mentre un 27B richiede quantization aggressiva o il ricorso a un'API cloud. Se il task è la stima calorica da foto, il modello più piccolo può essere non solo sufficiente, ma migliore.

Il setup dell'autore è ibrido per necessità: alcuni modelli girano in locale, altri su OpenRouter. È la fotografia di molti progetti self-hosted, dove la soglia di VRAM determina cosa può restare on-premise e cosa finisce in cloud. Il fatto che un modello aperto da 1,3B raggiunga il miglior risultato sposta l'ago della bilancia verso un'infrastruttura più contenuta, riducendo la dipendenza da API esterne e i costi operativi.

Il benchmark non è scientifico: 25 pasti sono pochi, non ci sono intervalli di confidenza, e la scelta dei prompt o della temperatura può spostare i risultati. Ma è utile come segnale qualitativo, soprattutto perché replica il modo in cui un singolo sviluppatore sceglie un modello: prova, confronta, poi decide in base al proprio hardware e al proprio caso d'uso.

Per chi deve decidere tra esecuzione locale e cloud, esistono trade-off da mappare: la latenza, la privacy delle immagini, i costi di inference e la manutenzione dell'hardware. AI-RADAR offre framework analitici su /llm-onpremise per confrontare questi scenari senza scorciatoie. Se un modello da 1,3B può battere un 27B su un task visivo così specifico, quante altre nicchie applicative stanno pagando la taglia senza riceverne il valore?