LFM2 guida completa: come funziona il Liquid Foundation Model per l’on-device AI

Di /
stato della ricerca deep learning

Che cos’è LFM2: guida a un foundation model pensato per girare sul device

LFM2 è la seconda generazione dei Liquid Foundation Models sviluppati da Liquid AI, una famiglia di modelli generativi progettati esplicitamente per girare on-device: smartphone, laptop, sistemi embedded, CPU e NPU di fascia consumer, non solo grandi GPU in datacenter.

A differenza dei classici modelli transformer da decine di miliardi di parametri, LFM2 si concentra su una fascia “small” ma molto curata:

  • modelli densi da circa 350M, 700M, 1.2B, 2.6B parametri, tutti con context window di 32K token
  • un modello Mixture-of-Experts (MoE) da 8.3B parametri totali ma solo 1.5B attivi per token, pensato per avere qualità da modello medio-grande con costi di calcolo molto più bassi

Su questa spina dorsale linguistica vengono poi costruite varianti multimodali e specializzate:

  • LFM2-VL, modelli vision-language per testo+immagini
  • LFM2-Audio, un modello audio-text-audio per ASR, TTS e voice assistant in tempo reale
  • LFM2-ColBERT, una variante per information retrieval in stile ColBERT, ottimizzata per ricerca monolingue e multilingue

Tutti i modelli LFM2 vengono rilasciati con pesi open e pacchetti di deploy pronti per Transformers, llama.cpp, ExecuTorch e vLLM, inclusi profili di quantizzazione pensati per CPU e SoC mobili.

Perché LFM2 è interessante

Se ti interessa “come funziona LFM2” e cerchi una “guida a LFM2” per capire se può funzionare sui tuoi device, il punto chiave è questo:

LFM2 è uno dei primi tentativi davvero sistematici di progettare un foundation model edge-first, cioè partendo dai vincoli del device (latency, memoria, consumo) e non adattando a posteriori un grande modello server-side. L’architettura, la scelta dei dati, il training recipe e il post-training sono co-progettati con misure di time-to-first-token, latency p50/p95 e peak memory su hardware reale, inclusi telefoni Android e CPU laptop.

Questo approccio permette di:

  • ottenere latenze molto basse anche in quantizzazione Q4 su CPU
  • restare entro budget di RAM tipici di smartphone moderni
  • mantenere una qualità competitiva su benchmark difficili (MMLU, GSM8K, IFEval, ecc.) rispetto ad altri small models open-source come Qwen3, Gemma 3, Llama 3.2, Granite e SmolLM3.

Per esempio, LFM2-2.6B raggiunge circa 64% di MMLU, oltre 82% su GSM8K e più del 79% su IFEval, rimanendo entro la classe “small model” e mantenendo throughput molto elevato su smartphone e laptop.

La variante LFM2-8B-A1B, pur avendo solo 1.5B parametri attivi, porta ancora più in alto i risultati su matematica e instruction following, avvicinandosi a modelli server più grandi pur restando compatibile con device edge.

Sul lato multimodale, LFM2-VL-3B è competitivo o superiore a modelli come Qwen2.5-VL-3B e altri VLM sotto i 4B parametri su benchmark di visione, OCR e multimodal reasoning, mantenendo allo stesso tempo ottime capacità linguistiche.

Con LFM2-Audio, Liquid AI dimostra infine che si può avere un modello unico che fa chat vocale, ASR e TTS con qualità vicina a modelli più grandi come Qwen2.5-Omni-3B e Whisper-large-v3-turbo, ma con latenza e footprint compatibili con l’on-device.

Per chi vuole esplorare direttamente codice e modelli, ecco i riferimenti principali:

leap-finetune (repo ufficiale di fine-tuning per LFM2), LFM2 Technical Report su arXiv (2511.23404), Dataset di training: non disponibile come dataset pubblico unificato (la miscela di dati è descritta nel paper ma non viene rilasciata come collezione scaricabile).

Indice

Come funziona LFM2: architettura ibrida e training recipe spiegate passo per passo

Per capire davvero come funziona LFM2, bisogna partire da tre elementi: architettura ibrida, pre-training con knowledge distillation Top-K e post-training in tre stadi, a cui si aggiungono i recipe specifici per multimodalità e audio.

