Liquid AI d1 vs Liquid AI d1-omni-600M: Het open beslissingsmodel dat je kan horen

Zoek naar de naam Liquid AI d1 en je komt uit bij een model met drie miljard parameters dat tekst en afbeeldingen leest. Het andere open checkpoint in dezelfde familie is een vijfde zo groot, verwerkt tot dertig seconden spraak en is van de twee het enige dat überhaupt iets over een stem kan beslissen. Het heet Liquid AI d1-omni-600M, en als je de familie via een lokale runtime-bibliotheek hebt gevonden in plaats van via de eigen documentatie van de leverancier, is de kans behoorlijk groot dat je de naam ervan nooit hebt gezien. Dat is de situatie die deze vergelijking wil rechtzetten, want de twee modellen zijn geen concurrerende antwoorden op dezelfde vraag. Het zijn antwoorden op twee verschillende vragen, en slechts bij één daarvan komt luisteren kijken.

Elk cijfer hieronder is afkomstig uit het eigen materiaal van Liquid AI: de LiquidAI/d1-omni-600M-modelkaart, de bijbehorende d1-omni-600M-GGUF-repository, en de releasepost van 7 oktober waarin beide open checkpoints tegelijk werden aangekondigd. De prestatierijen werden door de leverancier gescoord op een index die zij zelf onderhoudt, in plaats van te worden ingediend voor een openbare ranglijst, en de post zegt ronduit dat specifieke benchmarks voor audiobeslissingen een open probleem zijn. Niets hiervan is door iemand buiten het lab gereproduceerd.

Waar 587 miljoen parameters uit bestaan

Het getal in de kop verbergt een ongebruikelijke splitsing. Het totale aantal parameters komt uit op 587M, en ze vormen niet één stack: een gedeelde trunk van 381M met de decision head eraan vast, een vision-encoder van 94M en een audio-encoder van 112M. Elke modaliteit loopt door dezelfde trunkgewichten, en dat is de ontwerpbeslissing die het geheel klein houdt — het model bestaat niet uit drie modellen in een trenchcoat, het is één beslissende trunk met twee manieren om die te voeden.

De onderdelen komen van verschillende plekken in de catalogus van Liquid. De trunk stamt af van LFM2.5-Encoder-350M, een bidirectionele encoder, en niet van de decoder-only-lijn waaruit het grotere broertje afkomstig is. De visietoren is een SigLIP2 die uit LFM2.5-VL-450M is gehaald, met een adapter en LoRA-updates toegepast op de backbone. Het audiopad is een FastConformer-encoder met 17 lagen en een eigen adapter, fine-tuned tegen een bevroren tekstbackbone. De modelkaart meldt een context van 16.384 tokens die over tekst-, beeld- en audioposities samen wordt gedeeld, waarbij tekst wordt teruggebracht tot 896 tokens wanneer er afbeeldingen aanwezig zijn, en een vocabulaire van 65.536 tokens — de helft van de 128.000 van zijn grotere broertje. Dat laatste cijfer is de moeite waard om op te merken als je werkt in een taal die de familie slechts gedeeltelijk dekt.

Bidirectioneel versus alleen-decoder is de reden dat de twee modellen anders aanvoelen voor iedereen die beide heeft gebruikt. De encoderachtige trunk leest de volledige toestand in één keer, in beide richtingen, voordat er iets wordt geproduceerd. De decoderachtige leest vooruit, zoals een taalmodel doet. Beide zijn getraind om antwoorden te melden op basis van een distributie met nul outputtokens, dus geen van beide schrijft tekst — maar de machinerie eronder is een andere klasse van model, en de nauwkeurigheidskloof die hieronder wordt besproken is de zichtbare prijs van het kleinere, encoderachtige ontwerp.

Dertig seconden spraak, en niets om het mee te beoordelen.

Audio is de reden dat dit checkpoint bestaat. Het accepteert één clip van maximaal 30 seconden, 16 kHz mono, in dezelfde forward pass die het antwoord produceert, en het is het enige open-weight lid van de familie dat dat kan. Voor on-device werk is dat geen marginale functie. Een camera die een defect op een productielijn markeert, is een vision-probleem dat de grotere broer al aankan; een apparaat dat een gesproken verzoek routeert, een uiting classificeert of beslist of een beller om een terugbetaling vraagt, is een probleem waar alleen dit model op gericht kan worden.

Op die capaciteit rusten twee beperkingen, en beide zijn gedocumenteerd, wat betekent dat er geen excuus is om er in productie over te struikelen. Ten eerste bevat één verzoek afbeeldingen of audio, nooit beide — beide doorgeven leidt tot een ValueError in plaats van er stilletjes één te laten vallen, dus de fout is luid en goedkoop te vinden tijdens het testen. Ten tweede is het audiopad getraind op uitwisselingen tussen een Engelstalige spreker en een assistent, waarbij de clips op 30 seconden zijn afgekapt. Dat is één sprekergeometrie, één beurtstructuur en één accentverdeling. Het richten op callcenteropnamen of veldaudio is vragen om gedrag dat de kaart niet claimt, en het is precies het soort gat dat een benchmark zou blootleggen als die bestond.

