d1-2B vs Liquid AI d1-omni-600M: Wanneer de beslissende input geluid is

Leg een spraakbericht en een gefotografeerde factuur voor deze twee modellen en slechts één ervan kan antwoorden, en dat is niet het model met de betere score. d1-2B leest tekst, JSON, afbeeldingen en video, en kan helemaal geen audio verwerken. Liquid AI d1-omni-600M leest tekst met afbeeldingen of tekst met maximaal 30 seconden spraak, en kan geen audio en afbeeldingen in hetzelfde verzoek verwerken. Die ene asymmetrie bepaalt de meeste echte implementaties voordat een van beide benchmarks wordt geraadpleegd. Wat volgt is toch de eerlijke versie van de vergelijking: waar het 587M-model echt concurrerend is, waar het 1.92B-model nog lang niet vervangbaar is, en het ene pijplijnpatroon dat beide gebruikt zonder te doen alsof ze alternatieven zijn.

De beslissing is een kwestie van modaliteit, niet van score.

Een beslissingsmodel neemt een toestand en een reeks benoemde vragen en geeft per antwoord een waarschijnlijkheid terug, zonder gegenereerde tokens. De toestand is de volledige invoer, en het type van de toestand is de bindende beperking. De kaart van d1-2B vermeldt tekst, JSON, afbeeldingen en video. De kaart van Liquid AI d1-omni-600M vermeldt tekst met afbeeldingen, of tekst met audio — en de code handhaaft de uitsluiting: het doorgeven van zowel een afbeelding als een audioclip aan system_one werpt een ValueError op.

Dus de eerste vraag is niet welk model hoger scoort. Het is of het ding dat je moet beoordelen binnenkomt als pixels, als tekst of als golfvorm. Als het als een golfvorm binnenkomt, is er één antwoord in dit tweetal, en de rest van deze pagina gaat over hoeveel nauwkeurigheid je opgeeft om dat te krijgen.

Wat je voor 587M echt krijgt

De 600M is geen kleine versie van d1-2B. Het is een andere constructie, en het is de moeite waard om het budget uitgesplitst te zien, omdat dat zowel de sterke punten als het plafond ervan verklaart.

• Parameters — 587M totaal: een gedeelde trunk en beslissingshoofd van 381M, een vision-encoder van 94M en een audio-encoder van 112M. Elke modaliteit loopt door dezelfde trunk-gewichten.

• Base — LFM2.5-Encoder-350M, een bidirectionele encoder, met een SigLIP2-visietoren geleend van LFM2.5-VL-450M en een 17-laags FastConformer voor audio.

• Context — 16.384 tokens over tekst-, beeld- en audioposities samen, en een vocabulaire van 65.536 tokens. Het venster van d1-2B is 128K.

• Audio — tot 30 seconden 16 kHz mono spraak per verzoek. De kaart vermeldt expliciet dat de audiotak is getraind op verzoeken tussen een Engelstalige spreker en een assistent, wat een smalle distributie is voor een model dat men op opnamen van telefoongesprekken zal loslaten.

• Mediaregel — afbeeldingen of audio, nooit beide. De kaart documenteert de ValueError in plaats van je het zelf te laten ontdekken.

• Licentie — LFM Open License v1.0, dezelfde drempelstructuur als d1-2B: commercieel gebruik onder $10.000.000 jaarlijkse omzet.

• Snelheid — niet gepubliceerd. De kaart vermeldt geen latentiecijfers en noemt het model een vroege onderzoeksrelease die nog actief wordt ontwikkeld. d1-2B publiceert 5,7 ms op een H100 PCIe, 3,8 ms op een MI325X en 18,6 ms op een M5 Pro.

De tabel voor dezelfde run, en de rijen waar het verschil klein is

