d1-2B vs Liquid AI d1-3B: il modello più piccolo vince la classifica e perde il deployment

Quattro domande decidono questo confronto, e nessuna di esse è "quale modello è migliore". Lo stato include il video? Supera i 32K token? Devi eseguirlo sotto llama.cpp? Puoi permetterti di essere la prima persona a testarlo? d1-2B è il modello decisionale da 1,92B di Liquid AI, basato su LFM3-VL-2B e con un punteggio di 51,1 nella tabella Decision Index del fornitore. Liquid AI d1-3B è il modello da 3,12B rilasciato il 7 ottobre, basato su LFM2.5-VL-3B e con un punteggio di 49,0 nella stessa tabella. Il modello più nuovo e più piccolo è in vantaggio in media. Perde comunque tre delle righe su cui un deployment fa effettivamente affidamento, ed è quello dei due che non ha un percorso llama.cpp né un risultato di test indipendente. Questa pagina è organizzata attorno a quelle quattro domande anziché attorno alla classifica, perché la classifica non risponde a nessuna di esse.

La risposta breve, per carico di lavoro

• Triage solo testo ad alto volume — d1-2B, in virtù di 1.132 decisioni al secondo per 64 stati in batch e 3,84 GB di pesi. Il vantaggio del 3B su Typed Decisions è irrilevante quando l'output è un'etichetta.

• Lettura di diagrammi e grafici — Liquid AI d1-3B. Vince su AI2D 79,9 contro 76,7, ed è il modello con un'esecuzione indipendente alle spalle.

• Documenti lunghi, moduli lunghi, lunghe trascrizioni di chiamate — d1-2B. La sua finestra è di 128K token rispetto a 32.768, e la scheda è onesta nel dire che l'affidabilità cala oltre circa 64K, il che lascia comunque il doppio della capacità totale del 3B.

• Dispositivi edge che eseguono llama.cpp — Liquid AI d1-3B, per impostazione predefinita anziché per merito. Ha un repository GGUF e una build quantizzata weight-activation; d1-2B non ha né il primo né la seconda.

• Qualsiasi cosa in cui una decisione sbagliata è costosa e non testata — nessuno dei due, finché non li hai provati entrambi sui tuoi dati. Solo uno di essi è stato addirittura testato da una terza parte.

Stessa famiglia, a una generazione di distanza

I due modelli non sono fratelli nel senso che i nomi suggerirebbero. Liquid AI d1-3B discende da LFM2.5-VL-3B, che deriva da LFM2.5-2.6B-Base, e integra un encoder visivo SigLIP2 NaFlex da 400M. d1-2B discende da LFM3-VL-2B, la famiglia successiva, su una backbone di 24 livelli suddivisi tra 13 convoluzioni corte con gating, 5 livelli di attenzione a finestra scorrevole e 6 livelli di attenzione globale. È da quel divario generazionale che nasce l'inversione dei benchmark: l'architettura più recente fa di più per parametro, quindi il checkpoint più piccolo può superare quello più grande sulla maggior parte delle righe.

• Parametri — 1,92B per d1-2B rispetto a 3,12B per Liquid AI d1-3B.

• Scarica — 3,84 GB rispetto a 6,25 GB di safetensors BF16, entrambi in un unico file.

• Contesto — 128K token vs 32.768.

• Vocabolario — 128.000 token rispetto al vocabolario di LFM2.5.

• Input — testo o JSON, immagini o video, più domande con nome, per d1-2B; testo o JSON più immagini per il 3B. Il video è la differenza di capacità più netta tra i due.

• Lingue — sedici ciascuna, lo stesso insieme.

• Licenza — LFM Open License v1.0 per entrambi, con uso commerciale subordinato alla permanenza sotto i $10,000,000 di fatturato annuo. Non c'è alcun motivo di licenza per preferire l'una o l'altra.

• Rilascio — i pesi di d1-3B sono stati pubblicati il 5 ottobre e annunciati il 7 ottobre. Il repository di d1-2B è stato creato il 24 ottobre e non ha mai avuto un post proprio; l'unica frase del fornitore che lo nomina si trova nel lancio di LFM3 del 27 ottobre.

Un dettaglio nella documentazione va letto come un segnale più che come un fatto: la pagina della documentazione sui modelli decisionali di Liquid AI ora elenca d1-2B, d1-omni-2B, d1-omni-600M, d1.1 e d1-ultra. Non elenca più d1-3B. Il 3B non è stato ritirato — il suo repo, le build GGUF e MLX sono tutte attive — ma l'indice del fornitore stesso ha spostato lo slot dei pesi aperti sul 2B.