Architettura ibrida edge-first

LFM2 non è un semplice transformer standard. Liquid AI utilizza una hardware-in-the-loop architecture search: genera molteplici varianti di architettura, le addestra su un dataset di riferimento e misura in automatico qualità, latency e memoria su device reali (smartphone Snapdragon e CPU Ryzen) usando gli stessi stack di deploy che useranno in produzione (ExecuTorch, llama.cpp, vLLM).

Nel loro spazio di ricerca includono:

  • blocchi con short convolution, sliding-window attention, varianti di linear attention e state space models tipo S4, Liquid-S4, Mamba, ecc.
  • blocchi di grouped-query attention (GQA) con QK-norm per l’attenzione globale
  • MLP SwiGLU con diversa espansione
  • layout diversi di interleaving tra questi blocchi, con e senza opzioni MoE

La cosa interessante, e controintuitiva, è il risultato: sotto vincoli realistici di latency e memoria edge, la ricerca trova che basta un ibrido minimo:

  • la maggior parte dei layer sono gated short convolution blocks, operatori di convoluzione 1D locale con gating che mescolano token vicini molto velocemente e con ottimo uso della cache CPU
  • solo una piccola frazione di layer utilizza GQA, che fornisce l’attenzione globale necessaria per recupero di contesto e ragionamento a lungo raggio

Secondo gli autori, aggiungere altri operatori “alla moda” (linear attention, SSM complessi, extra convoluzioni) non migliora il trade-off qualità-latency-memoria, e anzi spesso peggiora i tempi o l’uso di memoria senza dare benefici stabili su downstream tasks.

In pratica, per “come funziona LFM2” a livello di backbone possiamo pensarlo così:

  • le gated short convolution gestiscono la maggior parte del lavoro di mescolamento locale, economico e parallelizzabile
  • pochi layer di GQA fanno da “ponti lunghi” che collegano parti lontane della sequenza e curano retrieval e ragionamento globale
  • MLP SwiGLU completano il blocco, come in molti moderni transformer

Questa struttura è mantenuta identica nei modelli densi e nel backbone del modello MoE.

Varianti dense e Mixture-of-Experts

Le varianti dense (350M-2.6B) condividono lo stesso tipo di blocchi con diversa profondità e ampiezza, tutte con context window di 32K token. Il modello LFM2-8B-A1B estende questo backbone sostituendo gran parte delle MLP con MoE layer: 32 esperti per layer, di cui solo pochi (Top-k) vengono attivati per ogni token, con un router a base di sigmoid e bias per bilanciare il carico tra esperti.

Lo scopo è chiaro: il modello ha abbastanza capacità totale per imparare molte competenze specializzate, ma ogni token paga il costo computazionale di soli 1.5B parametri attivi. Da qui l’idea di “qualità da 3-4B con costo da ~1.5B”.

Tokenizer e supporto multilingue

LFM2 utilizza un byte-level BPE tokenizer con vocabolario da 65.536 token, addestrato sulla stessa miscela di dati del pre-training. La costruzione del tokenizer è esplicitamente ottimizzata per inglese, giapponese, arabo, coreano, spagnolo, francese e tedesco, con supporto aggiuntivo per cinese, italiano e portoghese, includendo anche JSON e codice per migliorare l’efficienza su formati strutturati.

Sono previsti token speciali per:

  • fill-in-the-middle (FIM)
  • tool / function calling
  • template di chat in stile ChatML

Questo rende LFM2 pronto per agenti, tool-calling e chat multi-turn già a livello di base model.

Pre-training multi-stage con decoupled Top-K distillation

Il pre-training è pensato per piccoli modelli ma con un budget di token comunque elevato:

  • modelli densi: circa 10T token a context 4.096, seguiti da 1T token addizionali di mid-training a 32K su dati di qualità più alta e naturalmente long-context
  • modello MoE: 12T + 1T con recipe analogo

La composizione dei dati per i modelli densi è, in prima approssimazione:

  • 75% testo inglese
  • 20% testo multilingue
  • 5% codice

Per il modello MoE, aumenta la quota di codice (circa 15%), mantenendo comunque una forte componente multilingue.

