「Liquid AI d1-3B vs Granite 4.2 3B」という見出しのヒーロータイトルカード。サブ見出しは「一方は決定し、一方は書く」。左側には、チェックリストアイコン付きの d1-3B というラベルのカードがあり、キャプション「3.12B - 32,768トークン」と、「確率」「ラベル」「スコア」と表示されたチップがある。右側には、吹き出しアイコン付きの Granite 4.2 3B というラベルのカードがあり、キャプション「3B - 128Kトークン」と、「文章による回答」と表示されたチップがある。
Guides & Insights

Liquid AI d1-3B 対 Granite 4.2 3B:決して同じ仕事をしない2つの3Bモデル

著者

Gideon Frost

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

Liquid AI d1-3B と Granite 4.2 3B を同じ 1 基の GPU に載せれば、どちらも余裕で収まります — 一方は 3.12B パラメータ、もう一方は 3B です。両者はまた、まるで異なる分野から来たかのように振る舞います。IBM 自身のモデルカードが 2026 年 8 月 25 日付としている Granite 4.2 3B は推論モデルです。3 つの思考モード、<think>ブロック、そしてあなたが読む答えがあります。Liquid AI d1-3B は、2026 年 10 月 5 日に Hugging Face にアップロードされ、2 日後に Liquid が発表した意思決定モデルです。状態と明示的な型付き質問の集合を受け取り、1 回のフォワードパスで確率、ラベル、または尺度上の位置を返し、報告する値は output_tokens: 0 です。なぜなら、何も書き出さないからです。有用な問いは、どちらが優れているかではありません。あなたの呼び出しのうち、どれが実際に意思決定なのかです。なぜなら、この 2 つのリポジトリは、その分割の反対側の半分ずつに向けて作られているからです。

各リポジトリには実際に何が入っていますか

以下はすべて、2つのモデルカードとLiquidの発表投稿から来ています。ここにある内容はどれも独立に再現されたものではなく、第三者がどちらのモデルも同じハーネスで評価したこともなく、カード内の数値はベンダー自身によるものです。

• サイズ — Liquid AI d1-3B は合計3.12B、LiquidのLFM2.5-VL-3Bをベースに構築。Granite 4.2 3Bは、granite-4.1-3b-baseをベースに構築された3Bのデコーダーのみの密なトランスフォーマー

• 出力 — d1-3B は確率、ラベル、信頼度を返し、テキストは一切出力しません。Granite 4.2 3B はトークンを生成し、任意の思考の連鎖を <think> タグ

• コンテキスト — d1-3B 32,768トークン、Granite 4.2 3Bはネイティブで128K、カード上では長コンテキスト拡張により512Kまで対応

• 入力 — d1-3B のテキスト、JSON、画像、またはその混在。SigLIP2 NaFlex 400M ビジョンエンコーダーを経由。Granite 4.2 3B はテキストのみ

• ライセンス — d1-3B は Liquid の LFM Open License v1.0 に基づき、Granite 4.2 3B は Apache 2.0 に基づく

• 言語 — d1-3B は 16 言語を記載。Granite 4.2 3B はテスト済みの 12 言語を記載しており、カードにはその他は未テストであると注記されている

• 提供 — d1-3B はカスタムコードを同梱しています(trust_remote_code=True、 transformers>=5.14)。同一ファミリーに GGUF および w8a8 リポジトリがあり、llama.cpp、Ollama、LM Studio 向けのカードが文書化されています。Granite 4.2 3B は vLLM 0.20+ または SGLang 0.5.18+ で、カスタム thinking パーサーとともに動作します

それらの行のうち2つは、他のどれよりも多くの働きをしている。出力行はこの記事の主張そのものであり、ライセンス行は誰も比較表には入れない行だ。

A two-column scoreboard for Liquid AI d1-3B and Granite 4.2 3B. The d1-3B column reads: job answers a typed question; parameters 3.12B; output tokens billed 0; context 32,768 tokens; image input yes; one question 8 ms on an RTX 4090. The Granite 4.2 3B column reads: job writes a reasoned answer; parameters 3B; output tokens billed every token it writes; context 128K, to 512K extended; image input no; one question a full thinking pass. The footer reads 'Both columns vendor-reported, neither independently scored.'

一方は思考の連鎖を書き、もう一方は書くことを拒む

Granite 4.2 3B は、思考を声に出して示すことでその価値を発揮する。そのカードには 3 つのモードが記載されている。デフォルトで思考オン、非思考、そして推論トレースは保持しつつ短縮する低努力モードだ。サービングスタックはトレースを最終回答から分離するので、アプリケーションはクリーンなコンテンツと別個の推論フィールドを受け取る。これは、解き進める必要がある問い——数学の問題、論理の分岐、評価できるようになる前に書かねばならないコード——にとって良い設計だ。