Il tabellone, letto riga per riga

Tutti i valori riportati di seguito provengono dalla tabella di benchmark sulla model card di d1-2B, che valuta quattro modelli d1 aperti sugli stessi elementi con lo stesso scorer. Questo è importante perché la model card di Liquid AI d1-3B riporta 48,57 su Decision Index 0.2.1, mentre questa tabella riporta 49,0 sulla versione 0.3; il divario è dovuto all'edizione dell'indice, non a un cambiamento del modello, e la scheda lo dice in una nota. Confrontare direttamente le due schede — 48,57 contro 51,1 — equivarrebbe a sottrarre tra due test diversi. Il confronto all'interno di questa tabella è legittimo, ed è ciò che fa il resto di questa sezione.

• Decision Index public suite v0.3 — 51,1 vs 49,0.

• DecisionBench (Hanno Labs) v1 — 77,1 vs 73,1.

• Decision Bench (decisionbench.ai) v4 — 85,2 contro 83,6.

• JevBench v1.4.1 — 77,9 contro 76,2.

• ImajevBench v2.0-lite — 75.5 vs 64.0, il divario più ampio sul lato decisionale.

• WorkflowEvals — 81,6 vs 74,4.

• Il board interno di Liquid AI — 63,2 contro 58,8.

• Media Vision — 70,2 vs 65,4 su diciotto benchmark.

Ogni suite decisionale nominata in quella tabella va al 2B, ed è ciò che intende il post di lancio di LFM3 quando definisce d1-2B un sostituto di d1-3B «con un terzo di parametri in meno» e con punteggi più alti «su tutte e quattro le suite decisionali». L'affermazione è accurata così com'è scritta — e più ristretta di «batte il 3B», ed è per questo che esiste il paragrafo successivo. Poi ci sono le tre righe che vanno nella direzione opposta. Decisioni Rapide è 58,8 per d1-2B contro 59,3 per il 3B. Decisioni Tipizzate è 61,3 contro 65,0. AI2D è 76,7 contro 79,9. Nessuno di questi divari è ampio, e due dei tre stanno entro un punto, ma sono le righe in cui gli 1,2B parametri in più comprano ancora qualcosa di misurabile: decisioni orientate alla velocità, estrazione tipizzata e lettura di diagrammi. Se i job della tua pipeline consistono nell'estrazione tipizzata da moduli, il 3B non è l'opzione obsoleta che la pagina della documentazione lascia intendere.

Latenza: i due valori principali non sono comparabili

Liquid AI riporta 5,7 ms per decisione per d1-2B e 8 ms per Liquid AI d1-3B, e non si tratta della stessa misurazione. Il valore del 2B si riferisce a una H100 PCIe; quello del 3B a una RTX 4090. Un divario di 2,3 ms tra due GPU diverse non ti dice nulla su quale modello sia più veloce sul tuo hardware, e ripeterlo come confronto sarebbe esattamente il genere di riciclaggio di numeri che questo blog mira a evitare.

C'è una macchina che entrambe le schede riportano. Su un Apple M5 Pro, d1-2B impiega 18,6 ms per domanda e il 3B ne impiega 30 ms — una riduzione del 38% sullo stesso silicio. Questo è il confronto onesto sulla velocità, e indica la stessa direzione suggerita dalla differenza di dimensioni. Sul batching, d1-2B gestisce 1.132 decisioni al secondo su una H100 PCIe e 1.699 al secondo su una MI325X con 64 stati in una singola chiamata; la scheda del 3B riporta 475 al secondo su una RTX 4090 e 1.106 al secondo su una MI325X. La riga MI325X è quella condivisa da entrambe le schede, e lì il 2B è avanti di circa il 54%.

L'unico test indipendente esistente ha eseguito il 3B

A metà ottobre, Efraín Garay ha eseguito otto modelli decisionali rispetto a Decision Index 0.3 e tre attività con dati reali, e ha pubblicato i risultati insieme al codice. Due risultati sono rilevanti per questo confronto.

Il primo è rassicurante per il tabellone. Ha ricostruito la suite pubblica dal suo kit, ha verificato che i file scaricati corrispondessero a quelli ufficiali, ha campionato 6.000 richieste e ha assegnato a Liquid AI d1-3B un punteggio di 49,11 — rispetto al 49,04 di Liquid stesso sulle stesse righe e al 48,99 sulla suite completa. È la prova più forte disponibile che i numeri v0.3 nella tabella sopra siano calcolati correttamente. È una prova riguardante il 3B, non il d1-2B, che non ha testato.

