Liquid AI d1-3B landar på Ollama: en tyst lokal slutpunkt för en beslutsmodell

Det finns en ny d1 i Ollamas bibliotek, och den är inte en chattmodell. Posten beskriver den på en rad — ”en 3B-beslutsmodell från Liquid AI, byggd på LFM2.5-VL-3B” — och den där enda meningen innehåller de två fakta som spelar störst roll. Liquid AI d1-3B, den lilla modell som Liquid AI byggde ovanpå Liquid AI LFM2.5-VL-3B och släppte som öppna vikter den 5 oktober 2026, är nu paketerad så att en enda pull lägger den på din egen maskin; och den returnerar fortfarande kalibrerade sannolikheter för typade frågor i stället för genererad text, exakt som den underliggande checkpointen gör. Om du har ett triage-, routnings-, modererings- eller gatingsteg i en pipeline, är detta första gången som den specifika modellfamiljen är ett enda kommando bort från att köras utan API-nyckel, utan pris per anrop och utan att någon tillståndstext lämnar din hårdvara.

Ordet "tyst" spelar en verklig roll här, men det är värt att vara precis om vilken halva av den här historien som är dokumenterad och vilken halva som inte är det. Liquid AI:s egen blogg har aldrig nämnt Ollama: labbets senaste inlägg, den 13 oktober 2026, handlar om en annan modell i LFM2.5-serien, och dess två d1-inlägg – tillkännagivandet om vision den 5 oktober och lanseringen av "Open d1" den 7 oktober – beskriver vikter, ett API och en benchmarkpoäng, inte en lokal körmiljö. Ollamas bibliotekssida för d1 innehåller inte heller något tillkännagivande, och det gör inte heller leverantörens dokumentationsindex, som anger GGUF som tillgängligt för Liquid AI d1-3B och dess ljudkapabla syskonmodell Liquid AI d1-omni-600M medan det bara nämner llama.cpp, Ollama och MLX som generiska driftsättningsalternativ. Det som finns är ett publicerat paket, en registerpost med en digest som du kan verifiera, en fungerande readme och en nedladdningsräknare som visade 10,4K när detta skrevs den 15 oktober 2026. Det som inte finns är en mening från leverantören som säger "det här gjorde vi".

Vad annonsen faktiskt innehåller

Tre taggar listas – d1:latest, d1:3b och d1:3b-q8_0 – och alla tre pekar på samma manifestdigest, 8c2d9ddae441. Det är det första man bör förstå om sidan: bibliotekets räknare för "3 modeller" är en räkning av taggar, inte av checkpoints. En artefakt, tre namn, 3,7 GB, ett kontextfönster på 32K och text- och bildinmatning. Om du hade hoppats kunna välja en storlek eller en kvantisering finns det inget att välja ännu.

Registret bakom sidan är mer informativt än sidan. Paketets konfigurationsblob rapporterar en modellfamilj av lfm2, en modelltyp på 2,7B, en filtyp av Q8_0 och en minsta körtid på Ollama 0.40.4. Det levereras i två viktlager: en generativ modell på 2,87 GB och en separat projektor på 856 MB. Det andra lagret är visionskodaren, och dess närvaro visar att den lokala byggversionen behåller den multimodala vägen i stället för att reducera d1 till enbart text — modellen kan fortfarande läsa ett fotografi tillsammans med en supportbiljett och svara på frågor om båda. De två siffrorna på den här sidan som verkar vara oförenliga — "3B" i beskrivningen och "2.7B" i registret — läses bäst som stammen och helheten: Liquid AI:s modellkort anger checkpointen till 3,12B parametrar inklusive en visionskodare med 400M parametrar, och språkstammen är den mindre siffran. Den aritmetiken är vår, inte leverantörens, och den erbjuds som en förklaring snarare än en specifikation.

Det finns inget kalenderdatum någonstans på bibliotekssidan. Den rapporterar relativa tidsstämplar – "Uppdaterad för 2 timmar sedan" i stunden då den hämtades – och en nedladdningsräknare, vilket betyder att dagen då listningen först dök upp inte går att känna till från listningen själv. De daterade fästpunkterna finns alla på Hugging Face och hos leverantören: viktrepositoriet för Liquid AI d1-3B skapades den 5 oktober 2026, ett medföljande GGUF-repositorium den 6 oktober, och Liquid AI publicerade sitt släppinlägg den 7 oktober. Om du behöver sätta ett datum på "när blev det här körbart lokalt", är det ärliga svaret i dag att paketet finns och hämtas just nu, och ingen utanför Ollama kan säga vilken morgon det lades upp.

Varför ett förpackningsevenemang är ett verkligt evenemang

