d1-2B: Liquid AI lanserade en beslutsmodell på 1,9B utan att tillkännage den i ett inlägg

Hugging Face-repot för LiquidAI/d1-2B skapades 19:30 UTC den 24 oktober 2026. Syskonmodellen d1-Omni-2B dök upp tjugofyra sekunder senare. Vid slutet av den kvällen var båda repona kompletta — 3,84 GB BF16-safetensors, ett fyrtiotal filer med anpassad Transformers-kod, en kalibreringstabell, ett API för typade frågor — och inget som Liquid AI publicerade sade att någon av modellerna existerade. Den första leverantörsmeningen som namnger d1-2B anlände den 27 oktober, i lanseringen av LFM3-familjen — samma inlägg som publicerades på liquid.ai och på Hugging Faces egen blogg — som en bisats i ett stycke om två beslutsmodeller. Det har inte kommit något dedikerat inlägg sedan dess. Så det här är inte en lanseringshistoria, och att behandla det som en skulle hitta på ett marknadsföringsögonblick som aldrig ägde rum. Det är en historia om en fullständig modellartefakt med ett ofullständigt tillkännagivande, och om de två saker en läsare fortfarande kan göra med det: läsa repot, och hålla leverantörens siffror på armlängds avstånd tills någon utanför labbet kör dem.

De fem dagarna mellan vikterna och domen

Familjen d1 har släppts två gånger, och ingen av lanseringarna såg ut som den här. Den 7 oktober publicerade Liquid AI ”Open d1: Edge-beslutsmodeller för text, vision och ljud”, som introducerade d1-3B med 3,12B parametrar och d1-omni-600M med 587M, med ett påstående i rubriken, en benchmarktabell, latenssiffror och ett blogginlägg som har varit live sedan dess. Det inlägget innehåller ingen 2B-modell.

2B-linjen gick enligt ett annat schema. Bascheckpointen LFM3-Omni-2B dök upp den 21 oktober. Den 24 oktober, kl. 19:30 och 19:30:24 UTC, skapade Liquid AI repositorierna d1-2B och d1-Omni-2B. Sedan, den 27 oktober, namngav LFM3-lanseringsinlägget paret som "beslutsmodeller specialiserade från visions- och omnimodellerna" – en beskrivning, inte ett tillkännagivande. Samma dag lades fyra derivatrepositorier för d1-2B upp: MLX-byggen i fp16, 8-bit och 4-bit, plus en ONNX-export. Ingen skrev ett inlägg om dem heller.

Detta spelar roll av en praktisk anledning. Ett tillkännagivande är där en leverantör förbinder sig till en positionering: vad modellen är till för, vad den kostar, vilken runtime den riktar sig mot, vad den inte gör. Kortet gör en del av det arbetet, och gör det ovanligt väl. Men luckorna som det saknade inlägget lämnar är verkliga och specifika, och de listas längst ner i den här artikeln i stället för att döljas.

Vad arkivet faktiskt kommer att berätta för dig

Skalar man bort inramningen är checkpointen en liten, tätt specificerad multimodal klassificerare som vägrar generera text. Varje anrop returnerar typade svar med tillhörande sannolikheter och output_tokens: 0. Kortet säger det rakt ut: d1-2B "är inte en chattmodell".

• Parametrar — 1,92B, levereras som en enda 3,84 GB BF16-safetensors-fil.

• Bas — LFM3-VL-2B, på LFM3-stommen: 24 lager, varav 13 är gated short convolutions, 5 är sliding-window-attention och 6 är global attention.

• Kontext — 128K tokens och ett ordförråd på 128 000 tokens, fyra gånger så stort som fönstret på d1-3B:s 32 768.

• Indata — ett tillstånd som kan vara text eller valfritt JSON-värde, bilder eller en video, och valfritt antal namngivna frågor, allt i en medialista. Video är den kapacitet som d1-3B inte listar.

• Utdata — ja/nej, ett val bland namngivna alternativ, en ordnad poäng, ett värde eller datum som avläses från ett dokument med tillhörande spann, ett tal med ett p10–p90-intervall, en avgränsningsruta, eller varje förekomst av ett objekt med ett antal. Var och en bär en sannolikhet.

• Språk — sexton: engelska, arabiska, kinesiska, franska, tyska, italienska, japanska, koreanska, portugisiska, spanska, vietnamesiska, thailändska, indonesiska, hindi, ryska, polska.