Durante il pre-training, LFM2 non usa solo la classica next-token cross-entropy. Usa anche una forma di knowledge distillation da un teacher interno, LFM1-7B, ma in modo particolare: decoupled, tempered Top-K distillation.

L’idea, semplificando e senza formule, è questa:

  • il teacher per ogni token produce una distribuzione sulle possibili next token, ma per ridurre banda e storage si considerano solo le Top-K opzioni più probabili
  • se si applicasse direttamente una KL “normale” su questa distribuzione troncata, specialmente con temperature scaling, si rischierebbero instabilità perché si perde informazione sulla “coda” della distribuzione (support mismatch)
  • gli autori quindi separano il problema in due parti:
  • quanta probabilità totale il teacher assegna al set Top-K
  • come distribuisce questa probabilità all’interno del Top-K
  • il modello studente viene addestrato prima ad allineare la massa totale sul Top-K e poi la forma relativa all’interno del Top-K, applicando temperatura solo alla seconda parte

In questo modo, LFM2 riesce a sfruttare il segnale “soft” del teacher usando solo poche logit per token, evitando instabilità numeriche e problemi di support mismatch, e combinando il tutto con la classica cross-entropy su label dure.

Post-training in tre stadi: SFT, preference alignment, model merging

Dopo il pre-training, ogni checkpoint LFM2 passa attraverso un post-training a tre fasi:

  1. Supervised Fine-Tuning (SFT)
    In questa fase il modello impara il chat template e un insieme ampio di abilità “di base” per l’assistente: seguire istruzioni, rispondere in stile conversazionale, fare RAG, usare tool, risolvere problemi di matematica. Il corpus SFT include circa 5.39M esempi per i modelli densi e oltre 9M per il modello MoE, integrando 67-79 sorgenti tra open source, dati licenziati e generazioni sintetiche, con integrazione sistematica di esempi multilingue in quasi tutte le categorie.

  2. Preference Alignment
    Qui si usano dati di preferenza (offline, inclusi esempi on-policy generati dal modello SFT) per eseguire un allineamento stile preference optimization, cioè insegnare al modello non solo a produrre risposte corrette, ma anche a preferire quelle più utili, sicure e allineate alle linee guida. Nel paper si parla di dataset “off-policy” e componenti specifiche per questo passaggio, ma concettualmente è una forma di RLHF / DPO-like adattata ai piccoli modelli.

  3. Model Merging
    Alla fine vengono combinati più modelli specializzati (per esempio modelli ottimizzati per matematica, RAG, tool calling, ecc.) attraverso diverse tecniche di model merging: model soup, task arithmetic, TIES, DARE, DELLA e varianti. L’obiettivo è incorporare competenze complementari in un unico checkpoint finale senza dover rifare da zero un fine-tuning multi-task gigantesco.

Estensioni multimodali: LFM2-VL

Per i modelli vision-language LFM2-VL, la ricetta è simile ma con qualche ingrediente in più:

  • la vision backbone è un SigLIP2 nella variante NaFlex, capace di gestire immagini a risoluzione variabile
  • un connettore leggero basato su PixelUnshuffle + MLP riduce il numero di token visivi di un fattore 4 e li proietta nello spazio dei token linguistici LFM2, così da avere un’unica sequenza di token per testo e immagine

Il training avviene in tre fasi:

  • connector pre-training su un corpus di captioning ben allineato
  • multimodal mid-training, dove testo e immagini vengono mescolati con una schedule di data annealing: si parte da 100% testo e si scende fino a circa 30% testo e 70% multimodale, per poi proseguire a lungo a context 32K
  • joint multimodal SFT, con dataset per VQA, OCR, multi-image reasoning, conversational VLM, ecc., inclusa una porzione significativa di dati multilingue (anche in italiano) per le varianti più grandi come LFM2-VL-3B

Estensioni audio: LFM2-Audio

LFM2-Audio-1.5B prende il backbone linguistico LFM2-1.2B e lo estende con due rami dedicati all’audio:

  • un audio encoder che trasforma waveforms raw in log-mel features, poi in embedding continui con una pila di convoluzioni + FastConformer, prima di proiettarli nello spazio di LFM2
  • un percorso di audio decoder che non genera waveforms direttamente ma codici discreti RVQ (Mimi), con un RQ-Transformer più piccolo che genera i codici condizionato sull’output del backbone, e un detokenizer stile Vocos che converte i codici in audio 24kHz in tempo quasi reale

