SubQ Snap 1.1 vs Granite 4.2 3B: il prezzo per token è la bolletta sbagliata

di IBMGranite 4.2 3B è in listino a $0,03 per milione di token di input. SubQ Snap 1.1 è in listino a $0,04. Se la tariffa per token fosse il conto, il modello Apache-2.0 da 3 miliardi di parametri batterebbe il modello decisionale che è arrivato primo a pari merito nell'Artificial Analysis Decision Index v1.0, e questo articolo sarebbe breve. La tariffa non è il conto. Una volta che si applica un prezzo a una decisione anziché a un token — includendo ciò che ciascun modello deve emettere per produrne una — la classifica si ribalta, si ribalta di nuovo a seconda di un'unica impostazione di configurazione, e finisce in un punto che nessuno dei due fornitori pubblicizza.

Granite 4.2 3B è il modello di ragionamento denso e compatto di IBM, rilasciato il 25 agosto 2026 insieme ai fratelli 8B e 30B con insolitamente poco clamore — un post tecnico sul blog anziché un evento di lancio. Snap 1.1 è il modello decisionale di Subquadratic, attivo dal 22 ottobre 2026, che restituisce una scelta da un insieme fisso di risposte invece di generare testo. Si sovrappongono esattamente su un solo carico di lavoro: prendere un blocco di testo e decidere che cos'è. Tutto il resto è diverso, incluso ciò che significa "economico".

Innanzitutto, cosa sono realmente i due modelli

Granite 4.2 3B è un decoder denso da tre miliardi di parametri costruito su Granite-4.1-3B-Base. È un modello di ragionamento con tre modalità: una modalità di pensiero che emette una catena di pensiero, una modalità a basso sforzo e una modalità senza pensiero che risponde direttamente. IBM riporta AIME 2025 a 78,33, GPQA a 54,80, LiveCodeBench v6 a 69,71, MMLU-Pro a 67,84, IFBench a 74,3 e τ³-Bench a 45,8 — tutti dati del fornitore, nessuno riprodotto in modo indipendente. Sul contesto lungo riporta RULER di 67,52 a 64K e 55,30 a 128K. Artificial Analysis colloca il suo Intelligence Index a 9, che è non eccezionale in termini assoluti e superiore alla mediana della sua classe dimensionale.

La parte interessante è la questione hardware. Funziona con sei-otto gigabyte in bf16 e meno di due gigabyte quantizzato, il che significa un laptop, una singola GPU consumer o una CPU con RAM sufficiente. È solo testo, copre dodici lingue, supporta il tool calling compatibile con OpenAI ed è disponibile in vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX e Ollama. Se il tuo vincolo è «deve girare in un posto che controllo», questo modello lo soddisfa.

SubQ Snap 1.1 è il tipo opposto di prodotto in quasi ogni dimensione. Non ha pesi. Funziona solo tramite l'API di Subquadratic. Prende in input fino a 384K token di testo e immagini, oltre a un insieme di risposte da due a 255 alternative, e restituisce una selezione con una probabilità calibrata. Non sa scrivere una frase, ed è proprio questo il punto: non c'è output da analizzare né output da pagare.

La trappola dei token di output

Ecco l’aritmetica che il confronto per token nasconde. Prendiamo un milione di decisioni di instradamento, ognuna delle quali legge 6.000 token di testo dei ticket — un volume mensile plausibile per un’operazione di supporto di medie dimensioni, o un pomeriggio intenso per una di grandi dimensioni. Sono sei miliardi di token di input.

• Granite 4.2 3B in modalità non-thinking — 6B token di input a $0,03/M sono $180, più circa cinque token di output per decisione, ovvero 5M token di output a $0,12/M, per $0,60. Totale: circa $180,60.

• Granite 4.2 3B in modalità di pensiero — 6B di input a $180, più forse 800 token di ragionamento per decisione, oppure 800M token di output a $0,12/M, per $96. Totale: circa $276.

• SubQ Snap 1.1 — 6B token di input a 0,04 $/M equivalgono a 240 $, e non c'è affatto una voce di output.

La risposta onesta è che ci sono tre risposte diverse. Configurato per rispondere direttamente, Granite costa il 25% in meno di Snap e l'articolo finirebbe davvero lì. Configurato per pensare, Granite costa il 15% in più di Snap, perché i token di ragionamento sono la cosa più costosa nella pipeline e nessuno li mette a budget. Il vantaggio di Snap non è mai stata la sua tariffa di input — superiore del 33% a quella di Granite — bensì il fatto che l'architettura non ha alcun modo di spendere token nella deliberazione.

Non è un rischio teorico. Il profilo indipendente di Granite 4.2 3B redatto da Artificial Analysis definisce il modello «molto verboso» e registra che ha generato 92 milioni di token di output mentre veniva valutato sull’Intelligence Index, rispetto a una mediana di 67 milioni per modelli comparabili. La verbosità è una proprietà misurata del modello in modalità di ragionamento, ed è la proprietà che decide se il vantaggio di prezzo per token sopravvive al contatto con un carico di lavoro di routing.

Questo spiega anche un numero che a prima vista sembra sbagliato. Artificial Analysis colloca Snap 1.1 a circa 30 $ per milione di task, contro 8,4 $ per Elephant 9B. Trenta dollari per milione di task implicano un task medio molto breve, nell'ordine di qualche migliaio di token. Il mix di benchmark del Decision Index è breve. I tuoi ticket, contratti e log non lo sono, e da lì il costo cresce linearmente con la lunghezza dell'input. Considera i valori per task come una proprietà del benchmark, non come un preventivo.

Dove il 3B vince davvero

