LFM3: un modello da 1 GB non è ancora un agente affidabile

C’è una cifra che nel mondo dell’intelligenza artificiale sta diventando più interessante di molti benchmark: circa 1 GB. Non è la dimensione di un database, né quella di una presentazione commerciale piena di promesse. È la memoria indicativa dichiarata per i pesi quantizzati a 4 bit di LFM3-1.7B, il modello testuale della nuova famiglia presentata da Liquid AI il 27 ottobre 2026. E, naturalmente, è già abbastanza per far partire la solita gara a chi annuncia di poter mettere un agente ovunque.

La domanda, però, non è se un modello entra in un telefono o in un piccolo server. La domanda è quale parte del lavoro possiamo davvero affidargli, quanto costa mantenerla affidabile e cosa succede quando il modello sbaglia. Perché la RAM si misura facilmente; la qualità di una decisione sbagliata che finisce in un gestionale, decisamente meno.

Che cosa ha pubblicato Liquid AI, senza confondere i modelli

Nel rilascio tecnico su Hugging Face, Liquid AI presenta sei modelli post-addestrati derivati dal backbone LFM3-1.7B-Base: uno per il testo, uno per immagini e video, uno per audio, un modello omni che combina più modalità e due modelli orientati a risposte decisionali strutturate. Non è un unico modello che fa tutto con la stessa efficienza: è una famiglia con componenti e capacità differenti.

Il backbone testuale ha circa 1,73 miliardi di parametri e 24 layer, distribuiti tra 13 convoluzioni gated, 5 layer di sliding-window attention e 6 di global attention. Liquid chiama questa combinazione tri-hybrid. La scelta architetturale è interessante perché cerca di contenere i costi di inferenza senza rinunciare completamente alla capacità di collegare informazioni lontane nel contesto. È un compromesso progettuale, non una scorciatoia che elimina memoria, calcolo o errori.

La model card ufficiale indica una finestra di contesto fino a 256K token e un ingombro di circa 1 GB per i pesi del modello testuale a 4 bit. Quel gigabyte non è il consumo totale di un’applicazione: restano runtime, cache di attenzione, buffer, input, output, eventuali encoder multimodali e servizi di contorno. E una finestra da 256K token non garantisce che il modello ricordi, recuperi e ragioni correttamente su ogni informazione contenuta in quella finestra.

La differenza tra un modello locale e un sistema locale

Immaginiamo un’applicazione aziendale che riceva un documento, ne estragga numero, data e importo, li confronti con un ordine e proponga un’azione. Il modello può essere eccellente nel riconoscere campi, ma non dovrebbe essere l’unico componente a decidere se registrare un movimento contabile. Serve una pipeline che sappia distinguere un dato estratto da un dato verificato.

La parte intelligente non coincide necessariamente con quella autorizzata a scrivere. Un modello può proporre un JSON; uno schema lo valida; un controllo applicativo verifica coerenza e permessi; il sistema decide se procedere, chiedere revisione o interrompere. È la stessa differenza che passa tra generare una risposta e completare un workflow. Ne avevo affrontato un altro aspetto parlando di decisioni e processi che non si esauriscono in una risposta API.

Spostare un modello dal cloud al proprio server cambia il luogo in cui gira il codice. Non cambia, da solo, chi risponde degli errori.

I sei modelli servono a separare i compiti, non a moltiplicare le etichette

La famiglia LFM3 permette di progettare percorsi diversi: il modello testuale per estrazione e tool calling, quello vision per schermate e documenti visuali, audio per parlato, omni quando i segnali devono essere interpretati insieme. I modelli decisionali d1 sono pensati per produrre risposte calibrate e strutturate. Questa separazione può ridurre sprechi, ma introduce anche una responsabilità: decidere quando attivare ciascun componente e quando non fidarsi del suo risultato.

Una pipeline multimodale mal progettata può spendere più tempo in conversioni, trasferimenti e retry di quanto ne risparmi usando modelli piccoli. E un punteggio di confidenza non diventa automaticamente una probabilità affidabile nel nostro dominio: va calibrato su dati rappresentativi, soprattutto se il risultato attiva operazioni reali.

Cinque misure che contano più della classifica

Prima di scegliere un modello locale per un progetto concreto, costruirei un test sul lavoro che deve fare. Non un prompt dimostrativo preparato per fare bella figura, ma casi reali, input sporchi, documenti incompleti e richieste ambigue. Le misure utili sono poche, purché siano oneste.

