Il confine tra un LLM che gira con dignità su un Raspberry Pi e uno che invece crolla su sé stesso non è quasi mai una linea retta. È una scogliera, e i grafici che circolano di solito la nascondono. A rendere tutto più concreto è un’analisi indipendente pubblicata su Reddit dall’utente crusaderky, che ha messo sotto torchio il modello LFM2.5-2.6B di LiquidAI — un gioiellino da soli 2,6 miliardi di parametri che, stando ai benchmark ufficiali, tiene testa ad architetture ben più pesanti.

L’esperimento è chirurgico: per ogni combinazione possibile tra quantization GGUF del modello e quantization della cache KV, è stata calcolata la perplexity su set di test, cercando il miglior compromesso qualità-memoria per Raspberry Pi con 8 e 4 GB di RAM. I risultati aprono più di uno squarcio su quanto sia facile farsi ingannare dalle metriche di quantization quando si fa inference on-device.

Partiamo dai fatti. Su un Raspberry Pi da 8 GB, LFM2.5-2.6B gira senza alcun degrado materiale (il termine usato è «no material degradation»): un dato che da solo riscrive le aspettative per il deployment locale di modelli linguistici. Sulla variante da 4 GB il degrado c’è, ma è «contenuto». La vera sorpresa arriva però scavando nei dettagli della quantization: il formato Q4_K_M, spesso usato come scelta sicura per risparmiare VRAM, è da evitare categoricamente con questo modello. La sua curva di qualità non scende dolcemente: a un certo punto precipita, e lo fa senza che le metriche tradizionali — come la KLD logaritmica o il Top-1% dei token — lancino alcun allarme. Anzi, quei numeri raccontano una storia di degrado lineare e prevedibile, laddove la realtà è un salto improvviso che può silenziosamente invalidare le risposte del modello.

C’è un’altra lezione, delicata per chiunque lavori sull’allineamento dei modelli: l’abliterazione, la tecnica per rimuovere comportamenti indesiderati, ha un costo piatto di circa 0.075 KLD, un prezzo fisso che non dipende dalla configurazione scelta. Significa che ogni intervento di safety sull’LLM si porta via un pezzetto di capacità predittiva, e questo pedaggio va messo in conto quando si decide se e come distribuire il modello in produzione.

Illusione di linearità
Il vero colpo di scena del report è proprio il comportamento a scogliera della qualità. In molti grafici, la degradazione sembra graduale solo perché le metriche abituali operano in uno spazio compresso (logaritmico) o si concentrano sulle code della distribuzione. Ma quando si guarda la perplexity reale, il crollo è netto. È un bug-report concettuale: chi sta valutando se un modello quantizzato può funzionare per un task specifico — assistenza clienti on-prem, riassunto di documenti in ambienti air-gapped, chatbot per la PA — rischia di prendere una cantonata se si affida ciecamente alle misure aggregate senza testare il comportamento effettivo sull’hardware target.

Cosa significa tutto questo per il panorama dell’AI on-premise? Innanzitutto che la strada dei modelli piccoli e “tascabili” è più matura di quanto si pensi. LFM2.5-2.6B dimostra che non servono GPU da data center per avere un LLM utile: bastano dispositivi che costano meno di cento euro. Il punto non è più se sia possibile, ma con quali accortezze. Per chi valuta deployment in sede per questioni di sovranità dei dati o per contenere il TCO, l’analisi di crusaderky offre una bussola: testare sempre la qualità reale sulla propria macchina, non fidarsi delle metriche standard, e diffidare dei quant che promettono troppo risparmio di memoria senza mostrare il conto.

Non è un dettaglio tecnico per pochi. È il tipo di informazione che sposta la frontiera tra ciò che si può mettere in produzione locale e ciò che invece resta confinato al cloud. E che ricorda a tutti una verità scomoda: nel mondo della quantization, la linea retta è quasi sempre un’illusione ottica.