d1-2B: Liquid AI ha rilasciato un modello decisionale da 1,9 miliardi senza un post per annunciarlo

Il repository Hugging Face di LiquidAI/d1-2B è stato creato alle 19:30 UTC del 24 ottobre 2026. Il suo gemello, d1-Omni-2B, è apparso ventiquattro secondi dopo. Entro la fine di quella serata entrambi i repository erano completi — 3,84 GB di safetensors BF16, una quarantina di file di codice Transformers personalizzato, una tabella di calibrazione, un'API per domande tipizzate — e nulla di ciò che Liquid AI ha pubblicato diceva che uno dei due modelli esistesse. La prima frase del fornitore che nomina d1-2B è arrivata il 27 ottobre, all'interno del lancio della famiglia LFM3 — lo stesso post pubblicato su liquid.ai e sul blog di Hugging Face — come una clausola in un paragrafo su due modelli decisionali. Da allora non c'è stato alcun post dedicato. Quindi questa non è una storia di lancio, e trattarla come tale inventerebbe un momento di marketing che non è mai avvenuto. È una storia su un artefatto di modello completo con un annuncio incompleto, e sulle due cose che un lettore può ancora fare con esso: leggere il repository e tenere a distanza i numeri del fornitore finché qualcuno fuori dal laboratorio non li esegue.

I cinque giorni tra i pesi e la frase

La famiglia d1 è stata rilasciata due volte, e nessuna delle due pubblicazioni somigliava a questa. Il 7 ottobre Liquid AI ha pubblicato «Open d1: modelli decisionali edge per testo, visione e audio», che introduceva d1-3B con 3,12 miliardi di parametri e d1-omni-600M con 587 milioni, con un'affermazione di rilievo, una tabella di benchmark, dati sulla latenza e un post sul blog rimasto online da allora. Quel post non contiene alcun modello 2B.

La linea 2B si è mossa su un calendario diverso. Il checkpoint base LFM3-Omni-2B è apparso il 21 ottobre. Il 24 ottobre, alle 19:30 e alle 19:30:24 UTC, Liquid AI ha creato i repository d1-2B e d1-Omni-2B. Poi, il 27 ottobre, il post di lancio di LFM3 ha definito la coppia come «modelli decisionali specializzati a partire dai modelli vision e omni»: una descrizione, non un annuncio. Lo stesso giorno sono comparsi quattro repository derivate per d1-2B: build MLX a fp16, 8-bit e 4-bit, più un export ONNX. Anche su queste nessuno ha scritto un post.

Questo conta per una ragione pratica. Un annuncio è il momento in cui un fornitore si impegna sul posizionamento: a cosa serve il modello, quanto costa, quale runtime ha come target, cosa non fa. La scheda fa parte di questo lavoro, e lo fa in modo insolitamente efficace. Ma le lacune lasciate dal post mancante sono reali e specifiche, e sono elencate in fondo a questo articolo anziché essere mascherate.

Cosa ti dirà davvero il repository

Tolta la cornice, il checkpoint è un piccolo classificatore multimodale dalle specifiche molto dettagliate che rifiuta di generare testo. Ogni chiamata restituisce risposte tipizzate con probabilità associate e output_tokens: 0. La scheda lo dice apertamente: d1-2B "non è un modello chat".

• Parametri — 1,92B, distribuito come un singolo file safetensors BF16 da 3,84GB.

• Base — LFM3-VL-2B, sulla backbone LFM3: 24 livelli, di cui 13 sono convoluzioni brevi con gating, 5 sono attenzione a finestra scorrevole e 6 sono attenzione globale.

• Contesto — 128K token e un vocabolario di 128.000 token, quattro volte la finestra di 32.768 di d1-3B.

• Input — uno stato che può essere testo o qualsiasi valore JSON, immagini o un video, e un numero qualsiasi di domande con nome, tutto in un'unica lista media. Il video è la capacità che d1-3B non elenca.

• Output — sì/no, una scelta tra opzioni denominate, un punteggio ordinato, un valore o una data letti da un documento con il relativo span, un numero con un intervallo p10–p90, un bounding box, o ogni istanza di un oggetto con un conteggio. Ognuno è associato a una probabilità.

• Lingue — sedici: inglese, arabo, cinese, francese, tedesco, italiano, giapponese, coreano, portoghese, spagnolo, vietnamita, thailandese, indonesiano, hindi, russo, polacco.