Questa separazione tra input continuo e output discreto permette di mantenere rappresentazioni ricche per ASR e comprensione, evitando al tempo stesso overhead e artefatti tipici di alcuni schemi di tokenizzazione audio.

Retrieval: LFM2-ColBERT

Per il retrieval, LFM2-ColBERT-350M aggiunge una testa specifica sopra il backbone LFM2-350M, adottando il paradigma late-interaction di ColBERT: query e documenti sono codificati in vettori per token, pre-indicizzati, e la similarità viene calcolata con una max-similarity su tutte le coppie di token rilevanti, preservando molta espressività rispetto ai bi-encoder classici ma con costi molto più bassi dei cross-encoder.

Il training usa knowledge distillation da un cross-encoder teacher, e i risultati mostrano un chiaro vantaggio sulla copertura multilingue rispetto a baseline come GTE-ModernColBERT-v1.

Risultati LFM2: cosa ci dicono i benchmark su qualità e velocità

Una guida completa a LFM2 non può evitare la domanda più pratica: “ok, ma quanto bene va rispetto agli altri modelli small open-source?”

Testo: knowledge, instruction following, matematica, multilingue

La Technical Report presenta un’ampia tabella di risultati per i modelli da 350M a 8B, confrontati con Qwen3, Gemma 3, Llama 3.2, SmolLM3, Granite e altri.

A livello qualitativo:

  • nel range 350M-1.2B, i modelli LFM2 tendono a superare nettamente modelli di grandezza paragonabile su benchmark di knowledge (MMLU), instruction following (IFEval, IFBench, Multi-IF) e math reasoning (GSM8K, GSMPlus, MATH), spesso con meno token di training rispetto ad alcuni concorrenti
  • LFM2-1.2B, ad esempio, ottiene circa 55% su MMLU, 58% su GSM8K e oltre 74% su IFEval, superando corrispondenti modelli 1B-1.7B di altre famiglie in diversi setting di benchmark

Nei modelli più grandi:

  • LFM2-2.6B raggiunge ~64.4% su MMLU, più di 82% su GSM8K e oltre 60% su GSMPlus, con ottimi punteggi anche su MATH 500 e MATH Level 5
  • LFM2-8B-A1B spinge ancora oltre, con punteggi oltre 84% su GSM8K, ~75% su MATH 500 e oltre 62% su MATH Level 5, pur avendo solo 1.5B parametri attivi per token

Sul fronte multilingue, metriche come MMMLU e MGSM mostrano che LFM2 mantiene una buona frazione delle sue performance inglesi anche in altre lingue, grazie alla strategia di training che integra i campioni multilingue in quasi tutte le categorie di dati, invece di trattarli come un blocco separato.

Velocità su smartphone e laptop

Una delle parti più importanti della LFM2 guida completa è capire le prestazioni su hardware “normale”.

Su uno smartphone Samsung Galaxy S25 con SoC Snapdragon 8 Elite, usando llama.cpp in quantizzazione Q4_0, LFM2-350M supera i 1000 token/s di prefill su prompt da 1K token e mantiene throughput elevato anche a 4K, risultando fino a circa 2 volte più veloce di baseline come Granite-4.0-350M nelle stesse condizioni.

Modelli come LFM2-700M e LFM2-1.2B battono sistematicamente Qwen3-0.6B, Qwen3-1.7B, Llama-3.2-1B e altre varianti in termini di token/s sia in prefill che in decode, pur avendo qualità comparabile o migliore sui benchmark linguistici.

Su un laptop con AMD Ryzen AI 9 HX 370, le differenze diventano ancora più evidenti: LFM2-350M supera i 7.500 token/s di prefill su prompt da 1K, mentre modelli concorrenti restano sensibilmente sotto. Anche qui, LFM2-2.6B e LFM2-8B-A1B mantengono un ottimo equilibrio tra throughput e qualità rispetto a modelli 3-4B come Qwen3-4B, Gemma-3-4B e SmolLM3-3B.

