SubQ Snap 1.1 vs. Granite 4.2 3B: Der Preis pro Token ist die falsche Abrechnung

IBMs Granite 4.2 3B kostet 0,03 $ pro Million Eingabe-Tokens. SubQ Snap 1.1 kostet 0,04 $. Wäre der Tokenpreis der Rechnungsbetrag, würde das Apache-2.0-Modell mit 3 Milliarden Parametern das Entscheidungsmodell schlagen, das im Artificial Analysis Decision Index v1.0 punktgleich den ersten Platz belegte, und dieser Artikel wäre kurz. Der Tokenpreis ist nicht der Rechnungsbetrag. Sobald man eine Entscheidung statt eines Tokens bepreist — einschließlich dessen, was jedes Modell ausgeben muss, um eine zu erzeugen —, kippt das Ranking, kippt je nach einer einzigen Konfigurationseinstellung wieder zurück und endet an einem Punkt, mit dem keiner der Anbieter wirbt.

Granite 4.2 3B ist IBMs kleines dichtes Reasoning-Modell, das am 25. August 2026 zusammen mit den Geschwistern 8B und 30B mit ungewöhnlich wenig Aufhebens veröffentlicht wurde – ein technischer Blogbeitrag statt einer Launch-Veranstaltung. Snap 1.1 ist Subquadratics Entscheidungsmodell, live seit dem 22. Oktober 2026, das eine Auswahl aus einer festen Antwortmenge zurückgibt, statt Text zu generieren. Sie überschneiden sich in genau einem Arbeitslastfall: einen Textabschnitt zu nehmen und zu entscheiden, was er ist. Alles andere an ihnen ist anders, einschließlich der Bedeutung von „günstig“.

Zuerst einmal, was die beiden Modelle eigentlich sind

Granite 4.2 3B ist ein dichter Decoder mit drei Milliarden Parametern, der auf Granite-4.1-3B-Base aufbaut. Es ist ein Reasoning-Modell mit drei Modi: einem Denkmodus, der eine Gedankenkette erzeugt, einem Modus mit geringem Aufwand und einem Nicht-Denk-Modus, der direkt antwortet. IBM gibt AIME 2025 mit 78,33 an, GPQA mit 54,80, LiveCodeBench v6 mit 69,71, MMLU-Pro mit 67,84, IFBench mit 74,3 und τ³-Bench mit 45,8 – alles Herstellerangaben, keine davon unabhängig reproduziert. Bei langem Kontext meldet es RULER von 67,52 bei 64K und 55,30 bei 128K. Artificial Analysis setzt seinen Intelligence Index auf 9, was in absoluten Zahlen unspektakulär ist und über dem Median seiner Größenklasse liegt.

Der Hardware-Aspekt ist der interessante Teil. Es läuft mit sechs bis acht Gigabyte in bf16 und unter zwei Gigabyte quantisiert, was bedeutet: ein Laptop, eine einzelne Consumer-GPU oder eine CPU mit genügend RAM. Es ist rein textbasiert, deckt zwölf Sprachen ab, unterstützt OpenAI-kompatibles Tool-Calling und ist in vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX und Ollama verfügbar. Wenn Ihre Einschränkung lautet „muss irgendwo laufen, wo ich die Kontrolle habe“, erfüllt dieses Modell sie.

SubQ Snap 1.1 ist in nahezu jeder Hinsicht die entgegengesetzte Art von Produkt. Es hat keine Gewichte. Es läuft ausschließlich über die API von Subquadratic. Es nimmt bis zu 384K Tokens aus Text und Bildern sowie eine Antwortmenge von zwei bis 255 Alternativen entgegen und liefert eine Auswahl mit einer kalibrierten Wahrscheinlichkeit zurück. Es kann keinen Satz schreiben, und genau das ist der Punkt: Es gibt keine Ausgabe zu parsen und keine Ausgabe, für die gezahlt werden muss.

Die Output-Token-Falle

Hier ist die Rechnung, die der Vergleich pro Token verbirgt. Nehmen wir eine Million Routing-Entscheidungen, von denen jede 6.000 Tokens Tickettext liest – ein plausibles Monatsvolumen für einen mittelgroßen Supportbetrieb oder ein geschäftiger Nachmittag für einen großen. Das sind sechs Milliarden Eingabe-Tokens.

• Granite 4.2 3B im Nicht-Denkmodus — 6 Mrd. Eingabe-Tokens zu 0,03 $/Mio. sind 180 $, plus ungefähr fünf Ausgabe-Tokens pro Entscheidung, also 5 Mio. Ausgabe-Tokens zu 0,12 $/Mio., für 0,60 $. Gesamt: etwa 180,60 $.

