SubQ Snap 1.1 vs Granite 4.2 3B : le prix par jeton est la mauvaise facture

IBMGranite 4.2 3B est affiché à 0,03 $ par million de jetons d'entrée. SubQ Snap 1.1 est affiché à 0,04 $. Si le tarif par jeton constituait la facture, le modèle Apache-2.0 de 3 milliards de paramètres battrait le modèle de décision qui a terminé à égalité en première position sur l'Artificial Analysis Decision Index v1.0, et cet article serait court. Le tarif n'est pas la facture. Dès que l'on tarifie une décision plutôt qu'un jeton — y compris ce que chaque modèle doit émettre pour en produire une — le classement s'inverse, s'inverse à nouveau selon un seul paramètre de configuration, et aboutit à un résultat qu'aucun des deux fournisseurs ne met en avant.

Granite 4.2 3B est le petit modèle de raisonnement dense d’IBM, publié le 25 août 2026 aux côtés de ses frères 8B et 30B avec étonnamment peu de battage — un article de blog technique plutôt qu’un événement de lancement. Snap 1.1 est le modèle de décision de Subquadratic, en service depuis le 22 octobre 2026, qui renvoie un choix parmi un ensemble de réponses fixe au lieu de générer du texte. Ils se recoupent sur exactement un cas d’usage : prendre un extrait de texte et déterminer de quoi il s’agit. Tout le reste les distingue, y compris ce que signifie « bon marché ».

D'abord, ce que sont réellement les deux modèles

Granite 4.2 3B est un décodeur dense de trois milliards de paramètres construit sur Granite-4.1-3B-Base. C’est un modèle de raisonnement doté de trois modes : un mode réflexion qui émet une chaîne de pensée, un mode à faible effort et un mode sans réflexion qui répond directement. IBM annonce AIME 2025 à 78,33, GPQA à 54,80, LiveCodeBench v6 à 69,71, MMLU-Pro à 67,84, IFBench à 74,3 et τ³-Bench à 45,8 — tous des chiffres du fournisseur, aucun reproduit indépendamment. Sur contexte long, il annonce un RULER de 67,52 à 64K et de 55,30 à 128K. Artificial Analysis place son Intelligence Index à 9, ce qui est sans éclat en termes absolus et supérieur à la médiane de sa classe de taille.

Le volet matériel est la partie intéressante. Il fonctionne avec six à huit gigaoctets en bf16 et moins de deux gigaoctets quantifié, ce qui signifie un ordinateur portable, un seul GPU grand public ou un CPU avec suffisamment de RAM. Il est uniquement textuel, couvre douze langues, prend en charge l’appel d’outils compatible OpenAI et est disponible dans vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX et Ollama. Si votre contrainte est « doit s’exécuter quelque part que je contrôle », ce modèle la satisfait.

SubQ Snap 1.1 est le type de produit opposé dans presque toutes les dimensions. Il n’a pas de poids. Il fonctionne uniquement via l’API de Subquadratic. Il accepte jusqu’à 384 K tokens de texte et d’images, ainsi qu’un ensemble de réponses de deux à 255 alternatives, et renvoie une sélection assortie d’une probabilité calibrée. Il ne peut pas écrire une phrase, et c’est précisément le but : il n’y a aucune sortie à analyser et aucune sortie à payer.

Le piège des jetons de sortie

Voici l’arithmétique que la comparaison par jeton masque. Prenez un million de décisions de routage, chacune lisant 6 000 jetons de texte de ticket — un volume mensuel plausible pour une opération de support de taille moyenne, ou un après-midi chargé pour une grande. Cela fait six milliards de jetons d’entrée.

• Granite 4.2 3B en mode non-thinking — 6B tokens d'entrée à 0,03 $/M, soit 180 $, plus environ cinq tokens de sortie par décision, soit 5 M tokens de sortie à 0,12 $/M, pour 0,60 $. Total : environ 180,60 $.

