d1-omni vs Liquid AI D1 Omni 600M: twee namen, één checkpoint en een contextgetal waarvan niemand de bron kan vinden

Liquid AI D1 Omni 600M en d1-omni zijn geen twee modellen, en het zijn ook geen twee checkpoints van hetzelfde model. Het is één set gewichten — het multimodale beslissingsmodel van Liquid AI met 587M parameters, gebouwd op Liquid AI LFM2.5-Encoder-350M en gepubliceerd op Hugging Face op 5 oktober 2026 onder de repo-naam LiquidAI/d1-omni-600M — met twee verschillende bestandsnamen in twee verschillende catalogi. Een van die catalogi, die van de leverancier, vertelt je wat het model is. De andere, die van Ollama, vertelt je waarin iemand het heeft verpakt, en zet drie getallen op de kaart die de documentatie van de leverancier niet ondersteunt. Dat gat is precies de reden waarom deze vergelijking het lezen waard is, want voor een model dit klein is de verpakking geen voetnoot — het is het verschil tussen een tekst- en beeldmodel en het model waarvan de kaart zegt dat je het hebt gedownload.

De leverancier heeft niets aangekondigd over de Ollama-vermelding, en er is geen notitie van de maintainer, geen changelog-item en geen readme op de Ollama-pagina om ook maar iets daarvan te verklaren. Het eerlijke kader voor alles hieronder is dus dit: de gewichten zijn openbaar en inspecteerbaar, de verpakking is openbaar en inspecteerbaar, en de interpretatie van de verpakking die hier wordt gegeven is van ons, niet van Liquid AI. Waar een getal niet tot een bron kan worden herleid, zegt dit stuk dat, in plaats van het te herhalen.

Wat de twee namen eigenlijk zijn

Liquid AI publiceerde het model op Hugging Face met een aanmaaktijdstempel van 5 oktober 2026, twee dagen voordat het verscheen in de eigen blogpost van de leverancier "Open d1: Edge decision models for text, vision, and audio" op 7 oktober. De weights zijn gelicentieerd onder Liquid's eigen LFM 1.0-voorwaarden, getagd met d1_omni, system-one, multimodal, vision, audio en decision-model, en hebben op het moment van schrijven ongeveer 13.900 downloads en 135 likes verzameld. Gekwantiseerde varianten volgden volgens hun eigen schema: een GGUF-repository op 6 oktober, MLX-builds voor Apple Silicon op 12 oktober.

De Ollama-vermelding is geen van die repositories. Het is een Ollama-bibliotheekpagina genaamd d1-omni die de badge "vision 600m" draagt, vier tags toont en enkele minuten voordat dit werd geschreven was bijgewerkt — wat verklaart waarom de radar het überhaupt heeft opgemerkt. Niets erin vermeldt Liquid AI, LFM2.5-Encoder-350M of de Hugging Face-repository waar de bytes vandaan kwamen.

Het praktische verschil is dus een bestandsnaam en een distributiepad, niet een model. Wat verschilt, en wat ertoe doet, is de metadata die rond de bytes heen zit.

De drie getallen op de Ollama-kaart, één voor één gecontroleerd.

Ollama's pagina toont voor elke tag een grootte, een contextvenster en een invoerlijst. Alle drie verdienen een tweede blik, want bij dit model overleven twee ervan het contact met de bron niet.

• Contextvenster — 125K op de kaart, 16,384 in elke bron van de leverancier.De modelkaart van Liquid AI vermeldt een plafond van 16,384 tokens dat tekst-, beeld- en audioposities samen omvat, en de eigen documentatiepagina van de leverancier voor d1-omni-600M zegt "16K tokens". De string 125K komt in geen van beide voor. Het kan een artefact zijn van de positionele configuratie van de onderliggende LFM2.5-Encoder-architectuur of van de manier waarop Ollama een cachelimiet rapporteert, maar het is geen cijfer dat Liquid AI heeft gepubliceerd en het is er ook geen dat dit artikel aan iemand kan toeschrijven. Wat de discrepantie meer dan muggenzifterij maakt, is het getal dat daar direct onder staat.