Er bestaat geen enkele. In de releasepost wordt een specifieke benchmark voor audiobesluitvorming "momenteel een open probleem" genoemd en wordt de community uitgenodigd er een te bouwen. Dat is een openhartige uitspraak voor een lab om op te schrijven, en een echte beperking voor iedereen die het model evalueert. Liquid AI d1-omni-600M wordt gevraagd zich te verantwoorden op basis van een capaciteit die nog niemand kan meten. De leverancier hield ook de inferentiecijfers volledig achter, met als opgegeven reden dat het model een vroege onderzoeksrelease is die nog volop in ontwikkeling is. Er is dus helemaal geen latentiecijfer voor de 600M — niet voor tekst, niet voor visie, en niet voor het audiopad dat juist het hele punt is.

Wat zonder iets te verzinnen gezegd kan worden, is een rekensom op basis van het gepubliceerde aantal parameters: bij de float16-precisie die de modelkaart voor GPU's aanbeveelt, is 587M parameters in de orde van 1,2 GB aan gewichten vóór activaties, tegenover ongeveer 6,2 GB voor het 3,12B-zusmodel bij dezelfde precisie. De modelkaart bevat ook een precisiewaarschuwing die je gemakkelijk over het hoofd ziet, maar dat zou je niet moeten doen: het model is getraind in float32, float16 wordt aanbevolen op GPU's, en bfloat16 veranderde tijdens het testen het beste antwoord op sommige rijen. Als je servingstack standaard op bfloat16 staat, is dit een model waarbij die standaard niet veilig is.

Waarom de kleinere helft van de familie makkelijk te missen is

De reden dat een lezer bij de 3B aankomt en stopt, is structureel en niet toevallig. De documentatie-index van Liquid AI vermeldt drie rijen onder beslissingsmodellen, en die lezen niet hetzelfde: d1-3B en d1-omni-600M hebben Hugging Face- en GGUF-links met een "Nee" in de trainbare kolom, terwijl d1 in een eigen rij staat met de kale letters "API" waar bij elk ander model de downloadlinks zouden staan. In het releasebericht wordt d1 een familienaam genoemd en wordt het geserveerde endpoint nooit onderscheiden van het open checkpoint. Lokale runtime-bibliotheken nemen dan de 3B, omdat dat de enige is waarvan de grootte en het aantal modaliteiten overeenkomen met het item dat ze willen publiceren, en de 600M komt helemaal niet in dezelfde lijst voor.

Het resultaat is een familie waarvan het gepubliceerde verhaal over toegang, snel gelezen, eruitziet als één model en één API-regel. Wat feitelijk wordt aangeboden, zijn twee open checkpoints met verschillende trunks, verschillende modaliteiten en een verschil van 32 punten tussen hun scores op de eigen index van de leverancier, plus een gehost endpoint waarvan de leverancier de relatie met een van beide checkpoints nooit heeft bevestigd. De 600M is niet achter iets verborgen. Het heeft simpelweg geen naam die een zoekopdracht naar d1 naar boven haalt, en het is de enige van de twee die hoort.

De scores die bestaan, en de enige kolom die het lezen waard is

Op Decision Index 0.2.1 rapporteert de leverancier 15,95 voor Liquid AI d1-omni-600M tegenover 48,57 voor zijn grotere broer — een verschil dat groot genoeg is dat het totaal bijna nutteloos is als basis voor een keuze. De subscores zijn informatiever dan de som, en een ervan is echt verrassend.

• Kennis — 8,3 tegen 23,8

• Taal — 12,9 tegen 56,4

• Ophalen — 35,0 tegen 52,8

• Hulpmiddelen — 15,1 tegen 74,5

• Kunsten — 6,8 tegen 36,3

Retrieval is waar het kleine model zich staande houdt: het verliest minder dan een derde van de score van het grotere model, terwijl het in de andere vier kolommen 60 tot 80 procent verliest. Dat patroon komt overeen met waar een getrainde encoder goed in zou moeten zijn: het matchen van een state tegen content ligt dicht bij waarvoor de trunk is gebouwd, en het is veel minder afhankelijk van de gelaagde taalvaardigheid die het decoder-vormige broertje heeft geërfd van veel meer pretraining. De kolom Tools vertelt het tegenovergestelde verhaal, en een verschil van 59 punten is daar het getal om naar te staren als je workload het routeren van een verzoek naar de juiste functie is.

Op zeven openbare tekstbenchmarks wordt het beeld zachter. De leverancier meldt een gemiddelde van 78,4 voor de 600M tegen 82,9 voor de 3B, waarbij het kleine model nipt verliest op SQuAD 2.0 (74,0 tegen 85,3), PubMedQA (61,3 tegen 66,0), BoolQ (77,7 tegen 86,7) en XNLI (74,7 tegen 85,0), terwijl het wint op toxiciteitsdetectie met Civil Comments (95,8 tegen 93,0) en parafrase-identificatie met PAWS-X (79,5 tegen 76,9). Liquid's eigen framing is dat de 600M het gemiddelde van 77,1 van een 2B-beslismodel verslaat met een kwart van de parameters. Twee benchmarksuites geven twee verschillende ogenschijnlijke verdicts, beide zelfgerapporteerd, en de eerlijke lezing is dat geen van beide iets beslecht over het audiopad, omdat het audiopad in geen van beide suites zit.

