d1-omni vs Liquid AI D1 Omni 600M: Två namn, en checkpoint och ett kontextnummer som ingen kan härleda

Liquid AI D1 Omni 600M och d1-omni är inte två modeller, och de är inte heller två checkpoints av samma modell. De är en uppsättning vikter — Liquid AIs multimodala beslutsmodell med 587 miljoner parametrar, byggd på Liquid AI LFM2.5-Encoder-350M och publicerad på Hugging Face den 5 oktober 2026 under reponamnet LiquidAI/d1-omni-600M — med två olika filnamn i två olika kataloger. En av dessa kataloger, leverantörens, berättar vad modellen är. Den andra, Ollamas, berättar vad någon har paketerat in den i och skriver ut tre siffror på kortet som leverantörens dokumentation inte stöder. Det gapet är hela anledningen till att den här jämförelsen är värd att läsa, eftersom paketeringen för en modell så här liten inte är en fotnot — den är skillnaden mellan en text- och bildmodell och modellen som kortet säger att du laddade ner.

Leverantören har inte tillkännagivit något om Ollama-posten, och det finns ingen anteckning från ansvarig utvecklare, ingen changelog-post och ingen readme på Ollama-sidan som förklarar något av det. Så den ärliga ramen för allt nedan är denna: vikterna är offentliga och granskningsbara, paketeringen är offentlig och granskningsbar, och tolkningen av paketeringen som ges här är vår, inte Liquid AIs. När en siffra inte kan spåras till en källa säger den här texten det i stället för att upprepa den.

Vad de två namnen faktiskt är

Liquid AI publicerade modellen på Hugging Face med en skapandetidsstämpel på 5 oktober 2026, två dagar innan den dök upp i leverantörens eget blogginlägg "Open d1: Edge decision models for text, vision, and audio" den 7 oktober. Vikterna är licensierade under Liquid egna villkor för LFM 1.0, taggade d1_omni, system-one, multimodal, vision, audio och decision-model, och har vid skrivande stund fått ungefär 13 900 nedladdningar och 135 gillamarkeringar. Kvantiserade varianter följde enligt eget schema: ett GGUF-förråd den 6 oktober, MLX-byggen för Apple Silicon den 12 oktober.

Ollama-posten är inte något av dessa repositorier. Det är en Ollama-bibliotekssida med namnet d1-omni som bär märket "vision 600m", visar fyra taggar och hade uppdaterats minuter innan detta skrevs – vilket är varför radarn överhuvudtaget fick upp den. Inget i den namnger Liquid AI, LFM2.5-Encoder-350M eller Hugging Face-repositoriet som byten kom från.

Så den praktiska skillnaden är ett filnamn och en distributionsväg, inte en modell. Det som skiljer sig, och det som spelar roll, är den metadata som är inlindad runt byten.

De tre siffrorna på Ollama-kortet, kontrollerade en i taget

Ollamas sida skriver ut en storlek, ett kontextfönster och en indatalista för varje tagg. Alla tre förtjänar en andra titt, eftersom två av dem på den här modellen inte överlever kontakten med källan.

• Kontextfönster — 125K på kortet, 16,384 i varje leverantörskälla. Liquid AIs modellkort anger ett tak på 16,384 token som täcker text-, bild- och ljudpositioner tillsammans, och leverantörens egen dokumentationssida för d1-omni-600M säger "16K tokens". Strängen 125K förekommer inte i någon av dem. Det kan vara en artefakt av den underliggande LFM2.5-Encoder-arkitekturens positionskonfiguration eller av hur Ollama rapporterar en cachegräns, men det är inte en siffra som Liquid AI har publicerat och inte en som den här artikeln kan tillskriva någon. Det som gör avvikelsen mer än pedantisk är nästa siffra nedan.

• Det tillstånd du faktiskt kan skicka är begränsat till 896 tokens på bildvägen. Liquid-kortet säger att när bilder finns med "kapas tillståndet och frågetexten till 896 tokens, enligt träningen". Så en beslutsförfrågan som innehåller ett foto har en textbudget ungefär lika stor som den här meningen, oavsett vilken kontextsiffra som anges på en pull page. Om du dimensionerade en triage-prompt mot 125K och förväntade dig att betala för ett långt tillstånd, skulle du dimensionera mot en siffra som inte beskriver körtiden. Siffran 16,384 är det verkliga taket; siffran 896 är den verkliga arbetsgränsen för den multimodala vägen; 125K är en siffra utan spårbar dokumentation.

• Storlek — 850 MB på kortet, två filer i registret. Ollama-taggen d1-omni:latest motsvarar en 407 MB kvantiserad viktfil med beteckningen Q8_0 plus en 442 MB projektorfil med beteckningen BF16, och 407 + 442 = 849, vilket sidan avrundar till 850 MB. Båda redovisas ärligt; aritmetiken är helt enkelt summan av ett par med blandad precision snarare än en enda fil. Taggen d1-omni:600m-bf16 är den renare: 764 MB BF16-vikter plus samma 442 MB projektor, 1,2 GB på disk, och projektorn är byte-identisk mellan de två taggarna. Värt att notera inför nästa avsnitt, eftersom en projektor som bär sina egna vikter kan flytta det effektiva parameterantalet.

Ytterligare en detalj som är värd att dokumentera snarare än att förklara: runtime-parameterblobben i Ollamas d1-omni-paket är byte för byte samma längd – 18 byte – som den i Ollamas separata d1-paket, som levererar Liquid AI d1-3B med 2,87 GB Q8_0-vikter och en 855 MB-projektor. Två arkitekturer, två parameterantal, två decenniers skillnad i parameterskala mellan dem och samma 18-byte runtime-konfiguration. Det är en paketeringskonstant, inte ett påstående om någon av modellerna.