• Licenza — LFM Open License v1.0. L'uso commerciale è consentito al di sotto di 10.000.000 $ di ricavi annuali; il testo della licenza definisce tale cifra come soglia, e i diritti per l'uso commerciale al di sopra di essa sono subordinati al non superarla.

• Velocità — 5,7 ms per una singola decisione su una H100 PCIe e 3,8 ms su una AMD MI325X, con rispettivamente 1.132 e 1.699 decisioni al secondo quando 64 stati vengono raggruppati in un'unica chiamata. Su un Apple M5 Pro il valore per una singola domanda è 18,6 ms.

La tesi su cui vale la pena discutere: supera il modello che ha sostituito

La scheda di Liquid AI formula un'affermazione comparativa senza cautele: d1-2B "è in testa ai modelli d1 aperti in media e sulla nostra raccolta di oltre cento benchmark decisionali, davanti a d1-3B con meno di due terzi delle sue dimensioni". Si tratta di un'affermazione forte da parte di un modello da 1,92B su uno da 3,12B, ed è verificabile, perché la scheda riporta tutti e quattro i modelli d1 aperti in un'unica tabella, valutati sugli stessi elementi con lo stesso scorer.

Il numero principale è 51,1 contro 49,0 sulla suite pubblica Decision Index, versione 0.3 — un vantaggio di 2,1 punti. Prima che qualcuno lo interpreti come una vittoria netta, accanto vanno due avvertenze. Innanzitutto, la scheda di d1-3B riporta 48,57 su Decision Index 0.2.1, e la differenza tra 48,57 e 49,0 è la versione dell'indice, non un miglioramento del modello; la scheda di d1-2B afferma che tutti e quattro i modelli sono stati rivalutati sugli stessi elementi e che, di conseguenza, alcuni numeri di d1-3B differiscono dalla sua stessa scheda. In secondo luogo, la suite pubblica è solo una frazione di ciò che determina la classifica pubblica: il valutatore indipendente che l'ha ricostruita descrive 37 benchmark pubblici ponderati al 20% del punteggio, con il resto proveniente da test privati eseguiti solo dai manutentori.

Ciò che rende credibile il 49,0 come numero — anche se d1-2B di per sé non ha alcuna verifica esterna — è che qualcuno ha già riprodotto il 3B su questa esatta versione. Efraín Garay ha eseguito d1-3B su un campione stratificato di 6.000 richieste di Decision Index 0.3 a metà ottobre e ha ottenuto 49,11, contro il 49,04 di Liquid sulle stesse righe e il 48,99 sulla suite completa. Si tratta di una riproduzione entro un decimo di punto. Non convalida il 51,1 di d1-2B, che nessuna terza parte ha eseguito, ma convalida il metodo di scoring alla base della tabella in cui figura 51,1.

Dove il modello più piccolo non è in vantaggio

"È in testa sulla maggior parte dei singoli benchmark" sta facendo un lavoro silenzioso in quella frase. Nella tabella della stessa esecuzione, d1-3B vince ancora tre delle venti e passa righe che contano per una decisione di deployment:

• Fast Decisions — 59,3 per il 3B contro 58,8, l'unico benchmark decisionale orientato alla velocità in cui il modello più grande passa in vantaggio.

• Decisioni tipizzate — 65,0 contro 61,3, un divario di 3,7 punti e l'argomento singolo più chiaro a favore del modello più vecchio quando l'output deve essere un valore tipizzato anziché un'etichetta.

• AI2D — 79,9 contro 76,7, il benchmark di lettura dei diagrammi, dove una torre visiva più grande continua a garantire accuratezza.

Altrove l’ordine si inverte, a volte in modo netto. VisualWebBench è 96,2 per d1-2B contro 71,4 per d1-3B. ImajevBench v2.0-lite è 75,5 contro 64,0. MMMU-Pro è 26,4 contro 18,5 — entrambi sufficientemente bassi che non ci si dovrebbe fidare di nessuno dei due modelli per ragionamenti multimodali difficili, cosa che vale la pena dire chiaramente invece di presentare il divario di 7,9 punti come una vittoria. Le medie della visione sono 70,2 e 65,4.

Tre assenze che la card non può colmare

L'annuncio mancante si manifesta sotto forma di artefatti mancanti. Nessuno di questi è un difetto del modello; ognuno è un motivo per cui oggi il modello è più difficile da adottare di quanto lasci intendere la sua linea di benchmark.