• Licens — LFM Open License v1.0. Kommersiell användning beviljas under $10,000,000 i årlig omsättning; licenstexten definierar den siffran som en tröskel, och rättigheter för kommersiell användning över den är villkorade av att den inte överskrids.

• Hastighet — 5,7 ms för ett enskilt beslut på ett H100 PCIe och 3,8 ms på ett AMD MI325X, med 1 132 respektive 1 699 beslut per sekund när 64 tillstånd batchas i ett anrop. På en Apple M5 Pro är siffran för en enskild fråga 18,6 ms.

Påståendet som är värt att argumentera om: det slår modellen det ersatte

Liquid AIs modellkort framför ett jämförande påstående utan förbehåll: d1-2B "leder de öppna d1-modellerna i genomsnitt och på vår resultattavla med över hundra beslutsbenchmarkar, före d1-3B med mindre än två tredjedelar av dess storlek." Det är ett starkt uttalande från en 1,92B-modell om en 3,12B-modell, och det går att kontrollera, eftersom kortet visar alla fyra öppna d1-modellerna i en enda tabell som poängsatts på samma poster med samma poängsättare.

Siffran i toppraden är 51,1 mot 49,0 på Decision Index offentliga svit, version 0.3 – en ledning på 2,1 punkter. Innan någon tolkar det som en ren seger hör två förbehåll till det. För det första rapporterar d1-3B:s eget kort 48,57 på Decision Index 0.2.1, och skillnaden mellan 48,57 och 49,0 är indexversionen, inte en förbättring av modellen; d1-2B-kortet anger att alla fyra modeller poängsattes om på samma poster och att några av d1-3B:s siffror därför skiljer sig från dess eget kort. För det andra är den offentliga sviten en bråkdel av det som avgör den offentliga resultattavlan: den oberoende utvärderare som byggde om den beskriver 37 offentliga riktmärken viktade till 20 % av poängen, med resten från privata tester som endast underhållarna kör.

Det som gör 49,0 trovärdigt som tal – även om d1-2B i sig inte har någon extern kontroll – är att någon redan har reproducerat 3B på just den här versionen. Efraín Garay körde d1-3B på ett stratifierat urval på 6 000 förfrågningar från Decision Index 0,3 i mitten av oktober och fick 49,11, mot Liquids egna 49,04 på samma rader och 48,99 på hela sviten. Det är en reproduktion inom en tiondels poäng. Det validerar inte d1-2B:s 51,1, som ingen tredje part har kört, men det validerar poängsättningsmetoden bakom tabellen som 51,1 finns i.

Där den mindre modellen inte ligger före

”Leder på de flesta enskilda benchmarks” utför ett tyst arbete i den meningen. I tabellen för samma körning vinner d1-3B fortfarande tre av de drygt tjugo rader som är relevanta för ett driftsättningsbeslut:

• Snabba beslut — 59,3 för 3B mot 58,8, det enda snabbhetsorienterade beslutsriktmärket där den större modellen ligger snäppet före.

• Typade beslut — 65,0 mot 61,3, en skillnad på 3,7 punkter och det tydligaste enskilda argumentet för den äldre modellen när utdata måste vara ett typat värde snarare än en etikett.

• AI2D — 79,9 mot 76,7, benchmarken för diagramläsning, där ett större visionstorn fortfarande ger högre noggrannhet.

På alla andra ställen vänds ordningen, ibland kraftigt. VisualWebBench är 96,2 för d1-2B mot 71,4 för d1-3B. ImajevBench v2.0-lite är 75,5 mot 64,0. MMMU-Pro är 26,4 mot 18,5 – båda är tillräckligt låga för att ingen av modellerna bör anförtros svåra multimodala resonemangsuppgifter, vilket är värt att säga rakt ut i stället för att framställa gapet på 7,9 punkter som en vinst. Medelvärdena för vision är 70,2 och 65,4.

Tre luckor som kortet inte kan fylla

Det uteblivna tillkännagivandet visar sig i form av saknade artefakter. Inget av detta är en defekt i modellen; var och en är ett skäl till att modellen är svårare att införa i dag än vad dess benchmarklinje antyder.

