Liquid AI d1 vs Liquid AI d1-omni-600M: Il modello decisionale aperto che può ascoltarti

Cerca il nome Liquid AI d1 e ti imbatterai in un modello da tre miliardi di parametri che legge testo e immagini. L'altro checkpoint aperto della stessa famiglia è un quinto delle dimensioni, prende in considerazione fino a trenta secondi di parlato ed è l'unico dei due in grado di decidere qualcosa riguardo a una voce. Si chiama Liquid AI d1-omni-600M, e se hai trovato la famiglia tramite una libreria di runtime locale anziché tramite la documentazione ufficiale del fornitore, c'è una buona probabilità che tu non ne abbia mai visto il nome. Questa è la situazione che questo confronto vuole risolvere, perché i due modelli non sono risposte concorrenti alla stessa domanda. Sono risposte a due domande diverse, e solo una delle due implica l'ascolto.

Ogni dato riportato di seguito proviene da materiale direttamente prodotto da Liquid AI: la model card di LiquidAI/d1-omni-600M, il repository complementare d1-omni-600M-GGUF e il post di rilascio del 7 ottobre che ha annunciato contemporaneamente entrambi i checkpoint aperti. Le righe relative alle prestazioni sono state valutate dall'azienda produttrice su un indice che essa stessa mantiene, anziché essere sottoposte per una classifica pubblica, e il post afferma apertamente che benchmark dedicati alle decisioni audio sono un problema aperto. Nulla di quanto qui riportato è stato riprodotto da qualcuno al di fuori del laboratorio.

Di cosa sono fatti 587 milioni di parametri

Il numero in evidenza nasconde una suddivisione insolita. I parametri totali ammontano a 587M, e non sono un unico stack: un tronco condiviso da 381M con la testa decisionale collegata, un encoder visivo da 94M e un encoder audio da 112M. Ogni modalità passa attraverso gli stessi pesi del tronco, ed è la scelta progettuale che mantiene tutto piccolo — il modello non è tre modelli che indossano un impermeabile, è un unico tronco decisionale con due modi per alimentarlo.

I componenti provengono da punti diversi del catalogo di Liquid. Il tronco discende da LFM2.5-Encoder-350M, un encoder bidirezionale, anziché dalla linea solo decoder da cui proviene il fratello maggiore. La torre di visione è un SigLIP2 ripreso da LFM2.5-VL-450M con un adattatore e aggiornamenti LoRA applicati al backbone. Il percorso audio è un encoder FastConformer a 17 livelli con un proprio adattatore, sottoposto a fine-tuning rispetto a un backbone testuale congelato. La scheda riporta un contesto di 16.384 token condiviso tra posizioni di testo, immagini e audio insieme, con il testo ridotto a 896 token quando sono presenti immagini, e un vocabolario di 65.536 token — la metà dei 128.000 del suo fratello maggiore. Vale la pena notare quest'ultimo dato se lavori in una lingua che la famiglia copre solo in parte.

Il bidirezionale rispetto al solo decoder è il motivo per cui i due modelli risultano diversi a chiunque li abbia provati entrambi. Il tronco a forma di encoder legge l'intero stato in una volta sola, in entrambe le direzioni, prima di produrre qualsiasi cosa. Quello a forma di decoder legge in avanti come fa un modello linguistico. Entrambi sono addestrati a riportare risposte da una distribuzione con zero token di output, quindi nessuno dei due scrive testo — ma il meccanismo sottostante è una classe di modello diversa, e il divario di accuratezza discusso di seguito è il costo visibile del design più piccolo, a forma di encoder.

Trenta secondi di parlato, e niente per dargli un punteggio

L'audio è il motivo per cui esiste questo checkpoint. Accetta un singolo clip fino a 30 secondi, mono a 16 kHz, nella stessa passata in avanti che produce la risposta, ed è l'unico membro della famiglia a pesi aperti in grado di farlo. Per il lavoro on-device non è una funzionalità marginale. Una telecamera che segnala un difetto su una linea di produzione è un problema di visione che il fratello maggiore gestisce già; un dispositivo che instrada una richiesta vocale, classifica un enunciato o decide se un chiamante sta chiedendo un rimborso è un problema a cui solo questo può essere indirizzato.

Su quella capacità si innestano due vincoli, ed entrambi sono documentati, il che significa che non ci sono scuse per inciamparci in produzione. Primo, una richiesta trasporta immagini o audio, mai entrambi — passare entrambi genera un ValueError anziché scartarne uno in silenzio, quindi il fallimento è rumoroso ed economico da individuare in fase di test. Secondo, il percorso audio è stato addestrato su scambi tra un parlante di inglese e un assistente, con le clip tagliate a 30 secondi. Si tratta di una sola geometria di parlante, una sola struttura di turni e una sola distribuzione di accenti. Puntarlo su registrazioni di call centre o audio sul campo significa aspettarsi un comportamento che la scheda del modello non dichiara, ed è esattamente il tipo di lacuna che un benchmark farebbe emergere, se ne esistesse uno.

