Un test su hardware locale ha rimesso in discussione l'entusiasmo attorno a LFM2.5-24-A2B. Il redditor tracagnotto, dopo le critiche ricevute per un primo post giudicato troppo superficiale, ha pubblicato una verifica con configurazione esplicita: scheda RTX A4500, passaggio da llamaampere a LM Studio e un task agentico su Hermes. Il verdetto è duro: il modello non sarebbe affidabile nemmeno per "sbucciare una nocciolina".

La prima esecuzione con llamaampere, una build di llama.cpp ottimizzata, ha mostrato un contrasto netto. Da un lato 130 token/s su scheda professionale; dall'altro loop ripetuti ed errori su richieste semplici. È il classico caso di throughput elevato che non dice nulla sulla qualità dell'inference quando il modello perde coerenza. Per chi valuta deployment on-premise, separare la velocità di generazione dalla capacità di completare un compito è il primo passo per evitare sorprese.

Il problema non è il template

Passando a LM Studio, con engine e framework aggiornati, il comportamento erratico si è ridotto: in chat le risposte sono risultate "correttine". Ma la prova vera arriva quando l'utente collega il modello a Hermes Desktop e gli chiede di sviluppare un plugin per Garnet, il clone Redis di Microsoft. Il risultato, analizzato da ChatGPT durante il prompt engineering e verificato con GPT Sol, è stato netto: codice rotto, funzionalità richieste omesse e una verifica dichiarata senza test end-to-end. L'applicazione del template fix Sharp non ha cambiato la sostanza.

Il caso è interessante non per il singolo giudizio, ma per ciò che rivela sulle metriche con cui si sceglie un LLM per carichi locali. LFM2.5-24-A2B viene presentato come addestrato su harness agentici come openclaw e Hermes, eppure fallisce proprio nel compito che dovrebbe rappresentare il suo punto di forza. Questo segnale suggerisce che i benchmark sintetici o le demo di chat non bastano quando il modello deve interagire con un runtime esterno, produrre codice funzionante e non allucinare verifiche. Chi guadagna da questo equivoco? I vendor che spingono numeri di velocità e fine-tuning su dataset agentici, perché catturano l'attenzione iniziale. Chi perde? I team che integrano questi modelli in pipeline self-hosted senza test realistici e poi devono bonificare errori in produzione.

C'è un secondo ordine di implicazioni. La community locale aveva reagito con scetticismo al primo post chiedendo configurazioni. Il secondo test, più documentato, mostra che il problema non era un template sbagliato ma un limite strutturale del modello. Per chi gestisce infrastrutture on-premise, il collo di bottiglia non è sempre la VRAM o i token/s, ma la capacità di eseguire un task completo senza intervento umano. Una RTX A4500 può generare molto in fretta, ma se il codice prodotto è rotto, il TCO cresce per le ore di debugging. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per confrontare questi trade-off; qui la lezione è ancora più diretta: i test sintetici non sostituiscono un task agentico end-to-end.