d1-2B vs Liquid AI d1-3B: Den mindre modellen vinner på resultattavlan men förlorar vid driftsättningen

Fyra frågor avgör den här jämförelsen, och inte en enda av dem är "vilken modell som är bättre". Ingår video i tillståndet? Överskrider det 32K tokens? Behöver du köra det under llama.cpp? Har du råd att vara den första som testar det? d1-2B är Liquid AIs 1,92B-beslutsmodell, byggd på LFM3-VL-2B och fick 51,1 i leverantörens Decision Index-tabell. Liquid AI d1-3B är 3,12B-modellen som släpptes den 7 oktober, byggd på LFM2.5-VL-3B och fick 49,0 i samma tabell. Den nyare, mindre modellen leder i genomsnitt. Den förlorar fortfarande tre av de rader som en driftsättning faktiskt aktiverar, och den är den av de två som saknar llama.cpp-väg och oberoende testresultat. Den här sidan är organiserad kring de fyra frågorna snarare än kring resultattavlan, eftersom resultattavlan inte svarar på någon av dem.

Det korta svaret, per arbetsbelastning

• Triage av enbart text i stor volym — d1-2B, tack vare 1 132 beslut per sekund för 64 batchade tillstånd och 3,84 GB vikter. 3B:s fördel när det gäller Typed Decisions är irrelevant när utdata är en etikett.

• Diagram- och grafavläsning — Liquid AI d1-3B. Den vinner AI2D med 79,9 mot 76,7, och det är modellen med en oberoende körning bakom sig.

• Långa dokument, långa formulär, långa samtalsutskrifter — d1-2B. Dess fönster är 128K tokens mot 32 768, och kortet är ärligt om att tillförlitligheten avtar efter ungefär 64K, vilket fortfarande ger dubbelt så mycket utrymme som 3B:s totala kapacitet.

• Edge-boxar som kör llama.cpp — Liquid AI d1-3B, per default snarare än på grund av förtjänst. Den har ett GGUF-repo och en kvantiserad weight-activation-build; d1-2B har ingetdera.

• Allt där ett felaktigt val är kostsamt och oprövat — ingetdera, förrän du har kört båda på dina egna data. Bara ett av dem har ens körts av en tredje part.

Samma familj, en generation isär

De två modellerna är inte syskon på det sätt som namnen antyder. Liquid AI d1-3B härstammar från LFM2.5-VL-3B, som i sin tur härrör från LFM2.5-2.6B-Base, och har en 400M SigLIP2 NaFlex visionskodare. d1-2B härstammar från LFM3-VL-2B, nästa familj, på ett backbone med 24 lager uppdelade mellan 13 gated short convolutions, 5 sliding-window attention-lager och 6 globala attention-lager. Det är i detta generationsgap som benchmark-inversionen uppstår: den nyare arkitekturen gör mer per parameter, så den mindre checkpointen kan få högre poäng än den större på de flesta rader.

• Parametrar — 1,92B för d1-2B mot 3,12B för Liquid AI d1-3B.

• Ladda ner — 3,84 GB vs 6,25 GB BF16-safetensors, båda som enskilda filer.

• Kontext — 128K tokens vs 32 768.

• Ordförråd — 128 000 token jämfört med LFM2.5-ordförrådet.

• Indata — text eller JSON, bilder eller video, plus namngivna frågor, för d1-2B; text eller JSON plus bilder för 3B. Video är den tydligaste kapacitetsskillnaden mellan dem.

• Språk — sexton var, samma uppsättning.

• Licens — LFM Open License v1.0 för båda, med kommersiell användning villkorad av att ligga under 10 000 000 USD i årlig omsättning. Det finns ingen licensieringsanledning att föredra någon av dem.

• Släpp — d1-3B:s vikter lades upp den 5 oktober och tillkännagavs den 7 oktober. d1-2B:s repository skapades den 24 oktober och har aldrig haft ett eget inlägg; den enda leverantörsmeningen som nämner det finns i LFM3-lanseringen den 27 oktober.

En detalj i dokumentationen är värd att läsas som en signal snarare än ett faktum: Liquid AIs dokumentationssida för beslutsmodeller listar nu d1-2B, d1-omni-2B, d1-omni-600M, d1.1 och d1-ultra. Den listar inte längre d1-3B. 3B har inte pensionerats – dess repo, GGUF- och MLX-byggen är alla aktiva – men leverantörens eget index har flyttat platsen för öppna vikter till 2B.

