d1-omni vs Liquid AI D1 Omni 600M: due nomi, un checkpoint e un numero di contesto di cui nessuno riesce a individuare la fonte

Liquid AI D1 Omni 600M e d1-omni non sono due modelli, e non sono nemmeno due checkpoint dello stesso modello. Sono un unico insieme di pesi — il modello decisionale multimodale da 587M parametri di Liquid AI, basato su Liquid AI LFM2.5-Encoder-350M e pubblicato su Hugging Face il 5 ottobre 2026 con il nome del repository LiquidAI/d1-omni-600M — con due nomi file diversi in due cataloghi diversi. Uno di questi cataloghi, quello del fornitore, ti dice che cos'è il modello. L'altro, quello di Ollama, ti dice in cosa qualcuno lo ha confezionato e stampa sulla scheda tre numeri che la documentazione del fornitore non supporta. Questo divario è l'intera ragione per cui vale la pena leggere questo confronto, perché per un modello così piccolo il packaging non è una nota a piè di pagina — è la differenza tra un modello testo-e-immagine e il modello che la scheda dice che hai scaricato.

Il fornitore non ha annunciato nulla in merito alla voce Ollama, e non c’è alcuna nota dei manutentori, alcuna voce di changelog e alcun readme nella pagina Ollama che spieghi alcunché di tutto ciò. Quindi la cornice onesta per tutto quanto segue è questa: i pesi sono pubblici e ispezionabili, il packaging è pubblico e ispezionabile, e l’interpretazione del packaging qui offerta è nostra, non di Liquid AI. Laddove un numero non può essere ricondotto a una fonte, questo articolo lo dice invece di ripeterlo.

Quali sono in realtà i due nomi

Liquid AI ha pubblicato il modello su Hugging Face con un timestamp di creazione del 5 ottobre 2026, due giorni prima della sua comparsa nel post sul blog dello stesso fornitore "Open d1: modelli decisionali edge per testo, visione e audio" il 7 ottobre. I pesi sono concessi in licenza secondo i termini LFM 1.0 di Liquid, contrassegnati d1_omni, system-one, multimodal, vision, audio e decision-model, e hanno totalizzato circa 13.900 download e 135 like al momento della stesura. Le varianti quantizzate sono arrivate secondo il proprio calendario: un repository GGUF il 6 ottobre, build MLX per Apple Silicon il 12 ottobre.

La voce Ollama non corrisponde a nessuno di quei repository. È una pagina della libreria Ollama denominata d1-omni che riporta il badge "vision 600m", mostra quattro tag ed era stata aggiornata pochi minuti prima che questo venisse scritto — ed è per questo che il radar l'ha fatto emergere. Nulla in essa nomina Liquid AI, LFM2.5-Encoder-350M o il repository Hugging Face da cui provengono i byte.

Quindi la differenza pratica è un nome file e un percorso di distribuzione, non un modello. Ciò che differisce, e ciò che conta, sono i metadati che avvolgono i byte.

I tre numeri sulla scheda Ollama, controllati uno alla volta

La pagina di Ollama stampa una dimensione, una finestra di contesto e un elenco di input per ogni tag. Tutti e tre meritano un secondo sguardo, perché su questo modello due di essi non sopravvivono al contatto con la fonte.

• Finestra di contesto — 125K sulla scheda, 16.384 in tutte le fonti del fornitore. La scheda del modello di Liquid AI indica un limite di 16.384 token che copre complessivamente le posizioni di testo, immagine e audio, e la pagina di documentazione dello stesso fornitore per d1-omni-600M riporta «16K token». La stringa 125K non compare in nessuna delle due. Potrebbe essere un artefatto della configurazione posizionale dell'architettura LFM2.5-Encoder sottostante o del modo in cui Ollama segnala un limite di cache, ma non è un valore pubblicato da Liquid AI e non è un valore che questo articolo possa attribuire a nessuno. Ciò che rende la discrepanza più che pedante è il numero successivo, più in basso.

