Liquid AI d1-3B sbarca su Ollama: un endpoint locale silenzioso per un modello decisionale

C'è un nuovo d1 nella libreria di Ollama, e non è un modello di chat. La voce lo descrive in una riga — "un modello decisionale da 3B di Liquid AI, basato su LFM2.5-VL-3B" — e quella singola frase contiene i due fatti che contano di più. Liquid AI d1-3B, il piccolo modello che Liquid AI ha costruito sopra Liquid AI LFM2.5-VL-3B e rilasciato come pesi aperti il 5 ottobre 2026, è ora confezionato in modo che un solo pull lo metta sulla tua macchina; e restituisce ancora probabilità calibrate su domande tipizzate anziché testo generato, esattamente come fa il checkpoint sottostante. Se hai una fase di triage, instradamento, moderazione o gating in una pipeline, questa è la prima volta che quella specifica famiglia di modelli è a un comando di distanza dall'essere eseguita senza chiave API, senza costo per chiamata e senza che alcun testo di stato lasci il tuo hardware.

La parola "quiet", però, qui sta facendo un lavoro concreto, e vale la pena essere precisi su quale metà di questa storia sia documentata e quale no. Il blog di Liquid AI non ha mai menzionato Ollama: il post più recente del laboratorio, del 13 ottobre 2026, riguarda un modello diverso della linea LFM2.5, e i suoi due post su d1 — l'annuncio vision del 5 ottobre e il rilascio "Open d1" del 7 ottobre — descrivono pesi, un'API e un punteggio di benchmark, non un runtime locale. Anche la pagina della libreria di Ollama per d1 non riporta alcun annuncio, e nemmeno l'indice della documentazione del fornitore, che segna GGUF come disponibile per Liquid AI d1-3B e la sua controparte con capacità audio Liquid AI d1-omni-600M mentre nomina llama.cpp, Ollama e MLX solo come opzioni di deployment generiche. Ciò che esiste è un pacchetto pubblicato, una voce nel registry con un digest che puoi verificare, un readme funzionante e un contatore di download che segnava 10,4K quando questo è stato scritto, il 15 ottobre 2026. Ciò che non esiste è una frase del fornitore che dica «l'abbiamo fatto noi».

Cosa contiene effettivamente l'annuncio

Tre tag sono elencati — d1:latest, d1:3b e d1:3b-q8_0 — e tutti e tre risolvono allo stesso digest del manifest, 8c2d9ddae441. Questa è la prima cosa da capire della pagina: il contatore "3 modelli" della libreria è un conteggio di tag, non di checkpoint. Un artefatto, tre nomi, 3,7 GB, una finestra di contesto di 32K, e input di testo e immagini. Se speravi di scegliere una dimensione o una quantizzazione, non c'è ancora nulla da scegliere.

Il registro dietro la pagina è più informativo della pagina. Il blob di configurazione del pacchetto riporta una famiglia di modelli lfm2, un tipo di modello 2.7B, un tipo di file Q8_0 e un runtime minimo di Ollama 0.40.4. Viene distribuito in due livelli di pesi: un modello generativo da 2,87 GB e un proiettore separato da 856 MB. Quel secondo livello è il codificatore visivo, e la sua presenza indica che la build locale mantiene il percorso multimodale invece di ridurre d1 al solo testo — il modello può ancora leggere una fotografia insieme a un ticket di assistenza e rispondere a domande su entrambi. I due numeri su questa pagina che sembrano discordare — "3B" nella descrizione e "2.7B" nel registro — vanno letti preferibilmente come il tronco e il tutto: la scheda del modello di Liquid AI indica il checkpoint a 3,12B parametri, incluso un codificatore visivo da 400M parametri, e il tronco linguistico è la cifra più piccola. Quell'aritmetica è nostra, non del fornitore, ed è offerta come spiegazione anziché come specifica.

Non c'è nessuna data di calendario da nessuna parte nella pagina della libreria. Mostra timestamp relativi — «Aggiornato 2 ore fa» al momento della cattura — e un contatore di download, il che significa che il giorno in cui questo elenco è comparso per la prima volta non è desumibile dall'elenco stesso. I riferimenti datati sono tutti su Hugging Face e presso il fornitore: il repository dei pesi per Liquid AI d1-3B è stato creato il 5 ottobre 2026, un repository GGUF di accompagnamento il 6 ottobre, e Liquid AI ha pubblicato il suo post di rilascio il 7 ottobre. Se hai bisogno di dare una data a «quando è diventato eseguibile localmente», la risposta onesta oggi è che il pacchetto esiste e viene scaricato proprio adesso, e nessuno al di fuori di Ollama può dire in quale mattina sia stato messo online.

Perché un evento di packaging è un vero evento

