Liquid AI d1-omni-600M is nu een Ollama-pull: een 600M-beslissingsmodel dat je kan horen

Liquid AI d1-omni-600M werd op 17 oktober 2026 om 22:32 UTC een Ollama-pakket. Die tijdstempel is geen gok: de registry van Ollama stuurt bij elk manifest een ollama-push-time-header mee, en de vier tags achter de naam d1-omni werden die avond tussen 22:31:25 en 22:32:13 geaccepteerd, ongeveer vier uur voordat dit werd geschreven. Het model zelf is niet nieuw — Liquid AIopen-weighted Liquid AI d1-omni-600M samen met Liquid AI d1-3B op 5 oktober 2026 uit en kondigde beide aan in zijn "Open d1"-post op 7 oktober — maar tot gisteravond waren de enige manieren om de audiogeschikte versie op je eigen hardware te draaien een transformers-omgeving met trust_remote_code=True of een zelf gecompileerde llama.cpp-build. Nu is het ollama pull d1-omni. Niemand kondigde dat aan: niet de blog van Liquid AI, niet Ollama.

De verpakking is het verhaal, en het loont om precies te zijn over welke onderdelen ervan gedocumenteerd zijn. De meest recente blogposts van Liquid AI zijn d1-ultra op 15 oktober en LFM2.5-24B-A2B op 13 oktober, en geen van beide noemt Ollama; de eigen Ollama-deploymentpagina van het lab leert je nog steeds om de GGUF-repositories rechtstreeks vanaf Hugging Face te draaien met ollama run hf.co/LiquidAI/... en noemt nooit een d1-model. De blog van Ollama is even stil — de nieuwste berichten zijn Reflection's Beam op 16 oktober en een Fly.io-integratie op 13 oktober. Wat er in plaats daarvan bestaat, is een registry-item, vier tags, een verifieerbare digest en een bibliotheekpagina waaraan nog werd geschreven terwijl dit artikel werd geschreven: een vroege capture van die pagina gaf "No readme" terug, en een capture veertig minuten later gaf een volledige, door Liquid AI geschreven beschrijving met een benchmarktabel en een licentiesectie. Als je een gedateerde, controleerbare gebeurtenis voor de afgelopen zeven dagen wilt, dan is die header het.

Wat het register daadwerkelijk heeft geaccepteerd

Vier tags verwijzen naar twee images, en dat is het eerste dat je moet begrijpen voordat je gaat pullen. d1-omni:latest, d1-omni:600m en d1-omni:600m-q8_0 zijn hetzelfde manifest — digest 1ba59f63e836 — terwijl d1-omni:600m-bf16 een tweede is, digest c1e95fce6627. Er is geen F16-tag, hoewel de eigen GGUF-repository van de leverancier een F16-trunk publiceert.

• Gewichtslagen (Q8_0-build) — een trunk van 407 MB uit d1-omni-600M-Q8_0.gguf plus een projector van 442 MB uit mmproj-d1-omni-600M-BF16.gguf, met een licentieblob van 10,5 KB en een parametersblob van 18 bytes, goed voor in totaal 849.659.968 bytes.

• Gerapporteerde grootte — 850 MB voor de standaardtag en 1,2 GB voor 600m-bf16, beide zoals weergegeven op de bibliotheekpagina.

• Minimale runtime — vereist: 0.40.4 in de config-blob, die ook model_family: lfm2, model_type: 380.73M en bestandstype Q8_0 vermeldt.

• Context — de parameters-blob legt num_ctx vast op 16.384.

• Licentie — de ingesloten tekst is de LFM Open License v1.0, waarin Liquid AI, Inc. als licentiegever wordt vermeld, overeenkomend met de lfm1.0-identifier op de modelkaart.