Gli autori riassumono questi risultati mostrando come i punti corrispondenti ai modelli LFM2 dominino la Pareto frontier tra average eval score e prefill / decode throughput: per un dato livello di velocità, LFM2 tende a offrire la qualità più alta tra i modelli considerati.

Vision-language: LFM2-VL vs altri VLM small

Per la parte multimodale, la famiglia LFM2-VL mostra ottimi risultati su benchmark come MMBench, MMStar, SEEDBench, RealWorldQA, OCRBench, MMMU, MathVista e altri.

In sintesi:

  • LFM2-VL-450M batte nettamente SmolVLM2-500M su MMStar e MMBench, e ottiene punteggi migliori su OCRBench, mostrando che anche un modello sotto i 500M parametri può offrire visione competitiva
  • LFM2-VL-1.6B è competitivo con InternVL3.5-1B e altri modelli around 1-2B
  • LFM2-VL-3B spesso supera SmolVLM2-2.2B, InternVL3.5-2B e Qwen3-VL-2B su molte metriche, e resta vicino o superiore a Qwen2.5-VL-3B pur con parametri totali comparabili

Anche qui, un punto importante per chi cerca “come funziona LFM2-VL” è la graceful degradation rispetto al budget di vision token: riducendo il numero di token visivi per immagine, le prestazioni calano lentamente sulle task generali e solo più rapidamente sui task ad alta risoluzione, dando un controllo esplicito al deployer sul trade-off accuracy-latency.

Audio: LFM2-Audio-1.5B vs Qwen2.5-Omni e Whisper

LFM2-Audio viene valutato sia su VoiceBench (una suite di task per chatbot vocali) sia su un set di dataset ASR standard presi dall’Open ASR Leaderboard.

Rispetto a Qwen2.5-Omni-3B e a modelli come Moshi, Ultravox e Mini-Omni2, LFM2-Audio-1.5B:

  • mantiene punteggi molto competitivi su metriche di chat vocale e question answering
  • offre latenze più basse grazie alla combinazione backbone + RQ-Transformer + detokenizer ottimizzato

Sui task ASR, la Word Error Rate risulta vicina a quella di Whisper-large-v3-turbo su diversi dataset, nonostante il focus del modello sia più ampio (speech-to-speech chat, non solo trascrizione).

Retrieval: LFM2-ColBERT e NanoBEIR

Infine, LFM2-ColBERT-350M mostra forti miglioramenti su NanoBEIR rispetto a baseline come GTE-ModernColBERT-v1: la degradazione di NDCG@10 passando da inglese a lingue come arabo, giapponese e coreano è molto più contenuta, segno che il training multilingue del backbone e l’architettura late-interaction funzionano bene anche per cross-lingual retrieval.

Concetti chiave da capire per leggere bene la LFM2 Technical Report

Per usare davvero questa guida a LFM2 come “guida completa” al paper, ecco i concetti che vale la pena interiorizzare prima (e durante) la lettura.

Edge-first design

Un modello è “edge-first” quando tutto – architettura, training, quantizzazione, toolchain – è pensato partendo dai vincoli di device come telefono o laptop: time-to-first-token, latenza media e massima per token, peak memory per 4K e 32K token. In LFM2 questi numeri entrano direttamente nella procedura di architecture search e nella selezione dei checkpoint da rilasciare.

Gated short convolution vs attention globale

Le gated short convolution possono essere viste come un modo molto efficiente di mescolare informazioni tra token vicini: prendono una finestra locale, applicano una convoluzione depthwise e poi un gating che decide cosa far passare e cosa no. Sono economiche, cache-friendly e facili da ottimizzare su CPU.

La grouped-query attention (GQA) invece è il meccanismo che permette al modello di guardare lontano nella sequenza. Condividendo key/value tra gruppi di head, riduce la dimensione del KV cache e il traffico memoria, mantenendo però la flessibilità dei query. In LFM2 solo pochi layer usano GQA, il resto è affidato alle convoluzioni, riducendo molto il costo quadratico classico dell’attenzione.

Mixture-of-Experts (MoE) “attivo”

