Liquid AI d1 vs Liquid AI d1-3B: Vad Ollama-biblioteket kallar en modell och leverantören kallar två

Det finns två sätt att namnge samma uppsättning vikter, och Liquid AI d1 och Liquid AI d1-3B illustrerar skillnaden bättre än någon jämförelse av parametrar skulle göra. Ta bort ett bindestreck och ett storlekssuffix från det andra namnet och du får det första, så det är frestande att behandla den kortare strängen som ett smeknamn. De två kataloger som faktiskt listar dessa modeller håller inte med om den tolkningen. Liquid AIs eget dokumentationsindex håller d1 i en egen rad med bokstäverna "API" där nedladdningslänkarna finns, och håller d1-3B och d1-omni-600M i ett separat par rader med fungerande Hugging Face- och GGUF-länkar och ett "No" i kolumnen för träningsbarhet. Ollama, vars bibliotekspost är anledningen till att detta par är värt att skriva om överhuvudtaget, slår ihop allt till en sida som heter d1, beskriver den i en enda rad som "en 3B-beslutsmodell från Liquid AI, byggd på LFM2.5-VL-3B," och erbjuder exakt tre taggar under. Att jämföra Liquid AI d1 mot Liquid AI d1-3B är därför inte en jämförelse mellan en hostad slutpunkt och en öppen checkpoint, och det är inte heller en jämförelse mellan två checkpoints. Det är en jämförelse mellan en hostad slutpunkt och den öppna checkpoint som det lokala runtime-ekosystemet har bestämt är d1 när du säger ordet utan närmare precisering. Det mesta av det som följer handlar om vilken av dessa tolkningar din driftsättning faktiskt beror på.

En not om hur siffrorna nedan har tagits fram, eftersom ärligheten betyder mer än formateringen av den. Allt siffermaterial här är Liquid AI:s egen rapportering, på modellkorten eller i publiceringsinlägget från 7 oktober. Raderna i Decision Index poängsattes av leverantören med den officiella poängsättaren i stället för att skickas in för offentlig rankning, och ingen tredje part har oberoende reproducerat något d1-resultat som vi kunnat hitta. Där en siffra är en aritmetisk beräkning utifrån en publicerad siffra i stället för en mätning, framgår det.

Varifrån de två namnen kommer

Det kortare namnet är äldre. Liquid AI:s inlägg från den 5 oktober introducerade modellen som Liquid AI d1 — "vår första beslutsmodell", multimodal i den utgåvan, som besvarar skrivna frågor utifrån ett tillstånd av text, bilder eller båda, i en enda framåtpassning med noll utdatatoken. Det inlägget anger ett hostat pris på 0,04 USD per miljon indatatoken, fakturerar endast indatatoken och noterar att bilder debiteras som text med 1,5 token per 32×32-patch, så en 1024×1024-bild kostar 1 536 token. Den anger också latensen för textbeslut till 200–300 ms. Det är siffror för den hostade tjänsten, och inlägget säger uttryckligen att körtiden bakom dem är leverantörens egen beslutsändpunkt på api.liquid.ai/decisions/v1/systemone.

Det längre namnet förekommer i inlägget den 7 oktober och på Hugging Face, och det är det som bär den reproducerbara detaljen: 3,12B parametrar, ett kontextfönster på 32 768 token, en vokabulär på 128 000 token, sexton dokumenterade språk, en SigLIP2 NaFlex formoptimerad 400M visionskodare, och baskedjan LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Det kortet säger också tydligt att modellen inte är en chattmodell och inte skriver text. Detta är den checkpoint som hela det lokala ekosystemet bygger på: GGUF-repositoriet innehåller Q4_K_M på 1,67 GB, Q8_0 på 2,87 GB samt F16 och BF16 på 5,4 GB vardera.