Il prezzo più basso dei token è l'aspetto meno importante. Granite 4.2 3B può essere auto-ospitato con licenza Apache 2.0, il che significa nessun costo per chiamata una volta pagato l'hardware, nessun dato che lascia la tua rete, nessun limite di frequenza e nessun fornitore che possa cambiarti il prezzo o il modello sotto i piedi. Per un flusso di lavoro vincolato alla conformità non è una preferenza, è un requisito, e Snap 1.1 semplicemente non può entrare in quel contesto.

Fa anche di più. Scrive il riepilogo dopo la decisione di routing. Gestisce le chiamate agli strumenti con uno schema. Supporta un'estensione del contesto attivabile su richiesta fino a 512K, aggiunta in una quinta fase di pre-addestramento, che sulla carta è più lunga dei 384K di Snap — anche se il suo punteggio RULER, che scende da 67,52 a 64K a 55,30 a 128K, è un giusto avvertimento su quanto di quella finestra sia effettivamente utilizzabile. Ed è abbastanza piccolo da essere eseguito all'edge, in un container accanto alla tua applicazione, senza alcun salto di rete tra la decisione e l'azione.

Dove Snap 1.1 vince davvero

Tre cose in cui un modello generativo da 3B è scarso per costruzione.

La calibrazione viene per prima. Snap 1.1 riporta un errore di calibrazione atteso di 0,014, in calo da 0,108 nella preview, e un tasso di astensione dell'86% sulle domande a cui non sa rispondere — rispetto a un punteggio di non-allucinazione dello 0,7% per la sua release 1.0 sul proxy del fornitore. Sono numeri del fornitore e vanno letti come tali, ma descrivono un modello addestrato con l'astensione come obiettivo esplicito. Un modello di ragionamento da 3B non ha un obiettivo del genere. Chiedigli se si può rispondere a un ticket e produrrà comunque una frase plausibile.

Il comportamento in singola passata su contesti lunghi è il secondo. Snap elabora 384K token in un'unica passata forward con calcolo costante per token, che è l'intera giustificazione di Subquadratic Sparse Attention. Il decadimento RULER di Granite è il normale comportamento di un modello denso a dieci volte la sua lunghezza confortevole. Se la tua decisione dipende da qualcosa sepolto alla posizione 200.000 in un bundle di log, la differenza architetturale non è accademica.

La determinatezza della forma dell'output è la terza, ed è sottovalutata. Snap restituisce un numero sul tuo elenco di opzioni. Granite restituisce testo che poi devi analizzare, e ogni parser è un punto in cui una risposta malformata diventa un'interruzione del servizio. Il decoding vincolato colma gran parte di questo divario, il che vale la pena dirlo — non è un vantaggio fondamentale, è una differenza nella quantità di scaffolding che scrivi.

La domanda sulla configurazione che nessuno pone

Se stai usando Granite 4.2 3B come router, la singola modifica più preziosa che puoi fare è disattivare il thinking. IBM distribuisce quella modalità proprio per questo motivo, e l'aritmetica di cui sopra mostra perché: un modello di ragionamento a cui viene chiesto di scegliere una tra cinque etichette spesso spende ottocento token per giustificare una decisione che una passata non-thinking azzecca. Esegui il benchmark delle due modalità sui tuoi dati prima di dare per scontato che quella con thinking sia migliore. Su un'attività con un insieme fisso di risposte, spesso non lo è.

La leva equivalente di Snap è l'opposto: gli si forniscono meno opzioni, ma più incisive. La sua API limita le domande a sedici e le alternative a 255 per domanda, e la sua accuratezza sul Decision Index è del 20% — inferiore al 32% di d1-ultra — con il punteggio dell'indice sostenuto dall'astensione. Restringi l'insieme delle risposte e il problema di accuratezza si riduce; affidagli un giudizio aperto e declinerà, correttamente, e spesso.

Quello che costruirei davvero

Per una pipeline di supporto o documentale a volumi significativi, il design più economico e difendibile è quello a due stadi. Granite 4.2 3B viene eseguito in modalità non-thinking come classificatore di primo passaggio sulla maggioranza dei casi facili — i ticket che sono palesemente richieste di rimborso, palesemente interruzioni del servizio, palesemente spam — dove un modello 3B è accurato e non costa nulla al margine. Snap 1.1 gestisce il residuo: i thread lunghi, i casi ambigui, quelli in cui la risposta giusta potrebbe essere «escalation» e una supposizione sicura è peggiore di un rifiuto. Paghi $0,04 per milione di token solo sulla frazione che ne ha bisogno, e ottieni una probabilità calibrata esattamente sulle decisioni in cui la calibrazione conta.

Nessuno dei due fornitori vende quel design, perché ognuno vuole essere l'intero layer. Granite 4.2 3B non è nel catalogo di OrcaRouter — è Apache 2.0, quindi il self-hosting è la via normale, ed è anche offerto da diversi fornitori di inferenza. Anche Snap 1.1 non è nostro; funziona tramite l'API proprietaria di Subquadratic. Ciò che OrcaRouter apporta a un design come questo è il livello di generazione che vi sta dietro: oltre 200 modelli dietro un'unica chiave, prezzo di listino del fornitore passato a markup 0% e failover automatico, così il modello che scrive il riepilogo dell'escalation non è la stessa dipendenza del modello che decide di escalare.

Il punto da tenere d'occhio è se la calibrazione di Snap 1.1 regge quando la esegue qualcun altro. Il suo 20% di accuratezza è il dato più debole nel suo stesso materiale di lancio, ed è quello che decide se il design a due stadi descritto sopra è più economico di quanto sembri — più spesso Snap si astiene, più lavoro ricade sullo stadio che deve effettivamente rispondere.