Liquid AI d1 vs Liquid AI d1-3B: Wat de Ollama Library één model noemt en de leverancier twee.

Er zijn twee manieren om dezelfde set gewichten te benoemen, en Liquid AI d1 en Liquid AI d1-3B illustreren het verschil beter dan welke vergelijking van parameters dan ook. Trek één koppelteken en een grootte-achtervoegsel van de tweede naam af en je krijgt de eerste, dus het is verleidelijk om de kortere tekenreeks als een bijnaam te beschouwen. De twee catalogi die deze modellen daadwerkelijk vermelden, zijn het niet eens met die lezing. De eigen documentatie-index van Liquid AI houdt d1 in een eigen rij met de letters "API" waar de downloadlinks staan, en houdt d1-3B en d1-omni-600M in een afzonderlijk paar rijen met werkende Hugging Face- en GGUF-links en een "Nee" in de trainbare kolom. Ollama, waarvan de bibliotheekvermelding de reden is dat dit paar überhaupt het bespreken waard is, voegt dat allemaal samen tot één pagina genaamd d1, beschrijft het in één regel als "een 3B-beslissingsmodel van Liquid AI, gebouwd op LFM2.5-VL-3B," en biedt daaronder precies drie tags aan. Het vergelijken van Liquid AI d1 met Liquid AI d1-3B is daarom geen vergelijking tussen een gehost endpoint en een open checkpoint, en het is ook geen vergelijking tussen twee checkpoints. Het is een vergelijking tussen een gehost endpoint en het open checkpoint waarvan het lokale runtime-ecosysteem heeft bepaald dat het d1 is wanneer je het woord zonder nadere aanduiding zegt. Het meeste van wat volgt gaat erover van welke van die lezingen jouw deployment daadwerkelijk afhankelijk is.

Een opmerking over hoe de onderstaande cijfers tot stand zijn gekomen, want de eerlijkheid ervan weegt zwaarder dan de opmaak. Alles wat hier numeriek is, komt uit Liquid AI's eigen rapportage, op de modelkaarten of in de releasepost van 7 oktober. De rijen van de Decision Index zijn door de leverancier gescoord met de officiële scorer in plaats van ingediend voor een openbare rangschikking, en voor zover wij konden nagaan, heeft geen enkele derde partij enig d1-resultaat onafhankelijk gereproduceerd. Waar een getal een berekening op een gepubliceerd cijfer is in plaats van een meting, staat dat erbij.

Waar de twee namen vandaan komen

De kortere naam is ouder. De post van Liquid AI van 5 oktober introduceerde het model als Liquid AI d1 — "ons eerste beslissingsmodel", multimodaal in die release, dat getypte vragen beantwoordt over een toestand van tekst, afbeeldingen of beide, in één forward pass met nul outputtokens. Die post noemt een gehoste prijs van $0,04 per miljoen inputtokens, factureert alleen inputtokens, en merkt op dat afbeeldingen net als tekst worden gefactureerd tegen 1,5 tokens per 32×32 patch, dus een afbeelding van 1024×1024 kost 1.536 tokens. De post geeft ook de latentie voor tekstbeslissingen als 200–300 ms. Dat zijn cijfers voor de gehoste service, en de post is expliciet dat de runtime erachter de eigen beslissingsendpoint van de leverancier is op api.liquid.ai/decisions/v1/systemone.

De langere naam verschijnt in het bericht van 7 oktober en op Hugging Face, en het is degene die het reproduceerbare detail bevat: 3,12B parameters, een context van 32.768 tokens, een vocabulaire van 128.000 tokens, zestien gedocumenteerde talen, een op vorm geoptimaliseerde SigLIP2 NaFlex vision-encoder van 400M, en de basisketen LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Die kaart vermeldt ook duidelijk dat het model geen chatmodel is en geen tekst schrijft. Dit is het checkpoint waarop het hele lokale ecosysteem is gebouwd: de GGUF-repository bevat Q4_K_M van 1,67 GB, Q8_0 van 2,87 GB, en F16 en BF16 van elk 5,4 GB.