Ollama öppnade en kategori för beslutsmodeller den 29 september 2026, när man släppte slutpunkten /v1/systemone och en CLI-flagga --ask för modeller som besvarar typade frågor i en enda framåtpassning. Nimble och Clef var de första familjerna genom den dörren. Det som det nya paketet d1 tillför är något annat än en ny benchmark-rad: det tar en modell som fram till nu levde antingen i en Python-miljö med en vendorerad modellklass eller bakom en hostad slutpunkt, och gör lokal inferens till ett kommando.

Kontraktet är värt att upprepa eftersom det inte är vad de flesta läsare menar med "att köra en modell." Du ger d1 ett tillstånd – en sträng, ett JSON-objekt, en array, eller en sträng plus bilder – och en uppsättning namngivna frågor, och du får tillbaka svar utan några genererade tokens alls. noul är en ja/nej-fråga som besvaras som en enda sannolikhet mellan 0 och 1. choice returnerar den valda etiketten, ett konfidensvärde och en fullständig sannolikhetskarta över dina alternativ. score placerar tillståndet på en ordnad bedömningsskala med två till tio nivåer och returnerar den sannolikhetsviktade nivån plus varje nivås sannolikhet. Ett tillstånd, upp till 64 frågor, en genomgång av indata. Ollamas eget exempelsvar för ett supportärende returnerar usage.output_tokens: 0, vilket är den tydligaste möjliga formuleringen av designen.

För alla vars pipeline redan anropar en beslutsmodell över HTTP förändrar den lokala vägen tre saker på en gång: latens, eftersom begäran slutar lämna maskinen; kostnad, eftersom det inte finns någon mätare per anrop; och datahantering, eftersom ärendetexten och fotografiet som du klassificerar aldrig korsar nätverket. Om din data består av en kunds meddelande eller ett internt dokument är det sista oftast det enda argument som behöver framföras.

Att köra det, och begränsningarna som dokumentationen sätter runt det

Det finns tre ingångar som stöds, och de är alla dokumenterade på bibliotekssidan. CLI-vägen är ollama run d1 --ask "Begärs en återbetalning?" med state inläst via pipe från en fil, samt flaggorna --choice och --level för de andra två frågetyperna. HTTP-vägen är en POST till http://localhost:11434/v1/systemone med en modell, ett state, en valfri images-array och ett questions-objekt. SDK-vägen pekar TypeSafes Python-klient mot localhost, där API-nyckeln ignoreras och vilket platshållarvärde som helst fungerar.

Begränsningarna kommer från Ollamas dokumentation för ändpunkter snarare än från Liquid AI, och de är snävare än en generativ modells: förfrågningar måste rymmas inom 64 KiB utan bilder och 32 MiB med dem, strömning stöds inte, modeller som driftas i molnet avvisas direkt, och bilder måste vara base64-kodade PNG, JPEG eller WebP som skickas i förfrågans kropp – fjärr-URL:er avvisas. Bilder delas mellan samtliga frågor i en förfrågan, så en bild som du bara vill att det första svaret ska beakta måste skickas som ett eget anrop. Indata trunkeras aldrig, vilket innebär att ett överdimensionerat tillstånd är ett fel snarare än en tyst beskuren prompt.

Två dokumentationsdetaljer är värda att flagga som olösta. Ollamas slutpunktsreferens beskriver valtypen som att den accepterar 2 till 255 alternativnycklar, medan kapacitetssidan för beslutsmodeller anger 2 till 26 – en av de två är inaktuell, och det är inte självklart vilken. Och kapacitetssidan namnger sina modeller som Nimble, Tev1, Clef och Clef Flash, utan att nämna d1, trots att d1-paketets egen readme säger att det fungerar via /v1/systemone och --ask. Paketet kräver Ollama 0.40.4; den dokumenterade lägstanivån för slutpunkten själv är 0.35.0. Inget av detta är en motsägelse som hindrar dig från att hämta modellen, men läs versionskravet för paketet i stället för det som står i kapacitetsguiden.

Siffrorna, och vem som producerade varenda en av dem

Nu till den del som förtjänar störst försiktighet. Alla prestandasiffror som är kopplade till den här modellen är Liquid AI:s, och det finns ingen oberoende utvärdering av Liquid AI d1-3B som existerar såvitt vi kan finna. Leverantörens rapporterade resultat, som upprepas på Ollama-sidan och på modellkortet, är följande:

• Decision Index 0.2.1 — 48,1 för d1-3B, mot 47,11 för Decider 35B-A3B, som Liquid beskriver som den bästa poängen för en beslutsmodell under 10B parametrar. • Vision — ett medelvärde på 74,1 över elva offentliga bildbenchmarks, mot 73,9 för LFM2.5-VL-3B-basen den byggdes från. • Latens — 8 ms per beslut på ett RTX 4090, 9 ms på ett AMD MI325X och 30 ms på en Apple M5 Pro. • Genomströmning — 475 beslut per sekund på 4090 och 1 106 på MI325X när frågor packas i batcher. • Ablation — frågeuppsättningen som besvaras utan får 45,1, vilket är Liquids eget mått på hur mycket visionsvägen bidrar.