Il secondo è un avvertimento su ciò che misura un indice. Su un dataset sintetico di frodi con carta di 10.000 pagamenti, Liquid AI d1-3B ha ottenuto un AUC di 0,314 — inferiore alla casualità, classificando le anomalie come meno sospette dei pagamenti normali, perché raffiche di pagamenti consecutivi si collocavano a una probabilità mediana di 0,41 rispetto a 0,56 per un pagamento normale. Il modello era secondo nell'indice pubblico e ultimo in quel compito. La lezione si trasferisce direttamente: il 51,1 di d1-2B è un punteggio su una suite decisionale generale, e nessuno ha dimostrato che predica la performance sulla tua decisione specifica. Il fornitore lo afferma nella propria scheda, nell'istruzione di calibrare le soglie sui tuoi dati.

Cosa puoi effettivamente eseguire oggi

È qui che il confronto smette di essere equilibrato. Liquid AI d1-3B dispone di un repository GGUF dal 6 ottobre, di una build weight-activation a 8 bit dal 7 ottobre e di quattro varianti MLX dal 12 ottobre. d1-2B ha ricevuto tre build MLX e un export ONNX il 27 ottobre, e nient'altro. Non esiste alcun GGUF per d1-2B, nessuna quantizzazione oltre a quella a 4 bit e 8 bit di MLX e, quindi, nessun percorso llama.cpp pubblicato per la testa decisionale — anche se il modello base, LFM3-VL-2B, ha il proprio GGUF dal 19 ottobre.

Per un deployment con Transformers la differenza scompare: entrambi si caricano con trust_remote_code=True ed espongono le stesse system_one e system_one_batch chiamate. Per un deployment edge non è così. Se il tuo stack è llama.cpp su un Jetson o su un telefono, il 3B è l'unico dei due che puoi eseguire senza scrivere un'integrazione runtime, e i suoi dati edge pubblicati — 16 ms su Jetson AGX Thor, 26 ms su AGX Orin 64GB, 50 ms su Orin Nano — sono quelli su cui puoi pianificare.

Nessuno dei due modelli è servito da OrcaRouter, quindi scegliere tra loro è comunque una decisione di self-hosting. È un livello più in là che un router si guadagna il suo posto: i modelli decisionali raramente girano da soli, e il passo generativo che agisce su un'etichetta di routing proviene di solito da un modello ospitato. Una chiave compatibile con OpenAI per oltre 200 modelli, un DSL di routing che consente di comporre quei passaggi in un'unica chiamata e il failover automatico impediscono a quella metà della pipeline di diventare un secondo progetto di integrazione, mentre il nodo decisionale resta sul tuo hardware.

Se stai migrando, tre cose cambiano

La superficie dell'API è abbastanza simile che un porting sembra banale e non lo è. Primo, il contratto di input: d1-3B accetta immagini; d1-2B accetta un media elenco che può includere video, e la sua scheda descrive i media come codificati una volta per tutte le domande di una chiamata. Il codice che passa una singola immagine verrà eseguito, ma non sfrutterà ciò per cui il modello è stato costruito.

Secondo, la soglia. Entrambi i modelli restituiscono probabilità ed entrambi necessitano di una soglia decisionale calibrata sui tuoi dati. Una soglia ottimizzata sulla calibrazione di d1-3B non è trasferibile — le tabelle di calibrazione sono incluse in ciascun repository, calibrate separatamente — quindi una migrazione che mantiene il vecchio cutoff produrrà un punto operativo diverso e, in un flusso di moderazione o antifrode, un profilo di errore diverso.

Terzo, il crollo dell'affidabilità. La finestra da 128K è il dato di richiamo; la scheda indica che le risposte diventano meno affidabili oltre circa 64K token di stato. Sul 3B il tetto è 32.768, quindi una migrazione a d1-2B sarà di solito un guadagno netto di capacità — ma una pipeline che inizia a inviare stati da 100K token perché ora può farlo sta testando la parte dell'intervallo che il fornitore ha segnalato come più debole.

Il verdetto è meno simmetrico del tabellone. Per una nuova build in Transformers, su testo o immagini o video, con stati che possono durare a lungo, d1-2B è il default migliore e quello più economico da eseguire. Per un deployment edge sotto llama.cpp, per l'estrazione tipizzata o per la visione ricca di diagrammi, Liquid AI d1-3B è ancora il modello da scegliere — ed è l'unico dei due con qualche evidenza esterna a supporto. L'unica cosa da non fare è scegliere sulla sola linea 51,1 contro 49,0. Due punti sull'indice di un fornitore, tra due modelli che nessuno ha eseguito sul tuo task, non sono una decisione; sono uno spareggio.