• De toestand die je daadwerkelijk kunt doorgeven, is op het afbeeldingspad beperkt tot 896 tokens. In de kaart van Liquid staat dat wanneer er afbeeldingen aanwezig zijn, "de toestand- en vraagtekst wordt teruggebracht tot 896 tokens, zoals getraind". Dus een beslissingsverzoek met een foto heeft een tekstbudget van ongeveer de grootte van deze zin, ongeacht welk contextgetal er op een pull-pagina staat. Als je een triageprompt op 125K zou afstemmen en verwachtte te betalen voor een lange toestand, dan zou je afstemmen op een getal dat de runtime niet beschrijft. Het getal 16.384 is het echte plafond; het getal 896 is de echte werklimiet voor het multimodale pad; de 125K is een getal zonder papieren spoor.

• Grootte — 850MB op de kaart, twee bestanden in het register. De Ollama-tag d1-omni:latest verwijst naar een gekwantiseerd gewichtenbestand van 407MB aangeduid als Q8_0 plus een projectorbestand van 442MB aangeduid als BF16, en 407 + 442 = 849, wat de pagina afrondt op 850MB. Beide worden eerlijk vermeld; de berekening is gewoon de som van een gemengde-precisiecombinatie in plaats van één bestand. De d1-omni:600m-bf16-tag is de overzichtelijkere: 764MB BF16-gewichten plus dezelfde 442MB-projector, 1,2GB op schijf, en de projector is byte-identiek tussen de twee tags. Noemenswaardig voor de volgende sectie, omdat een projector die zijn eigen gewichten bevat, het effectieve aantal parameters kan verschuiven.

Nog een detail dat het waard is om vast te leggen in plaats van uit te leggen: de runtime-parameterblob in Ollama's d1-omni-pakket is byte voor byte even lang — 18 bytes — als die in Ollama's afzonderlijke d1pakket, dat Liquid AI d1-3B meelevert met 2,87 GB aan Q8_0-gewichten en een projector van 855 MB. Twee architecturen, twee parameteraantallen, twee decennia aan parameterschaal tussen beide, en dezelfde runtimeconfiguratie van 18 bytes. Dat is een packagingconstante, geen bewering over een van beide modellen.

Wat de gewichten zelf zeggen

Haal de verpakking eraf en het model blijkt ongewoon goed gedocumenteerd. Liquid AI D1 Omni 600M heeft in totaal 587M parameters, in drie delen opgesplitst: een gedeelde trunk en beslissingshead van 381M, een visie-encoder van 94M en een audio-encoder van 112M. De trunk is bidirectioneel — dit is een encoder, geen decoder — en het is dezelfde trunk voor elke modaliteit, met modaliteitsspecifieke torens eraan vastgeschroefd.

• Visie komt van een SigLIP2-toren die is overgenomen van Liquid AI LFM2.5-VL-450M, met een adapter en LoRA-updates die alleen actief waren voor beeldinvoer, terwijl de encoder zelf bevroren bleef.

• Audio komt van een 17-laagse FastConformer met een eigen adapter, gefinetuned in een fase waarin de tekst-backbone bevroren was, waarna de hele stack werd gefinetuned, de LoRA werd samengevoegd en de gewichten weer werden gemiddeld ten opzichte van de vorige checkpoint.

• De vocabulaires omvatten 65.536 tokens verdeeld over 15 talen: Engels, Duits, Spaans, Frans, Italiaans, Nederlands, Pools, Portugees, Arabisch, Hindi, Japans, Russisch, Turks, Vietnamees en Chinees.

• Modaliteiten kunnen niet worden gemengd. Een afzonderlijk verzoek bevat tekst plus afbeeldingen, of tekst plus maximaal 30 seconden spraak — niet beide. Audio wordt verwacht op 16kHz mono, tussen 0,5 en 30 seconden, en was getraind op uitwisselingen tussen een Engelssprekende en een assistent, wat een echte beperking vormt voor alles wat meertalig of rumoerig is.

