Un modello da 2,6 miliardi di parametri che gira in meno di 2,5 GB di memoria, su una CPU, e che su alcuni benchmark di uso dei tool batte un modello oltre tre volte più grande. È l’annuncio con cui Liquid AI ha presentato LFM2.5-2.6B, e non è l’ennesimo record di classifica: è un segnale su dove sta andando l’automazione aziendale. Per chi valuta agenti AI locali on premise, banche, sanità, PA, manifattura con dati sensibili, la domanda non è più “si può fare?”, ma “cosa serve perché funzioni davvero in produzione?”. Le due risposte sono molto diverse.
In questo articolo scoprirai:
- LFM2.5-2.6B: cosa ha annunciato Liquid AI e perché conta
- Agentic RL e Harness Proxy: come è stato addestrato
- Cosa dicono davvero i benchmark: dove vince e dove perde
- Agenti AI locali on premise: cosa cambia davvero per l’azienda
- Perché gli agenti AI on premise non sono plug-and-play
LFM2.5-2.6B: cosa ha annunciato Liquid AI e perché conta
LFM2.5-2.6B è un modello agentico progettato per girare interamente sul dispositivo: pianifica, chiama tool, esegue task multi-step senza mai uscire dal perimetro. I numeri dichiarati nell’annuncio ufficiale su Hugging Face sono 220 token/secondo su Apple M5 Max e 113 token/secondo su AMD Ryzen AI Max+ 395, entrambi in CPU inference, con un ingombro sotto i 2,5 GB. Su smartphone si scende a circa 30 token/secondo: lento per una chat, più che sufficiente per un agente che lavora in background.
Specifiche tecniche e licenza del modello LFM2.5-2.6B
Il modello conta 2,69 miliardi di parametri, una finestra di contesto da 131.072 token e un pre-training su circa 34 trilioni di token. Supporta 16 lingue, italiano incluso. Il supporto ai runtime è disponibile dal primo giorno: llama.cpp con checkpoint GGUF, MLX per Apple Silicon, vLLM e SGLang su GPU, ONNX per il deployment cross-platform.
Un punto che merita precisione: la model card dichiara la licenza lfm1.0, una licenza proprietaria dell’azienda. Liquid AI parla di modello “open-weight” e di download e fine-tuning senza restrizioni, ma open-weight non è sinonimo di open source: prima di costruirci sopra un servizio commerciale, i termini vanno letti dal vostro ufficio legale, non dedotti dai comunicati stampa.
Fino a un Raspberry Pi: qual è l’hardware minimo reale
L’ingombro sotto i 2,5 GB allarga l’insieme dei dispositivi compatibili molto oltre il laptop aziendale. Come sintetizza VentureBeat, il messaggio è “niente cloud, niente GPU”: agenti eseguibili su hardware piccolo come un Raspberry Pi. Il blog ufficiale di Liquid AI insiste sullo stesso posizionamento, l’edge come destinazione primaria, non come ripiego, e la scheda tecnica di MarkTechPost ricostruisce la pipeline che ci arriva.
Vale però distinguere due scenari. Un agente che gira su un M5 Max a 220 token/secondo è interattivo; lo stesso agente su una single-board resta utile per task asincroni, classificare documenti in arrivo, arricchire record, preparare bozze, dove nessuno aspetta davanti allo schermo. È una distinzione che va fatta in fase di design, perché determina quali processi si possono spostare in locale e quali no. Quando i task diventano molti e concorrenti, il collo di bottiglia si sposta dall’inferenza al coordinamento, ed è il territorio della multi-agent orchestration.
Agentic RL e Harness Proxy: come è stato addestrato
La parte tecnicamente interessante non è la dimensione, è il metodo. Il post-training si articola in quattro fasi: due round di supervised fine-tuning su tool use e traiettorie di harness, la specializzazione di teacher per dominio (matematica, codice, uso dei tool), una distillazione multi-dominio on-policy che comprime quei teacher in un unico modello studente, e infine il reinforcement learning agentico multi-turn.
Perché addestrare dentro harness reali cambia gli agenti AI
Quasi tutti i modelli imparano a chiamare tool in ambienti simulati. Liquid AI ha fatto l’RL dentro harness agentici reali, OpenClaw, Hermes Agent, trattandoli come scatole nere. Il pezzo che lo rende possibile si chiama Harness Proxy: intercetta in modo trasparente le traiettorie a livello di token, le ricostruisce e le valida come campioni di training, senza modificare di una riga il framework originale.
La conseguenza pratica è la compatibilità. Un modello che ha visto durante l’addestramento gli stessi formati di system prompt, le stesse schema di tool e gli stessi pattern di errore che incontrerà in produzione sbaglia meno nel momento in cui lo si collega a un vero stack. È lo stesso principio per cui un neoassunto formato sui processi reali dell’azienda è operativo prima di uno formato su casi di scuola. Ed è anche il motivo per cui l’architettura di integrazione, quali tool, esposti come, con quale contratto, smette di essere un dettaglio implementativo.
Cosa dicono davvero i benchmark: dove vince e dove perde
La claim “compete con modelli molto più grandi” è del vendor e va qualificata, perché è vera solo su alcune dimensioni. Su ToolSandbox, un benchmark che valuta l’uso dei tool in scenari stateful e conversazionali, LFM2.5-2.6B segna 77,83 contro il 76,44 di Qwen3.5-9B, un modello con oltre tre volte i parametri (2,69B contro 9B). Su IFBench (aderenza a istruzioni complesse) fa 59,17 contro 56,47, su IFStruct 85,49 contro 78,50, su Multi-IF 80,07 contro 62,55.
I limiti dichiarati: coding, BFCLv4 e tool malformati
Dove perde, perde chiaramente. Su BFCLv4, il Berkeley Function Calling Leaderboard, che nella versione 4 introduce una valutazione agentica olistica, si ferma a 56,88 contro 60,13. Su LiveCodeBench v6 il divario è netto: 59,41 contro 69,86. Su AIME25, ragionamento matematico, 51,87 contro 56,07. La lettura onesta è che si tratta di uno specialista di tool use e instruction following, non di un modello general-purpose, come nota anche l’analisi di ExplainX.
C’è poi un limite che Liquid AI dichiara esplicitamente e che chiunque progetti agenti deve mettere a verbale: se un tool restituisce dati malformati, il modello può presentarli come corretti senza segnalare l’anomalia. In un flusso agentico l’output sbagliato alimenta il passo successivo. La mitigazione suggerita, vincoli espliciti sul formato atteso nel prompt, funziona solo se qualcuno l’ha progettata, e va accompagnata da un’ottimizzazione consapevole dello stack di inferenza, un tema che abbiamo trattato in AI inference engineering.
Agenti AI locali on premise: cosa cambia davvero per l’azienda
Un agente AI locale è un sistema che ragiona, decide e agisce chiamando strumenti, database, API interne, file system, con il modello che gira su hardware controllato dall’azienda. La differenza con un agente AI in cloud non è la capacità: è dove passano i dati, chi ne risponde e quanto costa ogni chiamata. Con l’inferenza locale il costo marginale per token tende a zero e la latenza non dipende dalla rete.
Privacy, AI Act e settori regolati: il vero driver dell’on premise
Il driver dominante non è la performance, è la conformità. Il GDPR è pienamente operativo e la maggior parte degli obblighi dell’AI Act europeo diventa applicabile dal 2 agosto 2026, comprese le regole su sistemi ad alto rischio, documentazione e monitoraggio post-mercato. Per una cartella clinica, una pratica di credito o un fascicolo legale, “il dato non lascia il perimetro” è un requisito, non una preferenza.
Sul piano hardware il quadro cambia radicalmente. Le guide enterprise sull’on-premise, come quella di Intuz, raccomandano tipicamente almeno una GPU di fascia datacenter e 64 GB di RAM. Un modello che gira in 2,5 GB su una CPU esistente abbassa la barriera d’ingresso di un ordine di grandezza: sposta il problema dal budget hardware alla progettazione del sistema.
Il contesto italiano: sovranità del dato e LLM privati
In Italia il tema arriva sotto l’etichetta della sovranità del dato: l’analisi di AI4Business sul deployment on-premise lega la scelta dell’hardware locale al controllo giuridico dell’informazione, non al risparmio. Sul fronte normativo, Agenda Digitale elenca i requisiti che un agente a contatto con i clienti deve soddisfare, informativa, base giuridica, tracciabilità delle decisioni, obblighi che restano identici anche quando il modello gira nel vostro rack.
Per le imprese italiane, come mostra una rassegna sui private LLM in Italia, il vincolo prevalente che porta al modello privato è la riservatezza dei dati, non la performance né il costo. Il bivio, a quel punto, è organizzativo più che tecnico, ed è quello tra agente chiavi in mano e self-service: chi ha un team interno che presidia il ciclo di vita può gestirlo da sé, chi non l’ha finisce per scoprire i costi nascosti dopo il go-live.
Perché gli agenti AI on premise non sono plug-and-play
Qui va detta la cosa scomoda. LFM2.5-2.6B risolve il problema della fattibilità, non quello dell’integrazione. Scaricare un GGUF e farlo girare in locale è il lavoro di un pomeriggio. Portare quell’agente in produzione significa progettare cinque strati: le fonti dati interne, il retrieval con RAG su documenti reali, l’esposizione dei tool aziendali, oggi spesso via Model Context Protocol, i guardrail sugli output e l’osservabilità delle traiettorie.
Osservabilità e manutenzione: dove il risparmio sul cloud si brucia
Senza tracciamento delle traiettorie non sapete perché un agente ha sbagliato, e con il limite sui tool malformati dichiarato dal vendor questo smette di essere un lusso. Poi c’è il ciclo di vita: i modelli si aggiornano, i tool cambiano contratto, i prompt regrediscono. È il tema della manutenzione post-deployment e del passaggio da pilot a produzione, dove la maggior parte dei progetti si ferma. Anche l’ottimizzazione dell’inferenza, quantizzazione, batching, dimensionamento, resta una disciplina a sé.
È la ragione per cui, in MIMIR, il modello è la parte facile: quello che consegniamo è un servizio, non solo un prodotto. Nel caso on-premise questo cambia in concreto l’onboarding: si parte dal dimensionamento dell’hardware già presente in azienda, si integrano i tool interni che non escono dal perimetro e si predispone il tracciamento delle traiettorie sul vostro storage, non sul nostro. Se state valutando agenti AI locali on premise per dati sensibili o vincoli normativi, potete parlarne con noi e capire insieme cosa ha senso costruire nel vostro contesto.
Fonti:
- Liquid AI — annuncio ufficiale LFM2.5-2.6B su Hugging Face
- Model card LFM2.5-2.6B (specifiche e licenza lfm1.0)
- Liquid AI — blog ufficiale sul modello
- VentureBeat — agenti AI su device piccoli come un Raspberry Pi
- MarkTechPost — scheda tecnica del modello agentico on-device
- Berkeley Function Calling Leaderboard (BFCL)
- ExplainX — analisi su LFM2.5-2.6B e gli agenti on-device
- AI Act — timeline di implementazione
- Intuz — costruire un agente AI on-premise con RAG e LLM
- Agenda Digitale — agenti AI nell’assistenza clienti: requisiti normativi
