生成されたタイトルカードは「LFM2.5-24B-A2B vs Granite 4.2 30B」と表示し、サブタイトルは「スパースなラップトップモデルか、高密度ワークステーションモデルか」で、2つのラベル付きパネルの上にあり、それらには「LFM2.5-24B-A2B:合計24.0B、アクティブ2.45B、lfm1.0ライセンス」および「Granite 4.2 30B:29B dense、すべてのパラメータがアクティブ、Apache 2.0」と表示され、右下にOrcaRouterのロゴがある。
Guides & Insights

LFM2.5-24B-A2B 対 Granite 4.2 30B:スパースなノートPC向けモデルか、それとも密なワークステーション向けモデルか

著者

Alistair Wren

公開日

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

「オープンウェイト」は、LFM2.5-24B-A2BとGranite 4.2 30Bでは、2つの異なる役割を果たしている。Liquid AIのモデルは、2026年10月13日に発表された240億パラメータのMixture-of-Expertsで、トークンごとに2.45Bパラメータを活性化し、ベンダー独自のlfm1.0ライセンスで提供される。IBMのGranite 4.2 30Bは、2026年8月25日にHugging Faceで公開されたdenseなデコーダ専用の推論モデルで、BF16 safetensorsで約290億パラメータ、そのすべてがすべてのトークンで有効になり、Apache 2.0の下で提供される。このうち一方のライセンスは、何の条件も付かない標準的なApache許諾である。もう一方はそうではなく、その違いは、この2つについてあなたが交わしうるあらゆるベンチマーク論争を経てもなお残る。

2つ目の違いは、どんな評価でも隠せない算数の話です。2.45BアクティブのMoEは、すでに手持ちのマシンに合うサイズです。密な29Bモデルは、それを保持できるメモリを備えたGPUを必要とします。そのため、比較は「どちらがより賢いか」というよりも、「これらのうち実際に目の前のハードウェアで動かせるのはどれか」になります。

パラメータの配置場所

LFM2.5-24B-A2Bは、40層が30の二重ゲート付きショートコンボリューションブロックと10のグループ化クエリ注意層に分割され、各ブロックに64のエキスパート、top-4ルーティングを備えています。Liquidは、ローンチ記事の集計で33兆トークン、同じリリースに関するHugging Faceモデルカードの集計では36兆トークンで学習し(この食い違いはどちらの文書でも解消されていません)、その後2段階の中間学習を行い、実際のエージェントハーネス内でのエージェント強化学習で終わる5段階のポストトレーニングパイプラインで仕上げました。コンテキストは131,072トークン、語彙は128,000トークンです。

Granite 4.2 30Bは、Granite-4.1-30B-Baseチェックポイントを基盤に構築された、ルーティングを必要としない単一のデンススタックであり、選択可能な3つの推論モード(<think>タグで囲まれた完全な思考、低負荷の思考、思考なし)でトレーニングされています。128Kのネイティブコンテキストを備え、512Kまでの長コンテキスト拡張が文書化されており、テスト済みの12言語をサポートしています。また、モデルカードでは、タスク全体を通じてtemperature 1.0とtop_p 0.95を推奨しています。

実用的な帰結は、単なるスループットではなく、スループットの形だ。スパースルーティングとは、LFM2.5-24B-A2B がトークンあたり2.45B相当の演算を行うために24Bの重みファイルを読み込むということだ — メモリ帯域には良いが、特に何かに悪いわけではない。密(dense)とは、Granite 4.2 30B が出力する各トークンに対して29Bの作業をフルで行うということだ。ワークロードが短いターンを多数含む長いエージェントループなら、その差は複利的に積み重なる。

ベンダー番号を横に並べ、注意事項を添える

この2つを互いに直接競わせた者は誰もいない。IBMの数値はGranite 4.2のモデルカードに由来し、Liquidの数値はローンチ当日のvLLMの表に由来するが、そこにGraniteは列として現れていない。したがって、以下の行は直接対決ではなく、隣り合わせに置かれた2つの別々のベンダー主張であり、4つのベンチマークのうち2つは重複するが同一ではないハーネスを使用している。

A headless-browser capture of the Hugging Face model page for ibm-granite/granite-4.2-30b, showing the Text Generation tag, the 30B parameter size, the Apache 2.0 licence badge, and the model summary table listing the Granite Team at IBM as developers, a decoder-only dense transformer reasoning architecture, 128K native context with long-context extension to 512K, BF16 precision, twelve tested languages, a built-in think-tag reasoning mode, and a release date of August 25 2026.

• パラメータ — 合計24.0B、うち2.45Bがアクティブ。約29Bのdenseモデルはすべてアクティブ。あなたのハードウェアを決める、たった1つの数値。

• コンテキスト — 131,072トークン対ネイティブ128Kおよび拡張512K。ネイティブウィンドウとほぼ同等。必要ならGraniteの方がさらに拡張できます。

• ライセンス — lfm1.0 対 Apache 2.0。 Apache 2.0 には収益トリガーも用途分野の制限もありません。Liquid の条件を自社の数字と照らし合わせてご確認ください。

• エージェント型ツール使用 — BFCLv4 65.01 対 BFCL v4 61.39。Liquid の数値は自社ハーネスによるもので、IBM の数値は 4.2 のカードによるもの。ほぼ互角であり、その差よりもハーネスの違いの方が重要だ。

• コーディング — SWE-Bench Verified 51.00 対 57.00。Granite のリードであり、パターンに沿っている。LFM2.5-24B-A2B はツール呼び出し型、Granite 4.2 30B はツールも呼び出す推論モデルだ。

• 指示追従 — IFEval 96.75 および IFBench 74.69 に対し IFBench 77.17。どちらも強力です。2社は異なる行のペアを使用しているため、共通する行を比較してください。

