LFM3-1.7B vs Granite 4.2 30B：軸ごとに評価が分かれる2つのエージェントモデル

を同じページに並べるとLFM3-1.7BとGranite 4.2 30B、集計平均はどの行を見るかによって逆方向を指します。Berkeley Function Calling Leaderboard V4では、Liquid AIの17.3億パラメータモデルがIBMの61.39に対して71.39を記録し、約17分の1のモデルが10ポイント勝っています。SWE-bench Verifiedでは、GraniteがLFM3-1.7Bの43.40に対して57.00を記録し、逆方向に13.6ポイント勝っています。ルーティングはプロバイダーの定価にマージンを上乗せしません。プロバイダーの定価は0%のマークアップでそのまま反映されます。

両モデルともエージェント向けに作られており、どちらも2026年に2か月差でリリースされ、両ベンダーが重複するベンチマークを十分に公開しているため、寄せ集めではなく実際の比較が可能だ。それによりこれは珍しい対決となり、興味深い問いはどちらのモデルが優れているかではなく、あなたのワークロードが実際にどの軸にあるかだ。71のBFCLスコアと57のSWE-benchスコアの両方を必要とするタスクはごく少なく、またそうしたタスクはどちらか一方のモデルだけでは十分に対応できない。

交差する2つの数字

Granite 4.2 30Bは2026年8月25日にApache 2.0の下でリリースされた。Granite 4.1 30Bをベースに構築され、約15兆トークンで学習された約300億パラメータのdenseモデルである。IBMはこれをエンタープライズ向けと位置づけている。設定可能な3つの思考モード、OpenAIスキーマに準拠したネイティブなツール呼び出し、テスト済みの12言語、そして複数フェーズのGRPO強化学習で締めくくる3段階のトレーニングパイプラインを備える。

LFM3-1.7Bは2か月後に登場し、2026年10月27日に発表され、エージェント型ハーネスに特化して事後学習された——LiquidはモデルカードでHermes Agent、PI、OpenClawを挙げている。これは256Kコンテキストを持つ1.73Bのdenseモデルであり、汎用推論ではなくローカルエージェントとツール呼び出し向けに明示的に位置づけられている。

ベンチマークの交差は、1つの弱い数値による偶然ではない。LFM3-1.7Bの公開表全体はエージェント寄りだ。71.39 BFCL V4、80.36 ToolSandbox、68.01 τ³-bench、45.60 LiveClaw、38.42 WebArena-Verified。Graniteの表はエンジニアリング寄りだ。57.00 SWE-bench Verified、33.29 SWE-bench Pro、41.89 SWE-bench Multilingual、38.76 SciCode、TerminalBench 2.1では29.24。各ベンダーは「エージェント」の異なる定義に最適化しており、ベンチマーク表はどちらに寄っているかについて正直である。

68.01 対 68.05 の τ³ こそが本当の見出しだ

2つの劇的な差の下に隠れているのは互角の勝負だ。ユーザーシミュレーターとドメインポリシーを用いてマルチターンのタスク完了を測るツール使用評価であるτ³-benchでは、LFM3-1.7Bが68.01、Granite 4.2 30Bが68.05を記録する。その差は0.04点であり、ノイズと区別できない。

これは、どちらの大きな差よりも興味深い結果です。なぜなら、τ³ はほとんどのエージェント配備が実際に行うことに最も近いベンチマークだからです。会話を続け、ポリシーに従い、適切な関数を呼び出し、ミスから回復する。そこで1.73Bモデルが30Bのdenseモデルと同等なら、パラメータ数は有能なマルチターンのツール使用以外の何かを買っていることになります。

それが何をもたらすかは、異なるものを測定するBFCLとSWE-benchに現れる。BFCL V4はスキーマに対する単一ターンの関数呼び出しの正確性を試す——LFM3-1.7Bの71.39は、Liquidが実際のエージェントハーネス上で行ったポストトレーニングが直接功を奏したことを示唆している。SWE-bench Verifiedは実際のGitHub issueをエンドツーエンドで修正することを試すもので、リポジトリをコンテキストに保持し、ファイルをまたいで計画し、テストに通るパッチを生成する必要がある——Graniteの57.00は、それを実行する能力を備えたモデルと、そのために構築されたトレーニングセットを反映している。

つまり、その分かれ方は明確に読み取れる。ツールスキーマで十分に訓練された小規模モデルは、関数呼び出しテストで勝利する。コード修復で訓練された大規模モデルは、リポジトリテストで勝利する。両方が特に訓練されたマルチターンの中間領域では引き分けだ。

コンテキストこそ、仕様が最も大きく分岐する場所だ

• コンテキスト — LFM3-1.7Bは262,144トークン、Granite 4.2 30Bはネイティブ128Kで、512Kまで拡張可能。拡張は無償ではなく、IBMはネイティブウィンドウではなく拡張であると正直に認めている。

• 長文コンテキストの保持 — LFM3-1.7Bは128KのRULERで65.56、同じベンチマークファミリーにおけるGranite 4.2 30Bは81.4でした。より大きなモデルの方が長い文書の内容を多く保持しており、これは見出しのコンテキスト数値が示唆する内容とは逆です。

• フットプリント — BF16ウェイト約30Bに対して4ビットで約1GB、公式のFP8、NVFP4、MXFP4ビルド付き。これは単一GPUモデルであり、ラップトップ向けモデルではありません。

• 言語 — LFM3-1.7Bでは16言語、Graniteではテスト済みの12言語で、重なりは異なります。Graniteの12言語にはチェコ語とオランダ語が含まれ、Liquidの言語にはタイ語、ベトナム語、インドネシア語が含まれます。