• Ingen GGUF. d1-3B och d1-omni-600M fick båda GGUF-repos den 6 oktober, en dag efter att deras vikter lades upp, och d1-3B följde upp med ett 8-bitars viktaktiveringsbygge och fyra MLX-varianter. d1-2B har MLX- och ONNX-byggen sedan den 27 oktober, men ingen GGUF – så det finns ingen publicerad llama.cpp-väg för beslutshuvudet, även om basmodellen LFM3-VL-2B fick sin egen GGUF den 19 oktober. Om din edge-stack är llama.cpp är det här hela historien.

• Inget pris och ingen endpoint. Modellkortet listar inget hostat API, inget pris per token och ingen inferensleverantör. Det är inte ovanligt för en lansering med öppna vikter, men det innebär att det enda sättet att använda d1-2B är att köra det själv, och kortets avsnitt om driftsättning slutar vid ett Transformers-kodexempel.

• Ingen oberoende benchmark. Per den 28 oktober visar repot 44 nedladdningar och 13 gillningar. Den oberoende utvärdering av beslutsmodeller som finns omfattar d1-3B och d1-omni-600M, inte den här modellen. Varje prestandasiffra ovan är Liquid AI:s egen.

Det finns också en gräns som kortet självt anger: svaren "blir mindre tillförlitliga efter ungefär 64K tokens tillstånd", hälften av det annonserade 128K-fönstret, och uppskattningar är tillförlitliga för antal och poäng men mindre så för fria kvantiteter. En modell vars eget kort talar om var den försämras är mer användbar än en som inte gör det, men 128K-rubriken bör läsas som en kapacitetssiffra, inte ett arbetsintervall.

Hur en första driftsättning faktiskt ser ut

Det praktiska tillvägagångssättet är Transformers 5.19 eller nyare med trust_remote_code=True, bf16 på GPU, och system_one eller system_one_batch-anropet. Det finns inga samplingsparametrar eftersom det inte finns någon sampling. Den enda inställningsratten som spelar roll är set_size, som standard är den tränade storleken 16; att höja den ger snabbhet men kostar textnoggrannhet.

Kortets egen rekommendation är det steg som de flesta team hoppar över: kalibrera din beslutströskel på data från din egen användning. En sannolikhet på 0,62 betyder ingenting i sig. Om du dirigerar supportärenden eller flaggar dokument måste tröskeln som skiljer "eskalera" från "hantera automatiskt" anpassas efter ditt eget märkta urval, eftersom leverantörens kalibrering anpassades efter deras.

Den form detta passar in i är ett pipeline-steg, inte en assistent: triage, moderering, avsiktsklassificering, extrahering från formulär, omrankning, visuell inspektion. Det är exakt de platser där en pipeline redan anropar flera modeller, och där de generativa stegen runt beslutet vanligtvis kommer från ett hostat API. OrcaRouter tillhandahåller ingen Liquid AI-modell i dag – den här inkluderad – så att köra d1-2B innebär att köra den själv. Det en router är användbar för är resten av kedjan: en OpenAI-kompatibel nyckel för över 200 hostade modeller, ett routnings-DSL som komponerar steg till ett enda anrop, och automatisk failover när en leverantör faller bort, så att beslutsnoden på din GPU inte hålls som gisslan av den generativa noden bredvid.

Vad skulle förändra den här historien?

Fyra saker, i fallande ordning efter hur mycket de skulle spela roll. En GGUF skulle sätta d1-2B på samma runtime-fot som sina syskon och göra edge-pitchen verklig. Ett dedikerat inlägg skulle berätta för köpare vad Liquid AI anser att modellen är till för, bortom kortets lista över pipeline-steg. En oberoende körning – helst samma urval på 6 000 rader som reproducerade d1-3B – skulle förvandla 51,1 från ett leverantörspåstående till en mätning. Och ett hostat pris skulle göra frågan bygga-eller-köpa besvarbar överhuvudtaget.

Fram till dess är den ärliga sammanfattningen snäv och användbar: det finns en beslutsmodell på 1,92B, dess repository är tillräckligt komplett för att utvärderas, dess benchmarkförsprång gentemot 3B är verkligt i leverantörens egen tabell från samma körning och overifierat överallt annars, och den uteblivna annonseringen har lämnat den utan den paketering – runtime, endpoint, pris – som de flesta team behöver innan de sätter en modell i en pipeline. Om du redan kör Transformers och vill ha en klassificerare med 128K-fönster och videoindata är det värt en eftermiddag. Om du behöver llama.cpp eller en hanterad endpoint, vänta.