Fuga di notizie su LFM3: la prossima famiglia di Liquid AI è composta da quattro piccoli modelli Omni

Una pull request aperta su GitHub il 27 ottobre 2026 vuole insegnare a SGLang come servire una famiglia di modelli che non esiste pubblicamente. Indica quattro checkpoint — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B e LFM3-Omni-2B — e, letto in parallelo ai già rilasciati LFM2.5-2.6B e LFM2.5-24B-A2B, sembra un progetto per ciò che Liquid AI costruirà in seguito. La PR non è stata unita. Tutti e tre i suoi controlli CI stanno fallendo. Liquid AI non ha annunciato nulla di tutto ciò. Quel diff non unito è l'intero registro pubblico di LFM3 a oggi, ed è più informativo della maggior parte dei post di lancio — a patto di leggerlo per quello che è.

Quindi parliamo con precisione delle prove, perché sono scarse in una direzione e insolitamente dettagliate in un'altra. Qui non c'è nulla che sia una data di rilascio, un prezzo, un termine di licenza o un punteggio di benchmark. Non esiste alcuna model card di LFM3, alcun repository Hugging Face, alcun post di blog, alcun elenco API. Ciò che esiste è un contributo di tugot17 — Piotr Mazurek, che negli ultimi due mesi ha introdotto il supporto runtime per LFM in SGLang, llama.cpp e mlx-vlm — più il materiale pubblicato da Liquid stesso sulla generazione LFM2.5 che sta per essere soppiantata. Tutto ciò che segue è contrassegnato di conseguenza.

Cosa mette davvero sul tavolo la pull request

Il titolo della PR è [Feat] lfm3: Aggiungi supporto per testo, visione, audio e Omni, e porta due etichette che indicano che tipo di modifica è: jit-kernel e Multi-modal. Aggiunge la generazione nativa di testo per una famiglia di quattro, ciascuno con il proprio percorso di checkpoint:

• LFM3-1.7B — testo in ingresso, testo in uscita, il modello linguistico semplice alla base della famiglia

• LFM3-VL-2B — testo, immagini e video in ingresso, testo in uscita

• LFM3-Audio-2B — input testo e audio, output testo, e anche collegato all'endpoint /v1/audio/transcriptions

• LFM3-Omni-2B — testo, immagini, audio e video in ingresso, inclusa la colonna sonora di un video, testo in uscita

Un dettaglio in quella lista merita una pausa di riflessione. Ogni variante restituisce testo. Non esiste alcun percorso di output audio da nessuna parte nella PR, e la superficie non-chat del modello audio è la trascrizione: voce in ingresso, testo in uscita. Questo è più limitato della linea audio attuale di Liquid, dove LFM2.5-Audio-1.5B è documentato come in grado di gestire ASR, TTS e chat vocale intercalata in un unico modello. O il primo taglio SGLang copre solo la metà di LFM3-Audio dedicata alla generazione di testo, oppure la famiglia omni abbandona davvero la sintesi vocale. La PR non può stabilire quale delle due cose sia vera, e chiunque ti dica che lo fa sta tirando a indovinare. Considera «LFM3 parla» come non dimostrato.

Il resto del diff è dettaglio implementativo che comunque colloca cronologicamente il lavoro. Encoder di visione e audio con i relativi proiettori, una backbone condivisa, integrazione della cache ibrida, kernel di convoluzione CuTe DSL con un fallback PyTorch, e una nota sul fatto che FlashInfer usa per impostazione predefinita il prefill paginato, così l'attenzione a finestra scorrevole si comporta correttamente. La validazione è stata eseguita su H100 in FP16 usando quelli che la descrizione chiama development checkpoints — quattro parole che contano in seguito.

La frase sull'architettura, e il numero che le persone fraintenderanno

La PR descrive LFM3 come un backbone condiviso di convoluzioni corte con gating, con attenzione completa e a finestra scorrevole. È la linea evolutiva di LFM2 portata avanti, non sostituita: LFM2.5-24B-A2B è documentato come un ibrido di convoluzioni corte con gating e attenzione grouped-query su 40 livelli. Ciò che sembra nuovo nella fuga di notizie è la componente esplicita a finestra scorrevole che affianca l’attenzione completa.

Le note di convalida menzionano un prompt che supera una finestra scorrevole di 256 token, ed è questa la cifra che verrà citata fuori contesto per tutta la settimana. Non è la lunghezza del contesto di LFM3. In un design ibrido, gli strati di attenzione devono vedere solo localmente perché gli strati convoluzionali trasportano il segnale a lungo raggio — è l'intero presupposto dell'architettura, ed è per questo che la famiglia può mantenere 131,072 token di contesto su LFM2.5-24B-A2B mentre la maggior parte dei suoi strati non esegue affatto attenzione quadratica. Una finestra di attenzione di 256 token è un'affermazione su dove il modello guarda all'interno di un singolo strato, non su quanto testo può accettare. Il PR non indica il contesto totale di LFM3, e nessuno al di fuori di Liquid lo sa ancora.

