LFM3-1.7B-Base vs LFM2.5-2.6B-Base: Meno parametri, meno token, più contesto

L'aritmetica va nella direzione sbagliata. LFM3-1.7B-Base, pubblicato il 26 ottobre 2026, è il 36% più piccolo di LFM2.5-2.6B-Base, che Liquid AI ha rilasciato il 4 agosto 2026 — 1,73 miliardi di parametri contro 2,69 miliardi. È stato anche addestrato su meno token: 22 trilioni contro circa 34 trilioni. Secondo i due numeri che il settore usa di solito per classificare i modelli pre-addestrati, il checkpoint più recente dovrebbe essere peggiore. L'affermazione di Liquid è l'opposto, almeno per il modello post-addestrato costruito su di esso, e la domanda interessante per chiunque scelga un trunk da fine-tuneare è quale di queste differenze sia reale e quale sia una storia raccontata con una suite di benchmark. Eseguire il confronto dovrebbe costare calcolo, non un secondo contratto. 0% di ricarico OrcaRouter applica ai prezzi di listino dei fornitori un ricarico dello 0%.

Questo è un confronto all’interno di una stessa famiglia, il che lo rende insolitamente pulito. Stesso fornitore, stessa famiglia di licenze, stesso vocabolario da 128.000 token, stessa dimensione nascosta di 2.048, stesso ruolo base-to-base. I due checkpoint differiscono per architettura, volume di dati, lunghezza del contesto e quantità di post-addestramento incorporata nel tronco. Quasi tutto il resto rimane costante.

Il delta, dimensione per dimensione

• Parametri — 1.73B per LFM3-1.7B-Base contro 2.69B per LFM2.5-2.6B-Base. Una riduzione del 35.7%, da cui deriva la dicitura "35% in meno di parametri" nel post di lancio di Liquid.

• Livelli — 24 contro 30. Il modello più recente è meno profondo e anche più stretto.

• Mix di layer — tredici convoluzioni corte con gating, cinque blocchi di attenzione a finestra scorrevole e sei blocchi di attenzione completa per LFM3; ventidue convoluzioni e otto blocchi di attenzione completa per LFM2.5, senza livello a finestra scorrevole.

• Attenzione — sedici teste di query e quattro teste chiave-valore in LFM3, rispetto a trentadue e otto in LFM2.5. Entrambi mantengono la dimensione della testa a 128 e la dimensione nascosta a 2.048.

• Larghezza feed-forward — 7.680 per LFM3 rispetto a 10.752 per LFM2.5. È qui che si concentra in realtà la maggior parte della riduzione dei parametri.

• Cache delle convoluzioni — sette per LFM3 contro tre per LFM2.5, con l'aggiunta di una finestra scorrevole di 256 token.

• Contesto — 262.144 token contro 128.000. Il checkpoint più recente lo raddoppia.

• Token di pre-addestramento — 22 trilioni contro circa 34 trilioni, con gli ultimi 3,5 trilioni dell'esecuzione più recente dedicati a dati curati di mid-training, incluse tracce agentiche e chiamate agli strumenti.

• Artefatti — LFM3-1.7B-Base viene distribuito solo come safetensors BF16, a 3,46 GB. LFM2.5-2.6B-Base è disponibile in Safetensors più build GGUF, ONNX e MLX, occupa meno di 2,5 GB quantizzato ed è supportato da Transformers, vLLM, SGLang, llama.cpp e MLX.

Dove sono finiti i parametri

La riduzione non è distribuita uniformemente, e questo conta per chiunque stimi il costo del fine-tuning. Gli embedding sono condivisi in entrambi i modelli e il vocabolario è identico a 128.000 token, quindi la matrice degli embedding rimane invariata. La dimensione nascosta rimane invariata a 2.048. Il risparmio deriva da tre fattori: sei layer in meno, la metà delle teste di attenzione e un blocco feed-forward circa il 29% più stretto.