Wat geen enkel leveranciersdocument hardop zegt, is dat Liquid AI d1 en Liquid AI d1-3B dezelfde gewichten zijn. De documentatie-index wijst ze aparte rijen toe. Het releasebericht noemt d1 een familie, geen checkpoint. Artikelen van derden hebben de kloof opgemerkt en erop gewezen dat de leverancier de identificatie niet heeft bevestigd. De eerlijke bewering is dus kort: de cijfers waarmee de twee namen worden gepubliceerd, spreken elkaar nergens tegen waar wij ze kunnen vinden, de familie-release en het geserveerde endpoint werden twee dagen na elkaar aangekondigd met een compatibele beschrijving, en de leverancier heeft niet gezegd dat ze hetzelfde model zijn. Behandel de gelijkwaardigheid als een redelijke werkveronderstelling en niet als een feit waar de leverancier zijn naam aan heeft verbonden.

Wat de lokale build daadwerkelijk verandert

De vermelding van Ollama is geen heruitgave en geen nieuw checkpoint. Het is een verpakkingskeuze, en die verpakking legt drie beperkingen op die de eigen documentatie van de leverancier helemaal niet noemt. De eerste is de taglijst: d1:latest, d1:3b en d1:3b-q8_0, drie tags die één kwantisatie aanduiden. De GGUF-repository die Liquid publiceert, bevat vier precisieniveaus, en de 1,67 GB Q4_K_M — het bestand waar de meeste mensen op een laptop naar zouden grijpen — staat niet tussen de Ollama-tags. Wat je kunt ophalen is de 2,87 GB Q8_0 en alles waartoe die in de lokale opslag uitgroeit; de bibliotheekpagina meldt de download als 3,7 GB.

De tweede is het requestcontract. Ollama bedient deze modellen op /v1/systemone, neemt een state plus een questions-object en retourneert getypeerde antwoorden met output_tokens: 0. Dat is dezelfde vorm die het gehoste endpoint van de leverancier gebruikt, waardoor de overstap tussen lokaal en gehost een configuratiewijziging is in plaats van een herschrijving. De derde beperking staat in de endpointdocumentatie van Ollama en niet op de modelpagina, en ze is strenger dan die van een generatief model: verzoeken moeten binnen 64 KiB passen zonder afbeeldingen en binnen 32 MiB met afbeeldingen, streaming wordt niet ondersteund, in de cloud gehoste modellen worden geweigerd, en afbeeldingen moeten base64 PNG, JPEG of WebP in de body van het verzoek zijn — externe URL's worden geweigerd. Afbeeldingen worden gedeeld door elke vraag in een verzoek, dus een afbeelding die maar door één antwoord in beschouwing mag worden genomen, heeft een eigen aanroep nodig. Invoer wordt nooit afgekapt, wat betekent dat een te grote state een fout retourneert in plaats van stilzwijgend te worden ingekort. Dat is de betere faalmodus, en het is nog steeds een faalmodus die je client moet afhandelen.

Er zijn nog twee documentatiedetails onopgelost, en het is de moeite waard om ze te kennen voordat je een bug indient. De endpointreferentie van Ollama beschrijft het keuzevraagtype als een type dat 2 tot 255 optiesleutels accepteert, terwijl de mogelijkhedenpagina voor decision-models 2 tot 26 zegt; een van de twee is verouderd. En de mogelijkhedenpagina noemt de ondersteunde modellen Nimble, Tev1, Clef en Clef Flash, zonder d1 te vermelden — hoewel de eigen readme van het d1-pakket ondersteuning voor /v1/systemone en --ask documenteert, en het pakket Ollama 0.40.4 vereist, terwijl de eigen gedocumenteerde ondergrens van het endpoint zelf 0.35.0 is. Lees de versievereiste op het pakket, niet die in de handleiding.

De nummers, en onder welke naam ze zijn gepubliceerd.

Dit is het deel van de koppeling dat het gemakkelijkst fout gaat, omdat beide namen samen met prestatiecijfers worden gepubliceerd en de cijfers niet zijn georganiseerd zoals je zou verwachten.