Perché una pull request sul runtime è il segnale, non rumore

È ragionevole essere diffidenti nel ricavare la strategia di prodotto da un diff dell'infrastruttura. In questo caso specifico, lo schema è troppo coerente per essere ignorato, perché Liquid fornisce il supporto per i motori con i pesi anziché dopo di essi. LFM2.5-2.6B elenca llama.cpp, MLX, vLLM, SGLang, ONNX e Transformers 5.0+ tra i target supportati dal primo giorno. LFM2.5-24B-A2B era supportato in llama.cpp, MLX, vLLM, SGLang e ONNX al lancio. Una famiglia che arriva con cinque runtime pronti deve avere i propri kernel scritti prima dell'annuncio, il che significa che le PR arrivano prima e il post del blog segue.

L'autore si inserisce esattamente in quella cronologia. La storia pubblica di Mazurek è una serie di lavori di integrazione LFM: il decoding speculativo DSpark per LFM2-VL in SGLang a settembre, le correzioni ai modelli draft LFM2.5-VL-3B e DSpark in llama.cpp nello stesso mese, il decoding speculativo ereditato dal modello testuale in mlx-vlm e un riutilizzo della configurazione LFM2-MoE in SGLang il 13 ottobre. LFM3 è la voce successiva di quella sequenza, registrata nel fine settimana in cui la famiglia ha cambiato nome.

Due assenze sono altrettanto rivelatrici quanto la presenza. Non esiste una pull request corrispondente in Hugging Face Transformers per LFM3 — una ricerca in quel repository non restituisce nulla — e la PR di SGLang carica i suoi checkpoint tramite Transformers 5.19.0 standard con --trust-remote-code, che è ciò che si fa quando l'architettura non è ancora nativa nella libreria. C'è anche un commit che rifiuta esplicitamente la decodifica speculativa per LFM3, quindi il lavoro DSpark rilasciato per la generazione 2.5 non è ancora stato ripreso. Presto, e incompleto per design.

La domanda sulle dimensioni a cui nessuno ha risposto

Qui la fuga di notizie e l’ambizione dichiarata tirano in direzioni opposte, e la tensione è la cosa più interessante del documento.

Maxime Labonne, Head of Pretraining di Liquid, ha descritto l'obiettivo di LFM3 come la verifica se l'approccio a convoluzione breve che funziona alla scala da 350M a 1,2B possa reggere oltre i 10B parametri — il regime in cui le architetture attention hanno storicamente avuto il vantaggio. Si tratta di una questione di scaling, e implica un modello di grandi dimensioni.

I checkpoint trapelati sono 1.7B e tre a 2B. Nessuno di essi è al di sopra della soglia a cui si riferisce quella domanda.

Restano in piedi due interpretazioni. La prima è che questi siano la prima ondata compatta — una famiglia omni per telefoni e auto prima dell'arrivo di un fratello maggiore, il che corrisponde a come Liquid abbia sempre puntato prima sui modelli piccoli e a come la PR li descriva come checkpoint di sviluppo anziché release finali. La seconda è che 1.7B e 2B siano semplicemente le dimensioni convenienti per validare i kernel, e non ci dicano nulla su ciò che sarà effettivamente rilasciato. La posizione onesta è che il leak prova che la famiglia esiste e ne prova la forma; non ne prova il tetto. Se stai aspettando un modello Liquid >10B, questa PR non ne promette uno né lo esclude.

Ciò che LFM3 eredita, nel bene e nel male

Il baseline che deve battere è recente e ben documentato. LFM2.5-24B-A2B è stato rilasciato il 13 ottobre 2026 con 24B parametri totali e 2B attivi, 40 livelli, 64 esperti e routing top-4, una finestra di contesto di 131.072 token, un vocabolario da 128K e 33T token di pretraining. LFM2.5-2.6B, dei primi di agosto, sta in meno di 2,5 GB con un contesto di 128K. LFM2.5-VL-3B abbina la base 2.6B a un encoder visivo SigLIP2.

Vale la pena dirlo chiaramente: ogni benchmark che Liquid pubblica per questi è eseguito dal fornitore sui harness di Liquid stesso, senza alcuna valutazione indipendente associata. I numeri principali di LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — sono cifre di Liquid, e la stessa tabella mostra che perde contro Qwen3.6-35B-A3B su WebArena Verified (26.75 contro 37.62), GPQA Diamond e SWE-Bench Verified. Le tabelle dei fornitori che includono sconfitte sono più credibili di quelle che non le includono, ma credibile non è sinonimo di verificato. Non esiste alcun numero di LFM3 di alcun tipo, quindi non c'è ancora nulla da confrontare.

