SubQ Snap 1.1 vs Granite 4.2 3B: De prijs per token is de verkeerde rekening

IBM's Granite 4.2 3B staat vermeld voor $0,03 per miljoen invoertokens. SubQ Snap 1.1 staat vermeld voor $0,04. Als het tarief per token de rekening zou zijn, zou het Apache-2.0-model met 3 miljard parameters het beslissingsmodel verslaan dat samen op de eerste plaats eindigde in de Artificial Analysis Decision Index v1.0, en dan zou dit artikel kort zijn. Het tarief is niet de rekening. Zodra je een beslissing prijst in plaats van een token — inclusief wat elk model moet genereren om er één te produceren — keert de rangorde om, keert ze weer terug afhankelijk van één configuratie-instelling, en eindigt ergens waar geen van beide leveranciers mee adverteert.

Granite 4.2 3B is IBM's kleine dense redeneermodel, uitgebracht op 25 augustus 2026 naast de 8B- en 30B-varianten, met opvallend weinig tamtam — een technische blogpost in plaats van een lanceringsevenement. Snap 1.1 is het beslissingsmodel van Subquadratic, live sinds 22 oktober 2026, dat een keuze uit een vaste antwoordset retourneert in plaats van tekst te genereren. Ze overlappen op precies één workload: een stuk tekst nemen en beslissen wat het is. Al het overige aan hen is anders, inclusief wat "goedkoop" betekent.

Ten eerste, wat de twee modellen eigenlijk zijn

Granite 4.2 3B is een dense decoder met drie miljard parameters, gebouwd op Granite-4.1-3B-Base. Het is een redeneermodel met drie modi: een denkmodus die een gedachteketen genereert, een modus met lage inspanning, en een niet-denkmodus die direct antwoordt. IBM rapporteert AIME 2025 op 78,33, GPQA op 54,80, LiveCodeBench v6 op 69,71, MMLU-Pro op 67,84, IFBench op 74,3 en τ³-Bench op 45,8 — allemaal cijfers van de leverancier, geen ervan onafhankelijk gereproduceerd. Bij lange context rapporteert het een RULER van 67,52 bij 64K en 55,30 bij 128K. Artificial Analysis zet de Intelligence Index op 9, wat in absolute termen niets bijzonders is en boven de mediaan voor zijn grootteklasse ligt.

Het hardwareverhaal is het interessante deel. Het draait in zes tot acht gigabyte bij bf16 en onder de twee gigabyte na quantisatie, wat betekent: een laptop, één consumenten-GPU of een CPU met genoeg RAM. Het is alleen tekst, dekt twaalf talen, ondersteunt OpenAI-compatibele tool calling en is beschikbaar in vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX en Ollama. Als je beperking is "moet draaien op een plek waar ik controle over heb", dan voldoet dit model.

SubQ Snap 1.1 is in vrijwel elk opzicht het tegenovergestelde soort product. Het heeft geen gewichten. Het draait alleen via de API van Subquadratic. Het verwerkt tot 384K tokens tekst en afbeeldingen plus een antwoordset van twee tot 255 alternatieven, en retourneert een selectie met een gekalibreerde waarschijnlijkheid. Het kan geen zin schrijven, en dat is juist de bedoeling: er is geen uitvoer om te parsen en geen uitvoer om voor te betalen.

De valstrik van output-tokens

Dit is de rekensom die de vergelijking per token verbergt. Neem een miljoen routeringsbeslissingen, elk met 6.000 tokens aan tickettekst — een plausibel maandelijks volume voor een middelgrote supportorganisatie, of een drukke middag voor een grote. Dat zijn zes miljard invoertokens.

• Granite 4.2 3B in non-thinking-modus — 6B inputtokens tegen $0,03/M is $180, plus ongeveer vijf outputtokens per beslissing, oftewel 5M outputtokens tegen $0,12/M, voor $0,60. Totaal: ongeveer $180,60.

• Granite 4.2 3B in denkmodus — 6B invoer voor $180, plus wellicht 800 redeneertokens per beslissing, of 800M uitvoertokens tegen $0,12/M, voor $96. Totaal: ongeveer $276.