d1-3B にはそのようなモードはなく、付属のカードにもこう率直に記されています。「これはチャットモデルではなく、テキストを書きません」。呼び出しでは、質問を型とともに宣言します。noul ははい/いいえを返し、P(yes) を 0 から 1 の間の値として返します。choice は名前付きの選択肢集合から 1 つのラベルを選び、そのラベル、信頼度、および選択肢ごとの確率を返します。score は状態を 2〜10 段階の順序尺度上に位置づけ、期待されるレベルをその分布と凡例とともに返します。シグナルは 1 回のパスでプレースホルダー位置のロジットから読み取られるのであり、トークンごとにサンプリングされるのではありません。だからこそ使用量ブロックは、嘘をつかずに出力トークン数ゼロを報告できるのです。

その違いは、精度を変える前に、まず請求額を変える。400トークン分思考する Granite の分類呼び出しは、400出力トークンを支払う呼び出しであり、欲しかったラベルは、その後パーサーが取り出さなければならない散文の中に埋もれている。d1-3B の呼び出しは入力のみを課金する。トラフィックの大半がルール付きのラベルであるなら、その推論がラベルを変えたかどうかに関係なく、あなたは推論に対して支払い続けてきたことになる。

Granite 4.2 3Bの方が明らかに良い選択となる場合

推論ベンチマークを額面通りに受け取るなら——それらはIBM自身のもので、社内のNeMo Evaluatorパイプラインを通じて実行されており、外部の第三者による再現はなされていない——、3Bはそのサイズにしては異例に強い:AIME25 78.33、HMMT February 2025 66.67、GPQA 54.80、LiveCodeBench v6 69.71、MMLU-Pro 67.84、IFBench 74.33、BFCL v4 52.41、tau3-bench 45.78、そしてRULER 64Kは67.52で、128Kでは55.30に低下する。

そのリストからは4つのジョブが導かれ、d1-3B はそのいずれにも含まれていない。

• 128Kネイティブのコンテキスト、512Kまで拡張可能、d1-3Bの32,768トークンに対して — あなたのステートが長いドキュメントなら、選択はおのずと決まる

• OpenCode、Pi、OpenHands 向けの文書化されたパーサーとハーネス統合を備えたエージェント型ツール呼び出し。決定モデルにはこれに相当するものがない

• 回答が段落となるあらゆるタスク:要約、下書き、自由形式の構造への抽出、コード生成

• Apache 2.0 には閾値条項がないため、収益上限なしでファインチューニングと再配布が可能

Graniteカードに載っていないものに注目してください。SWE-BenchとTerminal-Benchの行は、3BではNAと記されています。IBMのエージェント型強化学習の段階は、このファミリーの8Bと30Bのモデルにのみ適用されたため、最小のモデルは、より大きな兄弟モデルが持つエージェントスコアを備えていません。「Granite 4.2」を見て、3Bがファミリーのエージェントプロファイルを継承していると想定するチームは、驚くことになるでしょう。

A capture of Liquid AI's own blog post 'Open d1: Edge decision models for text, vision, and audio' dated Oct 7, 2026, showing the opening paragraph that releases d1-3B and d1-omni-600M as open-weight models, d1-3B's Decision Index score of 48.57 and the claim that it is ahead of every model under 10B, and its latency of 8 ms on an NVIDIA GeForce RTX 4090, 16 ms on a Jetson AGX Thor and 26 ms on a Jetson AGX Orin.

{{2}}Granite{{/2}}が考え終わる前に{{1}}d1-3B{{/1}}が勝つ場面

Liquid自身のレイテンシ表は、ウォーム状態で、一度に1リクエストずつ測定したもので、その主張の最も強力な部分だ。単一の質問がRTX 4090で8 ms、AMD MI325Xで9 ms、Jetson AGX Thorで16 ms、Jetson AGX Orin 64GBで26 msで、64状態を1パスに詰め込んで4090では475/秒、MI325Xでは1,106/秒。規模感を示すと、これはGranite 4.2 3Bが推論トレースの数トークンを出力するのにおよそ要する時間だ。

d1-3Bでは、1つの状態に対する3種類の質問が、4090上で3回の個別呼び出しではなく21 msで済む。状態とその画像がすべての質問に対して一度だけ読み込まれるからだ。かつてルールごとに1つのHTTPリクエストを発行していたモデレーションやルーティングのスタックでは、これは呼び出しの行列と1回の呼び出しの違いである。

また、見ることもできる。d1-3Bは11の公開画像ベンチマークで平均74.1を記録し、ベースモデルの73.9と対比される。また、カードには、画像を取り除くと同一の質問のスコアが45.1になると記されており、答えはテキストプロンプトからではなく画像から得られている。個々の行はどちらにも振れる(CV-Benchは82.1でベースモデルの87.6に対して、POPEは88.5で90.1に対して)ため、視覚に関する主張は「ベースモデルと同等」であり、「それより優れている」ではない。