• Granite 4.2 3B en mode réflexion — 6B en entrée à 180 $, plus peut-être 800 jetons de raisonnement par décision, ou 800M de jetons en sortie à 0,12 $/M, pour 96 $. Total : environ 276 $.

• SubQ Snap 1.1 — 6 milliards de tokens d'entrée à 0,04 $/M, soit 240 $, et il n'y a aucune ligne de sortie du tout.

Donc, la réponse honnête, ce sont trois réponses différentes. Configuré pour répondre directement, Granite est 25 % moins cher que Snap, et l’article s’arrêterait vraiment là. Configuré pour réfléchir, Granite est 15 % plus cher que Snap, parce que les jetons de raisonnement sont l’élément le plus coûteux du pipeline et que personne ne prévoit de budget pour eux. L’avantage de Snap n’a jamais été son tarif d’entrée — il est 33 % plus élevé que celui de Granite — mais plutôt le fait que l’architecture n’a aucun moyen de consacrer des jetons à la délibération.

Ce n’est pas un risque théorique. Le profil indépendant de Granite 4.2 3B établi par Artificial Analysis qualifie le modèle de « très verbeux » et indique qu’il a généré 92 millions de tokens de sortie lors de son évaluation sur l’Intelligence Index, contre une médiane de 67 millions pour des modèles comparables. La verbosité est une propriété mesurée du modèle en mode raisonnement, et c’est cette propriété qui détermine si l’avantage de prix par token survit au contact d’une charge de travail de routage.

Cela explique aussi un chiffre qui semble faux à première vue. Artificial Analysis évalue Snap 1.1 à environ 30 $ par million de tâches, contre 8,4 $ pour Elephant 9B. Trente dollars par million de tâches impliquent une tâche moyenne très courte, de l’ordre de quelques milliers de jetons. Le mélange de benchmarks du Decision Index est court. Vos tickets, contrats et journaux ne le sont pas, et le coût augmente linéairement avec la longueur d’entrée à partir de là. Considérez les chiffres par tâche comme une propriété du benchmark, et non comme un devis.

Là où le 3B gagne véritablement

Le moindre coût des tokens n’est que l’aspect le moins important. Granite 4.2 3B peut être auto-hébergé sous licence Apache 2.0, ce qui signifie : aucun coût par appel une fois le matériel payé, aucune donnée ne quittant votre réseau, aucune limite de débit et aucun fournisseur ne pouvant modifier le prix ni le modèle dans votre dos. Pour un flux de travail soumis à des exigences de conformité, ce n’est pas une préférence, c’est une obligation, et Snap 1.1 ne peut tout simplement pas entrer dans cette catégorie.

Il en fait aussi plus. Il écrit le résumé après la décision de routage. Il gère les appels d’outils avec un schéma. Il prend en charge une extension de contexte optionnelle à 512K, ajoutée lors d’une cinquième phase de pré-entraînement, ce qui est plus long que les 384K de Snap sur le papier — même si la baisse de son score RULER, de 67,52 à 64K à 55,30 à 128K, est un avertissement légitime quant à la part réellement utilisable de cette fenêtre. Et il est assez petit pour tourner en périphérie, dans un conteneur à côté de votre application, sans saut réseau entre la décision et l’action.

Là où Snap 1.1 gagne véritablement

Trois choses pour lesquelles un modèle génératif de 3B est mauvais par construction.

La calibration vient en premier. Snap 1.1 rapporte une erreur de calibration attendue de 0,014, contre 0,108 dans la préversion, et un taux d’abstention de 86 % sur les questions auxquelles il ne peut pas répondre — contre un score de non-hallucination de 0,7 % pour sa propre version 1.0 sur le proxy du fournisseur. Ce sont des chiffres du fournisseur et ils doivent être lus comme tels, mais ils décrivent un modèle entraîné avec l’abstention comme objectif explicite. Un modèle de raisonnement 3B n’a pas un tel objectif. Demandez-lui si un ticket peut être traité et il produira une phrase plausible dans les deux cas.

