SubQ Snap 1.1 vs Granite 4.2 3B: O Preço por Token É a Conta Errada

da IBMGranite 4.2 3Bestá listado a US$ 0,03 por milhão de tokens de entrada. SubQ Snap 1.1 está listado a US$ 0,04. Se a tarifa por token fosse a conta, o modelo Apache-2.0 de 3 bilhões de parâmetros venceria o modelo de decisão que empatou em primeiro lugar no Artificial Analysis Decision Index v1.0, e este artigo seria curto. A tarifa não é a conta. Quando você precifica uma decisão em vez de um token — incluindo o que cada modelo precisa emitir para produzir uma — o ranking vira, vira de volta dependendo de uma única configuração, e termina em algum lugar que nenhum dos fornecedores anuncia.

Granite 4.2 3B é o pequeno modelo denso de raciocínio da IBM, lançado em 25 de agosto de 2026 ao lado dos irmãos 8B e 30B com uma fanfarra incomumente pequena — um post técnico em blog, em vez de um evento de lançamento. Snap 1.1 é o modelo de decisão da Subquadratic, disponível desde 22 de outubro de 2026, que retorna uma escolha de um conjunto fixo de respostas em vez de gerar texto. Eles se sobrepõem em exatamente uma tarefa: pegar um trecho de texto e decidir o que ele é. Todo o resto neles é diferente, inclusive o que "barato" significa.

Primeiro, o que os dois modelos realmente são

O Granite 4.2 3B é um decodificador denso de três bilhões de parâmetros construído sobre o Granite-4.1-3B-Base. É um modelo de raciocínio com três modos: um modo de pensamento que emite uma cadeia de raciocínio, um modo de baixo esforço e um modo sem pensamento que responde diretamente. A IBM relata AIME 2025 em 78,33, GPQA em 54,80, LiveCodeBench v6 em 69,71, MMLU-Pro em 67,84, IFBench em 74,3 e τ³-Bench em 45,8 — todos números do fornecedor, nenhum reproduzido de forma independente. Em contexto longo, relata RULER de 67,52 em 64K e 55,30 em 128K. A Artificial Analysis coloca seu Intelligence Index em 9, o que é sem nada de extraordinário em termos absolutos e acima da mediana para sua classe de tamanho.

A parte interessante é a história do hardware. Ele roda com seis a oito gigabytes em bf16 e menos de dois gigabytes quantizado, o que significa um laptop, uma única GPU de consumidor ou uma CPU com RAM suficiente. Ele é somente texto, cobre doze idiomas, suporta chamada de ferramentas compatível com OpenAI e é distribuído em vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX e Ollama. Se sua restrição é "precisa rodar em algum lugar que eu controle", este modelo atende.

O SubQ Snap 1.1 é o tipo oposto de produto em quase todas as dimensões. Não tem pesos. Funciona apenas por meio da API da Subquadratic. Aceita até 384K tokens de texto e imagens, além de um conjunto de respostas de duas a 255 alternativas, e retorna uma seleção com uma probabilidade calibrada. Ele não consegue escrever uma frase, e é essa a questão: não há saída para analisar nem saída pela qual pagar.

A armadilha dos tokens de saída

Eis a aritmética que a comparação por token esconde. Considere um milhão de decisões de roteamento, cada uma lendo 6.000 tokens de texto de ticket — um volume mensal plausível para uma operação de suporte de porte médio, ou uma tarde movimentada para uma grande. Isso equivale a seis bilhões de tokens de entrada.

• Granite 4.2 3B no modo não-pensante — 6B tokens de entrada a $0,03/M custam $180, mais aproximadamente cinco tokens de saída por decisão, ou 5M tokens de saída a $0,12/M, por $0,60. Total: cerca de $180,60.

• Granite 4.2 3B no modo de pensamento — 6B de entrada a $180, mais talvez 800 tokens de raciocínio por decisão, ou 800M tokens de saída a $0,12/M, por $96. Total: cerca de $276.

• SubQ Snap 1.1 — 6B tokens de entrada a $0.04/M são $240, e não há linha de saída alguma.

Então a resposta honesta são três respostas diferentes. Configurado para responder diretamente, o Granite é 25% mais barato que o Snap, e o artigo realmente terminaria aí. Configurado para pensar, o Granite é 15% mais caro que o Snap, porque os tokens de raciocínio são a coisa mais cara do pipeline e ninguém os inclui no orçamento. A vantagem do Snap nunca foi sua taxa de entrada — que é 33% maior que a do Granite — e sim o fato de a arquitetura não ter como gastar tokens com deliberação.

Isso não é um risco teórico. O perfil independente do Granite 4.2 3B feito pela Artificial Analysis classifica o modelo como "muito prolixo" e registra que ele gerou 92 milhões de tokens de saída durante a avaliação no Intelligence Index, contra uma mediana de 67 milhões para modelos comparáveis. A verbosidade é uma propriedade medida do modelo em modo de raciocínio, e é essa propriedade que decide se a vantagem de preço por token sobrevive ao contato com uma carga de trabalho de roteamento.

Isso também explica um número que parece errado à primeira vista. A Artificial Analysis situa o Snap 1.1 em cerca de US$ 30 por milhão de tarefas, contra US$ 8,4 para o Elephant 9B. Trinta dólares por milhão de tarefas implica uma tarefa média muito curta, da ordem de alguns milhares de tokens. A mistura de benchmarks do Decision Index é curta. Seus tickets, contratos e logs não são, e o custo escala linearmente com o comprimento da entrada a partir daí. Trate os números por tarefa como uma propriedade do benchmark, não como uma cotação.