正直なカウンターウェイト:d1-3B の Decision Index 0.2.1 における 48.57 は、リーダーボードへの提出によるものではなく、Liquid が公式スコアラー自体を実行して算出したものだ。また、競合する行は公開リーダーボードから来ている。8つのベンチマーク・アズ・デシジョンタスクにわたるその平均 77.1 と、DecisionBench での 71.8 も同様にファーストパーティによるものである。この比較の d1 側にあるものはすべて未検証である。

A capture of the Hugging Face model card for ibm-granite/granite-4.2-3b, showing the Apache 2.0 licence, the 3B parameter count, the decoder-only dense architecture built on Granite-4.1-3B-Base, the 128K native context with long-context extension to 512K, bfloat16 precision, the tested-language list and the built-in chain-of-thought reasoning mode.

なぜ3Bのreasonerは3Bの意思決定モデルではないのか

魅力的に映るのは、Granite 4.2 3B を d1-3B の安価な代替品として扱うこと、あるいはその逆だ。どちらも失敗するが、その失敗は品質の問題ではなく構造的なものである。

Granite に判断を求めると、解析しなければならない生成結果、モデルがその質問をどれほど難しいと感じたかに応じて膨らむ請求、そして選択した思考モードに依存するレイテンシが返ってくる。d1-3B に推論を求めても、何も得られない — 推論するためのトークンストリームが存在しないからだ。この2つのモデルは、ほとんどのパイプラインが1リクエストにつき何度もまたぐ線の両側に位置している。何かが判断を下し、何かが話さなければならない。d1-3B は前段に属し、そこでトリアージルールが経路を選び、較正済みの信頼度を返す。Granite 4.2 3B はその後ろ、答えを書き出す必要がある分岐に属する。

2つ目は、より静かな罠だ。意思決定モデルの価値はキャリブレーション、つまり0.9という信頼度が10回中9回は正しいことにある。Granite 4.2 3Bのカードはキャリブレーション指標も確率も公表しておらず、公表しているのは精度と推論のスコアだけだ。ベンチマークのリーダーボードで両者を比較しても、閾値を扱うときにどちらを信頼すべきかは何も分からない。

誰も表に入れないライセンスの一行

Granite 4.2 3B は Apache 2.0 の下で提供されています。d1-3B は LFM Open License v1.0 の下で提供されており、これは第5条までは寛容に読めます。商用利用は、あなたまたはあなたの法人が、同じ文書で年間収益1,000万米ドル以上と定義される閾値を下回っていることを条件に許諾され、その線を超える商用利用は単にライセンスされていません。非営利団体および研究利用者は除外されています。

趣味で使う人やスタートアップにとって、これは問題にならない。年度途中でその一線を越える企業 — あるいはそうした企業に買収される可能性のある企業 — にとって、2つのリポジトリは、パラメータ数がどれほど似て見えても、等価な成果物ではない。そしてライセンスレビューは、誰かがすでにプロトタイプを出荷したずっと後に行われることになる。これは、このページにある中で、早い段階で確認するのに最もコストが低い項目だ。

ペアを1つのパイプラインとして実行する

どちらのモデルも本日時点で当社のカタログには掲載されていないため、これは可用性についての主張ではありません。どちらもセルフホスト型のアーティファクトであり、特にGranite 4.2 3Bはそのカードに推論プロバイダーが一切記載されていません。しかし、チームが実際に行き着くパターンは、意思決定を行う呼び出しと発話を行う呼び出しの2つであり、そのパターンこそ、ルーティング層が存在意義を得る場所です。OrcaRouterは200以上のモデルを1つのAPIキーの背後に置き、プロバイダーの定価を0%のマークアップでそのままパススルーするという仕組みを採用しており、そのため、ベンダーの値下げは次の契約更新時ではなく当日に請求に反映されます。また、プロバイダー間の自動フェイルオーバーは、パイプラインの中央にある共有コンポーネントが、まだそれを評価している間に単一障害点になることはないということを意味します。セルフホスト型デプロイを決める前に、自社トラフィック上でd1-3Bをホスト型の汎用モデルとA/Bテストしたいなら、Graniteの系譜に最も近いルーティング可能な隣接モデルはGemma 4 31Bで、100万入力トークンあたり$0.13、100万出力トークンあたり$0.38です — はるかに大規模なモデルですが、パイプラインにおいては同じ「書く汎用モデル」の役割を担います。

規則として述べられた評決

必要なのが判断——スパムかどうか、どのキューか、どれほど緊急か、この画像がその説明と一致するか——なら、それを1回のパスでこなす唯一の存在が d1-3B で、しかも1桁ミリ秒でやってのける。必要なのが書かれた回答、長い文書の読解、ツール呼び出し、あるいはコードなら、そもそもトークンストリームを備えているのは Granite 4.2 3B のほうであり、3B の推論スコアはそのサイズにしては本当に印象的だ——IBM の評価では、まだ誰も確認していないけれど。

状況を変えるのは、新しいベンチマークの一行ではない。第三者が両モデルを同じキャリブレーションハーネスで採点することだ。なぜなら、モデルにしきい値を設定できるかどうかを決める特性は、今日、どちらのモデルカードでも比較できないものだからだ。