• Granite 4.2 3B im Thinking-Modus — 6B Eingabe zu $180, plus vielleicht 800 Reasoning-Tokens pro Entscheidung oder 800M Ausgabe-Tokens zu $0.12/M für $96. Gesamt: etwa $276.

SubQ Snap 1.1 — 6 Mrd. Input-Tokens zu 0,04 $/Mio. sind 240 $, und es gibt überhaupt keine Output-Zeile.

Die ehrliche Antwort sind also drei verschiedene Antworten. Auf direkte Antworten konfiguriert ist Granite 25 % günstiger als Snap, und der Artikel würde wirklich dort enden. Auf Denken konfiguriert ist Granite 15 % teurer als Snap, weil Reasoning-Tokens das Teuerste in der Pipeline sind und niemand sie einplant. Der Vorteil von Snap war nie sein Eingabepreis – er liegt 33 % höher als der von Granite –, sondern dass die Architektur keine Möglichkeit hat, Tokens fürs Abwägen auszugeben.

Das ist kein theoretisches Risiko. Das unabhängige Profil von Artificial Analysis zu Granite 4.2 3B bezeichnet das Modell als „sehr wortreich“ und verzeichnet, dass es bei der Evaluierung auf dem Intelligence Index 92 Millionen Ausgabe-Tokens erzeugte, gegenüber einem Median von 67 Millionen bei vergleichbaren Modellen. Die Ausführlichkeit ist eine gemessene Eigenschaft des Modells im Reasoning-Modus, und sie ist die Eigenschaft, die entscheidet, ob der Preisvorteil pro Token einer Routing-Workload standhält.

Das erklärt auch eine Zahl, die auf den ersten Blick falsch erscheint. Artificial Analysis beziffert Snap 1.1 auf rund 30 US-Dollar pro Million Aufgaben, gegenüber 8,4 US-Dollar für Elephant 9B. Dreißig Dollar pro Million Aufgaben implizieren eine sehr kurze durchschnittliche Aufgabe, in der Größenordnung von einigen tausend Tokens. Der Benchmark-Mix des Decision Index ist kurz. Ihre Tickets, Verträge und Logs sind es nicht, und die Kosten skalieren von dort aus linear mit der Eingabelänge. Betrachten Sie Pro-Aufgabe-Werte als Eigenschaft des Benchmarks, nicht als Preisangabe.

Wo die 3B wirklich gewinnt

Günstigere Tokens sind dabei noch das geringste Problem. Granite 4.2 3B kann unter Apache 2.0 selbst gehostet werden, was bedeutet, dass überhaupt keine Kosten pro Aufruf entstehen, sobald die Hardware bezahlt ist, dass keine Daten Ihr Netzwerk verlassen, dass es kein Rate Limit gibt und dass es keinen Anbieter gibt, der Ihnen den Preis oder das Modell unter den Füßen wegziehen kann. Für einen an Compliance gebundenen Workflow ist das keine Präferenz, sondern eine Voraussetzung, und Snap 1.1 kann diesen Raum schlicht nicht betreten.

Es kann auch mehr. Es schreibt die Zusammenfassung nach der Routing-Entscheidung. Es verarbeitet Tool-Aufrufe mit einem Schema. Es unterstützt eine Opt-in-Kontexterweiterung auf 512K, die in einer fünften Vortrainingsphase hinzugefügt wurde und auf dem Papier länger ist als Snaps 384K – allerdings ist sein RULER-Score, der bei 64K von 67,52 auf 55,30 bei 128K fällt, eine berechtigte Warnung dazu, wie viel von diesem Fenster nutzbar ist. Und es ist klein genug, um am Edge zu laufen, in einem Container neben Ihrer Anwendung, ohne Netzwerk-Hop zwischen Entscheidung und Aktion.

Wo Snap 1.1 wirklich gewinnt

Drei Dinge, in denen ein generatives 3B-Modell konstruktionsbedingt schlecht ist.

Kalibrierung ist das Erste. Snap 1.1 meldet einen erwarteten Kalibrierungsfehler von 0,014 – gegenüber 0,108 in der Vorschau – und eine Enthaltungsrate von 86 % bei Fragen, die es nicht beantworten kann; dem steht ein Nicht-Halluzinations-Wert von 0,7 % für sein eigenes 1.0-Release im Proxy des Anbieters gegenüber. Das sind Anbieterzahlen, und sie sollten auch so gelesen werden, doch sie beschreiben ein Modell, das mit Enthaltung als explizitem Ziel trainiert wurde. Ein 3B-Reasoning-Modell hat kein solches Ziel. Fragt man es, ob ein Ticket beantwortbar ist, erzeugt es so oder so einen plausiblen Satz.