Anche la licenza sarà mantenuta. I recenti checkpoint LFM di Liquid su Hugging Face sono ciascuno etichettati license: other — una licenza LFM su misura, non Apache-2.0 o MIT. Qualunque sia la licenza con cui verrà distribuito LFM3, presupponi le stesse condizioni personalizzate finché una model card non indichi diversamente, e leggile prima di costruire un prodotto sui pesi.

Quando potrebbe effettivamente arrivare

Nessuno ha una data, nemmeno chi fa pronostici per professione. Una domanda su Manifold Markets riguardo a quando sarà rilasciato LiquidAI LFM3 assegna il 40% al Q4 2026, il 21% al Q1 2027, il 21% al Q2 2027, l'11% al Q3 2026 e il 7% al Q2 2026 — su un volume totale di circa Ṁ160, abbastanza piccolo da far sì che le percentuali riflettano una manciata di trader anziché un consenso. Interpretalo come «probabilmente entro i prossimi due trimestri», e non con maggiore precisione di così.

Le dinamiche tecniche suggeriscono prima piuttosto che dopo. Il lavoro sul kernel che approda in un runtime importante è ingegneria di fase finale, non iniziale: non si scrivono kernel di convoluzione CuTe e non si collega una cache ibrida per un modello che arriverà tra un anno. Il nome della famiglia si è stabilizzato su LFM3 in quattro varianti e quattro percorsi di checkpoint. Ma la PR non è unita, con tutti e tre i controlli rossi, richiede una revisione approvativa che non ha, e 2 dei 22 controlli di validazione omni e 2 dei 16 controlli visione falliscono ancora il confronto ROUGE. Questo è un branch a metà lavorazione, non un release candidate.

Che cosa significa se stai scegliendo un modello questa settimana

Niente riguardo a LFM3 dovrebbe cambiare una decisione che prendi oggi. Non è disponibile, non ha un prezzo pubblico, non è stato sottoposto a benchmark e non è concesso in licenza al pubblico. Se hai bisogno ora di un piccolo modello multimodale, la generazione LFM2.5 è la vera risposta, e i suoi vincoli — punteggi dichiarati dal fornitore, licenza personalizzata e un profilo di coding che sia le tabelle di Liquid sia la copertura esterna indicano come punto debole — sono gli elementi da valutare.

Ciò per cui la fuga di notizie è davvero utile è la pianificazione. Ti dice che sta arrivando una famiglia omni compatta, che probabilmente arriverà su più runtime contemporaneamente e che la sua variante audio potrebbe non sintetizzare il parlato. Se la tua roadmap dava per scontato che la prossima mossa di Liquid fosse un modello di testo più grande, le prove finora non supportano questa ipotesi.

La frammentazione dei runtime è il problema pratico che questa famiglia creerà. L'abitudine di Liquid di distribuire simultaneamente su llama.cpp, MLX, vLLM, SGLang e ONNX è un bene per la portabilità e scomoda per chiunque voglia un unico endpoint: cinque motori significano cinque configurazioni di deployment, cinque insiemi di particolarità del preprocessing e cinque date diverse in cui arriva una correzione. Quanto a OrcaRouter, il catalogo di oltre 200 modelli oggi non include nemmeno un singolo checkpoint LFM, quindi non c'è modo di chiamare LFM3 tramite esso e nulla di ciò che è scritto qui va letto come una promessa che ci sarà. Quello che un livello di routing serve davvero a fare in questa situazione è fare da cerniera tra un modello non ancora collaudato e un percorso di produzione — inviare una porzione di traffico a qualcosa di nuovo mentre un modello noto resta dietro, con il failover che copre il divario, è il modo in cui valuti il successore di una famiglia non ancora rilasciata senza puntare una funzionalità rivolta al cliente su un mercato di previsioni al 40%.

Le questioni aperte da tenere d’occhio

Quattro cose risolveranno questa situazione più in fretta di qualsiasi ulteriore congettura. Se i quattro percorsi dei checkpoint diventeranno repository Hugging Face reali e scaricabili — in questo momento, una ricerca nell’organizzazione LiquidAI non restituisce nulla sotto LFM3, e i repository indicati nella PR non sono pubblicamente risolvibili. Se comparirà una PR di Transformers, il che segnalerebbe che l’architettura viene portata upstream correttamente anziché eseguita tramite codice remoto. Se verranno chiusi i controlli di validazione falliti, dato che 2 fallimenti omni su 22 fanno la differenza tra una demo e un merge. E se comparirà un membro della famiglia da >10B, che è la domanda a cui Labonne ha detto che LFM3 esiste per rispondere.

Fino ad allora, la frase più accurata che chiunque possa scrivere su LFM3 è quella con cui si apre questo articolo: esiste una pull request, non è ancora stata integrata, e nomina quattro piccoli modelli omni che Liquid AI non ha annunciato. È un segnale reale — solo precoce, e i segnali precoci meritano di essere letti esattamente per quello che sono.