Le comportement en contexte long à passe unique est le deuxième. Snap traite 384K tokens en une seule passe avant avec un coût de calcul constant par token, ce qui constitue toute la justification de Subquadratic Sparse Attention. La dégradation RULER de Granite est le comportement normal d’un modèle dense à dix fois sa longueur confortable. Si votre décision dépend d’un élément enfoui à la position 200 000 d’un ensemble de journaux, la différence architecturale n’est pas théorique.

Le déterminisme de la forme de sortie est le troisième point, et il est sous-estimé. Snap renvoie un nombre parmi votre liste d’options. Granite renvoie du texte que vous analysez ensuite, et chaque analyseur est un endroit où une réponse malformée se transforme en panne. Le décodage contraint comble l’essentiel de cet écart, ce qui mérite d’être dit — ce n’est pas un avantage fondamental, c’est une différence dans la quantité d’échafaudage que vous écrivez.

La question de configuration que personne ne pose

Si vous utilisez Granite 4.2 3B comme routeur, le changement le plus utile que vous puissiez apporter est de désactiver la réflexion. IBM fournit ce mode précisément pour cette raison, et le calcul ci-dessus montre pourquoi : un modèle de raisonnement à qui l’on demande de choisir l’une de cinq étiquettes dépensera souvent huit cents tokens pour justifier une décision qu’un passage sans réflexion trouve juste. Évaluez les deux modes sur vos propres données avant de supposer que celui avec réflexion est meilleur. Sur une tâche dont l’ensemble de réponses est fixe, ce n’est souvent pas le cas.

Le levier équivalent de Snap est l’inverse : vous lui donnez moins d’options, plus précises. Son API limite les questions à seize et les alternatives à 255 par question, et sa précision sur le Decision Index est de 20 % — inférieure aux 32 % de d1-ultra — le score de l’indice étant porté par l’abstention. Réduisez l’ensemble des réponses et le problème de précision diminue ; soumettez-lui un jugement ouvert et il refusera, à juste titre, et souvent.

Ce que je construirais réellement

Pour un pipeline de support ou de traitement de documents à volume significatif, la conception défendable la moins chère est une architecture en deux étapes. Granite 4.2 3B fonctionne en mode sans réflexion comme classificateur de première passe sur la majorité facile — les tickets qui sont de toute évidence des demandes de remboursement, de toute évidence des signalements de panne, de toute évidence du spam — où un modèle 3B est précis et ne coûte rien à la marge. Snap 1.1 traite le reste : les longs fils de discussion, les cas ambigus, ceux où la bonne réponse pourrait être « escalader » et où une supposition confiante est pire qu’un refus. Vous ne payez 0,04 $ par million de tokens que sur la fraction qui en a besoin, et vous obtenez une probabilité calibrée exactement sur les décisions où la calibration compte.

Aucun des deux fournisseurs ne vend cette architecture, car chacun veut être la couche entière. Granite 4.2 3B ne figure pas au catalogue d'OrcaRouter — il est sous Apache 2.0, donc l'auto-hébergement est la voie normale, et il est également proposé par un certain nombre de fournisseurs d'inférence. Snap 1.1 n'est pas à nous non plus ; il passe par l'API propre à Subquadratic. Ce qu'OrcaRouter apporte à une architecture comme celle-ci, c'est le niveau de génération qui la sous-tend : plus de 200 modèles derrière une seule clé, le prix catalogue du fournisseur répercuté sans marge, et un basculement automatique, de sorte que le modèle qui rédige le résumé d'escalade ne constitue pas la même dépendance que le modèle qui décide d'escalader.

Ce qu'il faut surveiller, c'est de savoir si la calibration de Snap 1.1 tient lorsque quelqu'un d'autre l'exécute. Ses 20 % de précision constituent le chiffre le plus faible de ses propres supports de lancement, et c'est celui qui détermine si la conception à deux étages ci-dessus est moins coûteuse qu'elle n'en a l'air — plus Snap s'abstient fréquemment, plus le travail retombe sur l'étage qui doit réellement répondre.