• Lo stato che puoi effettivamente passare è limitato a 896 token nel percorso delle immagini. La scheda di Liquid dice che, quando sono presenti immagini, "lo stato e il testo della domanda vengono ridotti a 896 token, come da addestramento". Quindi una richiesta decisionale che contiene una foto ha un budget di testo all'incirca della dimensione di questa frase, indipendentemente dal valore di contesto stampato su una pagina pull. Se stessi dimensionando un prompt di triage su 125K e ti aspettassi di pagare per uno stato lungo, lo staresti dimensionando su un numero che non descrive il runtime. Il valore 16.384 è il vero tetto massimo; il valore 896 è il vero limite operativo per il percorso multimodale; il 125K è un numero senza traccia documentale.

• Dimensione — 850 MB sulla scheda, due file nel registro. Il tag Ollama d1-omni:latest corrisponde a un file di pesi quantizzati da 407 MB denominato Q8_0 più un file projector da 442 MB denominato BF16, e 407 + 442 = 849, che la pagina arrotonda a 850 MB. Entrambi sono elencati onestamente; l'aritmetica è solo la somma di un accoppiamento a precisione mista anziché di un singolo file. Il tag d1-omni:600m-bf16 è quello più pulito: 764 MB di pesi BF16 più lo stesso projector da 442 MB, 1,2 GB su disco, e il projector è identico byte per byte tra i due tag. Da notare per la sezione successiva, perché un projector che porta i propri pesi può spostare il conteggio effettivo dei parametri.

Un altro dettaglio che vale la pena registrare anziché spiegare: il blob dei parametri di runtime all'interno del pacchetto d1-omni di Ollama ha esattamente la stessa lunghezza, byte per byte — 18 byte — di quello all'interno del pacchetto separato d1 di Ollama, che distribuisce Liquid AI d1-3B con 2.87GB di pesi Q8_0 e un proiettore da 855MB. Due architetture, due quantità di parametri, due decenni di scala dei parametri tra di loro, e la stessa configurazione di runtime da 18 byte. Questa è una costante di packaging, non un'affermazione su nessuno dei due modelli.

Quello che i pesi stessi dicono

Togli il packaging e il modello è insolitamente ben documentato. Liquid AI D1 Omni 600M totala 587M parametri suddivisi in tre parti: un trunk condiviso e una testa decisionale da 381M, un encoder visivo da 94M e un encoder audio da 112M. Il trunk è bidirezionale — questo è un encoder, non un decoder — ed è lo stesso trunk per ogni modalità, con torri specifiche per modalità innestate sopra.

• Visione deriva da una torre SigLIP2 ereditata da Liquid AI LFM2.5-VL-450M, con un adattatore e aggiornamenti LoRA attivi solo per gli input di immagini mentre l'encoder stesso è rimasto congelato.

• Audio proviene da un FastConformer a 17 livelli con il proprio adattatore, ottimizzato in una fase in cui il backbone testuale era congelato, poi l'intero stack è stato ottimizzato, il LoRA è stato unito e i pesi sono stati mediati rispetto al checkpoint precedente.

• Il vocabolario comprende 65.536 token in 15 lingue: inglese, tedesco, spagnolo, francese, italiano, olandese, polacco, portoghese, arabo, hindi, giapponese, russo, turco, vietnamita e cinese.

• Le modalità non possono essere combinate. Una singola richiesta accetta testo più immagini, oppure testo più fino a 30 secondi di parlato — non entrambi. L'audio è previsto a 16 kHz mono, tra 0,5 e 30 secondi, ed è stato addestrato su scambi tra un parlante inglese e un assistente, il che rappresenta un vincolo reale per qualsiasi contenuto multilingue o rumoroso.