Restringere il blocco feed-forward è il modo più economico per ridurre un transformer, perché quel blocco contiene la maggior parte dei parametri in ogni layer. Dimezzare le teste di attenzione riduce sia la cache key-value sia i pesi, ed è per questo che un modello con una context window raddoppiata può comunque essere descritto come adatto a stare in circa 1 GB a 4-bit. Il compromesso è la capacità: un MLP più stretto ha meno spazio per immagazzinare associazioni fattuali, e un numero inferiore di teste offre al modello meno pattern di attenzione indipendenti con cui lavorare. L'argomentazione di Liquid è che dati migliori e una migliore combinazione di layer compensino più che ampiamente. Questa argomentazione è verificabile e, al momento della pubblicazione, nessuno al di fuori dell'azienda l'ha verificata.

Da dove proviene il contesto

Raddoppiare il contesto da 128K a 256K senza raddoppiare il costo dell'attenzione richiede di non applicare l'attenzione a livello globale. Lo stack di LFM3 lo fa assegnando cinque dei suoi ventiquattro layer a una finestra scorrevole di 256 token e tredici alle convoluzioni, lasciando solo sei layer che vedono l'intera sequenza. La configurazione include anche un fattore rotativo parziale di 0,5 sui layer di attenzione globale, applicando embedding rotativi a metà delle dimensioni di ciascuna testa, e un theta rotativo di un milione su quei layer contro diecimila su quelli scorrevoli.

Il post di lancio di Liquid fornisce un numero concreto per ciò che questo comporta: a 128K token, la KV cache del modello testuale è di 1,6 GB. Per LFM2.5-2.6B-Base non è pubblicato alcun dato equivalente. Il confronto è quindi indicativo anziché esatto — la nuova architettura è progettata per mantenere un contesto più lungo con meno memoria, e il dato del fornitore è l'unica misurazione disponibile.

Perché meno token è l'affermazione interessante

Passare da trentaquattro trilioni di token a ventidue trilioni rappresenta una riduzione del 35% del calcolo di pre-addestramento a livello di dati, ed è la direzione opposta rispetto alla maggior parte delle generazioni di modelli. La storia abituale è più dati, più parametri, modello migliore. La storia di Liquid è meno di entrambi, con una nuova architettura e una miscela di dati che aggiunge articoli scientifici, codice a livello di repository, matematica e una più ampia varietà di fonti di conoscenza.

La fase di mid-training da 3,5 trilioni di token è ciò che distingue questo checkpoint da un semplice pre-training. Utilizza dati curati e di qualità superiore, con una quota maggiore di tracce agentiche e chiamate agli strumenti, ed è qui che viene estesa la finestra di contesto. Questa fase è anche il motivo per cui il modello base include un template di chat: i dati di mid-training sono stati formattati come conversazioni, con e senza tracce di pensiero.

Nessuna di queste informazioni può essere verificata dall'esterno. I conteggi dei token sono autodichiarati, i mix di dati non vengono pubblicati e non esiste alcuna ablazione che mostri quale modifica abbia prodotto quale guadagno. L'affermazione è plausibile — negli ultimi due anni la qualità dei dati ha ripetutamente superato il volume grezzo — ma plausibile non equivale a misurato.

Cosa può chiarire un confronto base a base

Può chiarire specifiche, costi e compatibilità, e questa pagina lo fa. Non può chiarire la qualità, perché nessuno dei due checkpoint ha un benchmark pubblicato. Liquid non ha pubblicato alcuna valutazione per LFM2.5-2.6B-Base e non ne ha pubblicata nessuna nemmeno per LFM3-1.7B-Base. Entrambe le schede consigliano il checkpoint per un fine-tuning esteso e indirizzano i lettori altrove per la chat.

L’unica prova di qualità nella famiglia è la coppia post-addestrata. Liquid riporta LFM3-1.7B a una media di 49,37 sulla propria suite rispetto a 31,55 per LFM2.5-2.6B, con il modello più recente che usa il 35% in meno di parametri. Si tratta di un divario ampio, ed è un dato del fornitore misurato su una suite scelta dal fornitore, confrontando due modelli che differiscono sia nel post-addestramento sia nel trunk. È una prova che la ricetta LFM3 produce un modello instruct migliore. Non è una prova che il checkpoint di base sia un punto di partenza migliore, perché il post-addestramento sopra di esso potrebbe spiegare l’intera differenza.