• Nessun GGUF. d1-3B e d1-omni-600M hanno entrambi ottenuto repository GGUF il 6 ottobre, un giorno dopo la pubblicazione dei loro pesi, e d1-3B ha fatto seguito con una build weight-activation a 8 bit e quattro varianti MLX. d1-2B ha build MLX e ONNX al 27 ottobre, ma nessun GGUF — quindi non esiste un percorso llama.cpp pubblicato per la testa decisionale, anche se il modello base LFM3-VL-2B ha ottenuto il proprio GGUF il 19 ottobre. Se il tuo stack edge è llama.cpp, questa è tutta la storia.

• Nessun prezzo e nessun endpoint. La scheda non elenca alcuna API ospitata, alcun prezzo per token e alcun provider di inferenza. Non è insolito per un rilascio open-weights, ma significa che l'unico modo per usare d1-2B è eseguirlo, e la sezione sul deployment della scheda si ferma a uno snippet di Transformers.

• Nessun benchmark indipendente. Al 28 ottobre il repository mostra 44 download e 13 like. La valutazione indipendente del modello decisionale esistente copre d1-3B e d1-omni-600M, non questo modello. Ogni dato di prestazione riportato sopra è proprio di Liquid AI.

C'è anche un limite che la scheda dichiara su se stessa: le risposte «diventano meno affidabili oltre circa 64K token di stato», metà della finestra pubblicizzata di 128K, e le stime sono affidabili su conteggi e punteggi ma meno su quantità libere. Un modello la cui scheda ti dice dove degrada è più utile di uno che non lo fa, ma il dato di testa dei 128K va letto come una cifra di capacità, non come un intervallo operativo.

Come appare davvero un primo deployment

Il percorso pratico è Transformers 5.19 o versioni successive con trust_remote_code=True, bf16 su GPU e la system_one oppure system_one_batch chiamata. Non ci sono parametri di campionamento perché non c'è campionamento. L'unico parametro di regolazione che conta è set_size, che per impostazione predefinita è la dimensione addestrata di 16; aumentarlo fa guadagnare velocità e costa precisione del testo.

La raccomandazione della scheda stessa è il passaggio che la maggior parte dei team salta: calibrare la soglia decisionale sui dati del proprio caso d’uso. Una probabilità di 0,62 non significa nulla di per sé. Se instradi ticket di assistenza o segnali documenti, la soglia che separa «escalation» da «gestione automatica» deve essere calibrata sul tuo campione etichettato, perché la calibrazione del fornitore è stata adattata ai loro dati.

La forma a cui questo si adatta è un passaggio di una pipeline, non un assistente: triage, moderazione, classificazione delle intenzioni, estrazione da moduli, reranking, ispezione visiva. Sono esattamente i punti in cui una pipeline chiama già diversi modelli, e in cui i passaggi generativi attorno alla decisione provengono di solito da un'API ospitata. OrcaRouter non serve oggi nessun modello Liquid AI — incluso questo — quindi eseguire d1-2B significa eseguirlo da soli. Ciò per cui un router è utile è il resto della catena: una chiave compatibile con OpenAI per oltre 200 modelli ospitati, un DSL di routing che compone i passaggi in un'unica chiamata e un failover automatico quando un provider smette di rispondere, così il nodo decisionale sulla tua GPU non è ostaggio del nodo generativo accanto ad esso.

Cosa cambierebbe questa storia?

Quattro cose, in ordine decrescente di quanto conterebbero. Un GGUF metterebbe d1-2B sullo stesso piano di runtime dei suoi modelli fratelli e renderebbe concreta la proposta edge. Un post dedicato spiegherebbe agli acquirenti a cosa serve il modello secondo Liquid AI, al di là dell'elenco di passaggi della pipeline riportato nella scheda. Un'esecuzione indipendente — idealmente lo stesso campione da 6.000 righe che ha riprodotto d1-3B — trasformerebbe il 51,1 da un'affermazione del fornitore in una misurazione. E un prezzo per l'hosting renderebbe finalmente possibile rispondere alla domanda se costruire o acquistare.

Fino ad allora, il riepilogo onesto è ristretto e utile: esiste un modello decisionale da 1,92B, il suo repository è abbastanza completo da poter essere valutato, il suo vantaggio nei benchmark rispetto al 3B è reale sulla tabella della stessa esecuzione del fornitore e non verificato altrove, e l'annuncio mancante lo ha lasciato senza il packaging — runtime, endpoint, prezzo — di cui la maggior parte dei team ha bisogno prima di inserire un modello in una pipeline. Se usi già Transformers e vuoi un classificatore con finestra da 128K e input video, vale la pena dedicarci un pomeriggio. Se ti serve llama.cpp o un endpoint gestito, aspetta.