Nel modello LFM2-8B-A1B, il numero di parametri totali è alto (8.3B), ma solo una piccola sotto-matrice di esperti viene realmente attivata per ciascun token, grazie a un router che sceglie i Top-k esperti più utili. Questo significa che il costo di decode per token è simile a un modello molto più piccolo, mentre la capacità complessiva per apprendere competenze specializzate è quella di un modello più grande. Quando nel paper vedi “active params”, pensa proprio al numero di parametri che partecipano effettivamente al calcolo per token.

Pre-training vs post-training

Il pre-training è la fase in cui il modello impara a prevedere il token successivo su una grande miscela di dati generalisti (testo, multilingue, codice). È qui che acquisisce linguaggio, conoscenza del mondo, pattern generali.

Il post-training è la fase in cui si plasma il comportamento “da assistente” e si consolidano abilità specifiche (chat, RAG, tool calling, math, sicurezza). L’uso di SFT, preference optimization e model merging fa sì che piccoli modelli come LFM2 possano essere molto più utili e robusti, pur avendo visto meno dati rispetto a modelli giganti.

Decoupled Top-K knowledge distillation

Qui la chiave è capire che il teacher non passa al student tutta la distribuzione di probabilità, ma solo le top K candidate. Se ci si limitasse a fare una KL classica su questa distribuzione troncata, si otterrebbero gradienti strani: il modello verrebbe punito per non mettere massa dove il teacher non ha esplicitamente dato nessuna informazione.

La decoupled Top-K distillation “spacchetta” l’obiettivo in:

  • quanta massa totale sta nel Top-K secondo il teacher
  • come è distribuita quella massa tra le K opzioni

Il modello student impara entrambe le cose separatamente, e la temperatura viene applicata solo alla parte “intra-Top-K”, evitando instabilità e permettendo di usare temperature più alte per rendere il segnale del teacher più espressivo.

Curriculum learning e data mixture

LFM2 usa una forma di curriculum learning: i dati vengono organizzati per difficoltà o per competenza (per esempio matematica, tool use, long-context, ecc.) e introdotti in sequenza o con schedulazioni pensate per massimizzare ciò che il modello impara a parità di compute. La miscela SFT è costruita iterativamente, ottimizzando singole capacità prima di combinarle in un mixture bilanciato.

Multimodalità con SigLIP2 e PixelUnshuffle

In LFM2-VL il trucco è far “parlare la stessa lingua” a immagini e testo:

  • SigLIP2 produce embedding per patch d’immagine
  • PixelUnshuffle riduce il numero di token visivi aggregando i pixel in macro-patch
  • un MLP proietta queste feature nello spazio dei token linguistici LFM2

Da quel punto in poi, l’immagine è solo una serie di token “speciali” nello stesso spazio del testo, e il modello può fare attenzione cross-modale con gli stessi blocchi convoluzione+GQA che usa per il linguaggio.

Audio generativo con RVQ e detokenizer

LFM2-Audio separa chiaramente input e output: l’encoder audio produce embedding continui compatibili con il backbone LFM2, mentre l’output viene generato come sequenza di codici RVQ (semantici + acustici) sopra cui opera un detokenizer leggero stile Vocos. Questo schema riduce la complessità di generare waveforms ad alta fedeltà e rende più facile mantenere bassa la latenza, perché il backbone non deve predire ogni campione audio ma solo frame di codici.

Late-interaction retrieval

Nel retrieval, la differenza tra bi-encoder, cross-encoder e late-interaction è cruciale:

  • i bi-encoder schiacciano query e documento in un singolo vettore ciascuno
  • i cross-encoder concatenano query e documento e fanno attention congiunta, ma costano troppo
  • i modelli late-interaction come ColBERT mantengono un embedding per token e fanno matching token-to-token in fase di retrieval, con un’operazione MaxSim che recupera la migliore corrispondenza per ogni token della query

LFM2-ColBERT usa questo schema sopra il backbone LFM2, e viene distillato da un cross-encoder più grande, ottenendo un buon compromesso tra qualità (vicina ai cross-encoder) e efficienza (simile ai bi-encoder).

Quiz su LFM2: metti alla prova la tua comprensione

Perché LFM2 è definito un modello edge-first?