Ollama ha aperto una categoria di modelli decisionali il 29 settembre 2026, quando ha rilasciato l'endpoint /v1/systemone e un flag CLI --ask per modelli che rispondono a domande tipizzate in un singolo passaggio in avanti. Nimble e Clef sono state le prime famiglie a varcare quella porta. Ciò che aggiunge il nuovo pacchetto d1 è qualcosa di diverso da una nuova riga di benchmark: prende un modello che finora viveva o in un ambiente Python con una classe di modello vendorizzata o dietro un endpoint ospitato, e rende l'inferenza locale un comando.

Vale la pena ribadire il contratto perché non è ciò che la maggior parte dei lettori intende con «eseguire un modello». A d1 si passa uno stato — una stringa, un oggetto JSON, un array, oppure una stringa più immagini — e un insieme di domande con nome, e si ricevono risposte indietro senza alcun token generato. noul è una domanda sì/no a cui si risponde con una singola probabilità compresa tra 0 e 1. choice restituisce l'etichetta selezionata, una confidenza e una mappa di probabilità completa sulle opzioni. score colloca lo stato su una rubrica ordinata da due a dieci livelli e restituisce il livello ponderato per probabilità più la probabilità di ciascun livello. Uno stato, fino a 64 domande, una sola passata sull'input. La risposta di esempio di Ollama per un ticket di supporto restituisce usage.output_tokens: 0, che è la dichiarazione più chiara possibile del design.

Per chiunque la cui pipeline chiami già un modello decisionale via HTTP, la via locale cambia tre cose contemporaneamente: la latenza, perché la richiesta smette di lasciare la macchina; il costo, perché non c'è un contatore per chiamata; e la gestione dei dati, perché il testo del ticket e la fotografia che stai classificando non attraversano mai la rete. Se il tuo stato è un messaggio di un cliente o un documento interno, quest'ultima è di solito l'unico argomento che deve essere fatto.

Eseguirlo, e i limiti che la documentazione gli impone

Ci sono tre modi supportati per accedere, e sono tutti documentati nella pagina della libreria. Il percorso CLI è ollama run d1 --ask "È richiesto un rimborso?" con lo stato passato tramite pipe da un file, e i flag --choice e --level per gli altri due tipi di domanda. Il percorso HTTP è una POST a http://localhost:11434/v1/systemone con un modello, uno stato, un array di immagini opzionale e un oggetto domande. Il percorso SDK punta il client Python di TypeSafe su localhost, dove la chiave API viene ignorata e qualsiasi valore segnaposto funziona.

I limiti provengono dalla documentazione dell'endpoint di Ollama piuttosto che da Liquid AI, e sono più stringenti di quelli di un modello generativo: le richieste devono rientrare in 64 KiB senza immagini e 32 MiB con esse, lo streaming non è supportato, i modelli ospitati sul cloud vengono respinti senza appello, e le immagini devono essere PNG, JPEG o WebP codificate in base64 e inviate nel corpo della richiesta — gli URL remoti vengono rifiutati. Le immagini sono condivise da ogni domanda di una richiesta, quindi un'immagine che vuoi che venga considerata solo dalla prima risposta deve essere inviata come chiamata separata. L'input non viene mai troncato, il che significa che uno stato di dimensioni eccessive è un errore anziché un prompt troncato silenziosamente.

Due dettagli della documentazione meritano di essere segnalati come irrisolti. Il riferimento dell'endpoint di Ollama descrive il tipo choice come accettante da 2 a 255 chiavi di opzione, mentre la pagina delle funzionalità per i modelli decisionali dice da 2 a 26 — uno dei due è obsoleto, e non è ovvio quale. E la pagina delle funzionalità elenca i modelli supportati come Nimble, Tev1, Clef e Clef Flash, senza menzionare d1, anche se il readme del pacchetto d1 stesso afferma che funziona tramite /v1/systemone e --ask. Il pacchetto richiede Ollama 0.40.4; la versione minima documentata per l'endpoint stesso è 0.35.0. Niente di tutto ciò è una contraddizione che ti impedisce di scaricare il modello, ma leggi il requisito di versione sul pacchetto invece di quello nella guida alle funzionalità.

I numeri, e chi ha prodotto ognuno di essi

Ora la parte che merita la massima cautela. Ogni cifra di prestazione associata a questo modello è di Liquid AI, e non esiste alcuna valutazione indipendente di Liquid AI d1-3B esistente per quanto ci risulta. I risultati riportati dal fornitore, ripetuti sulla pagina Ollama e sulla scheda del modello, sono questi:

• Decision Index 0.2.1 — 48,57 per d1-3B, contro 47,11 per Decider 35B-A3B, che Liquid descrive come il miglior punteggio per un modello decisionale sotto i 10 miliardi di parametri. • Visione — una media di 74,1 su undici benchmark pubblici di immagini, contro 73,9 per la base LFM2.5-VL-3B da cui è stato costruito. • Latenza — 8 ms per decisione su una RTX 4090, 9 ms su una AMD MI325X e 30 ms su un Apple M5 Pro. • Throughput — 475 decisioni al secondo sulla 4090 e 1.106 sulla MI325X quando le domande vengono raggruppate in batch. • Ablation — lo stesso insieme di domande a cui si risponde senza immagini totalizza 45,1, che è la misura di Liquid stessa di quanto contribuisca il percorso visivo.