Die projector verdient een tweede blik, want hij is groter dan het model waaraan hij is gekoppeld. Als je de GGUF-metadata rechtstreeks uit de registry-blob leest, zie je clip.has_vision_encoder = True en clip.has_audio_encoder = True in hetzelfde bestand: 197 vision-tensors over 12 blokken bij 768-brede embeddings en 256-pixelinputs, en 641 audio-tensors over 17 blokken bij 512-brede embeddings met 128 mel-bins. Dat zijn de SigLIP2-toren en de FastConformer-encoder die beide in de multimodale bundel meereizen, waardoor een trunk met 381M parameters achter een bijlage van 442 MB wordt geleverd. De audiomogelijkheid zit fysiek in het pakket dat je downloadt; de vraag of het endpoint erbij kan komen, komt later.

Het model heeft 587M parameters en de 125K-badge is groter dan de waarheid.

De pagina van Ollama adverteert bij elke tag met een "contextvenster van 125K". De eigen num_ctx van het pakket is 16.384, en de modelkaart van Liquid AI zegt hetzelfde in woorden: 16.384 tokens die samen tekst-, beeld- en audioposities beslaan, waarbij de state- en vraagtekst tot 896 tokens worden teruggebracht zodra er afbeeldingen aanwezig zijn. Het cijfer van 125K is herleidbaar — de trunk-GGUF bevat lfm2.context_length = 128000 — maar het is het plafond van de architectuur, niet het venster dat je krijgt, en het is het getal dat het meest waarschijnlijk iemand misleidt die een vervanging kiest voor een classifier met lange context. Beschouw 16.384 als het werkbare getal, en 896 tokens tekst als het werkbare getal wanneer er een afbeelding in de state zit.

De rest van de metadata bevestigt de modelkaart eerder dan de marketingtekst. De trunk bestaat uit 18 blokken, embeddings met een breedte van 1.024 en een vocabulaire van 65.536, en het is geen decoder: lfm2.attention.causal is False. De KV-headaantallen per laag lezen 0, 0, 8, 0, 0, 8, …, wat betekent dat de meeste van die blokken helemaal geen attention-blokken zijn; dat is de erfenis van de bidirectionele encoder die erdoorheen schemert. De decision-head bestaat uit twee blokken (lfm2.decision.block_count = 2), en de kalibratieconstanten die de leverancier in config.json bewaart, zitten ook in deze GGUF — keuzevragen hebben een temperatuur van 1.7465 bij twee opties, 1.3999 bij drie tot vijf, 1.1751 bij zes tot tien en 1.3725 boven elf; ja/nee is 1.6663; gescoorde vragen zijn 1.7301 bij drie tot vijf niveaus en 1.0 bij zes tot tien. Dat is het hele ontwerp op één plek: een vaste set benoemde antwoorden, in één pass gescoord, gekalibreerd per vraagvorm, met output_tokens: 0 aan het eind.

Het is geen chatmodel en schrijft geen tekst. Liquid AI vermeldt vijftien talen, zet de audiotrainingsdata alleen in het Engels — verzoeken tussen een spreker en een assistent — en beperkt clips tot 30 seconden. De kaart waarschuwt ook tegen bfloat16 op GPU's: bij de eigen controles van de leverancier veranderde het het beste antwoord op 0,8% van de tekstrijen en 1,7% van de audiorijen, waar float16 overal overeenkwam met float32.

Audio zit in de gewichten en ontbreekt in de gedocumenteerde API.

Dit is de discrepantie die je moet kennen voordat je een bug meldt. De readme van de bibliotheekpagina, die Liquid AI heeft geschreven, documenteert audio door een base64-WAV in de images-array van een /v1/systemone-verzoek te zetten. De Hugging Face GGUF-readme van de leverancier voor dezelfde checkpoint documenteert het anders, met een files-array die data:audio/wav;base64,… naar de llama.cpp-server draagt. En de endpointreferentie die Ollama publiceert, documenteert geen van beide: het requestschema ervan heeft state, images, questions en keep_alive, beschrijft images als "Vereist een model met visie, zoals Clef," en bevat helemaal geen audio-veld en geen files-veld. Ollama's eigen gids voor beslissingsmodellen noemt ondertussen Nimble, Tev1, Clef en Clef Flash als de beslissingsmodellen en zegt alleen dat de Clef-modellen ook afbeeldingen kunnen beoordelen.