Note di migrazione per chiunque utilizzi LFM2.5

I due checkpoint condividono una dimensione del vocabolario, una dimensione nascosta e una famiglia di tokenizer, il che fa sembrare la migrazione più semplice di quanto sia. Non condividono il codice di modellazione: LFM2.5 viene caricato come Lfm2ForCausalLM e LFM3 come Lfm3ForCausalLM, entrambi tramite codice personalizzato con trust_remote_code=True. Uno script di addestramento scritto per uno non caricherà l'altro senza cambiare la classe del modello, e i template di chat sono diversi nella gestione delle tracce di ragionamento.

La differenza operativa più importante è il packaging. LFM2.5-2.6B-Base dispone di build GGUF, ONNX e MLX e funziona con llama.cpp, vLLM, SGLang, Transformers e MLX. LFM3-1.7B-Base viene distribuito come un singolo file safetensors BF16; le build quantizzate e multipiattaforma esistono per LFM3-1.7B post-addestrato, non per il checkpoint base. Se la tua pipeline dipende da un artefatto GGUF, dovrai convertirlo autonomamente e validare il risultato.

Il supporto al fine-tuning è il contrappeso. LFM3-1.7B-Base collega notebook TRL per il fine-tuning supervisionato e il pre-addestramento continuato, e la documentazione copre il percorso da lì. Il checkpoint più piccolo, il contesto da 256K e il mid-training agentico sono tutti mirati esattamente al tipo di adattamento al dominio che quei notebook dimostrano.

Da quale tronco iniziare

Parti da LFM3-1.7B-Base se stai iniziando un nuovo fine-tuning, il tuo task trae beneficio dal contesto lungo e puoi lavorare in BF16 con Transformers o convertire i pesi da solo. La riduzione del 35% dei parametri è un risparmio reale in una sessione di addestramento su singola GPU, il contesto raddoppiato è un vero cambiamento di capacità e il template della chat accorcia la fase supervisionata.

Resta su LFM2.5-2.6B-Base se hai già una pipeline funzionante, dipendi da un artefatto GGUF o ONNX, oppure hai bisogno di un checkpoint con un anno di strumenti della community alle spalle. Il modello più recente ha solo tre giorni di vita. La sua variante instruct dispone di build quantizzate e del supporto dal primo giorno in vLLM, SGLang, llama.cpp, Ollama, LM Studio, MLX e ONNX Runtime, ma il checkpoint base no, e questo divario è il costo pratico dell'essere in anticipo.

Se non sei sicuro, esegui l'esperimento invece di leggere il materiale di marketing. Prendi una piccola porzione dei tuoi dati, esegui la stessa ricetta di pre-addestramento continuato su entrambi i trunk per lo stesso numero di passaggi e valuta su un set di hold-out che hai creato prima di iniziare. Sono poche ore di GPU e risponde a una domanda a cui nessuna tabella di fornitore può rispondere. Quando esistono i due fine-tuning, mettili entrambi dietro un unico endpoint di OrcaRouter: il DSL di routing può suddividere il traffico tra di essi, e il failover automatico significa che un esperimento sbagliato non diventa una giornata di produzione sbagliata. La piattaforma applica ai prezzi di listino dei fornitori un ricarico dello 0%, quindi il costo per eseguire il test è il costo della potenza di calcolo, non un secondo contratto.

Il numero da tenere d'occhio

L'affermazione che risolverebbe la questione non è un'altra media. È una valutazione di un modello base — qualsiasi valutazione di un modello base — pubblicata da Liquid o da terzi, che confronti LFM3-1.7B-Base e LFM2.5-2.6B-Base dopo una ricetta di fine-tuning identica. Finché non esisterà, il delta generazionale è documentato nell'architettura e nella configurazione, plausibile nei conteggi dei token e non dimostrato dove conta. Il checkpoint più recente è più piccolo, con un contesto più lungo e meglio strutturato per l'addestramento. Se sia migliore è una domanda a cui il repository non risponde.