• SubQ Snap 1.1 — 6B invoertokens tegen $0.04/M is $240, en er is helemaal geen uitvoerregel.

Dus het eerlijke antwoord is drie verschillende antwoorden. Geconfigureerd om direct te antwoorden, is Granite 25% goedkoper dan Snap en dan zou het artikel daar echt eindigen. Geconfigureerd om te denken, is Granite 15% duurder dan Snap, omdat reasoning-tokens het duurste onderdeel in de pipeline zijn en niemand ervoor budgetteert. Snaps voordeel was nooit de inputprijs — die is 33% hoger dan die van Granite — het is dat de architectuur geen manier heeft om tokens aan deliberatie te besteden.

Dat is geen theoretisch risico. Het onafhankelijke profiel van Granite 4.2 3B door Artificial Analysis noemt het model "zeer breedsprakig" en vermeldt dat het 92 miljoen outputtokens genereerde tijdens de evaluatie op de Intelligence Index, tegen een mediaan van 67 miljoen voor vergelijkbare modellen. De breedsprakigheid is een gemeten eigenschap van het model in redeneermodus, en het is de eigenschap die bepaalt of het prijsvoordeel per token standhoudt onder een routeringsworkload.

Dat verklaart ook een getal dat op het eerste gezicht verkeerd lijkt. Artificial Analysis positioneert Snap 1.1 op ongeveer $30 per miljoen taken, tegenover $8,4 voor Elephant 9B. Dertig dollar per miljoen taken impliceert een gemiddelde taak die zeer kort is, in de orde van een paar duizend tokens. De benchmarksamenstelling van de Decision Index is kort. Uw tickets, contracten en logs zijn dat niet, en vanaf daar schaalt de kosten lineair met de invoerlengte. Beschouw cijfers per taak als een eigenschap van de benchmark, niet als een prijsopgave.

Waar de 3B echt wint

Goedkopere tokens zijn nog het minste. Granite 4.2 3B kan onder Apache 2.0 zelf worden gehost, wat betekent dat er helemaal geen kosten per aanroep zijn zodra de hardware is betaald, dat er geen data je netwerk verlaat, dat er geen rate limit is en dat er geen leverancier is die de prijs of het model onder je vandaan kan veranderen. Voor een compliance-gebonden workflow is dit geen voorkeur, maar een vereiste, en Snap 1.1 kan die ruimte simpelweg niet betreden.

Het doet ook meer. Het schrijft de samenvatting na de routeringsbeslissing. Het verwerkt tool calls met een schema. Het ondersteunt een optionele contextuitbreiding naar 512K, toegevoegd in een vijfde pretrainingsfase, die op papier langer is dan Snap's 384K — hoewel de RULER-score die daalt van 67,52 bij 64K naar 55,30 bij 128K een duidelijke waarschuwing is over hoeveel van dat venster bruikbaar is. En het is klein genoeg om aan de edge te draaien, in een container naast je applicatie, zonder netwerksprong tussen de beslissing en de actie.

Waar Snap 1.1 echt wint

Drie dingen waarin een 3B-generatief model inherent slecht is.

Kalibratie komt eerst. Snap 1.1 rapporteert een verwachte kalibratiefout van 0,014, een daling ten opzichte van 0,108 in de preview, en een onthoudingspercentage van 86% bij vragen die het niet kan beantwoorden — tegenover een non-hallucinatiescore van 0,7% voor zijn eigen 1.0-release op de proxy van de leverancier. Dat zijn cijfers van de leverancier en moeten als zodanig worden gelezen, maar ze beschrijven een model dat is getraind met onthouding als expliciet doel. Een 3B-redeneermodel heeft geen dergelijk doel. Vraag het of een ticket beantwoordbaar is en het zal hoe dan ook een plausibele zin produceren.

