d1-2B: Liquid AI heeft een beslissingsmodel van 1,9 miljard uitgebracht zonder een bericht om het aan te kondigen.

De Hugging Face-repository voor LiquidAI/d1-2B is op 24 oktober 2026 om 19:30 UTC aangemaakt. Het zusterproject, d1-Omni-2B, verscheen vierentwintig seconden later. Aan het eind van die avond waren beide repo's compleet — 3,84 GB aan BF16-safetensors, zo'n veertig bestanden met aangepaste Transformers-code, een kalibratietabel, een API voor getypeerde vragen — en niets dat Liquid AI publiceerde zei dat een van beide modellen bestond. De eerste zin van de leverancier die d1-2B noemt, verscheen op 27 oktober, binnen de lancering van de LFM3-familie — dezelfde post gepubliceerd op liquid.ai en op de eigen blog van Hugging Face — als één bijzin in een alinea over twee beslissingsmodellen. Sindsdien is er geen aparte post meer geweest. Dit is dus geen lanceringsverhaal, en het als zodanig behandelen zou een marketingmoment verzinnen dat nooit heeft plaatsgevonden. Het is een verhaal over een compleet modelartefact met een onvolledige aankondiging, en over de twee dingen die een lezer daar nog mee kan doen: de repo lezen, en de cijfers van de leverancier op afstand houden tot iemand buiten het lab ze draait.

De vijf dagen tussen de gewichten en de zin

De d1-familie is twee keer uitgebracht, en geen van beide releases leek op deze. Op 7 oktober publiceerde Liquid AI "Open d1: Edge decision models for text, vision, and audio", waarin d1-3B met 3,12B parameters en d1-omni-600M met 587M werden geïntroduceerd, met een hoofdclaim, een benchmarktabel, latentiecijfers en een blogpost die sindsdien online is gebleven. Die post bevat geen 2B-model.

De 2B-lijn liep volgens een ander schema. Het basischeckpoint LFM3-Omni-2B verscheen op 21 oktober. Op 24 oktober, om 19:30 en 19:30:24 UTC, creëerde Liquid AI de repositories d1-2B en d1-Omni-2B. Vervolgens noemde de LFM3-lanceringspost op 27 oktober het paar "beslissingsmodellen gespecialiseerd op basis van de vision- en omni-modellen" — een beschrijving, geen aankondiging. Dezelfde dag verschenen vier afgeleide repo's voor d1-2B: MLX-builds in fp16, 8-bit en 4-bit, plus een ONNX-export. Ook daarover schreef niemand een post.

Dit is om een praktische reden belangrijk. In een aankondiging legt een leverancier zijn positionering vast: waarvoor het model bedoeld is, wat het kost, op welke runtime het is gericht en wat het niet doet. De kaart doet een deel van dat werk, en doet dat uitzonderlijk goed. Maar de hiaten die het ontbrekende bericht achterlaat, zijn reëel en concreet, en ze staan onderaan dit stuk vermeld in plaats van te worden verdoezeld.

Wat de repository je werkelijk zal vertellen

Zet de framing opzij en de checkpoint is een kleine, tot in detail gespecificeerde multimodale classifier die weigert tekst te genereren. Elke aanroep retourneert getypeerde antwoorden met bijgevoegde waarschijnlijkheden en output_tokens: 0. De kaart zegt het ronduit: d1-2B "is geen chatmodel."

• Parameters — 1,92 miljard, geleverd als één 3,84 GB BF16-safetensorsbestand.

• Basis — LFM3-VL-2B, op de LFM3-backbone: 24 lagen, waarvan 13 gegate korte convoluties, 5 sliding-window-attentie en 6 globale aandacht.

• Context — 128K tokens en een vocabulaire van 128.000 tokens, vier keer het venster van d1-3B's 32.768.

• Invoer — een toestand die tekst of elke JSON-waarde kan zijn, afbeeldingen of een video, en een willekeurig aantal benoemde vragen, allemaal in één medialijst. Video is de mogelijkheid die d1-3B niet vermeldt.

• Uitvoer — ja/nee, een keuze uit benoemde opties, een geordende score, een waarde of datum uit een document met de bijbehorende span, een getal met een p10–p90-interval, een bounding box, of elk exemplaar van een object met een telling. Elk daarvan heeft een waarschijnlijkheid.

• Talen — zestien: Engels, Arabisch, Chinees, Frans, Duits, Italiaans, Japans, Koreaans, Portugees, Spaans, Vietnamees, Thais, Indonesisch, Hindi, Russisch, Pools.

• Licentie — LFM Open License v1.0. Commercieel gebruik is toegestaan onder een jaarlijkse omzet van $10.000.000; de licentietekst definieert dat bedrag als drempel, en rechten voor commercieel gebruik daarboven zijn afhankelijk van het niet overschrijden ervan.