Niente di tutto ciò compare nella pagina di Ollama, e l'omissione ha una conseguenza che si vede direttamente negli esempi d'uso. Gli snippet di Ollama sono chiamate di chat — una stringa di modello, un array di messaggi, la parola "Hello!" — e il checkpoint sottostante non può rispondervi. Non è un modello di chat e non scrive testo. Restituisce risposte tipizzate: una probabilità sì/no, un'etichetta con una probabilità per etichetta, oppure una posizione su una scala ordinata, tutte lette direttamente dalla distribuzione di output con zero token di output generati. Le interfacce pubblicate lo riflettono: system_one e probabilities tramite Transformers, oppure un /v1/systemone endpoint tramite llama.cpp 0.7.0 e versioni successive. Una chiamata in formato chat a un modello decisionale è l'errore che questo divario di denominazione invita a commettere.

Due avvertenze accompagnano ciascuno di quei dati

Innanzitutto, Liquid ha valutato le proprie righe con lo scorer ufficiale anziché inviarle per la classifica pubblica, e nessuna terza parte ha riprodotto alcun risultato di d1-omni-600M — il fornitore dichiara chiaramente sulla model card che non riporta numeri di inferenza per questo checkpoint perché si tratta di una release di ricerca preliminare in sviluppo attivo. In secondo luogo, i due numeri principali non concordano tra loro: il divario di 32 punti nell'indice e il divario di 4,5 punti nella media dei benchmark descrivono lo stesso modello, ed è per questo che i punteggi parziali, non i totali, sono la lettura utile. Retrieval a 35,0 e Tools a 15,1 contro Arts a 6,8 indicano per quali attività questo checkpoint è pronto e per quali non lo è. Audio non ha affatto una colonna benchmark; Liquid definisce i benchmark dedicati alle decisioni audio un problema aperto.

Liquid AI D1 Omni 600M guida anche la propria famiglia su due dei sette: Civil Comments a 95,8 e PAWS-X a 79,5. Quelle sono le due righe in cui un encoder da 587M batte nettamente il decoder da 3B, ed entrambe hanno una conformazione da classificazione di testo anziché da ragionamento — il che si adatta all'architettura invece di contraddirla.

Scegli in base a ciò che vuoi. Se vuoi che funzioni localmente con Ollama, d1-omni è il nome che funziona — 850 MB per la build Q8_0, 1,2 GB per BF16, lo stesso percorso immagine documentato da Liquid, e nessuno dei due tag include un proiettore audio. Se vuoi il modello descritto dal fornitore, Liquid AI D1 Omni 600M è il nome da cercare, e la via Transformers tramite il repository Hugging Face è quella la cui lunghezza del contesto, elenco delle modalità e numero di parametri corrispondono alla documentazione.

In ogni caso, questa è la metà economica di una pipeline. Il modello decisionale classifica; qualcos'altro deve agire sulla classificazione. È il confine su cui si colloca OrcaRouter e quello che vale la pena enunciare con precisione: nessun modello Liquid AI è nel nostro catalogo, quindi la chiamata a d1-omni stessa va dove già la esegui — questi pesi sul tuo hardware, oppure l'API del fornitore e piattaforme di terze parti per le versioni ospitate. Ciò a cui servono i 200+ modelli dietro un'unica chiave compatibile con OpenAI è tutto ciò che sta a valle, al prezzo di listino di ciascun provider passato attraverso con uno 0% di ricarico, con failover automatico tra provider quando una richiesta sottoposta a triage si dirama verso un modello che sta avendo una brutta giornata.

Che cosa risolverebbe la questione aperta

Tre cose basterebbero a chiudere la questione, e nessuna richiede un annuncio del fornitore. Confrontare l'output del tag Ollama da 850MB con il checkpoint Hugging Face sugli stessi input ci direbbe se il packaging ha cambiato le risposte. Un commit di llama.cpp o una voce nel changelog di Ollama che spieghi il valore di contesto ci direbbe se 125K è un errore o una capacità che la model card non ha ancora recepito. E un risultato audio pubblicato — qualsiasi risultato audio — sposterebbe questo checkpoint fuori dalla categoria in cui si trova attualmente, ovvero un modello ben documentato con uno strato di packaging non documentato e una scoreboard interamente del fornitore.

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.