Non ne esiste nessuno. Il post di rilascio definisce i benchmark dedicati alle decisioni audio "attualmente un problema aperto" e invita la comunità a costruirne uno, il che è una cosa schietta da scrivere per un laboratorio e un vincolo concreto per chiunque valuti il modello. Liquid AI d1-omni-600Mè chiamato a giustificarsi sulla base di una capacità che nessuno è ancora in grado di misurare. Il fornitore ha inoltre omesso del tutto i numeri sull'inferenza, adducendo la motivazione dichiarata che il modello è un rilascio di ricerca preliminare in fase di sviluppo attivo. Quindi non esiste alcun dato di latenza per il 600M — né per il testo, né per la visione, né per il percorso audio che è il punto centrale.

Ciò che si può dire senza inventare nulla è un calcolo aritmetico sul numero di parametri pubblicato: alla precisione float16 che la scheda consiglia per le GPU, 587M parametri corrispondono a circa 1,2 GB di pesi prima delle attivazioni, contro circa 6,2 GB per il modello affine da 3,12B alla stessa precisione. La scheda riporta anche un avviso sulla precisione che è facile trascurare, ma che non dovrebbe esserlo: il modello è stato addestrato in float32, si consiglia float16 su GPU, e bfloat16 ha cambiato la risposta principale su alcune righe durante i test. Se il vostro stack di serving usa bfloat16 come impostazione predefinita, questo è un modello in cui tale impostazione non è sicura.

Perché la metà più piccola della famiglia sfugge facilmente

Il motivo per cui un lettore arriva al 3B e si ferma è strutturale, non accidentale. L'indice della documentazione di Liquid AI elenca tre righe sotto i modelli decisionali e non si presentano allo stesso modo: d1-3B e d1-omni-600M riportano link a Hugging Face e GGUF con un "No" nella colonna addestrabile, mentre d1 occupa una riga a sé stante con le sole lettere "API" dove dovrebbero esserci i link di download di ogni altro modello. Il post di rilascio chiama d1 un nome di famiglia e non distingue mai l'endpoint servito dal checkpoint aperto. Le librerie runtime locali scelgono poi il 3B, perché è quello le cui dimensioni e il cui numero di modalità corrispondono alla voce che vogliono pubblicare, e il 600M non compare affatto nello stesso elenco.

Il risultato è una famiglia la cui storia di accesso pubblicata, letta rapidamente, sembra un unico modello e un'unica riga API. Ciò che in realtà viene offerto sono due checkpoint aperti con trunk diversi, modalità diverse e un divario di 32 punti tra i loro punteggi sull'indice dello stesso fornitore, più un endpoint ospitato il cui rapporto con l'uno o l'altro checkpoint non è mai stato confermato dal fornitore. Il 600M non è nascosto dietro nulla. Semplicemente non ha un nome che una ricerca di d1 possa far emergere, ed è l'unico dei due che sente.

I punteggi che esistono, e l'unica colonna che vale la pena leggere

Sul Decision Index 0.2.1 il fornitore riporta 15,95 per Liquid AI d1-omni-600Mcontro 48,57 del suo fratello maggiore — un divario abbastanza ampio da rendere il totale quasi inutile come base per la scelta. I punteggi parziali sono più informativi della somma, e uno di essi è davvero sorprendente.

• Conoscenza — 8,3 contro 23,8

• Lingua — 12,9 contro 56,4

• Recupero — 35,0 contro 52,8

• Strumenti — 15,1 contro 74,5

• Arti — 6,8 contro 36,3

Il recupero è il punto in cui il modello piccolo tiene la posizione, perdendo meno di un terzo del punteggio del modello più grande, mentre nelle altre quattro colonne perde dal 60 all'80 percento. Questo schema corrisponde a ciò in cui un encoder addestrato dovrebbe essere bravo: confrontare uno stato con un contenuto è vicino a ciò per cui è stato costruito il trunk, ed è molto meno dipendente dalla capacità linguistica stratificata che il fratello a forma di decoder ha ereditato da un pre-addestramento molto più esteso. La colonna Strumenti racconta la storia opposta, e un divario di 59 punti è il numero da tenere d'occhio se il tuo carico di lavoro consiste nell'instradare una richiesta alla funzione giusta.