• 思考モード — Granite 4.2 30B はフル、低負荷、思考なしの各モードを搭載しています。LFM3-1.7B にはそのようなモードはなく、そのカードにはそもそも複雑な多段階推論を想定していないと記載されています。

• ライセンス — Granite は Apache 2.0、それに対する LFM Open License v1.0 は年間売上1,000万ドル未満なら無償、それを超える場合は商用ライセンスが必要です。

1.73Bにはない、30B denseが払うコストとは

Granite 4.2 30Bは密（dense）モデルです。つまり、300億個のパラメータすべてが各トークンで実行されます。ここにはアクティブパラメータの割引はありません。トークンあたりの計算コストは小モデルの約17倍で、メモリコストは重みファイル全体分です。IBMはそれを扱いやすくするための量子化を提供していますが、これがスマートフォンで動作する構成は存在しません。

LFM3-1.7Bの利点は、主として速度にあるわけではない。モデルがアプリケーションの他の部分と同じメモリ予算に収まることにある。1 GBのモデルなら、同じデバイス上にドキュメントストア、キャッシュ、2つ目のモデルを置く余地が残る——これにより、単に理論上ローカルなだけでなく、実際にローカルエージェントが可能になる。Liquidは、テスト済みハードウェアで前任モデルより1.8～2.8倍高速なデコードと、128Kで1.6 GBのKVキャッシュを報告しており、どちらも長い会話を保持するオンデバイスエージェントにとって重要だ。

これに対する釣り合いを取る要素は、Graniteの30B容量がSWE-benchの数値で実際に効いているということだ。エージェントの仕事がリポジトリ全体にわたってコードを変更することなら、13.6ポイントの差は小さいモデルがプロンプティングで埋め合わせられるものではなく、計算コストの節約はより悪い結果を買うことになる。

ライセンス、署名、および調達に関する課題

Apache 2.0 は、大規模組織が法務レビューなしで Granite 4.2 30B を採用できる理由です。収益のしきい値も、商用トリガーも、交渉もありません。IBM はまた、2026年4月以降、リリースされた Granite モデルに暗号学的署名を付けており、それは些細なことに聞こえますが、本番環境の重みが検証済みの重みであることを証明しなければならない立場になると話は別です。

Liquid's LFM Open License v1.0 は、スタートアップ規模では本当に寛容です——年間売上1,000万ドル未満なら商用利用は無料——しかしそのラインを超えると有償の商用ライセンスが必要になります。個人開発者や小規模チームにとっては問題になりません。大企業内の一事業部門にとっては、最初のデプロイ前に始まり、すぐには終わらないかもしれない協議になります。その非対称性はどのベンチマークにも反映されず、しばしばそれだけで判断を決めてしまいます。

どちらにも賭けずに両方を走らせる

この2つを評価するチームにとって実用的な進め方は、まずどちらか一方を選ぶことではありません。どちらもオープンウェイトであり、独立した評価者による実証はまだありません。つまり、重要な唯一のベンチマークは自社独自のものです。候補モデルを単一のエンドポイント経由でルーティングし、同じエージェントトレースを両方に通し、BFCLやSWE-benchではなく自社のタスクで比較してください。

ここでOrcaRouterは、ホストとしてよりもコントロールサーフェスとして役立ちます：200を超えるモデルにまたがる1つのキーと1つの請求、プロバイダーの定価を0%のマークアップでそのまま適用し、自動フェイルオーバーにより、あるプロバイダーが一時的に不調でも評価実行が中断しないようにします。LFM3-1.7BもGranite 4.2 30Bも現在当社のカタログにはありません。どちらもオープンウェイトのダウンロードであり、それぞれセルフホスティングが道です。ルーティングが真価を発揮するのは周辺スタックです。エージェントがエスカレーションするフロンティアモデルや、ローカルモデルのパッチがテストに失敗したときに比較するセカンドオピニオンです。

誰がどれを取るべきか

LFM3-1.7Bを選ぶべきなのは、エージェントがユーザーのデバイス上で動作する場合、作業がAPIに対するツール呼び出しと構造化抽出である場合、そして256Kのコンテキストと1GBのフットプリントが製品を実現可能にする鍵である場合です。ベンダー自身が「エージェント型コーディング向けではない」と警告している点は受け入れ、必要なケースに備えてより大きなモデルをその後ろに控えさせておきましょう。

Granite 4.2 30B を選びましょうエージェントがコードベースに触れる場合、調達のために Apache 2.0 と署名済みウェイトが必要な場合、ワークロードが設定可能な思考エフォートの恩恵を受ける場合、そしてそれを提供する GPU がある場合です。BFCL の不足分は現実のものですが、範囲は限定的です。単一の呼び出しにおけるスキーマの正確性を測るものであり、よく設計されたツールスキーマを備えた 30B モデルは、実運用ではその差の多くを埋めます。

分割を採用しよう——両ベンダーが目指しているもの、すなわち、1ギガバイト内で定型的なツール呼び出しを処理し、リポジトリ規模の作業をサーバーへエスカレーションするローカルエージェント——を構築しているなら。そのアーキテクチャは、各モデルが自らのベンチマーク表で強いと示しているところでそれぞれのモデルを使い、交差した軸が問題でなくなる唯一の構成だ。

注目に値する問いは、Liquid のエージェント型ポストトレーニングのレシピが、より大きなチェックポイントに転移するかどうかだ。将来の LFM モデルが 71.39 クラスの BFCL 挙動を維持しつつ、リポジトリ作業のための能力を加えれば、軸の分割は崩れ、この比較は単純なサイズの判断になる。それまでは、この2つのモデルは同じ仕事を争っているのではない — 1つのものの2つの半分なのだ。