La riga vision è quella che dovrebbe ridimensionare le aspettative. Un miglioramento di 0,2 punti rispetto al modello base su una serie di benchmark di immagini rientra nel rumore della maggior parte dei resoconti di benchmark; qualunque cosa ti garantisca il decision head, non è un image encoder materialmente migliore. La riga di ablazione è più interessante nella direzione opposta — un salto di circa 29 punti quando vengono aggiunte le immagini — ma confronta due set di domande diversi, non due versioni dello stesso. E il Decision Index è uno strumento di terze parti sul quale Liquid ha valutato le proprie voci invece di inviarle per la classificazione pubblica, quindi considera 48,57 come un'affermazione del fornitore fatta con il righello di qualcun altro. Anche le cifre sulla velocità non sono verificate: 8 ms su una 4090 è un numero plausibile per un modello 3B che esegue un singolo forward pass, e resta il fatto che nessuno ha pubblicato una run che non possiede.

Dove OrcaRouter è adatto, e dove non lo è

OrcaRouter non serve Liquid AI d1-3B. Abbiamo controllato il nostro catalogo prima di scrivere questo — 207 modelli, nessuno di Liquid AI, nessuno un modello decisionale — quindi se vuoi chiamare d1 da un'API anziché dal tuo hardware, la via ospitata oggi è l'endpoint decisionale del fornitore stesso su api.liquid.ai/decisions/v1/systemone, dove un tier d1 a pagamento gestisce le immagini e un tier d1:free gratuito è solo testo, più qualunque piattaforma di terze parti lo adotti. Nulla in questo articolo va letto come un'affermazione che lo ospitiamo.

Ciò che facciamo è adiacente al problema che questo modello risolve. Il motivo per cui esiste un modello decisionale è che le pipeline hanno bisogno di un modo economico e deterministico per scegliere tra le opzioni, e l'esempio documentato di d1 stesso è un ticket instradato a un team di destinazione — che è un problema di routing di un livello inferiore al nostro. Quando quella decisione fa da gate a una chiamata verso un modello generativo che noleggi anziché eseguire, OrcaRouter è una chiave compatibile con OpenAI per oltre 200 modelli ospitati al prezzo di listino del provider, passata attraverso con markup dello 0%, così un taglio di prezzo del fornitore ti raggiunge il giorno in cui arriva anziché al prossimo rinnovo contrattuale. E poiché la metà locale di questa pipeline è la metà che possiedi, il rischio risiede nella metà ospitata: failover automatico tra provider mantiene viva una richiesta sottoposta a triage quando il modello a cui l'hai instradata non è disponibile. Nessuno dei due è un motivo per usare un modello decisionale da 3B. Sono motivi per cui la cosa dall'altra parte della decisione non dovrebbe essere un singolo punto di guasto.

Che cosa lo trasformerebbe da una nota di confezionamento in una storia?

Cinque cose, ognuna delle quali cambierebbe la lettura. Liquid AI che riconosce il port, oppure il suo indice di documentazione che aggiunge Ollama alla riga di deployment che attualmente riempie con llama.cpp e MLX. Una seconda quantizzazione: il repository GGUF di Liquid stesso include Q4_K_M, F16 e BF16 insieme a Q8_0, quindi una build locale più piccola è tecnicamente disponibile, solo non attraverso questo pacchetto. Un percorso locale per Liquid AI d1-omni-600M, il fratello da 587M parametri che legge fino a trenta secondi di audio e che il fornitore etichetta come release di ricerca preliminare — quello conterebbe più del 3B per il lavoro on-device, e non se ne vede traccia in nessuna libreria finora. Una riga indipendente del Decision Index, o una voce in una classifica pubblica, che è l'unico pezzo mancante in tutta questa famiglia di modelli. E Ollama che aggiunge d1 alla sua pagina delle capacità decisionali, che è una modifica di una riga che ti direbbe che il port è approvato anziché incidentale.

Fino ad allora, la decisione è abbastanza semplice da poter essere presa alle tue condizioni. Se usi già una versione recente di Ollama, il pull è un solo comando, il download è di 3,7 GB, e ciò che sostituisce è o una chiamata ospitata che preferiresti non fare con il testo di un cliente, oppure un ambiente Python che richiede più lavoro di manutenzione di quanto il modello valga. Se hai bisogno di prove indipendenti di accuratezza prima che questo finisca davanti a utenti reali, tali prove non esistono ancora per nessun modello d1, e nessuna quantità di impacchettamento locale può crearle.

Eseguire la fase decisionale sul tuo hardware è anche un buon momento per dare un'occhiata a ciò che è già andato storto in questa categoria: gli incidenti AI documentati e i fallimenti degli agenti che coinvolgono modelli decisionali sono raccoltinell'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, il livello di gravità, il grado di confidenza e il flag di contestazione.