SubQ Snap 1.1 対 Granite 4.2 3B：トークンあたりの価格は誤った請求書だ

IBMのGranite 4.2 3Bの定価は100万入力トークンあたり0.03ドル。SubQ Snap 1.1の定価は0.04ドル。トークン単価が請求額そのものであるなら、30億パラメータのApache-2.0モデルは、Artificial Analysis Decision Index v1.0で同率1位となった意思決定モデルを上回り、この記事は短く済んだはずだ。単価は請求額ではない。トークンではなく意思決定単位で価格を算定すると——各モデルが1つの意思決定を生成するために何を出力しなければならないかも含めて——順位は逆転し、単一の設定次第でまた逆転し、最終的にはどちらのベンダーも宣伝していないどこかに落ち着く。

Granite 4.2 3BはIBMの小型高密度推論モデルで、2026年8月25日に8Bおよび30Bの兄弟モデルとともに、異例なほど目立たない形で公開された——ローンチイベントではなく技術ブログ記事によって。Snap 1.1はSubquadraticの意思決定モデルで、2026年10月22日から稼働しており、テキストを生成する代わりに固定の回答セットから1つの選択肢を返す。両者が重なるのは正確に1つのワークロードだけだ。テキストの断片を受け取り、それが何であるかを判断するというもの。それ以外のすべては異なっており、「安価」の意味するところも違う。

まず、その2つのモデルが実際に何であるか。

Granite 4.2 3Bは、Granite-4.1-3B-Baseを基に構築された30億パラメータのdenseデコーダである。推論モデルであり、3つのモードを備える。思考の連鎖を出力する思考モード、低負荷モード、そして直接回答する非思考モードである。IBMはAIME 2025で78.33、GPQAで54.80、LiveCodeBench v6で69.71、MMLU-Proで67.84、IFBenchで74.3、τ³-Benchで45.8を報告しているが、これらはすべてベンダー公表値であり、独立に再現されたものはない。長文脈では、64KでRULER 67.52、128Kで55.30を報告している。Artificial AnalysisはそのIntelligence Indexを9と評価しており、絶対値としては目立たないものの、同サイズクラスの中央値は上回っている。

ハードウェアの話が興味深い部分です。bf16で6～8ギガバイト、量子化すると2ギガバイト未満で動作します。つまり、ラップトップ、単体のコンシューマー向けGPU、または十分なRAMを備えたCPUで動かせます。テキスト専用で、12言語をカバーし、OpenAI互換のツール呼び出しをサポートし、vLLM、SGLang、Transformers、GGUF、llama.cpp、MLX、Ollamaで提供されます。制約が「自分が管理する場所で実行しなければならない」なら、このモデルはそれを満たします。

SubQ Snap 1.1は、ほとんどあらゆる次元で正反対の種類の製品です。重みはありません。SubquadraticのAPI経由でのみ動作します。最大384Kトークン分のテキストと画像、さらに2～255個の選択肢からなる回答セットを受け取り、キャリブレーションされた確率を伴う選択を返します。文章を書くことはできません。それが要点です。解析すべき出力も、支払うべき出力もありません。

出力トークンの罠

トークン単位の比較では見えてこない計算を以下に示します。100万件のルーティング判断があり、それぞれがチケットのテキスト6,000トークンを読み取るとします。これは中規模のサポート運用では月間として妥当な量であり、大規模な運用では忙しい午後1回分に相当する量です。つまり、60億入力トークンになります。

• Granite 4.2 3B の非思考モード — 入力トークン 6B 個は $0.03/M で $180、さらに判断ごとに出力トークン約5個、つまり出力トークン 5M 個は $0.12/M で $0.60。合計：約 $180.60。

• Granite 4.2 3B（思考モード）— 入力6Bで180ドル、さらに意思決定ごとに推論トークンがおそらく800、つまり出力トークン800Mを$0.12/Mで96ドル。合計：約276ドル。

• SubQ Snap 1.1 — 6B入力トークンを$0.04/Mで計算すると$240になり、出力の項目は一切ありません。

正直に言えば、答えは三つに分かれます。直接答えるように設定すると、Granite は Snap より 25% 安く、記事は本当にそこで終わっていたでしょう。考えるように設定すると、Granite は Snap より 15% 高くなります。推論トークンはパイプラインで最も高価なもので、誰もその予算を確保していないからです。Snap の強みは入力料金ではありませんでした——それは Granite より 33% 高いのです——強みは、そのアーキテクチャには熟考にトークンを使う方法がないことです。

それは理論上のリスクではない。Artificial AnalysisによるGranite 4.2 3Bの独立したプロファイルは、同モデルを「非常に冗長」と評し、Intelligence Indexでの評価中に9200万個の出力トークンを生成したと記録している。これは同等モデルの中央値である6700万個に対しての数値だ。この冗長性は推論モードにおけるモデルの測定可能な特性であり、トークン単価の優位性がルーティングワークロードとの接触を経ても維持されるかどうかを決定する特性でもある。

それは、一見すると間違っているように見える数字の説明にもなります。Artificial AnalysisはSnap 1.1を100万タスクあたり約30ドルと位置づけていますが、Elephant 9Bは8.4ドルです。100万タスクあたり30ドルというのは、平均タスクが数千トークン程度の非常に短いことを意味します。Decision Indexのベンチマーク構成は短いものです。あなたのチケット、契約書、ログはそうではなく、そこからコストは入力長に比例して増えます。タスクあたりの数値は見積もりではなく、ベンチマークの性質として扱ってください。