• Decision Index 0.2.1 — 48,57, gepubliceerd onder Liquid AI d1-3B. Liquid beschrijft het als de beste score voor een beslissingsmodel onder 10B parameters en plaatst het vóór een 35B-A3B-model op 47,11. • Latentie bij tekstbeslissingen — 200–300 ms, gepubliceerd onder Liquid AI d1 in het hosted-API-bericht. Er is geen equivalent cijfer gekoppeld aan de naam van het open checkpoint zelf. • Latentie van één vraag op lokale hardware — 8 ms op een RTX 4090, 16 ms op een Jetson AGX Thor, 26 ms op een Jetson AGX Orin 64 GB, 50 ms op een Orin Nano, 30 ms op een Apple M5 Pro. Gepubliceerd onder Liquid AI d1-3B. • Doorvoer — 475 beslissingen per seconde op de RTX 4090 en 1.106 per seconde op een AMD MI325X met vragen in batches gebundeld. Gepubliceerd onder Liquid AI d1-3B. • Visie — een gemiddelde van 74,1 over elf publieke beeldbenchmarks, tegenover 73,9 voor de LFM2.5-VL-3B-basis waarop het is gebouwd. Gepubliceerd onder Liquid AI d1-3B. • Beeldablatie — dezelfde vragenreeks, beantwoord met verwijderde afbeeldingen, scoort 45,1, wat de eigen meting van de leverancier is van de bijdrage van het visiepad. Gepubliceerd onder Liquid AI d1-3B.

Uit die lijst komen twee problemen voort, en geen van beide is fataal, en dat is precies waarom ze over het hoofd worden gezien. Het gehoste cijfer en het lokale cijfer liggen 25 tot 37 keer uit elkaar — 200–300 ms tegenover 8 ms — en ze zijn gemeten op zaken die de leverancier niet in vergelijkbare termen beschrijft. De kloof lezen als “lokaal is sneller” is niet onderbouwd, omdat het gehoste getal end-to-end via een API is en de 8 ms een forward pass op een met naam genoemde GPU is. Het zijn niet dezelfde metingen, en de leverancier beweert dat ook nergens.

Het tweede probleem is de vision-rij. Een verbetering van 0,2 punt ten opzichte van het basismodel op elf beeldbenchmarks valt binnen de ruis van de meeste benchmarkrapportages, dus wat de decision head je ook oplevert, het is geen wezenlijk betere beeldencoder. De ablatie-rij ziet er in de andere richting veel indrukwekkender uit — een verschil van ongeveer 29 punten wanneer afbeeldingen worden toegevoegd — maar vergelijkt twee verschillende vragensets in plaats van twee versies van één, wat Liquid zelf in het bericht aangeeft. Beide rijen zijn nuttig. Geen van beide ondersteunt een sterke bewering over de kwaliteit van visuele beslissingen, en geen enkele derde partij heeft een van beide uitgevoerd.

Waar de twee namen in de praktijk uiteenlopen

Voor een koper komt het onderscheid neer op vier vragen, en de antwoorden wijzen niet allemaal dezelfde kant op.

• Kostenstructuur — Liquid AI d1wordt gefactureerd per inputtoken, tegen het gepubliceerde tarief van de leverancier, zonder dat er outputtokens betaald hoeven te worden. Liquid AI d1-3Bis een download van 2,87 GB in de verpakking van Ollama of een van 1,67 GB uit de GGUF-repo van de leverancier, zonder enige meting per aanroep. • Latentie, meetbaar — de gehoste route geeft 200–300 ms per tekstbeslissing. De gepubliceerde 8 ms van de lokale route is een forward pass op een RTX 4090 met een warm model, wat een echt getal is en geen round trip van een verzoek. • Gegevenspad — de gehoste route stuurt de toestand naar de leverancier. De lokale route houdt die op de machine, wat voor een supportticket, een medische notitie of een foto meestal het argument is dat de discussie beëindigt. • Versiepinning — Liquid AI d1achter een endpoint is wat de leverancier vandaag serveert. Liquid AI d1-3Bin Ollama is een vast pakket dat u beheert, en de keerzijde is dat u zelf de upgrades beheert.

De ongemakkelijke realiteit onder alle vier is dat het open checkpoint een zustermodel van het gehoste model is in plaats van een vervanging ervoor, en de leverancier heeft het tegendeel niet gezegd. De modelkaart voor het open checkpoint beveelt het aan voor routing en triage, moderatie, intentieclassificatie, extractiecontroles, reranking, LLM-as-a-judge en guardrails, en beschrijft het als post-getraind op LFM2.5-VL-3B voor gekalibreerde beslissingen in één doorgang. De post over het gehoste model beschrijft dezelfde set taken in andere bewoordingen en vermeldt de prijs voor de gehoste versie. Als dat één model is, is de lokale build een gratis kopie van een gehost product, wat een ongebruikelijk iets zou zijn voor een lab om uit te brengen zonder dat te vermelden. Als het twee fine-tunes van een gemeenschappelijke basis zijn, mag niet worden aangenomen dat de gepubliceerde cijfers in een van beide richtingen overdraagbaar zijn. De tweede verklaring vergt minder van de leverancier en sluit aan bij het bewijs dat we hebben.