Vision-raden är den som bör dämpa förväntningarna. En förbättring med 0,2 punkter jämfört med basmodellen på en uppsättning bildbenchmarks ligger inom bruset för det mesta av benchmark-rapporteringen; vad beslutsheaden än ger dig är det inte en väsentligt bättre bildkodare. Ablationsraden är mer intressant i den andra riktningen – en svängning på ungefär 29 punkter när bilder läggs till – men den jämför två olika frågeuppsättningar, inte två versioner av samma uppsättning. Och Decision Index är ett tredjepartsinstrument där Liquid poängsatte sina egna bidrag i stället för att skicka in dem för offentlig rankning, så betrakta 48,57 som ett leverantörspåstående gjort med någon annans linjal. Hastighetssiffrorna är inte heller granskade: 8 ms på en 4090 är ett rimligt tal för en 3B-modell som gör en framåtpassning, och det är fortfarande så att ingen har publicerat en körning som de inte äger.

Var OrcaRouter passar in, och var det inte gör det

OrcaRouter serverar inte Liquid AI d1-3B. Vi kontrollerade vår katalog innan vi skrev detta – 207 modeller, ingen av dem från Liquid AI, ingen av dem en beslutsmodell – så om du vill anropa d1 från ett API i stället för från din egen hårdvara är den hostade vägen i dag leverantörens egen beslutsändpunkt på api.liquid.ai/decisions/v1/systemone, där en betald d1-nivå hanterar bilder och en kostnadsfri d1:free-nivå endast är text, plus vilka tredjepartsplattformar som än tar upp den. Ingenting i den här artikeln bör läsas som ett påstående om att vi hostar den.

Det vi gör ligger nära problemet som den här modellen löser. Anledningen till att en beslutsmodell finns är att pipelines behöver ett billigt, deterministiskt sätt att välja bland alternativ, och d1:s eget dokumenterade exempel är ett ärende som dirigeras till ett mottagande team – vilket är ett dirigeringsproblem en nivå under vårt. När det beslutet styr ett anrop till en generativ modell som du hyr i stället för att köra själv, är OrcaRouter en OpenAI-kompatibel nyckel för 200+ hostade modeller till leverantörens listpris, vidarebefordrad med 0 % påslag, så en leverantörsprissänkning når dig samma dag som den landar i stället för vid nästa avtalsförnyelse. Och eftersom den lokala halvan av denna pipeline är den halva du äger, ligger risken i den hostade halvan: automatisk redundansväxling mellan leverantörer håller en triagerad begäran vid liv när modellen du dirigerade den till går ner. Inget av dessa är ett skäl att använda en 3B-beslutsmodell. De är skäl till att det som ligger på andra sidan beslutet inte bör vara en enda felpunkt.

Vad skulle förvandla detta från en förpackningsnotis till en berättelse?

Fem saker, var och en av vilka skulle ändra tolkningen. Att Liquid AI erkänner porten, eller att dess dokumentationsindex lägger till Ollama i den driftsättningsrad som för närvarande fylls med llama.cpp och MLX. En andra kvantisering: Liquids eget GGUF-arkiv levererar Q4_K_M, F16 och BF16 tillsammans med Q8_0, så ett mindre lokalt bygge är tekniskt tillgängligt, bara inte via detta paket. En lokal väg för Liquid AI d1-omni-600M, syskonet med 587M parametrar som kan läsa upp till trettio sekunder ljud och som leverantören betecknar som en tidig forskningsrelease – den skulle spela större roll än 3B för arbete på enheten, och det finns ännu inga tecken på den i något bibliotek. En oberoende rad i Decision Index, eller en offentlig topplistepost, vilket är den enda saknade pusselbiten för hela den här modellfamiljen. Och att Ollama lägger till d1 på sin sida för beslutsförmåga, vilket är en ändring på en rad som skulle visa att porten är godkänd snarare än tillfällig.

Fram till dess är beslutet tillräckligt enkelt att fatta på dina egna villkor. Om du redan kör en nyare Ollama är pull ett enda kommando, nedladdningen är 3,7 GB, och det den ersätter är antingen ett hostat anrop som du helst inte vill göra med en kunds text eller en Python-miljö som är mer arbete att underhålla än modellen är värd. Om du behöver oberoende bevis på noggrannhet innan detta hamnar framför riktiga användare, finns det beviset ännu inte för någon d1-modell, och ingen mängd lokal paketering skapar det.

Att köra beslutssteget på din egen hårdvara är också ett bra tillfälle att titta på vad som redan har gått fel i den här kategorin: de dokumenterade AI-incidenterna och agentfelen som involverar beslutsmodeller samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omstriddhetsflagga.