Liquid AI d1-3B vs Granite 4.2 3B: Två 3B-modeller som aldrig gör samma jobb

Sätt Liquid AI d1-3B och Granite 4.2 3B på samma enda GPU och båda får plats bekvämt — 3,12B parametrar på ena sidan, 3B på den andra. De kommer också att bete sig som om de kom från olika discipliner. Granite 4.2 3B, som IBMs eget modellkort daterar till den 25 augusti 2026, är en resonemangsmodell: tre tankelägen, ett <think>-block och ett svar du läser. Liquid AI d1-3B, uppladdad till Hugging Face den 5 oktober 2026 och annonserad av Liquid två dagar senare, är en beslutsmodell: den tar ett tillstånd plus en explicit uppsättning typade frågor och returnerar en sannolikhet, en etikett eller en position på en skala i en enda framåtpassning, och rapporterar output_tokens: 0 eftersom den aldrig skriver något. Den användbara frågan är inte vilken av dem som är bättre. Det är vilket av dina anrop som faktiskt är ett beslut, eftersom de två repona är byggda för motsatta halvor av den uppdelningen.

Vad som faktiskt finns i varje arkiv

Allt nedan kommer från modellkorten och Liquids tillkännagivandeinlägg. Inget här har oberoende reproducerats, ingen tredje part har betygsatt någon av modellerna på samma utvärderingsramverk, och siffrorna i korten är leverantörernas egna.

• Storlek — Liquid AI d1-3B 3,12B totalt, byggd på Liquids LFM2.5-VL-3B; Granite 4.2 3B en 3B decoder-only dense transformer byggd på granite-4.1-3b-base

• Utdata — d1-3B returnerar sannolikheter, etiketter och konfidensvärden och skriver ingen text alls; Granite 4.2 3B genererar tokens, inklusive en valfri tankekedja inuti <think>-taggar

• Kontext — d1-3B 32 768 tokens; Granite 4.2 3B 128K inbyggt, med en långkontextförlängning till 512K på kortet

• Indata – d1-3B text, JSON, bilder eller en blandning, via en SigLIP2 NaFlex 400M-vision encoder; Granite 4.2 3B endast text

• Licens — d1-3B under Liquid's LFM Open License v1.0; Granite 4.2 3B under Apache 2.0

• Språk — d1-3B listar 16; Granite 4.2 3B listar tolv testade, med kortet som noterar att andra är otestade

• Servering – d1-3B levereras med anpassad kod (trust_remote_code=True, transformers>=5.14), med GGUF- och w8a8-repon i samma familj och modellkort dokumenterade för llama.cpp, Ollama och LM Studio; Granite 4.2 3B körs under vLLM 0.20+ eller SGLang 0.5.18+ med en anpassad tankeparser

Två av de där raderna gör mer arbete än de andra. Utdataraden är hela argumentet i den här artikeln, och licensraden är den som ingen tar med i jämförelsetabellen.

Den ena skriver en tankekedja, den andra vägrar skriva.

Granite 4.2 3B förtjänar sin plats genom att tänka högt. Dess modellkort dokumenterar tre lägen: tänkande på som standard, icke-tänkande och ett läge med låg ansträngning som behåller resonemangsspåret men kortar det. Serveringsstackarna separerar resonemangsspåret från det slutliga svaret så att din applikation får rent innehåll plus ett separat resonemangsfält. Det är en bra design för en fråga som behöver arbetas ut – ett matematikproblem, en gren av logik, en kodbit som måste skrivas innan den kan bedömas.

d1-3B har inget sådant läge, och dess kort säger det rakt ut: "Det är inte en chattmodell och skriver inte text." Ett anrop deklarerar frågor med en typ. noul är en ja/nej-fråga som returnerar P(ja) mellan 0 och 1. choice väljer en etikett från en namngiven uppsättning alternativ och returnerar etiketten, en konfidens och en sannolikhet per alternativ. score placerar tillståndet på en ordnad skala från två till tio och returnerar den förväntade nivån med dess fördelning och teckenförklaring. Signalen läses från logits vid en platshållarposition i en enda genomkörning, inte samplad token för token, vilket är varför användningsblocket kan rapportera noll utdatatoken utan att ljuga.