Vad vikterna själva säger

Skalar man bort förpackningen är modellen ovanligt väl dokumenterad. Liquid AI D1 Omni 600M har totalt 587M parametrar fördelade på tre delar: en delad stam och ett beslutshead på 381M, en visionsencoder på 94M och en ljudencoder på 112M. Stammen är dubbelriktad – detta är en encoder, inte en decoder – och det är samma stam för varje modalitet, med modalitetsspecifika torn påmonterade.

• Vision kommer från ett SigLIP2-torn som ärvts från Liquid AI LFM2.5-VL-450M, med en adapter och LoRA-uppdateringar som endast var aktiva för bildindata medan själva kodaren förblev fryst.

• Ljud kommer från en FastConformer med 17 lager och en egen adapter, finjusterad i ett skede där textryggraden var fryst, därefter finjusterades hela stacken, LoRA slogs samman och vikterna medelvärdesbildades mot den tidigare checkpunkten.

• Ordförrådet omfattar 65 536 token på 15 språk: engelska, tyska, spanska, franska, italienska, nederländska, polska, portugisiska, arabiska, hindi, japanska, ryska, turkiska, vietnamesiska och kinesiska.

• Modaliteter kan inte blandas. En enskild begäran tar text plus bilder, eller text plus upp till 30 sekunder tal – inte båda. Ljud förväntas i 16 kHz mono, mellan 0,5 och 30 sekunder, och tränades på utbyten mellan en engelsktalande person och en assistent, vilket är en verklig begränsning för allt flerspråkigt eller brusigt.

Inget av detta framgår av Ollama-sidan, och utelämnandet får en konsekvens som syns direkt i användningsexemplen. Ollamas kodsnuttar är chattanrop – en modellsträng, en messages-array, ordet "Hello!" – och den underliggande checkpointen kan inte svara på dem. Den är ingen chattmodell och skriver ingen text. Den returnerar typade svar: en ja/nej-sannolikhet, en etikett med en sannolikhet per etikett, eller en position på en ordnad skala, allt avläst direkt från utdatadistributionen utan att några utdatatokens genereras. De publicerade gränssnitten speglar detta: system_one och sannolikheter via Transformers, eller en /v1/systemone-endpoint via llama.cpp 0.7.0 och senare. Ett chattformat anrop mot en beslutsmodell är precis det fel som denna namngivningsklyfta bjuder in till.

Två förbehåll gäller för var och en av dessa siffror

För det första poängsatte Liquid sina egna rader med den officiella poängräknaren i stället för att skicka in dem för offentlig rangordning, och ingen tredje part har återproducerat något d1-omni-600M-resultat – leverantören anger direkt på modellkortet att den inte rapporterar inferenstal för denna checkpoint eftersom det är en tidig forskningsrelease under aktiv utveckling. För det andra motsäger de två rubriksiffrorna varandra: gapet på 32 punkter i indexet och gapet på 4,5 punkter i benchmarkmedelvärdet beskriver samma modell, vilket är anledningen till att delpoängen, inte totalerna, är det användbara läsningen. Retrieval på 35,0 och Tools på 15,1 mot Arts på 6,8 säger vilka jobb denna checkpoint är och inte är redo för. Audio har ingen benchmarkkolumn alls; Liquid kallar dedikerade benchmarktester för audiobeslut ett öppet problem.

Liquid AI D1 Omni 600M ligger också i topp inom sin egen familj i två av de sju: Civil Comments på 95,8 och PAWS-X på 79,5. Det är de två raderna där en 587M-encoder slår 3B-decodern rent ut, och båda har formen av textklassificering snarare än resonemang – vilket passar arkitekturen snarare än motsäger den.

Välj efter vad du vill ha. Om du vill köra den lokalt under Ollama, d1-omni är namnet som fungerar – 850 MB för Q8_0-bygget, 1,2 GB för BF16, samma bildsökväg som Liquid dokumenterar, och ingen av taggarna har någon ljudprojektor. Om du vill ha modellen som leverantören beskriver, Liquid AI D1 Omni 600M är namnet att söka på, och Transformers-vägen via Hugging Face-repositoriet är den där kontextlängd, modalitetslista och parameterantal matchar dokumentationen.

Hur som helst är detta den billiga halvan av en pipeline. Beslutsmodellen klassificerar; något annat måste agera på klassificeringen. Det är gränsen som OrcaRouter ligger på, och den som är värd att formulera exakt: ingen Liquid AI-modell finns i vår katalog, så själva d1-omni-anropet går dit du redan kör det — dessa vikter på din egen hårdvara, eller leverantörens eget API och tredjepartsplattformar för de hostade syskonmodellerna. Vad 200+ modeller bakom en OpenAI-kompatibel nyckel används till är allt nedströms, till varje leverantörs listpris som förs vidare med 0 % påslag, med automatisk failover mellan leverantörer när en triagerad förfrågan skickas ut till en modell som har en dålig dag.

Vad skulle avgöra den öppna frågan

Tre saker skulle stänga den här frågan, och ingen av dem kräver något tillkännagivande från leverantören. Någon som jämförde 850MB Ollama-taggens utdata med Hugging Face-checkpointen på samma indata skulle tala om för oss huruvida paketeringen förändrade svaren. En llama.cpp-commit eller en post i Ollama-ändringsloggen som förklarar kontextsiffran skulle tala om för oss huruvida 125K är ett misstag eller en förmåga som modellkortet inte har hunnit ikapp. Och ett publicerat ljudresultat – vilket ljudresultat som helst – skulle flytta denna checkpoint ut ur den kategori där den för närvarande befinner sig, som är en väldokumenterad modell med ett odokumenterat paketeringslager och en resultattavla som helt och hållet är leverantörens egen.

De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga.