Liquid AI d1-omni-600M vs Liquid AI d1-3B: Welke helft van de d1-familie heb je eigenlijk echt nodig?

Liquid AI d1-omni-600M en Liquid AI d1-3B werden op 5 oktober 2026 binnen acht uur na elkaar geüpload naar Hugging Face en samen uitgebracht in dezelfde aankondiging van 7 oktober, waardoor de gebruikelijke vraag — welke is nieuwer, welke is beter — de verkeerde is. Het zijn de twee uiteinden van een bewuste ruil. Liquid AI d1-3B is het afgewerkte product: 3,12 miljard parameters, een 48,57 op de door de leverancier gescoorde Decision Index 0.2.1, benchmarktabellen, latentie gemeten tot op een Jetson Orin Nano, en een plek die in het releasebericht wordt beschreven als de hoogste beslissingskwaliteit in zijn klasse. Liquid AI d1-omni-600M is het experiment: 587 miljoen parameters, een 15,95 op dezelfde index, audio-invoer die de 3B niet heeft, en een modelkaart die ronduit zegt dat het om een vroege onderzoeksrelease gaat zonder inferentienummers, omdat er nog actief aan wordt ontwikkeld. Kiezen tussen de twee is geen kwaliteitsbeslissing. Het is een beslissing over of je de extra modaliteiten onderaan de familie nodig hebt of de extra nauwkeurigheid bovenaan, en de cijfers scharen zich achter die splitsing in plaats van haar te vertroebelen.

Alles hieronder is afkomstig uit de twee modelkaarten en de releasepost van 7 oktober, waarbij de eigen etikettering van de releasepost wordt gerespecteerd: de d1-rijen op de Decision Index zijn door Liquid AI gescoord met de officiële scorer in plaats van te zijn ingediend bij de openbare leaderboard, en niets hiervan is onafhankelijk gereproduceerd.

Twee backbones die nooit zouden convergeren

De d1-familie heeft geen enkel recept naar beneden geschaald. De twee checkpoints beginnen aan tegenovergestelde uiteinden van Liquid's modelcatalogus en ontmoeten elkaar in het midden.

Liquid AI d1-3B is gebouwd bovenop LFM2.5-VL-3B, het decoder-only vision-languagemodel van de leverancier uit augustus 2026. De basis ervan is gemaakt door de gewichten van LFM2.5-2.6B te middelen met de tekst-backbone van LFM2.5-VL-3B, en vervolgens checkpoints te fine-tunen onder verschillende random seeds en datamengsels, alvorens ze opnieuw samen te voegen. Het heeft een SigLIP2 NaFlex-vormgeoptimaliseerde 400M vision-encoder, een context van 32.768 tokens, een vocabulaire van 128.000 tokens en zestien gedocumenteerde talen.

Liquid AI d1-omni-600M komt uit de andere richting. De trunk is LFM2.5-Encoder-350M, een bidirectionele encoder, eerst fijn afgestemd op beslissingstaken en daarna in fasen uitgebreid — een FastConformer-encoder met 17 lagen plus adapter voor audio, waarbij de audio-encoder later werd fijn afgestemd met een bevroren tekst-backbone, vervolgens een SigLIP2-toren die uit LFM2.5-VL-450M is overgenomen met een adapter en LoRA-updates aan de backbone voor vision. Het uiteindelijke model werd samengevoegd uit de LoRA-updates en gemiddeld met het vorige checkpoint. Het komt uit op in totaal 587M parameters: een gedeelde trunk en beslissingshoofd van 381M, een vision-encoder van 94M en een audio-encoder van 112M.

Decoder-only versus bidirectioneel is het punt om aan vast te houden. De 3B leest een toestand en produceert een beslissing zoals een taalmodel een tokenreeks produceert: één richting per keer. De 600M leest de volledige toestand in één keer en beslist, wat je zou verwachten van een encoder die nooit bedoeld was om te genereren. Beide zijn getraind om antwoorden te rapporteren op basis van de distributie van het model, met nul outputtokens, maar de machinerie eronder is niet dezelfde klasse van model, en de nauwkeurigheidskloof hieronder is de zichtbare prijs van het kleinere, encoder-vormige ontwerp.

De spread van de Decision Index is groot, en de subscores zijn interessanter dan het totaal.

Op Decision Index 0.2.1 rapporteert Liquid 48,57 voor Liquid AI d1-3B en 15,95 voor Liquid AI d1-omni-600M, tegenover 50,02 voor Winnow-12B. Dat is een gat van 32 punten tussen twee checkpoints die dezelfde dag door hetzelfde lab zijn uitgebracht, en het lezen van de vijf subscores verklaart waar dat vandaan komt.