• Accuratezza sul compito: quanti campi o decisioni sono corretti, con un dataset di verifica separato dal fine-tuning.
• Errori pericolosi: quante risposte formalmente valide producono comunque un’azione sbagliata, e quanto costa intercettarle.
• Latenza end-to-end: dal documento ricevuto all’esito verificato, includendo parsing, retrieval, chiamate agli strumenti e retry.
• Memoria e saturazione: picco RAM/VRAM con il contesto e la concorrenza realmente previsti, non solo dimensione del file quantizzato.
• Costo operativo: hardware, energia, manutenzione, monitoraggio, aggiornamenti e fallback rispetto all’alternativa via API.

Liquid AI pubblica benchmark favorevoli e dati prestazionali dettagliati. Sono informazioni utili per scegliere cosa provare, ma restano misure dichiarate dal produttore e non un test riprodotto sulla nostra applicazione. Anche la model card pone un limite esplicito: LFM3-1.7B non è raccomandato per agentic coding o ragionamenti complessi in più passaggi. Ignorare questa avvertenza per costruire un agente che modifica autonomamente codice e database non sarebbe audacia tecnica: sarebbe leggere soltanto le righe del benchmark che ci piacciono.

Fine-tuning: meno parametri, non meno manutenzione

Il rilascio comprende notebook ed esempi per adattare i modelli con una singola GPU. È un vantaggio concreto per chi ha un dominio ben delimitato: un catalogo prodotti, una tassonomia documentale, una classificazione ripetitiva, una terminologia settoriale. Ma il fine-tuning non sostituisce la definizione dei requisiti e non elimina la necessità di valutazioni successive.

Ogni nuova versione dei dati, ogni cambio di formato, ogni nuova procedura introduce un potenziale scostamento. Il lavoro non finisce quando il modello restituisce la prima risposta corretta: servono versionamento di dataset e prompt, regressioni, soglie di escalation e un modo per tornare al comportamento precedente. In altre parole, serve sviluppo software. La parte che qualcuno continua a considerare un fastidioso dettaglio tra un annuncio e il successivo.

Open-weight non vuol dire senza condizioni

Un altro dettaglio che non andrebbe relegato in fondo alla pagina è la licenza. LFM3 usa la LFM Open License v1.0, basata su Apache 2.0 ma con una condizione sostanziale: la concessione gratuita per uso commerciale non copre le entità con fatturato annuo pari o superiore a 10 milioni di dollari. Per queste serve un accordo commerciale distinto. La licenza definisce anche il perimetro della legal entity, quindi la valutazione non può fermarsi al nome della singola applicazione o della piccola società che la distribuisce.

I pesi sono disponibili e si possono adattare, ma non è corretto presentare questa licenza come Apache 2.0 pura. Prima di incorporare un modello in un prodotto destinato a clienti, bisogna verificare i termini applicabili al proprio caso e a quello dei destinatari. Il controllo legale non si risolve con un flag in un file di configurazione.

Quando ha senso davvero portare l’AI vicino ai dati

L’AI locale diventa interessante quando esiste un motivo operativo verificabile: vincoli di connettività, latenza stabile, dati che non devono uscire da un perimetro controllato, costi di inferenza prevedibili a un certo volume, o un compito specialistico per il quale un modello piccolo offre qualità sufficiente. Non quando si vuole soltanto poter dire che il cloud non serve più.

Anche la località è una proprietà da verificare: telemetria, aggiornamenti, servizi di retrieval, storage dei log e chiamate di fallback possono ancora uscire dalla macchina. Un’architettura realmente controllata deve mappare questi flussi. Allo stesso modo, se si usano più modelli o provider, occorre sapere quale ha risposto e con quale versione. È un tema vicino a quello discusso nell’articolo sui benchmark che perdono significato quando il routing cambia senza essere dichiarato.

Il test che farei prima di una scelta di produzione

Prenderei cinquanta o cento casi rappresentativi del processo, includendo gli errori che oggi richiedono una correzione umana. Eseguirei lo stesso protocollo su LFM3 locale e su una soluzione alternativa, con criteri di successo fissati prima del confronto. Misurerei la qualità della risposta, ma soprattutto la percentuale di esiti che attraversano correttamente validazioni, permessi e fallback. Infine calcolerei il costo per operazione corretta, non per milione di token teorici.

Se il modello locale supera la soglia di qualità con costi e vincoli migliori, ha senso adottarlo. Se fallisce su una classe critica di casi, lo si limita a un ruolo più stretto o si usa un fallback. Non è una sconfitta: è architettura. E forse questa è la notizia più interessante dietro LFM3: i modelli abbastanza piccoli da stare vicino ai dati ci costringono finalmente a discutere di sistemi, responsabilità e misure, invece di limitarci a contare parametri.