Onde o 3B realmente vence

Tokens mais baratos são o menor dos problemas. O Granite 4.2 3B pode ser auto-hospedado sob a licença Apache 2.0, o que significa nenhum custo por chamada depois que o hardware for pago, nenhum dado saindo da sua rede, nenhum limite de requisições e nenhum fornecedor que possa mudar o preço ou o modelo sob seus pés. Para um fluxo de trabalho vinculado à conformidade, isso não é uma preferência, é um requisito, e o Snap 1.1 simplesmente não pode entrar nesse contexto.

Ele também faz mais. Ele escreve o resumo após a decisão de roteamento. Ele lida com chamadas de ferramentas com um schema. Ele suporta uma extensão opcional de contexto para 512K, adicionada em uma quinta fase de pré-treinamento, que no papel é maior que os 384K do Snap — embora sua pontuação RULER cair de 67,52 em 64K para 55,30 em 128K seja um alerta justo sobre quanto dessa janela é utilizável. E é pequeno o suficiente para rodar na borda, em um contêiner ao lado da sua aplicação, sem salto de rede entre a decisão e a ação.

Onde o Snap 1.1 realmente vence

Três coisas nas quais um modelo generativo de 3B é ruim por construção.

A calibração vem primeiro. O Snap 1.1 relata um erro de calibração esperado de 0,014, abaixo de 0,108 na prévia, e uma taxa de abstenção de 86% em perguntas que não consegue responder — contra uma pontuação de não alucinação de 0,7% para seu próprio lançamento 1.0 no proxy do fornecedor. Esses são números do fornecedor e devem ser lidos como tal, mas descrevem um modelo treinado com a abstenção como objetivo explícito. Um modelo de raciocínio 3B não tem esse tipo de meta. Pergunte se um ticket é respondível e ele produzirá uma frase plausível de qualquer maneira.

O comportamento de passagem única em contexto longo é o segundo. O Snap processa 384K tokens em uma única passagem forward com computação constante por token, o que é a justificativa inteira para a Subquadratic Sparse Attention. A degradação do RULER do Granite é o comportamento normal de um modelo denso a dez vezes seu comprimento confortável. Se sua decisão depende de algo enterrado na posição 200.000 em um pacote de logs, a diferença arquitetural não é acadêmica.

O determinismo da forma da saída é o terceiro, e é subestimado. O Snap retorna um número sobre a sua lista de opções. O Granite retorna texto que você depois analisa, e todo parser é um lugar onde uma resposta malformada vira uma indisponibilidade. A decodificação restrita fecha a maior parte dessa lacuna, o que vale dizer — não é uma vantagem fundamental, é uma diferença na quantidade de estrutura de suporte que você escreve.

A pergunta de configuração que ninguém faz

Se você estiver executando o Granite 4.2 3B como roteador, a mudança mais valiosa que pode fazer é desativar o pensamento. A IBM disponibiliza esse modo exatamente por esse motivo, e a aritmética acima mostra por quê: um modelo de raciocínio ao qual se pede que escolha um entre cinco rótulos frequentemente gasta oitocentos tokens justificando uma decisão que uma passada sem pensamento acerta. Faça benchmark dos dois modos com seus próprios dados antes de presumir que o modo de pensamento é melhor. Em uma tarefa com um conjunto fixo de respostas, muitas vezes ele não é.

O equivalente à alavanca no Snap é o oposto: você lhe dá menos opções, mais precisas. Sua API limita as perguntas a dezesseis e as alternativas a 255 por pergunta, e sua precisão no Decision Index é de 20% — inferior aos 32% do d1-ultra — com a pontuação do índice sustentada pela abstenção. Restrinja o conjunto de respostas e o problema de precisão diminui; entregue-lhe um julgamento aberto e ele recusará, corretamente, e com frequência.

O que eu realmente construiria

Para um pipeline de suporte ou de documentos em volume significativo, o projeto defensável mais barato é o de dois estágios. O Granite 4.2 3B roda em modo sem raciocínio como o classificador de primeira passagem sobre a maioria fácil — os tickets que são obviamente sobre reembolso, obviamente sobre indisponibilidade, obviamente spam —, em que um modelo de 3B é preciso e não custa nada na margem. O Snap 1.1 cuida do resíduo: as conversas longas, os casos ambíguos, aqueles em que a resposta certa pode ser “escalar” e um palpite confiante é pior do que uma recusa. Você paga US$ 0,04 por milhão de tokens apenas na fração que precisa disso, e obtém uma probabilidade calibrada exatamente nas decisões em que a calibração importa.

Nenhum dos fornecedores vende esse design, porque cada um quer ser a camada inteira. O Granite 4.2 3B não está no catálogo do OrcaRouter — é Apache 2.0, então a auto-hospedagem é o caminho normal, e ele também é oferecido por vários provedores de inferência. O Snap 1.1 também não é nosso; ele roda pela própria API da Subquadratic. O que o OrcaRouter acrescenta a um design como esse é a camada de geração por trás dele: mais de 200 modelos atrás de uma única chave, preço de tabela do provedor repassado com 0% de margem e failover automático, então o modelo que escreve o resumo de escalonamento não é a mesma dependência que o modelo que decide escalar.

O ponto a observar é se a calibração do Snap 1.1 se mantém quando outra pessoa o executa. A sua precisão de 20% é o número mais fraco no próprio material de lançamento, e é ele que decide se o design de dois estágios acima é mais barato do que parece — quanto mais vezes o Snap se abstém, mais trabalho recai sobre o estágio que tem de responder efetivamente.