Beide helften van de beslissing uitvoeren zonder twee stacks te draaien

Welke naam je ook kiest, de pipeline eromheen ziet er meestal hetzelfde uit. Een supportwachtrij krijgt een keuzevraag over een doelteam, een boolvraag of er een terugbetaling wordt aangevraagd, en een scorevraag voor urgentie — één status, drie antwoorden, één pass. Waar de twee namen echt uiteenlopen, is op het punt waarop de beslissing bepaalt of een aanroep naar een generatief model dat je huurt in plaats van zelf draait, doorgaat. Die aanroep is een ander probleem met een ander faalprofiel, en het is het deel van de pipeline waar d1gelijk hebben het minst van belang is: een routeringsantwoord met een waarschijnlijkheid van 0,98, gevolgd door een 502 van het model waarnaar je hebt gerouteerd, is hoe dan ook een mislukte aanvraag.

Wij hosten geen enkel Liquid AI-model — we hebben onze eigen catalogus nagekeken voordat we dit schreven — dus niets hier is een bewering over het aanroepen van deze gewichten via ons. Wat wij doen, is de laag aan de andere kant van de beslissing: één OpenAI-compatibele sleutel voor de modellen waar een getriageerd verzoek naartoe uitwaaiert, tegen de lijstprijs van elke aanbieder, doorgegeven met 0% opslag, zodat een prijsverlaging van een leverancier je bereikt op de dag dat ze ingaat en niet bij contractvernieuwing, met automatische failover tussen aanbieders zodat een getriageerd verzoek het overleeft wanneer het model waar je het naartoe hebt gerouteerd uitvalt. Als je voor het eerst een beslissingsmodel in een pipeline aansluit, is dat het deel dat je saai wilt maken.

Welke naam te gebruiken, per situatie

Als je het model deze week wilt uitproberen zonder een Python-omgeving die het onderhoud waard is, gebruik dan de naam die de lokale runtime gebruikt. Haal Liquid AI d1 uit de bibliotheek, accepteer Q8_0 en 3,7 GB, en beschouw het maximum van 64 KiB per verzoek en de no-streamingregel als ontwerpbeperkingen in plaats van ergernissen. Je krijgt op dag één een echt endpoint, echte getypeerde antwoorden en geen meter per aanroep.

Als je een kleinere voetafdruk nodig hebt dan Q8_0, is de naam die je moet gebruiken Liquid AI d1-3B, want de Q4_K_M-build van 1,67 GB staat in de GGUF-repository van de leverancier en niet in de bibliotheekvermelding. Dat enkele feit is vandaag het meest praktische verschil tussen de twee namen, en het is het punt dat het vaakst over het hoofd wordt gezien door iedereen die de bibliotheekpagina leest en daar stopt.

Als je dit aan betalende gebruikers voorlegt en eerst bewijs van nauwkeurigheid nodig hebt, helpt geen van beide namen je vooralsnog. Er is, voor zover wij konden vinden, geen onafhankelijke evaluatie van enig d1-model, de rijen van de Decision Index waren zelf gescoord, en de leverancier heeft helemaal geen audio-beslissingsbenchmark gepubliceerd. Wat je kunt doen, is de confidencewaarde instrumenteren die het model al retourneert — 0 tot 1, die weergeeft hoe sterk de waarschijnlijkheden één antwoord begunstigen, in plaats van hoe waarschijnlijk het is dat dat antwoord juist is — en op je eigen verkeer uitzoeken waar het ding onzeker is. Die meting is meer waard dan welke van de bovenstaande slides dan ook, en het kost een dag.

Het beslissingsmodel is de goedkope helft van de pijplijn. Het generatieve model waarnaar het routeert, is de helft die een contract nodig heeft — één OpenAI-compatibele sleutel draagt de modellen waarnaar een getriageerd verzoek uitwaaiert, elk tegen de lijstprijs van zijn provider, doorberekend met 0% opslag.

Het verkleinen van een gedistilleerd checkpoint ten opzichte van de eigen volledige release is ook een goed moment om het dossier na te kijken: de gedocumenteerde AI-incidenten en agentfouten rond kleine Liquid-modellen staan verzameld in het OrcaRouter AI Incident Archive, waar elk item zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistingsmarkering bevat.