Det som inget leverantörsdokument säger rakt ut är att Liquid AI d1 och Liquid AI d1-3B är samma vikter. Dokumentationsindexet tilldelar dem separata rader. Lanseringsinlägget kallar d1 för en familj, inte en checkpoint. Tredjepartsartiklar har uppmärksammat gapet och noterat att leverantören inte har bekräftat identifieringen. Så det ärliga påståendet är kort: siffrorna som de två namnen publiceras med står inte i konflikt med varandra någonstans där vi kan hitta dem, familjelanseringen och den betjänade slutpunkten tillkännagavs med två dagars mellanrum och med en kompatibel beskrivning, och leverantören har inte sagt att de är samma modell. Betrakta likvärdigheten som ett rimligt arbetsantagande och inte som ett faktum som leverantören har satt sitt namn på.

Vad den lokala byggversionen faktiskt ändrar

Ollamas post är inte en återutgivning och inte en ny checkpoint. Det är ett paketeringsbeslut, och paketeringen påtvingar tre begränsningar som leverantörens egen dokumentation inte nämner över huvud taget. Den första är tagglistan: d1:latest, d1:3b och d1:3b-q8_0, tre taggar som namnger en kvantisering. GGUF-repositoriet som Liquid publicerar innehåller fyra precisioner, och 1,67 GB Q4_K_M – den som de flesta skulle ta till på en bärbar dator – finns inte bland Ollama-taggarna. Det du kan hämta är 2,87 GB Q8_0 och vad den expanderar till i den lokala lagringen; bibliotekssidan anger nedladdningen till 3,7 GB.

Det andra är begärandekontraktet. Ollama svarar med dessa modeller på /v1/systemone, tar emot ett state plus ett questions-objekt och returnerar typade svar med output_tokens: 0. Det är samma form som leverantörens hostade slutpunkt använder, vilket är det som gör växlingen mellan lokalt och hostat till en konfigurationsändring i stället för en omskrivning. Det tredje villkoret finns i Ollamas slutpunktsdokumentation i stället för på modellsidan, och det är strängare än en generativ modells: begäranden måste rymmas inom 64 KiB utan bilder och 32 MiB med dem, streaming stöds inte, molnhostade modeller avvisas, och bilder måste vara base64-PNG, JPEG eller WebP i begärandekroppen – externa URL:er avvisas. Bilder delas av varje fråga i en begäran, så en bild som du bara vill att ett svar ska beakta behöver ett eget anrop. Indata trunkeras aldrig, vilket innebär att ett överdimensionerat state returnerar ett fel i stället för att tyst klippas. Det är det bättre felläget, och det är fortfarande ett felläge som din klient måste hantera.

Två dokumentationsdetaljer är fortfarande olösta och värda att känna till innan du rapporterar en bugg. Ollamas slutpunktsreferens beskriver valfrågetypen som att den accepterar 2 till 255 alternativnycklar, medan dess kapacitetssida för beslutsmodeller anger 2 till 26; en av de två är inaktuell. Och kapacitetssidan listar sina stödda modeller som Nimble, Tev1, Clef och Clef Flash, utan att nämna d1 – trots att d1-paketets egen README dokumenterar stöd för /v1/systemone och --ask, och paketet kräver Ollama 0.40.4 medan slutpunktens egen dokumenterade minimiversion är 0.35.0. Läs versionskravet för paketet, inte det i guiden.

Siffrorna, och under vilket namn de publicerades

Det här är den del av parkopplingen som är lättast att få fel, eftersom båda namnen publiceras med prestandasiffror och siffrorna inte är organiserade på det sätt man skulle förvänta sig.

