Liquid AI d1-omni-600M è ora disponibile come pull di Ollama: un modello decisionale da 600M in grado di ascoltarti

Liquid AI d1-omni-600M è diventato un pacchetto Ollama alle 22:32 UTC del 17 ottobre 2026. Quel timestamp non è un'ipotesi: il registry di Ollama fornisce un header ollama-push-time su ogni manifest, e i quattro tag dietro il nome d1-omni sono stati accettati tra le 22:31:25 e le 22:32:13 di quella sera, circa quattro ore prima che questo testo fosse scritto. Il modello in sé non è nuovo — Liquid AI ha reso disponibili i pesi aperti di Liquid AI d1-omni-600M insieme a Liquid AI d1-3B il 5 ottobre 2026 e ha annunciato entrambi nel suo post "Open d1" del 7 ottobre — ma fino alla scorsa notte gli unici modi per eseguire quello con capacità audio sul proprio hardware erano un ambiente transformers con trust_remote_code=True o una build di llama.cpp compilata da sé. Ora basta ollama pull d1-omni. Nessuno lo ha annunciato: né il blog di Liquid AI, né Ollama.

Il packaging è la storia, e vale la pena essere precisi su quali parti siano documentate. I post più recenti del blog di Liquid AI sono d1-ultra del 15 ottobre e LFM2.5-24B-A2B del 13 ottobre, e nessuno dei due menziona Ollama; la pagina di deployment Ollama del laboratorio continua a insegnarti a eseguire i suoi repository GGUF direttamente da Hugging Face con ollama run hf.co/LiquidAI/... e non nomina mai un modello d1. Anche il blog di Ollama tace — le sue ultime voci sono Reflection's Beam del 16 ottobre e un'integrazione Fly.io del 13 ottobre. Quello che esiste invece è una voce nel registry, quattro tag, un digest verificabile e una pagina della libreria che era ancora in fase di redazione mentre questo articolo veniva scritto: una cattura iniziale di quella pagina restituiva "No readme", e una cattura quaranta minuti dopo restituiva una descrizione completa scritta da Liquid AI, con una tabella di benchmark e una sezione sulla licenza. Se volete un evento datato e verificabile per gli ultimi sette giorni, è proprio quell'intestazione.

Ciò che il registro ha effettivamente accettato

Quattro tag corrispondono a due immagini, ed è la prima cosa da capire prima di effettuare il pull. d1-omni:latest, d1-omni:600m e d1-omni:600m-q8_0 sono lo stesso manifest — digest 1ba59f63e836 — mentre d1-omni:600m-bf16 è un secondo manifest, digest c1e95fce6627. Non esiste alcun tag F16, anche se il repository GGUF del fornitore pubblica un trunk F16.

• Livelli di pesi (build Q8_0) — un tronco da 407 MB da d1-omni-600M-Q8_0.gguf più un proiettore da 442 MB da mmproj-d1-omni-600M-BF16.gguf, con un blob di licenza da 10,5 KB e un blob dei parametri da 18 byte, per un totale di 849.659.968 byte.

• Dimensione riportata — 850 MB per il tag predefinito e 1,2 GB per 600m-bf16, entrambe come indicate sulla pagina della libreria.

• Versione minima del runtime — richiede: 0.40.4 nel blob di configurazione, che riporta anche model_family: lfm2, model_type: 380.73M e tipo di file Q8_0.

• Contesto — il blob dei parametri fissa num_ctx a 16.384.

• Licenza — {{1}}il testo incorporato è la LFM Open License v1.0, che indica Liquid AI, Inc. come licenziante, in corrispondenza con l'identificatore lfm1.0 riportato sulla model card.{{/1}}

Quel proiettore merita un secondo sguardo, perché è più grande del modello a cui è collegato. Leggendo direttamente i metadati GGUF dal blob del registro si vede clip.has_vision_encoder = True e clip.has_audio_encoder = True nello stesso file: 197 tensori di visione su 12 blocchi con embedding a 768 dimensioni e input da 256 pixel, e 641 tensori audio su 17 blocchi con embedding a 512 dimensioni e 128 bin mel. Sono la torre SigLIP2 e l'encoder FastConformer entrambi in viaggio nel bundle multimodale, ed è per questo che un trunk da 381 milioni di parametri viene fornito dietro un allegato da 442 MB. La capacità audio è fisicamente nel pacchetto che scarichi; la questione se l'endpoint possa raggiungerla viene dopo.

Il modello ha 587M parametri e il badge 125K è più grande della verità

La pagina di Ollama pubblicizza una "finestra di contesto da 125K" su ogni tag. Il num_ctx del pacchetto stesso è 16.384, e la model card di Liquid AI dice la stessa cosa a parole: 16.384 token che coprono insieme posizioni di testo, immagine e audio, con il testo dello stato e della domanda ridotto a 896 token ogni volta che sono presenti immagini. La cifra di 125K è riconducibile a una fonte — il GGUF del trunk riporta lfm2.context_length = 128000 — ma è il limite massimo dell'architettura, non la finestra che si ottiene, ed è il numero che più probabilmente può indurre in errore chi sta dimensionando un sostituto per un classificatore a contesto lungo. Considera 16.384 come valore operativo e 896 token di testo come valore operativo quando un'immagine è nello stato.

