d1-Omni-2B: cosa include — e cosa lascia fuori — il modello decisionale 2B più discreto di Liquid AI

Il repository Hugging Face per LiquidAI/d1-Omni-2B è stato creato alle 19:30 UTC del 24 ottobre 2026. Il primo post sul blog di Liquid AI a menzionare il modello per nome è stato pubblicato il 27 ottobre. Per quei tre giorni il repository è stato pubblico e completo — una scheda tecnica completa, 4,33 GB di safetensors BF16, codice Transformers funzionante — e nulla di ciò che il fornitore ha pubblicato ne indicava l'esistenza. Quando la menzione è finalmente arrivata, erano due paragrafi e una tabella di quattro righe all'interno del lancio di una famiglia di sei modelli, non un lancio a sé stante. Questa è la forma di questo rilascio, ed è il quadro onesto per tutto ciò che segue: i pesi sono ispezionabili, le affermazioni sono del fornitore, e le parti che un acquirente normalmente otterrebbe da un annuncio — un prezzo, un endpoint ospitato, un benchmark indipendente — non ci sono ancora.

L'intervallo di cinque giorni tra i pesi e le parole

La storia dei modelli decisionali di Liquid AI è stata raccontata due volte, e d1-Omni-2B non compare in nessuna delle due versioni. Il 7 ottobre l'azienda ha pubblicato "Open d1: modelli decisionali edge per testo, visione e audio", che introduceva esattamente due checkpoint aperti: d1-3B, un modello visione e testo da 3,12B, e d1-omni-600M, un modello da 587M che accettava testo con immagini o testo con fino a 30 secondi di audio. Quel post è ancora online e continua a non contenere alcun modello 2B.

La linea 2B è arrivata con un calendario diverso. Il 21 ottobre il checkpoint di base LFM3-Omni-2B è apparso su Hugging Face. Il 24 ottobre, a ventiquattro secondi di distanza, Liquid AI ha creato i repository per d1-2B e d1-Omni-2B. Il post di lancio di LFM3 del 27 ottobre ha poi nominato la famiglia: sei modelli intorno ai 2B parametri, quattro che coprono testo, visione, audio e omni e, usando le parole stesse del post, "gli ultimi due sono modelli decisionali specializzati a partire dai modelli visione e omni". Quella frase è l'annuncio. Non c'è stato alcun post separato su d1-Omni-2B, nessuna pagina dei prezzi, nessuna citazione di un partner del lancio e nessun aggiornamento all'articolo del 7 ottobre.

Quindi il modello non è privo di documentazione — il repository è uno dei piccoli checkpoint meglio documentati pubblicati da Liquid AI, e la pagina di documentazione del fornitore dedicata ai modelli decisionali lo elenca accanto a d1-2B e d1-omni-600M. È stato annunciato poco. Questa distinzione è importante perché ti dice quali dichiarazioni sono passate attraverso una revisione di lancio e quali no.

Leggere la scheda come un foglio di specifiche

Tralasciando la cornice, il checkpoint è semplice. d1-Omni-2B è un modello decisionale post-addestrato basato su LFM3-Omni-2B, e non è un modello di chat: non scrive testo e non produce parlato, e ogni chiamata restituisce output_tokens: 0.

• Parametri — 2,17B, distribuito come un singolo file safetensors BF16 da 4,33 GB.

• Architettura — la backbone LFM3: 24 layer, di cui 13 sono convoluzioni corte con gating, 5 sono attenzione a finestra scorrevole con una finestra di 256 token e 6 sono attenzione globale. Il post della famiglia descrive questa miscela tri-ibrida come il risultato di una ricerca architetturale hardware-in-the-loop condotta su 14 combinazioni di dispositivi e backend.

• Contesto e vocabolario — 128K token e un vocabolario di 128.000 token condiviso con il resto di LFM3.

• Input — uno stato che può essere testo o qualsiasi valore JSON, oltre a immagini, fotogrammi video e clip audio, oltre a un numero qualsiasi di domande con nome, scritte o parlate. L'API della scheda accetta tutti questi elementi in un unico elenco media, il che rappresenta una differenza significativa rispetto al checkpoint da 587M: d1-omni-600M è documentato come testo con immagini o testo con audio, non entrambi contemporaneamente.

• Output — risposte tipizzate con probabilità. Sì/no, una scelta tra opzioni denominate, un punteggio ordinato, un valore letto da un documento con il relativo span, un numero con un intervallo p10–p90, un bounding box, oppure ogni istanza di un oggetto con un conteggio.

• Lingue — sedici. Il parlato copre lo stesso insieme tranne hindi, thai, vietnamita e indonesiano, cosa che vale la pena segnalare perché il lato testo li elenca.