Su sette benchmark testuali pubblici il quadro si attenua. Il fornitore riporta una media di 78,4 per il 600M contro 82,9 per il 3B, con il modello piccolo che perde di stretta misura su SQuAD 2.0 (74,0 contro 85,3), PubMedQA (61,3 contro 66,0), BoolQ (77,7 contro 86,7) e XNLI (74,7 contro 85,0), mentre vince su Civil Comments per il rilevamento della tossicità (95,8 contro 93,0) e su PAWS-X per l'identificazione delle parafrasi (79,5 contro 76,9). La stessa impostazione di Liquid è che il 600M batte la media di 77,1 di un modello decisionale da 2B con un quarto dei parametri. Due suite di benchmark danno due verdetti apparentemente diversi, entrambi auto-riportati, e la lettura onesta è che nessuno dei due dirime nulla sul percorso audio, perché il percorso audio non è presente in nessuna delle due suite.

Dove i due si incontrano davvero

Nonostante tutte le divergenze, il modello di programmazione è identico, ed è proprio questo a renderli intercambiabili in un senso specifico. Entrambi rispondono a domande noul, di scelta e di punteggio su uno stato, entrambi restituiscono la risposta scelta con una mappa di probabilità e un valore di confidenza tra 0 e 1, ed entrambi riportano output_tokens: 0. Il campo confidence è quello che le persone fraintendono: misura quanto fortemente le probabilità favoriscono una risposta, non la probabilità che la risposta sia corretta. Uno 0,96 su una domanda posta male è una risposta sbagliata data con sicurezza, e il campo non ti avviserà.

Il punto in cui si incontrano nella pratica è una cascata. Filtra con Liquid AI d1-omni-600M — a basso costo, in locale e includendo i casi audio che nessun valutatore solo testuale può toccare — poi inoltra gli elementi che colloca vicino al centro della sua scala al checkpoint più grande per una decisione più precisa. Le regole di escalation sono la confidenza e la distribuzione che il 600M già restituisce, quindi la logica di instradamento non richiede un modello aggiuntivo e, su un carico di lavoro con una forte maggioranza di elementi facili, la maggior parte del traffico non raggiunge mai il secondo stadio. Questa composizione funziona perché entrambi i modelli restituiscono lo stesso tipo di oggetto. Due modelli arbitrari non lo farebbero.

Se quella cascata dovesse mai fare da gate a una chiamata a un modello generativo che noleggi anziché eseguire in proprio, lo strato sottostante è dove l'idraulica diventa interessante, ed è anche dove entriamo in gioco noi. Instradare una decisione attraverso una catena di modelli è esattamente il tipo di problema per cui esiste una regola di routing: OrcaRouter compone diversi modelli dietro un unico endpoint compatibile con OpenAI, ciascuno al suo prezzo di listino del provider, passato con 0% di markup, con failover automatico tra provider così un'escalation che fallisce a livello di provider riprova su un fallback invece di far fallire la richiesta. Non ospitiamo alcun modello Liquid AI — l'abbiamo verificato prima di scrivere questo — quindi nulla di quanto sopra è un'affermazione sul chiamare questi pesi attraverso di noi. Il punto è che il modello decisionale è la parte economica della pipeline e il modello preso in prestito dall'altra parte è la parte che va giù.

Da dove viene il file, se vuoi eseguirlo oggi

Per la distribuzione locale, il repository GGUF del fornitore stesso per il 600M fornisce Q8_0 a 407 MB e F16 e BF16 a 764 MB ciascuno, senza alcuna build a 4 bit elencata — quindi il download ufficiale più piccolo è circa sette volte più piccolo della build corrispondente del modello più grande e all'incirca della stessa dimensione di una fotografia a media risoluzione. L'esempio della scheda stessa avvia un server llama.cpp con flag di batch di 4096 e suggerisce di aumentarli a 16384 per stati più lunghi, quindi interroga lo stesso endpoint /v1/systemone che usa il fratello maggiore.

L'unica cosa che il percorso locale non ti dà sono i numeri del percorso audio, perché non esistono. Se intendi far passare la voce attraverso questo davanti a utenti reali, la valutazione è tua da costruire: un set etichettato di clip, gli stessi tre tipi di domanda, e un tasso di risposta misurato per classe. Non è una bocciatura del modello — un checkpoint da 587M che decide su una clip vocale in un solo passaggio è uno strumento genuinamente diverso da un classificatore di testo imbullonato a uno step di trascrizione, e merita un test reale piuttosto che uno basato sulle sensazioni.

Se quella cascata dovesse mai vincolare una chiamata a un modello generativo che noleggi anziché eseguire in proprio, OrcaRouter compone diversi modelli dietro un unico endpoint compatibile con OpenAI , ciascuno al prezzo di listino del rispettivo provider, trasferito senza alcun ricarico.

Scegliere un checkpoint omni invece di quello solo testo è anche un buon momento per guardare a ciò che è già andato storto in questa classe: gli incidenti documentati di IA e i fallimenti degli agenti che coinvolgono piccoli modelli multimodali sono raccolti in the OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.