Den skillnaden förändrar det innan den förändrar din noggrannhet. Ett Granite-klassificeringsanrop som tänker i 400 tokens är ett anrop du betalar 400 utdatatokens för, och etiketten du behöver ligger begravd i prosa som sedan måste hämtas. Ett d1-3B-anrop fakturerar indata. Om största delen av din trafik är en etikett med en tillhörande regel har du betalat för resonemanget oavsett om det ändrade etiketten eller inte.

Där Granite 4.2 3B helt klart är det bättre valet

Ta resonemangsbenchmarkarna för vad de är – de är IBMs egna, körda genom en intern NeMo Evaluator-pipeline, och ingen extern part har reproducerat dem – och 3B-modellen är ovanligt stark för sin storlek: AIME25 78,33, HMMT February 2025 66,67, GPQA 54,80, LiveCodeBench v6 69,71, MMLU-Pro 67,84, IFBench 74,33, BFCL v4 52,41, tau3-bench 45,78 och RULER 64K 67,52 som sjunker till 55,30 vid 128K.

Fyra jobb följer av den listan, och d1-3B finns inte i något av dem.

• En inbyggd kontext på 128K, utökningsbar till 512K, mot 32 768 tokens på d1-3B — om ditt tillstånd är ett långt dokument är valet gjort åt dig

• Agentiskt verktygsanrop med en dokumenterad parser och harness-integrationer för OpenCode, Pi och OpenHands, vilket en beslutsmodell inte har någon motsvarighet till

• Alla uppgifter vars svar är ett stycke: sammanfattning, utkast, extrahering till fri struktur, kodgenerering

• Finjustering och vidaredistribution utan intäktstak, eftersom Apache 2.0 inte har någon tröskelklausul

Lägg märke till vad som inte står på Granite-kortet: SWE-Bench- och Terminal-Bench-raderna är markerade NA för 3B. IBM:s agentiska förstärkningsinlärningssteg tillämpades endast på 8B- och 30B-medlemmarna i familjen, så den minsta modellen bär inte de agentiska poäng som dess större syskon gör. Ett team som läser "Granite 4.2" och antar att 3B ärver familjens agentiska profil kommer att bli förvånat.

Där d1-3B vinner innan Granite hinner tänka klart

Liquids egen latensmätningstabell, mätt i varmt tillstånd, en förfrågan i taget, är den starkaste delen av dess argument: en enda fråga på 8 ms på ett RTX 4090 och 9 ms på en AMD MI325X, 16 ms på en Jetson AGX Thor och 26 ms på en Jetson AGX Orin 64GB, med 64 tillstånd packade i en enda omgång vid 475/s på 4090 och 1 106/s på MI325X. Som jämförelse är det ungefär den tid Granite 4.2 3B behöver för att generera några tokens av sitt resonemangsspår.

Tre frågetyper på ett enda tillstånd kostar d1-3B 21 ms på 4090 i stället för tre separata anrop, eftersom tillståndet och dess bilder läses en gång för alla frågor. I en modererings- eller routningsstack som brukade skicka en HTTP-begäran per regel är det skillnaden mellan en kö av anrop och ett enda.

Den ser också. d1-3B får ett medelvärde på 74,1 över elva offentliga bildbenchmarks jämfört med 73,9 för sin basmodell, och kortet noterar att med bilderna borttagna får samma frågor 45,1 — svaren kommer från bilden, inte från textprompten. Enskilda rader går åt båda hållen (CV-Bench 82,1 mot basmodellens 87,6, POPE 88,5 mot 90,1), så påståendet om vision är "i nivå med basmodellen", inte "bättre än den".

Den ärliga motvikten: d1-3B:s 48,57 på Decision Index 0.2.1 producerades av att Liquid själva körde den officiella poängsättaren i stället för genom en inlämning till resultattavlan, och de konkurrerande raderna kommer från den offentliga resultattavlan. Dess medelvärde på 77,1 över åtta benchmark-som-beslut-uppgifter och dess 71,8 på DecisionBench är likaså förstapartsmätningar. Allt på d1-sidan i den här jämförelsen är overifierat.

Varför en 3B-resonerare inte är en 3B-beslutsmodell