Das Verhalten bei langem Kontext in einem einzigen Durchlauf ist der zweite Punkt. Snap verarbeitet 384K Token in einem einzigen Vorwärtsdurchlauf mit konstantem Rechenaufwand pro Token, was die gesamte Rechtfertigung für Subquadratic Sparse Attention ist. Granites RULER-Decay ist das normale Verhalten eines dichten Modells bei zehnmal seiner komfortablen Länge. Wenn Ihre Entscheidung von etwas abhängt, das an Position 200.000 in einem Log-Bundle vergraben ist, ist der Architekturunterschied nicht akademisch.

Die Determiniertheit der Ausgabeform ist der dritte Punkt, und sie wird unterschätzt. Snap liefert eine Zahl über deiner Optionsliste zurück. Granite liefert Text zurück, den du anschließend parst, und jeder Parser ist eine Stelle, an der eine fehlerhafte Antwort zu einem Ausfall wird. Constrained Decoding schließt den größten Teil dieser Lücke, was erwähnenswert ist – es ist kein fundamentaler Vorteil, sondern ein Unterschied darin, wie viel Gerüstcode du schreibst.

Die Konfigurationsfrage, die niemand stellt

Wenn Sie Granite 4.2 3B als Router betreiben, ist die mit Abstand wertvollste Änderung, die Sie vornehmen können, das Denken abzuschalten. IBM liefert diesen Modus genau aus diesem Grund mit, und die obige Rechnung zeigt, warum: Ein Reasoning-Modell, das eines von fünf Labels auswählen soll, verbraucht oft achthundert Tokens darauf, eine Entscheidung zu begründen, die ein Durchlauf ohne Denken richtig hinbekommt. Benchmarken Sie die beiden Modi mit Ihren eigenen Daten, bevor Sie annehmen, dass der denkende besser ist. Bei einer Aufgabe mit einer festen Antwortmenge ist er das häufig nicht.

Snaps entsprechender Hebel ist das Gegenteil: Man gibt ihm weniger, schärfere Optionen. Seine API begrenzt Fragen auf sechzehn und Alternativen auf 255 pro Frage, und seine Genauigkeit beim Decision Index liegt bei 20 % – niedriger als die 32 % von d1-ultra –, wobei die Indexpunktzahl durch Enthaltung getragen wird. Verengt man die Antwortmenge, schrumpft das Genauigkeitsproblem; übergibt man ihm ein offenes Urteil, wird es ablehnen – zu Recht und oft.

Was ich tatsächlich bauen würde

Für eine Support- oder Dokumentenpipeline mit nennenswertem Volumen ist das günstigste vertretbare Design ein zweistufiges. Granite 4.2 3B läuft im Non-Thinking-Modus als First-Pass-Klassifikator für die einfache Mehrheit – die Tickets, die eindeutig Erstattung, eindeutig Ausfall, eindeutig Spam sind –, bei der ein 3B-Modell präzise ist und marginal nichts kostet. Snap 1.1 übernimmt den Rest: die langen Threads, die mehrdeutigen Fälle, diejenigen, bei denen die richtige Antwort „eskalieren“ sein könnte und eine selbstsichere Vermutung schlechter ist als eine Ablehnung. Sie zahlen 0,04 US-Dollar pro Million Tokens nur für den Bruchteil, der es braucht, und Sie erhalten eine kalibrierte Wahrscheinlichkeit genau für die Entscheidungen, bei denen Kalibrierung zählt.

Keiner der beiden Anbieter verkauft dieses Design, weil jeder die gesamte Ebene sein möchte. Granite 4.2 3B ist nicht im Katalog von OrcaRouter – es ist Apache 2.0, daher ist Self-Hosting der übliche Weg, und es wird auch von einer Reihe von Inferenzanbietern angeboten. Snap 1.1 ist auch nicht von uns; es läuft über Subquadratics eigene API. Was OrcaRouter zu einem solchen Design beiträgt, ist die Generierungsebene dahinter: 200+ Modelle hinter einem Schlüssel, Anbieter-Listenpreis zu 0 % Aufschlag durchgereicht und automatisches Failover, sodass das Modell, das die Eskalationszusammenfassung schreibt, nicht dieselbe Abhängigkeit darstellt wie das Modell, das entscheidet, zu eskalieren.

Worauf man achten muss, ist, ob die Kalibrierung von Snap 1.1 hält, wenn jemand anderes es ausführt. Seine 20 % Genauigkeit sind die schwächste Zahl im eigenen Launch-Material, und sie ist diejenige, die entscheidet, ob das oben beschriebene zweistufige Design billiger ist, als es aussieht — je häufiger Snap sich zurückhält, desto mehr Arbeit fällt an die Stufe zurück, die tatsächlich antworten muss.