• Snelheid — 5,7 ms voor één enkele beslissing op een H100 PCIe en 3,8 ms op een AMD MI325X, met respectievelijk 1.132 en 1.699 beslissingen per seconde wanneer 64 toestanden in één aanroep worden gebundeld. Op een Apple M5 Pro bedraagt de waarde voor één enkele vraag 18,6 ms.

De bewering die de moeite van het bediscussiëren waard is: het verslaat het model dat het heeft vervangen.

De modelkaart van Liquid AI doet één vergelijkende bewering zonder voorbehoud: d1-2B "leidt gemiddeld onder de open d1-modellen en op ons bord van meer dan honderd beslissingsbenchmarks, vóór d1-3B met minder dan twee derde van diens omvang." Dat is een sterke uitspraak van een model van 1,92B over een model van 3,12B, en ze is controleerbaar, omdat de kaart alle vier open d1-modellen in één tabel zet, gescoord op dezelfde items met dezelfde scorer.

Het hoofdgetal is 51,1 tegenover 49,0 op de publieke suite van Decision Index, versie 0.3 — een voorsprong van 2,1 punt. Voordat iemand dat als een duidelijke overwinning leest, horen er twee kanttekeningen naast. Ten eerste rapporteert de eigen kaart van d1-3B 48,57 op Decision Index 0.2.1, en het verschil tussen 48,57 en 49,0 is de indexversie, niet een verbetering van het model; de kaart van d1-2B stelt dat alle vier modellen opnieuw zijn gescoord op dezelfde items en dat een paar cijfers van d1-3B daarom afwijken van zijn eigen kaart. Ten tweede is de publieke suite slechts een fractie van wat de publieke ranglijst bepaalt: de onafhankelijke evaluator die hem opnieuw heeft opgebouwd, beschrijft 37 publieke benchmarks die voor 20% van de score wegen, waarbij de rest afkomstig is van privétests die alleen de beheerders uitvoeren.

Wat de 49,0 geloofwaardig maakt als getal — hoewel d1-2B zelf geen externe controle heeft — is dat iemand de 3B al heeft gereproduceerd op deze exacte versie. Efraín Garay liet d1-3B draaien op een gestratificeerde steekproef van 6.000 verzoeken uit Decision Index 0.3 medio oktober en kwam uit op 49,11, tegenover Liquids eigen 49,04 op dezelfde rijen en 48,99 op de volledige suite. Dat is een reproductie binnen een tiende punt. Het valideert de 51,1 van d1-2B niet, want geen enkele derde partij heeft d1-2B gedraaid, maar het valideert wel de scoringsmethode achter de tabel waarin 51,1 staat.

Waar het kleinere model niet vooroploopt

‘Leidt op de meeste afzonderlijke benchmarks’ doet in die zin stilletjes zijn werk. In de tabel met dezelfde run wint d1-3B nog steeds drie van de ruim twintig rijen die van belang zijn voor een deploymentbeslissing:

• Snelle beslissingen — 59,3 voor de 3B tegen 58,8, de enige op snelheid gerichte beslissingsbenchmark waar het grotere model net vooroploopt.

• Getypeerde beslissingen — 65,0 tegen 61,3, een verschil van 3,7 punten en het duidelijkste afzonderlijke argument voor het oudere model wanneer de uitvoer een getypeerde waarde moet zijn in plaats van een label.

• AI2D — 79,9 tegen 76,7, de benchmark voor het lezen van diagrammen, waar een grotere vision tower nog steeds nauwkeurigheid oplevert.

Overal elders keert de volgorde om, soms fors. VisualWebBench is 96,2 voor d1-2B tegenover 71,4 voor d1-3B. ImajevBench v2.0-lite is 75,5 tegenover 64,0. MMMU-Pro is 26,4 tegenover 18,5 — beide zo laag dat geen van beide modellen vertrouwd mag worden voor moeilijk multimodaal redeneren, wat je ronduit moet zeggen in plaats van de kloof van 7,9 punten als een overwinning voor te stellen. De visie-gemiddelden zijn 70,2 en 65,4.

Drie afwezigheden die de kaart niet kan opvullen

De ontbrekende aankondiging komt tot uiting in ontbrekende artefacten. Geen van deze is een defect in het model; elk ervan is een reden waarom het model vandaag moeilijker te adopteren is dan zijn benchmarklijn doet vermoeden.

• Geen GGUF. d1-3B en d1-omni-600M kregen beide op 6 oktober GGUF-repositories, een dag nadat hun gewichten online stonden, en d1-3B volgde met een 8-bit weight-activation-build en vier MLX-varianten. d1-2B heeft sinds 27 oktober MLX- en ONNX-builds, maar geen GGUF — dus er is geen llama.cpp-pad gepubliceerd voor de decision head, hoewel het basismodel LFM3-VL-2B op 19 oktober zijn eigen GGUF kreeg. Als je edge-stack llama.cpp is, dan is dit het hele verhaal.