Il resto dei metadati conferma la scheda del modello piuttosto che la linea di marketing. Il tronco è di 18 blocchi, embedding di dimensione 1.024 e un vocabolario di 65.536, e non è un decoder: lfm2.attention.causal è False. I conteggi delle teste KV per layer riportano 0, 0, 8, 0, 0, 8, …, il che significa che la maggior parte di quei blocchi non sono affatto blocchi di attenzione, ovvero l'ascendenza da encoder bidirezionale che emerge. La testa decisionale è di due blocchi (lfm2.decision.block_count = 2), e le costanti di calibrazione che il fornitore tiene in config.json sono anche in questo GGUF — le domande a scelta hanno una temperatura di 1,7465 con due opzioni, 1,3999 con tre-cinque, 1,1751 con sei-dieci e 1,3725 sopra undici; sì/no è 1,6663; le domande con punteggio sono 1,7301 con tre-cinque livelli e 1,0 con sei-dieci. Questo è l'intero design in un unico posto: un insieme fisso di risposte denominate, valutate in un'unica passata, calibrate per forma della domanda, con output_tokens: 0 alla fine.

Non è un modello conversazionale e non scrive testo. Liquid AI ne elenca quindici lingue, inserisce i dati di addestramento audio solo in inglese — richieste tra un parlante e un assistente — e limita le clip a 30 secondi. La scheda mette inoltre in guardia dall'uso di bfloat16 sulle GPU: nei controlli effettuati dal fornitore stesso, ha modificato la risposta principale sullo 0,8% delle righe di testo e sull'1,7% delle righe audio, mentre float16 corrispondeva a float32 ovunque.

L'audio è nei pesi ed è assente dall'API documentata

Questa è la discrepanza che vale la pena conoscere prima di segnalare un bug. Il readme della pagina della libreria, scritto da Liquid AI, documenta l'audio inserendo un WAV base64 nell'array images di una richiesta /v1/systemone. Il readme GGUF su Hugging Face del fornitore, relativo allo stesso checkpoint, lo documenta diversamente, con un array files che trasporta data:audio/wav;base64,… nel server llama.cpp. E il riferimento dell'endpoint pubblicato da Ollama non documenta né l'uno né l'altro: il suo schema di richiesta ha state, images, questions e keep_alive, descrive images come "Richiede un modello con capacità visive, come Clef," e non contiene alcun campo audio né alcun campo files. Nel frattempo, la guida ai modelli decisionali di Ollama indica Nimble, Tev1, Clef e Clef Flash come modelli decisionali e dice solo che i modelli Clef possono anche valutare le immagini.

Quindi la posizione onesta sull'audio in Ollama oggi è: l'encoder è verificato come presente nel blob, il readme del fornitore dice che funziona tramite immagini e lo schema pubblicato non lo contempla. L'input di immagini sullo stesso modello ha basi più solide: la visione è una capacità documentata di System One e d1-omni compare nell'elenco della categoria visione di Ollama. Accanto a questa ci sono due lacune documentali minori: il riferimento dell'endpoint consente fino a 255 chiavi di opzione in una domanda a scelta, mentre la guida decisionale ne indica da 2 a 26, e la soglia minima di runtime del pacchetto, 0.40.4, è più alta dello 0.35.0 citato dalla documentazione dell'endpoint.

Archiviato sotto visione, non sotto decisione

La ricerca dei modelli di Ollama filtra i modelli decisionali in una categoria a sé. Contiene nove voci — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya e strands-decider — e né d1 né d1-omni è tra queste. La pagina d1-omni è taggata vision e 600m, e compare nell'elenco vision, quindi chi cerca "decision model" non troverà il più recente. Si tratta di un problema di reperibilità più che di capacità, ma è importante se stavi pianificando di confrontare le famiglie di modelli decisionali nel catalogo di Ollama e avevi concluso che questa non esistesse.

Ciò significa anche che d1-omni è il primo modello decisionale nella libreria di Ollama in grado di accettare input vocali — l'encoder audio è incluso nel pacchetto e nessun altro modello in quella lista di nove ne dispone. Se l'endpoint gli passerà effettivamente il tuo WAV è la questione aperta della sezione precedente, ed è la cosa più suscettibile di essere cambiata nel momento in cui leggerai questo testo.

I numeri, e chi ha prodotto ognuno di essi

Ogni valore di accuratezza associato a Liquid AI d1-omni-600M è di Liquid AI, e, per quanto possiamo verificare, non esiste alcuna valutazione indipendente di alcun modello d1 — nessuna riga di classifica, nessuna esecuzione di terze parti, nessuna contestazione pubblicata del punteggio del fornitore. Il fornitore ha assegnato lui stesso il punteggio a entrambi i checkpoint d1 con lo scorer ufficiale di Decision Index anziché inviarli alla classifica pubblica, e lo dichiara sulla scheda; ogni riga concorrente nella sua tabella proviene dalla classifica v0.2.1, il che significa che il confronto è un numero autovalutato accanto a numeri valutati esternamente.