Resultattavlan, läs rad för rad

Alla siffror nedan kommer från benchmarktabellen på modellkortet för d1-2B, som poängsätter fyra öppna d1-modeller på samma poster med samma poängsättare. Det spelar roll eftersom Liquid AI d1-3B:s eget kort rapporterar 48.57 på Decision Index 0.2.1 medan den här tabellen rapporterar 49.0 på version 0.3; skillnaden är indexutgåvan, inte en modelländring, och kortet säger det i en not. Att jämföra de två korten direkt – 48.57 mot 51.1 – skulle vara att subtrahera över två olika tester. Att jämföra inom den här tabellen är legitimt, och det är vad resten av det här avsnittet gör.

• Decision Index public suite v0.3 — 51,1 vs 49,0.

• DecisionBench (Hanno Labs) v1 – 77,1 mot 73,1.

• Decision Bench (decisionbench.ai) v4 — 85,2 mot 83,6.

• JevBench v1.4.1 — 77,9 mot 76,2.

• ImajevBench v2.0-lite — 75,5 vs 64,0, den största skillnaden på beslutssidan.

• WorkflowEvals — 81,6 mot 74,4.

• Liquid AI:s interna resultattavla — 63,2 mot 58,8.

• Vision-genomsnitt — 70,2 vs 65,4 över arton benchmarks.

Varje namngiven beslutssvit i den tabellen går till 2B, vilket är vad LFM3-lanseringsinlägget menar när det kallar d1-2B en ersättare för d1-3B "med en tredjedel färre parametrar" och högre poäng "på alla fyra beslutssviter". Påståendet är korrekt som skrivet — och snävare än "slår 3B", vilket är anledningen till att nästa stycke finns. Sedan de tre rader som går åt andra hållet. Fast Decisions är 58,8 för d1-2B mot 59,3 för 3B. Typed Decisions är 61,3 mot 65,0. AI2D är 76,7 mot 79,9. Ingen av dessa skillnader är stor, och två av de tre ligger inom en poäng, men det är raderna där de extra 1,2B parametrarna fortfarande ger något mätbart: snabborienterade beslut, typad extrahering och diagramläsning. Om jobben i din pipeline är typad extrahering från formulär är 3B inte det föråldrade alternativet som dokumentationssidan antyder.

Latens: de två huvudnumren är inte jämförbara

Liquid AI uppger 5,7 ms per beslut för d1-2B och 8 ms för Liquid AI d1-3B, och det är inte samma mätning. Siffran för 2B gäller på en H100 PCIe; siffran för 3B gäller på en RTX 4090. En skillnad på 2,3 ms mellan två olika GPU:er säger dig ingenting om vilken modell som är snabbare på din hårdvara, och att upprepa den som en jämförelse skulle vara precis den sorts siffertvätt som den här bloggen finns för att undvika.

Det finns en maskin som båda korten rapporterar resultat för. På en Apple M5 Pro tar d1-2B 18,6 ms per fråga och 3B tar 30 ms – en minskning med 38 % på identisk kisel. Det är den ärliga hastighetsjämförelsen, och den pekar i samma riktning som storleksskillnaden antyder. När det gäller batching hanterar d1-2B 1 132 beslut per sekund på en H100 PCIe och 1 699 per sekund på en MI325X med 64 tillstånd i ett anrop; 3B:s kort anger 475 per sekund på en RTX 4090 och 1 106 per sekund på en MI325X. MI325X-raden är den som båda korten delar, och där ligger 2B före med ungefär 54 %.

Det enda oberoende testet som finns körde 3B

I mitten av oktober körde Efraín Garay åtta beslutsmodeller mot Decision Index 0.3 och tre uppgifter med verklig data, och publicerade resultaten med kod. Två fynd har bäring på denna jämförelse.

Det första är betryggande för resultattavlan. Han byggde om den offentliga sviten från dess kit, kontrollerade att de nedladdade filerna matchade de officiella, tog ett urval på 6 000 förfrågningar och gav Liquid AI d1-3B poängen 49,11 – mot Liquids egna 49,04 på samma rader och 48,99 på hela sviten. Det är det starkaste tillgängliga beviset för att siffrorna för v0.3 i tabellen ovan beräknas korrekt. Det är bevis om 3B, inte om d1-2B, som han inte testade.

