LFM3-Omni-2B: il modello Omni che parla, e il leak che diceva che non poteva farlo

LFM3-Omni-2Brisponde con una voce. Quella singola frase è la notizia, perché una settimana fa le migliori prove pubbliche dicevano il contrario. Quando la famiglia LFM3 è emersa attraverso una pull request SGLang non integrata, i checkpoint erano configurati solo per l'output testuale, e il nostro stesso articolo su quella fuga di notizie concludeva, correttamente all'epoca, che "LFM3 parla" non era dimostrato. Il 27 ottobre 2026, Liquid AI ha pubblicato l'annuncio della famiglia e la model card, e la card lo chiarisce: uscita vocale a 24 kHz, generata tramite un componente chiamato LiquidCodec, trasmessa in streaming più velocemente del tempo reale. Un modello non dimostrato non dovrebbe essere un elemento portante fin dal primo giorno. failover automatico Il traffico può spostarsi in base a regole e un percorso in errore esegue il failover senza modifiche al codice.

Tutto il resto di questo rilascio è più discreto di quanto quella correzione suggerisca. L'annuncio di Liquid riguarda sei modelli, e a LFM3-Omni-2B sono dedicate tre frasi — nessuna tabella di benchmark, nessuna lunghezza del contesto, nessun numero di parametri. La documentazione quantitativa vive interamente nella scheda di Hugging Face, da cui provengono tutte le cifre seguenti. Vale la pena comprendere questa separazione prima di pianificare in base al modello: il posizionamento è marketing, i numeri stanno in un repository, e nulla in nessuno dei due è stato testato in modo indipendente.

Cosa è stato effettivamente rilasciato, e quando

Il repository è stato creato il 21 ottobre 2026 alle 16:58 UTC. La card è stata modificata l'ultima volta il 27 ottobre alle 17:25 UTC, lo stesso giorno del post della famiglia. Al momento della scrittura Hugging Face mostrava 83 download e 17 like — numeri modesti, adatti a un checkpoint pubblicato come uno dei rami di una famiglia di sei modelli anziché come un rilascio di punta. Le repository sorelle raccontano la stessa storia: LFM3-VL-2B è stata creata il 19 ottobre, LFM3-Audio-2B l'8 settembre, e tutte sono state toccate il 27 ottobre.

Quindi non si tratta di un modello non annunciato nel senso suggerito dal brief. Liquid ha annunciato la famiglia, ha indicato i nomi dei sei rami e ha descritto cosa fa il modello omni. Ciò che l'azienda non ha fatto è annunciare LFM3-Omni-2B con modalità proprie. Non c'è un post autonomo, nessun resoconto di valutazione il giorno del lancio, nessuna pagina dei prezzi perché non esiste un endpoint ospitato, e nessun benchmark indipendente. Il divario tra "annunciato" e "documentato" è il punto in cui si colloca questo articolo.

La scheda per intero

Il checkpoint è una singola build BF16 da 2.166.928.384 parametri, che la scheda arrotonda a 2,17B. Si basa sul tronco LFM3-1.7B-Base — la stessa spina dorsale tri-ibrida del resto della famiglia, con convoluzioni corte con gating che coprono la maggior parte dei livelli e l'attenzione globale riservata a una manciata di essi. Su quel tronco si trovano un encoder visivo, un encoder audio causale e il tokenizer LiquidCodec che riconverte i token generati in forma d'onda.

• Input — testo, immagini alla risoluzione nativa, video a 2 fotogrammi al secondo per un intervallo da 4 a 384 fotogrammi e audio a 16 kHz. L'input video può includere la propria colonna sonora.

• Output — testo, voce a 24 kHz o entrambi nella stessa risposta.

• Contesto — 32.768 token che coprono insieme input e output.

• Budget immagini — un massimo di 2.048 token visivi per immagine, qualunque sia la risoluzione.

• Lingue — la scheda elenca 16 lingue per il testo e 19 lingue o varianti locali per il parlato; i metadati del repository ne dichiarano 23. Le due cifre non coincidono nella pagina.