• Licenza — LFM Open License v1.0. L'uso commerciale è consentito al di sotto di 10.000.000 $ di ricavi annui; al di sopra, il testo della licenza afferma che l'uso commerciale "non è concesso in licenza ai sensi del presente Accordo".

L'audio è l'affermazione che vale la pena verificare

Il motivo per scegliere questo checkpoint rispetto a d1-2B è l'audio. Liquid AI lo posiziona per «routing di chiamate e messaggi vocali ed eventi sonori», e la scheda del modello contiene l'unico elemento di prova con cui un post di lancio sarebbe normalmente partito: un confronto tra parlato e scritto sugli stessi elementi.

• Instradamento e triage aziendale (DecisionBench, Hanno Labs v1) — 83,4 scritto, 78,2 parlato.

• Casi di servizio clienti (Decisioni digitate) — 50,5 scritti, 48,0 parlati.

• JevBench v1.4.1, le righe che una voce può pronunciare — 87,6 scritto, 89,0 parlato, il che significa che la prova parlata ha ottenuto un punteggio leggermente più alto, che è rumore più che un miglioramento.

• Eventi sonori (ESC-50) — 84,5, senza equivalente scritto.

• Identificazione della lingua parlata (FLEURS, 43 lingue) — 92,5.

Quei numeri supportano il pitch. Il resto della sezione audio è la parte che ti dice dove non costruire, ed è insolitamente franca per una scheda del fornitore. Gli stati brevi parlati scendono da 42,0 nella versione scritta a 22,8 in quella ascoltata. I passaggi Belebele in otto lingue scendono da 83,6 a 41,8. La scheda afferma chiaramente che i lunghi passaggi parlati perdono gran parte della loro accuratezza, «soprattutto al di fuori delle lingue con scrittura latina», e indirizza chiunque non disponga di input audio a d1-2B, che secondo la scheda è più forte sul testo e sulle singole caselle, segnala più spesso i valori mancanti ed è meglio calibrato.

Lette insieme, quelle righe descrivono un modello bravo con enunciati brevi e instradabili nelle lingue principali e molto più debole in tutto ciò che richiede di mantenere a lungo uno stato vocale. Il triage dei call center è adatto. Una riunione registrata di quaranta minuti no.

Il tabellone è del fornitore, e l'indice ha cambiato versione.

Ogni valore prestazionale riportato per questo modello proviene da Liquid AI stessa. La scheda è esplicita sul metodo: tutti e quattro i modelli d1 sono stati valutati sugli stessi elementi con lo stesso criterio di punteggio, quindi alcune cifre differiscono leggermente dalle singole schede da cui provengono. Non afferma che una terza parte ne abbia riprodotto alcuna parte, e al momento della stesura non esiste alcuna valutazione indipendente di d1-Omni-2B.

• suite pubblica Decision Index, v0.3 — 49,0 per d1-Omni-2B, contro 51,1 per d1-2B, 49,0 per d1-3B e 18,3 per d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 76,4, rispetto a 77,1, 73,1 e 58,7 rispettivamente.

• decisionbench.ai v4 — 84,7, contro 85,2, 83,6 e 57,9.

• ImajevBench v2.0-lite — 72,3, contro 75,5, 64,0 e 21,7.

• La tabella del produttore di oltre cento benchmark — 61,8, contro 63,2, 58,8 e nessun punteggio per il 600M.

• Media Vision su 18 benchmark di immagini — 67,7, contro 70,2, 65,4 e 42,8.

Una trappola si nasconde nel mezzo di tutto questo. Il post del 7 ottobre riportava d1-omni-600M a 15,95 su Decision Index v0.2.1. La nuova scheda lo riporta a 18,3 su v0.3. Sono suite diverse e la differenza non è un guadagno di capacità; non sottrarre l'uno dall'altro. L'unico confronto equo è quello che la scheda ha effettivamente fatto, con tutti e quattro i modelli rivalutati sugli stessi elementi.

Lo schema che sopravvive alla nuova valutazione è che d1-Omni-2B si colloca appena sotto d1-2B su quasi tutti i fronti e sopra la generazione precedente con un ampio margine. Liquid AI lo presenta come capace di battere d1-3B sulla sua decision board e su 16 dei 18 benchmark di immagini con il 70% dei parametri, il che è vero per la tabella così come stampata ed è anche un confronto con un modello che la famiglia ha ormai sostituito.

Ciò a cui il repository non risponde

Cinque domande restano aperte, e nessuna di esse trova risposta leggendo i pesi.

