SubQ Snap 1.1 vs Granite 4.2 3B: Priset per token är fel räkning

IBMs Granite 4.2 3B har ett listpris på 0,03 USD per miljon indatatoken. SubQ Snap 1.1 har ett listpris på 0,04 USD. Om priset per token vore räkningen skulle den Apache-2.0-licensierade modellen med 3 miljarder parametrar slå den beslutsmodell som delade förstaplatsen i Artificial Analysis Decision Index v1.0, och den här artikeln skulle vara kort. Priset är inte räkningen. När man prissätter ett beslut i stället för en token – inklusive vad varje modell måste generera för att producera ett – vänder rangordningen, vänder tillbaka beroende på en enda konfigurationsinställning och hamnar någonstans som ingen av leverantörerna gör reklam för.

Granite 4.2 3B är IBMs lilla täta resonemangsmodell, som släpptes den 25 augusti 2026 tillsammans med syskonen 8B och 30B med ovanligt lite pompa och ståt – ett tekniskt blogginlägg snarare än ett lanseringsevenemang. Snap 1.1 är Subquadratics beslutsmodell, i drift sedan den 22 oktober 2026, som returnerar ett val ur en fast svarsuppsättning i stället för att generera text. De överlappar inom exakt en arbetsbelastning: att ta en textbit och avgöra vad den är. Allt annat hos dem skiljer sig, inklusive vad "billig" betyder.

Först, vad de två modellerna faktiskt är

Granite 4.2 3B är en tät dekoder med tre miljarder parametrar, byggd på Granite-4.1-3B-Base. Det är en resonemangsmodell med tre lägen: ett tänkandeläge som avger en tankekedja, ett läge med låg ansträngning och ett icke-tänkande läge som svarar direkt. IBM rapporterar AIME 2025 på 78,33, GPQA på 54,80, LiveCodeBench v6 på 69,71, MMLU-Pro på 67,84, IFBench på 74,3 och τ³-Bench på 45,8 – alla är leverantörens siffror, och ingen av dem har oberoende reproducerats. För lång kontext rapporterar den RULER på 67,52 vid 64K och 55,30 vid 128K. Artificial Analysis anger dess Intelligence Index till 9, vilket inte är anmärkningsvärt i absoluta termer och ligger över medianen för dess storleksklass.

Hårdvarudelen är det intressanta. Den körs på sex till åtta gigabyte i bf16 och under två gigabyte kvantiserad, vilket innebär en laptop, ett enda konsumentgrafikkort eller en CPU med tillräckligt med RAM. Den är enbart textbaserad, täcker tolv språk, stöder OpenAI-kompatibelt verktygsanrop och finns i vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX och Ollama. Om din begränsning är "måste köras någonstans jag kontrollerar" klarar den det.

SubQ Snap 1.1 är i nästan varje avseende den motsatta typen av produkt. Den har inga vikter. Den körs endast via Subquadratics API. Den tar emot upp till 384K token text och bilder plus en svarsuppsättning med två till 255 alternativ och returnerar ett val med en kalibrerad sannolikhet. Den kan inte skriva en mening, vilket är poängen: det finns ingen utdata att tolka och ingen utdata att betala för.

Utdata-tokenfällan

Här är räkneexemplet som jämförelsen per token döljer. Ta en miljon dirigeringsbeslut som vart och ett läser 6 000 token ärendetext – en rimlig månadsvolym för en medelstor supportverksamhet, eller en intensiv eftermiddag för en stor sådan. Det blir sex miljarder indatatoken.

• Granite 4.2 3B i icke-tänkande läge — 6B indatatokens till $0,03/M är $180, plus ungefär fem utdatatokens per beslut, eller 5M utdatatokens till $0,12/M, för $0,60. Totalt: cirka $180,60.

• Granite 4.2 3B i tankeläge — 6B indata för $180, plus kanske 800 resonemangstoken per beslut, eller 800M utdatatoken för $0.12/M, för $96. Totalt: cirka $276.

• SubQ Snap 1.1 — 6B indatatoken till $0.04/M är $240, och det finns ingen utdatarad alls.

Så det ärliga svaret är tre olika svar. Konfigurerad att svara direkt är Granite 25 % billigare än Snap, och artikeln skulle verkligen sluta där. Konfigurerad att tänka är Granite 15 % dyrare än Snap, eftersom resonemangstokens är det dyraste i pipeline och ingen budgeterar för dem. Snaps fördel var aldrig dess inputpris – det är 33 % högre än Granites – utan att arkitekturen inte har något sätt att lägga tokens på överläggning.

Det är inte en teoretisk risk. Artificial Analysiss oberoende profil av Granite 4.2 3B kallar modellen "mycket ordrik" och noterar att den genererade 92 miljoner utdatatoken medan den utvärderades på Intelligence Index, jämfört med en median på 67 miljoner för jämförbara modeller. Ordrikheten är en uppmätt egenskap hos modellen i resonemangsläge, och det är egenskapen som avgör om prisfördelen per token står sig vid en routing-arbetsbelastning.

Det förklarar också en siffra som ser fel ut vid första anblicken. Artificial Analysis anger Snap 1.1 till ungefär 30 dollar per miljon uppgifter, jämfört med 8,4 dollar för Elephant 9B. Trettio dollar per miljon uppgifter innebär en mycket kort genomsnittlig uppgift, i storleksordningen några tusen tokens. Decision Index benchmarkmix är kort. Dina ärenden, kontrakt och loggar är det inte, och kostnaden skalar linjärt med indatalängden därifrån. Betrakta siffror per uppgift som en egenskap hos benchmarken, inte som en offert.