• Decision Index 0.2.1 — 15,95 per d1-omni-600M (conoscenza 8,3, linguaggio 12,9, recupero 35,0, strumenti 15,1, arti 6,8) rispetto a 48,57 per d1-3B.

Benchmark come decisioni, media di sette — 78,4 per d1-omni-600M contro 82,9 per d1-3B, con il modello 600M avanti su Civil Comments (95,8 vs 93,0) e PAWS-X (79,5 vs 76,9) e indietro su BoolQ (77,7 vs 86,7) e SQuAD 2.0 (74,0 vs 85,3).

• Fast Decisions, split dev — 76.9, dichiarato dal fornitore, nessuna riga di confronto pubblicata.

• Velocità — niente. La scheda afferma chiaramente che i dati sull'inferenza non vengono riportati perché si tratta di una versione di ricerca preliminare in fase di sviluppo attivo, quindi qualsiasi dichiarazione sulla latenza che vedi altrove è una misurazione fatta da qualcun altro.

• I numeri di esempio nella pagina Ollama — l'esempio svolto nel readme mostra `urgent` con risposta a 0.998 e `technical` a 0.995. Sono output illustrativi di una singola richiesta, pubblicati dal runtime, e non costituiscono un benchmark.

Il divario tra 15,95 e 48,57 è la cosa più utile sulla scheda, perché risolve la questione dell'acquisto con le parole stesse del fornitore: il readme ti dice di usare d1 quando ciò che conta è l'accuratezza su testo e immagini e di scegliere d1-omni quando conta la dimensione o ti serve l'audio. Un modello da 587M che totalizza 78,4 su sette benchmark pubblici, reinterpretato come decisioni, è un plausibile classificatore edge. Non è una versione più piccola del 3B.

Dove OrcaRouter è adatto, e dove non lo è

Non serviamo questo modello. Un controllo del nostro catalogo il 18 ottobre ha restituito 208 ID modello e nessuno di essi proviene da Liquid AI, quindi nulla di quanto sopra costituisce una dichiarazione di disponibilità e dalla nostra parte non esiste alcun percorso per recuperarlo. Se desideri Liquid AI d1-omni-600M, il percorso locale è quello descritto sopra, mentre il percorso ospitato è l'API del fornitore stesso e qualunque piattaforma di terze parti lo adotti.

Ciò che il packaging cambia è la forma del sistema che lo circonda, ed è lì che siamo utili. Un modello decisionale non è quasi mai l'intera pipeline: il ticket che etichetta, il frame che segnala e la trascrizione che instrada devono comunque ricevere risposta, essere riassunti o essere inoltrati a un livello superiore da qualcosa che scrive testo. Quelle chiamate generative stanno dietro un'unica chiave compatibile con OpenAI per oltre 200 modelli ospitati al prezzo di listino del provider, passata attraverso con 0% di markup, così una variazione di prezzo del fornitore ti arriva lo stesso giorno invece che con un nuovo contratto. E poiché d1-omni-600M viene fornito senza prove indipendenti di accuratezza e senza latenza pubblicata, il modo giusto per metterlo davanti al traffico reale è dietro failover automatico tra provider — lascia che gestisca le chiamate di cui è sicuro e mantieni una via d'uscita quando non lo è, invece di rendere 587M parametri un singolo punto di guasto per la tua fase di triage. La decisione resta locale; il fallback non deve esserlo.

Cosa cambierebbe questa lettura

Quattro cose, ognuna delle quali trasformerebbe una nota di packaging in un articolo diverso. Ollama che documenta l’audio nello schema di richiesta di System One, il che convertirebbe il trucco WAV-in-immagini del readme in un input supportato e renderebbe questo il primo modello decisionale con capacità vocali che puoi eseguire con un solo comando. Una delle due aziende che riconosce il porting — Liquid AI che aggiunge d1-omni alla pagina Ollama della propria documentazione di deployment, oppure Ollama che lo elenca tra i modelli decisionali invece che tra quelli di visione. Un dato sulla velocità da chiunque, fornitore o meno, dato che oggi non ne esiste alcuno. E una riga indipendente del Decision Index per qualsiasi modello d1, che resta l’unico tassello mancante in tutta la famiglia.

Fino ad allora la decisione è semplice. Se esegui già Ollama alla versione 0.40.4 o successiva, il pull è un solo comando, il download è di 850 MB e ciò che ottieni è un classificatore da 587M che risponde a domande digitate in un singolo passaggio in avanti su testo e immagini — e, se il readme è corretto, su oltre 30 secondi di parlato in inglese. Se il tuo stato è lungo, tieni a mente la finestra da 16.384 token e il budget di testo da 896 token invece del badge da 125K. E se ti serve una prova che sia accurato prima che assegni un'etichetta a qualcosa che un cliente vede, quella prova non esiste ancora, per questo modello o per qualsiasi suo fratello.

I fallimenti documentati dell'IA e gli incidenti degli agenti dietro release come questa sono raccolti nell'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, gravità, grado di confidenza e flag di contestazione.