• Licenza — LFM Open License v1.0, i termini personalizzati utilizzati da Liquid sin da LFM2, non una licenza OSI.

• Ragionamento — nessuno. La scheda indica che la modalità di pensiero non è supportata e che enable_thinking=True non può essere utilizzato.

Due di quelle righe contano più delle altre. La prima è il contesto da 32K, che è piccolo per un modello multimodale del 2026 e una conseguenza diretta dell'obiettivo on-device: ogni token di contesto costa memoria su un telefono. La seconda è la licenza. LFM Open License v1.0 non è Apache-2.0, e i termini prevedono una soglia di ricavi che determina chi può usare i pesi commercialmente senza un accordo separato. Se stai valutando questo modello per un prodotto, leggi la licenza prima dei benchmark.

I numeri che nessuno ha annunciato

Il post di Liquid avanza un'unica affermazione comparativa su LFM3-Omni-2B: che supera modelli fino a 10,7 miliardi di parametri, «come Qwen2.5-Omni-7B», su Daily-Omni, WorldSense e AV-SpeakerBench. Nessun punteggio accompagna quella frase. La scheda li fornisce, e sono auto-misurati da Liquid AI — una valutazione del fornitore, non indipendente, e l'unica valutazione esistente.

Sui tre benchmark citati nel post, la scheda riporta Daily-Omni 70.09, WorldSense 47.10 e AV-SpeakerBench 46.79. OmniBench si attesta a 46.32 complessivo, con 48.25 sul sottoinsieme vocale. Per le domande e risposte visive parlate — il cavallo di battaglia del modello, in cui si fanno domande su un'immagine a voce — la scheda elenca RealWorldQA 64.68, MMStar 51.79, POPE 83.78, ERQA 39.43 ed EmbSpatial 67.59. Le righe audio sono ASR inglese a 6.36 di tasso di errore di parola, ASR multilingue a 6.72, sintesi vocale inglese a 3.80 UTMOSv2, VoiceBench 64.73 e comprensione audio MMAR 51.40. I suoi punteggi di visione solo testo, per completezza, sono DocVQA 92.47, OCRBench 806 su 1.000, validazione MMMU 42.44 e MathVista mini 62.50.

Considerati nel loro insieme, i punteggi descrivono un modello competente in tutto e eccellente in nulla. Un 46.79 su AV-SpeakerBench e un 47.10 su WorldSense non sono numeri che fanno vincere una classifica; sono numeri che suggeriscono che un modello da 2.2B può reggere il confronto nel ragionamento audio-visivo senza sgretolarsi. Il punteggio DocVQA è l'eccezione nella direzione opposta e la singola cifra più interessante della tabella — 92.47 da un modello omni da 2.2B è alto, ed è l'unica riga in cui questo checkpoint supera chiaramente il modello vision dedicato di Liquid, che riporta 91.1.

Cosa ha azzeccato il leak, e l'unica cosa che ha sbagliato

La pull request di SGLang che ha portato questa famiglia all'attenzione pubblica era accurata su quasi tutti gli aspetti strutturali. Indicava correttamente i quattro checkpoint, descriveva correttamente il backbone condiviso ed era giusto nel dire che la finestra scorrevole di 256 token è un'impostazione dell'attenzione anziché il limite di contesto. Era anche giusto essere cauti: la pull request non era stata mergiata, tre controlli CI stavano fallendo e due dei ventidue controlli di validazione omni fallivano ancora nei confronti ROUGE rispetto ai checkpoint di sviluppo.

Dove ci ha tratto in inganno — e dove l’abbiamo ripetuto — è stata la modalità di output. Il percorso di runtime che collegava restituiva testo. Non c’era alcun ramo di output audio in quel codice, e l’inferenza ragionevole era che la famiglia potesse aver abbandonato la sintesi vocale, oppure che il primo taglio del runtime fosse solo testo. Il modello distribuito fa entrambe le cose. La lezione non è che la fuga di notizie sia stata negligente; è che un’integrazione di serving descrive il percorso che qualcuno ha implementato, non la capacità del checkpoint che vi sta dietro. Una PR è una prova riguardo a un runtime, e noi l’abbiamo trattata come una prova riguardo a un modello.