Dus de eerlijke positie over audio in Ollama vandaag is: de encoder is aantoonbaar aanwezig in de blob, de readme van de leverancier zegt dat het via afbeeldingen werkt, en het gepubliceerde schema laat het niet toe. Afbeeldingsinvoer op hetzelfde model staat op steviger grond — vision is een gedocumenteerde System One-mogelijkheid en d1-omni verschijnt in Ollama's vision-categorieoverzicht. Twee kleinere hiaten in de documentatie staan naast dat ene: de endpoint-referentie staat maximaal 255 optiekeys toe in een keuzevraag, terwijl de beslissingsgids 2 tot 26 zegt, en de runtime-ondergrens van het pakket van 0.40.4 is hoger dan de 0.35.0 die de endpoint-documentatie noemt.

Ingedeeld onder visie, niet onder beslissing.

De modelzoekfunctie van Ollama plaatst beslissingsmodellen in een eigen categorie. Die bevat negen vermeldingen — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya en strands-decider — en noch d1 noch d1-omni staat ertussen. De pagina van d1-omni is getagd met vision en 600m, en het verschijnt in de vision-lijst, dus een lezer die naar "beslissingsmodel" zoekt, vindt het nieuwste model niet. Dat is een vindbaarheidsprobleem in plaats van een capaciteitsprobleem, maar het maakt wel uit als je van plan was de beslissingsfamilies in Ollama's eigen catalogus te vergelijken en concludeerde dat dit model niet bestond.

Wat het ook betekent, is dat d1-omni het eerste beslissingsmodel in Ollama's bibliotheek is dat überhaupt spraak aankan — de audio-encoder zit in het pakket en niets anders in die lijst van negen modellen heeft er een. Of het endpoint je WAV eraan zal doorgeven, is de open vraag uit de bovenstaande sectie, en het is het enige dat het waarschijnlijkst is veranderd tegen de tijd dat je dit leest.

De nummers, en wie ze allemaal heeft geproduceerd.

Elk nauwkeurigheidscijfer dat gekoppeld is aan Liquid AI d1-omni-600M is van Liquid AI, en voor zover wij kunnen vinden bestaat er geen onafhankelijke evaluatie van enig d1-model — geen rij op een leaderboard, geen door derden uitgevoerde run, geen gepubliceerde afwijzing van de scoring door de leverancier. De leverancier heeft beide d1-checkpoints zelf gescoord met de officiële Decision Index-scorer in plaats van ze naar het openbare leaderboard in te dienen, en zegt dat ook op de modelkaart; elke concurrerende rij in de tabel komt uit leaderboard v0.2.1, wat betekent dat de vergelijking een zelfgescoord getal is dat naast extern gescoorde getallen staat.

• Decision Index 0.2.1 — 15,95 voor d1-omni-600M (kennis 8,3, taal 12,9, retrieval 35,0, tools 15,1, kunsten 6,8) tegenover 48,57 voor d1-3B.

• Benchmarks als beslissingen, gemiddelde van zeven — 78,4 voor d1-omni-600M tegenover 82,9 voor d1-3B, waarbij het 600M-model voorloopt op Civil Comments (95,8 vs 93,0) en PAWS-X (79,5 vs 76,9) en achterloopt op BoolQ (77,7 vs 86,7) en SQuAD 2.0 (74,0 vs 85,3).

• Fast Decisions, dev split — 76,9, door de leverancier gerapporteerd, geen vergelijkingsrij gepubliceerd.

• Snelheid — niets. De kaart vermeldt ronduit dat inferentiecijfers niet worden gerapporteerd omdat dit een vroege onderzoeksrelease is die actief wordt ontwikkeld, dus elke latentieclaim die je er elders over ziet, is iemands eigen meting.