LFM2 è edge-first perché l’intera progettazione – dalla scelta dei blocchi architetturali fino alla selezione dei checkpoint da rilasciare – è guidata da metriche misurate su hardware edge reale: tempo al primo token, latenza per token, throughput di prefill e picco di memoria su smartphone e CPU laptop, oltre alla qualità sui benchmark. Gli esperimenti di architecture search scartano direttamente configurazioni che violano i budget di latency e memoria, e mantengono solo quelle che stanno sulla Pareto frontier qualità-latency-memoria.

Quali sono i componenti principali del backbone LFM2?

Il backbone LFM2 combina principalmente tre componenti: gated short convolution blocks per il mixing locale veloce e cache-friendly; pochi layer di grouped-query attention (GQA) per l’attenzione globale e il retrieval a lungo raggio; e MLP SwiGLU per la trasformazione non lineare per token. Nei modelli MoE, le MLP vengono sostituite da layer Mixture-of-Experts, mantenendo invariata la parte convoluzione+GQA.

Che problema risolve la decoupled Top-K knowledge distillation?

La decoupled Top-K distillation risolve il problema del support mismatch quando si usa il teacher solo per le Top-K logit e si applica temperature scaling. Senza decoupling, la KL su una distribuzione troncata può diventare instabile perché la massa di probabilità fuori dal Top-K viene trattata implicitamente come zero. Separando la massa totale sul Top-K dalla distribuzione relativa all’interno del Top-K e applicando temperatura solo alla seconda, gli autori riescono a trasferire il “soft signal” del teacher usando poche logit per token senza instabilità numeriche, combinando il tutto con la classica cross-entropy su label dure.

In cosa consiste il post-training a tre stadi di LFM2?

Il post-training LFM2 consiste in tre fasi: SFT su una miscela ampia di dati per insegnare al modello a rispondere in chat, seguire istruzioni, fare RAG e usare tool; preference alignment su dati di preferenza offline (inclusi esempi generati dal modello SFT) per ottimizzare lo stile e la sicurezza delle risposte; e model merging, dove diversi modelli specializzati vengono combinati nello spazio dei pesi per ottenere un unico checkpoint con capacità composite (math, tool use, dialogo, long-context, ecc.) senza dover rifare un training enorme da zero.

A cosa serve la famiglia LFM2-VL?

La famiglia LFM2-VL estende LFM2 alla visione, permettendo di trattare testo e immagini insieme. Attraverso un encoder SigLIP2 e un connettore PixelUnshuffle+MLP, le immagini vengono convertite in token nello stesso spazio del linguaggio, così che il modello possa risolvere task di VQA, OCR, multi-image reasoning, document understanding, ecc. LFM2-VL è stato pensato per mantenere la stessa efficienza edge dei modelli linguistici, offrendo allo stesso tempo performance competitive o superiori rispetto ai VLM open-source della stessa taglia.

Come funziona a grandi linee LFM2-Audio?

LFM2-Audio prende il backbone LFM2-1.2B e lo arricchisce con un encoder audio che trasforma waveforms in embedding continui, e un decoder che genera codici RVQ Mimi invece di waveform diretti. Un piccolo RQ-Transformer genera i codici condizionato sull’output del backbone, e un detokenizer stile Vocos li converte in audio 24kHz. Questo permette di avere un unico modello che può fare ASR (audio-in, text-out), TTS (text-in, audio-out) e chat vocale in tempo reale, con qualità competitiva rispetto a modelli molto più grandi.

Quando ha senso usare un modello come LFM2-350M e quando un LFM2-2.6B o LFM2-8B-A1B?

LFM2-350M è ideale per device molto vincolati o applicazioni dove la priorità è la latency minima (ad esempio piccoli agenti embedded, semplici assistenti offline, feature AI dentro app mobili). LFM2-2.6B è più indicato quando ti serve un compromesso qualità-latenza molto forte su task più complessi (math, coding leggero, RAG multiturno), restando in regime on-device. LFM2-8B-A1B ha senso quando vuoi massimizzare la qualità pur restando entro i budget di inferenza di un 1-2B: è particolarmente interessante per agenti complessi e applicazioni dove la qualità extra su reasoning e instruction following fa davvero la differenza.