Cosa non è ancora confermato

Tre cose, e sono proprio le tre che deciderebbero un deployment in produzione.

Innanzitutto, non esiste alcuna valutazione indipendente di alcun tipo. Ogni numero sopra riportato è stato prodotto dall'azienda che ha creato il modello, sul proprio harness, senza alcuna metodologia pubblicata. Non esiste alcuna voce in Artificial Analysis, nessun risultato LMArena, nessuna riproduzione da parte di terzi. Considera la tabella dei benchmark come una specifica delle intenzioni, non come una misurazione.

In secondo luogo, l’erogazione vocale non è documentata al di fuori del percorso proprietario del fornitore. La scheda afferma che il supporto a SGLang copre l’output testuale e non documenta come viene erogato il ramo vocale. Se il tuo piano è «un modello, risposte parlate, sul nostro hardware», la scheda non fornisce alcun riferimento per la seconda metà di quella frase. Al momento della stesura, il repository non elenca alcun provider di inferenza.

Terzo, i dati sulle lingue non concordano tra loro. Sedici lingue per il testo, diciannove varianti vocali, ventitré nei metadati. Probabilmente sono tre definizioni diverse della stessa cosa, ma nessuno ha pubblicato quale sia quella corretta.

Perché un modello omni da 2,2 miliardi è una scommessa diversa

Il modo consueto di costruire un assistente vocale nel 2026 è una pipeline: un modello ASR converte il parlato in testo, un modello linguistico pensa, un modello di visione gestisce la fotocamera e un modello TTS pronuncia la risposta. Ogni fase è un checkpoint separato, un budget di latenza separato e una modalità di errore separata. La proposta di LFM3-Omni-2B è che tutti e quattro si riducano a un unico file BF16 da 4,3 GB che sta su un telefono e non lo lascia mai.

Questo è un vero argomento architetturale, ed è il motivo per cui i punteggi dei benchmark contano meno della forma della cosa. Una pipeline di quattro piccoli modelli specialistici di solito batte un singolo generalista su ogni singolo compito. Ciò che non può fare è condividere le rappresentazioni: il modello omni coglie il tono di una domanda su un'immagine, e la risposta è condizionata da entrambi contemporaneamente. Se questo produca risposte migliori è esattamente ciò che nessuna valutazione indipendente ha testato.

Il modo pratico di usare un checkpoint come questo finché non è comprovato è tenerlo fuori dal tuo percorso critico. Il routing DSL di OrcaRouter è stato costruito per quel modello — un percorso specialistico e un percorso sperimentale dietro un unico endpoint, così un nuovo modello può ricevere traffico in proporzione alla sua affidabilità anziché tutto in una volta, con failover automatico quando genera errori. LFM3-Omni-2B non è oggi nel nostro catalogo, quindi nulla di quanto scritto qui afferma che tu possa chiamarlo tramite noi. Quando un modello come questo arriverà davvero, questa è la forma di deployment che gli si addice: disponibile, misurato e non indispensabile finché non se lo guadagna.

Cosa guardare

Il prossimo segnale non è un'altra tabella di benchmark. È se qualcuno al di fuori di Liquid ne pubblica una. Un modello omni da 2,2B che mantiene davvero 70,09 su Daily-Omni è un risultato notevole per il lavoro on-device, e una riproduzione indipendente — anche solo parziale — varrebbe più del foglio completo del fornitore. Il secondo segnale è il merge in SGLang: quando il percorso vocale è documentato in uno stack di serving, il modello smette di essere un repository e inizia a essere infrastruttura.

Fino ad allora, il riassunto onesto è limitato. LFM3-Omni-2B esiste, è più piccolo di quasi tutto ciò con cui compete, accetta in ingresso quattro modalità e ne restituisce due, ed è il primo modello Liquid in grado di rispondere ad alta voce. Il leak diceva che non poteva. La scheda dice che può, e per ora la scheda è l'unica testimone.