• Decision Index 0.2.1 – 48,57, publicerat under Liquid AI d1-3B. Liquid beskriver det som den bästa poängen för en beslutsmodell under 10B parametrar och placerar den före en 35B-A3B-modell på 47,11. • Latens för textbeslut — 200–300 ms, publicerat under Liquid AI d1 i inlägget om det hostade API:et. Det finns ingen motsvarande siffra kopplad till den öppna checkpointens eget namn. • Latens för en enskild fråga på lokal hårdvara — 8 ms på ett RTX 4090, 16 ms på en Jetson AGX Thor, 26 ms på en Jetson AGX Orin 64 GB, 50 ms på en Orin Nano, 30 ms på en Apple M5 Pro. Publicerat under Liquid AI d1-3B. • Genomströmning — 475 beslut per sekund på RTX 4090 och 1 106 per sekund på ett AMD MI325X med frågor packade i batchar. Publicerat under Liquid AI d1-3B. • Vision — ett medelvärde på 74,1 över elva offentliga bildbenchmarkar, mot 73,9 för LFM2.5-VL-3B-basen som den byggdes från. Publicerat under Liquid AI d1-3B. • Bildablation — samma frågeuppsättning besvarad med bilderna borttagna får 45,1, vilket är leverantörens egen mätning av vad vision-vägen bidrar med. Publicerat under Liquid AI d1-3B.

Två problem framgår av den listan, och inget av dem är fatalt, vilket är precis varför de förbises. Den hostade siffran och den lokala siffran skiljer sig 25 till 37 gånger — 200–300 ms mot 8 ms — och de mättes på saker som leverantören inte beskriver i jämförbara termer. Att tolka gapet som "lokalt är snabbare" stöds inte, eftersom den hostade siffran är end-to-end genom ett API och 8 ms är en forward pass på en namngiven GPU. De är inte samma mätning, och leverantören påstår aldrig att de är det.

Det andra problemet är visionsraden. En förbättring på 0,2 punkter jämfört med basmodellen över elva bildbenchmarks ligger inom bruset i de flesta benchmarkrapporteringar, så vad beslutsdelen än ger dig är den inte en väsentligt bättre bildkodare. Ablationsraden ser mycket mer imponerande ut 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 snarare än två versioner av en och samma, vilket Liquid anger i själva inlägget. Båda raderna är användbara. Ingen av dem stöder ett starkt påstående om kvaliteten på visuella beslut, och ingen tredje part har kört någon av dem.

Där de två namnen skiljer sig åt i praktiken

För en köpare kokar skillnaden ner till fyra frågor, och svaren pekar inte alla åt samma håll.

• Kostnadsbild — Liquid AI d1 faktureras per indatatoken, till leverantörens publicerade pris, utan utgående token att betala för. Liquid AI d1-3B är en nedladdning på 2,87 GB i Ollamas paketering eller en på 1,67 GB från leverantörens GGUF-repo, helt utan mätare per anrop. • Latens, mätbar — den hostade vägen uppger 200–300 ms per textbeslut. Den lokala vägens publicerade 8 ms är en framåtpassning på ett RTX 4090 med en varm modell, vilket är en verklig siffra och inte en tur-och-retur-resa för en begäran. • Dataväg — den hostade vägen skickar tillståndet till leverantören. Den lokala vägen behåller det på maskinen, vilket för ett supportärende, en medicinsk anteckning eller ett fotografi vanligtvis är argumentet som avslutar diskussionen. • Versionslåsning — Liquid AI d1 bakom en endpoint är vad leverantören serverar idag. Liquid AI d1-3B i Ollama är ett fast paket som du kontrollerar, och avvägningen är att du själv ansvarar för uppgraderingarna.

Den besvärande verkligheten bakom alla fyra är att den öppna checkpointen är ett syskon till den hostade modellen snarare än en ersättare för den, och leverantören har inte sagt något annat. Modellkortet för den öppna checkpointen rekommenderar den för routning och triage, moderering, avsiktsklassificering, extraktionskontroller, omrangordning, LLM-som-domare och skyddsräcken, och beskriver den som eftertränad på LFM2.5-VL-3B för kalibrerade beslut i ett enda pass. Inlägget om den hostade modellen beskriver samma uppsättning uppgifter med andra ord och anger priset för den hostade modellen. Om dessa är en och samma modell är den lokala versionen en gratis kopia av en hostad produkt, vilket skulle vara en ovanlig sak för ett labb att släppa utan att säga det. Om de är två finjusteringar av en gemensam bas bör de publicerade siffrorna inte antas kunna överföras i någon riktning. Den andra förklaringen kräver mindre av leverantören och stämmer med de bevis vi har.