Där 3B verkligen vinner

Billigare tokens är det minsta problemet. Granite 4.2 3B kan självhostas under Apache 2.0, vilket innebär att det inte finns någon kostnad per anrop alls när hårdvaran väl är betald, ingen data lämnar ditt nätverk, ingen begränsning av anropsfrekvens och ingen leverantör som kan ändra priset eller modellen under dig. För ett arbetsflöde som styrs av efterlevnadskrav är detta inte en preferens, det är ett krav, och Snap 1.1 kan helt enkelt inte ta sig in i det rummet.

Den gör också mer. Den skriver sammanfattningen efter routingbeslutet. Den hanterar verktygsanrop med ett schema. Den stöder en opt-in-kontextutökning till 512K, tillagd i en femte förträningsfas, vilket på papper är längre än Snaps 384K – men att dess RULER-poäng sjunker från 67,52 vid 64K till 55,30 vid 128K är en rimlig varning om hur mycket av det fönstret som faktiskt är användbart. Och den är tillräckligt liten för att köras vid edge, i en container bredvid din applikation, utan något nätverkshopp mellan beslutet och åtgärden.

Där Snap 1.1 verkligen vinner

Tre saker som en 3B-generativ modell är dålig på till sin konstruktion.

Kalibrering kommer först. Snap 1.1 rapporterar ett förväntat kalibreringsfel på 0,014, ner från 0,108 i förhandsversionen, och en avståendegrad på 86 % på frågor som den inte kan besvara – mot en icke-hallucineringspoäng på 0,7 % för dess egen 1.0-version på leverantörens proxy. Det är leverantörens siffror och bör läsas som sådana, men de beskriver en modell som tränats med avstående som ett explicit mål. En resonerande 3B-modell har inget sådant mål. Fråga den om ett ärende kan besvaras och den producerar en trovärdig mening oavsett.

Långkontextbeteendet vid en enda genomkörning är det andra. Snap bearbetar 384K token i en enda framåtpassning med konstant beräkningsmängd per token, vilket är hela motiveringen till Subquadratic Sparse Attention. Granites RULER-förfall är det normala beteendet hos en dense-modell vid tio gånger dess bekväma längd. Om ditt beslut beror på något som ligger begravt vid position 200 000 i ett loggpaket är den arkitektoniska skillnaden inte akademisk.

Determinismen i utdatans form är den tredje, och den underskattas. Snap returnerar ett nummer över din alternativlista. Granite returnerar text som du sedan tolkar, och varje parser är en plats där ett felaktigt svar blir ett avbrott. Begränsad avkodning täpper igen större delen av den luckan, vilket är värt att säga – det är inte en grundläggande fördel, det är en skillnad i hur mycket stödstruktur du skriver.

Konfigurationsfrågan som ingen ställer

Om du kör Granite 4.2 3B som router är den enskilt mest värdefulla ändringen du kan göra att stänga av tänkandet. IBM levererar det läget just av den anledningen, och räkneexemplet ovan visar varför: en resonerande modell som ombeds välja en av fem etiketter lägger ofta åttahundra token på att motivera ett beslut som en icke-tänkande körning får rätt. Benchmarka de två lägena på dina egna data innan du antar att det tänkande läget är bättre. På en uppgift med en fast svarsuppsättning är det ofta inte det.

Snaps motsvarande hävstång är den motsatta: man ger den färre, vassare alternativ. Dess API begränsar frågor till sexton och svarsalternativ till 255 per fråga, och dess träffsäkerhet på Decision Index är 20 % – lägre än d1-ultras 32 % – där indexpoängen bärs upp av avståenden. Begränsa svarsmängden och träffsäkerhetsproblemet krymper; ge den en öppen bedömning och den kommer att avstå – korrekt och ofta.

Vad jag faktiskt skulle bygga

För en support- eller dokumentpipeline vid betydande volym är den billigaste försvarbara designen en tvåstegslösning. Granite 4.2 3B körs i non-thinking-läge som förstapassklassificerare på den enkla majoriteten – ärendena som uppenbart gäller återbetalning, uppenbart driftavbrott, uppenbart spam – där en 3B-modell är träffsäker och inte kostar något marginellt. Snap 1.1 hanterar resten: de långa trådarna, de tvetydiga fallen, de där rätt svar kan vara "eskalera" och en självsäker gissning är sämre än ett avböjande. Du betalar 0,04 USD per miljon tokens endast för den andel som behöver det, och du får en kalibrerad sannolikhet för exakt de beslut där kalibrering spelar roll.

Ingen av leverantörerna säljer den designen, eftersom var och en vill vara hela lagret. Granite 4.2 3B finns inte i OrcaRouters katalog – den är Apache 2.0, så självhosting är den vanliga vägen, och den tillhandahålls även av ett antal inferensleverantörer. Snap 1.1 är inte heller vår; den körs via Subquadratics egen API. Det OrcaRouter bidrar med i en sådan design är genereringsnivån bakom den: över 200 modeller bakom en enda nyckel, leverantörernas listpriser vidarebefordras med 0 % påslag och automatisk failover, så modellen som skriver eskaleringssammanfattningen är inte samma beroende som modellen som beslutar att eskalera.

Det man bör hålla ögonen på är om Snap 1.1:s kalibrering håller när någon annan kör den. Dess noggrannhet på 20 % är den svagaste siffran i dess eget lanseringsmaterial, och det är den som avgör om den tvåstegsdesign som beskrivs ovan är billigare än den verkar — ju oftare Snap avstår, desto mer arbete faller tillbaka på steget som faktiskt måste svara.