• Voorbeeldgetallen op de Ollama-pagina — het uitgewerkte voorbeeld in de readme toont "urgent" beantwoord op 0,998 en "technical" op 0,995. Dat zijn illustratieve outputs van één verzoek, gepubliceerd door de runtime, en het is geen benchmark.

Het gat tussen 15,95 en 48,57 is het nuttigste op de kaart, want het beslecht de aankoopvraag in de eigen woorden van de leverancier: de readme zegt dat je d1 moet gebruiken wanneer nauwkeurigheid bij tekst en afbeeldingen het belangrijkst is, en naar d1-omni moet grijpen wanneer formaat ertoe doet of je audio nodig hebt. Een 587M-model dat 78,4 scoort op zeven openbare benchmarks, omgezet naar beslissingen, is een plausibele edge-classifier. Het is geen kleinere versie van de 3B.

Waar OrcaRouter past, en waar niet

Wij bieden dit model niet aan. Een controle van onze catalogus op 18 oktober leverde 208 model-id's op, en geen ervan is van Liquid AI, dus niets hier is een claim over beschikbaarheid en er is aan onze kant geen route om het op te halen. Als u Liquid AI d1-omni-600M wilt, is het lokale pad het hierboven beschreven pad, en het gehoste pad is de eigen API van de leverancier en de platforms van derden die het oppikken, welke dat ook zijn.

Wat de verpakking verandert, is de vorm van het systeem eromheen, en daar zijn wij nuttig. Een beslissingsmodel is bijna nooit de hele pipeline: het ticket dat het labelt, het frame dat het markeert en het transcript dat het routeert, moeten nog steeds worden beantwoord, samengevat of geëscaleerd door iets dat tekst schrijft. Die generatieve aanroepen zitten achter één OpenAI-compatibele sleutel voor 200+ gehoste modellen tegen de lijstprijs van de provider, doorgegeven met 0% markup, zodat een prijswijziging van een leverancier je dezelfde dag bereikt in plaats van bij een nieuw contract. En omdat d1-omni-600M wordt geleverd zonder onafhankelijk bewijs van nauwkeurigheid en zonder gepubliceerde latentie, is de juiste manier om het voor echt verkeer te zetten achter automatische failover tussen providers — laat het de aanroepen afhandelen waarover het zeker is, en houd een uitwijkroute open wanneer dat niet zo is, in plaats van van 587M parameters een single point of failure te maken voor je triage-stap. De beslissing blijft lokaal; de fallback hoeft dat niet te zijn.

Wat zou deze aflezing veranderen?

Vier dingen, waarvan elk afzonderlijk van een verpakkingsnotitie een ander artikel zou maken. Ollama dat audio documenteert in het System One-aanvraagschema, wat de WAV-in-afbeeldingen-truc uit de readme zou omzetten in een ondersteunde invoer en dit het eerste spraakgeschikte beslissingsmodel zou maken dat je met één commando kunt draaien. Een van beide bedrijven die de overzetting erkennen — Liquid AI dat d1-omni toevoegt aan de Ollama-pagina van zijn deploymentdocumentatie, of Ollama dat het onder beslissingsmodellen vermeldt in plaats van onder vision. Een snelheidscijfer van wie dan ook, leverancier of niet, aangezien er vandaag geen bestaat. En een onafhankelijke Decision Index-rij voor elk d1-model, wat het enige ontbrekende stuk blijft voor de hele familie.

Tot die tijd is de beslissing eenvoudig. Als je Ollama al op 0.40.4 of later draait, is de pull één commando, de download 850 MB, en wat je krijgt is een 587M-classifier die getypte vragen beantwoordt in één forward pass over tekst en afbeeldingen — en, als de readme klopt, over meer dan 30 seconden Engelse spraak. Als je state lang is, houd dan rekening met het venster van 16,384 tokens en het tekstbudget van 896 tokens in plaats van de 125K-badge. En als je bewijs nodig hebt dat het nauwkeurig is voordat het iets labelt dat een klant ziet, dan bestaat dat bewijs nog niet, niet voor dit model en niet voor een van zijn soortgenoten.

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.