Niets daarvan staat op de Ollama-pagina, en die weglating heeft een gevolg dat je rechtstreeks in de gebruiksvoorbeelden kunt zien. De snippets van Ollama zijn chat-aanroepen — een modelstring, een messages-array, het woord "Hello!" — en het onderliggende checkpoint kan ze niet beantwoorden. Het is geen chatmodel en schrijft geen tekst. Het retourneert getypeerde antwoorden: een ja/nee-waarschijnlijkheid, een label met een waarschijnlijkheid per label, of een positie op een geordende schaal, allemaal rechtstreeks uit de outputdistributie gelezen met nul gegenereerde uitvoertokens. De gepubliceerde interfaces weerspiegelen dat: system_one en waarschijnlijkheden via Transformers, of een /v1/systemone-endpoint via llama.cpp 0.7.0 en later. Een chatvormige aanroep tegen een beslissingsmodel is de fout die deze naamgevingskloof uitlokt.

Aan elk van die cijfers kleven twee kanttekeningen.

Ten eerste heeft Liquid de eigen rijen gescoord met de officiële scorer in plaats van ze voor openbare ranking in te dienen, en geen enkele derde partij heeft een d1-omni-600M-resultaat gereproduceerd — de leverancier zegt ronduit op de modelkaart dat er geen inferentiecijfers voor deze checkpoint worden gerapporteerd, omdat het een vroege onderzoeksrelease is die nog actief wordt ontwikkeld. Ten tweede spreken de twee kopcijfers elkaar tegen: de indexkloof van 32 punten en het verschil in benchmarkgemiddelde van 4,5 punt beschrijven hetzelfde model, en daarom zijn de subscores, niet de totalen, de nuttige interpretatie. Retrieval op 35,0 en Tools op 15,1 tegenover Arts op 6,8 vertelt je voor welke taken deze checkpoint wel en niet klaar is. Audio heeft helemaal geen benchmarkkolom; Liquid noemt speciale audio-decisionbenchmarks een open probleem.

Liquid AI D1 Omni 600M voert ook zijn eigen familie aan op twee van de zeven: Civil Comments met 95,8 en PAWS-X met 79,5. Dat zijn de twee rijen waar een 587M-encoder de 3B-decoder ronduit verslaat, en beide zijn eerder op tekstclassificatie dan op redeneren gericht — wat bij de architectuur past in plaats van die tegen te spreken.

Kies op basis van wat je wilt. Als je wilt dat het lokaal onder Ollama draait, d1-omni is de naam die werkt — 850MB voor de Q8_0-build, 1.2GB voor BF16, hetzelfde imagepad dat Liquid documenteert, en geen van beide tags bevat een audioprojector. Als je het model wilt dat de leverancier beschrijft, Liquid AI D1 Omni 600M is de naam om op te zoeken, en de Transformers-route via de Hugging Face-repository is degene waarvan de contextlengte, modaliteitenlijst en het aantal parameters overeenkomen met de documentatie.

Hoe dan ook, dit is de goedkope helft van een pipeline. Het beslissingsmodel classificeert; iets anders moet op de classificatie reageren. Dat is de grens waar OrcaRouter op zit en degene die het waard is om precies te formuleren: geen enkel Liquid AI-model staat in onze catalogus, dus de d1-omni-aanroep zelf gaat naar waar je die al draait — deze weights op je eigen hardware, of de eigen API van de leverancier en third-partyplatforms voor de gehoste varianten. Waar de 200+ modellen achter één OpenAI-compatibele sleutel voor zijn, is alles stroomafwaarts, tegen de lijstprijs van elke provider, doorgegeven met 0% markup, met automatische failover tussen providers wanneer een getrieerde aanvraag uitwaaiert naar een model dat een slechte dag heeft.

Wat zou de open vraag beslechten

Drie dingen zouden dit afronden, en geen ervan vereist een aankondiging van een leverancier. Iemand die de output van de 850MB Ollama-tag vergelijkt met het Hugging Face-checkpoint op dezelfde invoer, zou ons vertellen of de verpakking de antwoorden heeft veranderd. Een llama.cpp-commit of Ollama-changelogvermelding die de contextwaarde verklaart, zou ons vertellen of 125K een fout is of een capaciteit waar de modelkaart nog niet mee is bijgewerkt. En een gepubliceerd audioresultaat — elk audioresultaat — zou dit checkpoint uit de categorie halen die het momenteel bezet: een goed gedocumenteerd model met een ongedocumenteerde verpakkingslaag en een scorebord dat volledig van de leverancier zelf is.

De gedocumenteerde AI-fouten en incidenten met agents achter releases zoals deze worden verzameld in het OrcaRouter AI Incident Archive, waar elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwistingsmarkering bevat.