{{1}}3B{{/1}}が本当に勝っているところ

トークン単価が安いことなど、最も些細な問題にすぎません。Granite 4.2 3BはApache 2.0のもとでセルフホストできるため、ハードウェア費用を支払ってしまえば呼び出しごとのコストは一切かからず、データが自社ネットワークの外に出ることも、レート制限も、価格やモデルをこちらに無断で変更するベンダーもありません。コンプライアンスに縛られたワークフローにとって、これは好みの問題ではなく必須要件であり、Snap 1.1はそもそもその領域に足を踏み入れることすらできません。

さらに多くのことも行います。ルーティング判断の後に要約を生成します。スキーマ付きのツール呼び出しを処理します。オプトインの512Kへのコンテキスト拡張をサポートし、これは5回目の事前学習フェーズで追加されました。紙の上ではSnapの384Kより長いものの、RULERスコアが64Kで67.52から128Kで55.30に低下することは、そのウィンドウのどれだけが実際に使えるかについての妥当な警告です。そして、アプリケーションの隣のコンテナ内で、エッジで実行できるほど小さく、判断とアクションの間にネットワークホップはありません。

Snap 1.1 が本当に勝る場面

3B生成モデルが構造上苦手とする3つのこと。

較正が第一だ。Snap 1.1は、期待較正誤差が0.014（プレビュー版の0.108から低下）であり、答えられない質問に対する棄権率が86%だと報告している——ベンダーのプロキシにおける自社の1.0リリースの非ハルシネーションスコア0.7%に対して。これらはベンダーの数値であり、そのように読むべきだが、棄権を明示的な目的として訓練されたモデルを表している。3B推論モデルにはそのような目標はない。チケットが回答可能かどうかを尋ねれば、どちらにせよもっともらしい文を生成する。

長コンテキストでのシングルパス動作が2つ目です。Snap は1回のフォワードパスで384Kトークンを処理し、トークンあたりの計算量は一定です。これこそが Subquadratic Sparse Attention を正当化するすべてです。Granite の RULER 減衰は、快適に扱える長さの10倍の長さにおける密なモデルの通常の挙動です。ログバンドル内の位置200,000に埋もれている何かに判断を左右されるなら、そのアーキテクチャ上の違いは机上の話ではありません。

出力形状の決定性が3つ目であり、これは過小評価されている。Snapは選択肢リスト上の数値を返す。Graniteはテキストを返し、それをあなたが解析する。そしてあらゆるパーサーは、不正な形式の回答が障害になる場所だ。制約付きデコーディングはその差のほとんどを埋める。これは言っておく価値がある——根本的な優位性ではなく、どれだけの足場を書くかという違いである。

誰も尋ねない設定の質問

Granite 4.2 3B をルーターとして実行しているなら、最も価値のある単一の変更は thinking をオフにすることです。IBM がこのモードを出荷しているのはまさにこの理由であり、上記の計算がその理由を示しています。5 つのラベルのうち 1 つを選ぶよう求められた推論モデルは、thinking なしのパスなら正しく判断できる決定を正当化するために、しばしば 800 トークンを費やします。thinking のあるモードの方が優れていると決めつける前に、自分のデータで 2 つのモードをベンチマークしてください。固定された回答集合があるタスクでは、そうでないことが頻繁にあります。

Snapにおける同等のレバーは逆だ。より少なく、より鋭い選択肢を与えるのだ。そのAPIは質問を16個、各質問の選択肢を255個に制限しており、Decision Indexでの精度は20%——d1-ultraの32%より低い——で、指数スコアは棄権によって支えられている。回答集合を狭めれば精度の問題は小さくなる。自由形式の判断を渡せば、それは正しく、そしてしばしば辞退する。

私なら実際に作るもの

実用的な規模のサポートまたはドキュメントパイプラインでは、最も安価で正当化できる設計は2段階構成です。Granite 4.2 3B は非思考モードで、簡単な大多数に対する一次分類器として動作します。つまり、明らかに返金、明らかに障害、明らかにスパムといったチケットであり、そこでは3Bモデルが正確で、限界費用はかかりません。Snap 1.1 は残りを処理します。長いスレッド、曖昧なケース、正解が「エスカレーション」かもしれず、自信のある推測が拒否より悪いケースです。$0.04/100万トークンは必要な一部にのみ支払い、較正が重要なまさにその判断について較正済みの確率を得られます。

どちらのベンダーもその設計を販売していません。各社がレイヤー全体を担いたいと考えているからです。Granite 4.2 3BはOrcaRouterのカタログにはありません。Apache 2.0なのでセルフホスティングが通常の選択肢であり、多数の推論プロバイダーもこれを提供しています。Snap 1.1も当社のものではありません。Subquadratic独自のAPI経由で動作します。このような設計でOrcaRouterが担うのは、その背後にある生成層です：200以上のモデルを1つのキーで利用でき、プロバイダーの定価を0%のマークアップでそのまま提供し、自動フェイルオーバーも実現します、そのため、エスカレーションの要約を書くモデルは、エスカレーションすべきか判断するモデルと同じ依存先にはなりません。

注目すべきは、他の誰かが実行したときにSnap 1.1のキャリブレーションが維持されるかどうかだ。その20%という精度は、自身のローンチ資料の中で最も弱い数字であり、上記の2段階設計が見かけより安くつくかどうかを決める数字でもある。Snapが棄権する頻度が高いほど、実際に回答しなければならない段階に多くの作業が戻ってくる。