• Kennis — 23,8 voor Liquid AI d1-3B tegenover 8,3 voor Liquid AI d1-omni-600M

• Taal — 56,4 tegen 12,9

• Ophalen — 52,8 tegen 35,0

• Hulpmiddelen — 74,5 tegen 15,1

• Kunsten — 36,3 tegen 6,8

Retrieval is de enige plek waar het kleine model standhoudt, met een verlies van minder dan een derde van de score van de 3B, terwijl het bij de andere vier categorieën 60 tot 80 procent verliest. Dat patroon komt overeen met wat de 600M is: een getrainde encoder met echte representatiecapaciteit voor het matchen van een toestand aan inhoud, en veel minder van de gelaagde capaciteit die de 3B erft van een decoder die op veel meer taal is voorgetraind. Als je workload een retrieval-achtige beslissing is — beantwoordt deze passage deze vraag, welk van deze documenten is relevant — dan is het profiel van de 600M minder slecht dan zijn totaal doet vermoeden. Als je workload een tool-routingbeslissing is, is de kloof van 51 punten in die kolom het getal om naar te staren.

De tekstbenchmarktabel vertelt een milder verhaal dan de index, wat de moeite waard is om te weten voordat een van beide cijfers wordt gebruikt om een punt te maken. Op zeven openbare benchmarks leidt de 3B met een gemiddelde van 82,9 en de 600M bereikt 78,4. De 600M verliest eigenlijk nipt 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), maar wint op Civil Comments-toxiciteitsdetectie (95,8 tegen 93,0) en op PAWS-X-parafrase-identificatie (79,5 tegen 76,9). De eigen framing van Liquid is dat de 600M het gemiddelde van 77,1 van Decider 2B verslaat met een kwart van de parameters. Twee benchmarksuites, twee verschillende ogenschijnlijke oordelen, beide door de leverancier gerapporteerd — dat is wat het bewijs ondersteunt en niets meer.

Wat de 600M heeft dat de 3B niet heeft

De reden om een indexverschil van 32 punten te tolereren, is dat Liquid AI d1-omni-600M iets doet wat Liquid AI d1-3B niet kan, en het is geen verschil in getrouwheid.

• Audio — Liquid AI d1-omni-600M verwerkt via zijn FastConformer-encoder tot 30 seconden spraak per verzoek; Liquid AI d1-3B verwerkt geen spraak.

• Modaliteitsmenging — de 600M accepteert tekst met afbeeldingen of tekst met audio, en gooit een ValueError als beide samen binnenkomen; de 3B accepteert tekst en afbeeldingen

• Contextvenster — 16.384 tokens verdeeld over tekst-, afbeeldings- en audioposities voor de 600M, waarbij tekst wordt teruggebracht tot 896 tokens wanneer er afbeeldingen aanwezig zijn; 32.768 tokens voor de 3B

• Vocabulaire — 65.536 voor de 600M, 128.000 voor de 3B

• Precisie — de 600M-kaart raadt float16 aan op GPU en waarschuwt dat bfloat16 het topantwoord op sommige rijen heeft veranderd; de 3B wordt geleverd met 15 kwantisaties, waaronder een w8a8-build

• Talen — de 600M noemt 16 talen in een andere set dan de 16 van de 3B, en de audio ervan wordt beschreven als getraind op uitwisselingen tussen een Engelstalige spreker en een assistent, wat een smalle selectie is van wat een productie-audiofeed bevat

De audiotrainingsnotitie is makkelijk om overheen te lezen, en dat zou niet zo moeten zijn. Een model dat is getraind op Engelstalige uitwisselingen tussen spreker en assistent heeft één sprekergeometrie, één beurtstructuur en één accentverdeling gezien. Het inzetten ervan op callcenter-audio of veldopnamen is vragen om gedrag dat de kaart niet claimt, en de releasepost is openhartig: er bestaat geen benchmark voor audiobeslissingen om het daaraan te toetsen — Liquid noemt dat "momenteel een open probleem" en nodigt de gemeenschap uit er een te bouwen.

Latentie: de ene broer of zus heeft de tabellen, de andere heeft een voetnoot.

Voor beslissingsmodellen is het interessante getal de end-to-end latency, omdat er geen decoding te timen valt. Liquid publiceert een volledige set voor de 3B en geen voor de 600M.

• Eén vraag — 8 ms op een RTX 4090, 9 ms op een MI325X, 16 ms op een Jetson AGX Thor, 26 ms op een Jetson AGX Orin 64 GB, 50 ms op een Orin Nano, 30 ms op een Apple M5 Pro

• Drie vragen over één state — 21 ms op de RTX 4090 en 20 ms op de AGX Thor, ongeveer 1,3x de kosten van één enkele vraag in plaats van 3x