• Geen prijs en geen endpoint. De kaart vermeldt geen gehoste API, geen prijs per token en geen inferentieprovider. Dat is niet ongebruikelijk voor een release met open gewichten, maar het betekent dat de enige manier om d1-2B te gebruiken is door het te draaien, en de deploymentsectie van de kaart stopt bij een Transformers-fragment.

• Geen onafhankelijke benchmark. Per 28 oktober toont de repo 44 downloads en 13 likes. De bestaande onafhankelijke evaluatie van beslissingsmodellen heeft betrekking op d1-3B en d1-omni-600M, niet op dit model. Elk prestatiecijfer hierboven is afkomstig van Liquid AI zelf.

Er is ook een beperking die de kaart over zichzelf vermeldt: antwoorden "worden minder betrouwbaar na ongeveer 64K tokens aan state," de helft van het geadverteerde venster van 128K, en schattingen zijn betrouwbaar voor aantallen en scores, maar minder voor vrije hoeveelheden. Een model waarvan de eigen kaart aangeeft waar het minder presteert, is nuttiger dan een model dat dat niet doet, maar de 128K-kop moet worden gelezen als een capaciteitscijfer, niet als een werkbereik.

Hoe een eerste implementatie er in de praktijk uitziet

De praktische route is Transformers 5.19 of nieuwer met trust_remote_code=True, bf16 op GPU, en de system_one of system_one_batch-aanroep. Er zijn geen samplingparameters, omdat er geen sampling is. De enige afstelknop die ertoe doet, is set_size, die standaard op de getrainde grootte van 16 staat; die verhogen levert snelheid op en kost tekstnauwkeurigheid.

De eigen aanbeveling van de kaart is de stap die de meeste teams overslaan: kalibreer je beslissingsdrempel op gegevens uit je eigen gebruik. Een waarschijnlijkheid van 0,62 zegt niets op zichzelf. Als je supporttickets routeert of documenten markeert, moet de drempel die "escaleren" van "automatisch afhandelen" scheidt, worden afgestemd op je eigen gelabelde steekproef, omdat de kalibratie van de leverancier op de hunne is afgestemd.

De vorm waar dit bij past is een pipeline-stap, geen assistent: triage, moderatie, intentieclassificatie, extractie uit formulieren, reranking, visuele inspectie. Dat zijn precies de plekken waar een pipeline al meerdere modellen aanroept, en waar de generatieve stappen rond de beslissing meestal van een gehoste API komen. OrcaRouter host vandaag geen enkel Liquid AI-model — dit model inbegrepen — dus d1-2B draaien betekent dat je het zelf moet draaien. Waar een router nuttig voor is, is de rest van de keten: één OpenAI-compatibele sleutel voor meer dan 200 gehoste modellen, een routing-DSL die stappen combineert tot één aanroep, en automatische failover wanneer een provider uitvalt, zodat het beslissingsknooppunt op je GPU niet gegijzeld wordt door het generatieve knooppunt ernaast.

Wat zou dit verhaal veranderen?

Vier dingen, in afnemende volgorde van hoe belangrijk ze zouden zijn. Een GGUF zou d1-2B qua runtime op gelijke voet brengen met zijn broers en zussen en de edge-pitch concreet maken. Een aparte post zou kopers vertellen waarvoor Liquid AI het model bedoeld acht, verder dan de lijst met pipeline-stappen op de modelkaart. Een onafhankelijke run — idealiter dezelfde steekproef van 6.000 rijen die d1-3B reproduceerde — zou 51,1 omzetten van een leveranciersclaim in een meting. En een gehoste prijs zou de build-versus-buy-vraag überhaupt beantwoordbaar maken.

Tot dan is de eerlijke samenvatting beperkt en nuttig: er bestaat een {{1}}1.92B{{/1}}-beslissingsmodel, de repository ervan is compleet genoeg om te evalueren, de benchmarkvoorsprong op de {{2}}3B{{/2}} is echt op de eigen same-run-tabel van de leverancier en nergens anders geverifieerd, en de ontbrekende aankondiging heeft het zonder de verpakking — runtime, endpoint, prijs — gelaten die de meeste teams nodig hebben voordat ze een model in een pipeline zetten. Als je al {{3}}Transformers{{/3}} draait en een classifier met een {{4}}128K{{/4}}-venster en video-invoer wilt, is het een middagje waard. Als je {{5}}llama.cpp{{/5}} of een beheerd endpoint nodig hebt, wacht dan.