Beide modellen staan in de benchmarktabel op de kaart van d1-2B, die vier open d1-modellen op identieke items met een identieke scorer beoordeelt. Dat maakt de vergelijking schoner dan de meeste vergelijkingen tussen kaarten, met één voorbehoud: de eigen kaart van d1-omni-600M vermeldt 15,95 op Decision Index 0.2.1, terwijl deze tabel 18,3 op versie 0.3 vermeldt. Het verschil is de editie van de index, en beide getallen zijn correct voor hun eigen test.

• Decision Index public suite v0.3 — 51,1 voor d1-2B versus 18,3 voor Liquid AI d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 77,1 vs 58,7.

• Decision Bench (decisionbench.ai) v4 — 85,2 vs. 57,9.

• ImajevBench v2.0-lite — 75,5 vs 21,7, de grootste kloof aan de beslissingszijde tussen de twee.

• WorkflowEvals — 81,6 vs 48,8.

• Vision-gemiddelde, 18 benchmarks — 70,2 vs. 42,8.

• VisualWebBench — 96,2 vs 14,9, wat minder een vergelijking is dan een uitspraak over hoeveel een vision-encoder van 94M kan dragen.

Dan de rijen die pleiten voor terughoudendheid. Typed Decisions is 61,3 tegen 57,5 — een verschil van 3,8 punten voor een model met een derde van de parameters. POPE, de benchmark voor objecthallucinatie, is 88,7 tegen 82,7. JevBench is 77,9 tegen 58,0, een groot verschil, maar DecisionBench v4 is 85,2 tegen 57,9, en samen geven de twee aan dat de 600M ongelijkmatig is in plaats van uniform zwak. Het eigen lanceringsbericht van Liquid AI zet het gemiddelde over zeven benchmarks op 78,4, wat hoog is voor 587M; de kaart van d1-2B publiceert geen vergelijkbaar gemiddelde, dus de twee cijfers moeten niet naast elkaar worden gezet.

Het enige cijfer dat geen van beide modellen flatteert, is het onafhankelijke. Efraín Garay draaide Liquid AI d1-omni-600M op een steekproef van 6.000 aanvragen uit Decision Index 0.3 en kreeg 14,0, tegenover de eigen 14,17 van de leverancier op dezelfde steekproef — een nauwkeurige reproductie. Hij ontdekte ook dat 1.758 aanvragen het instructie- en optiebudget van het model overschreden en werden geweigerd, als fout geteld, wat een reële kost is van een 16K-venster in een suite die is gebouwd voor langere toestanden.

Waar de 600M de enige optie is

Audiorouting is het geval waarvoor het model is gebouwd, en de voorbeelden op de kaart zijn concreet: routering van oproepen en spraakberichten, geluidsgebeurtenissen, gesproken instructies over een geschreven status. Niets daarvan is bij enige nauwkeurigheid beschikbaar vanuit d1-2B, omdat het geen audio-encoder heeft en geen audioposities in zijn invoerschema.

Twee onafhankelijke datapunten zouden de verkooppraat moeten temperen. Het eerste is de bovenstaande evaluatie, waarin de 600M een AUC van 0,580 voor schotdetectie en een AUC van 0,593 voor regenvoorspelling behaalde op taken met echte data — nauwelijks boven kans, en achter elk getest groter model. Het tweede is een praktijkreview die minder dan 2GB VRAM-gebruik mat en vaststelde dat het model voordracht en toon in audio veel betrouwbaarder classificeerde dan semantische betekenis, waarbij vragen in inferentiestijl dicht bij een muntworp lagen. Beide wijzen dezelfde kant op: dit is een screeningsmodel. Het is goed in "wat voor soort ding is dit", en het is geen vervanging voor een model dat begrijpt wat er gezegd is.

Dat is geen kritiek op een 587M-checkpoint. Het is wat je met 587M krijgt wanneer 381M daarvan gedeelde trunk is. De reden om het te gebruiken is kosten en voetafdruk — minder dan 2GB VRAM, een GGUF-repository sinds 6 oktober, MLX-builds sinds 12 oktober, en een beslissing in één forward pass — niet getrouwheid.