Gedrag met lange context in één doorgang is het tweede. Snap verwerkt 384K tokens in één forward pass met constante rekenkosten per token, wat de volledige rechtvaardiging vormt voor Subquadratic Sparse Attention. Het RULER-verval van Granite is het normale gedrag van een dense model bij tien keer zijn comfortabele lengte. Als je beslissing afhangt van iets dat begraven ligt op positie 200.000 in een logbundel, is het architectuurverschil niet academisch.

Het determinisme van de vorm van de uitvoer is het derde, en het wordt ondergewaardeerd. Snap geeft een getal terug over je lijst met opties. Granite geeft tekst terug die je vervolgens parseert, en elke parser is een plek waar een misvormd antwoord een storing wordt. Beperkte decodering dicht het grootste deel van die kloof, wat het vermelden waard is — het is geen fundamenteel voordeel, het is een verschil in hoeveel scaffolding je schrijft.

De configuratievraag die niemand stelt

Als je Granite 4.2 3B als router gebruikt, is de enkele meest waardevolle wijziging die je kunt doorvoeren het uitschakelen van denken. IBM levert die modus precies om deze reden, en de rekensom hierboven laat zien waarom: een redeneermodel dat wordt gevraagd een van vijf labels te kiezen, besteedt vaak achthonderd tokens aan het rechtvaardigen van een beslissing die een doorloop zonder denken correct krijgt. Benchmark de twee modi op je eigen data voordat je aanneemt dat de denkende beter is. Bij een taak met een vaste set antwoorden is dat vaak niet zo.

De equivalente hefboom bij Snap is het tegenovergestelde: je geeft het minder, scherpere opties. De API staat maximaal zestien vragen en 255 alternatieven per vraag toe, en de nauwkeurigheid op de Decision Index is 20% — lager dan de 32% van d1-ultra — waarbij de indexscore door onthouding wordt gedragen. Beperk de antwoordset en het nauwkeurigheidsprobleem wordt kleiner; leg je het een open beoordeling voor, dan zal het weigeren, terecht, en vaak.

Wat ik daadwerkelijk zou bouwen

Voor een support- of documentpijplijn met een behoorlijk volume is de goedkoopste verdedigbare aanpak een tweetrapsaanpak. Granite 4.2 3B draait in non-thinking-modus als eerstelijnsclassificator voor de gemakkelijke meerderheid — de tickets die overduidelijk over terugbetaling gaan, overduidelijk een storing betreffen, overduidelijk spam zijn — waar een 3B-model nauwkeurig is en marginaal niets kost. Snap 1.1 behandelt de rest: de lange threads, de dubbelzinnige gevallen, de gevallen waarin het juiste antwoord misschien "escaleren" is en een zelfverzekerde gok slechter is dan een weigering. Je betaalt $0,04 per miljoen tokens alleen voor het deel dat het nodig heeft, en je krijgt een gekalibreerde waarschijnlijkheid precies voor de beslissingen waar kalibratie ertoe doet.

Geen van beide leveranciers verkoopt dat ontwerp, want elk van hen wil de hele laag zijn. Granite 4.2 3B staat niet in de catalogus van OrcaRouter — het is Apache 2.0, dus self-hosting is de normale route, en het wordt ook door een aantal inferenceproviders aangeboden. Snap 1.1 is ook niet van ons; het draait via Subquadratic's eigen API. Wat OrcaRouter bijdraagt aan een ontwerp als dit, is de generatielaag erachter: 200+ modellen achter één sleutel, de lijstprijs van de provider doorgegeven tegen 0% opslag, en automatische failover, zodat het model dat de escalatiesamenvatting schrijft niet dezelfde afhankelijkheid is als het model dat besluit te escaleren.

Het punt om in de gaten te houden is of de kalibratie van Snap 1.1 standhoudt wanneer iemand anders het uitvoert. De nauwkeurigheid van 20% is het zwakste cijfer in zijn eigen introductiemateriaal, en dat is precies het cijfer dat bepaalt of het hierboven beschreven tweefasige ontwerp goedkoper is dan het lijkt — hoe vaker Snap geen antwoord geeft, hoe meer werk er terugvalt naar de fase die daadwerkelijk het antwoord moet geven.