Det frestande draget är att behandla Granite 4.2 3B som en billigare ersättare för d1-3B, eller tvärtom. Båda misslyckas, och misslyckandet är strukturellt snarare än en fråga om kvalitet.

Be Granite fatta beslut och du får en generering som du måste tolka, en räkning som skalar med hur svår modellen uppfattade att frågan var, och en latens som beror på vilket tankeläge du valde. Be d1-3B att resonera och du får ingenting alls — den har ingen tokenström att resonera i. De två modellerna ligger på varsin sida om en gräns som de flesta pipelines korsar flera gånger per begäran: något måste fatta beslut, och något måste tala. d1-3B hör hemma längst fram, där en triageregel väljer en väg och returnerar en kalibrerad konfidens. Granite 4.2 3B hör hemma bakom den, på den gren som behöver ett svar skrivet.

Det finns en andra, tystare fälla. Värdet hos en beslutsmodell är kalibrering – en konfidens på 0,9 som har rätt nio gånger av tio. Kortet för Granite 4.2 3B publicerar inga kalibreringsmått och inga sannolikheter; det publicerar träffsäkerhets- och resonemangspoäng. Att jämföra de två på en benchmark-topplista säger ingenting om vilken av dem du bör lita på när det gäller ett tröskelvärde.

Licensraden som ingen lägger i tabellen

Granite 4.2 3B släpps under Apache 2.0. d1-3B släpps under LFM Open License v1.0, som framstår som tillåtande ända till avsnitt 5: kommersiell användning beviljas under förutsättning att du eller din juridiska person ligger under ett tröskelvärde som i samma dokument definieras som en årlig intäkt på tio miljoner US-dollar eller mer, och all kommersiell användning över den gränsen är helt enkelt inte licensierad. Ideella organisationer och forskningsanvändare undantas.

För en hobbyist eller en startup är detta inget problem. För ett företag som passerar den gränsen mitt under året — eller som skulle kunna förvärvas av ett sådant — är de två reporna inte likvärdiga artefakter, oavsett hur lika deras parameterantal ser ut, och licensgranskningen sker långt efter att någon redan har skeppat prototypen. Det är det billigaste på den här sidan att kontrollera tidigt.

Kör paret som en enda pipeline

Ingen av modellerna finns i vår katalog i dag, så detta är inte ett påstående om tillgänglighet: båda är självhostade artefakter, och Granite 4.2 3B i synnerhet har inga inferensleverantörer listade på sitt kort alls. Men mönstret ett team faktiskt landar i är ett anrop som fattar beslut och ett annat som talar, och det mönstret är där ett routningslager förtjänar sin plats. OrcaRouter sätter fler än 200 modeller bakom en enda API-nyckel med leverantörernas listpriser vidarebefordrade med 0 % påslag, så en leverantörs prissänkning når din faktura samma dag i stället för vid nästa avtalsförnyelse, och automatisk redundansväxling mellan leverantörer innebär att den delade komponenten mitt i en pipeline inte blir en enda felpunkt medan du fortfarande utvärderar den. Om du vill A/B-testa d1-3B mot en hostad generalist på din egen trafik innan du binder dig till en självhostad distribution, är den närmaste routade grannen till Granites härstamning Gemma 4 31B till $0,13 per miljon indatatoken och $0,38 per miljon utdatatoken — en mycket större modell, men samma "generalist som skriver"-roll i pipelinen.

Domen, uttryckt som en regel

Om det du behöver är en bedömning — spam eller inte, vilken kö, hur brådskande det är, om den här bilden matchar den beskrivningen — är d1-3B den enda av de två som gör jobbet i ett svep, och den gör det på ensiffriga millisekunder. Om det du behöver är ett skriftligt svar, en läsning av ett långt dokument, ett verktygsanrop eller en bit kod, är Granite 4.2 3B den som överhuvudtaget har en tokenström, och 3B:s resonemangspoäng är verkligen imponerande för sin storlek — på IBMs egna utvärderingar, som ingen ännu har granskat.

Det som skulle förändra bilden är inte en ny benchmark-rad. Det är en tredje part som poängsätter båda modellerna på samma kalibreringsrigg, eftersom den egenskap som avgör huruvida man kan sätta ett tröskelvärde på en modell är den som inget av korten låter dig jämföra i dag.