Waar de twee elkaar daadwerkelijk ontmoeten

Ondanks alle verschillen is het programmeermodel identiek, en dat is wat ze in één specifiek opzicht uitwisselbaar maakt. Beide beantwoorden noul-, keuze- en scorevragen over een toestand, beide retourneren het gekozen antwoord met een waarschijnlijkheidskaart en een betrouwbaarheidswaarde tussen 0 en 1, en beide rapporteren output_tokens: 0. Het veld confidence is het veld dat mensen verkeerd lezen: het meet hoe sterk de waarschijnlijkheden één antwoord begunstigen, niet de kans dat het antwoord juist is. Een 0,96 bij een slecht gestelde vraag is een zelfverzekerd fout antwoord, en het veld zal je niet waarschuwen.

Waar ze in de praktijk samenkomen, is een cascade. Screen met Liquid AI d1-omni-600M — goedkoop, lokaal, en inclusief de audiogevallen die geen enkele op tekst gerichte scorer kan aanpakken — en escaleer vervolgens de items die het dicht bij het midden van zijn schaal plaatst naar het grotere checkpoint voor een scherpere beslissing. De escalatieregels zijn het vertrouwen en de distributie die de 600M al teruggeeft, dus de routeringslogica heeft geen extra model nodig, en bij een workload met een sterke meerderheid aan eenvoudige items bereikt het meeste verkeer nooit de tweede fase. Die compositie werkt omdat beide modellen hetzelfde soort object teruggeven. Twee willekeurige modellen zouden dat niet doen.

Als die cascade ooit als poort dient voor een aanroep naar een generatief model dat je huurt in plaats van zelf te draaien, dan is de laag daaronder waar de bedrading interessant wordt, en dat is ook waar wij in beeld komen. Het routeren van een beslissing door een keten van modellen is precies het soort probleem waarvoor een routeringsregel is bedoeld: OrcaRouter stelt verschillende modellen samen achter één OpenAI-compatibel eindpunt, elk tegen de lijstprijs van de provider, doorgegeven met 0% markup, met automatische failover tussen providers zodat een escalatie die mislukt bij de providerlaag opnieuw wordt geprobeerd via een fallback in plaats van dat het verzoek mislukt. We hosten geen enkel Liquid AI-model — we hebben dit gecontroleerd voordat we dit schreven — dus niets hierboven is een bewering over het aanroepen van deze gewichten via ons. Het punt is dat het beslissingsmodel het goedkope deel van de pijplijn is en het geleende model aan de andere kant het deel is dat uitvalt.

Waar het bestand vandaan komt, als je het vandaag wilt uitvoeren

Voor lokale deployment bevat de eigen GGUF-repository van de leverancier voor de 600M Q8_0 van 407 MB en F16 en BF16 van elk 764 MB, zonder dat er een 4-bit-build wordt vermeld — dus de kleinste officiële download is ongeveer zeven keer kleiner dan de overeenkomstige build van het grotere model en ongeveer even groot als een foto met gemiddelde resolutie. Het voorbeeld op de kaart zelf start een llama.cpp-server met batchflags van 4096 en suggereert ze te verhogen naar 16384 voor langere states, en bevraagt vervolgens dezelfde /v1/systemone-endpoint die het grotere broertje gebruikt.

Het enige wat de lokale route je niet geeft, zijn de cijfers van het audiopad, want die bestaan niet. Als je van plan bent om spraak hiermee te verwerken voor echte gebruikers, is het aan jou om de evaluatie te bouwen: een gelabelde set clips, dezelfde drie vraagtypes, en een gemeten antwoordpercentage per klasse. Dat is geen afwijzing van het model — een 587M-checkpoint dat in één pass over een spraakclip beslist, is een wezenlijk ander instrument dan een tekstclassificator die aan een transcriptiestap is vastgeschroefd, en het verdient een echte test in plaats van een op gevoel gebaseerde.

Als die cascade ooit als poort dient voor een aanroep naar een generatief model dat je huurt in plaats van zelf draait, combineert OrcaRouter meerdere modellen achter één OpenAI-compatibel endpoint , elk tegen de listprijs van zijn provider, doorgegeven met 0% opslag.

Kiezen voor een omni-checkpoint in plaats van het tekst-only exemplaar is ook een goed moment om te kijken naar wat er in deze klasse al is misgegaan: de gedocumenteerde AI-incidenten en agentfouten waarbij kleine multimodale modellen betrokken zijn, zijn verzameld in het OrcaRouter AI Incident Archive, waar elk item zijn eigen bronnen, ernst, vertrouwensgraad en betwistingsmarkering heeft.