• Een toestand van 3,4K tokens — 102 ms op de 4090, 220 ms op de Thor, 1.640 ms op de Orin Nano

• Gebundelde doorvoer — 475 beslissingen per seconde op de RTX 4090, 1.106 per seconde op de MI325X

• Een 384px-afbeelding — 17 ms op de 4090, 18 ms op de MI325X

Die cijfers beschrijven alleen Liquid AI d1-3B. Voor Liquid AI d1-omni-600M vermeldt de modelkaart dat er geen inferentiecijfers worden gerapporteerd omdat het model een vroege onderzoeksrelease is die actief wordt ontwikkeld. Het is niet zo dat het kleine model langzamer is — het tegenovergestelde is vrijwel zeker, want een vijfde van de parameters wordt niet langzamer bij dezelfde precisie — het is dat er geen cijfer bestaat, en het citeren van de milliseconden van de 3B voor de 600M zou een verzinsel met een plausibele vorm zijn. Wat zonder iets te verzinnen gezegd kan worden, is dat bij de float16-precisie die de kaart aanbeveelt, 587M parameters in de orde van 1,2 GB aan gewichten ligt vóór activaties, wat rekenwerk is op basis van een gepubliceerd parameteraantal en niet een meting.

De cascade is het echte antwoord voor de meeste workloads.

Omdat beide checkpoints samen zijn uitgebracht en hetzelfde soort object retourneren — een waarschijnlijkheid, een label met een betrouwbaarheid, of een geordende score — werken ze samen op een manier waarop twee willekeurige modellen dat niet doen. De 600M kan screenen en de 3B kan beoordelen. Scoor binnenkomende items met Liquid AI d1-omni-600M, en escaleer de items die het dicht bij het midden van zijn schaal plaatst naar Liquid AI d1-3B voor een scherper oordeel. De escalatieregels zijn de betrouwbaarheid en de verdeling die de 600M al retourneert, dus de routeringslogica heeft geen extra model nodig. Bij een workload met een sterke meerderheid aan eenvoudige items bereikt het meeste verkeer de 3B nooit en wordt het meeste geld nooit uitgegeven.

Dat patroon is ook de reden waarom het de moeite waard is om de twee modellen achter een router te draaien. Via OrcaRouter zouden beide achter één API-sleutel zitten tegen de listprijs van elke provider, doorgegeven met 0% markup, zodat de cascade een routeringsregel is in plaats van een tweede integratie, en een escalatie die op providerniveau mislukt, opnieuw wordt geprobeerd op een fallback in plaats van dat het verzoek mislukt. Automatische failover is hier belangrijker dan bij een uitgekristalliseerd model, omdat een van beide een checkpoint is waarvan de leverancier zelf zegt dat de ontwikkeling nog volop gaande is.

Niets daarvan is een bewering over beschikbaarheid, en het onderscheid is de moeite waard om duidelijk te maken: de open d1-checkpoints staan niet in onze catalogus. De route van de leverancier is om de gewichten te downloaden en ze lokaal te draaien — ondersteuning voor llama.cpp was er vanaf dag één op hardware van Apple, AMD, Qualcomm en NVIDIA — of om ze te bereiken via de eigen API van de leverancier en platforms van derden.

Kiezen, in één keer

Als je tekst en afbeeldingen nodig hebt, en het antwoord moet kloppen, kies dan Liquid AI d1-3B. Het heeft de benchmarks, de latentietabellen, de bredere context, het grotere vocabulaire en de kwantisaties, en het is het lid van het tweetal dat Liquid positioneert als de kwaliteitsleider in zijn grootteklasse.

Als je spraak in het beslissingspad nodig hebt, neem dan Liquid AI d1-omni-600M, want het is de enige open-weight optie in deze familie die überhaupt audio accepteert, en accepteer dat je het op onderbuikgevoel en een demo overneemt totdat iemand een audio-beslissingsbenchmark publiceert of de achtergehouden vision-split.

Als je nog niet weet welke van die jouw workload beschrijft, begin dan met de 3B en instrumenteer het vertrouwen dat hij retourneert. De subscores zijn de aanwijzing: een taak die in de kolommen Tools of Taal zit, zal slecht bediend worden door de 600M, terwijl iets retrieval-achtigs de enige plek is waar de kleine checkpoint dichterbij zit dan zijn totaal suggereert. De familie bestaat zodat je nauwkeurigheid kunt inruilen voor footprint, en de ruil is alleen veilig als je weet welke kolom je taak inneemt.

Via OrcaRouter zitten beide modellen achter één API-sleutel bij een routeringsregel in plaats van een tweede integratie en een escalatie die op de providerlaag mislukt, wordt opnieuw geprobeerd via een fallback in plaats van te mislukken.