GraniteのカードがLiquidのカードでは公開していない詳細を補っている点については、それを推論モデル側の主張として受け取ってよい。AIME 2025は89.17、GPQAは66.41、LiveCodeBench v6は75.77、MMLU-Proは77.60、SciCodeは38.76、RULERは64Kで89.96、128Kで81.38。この最後の2つは、LFM2.5-24B-A2Bがまだ持っていない種類の長コンテキスト証拠だ。Liquidは131Kウィンドウについて、どのコンテキスト長でも検索の数値を公開していない。

A generated two-column scoreboard titled LFM2.5-24B-A2B vs Granite 4.2 30B, the scoreboard. The left column reads total parameters 24.0B, active per token 2.45B, context 131,072 tokens, licence lfm1.0, BFCLv4 65.01 and SWE-Bench Verified 51.00. The right column reads total parameters 29B dense, active per token 29B, context 128K native and 512K extended, licence Apache 2.0, BFCL v4 61.39 and SWE-Bench Verified 57.00, above a footer reading All figures vendor-reported; the two have never been benchmarked against each other.A headless-browser capture of the benchmark section of Liquid AI's launch post for LFM2.5-24B-A2B, showing the sixteen-row table with the LFM2.5-24B-A2B, Qwen3.6-35B-A3B, Gemma-4-26B-A4B-it and Nemotron-3.5-Lightning columns, including the rows AutomationBench 27.69 against 8.72, LiveClaw 48.09 against 38.19, ToolSandbox 80.71 against 75.02 and WebArena Verified 26.75 against 37.62, followed by Liquid's own summary that the model leads or matches on five of eight tool-use and agentic benchmarks.

それぞれを保持することがあなたに何を要するか

LiquidのAPIアクセスは入力トークン100万あたり0.10ドル——キャッシュ利用時は0.05ドル——、出力トークン100万あたり1.00ドルという価格で、同社独自のConsole上で提供され、開始クレジットは2ドル分。だが、ホスト型エンドポイントが本当の製品というわけではない。製品は24B-A2Bのファイルそのものであり、ベンダーが掲げるスループットの数値はすべてオンデバイスでのものだ。Apple M5 Maxで毎秒184トークン、AMD Ryzen AI Max+ 395で毎秒114トークン。いずれもベンダーによる報告であり、再現されたものではない。そして、それらが実際に成り立つかどうかとは別に、アーキテクチャ上の論拠は成り立つ。2.45BアクティブのMoEは、密な29Bモデルにはできない形でユニファイドメモリ上で動作するのだから。

IBMはモデルカード上でトークンあたりの価格を公表していない——Granite 4.2 30Bはセルフホスト型チェックポイントとして位置づけられ、BF16に加えてFP8、NVFP4/MXFP4、GGUFの量子化版として配布されている。総コストとは、およそ29Bの密な重みを保持するために購入またはレンタルしなければならないGPUそのものであり、FP8の密な30Bは、量子化された2.45BアクティブのMoEよりもかなり多くのメモリを要求する。トークンあたりの提供量ベースで見れば、スパースモデルのほうが運用コストは安い。コールドスタートと最悪ケースのレイテンシの観点では、密なモデルにはウォームアップすべきルーティングが存在しない。そのどちらを重視するかは、エンドポイントが常時稼働しているかどうかで完全に決まる。

どちらにもコミットせずにどちらかを試したいなら、両方のルートが存在します。Granite 4.2 30B は Apache 2.0 のもとで自己ホスト可能で、収益上限もありません。そして上記のすべての数値の提供側 — qwen/qwen3.6-35b-a3b と google/gemma-4-26b-a4b-it など — は、当社のカタログ上で1つのキーの背後にあり、各プロバイダー自身の定価に対する0%のマークアップなので、ベンダーの価格変更は、次の請求サイクルではなく、発表されたその日にエンドポイントへ反映されます。

どちらを選ぶべきですか

マシンが制約で、ワークロードがツール呼び出しなら、LFM2.5-24B-A2Bを選べ。ハーネス型の作業が測定される場面で勝ち、ノートPCで扱えるフットプリントで131Kのコンテキストを保持し、Liquidは静的なテストセットではなく実際のエージェントスキャフォールドに対してこれを訓練した——この点は、推論モデルよりもルーターにとって重要だ。選ぶなら、次の2点を受け入れよ:lfm1.0ライセンスはApache 2.0ではないこと、そしてLiquidの外部ではまだ誰もこのチェックポイントを評価していないこと。

ハードウェアがあるなら、行動する前に推論するモデルが必要なら、あるいはライセンスが法務チームにとってすでに馴染みのあるものである必要があるなら、Granite 4.2 30B を選びましょう。コーディングで優位に立ち、2つのうち長文脈検索の数値を公表している唯一のモデルであり、その512K拡張はマーケティング上の売り文句ではなく実際のドキュメントです。そのエージェント関連の数値はより薄く、BFCL v4 で 61.39 対 Liquid の 65.01 です。これはパラメータ数から示唆されるものとはまったく逆であり、密度がもたらすのは推論であって、ツール規律を自動的にもたらすわけではないということを思い出させます。

正直にまとめると、この2つは代替品ではない。LFM2.5-24B-A2B は、クラウド接続のないデバイス上でループを回すモデルとして作られている。Granite 4.2 30B は、問題について徹底的に考え、出荷できることを証明するためのライセンスを備えたモデルとして作られている。両方を持っているなら、ルーティング上の問いはどちらがリクエストを受けるかであり、それはベンチマーク表ではなく、ルーティング層が下すために存在する決定だ。

ライブモデルの停止や性能低下を当社のインシデントアーカイブで追跡し、どのルートが正常にフェイルオーバーしたかを確認できます。