Domanda 8: Cosa significa che LFM2 ha pesi open e perché è importante?

Dire che LFM2 ha open weights significa che i pesi dei modelli (dense, MoE, VL, Audio, ColBERT e i vari “Nanos”) sono scaricabili pubblicamente, ad esempio dall’account LiquidAI su Hugging Face, con licenze e toolchain di deploy espliciti. Questo è importante perché permette: fine-tuning personalizzato, deploy totalmente on-prem o on-device senza chiamate a servizi esterni, auditing indipendente, comparazioni più trasparenti con altri modelli open-source e un ecosistema di tool community-driven (come leap-finetune, cookbook, integrazioni in Transformers, ecc.).

Studi correlati e modelli affini a LFM2: cosa leggere dopo

Per chi vuole andare oltre questa LFM2 guida completa, il paper discute un ampio panorama di lavori collegati.

Un primo riferimento è la prima generazione di Liquid Foundation Models (LFM1) e il prototipo accademico STAR, dove gli autori avevano già sperimentato con search su operatori alternativi (state space, convoluzioni, varianti ibride) usando proxy come perplexity e cache size. LFM2 riprende quell’idea ma sostituisce le proxy con obiettivi più realistici (downstream tasks e misure hardware-in-the-loop), mostrando che a parità di obiettivi una configurazione più semplice (conv+GQA) è sufficiente.

Poi c’è l’ampio filone di architetture efficienti basate su state space models (SSM) e linear attention, come S4, Liquid-S4, Mamba, Hyena, ecc., che cercano di sostituire o integrare l’attenzione tradizionale con operatori sub-quadratici. LFM2 si colloca un po’ in controtendenza: riconosce i benefici delle componenti short-convolution presenti in molti di questi blocchi, ma conclude empiricamente che sulle metriche edge non serve portarsi dietro l’intera complessità degli SSM, se si progettano bene le convoluzioni e si inseriscono pochi layer di attenzione globale.

Sul fronte small language models open-source da confrontare o approfondire, il paper utilizza come baseline famiglie come Qwen3, Gemma 3, Llama 3.2, SmolLM3 e Granite 4.0, tutte focalizzate su modelli di pochi miliardi o meno, ma generalmente basate su architetture transformer più tradizionali. Leggere i loro report aiuta a mettere in prospettiva quanto sia alto il livello della competizione e dove LFM2 guadagna vantaggio (specie su throughput CPU e math/multilingue).

Per la parte multimodale, i confronti più frequenti sono con SmolVLM2, InternVL3.5, Qwen2.5-VL e altri VLM sotto i 4B parametri. Questi lavori esplorano scelte simili (encoder visivo separato, connector leggero, training in più fasi) ma con trade-off diversi tra resolution supportata, grounding, OCR, multi-image reasoning e bilanciamento tra capacità visive e linguistiche.

Sul versante audio, LFM2-Audio entra in dialogo con sistemi come Qwen2.5-Omni, Whisper, Moshi, Ultravox, Mini-Omni2, che rappresentano strategie diverse per unificare ASR, TTS e chat vocale. Alcuni puntano più sulla qualità di ASR, altri sulle capacità multimodali generali. Il contributo di LFM2-Audio è mostrare che un design backbone+RQ-Transformer+detokenizer pensato per edge può mantenere una qualità comparabile con modelli più grandi, ma con latenza e footprint più contenuti.

Infine, per il retrieval, lavori come ColBERT e GTE-ModernColBERT sono fondamentali per capire il contesto: definiscono il paradigma late-interaction e mostrano come recuperare gran parte della qualità dei cross-encoder mantenendo la scalabilità dei bi-encoder. LFM2-ColBERT applica questi principi usando un backbone edge-first e un training distillato, portando il paradigma anche nel regime dei piccoli modelli on-device.

Se stai esplorando modelli per l’on-device AI, leggere la LFM2 Technical Report insieme ai report di queste famiglie ti darà una visione abbastanza completa dello stato dell’arte, e questa guida a LFM2 dovrebbe aiutarti a muoverti tra sezioni, concetti e risultati senza perderti nei dettagli più tecnici.

Torna in alto