• Accesso hosted e prezzo. Il post su LFM3 afferma che i modelli di base e post-addestrati sono disponibili su Hugging Face, il Playground e l'API Liquid AI. Tuttavia, la tabella della documentazione sui modelli decisionali elenca d1-Omni-2B come pesi aperti e riserva a d1.1 e d1-ultra le righe relative alle versioni solo hosted, e la pagina del modello su Hugging Face afferma che "questo modello non è distribuito da alcun provider di inferenza". Non è pubblicato alcun prezzo per chiamata per questo checkpoint in nessun luogo che questo articolo sia riuscito a trovare, quindi considera l'accesso hosted plausibile ma non confermato.

• Dati di addestramento. La scheda non fornisce alcun corpus, alcuna composizione né alcuna descrizione del dataset. Menziona test su clip e voci «che nessuna riga di addestramento contiene», il che implica che un set di addestramento esista e non dice nulla su cosa contenga.

• Quantizzazione. Il repository principale distribuisce BF16, e Liquid AI pubblica tre build gemelle: MLX fp16, MLX 8-bit e un export ONNX. Non esiste un GGUF del fornitore, anche se la libreria d1-omni di Ollama contiene un tag 2b a 4,4 GB con contesto 125K, e la dimensione è abbastanza vicina al checkpoint BF16 da non sembrare una quantizzazione aggressiva.

• Valutazione indipendente. Nessuna. Ogni numero sopra riportato è eseguito dal fornitore con il suo stesso sistema di valutazione sulla sua stessa scheda.

• Se sostituisce d1-omni-600M. La scheda consiglia d1-2B rispetto a questo modello quando non è presente audio, e consiglia questo modello rispetto a d1-2B quando lo è. Non dice nulla sul futuro del checkpoint 587M, e Liquid AI non lo ha dichiarato obsoleto.

Eseguirlo, e quanto costa in termini di hardware

Il percorso di inferenza è Transformers 5.19 o successivo con trust_remote_code, e la chiamata è model.system_one(state, questions, media). Non ci sono parametri di campionamento da impostare, perché non viene campionato nulla. La compilazione richiede circa un minuto alle prime chiamate; dopodiché la scheda riporta 5,8 ms per una domanda e 7,7 ms per tre su una H100 PCIe, 3,7 ms e 5,6 ms su un AMD MI325X, e 21,1 ms e 28,9 ms su un Apple M5 Pro. Uno stato da 5K token costa 52 ms sull'H100. Il batching è ciò che determina il throughput: 1.154 stati al secondo sull'H100 e 1.697 sul MI325X con 64 stati in una singola chiamata.

Per un modello di questa classe quei numeri sono l'argomento. Non compete con un modello di chat sulla qualità; compete con il fatto stesso di eseguire un modello di chat. Un forward pass da 5,8 ms che restituisce una probabilità calibrata è una voce diversa da una chiamata generativa che restituisce un paragrafo che poi devi analizzare.

Dove termina la decisione e inizia il resto della pipeline

Un modello come questo fa un solo salto. Trasforma un ticket, la registrazione di una chiamata o un fotogramma di una telecamera in un'etichetta e un livello di confidenza, e poi qualcosa deve agire su quell'etichetta: redigere la risposta, escalare il caso, chiamare l'API. Nessun modello Liquid AI è nel catalogo di OrcaRouter, quindi è sul secondo salto che si colloca realmente il nostro prodotto: i modelli generativi che consumano la decisione passano attraverso un'unica chiave compatibile con OpenAI che copre oltre 200 modelli, al prezzo di listino di ciascun provider, trasferito con markup dello 0%, con failover automatico quando una richiesta arriva su un provider che sta avendo un momento critico. Il modello decisionale è la parte economica, veloce e deterministica. Vale la pena collegare la parte costosa e non deterministica a qualcosa in grado di ritentare.

Cosa lo risolverebbe

Tre cose farebbero passare d1-Omni-2B da «promettente» a «consigliabile», e nessuna di esse richiede un altro post sul blog. La prima è un'esecuzione indipendente della suite audio su hardware che il fornitore non controlla: il divario tra 22,8 e 42,0 sugli stati brevi parlati è il numero più suscettibile di cambiare sotto il microfono di qualcun altro. La seconda è un prezzo pubblicato per l'accesso ospitato, senza il quale non si può completare il calcolo costruire-o-acquistare. La terza è un confronto diretto con d1-2B sugli stessi compiti che includono audio, perché la raccomandazione della scheda stessa — usare il 2B omni solo quando l'input include audio — è la frase più utile al suo interno, ed è anche quella che nessuno ha testato al di fuori di Liquid AI.