Att köra båda halvorna av beslutet utan att köra två stackar

Vilket namn du än väljer tenderar pipelinen runt det att se likadan ut. En supportkö får en valfråga om ett målteam, en nollfråga om huruvida en återbetalning begärs, och en poängfråga för angelägenhetsgrad — ett tillstånd, tre svar, en körning. Där de två namnen verkligen skiljer sig åt är vid den punkt där beslutet reglerar ett anrop till en generativ modell som du hyr snarare än kör. Det anropet är ett annat problem med en annan felprofil, och det är den del av pipelinen där det spelar minst roll att d1 har rätt: ett dirigeringssvar med sannolikhet 0,98 följt av en 502 från modellen du dirigerade till är en misslyckad begäran oavsett.

Vi hostar ingen Liquid AI-modell — vi kontrollerade vår egen katalog innan vi skrev detta — så inget här är ett påstående om att anropa dessa vikter via oss. Det vi gör är lagret på andra sidan beslutet: en OpenAI-kompatibel nyckel för de modeller som en triagerad begäran grenar ut till, till varje leverantörs listpris vidarebefordrat med 0 % påslag, så att en leverantörs prissänkning når dig samma dag som den landar i stället för vid avtalsförnyelse, med automatisk failover mellan leverantörer så att en triagerad begäran överlever att modellen du dirigerade den till går ner. Om du kopplar in en beslutsmodell i en pipeline för första gången är det den halvan som är värd att göra tråkig.

Vilket namn som ska användas, beroende på situation

Om du vill prova modellen den här veckan utan en Python-miljö som är värd att underhålla, använd namnet som den lokala körmiljön använder. Hämta Liquid AI d1 från biblioteket, acceptera Q8_0 och 3,7 GB, och betrakta taket på 64 KiB per begäran och regeln om ingen streaming som designbegränsningar snarare än besvär. Du får en riktig endpoint, riktiga typade svar och ingen mätare per anrop redan dag ett.

Om du behöver ett mindre fotavtryck än Q8_0 är namnet du ska använda Liquid AI d1-3B, eftersom 1,67 GB Q4_K_M-bygget finns i leverantörens GGUF-repositorium och inte i biblioteksposten. Detta enda faktum är den mest praktiska skillnaden mellan de två namnen idag, och det är det som med störst sannolikhet missas av alla som läser bibliotekssidan och stannar där.

Om du sätter det här framför betalande användare och först behöver bevis på träffsäkerhet, hjälper inget av namnen dig ännu. Det finns ingen oberoende utvärdering av någon d1-modell som vi kunde hitta, raderna i Decision Index var självskattade, och leverantören har inte publicerat något benchmark för ljudbeslut alls. Vad du kan göra är att instrumentera det konfidensvärde som modellen redan returnerar — 0 till 1, vilket speglar hur starkt sannolikheterna talar för ett svar, inte hur sannolikt det är att svaret är rätt — och ta reda på var i din egen trafik som saken är osäker. Den mätningen är värd mer än någon av bilderna ovan, och den tar en dag.

Beslutsmodellen är den billiga halvan av pipelinen. Den generativa modellen som den dirigerar till är den halva som behöver ett avtal — en OpenAI-kompatibel nyckel omfattar de modeller som en triagerad begäran sprids ut till, var och en till sin leverantörs listpris, vidarebefordrat med 0 % påslag.

Att skala ner en destillerad checkpoint mot dess egen fullständiga release är också ett bra tillfälle att kontrollera registret: de dokumenterade AI-incidenterna och agentfelen kring små Liquid-modeller samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistad status.