Den andra är en varning om vad ett index mäter. På en syntetisk bank för kortbedrägerier med 10 000 betalningar fick Liquid AI d1-3B en AUC på 0,314 – sämre än slumpen, och rankade anomalier som mindre misstänkta än normala betalningar, eftersom serier av tätt på varandra följande betalningar hamnade på en median sannolikhet på 0,41 jämfört med 0,56 för en normal betalning. Modellen låg tvåa på det offentliga indexet och sist på den uppgiften. Lärdomarna går direkt att överföra: d1-2B:s 51,1 är en poäng på en allmän testsvit för beslut, och ingen har visat att den förutsäger prestanda för just ditt specifika beslut. Leverantören säger det själv i sitt eget modellkort, i instruktionen att kalibrera tröskelvärden på dina egna data.

Vad du faktiskt kan köra idag

Det är här jämförelsen inte längre är jämn. Liquid AI d1-3B har haft ett GGUF-repo sedan 6 oktober, ett bygge med 8-bitars vikter och aktiveringar sedan 7 oktober och fyra MLX-varianter sedan 12 oktober. d1-2B fick tre MLX-byggen och en ONNX-export den 27 oktober, och inget annat. Det finns ingen GGUF för d1-2B, ingen kvantisering utöver MLX:s 4-bitars och 8-bitars, och därför ingen publicerad llama.cpp-väg för beslutsheaden – trots att basmodellen LFM3-VL-2B har haft sin egen GGUF sedan 19 oktober.

För en Transformers-distribution försvinner skillnaden: båda laddas med trust_remote_code=True och exponerar samma system_one och system_one_batchanrop. För en edge-distribution gör den det inte. Om din stack är llama.cpp på en Jetson eller en telefon är 3B den enda av de två som du kan köra utan att skriva en runtime-integration, och dess publicerade edge-siffror – 16 ms på Jetson AGX Thor, 26 ms på AGX Orin 64GB, 50 ms på Orin Nano – är de som du kan planera utifrån.

Ingen av modellerna serveras av OrcaRouter, så att välja mellan dem är ett självhostingsbeslut oavsett. Där en router förtjänar sin plats är ett lager bort: beslutsmodeller körs sällan ensamma, och det generativa steget som agerar på en routingetikett kommer vanligtvis från en hostad modell. En OpenAI-kompatibel nyckel för över 200 modeller, ett routing-DSL som låter dig sätta samman dessa steg till ett enda anrop, och automatisk failover hindrar den halvan av pipelinekedjan från att bli ett andra integrationsprojekt medan beslutsnoden stannar på din egen hårdvara.

Om du migrerar ändras tre saker

API-ytan är tillräckligt lik för att en portning ska verka trivial, och det är den inte. Först, indatakontraktet: d1-3B tar bilder; d1-2B tar en media-lista som kan innehålla video, och dess kort beskriver mediet som kodat en gång för alla frågor i ett anrop. Kod som skickar en enda bild kommer att köras, men den kommer inte att använda det som modellen byggdes för.

För det andra tröskelvärdet. Båda modellerna returnerar sannolikheter, och båda behöver ett beslutströskelvärde anpassat till era data. Ett tröskelvärde som justerats mot d1-3B:s kalibrering går inte att överföra — kalibreringstabellerna levereras inuti varje repo och är separat anpassade — så en migrering som behåller den gamla gränsen ger en annan arbetspunkt och, i en modererings- eller bedrägeripipeline, en annan felprofil.

För det tredje, tillförlitlighetsstupet. Fönstret på 128K är rubriken; kortet säger att svaren blir mindre tillförlitliga bortom ungefär 64K token med tillstånd. På 3B är taket 32 768, så en migrering till d1-2B blir vanligtvis en ren kapacitetsvinst – men en pipeline som börjar mata in 100K-token-tillstånd eftersom den nu kan det testar den del av intervallet som leverantören har flaggat som svagare.

Domen är mindre symmetrisk än resultattavlan. För en ny byggnation i Transformers, på text eller bilder eller video, med tillstånd som kan pågå länge, är d1-2B det bättre standardvalet och det billigare att köra. För en edge-driftsättning under llama.cpp, för typad extrahering eller för diagramtung vision är Liquid AI d1-3B fortfarande modellen att välja – och det är den enda av de två som har några externa bevis bakom sig. Det enda man inte ska göra är att välja enbart utifrån raden 51,1 mot 49,0. Två poäng på en leverantörs index, mellan två modeller som ingen har kört på din uppgift, är inte ett beslut; det är ett tiebreak.