Een cascade die beide gebruikt

De fout is om deze als concurrenten te behandelen. Het zijn twee fasen van hetzelfde filter, en de natuurlijke pipeline laat het goedkope model eerst draaien.

Fase één: Liquid AI d1-omni-600M neemt het binnenkomende item — een spraaknotitie, een supportgesprek, een schriftelijke klacht met een bijlage — en beantwoordt grove vragen. Is dit een factureringsprobleem of een technisch probleem? Is de beller boos? Bevat dit bericht überhaupt een verzoek? Met minder dan 2 GB en één pass is dat goedkoop genoeg om op elk item uit te voeren.

Fase twee: alles wat de 600M dicht bij het midden van zijn schaal plaatst, of alles wat binnenkomt met een afbeelding die gelezen moet worden, gaat naar d1-2B. De 2B krijgt een venster van 128K, video-invoer en ongeveer drie keer het vision-gemiddelde, en ziet alleen het deel van het verkeer dat de eerste fase niet kon afhandelen.

Het werk zit in de drempelwaarden. Beide kaarten geven kansen terug, en beide zeggen dat je op je eigen data moet kalibreren — de kaart van d1-2B zegt dat letterlijk. Een cascade met een ongekalibreerde middelste band escaleert óf alles, en dan was de 600M decoratie, óf niets, en dan corrigeert de 2B nooit de fase die niet kan lezen.

In de meeste echte systemen is er een derde fase: het model dat het antwoord schrijft. Daar komt een gehoste API in beeld, en daar is OrcaRouter relevant. Geen van beide Liquid AI-modellen wordt door ons geserveerd, dus de beslisnodes blijven op je eigen GPU; de generatieve stap die hun labels verbruikt, kan komen van één OpenAI-compatibele sleutel voor meer dan 200 modellen, met 0% opslag op de lijstprijzen van providers en automatische failover als een provider midden in het verkeer wegvalt. De routing-DSL is ook de eerlijke manier om de cascade zelf uit te drukken — de twee beslismodellen als stappen aan de GPU-kant, de antwoordgeneratie als een gehoste stap, samengesteld in plaats van aan elkaar gelijmd in applicatiecode.

Wat geen van beide modellen doet, en de derde optie

Geen van beide schrijft tekst. Beide retourneren getypeerde antwoorden en waarschijnlijkheden met nul uitvoertokens; als de volgende stap proza nodig heeft, is dat een ander model. Geen van beide verwerkt video met audio: d1-2B neemt videoframes maar geen geluid, de 600M neemt geluid maar niet samen met afbeeldingen, en het maximum van 30 seconden audio is een harde limiet, geen aanbeveling.

Als de eis echt is ‘audio en afbeeldingen in hetzelfde verzoek’, is het antwoord geen van beide — het is d1-Omni-2B, het 2,17B-zustermodel dat Liquid AI vierentwintig seconden na d1-2B creëerde en dat tekst, afbeeldingen, videoframes en audioclips in één medialijst accepteert. De score op de Decision Index is 49,0 in dezelfde v0.3-tabel, het visioengemiddelde is 67,7, en het heeft hetzelfde gebrek aan onafhankelijke tests als d1-2B. Het kost ongeveer vier keer de parameters van de 600M, en dat is de prijs van het niet hoeven kiezen tussen modaliteiten.

Dus de regel is kort. Als de toestand spraak bevat en er verder niets hoeft te worden bekeken, is Liquid AI d1-omni-600M het enige lid van dit paar dat kan draaien, en het moet als een scherm worden behandeld. Als de toestand tekst, afbeeldingen of video is en het antwoord stand moet houden, is d1-2B het model — en dat is degene met een gepubliceerde latentiewaarde, een venster van 128K en een voorsprong in benchmarks die standhoudt wanneer je die rij voor rij leest. Als de toestand beide bevat, is geen van beide het antwoord, en het 2.17B omni-model is dat wel.