LFM3-1.7B vs MiniCPM5-2B：Liquidの23対4スコアボードを検証

2026年10月27日、Liquid AIはLFM3-1.7BとMiniCPM5-2Bを対決させた27行のベンチマーク表を公開した。Liquidのモデルはそのうち23行で勝利する。MiniCPM5は4勝だ。この勝ち数はすぐに広まったが、それが問題である。なぜなら、あるベンダーがベンチマークを選び、ハーネスを書き、両モデルを実行した表から抽出できる情報として、勝ち数は最も情報量の少ないものだからだ。これは、その23–4が実際に何を語っているかを検証するものであり、まず一つの告白から始まる。Liquidが暗に反論している比較は、このブログで一日前に公開されており、その記事はまさにこの論点を提示しなかった。あの記事は2つのベースチェックポイントを比較し、どちらにも使える評価はないと結論づけた。こちらは両者に事後学習済みの重みを載せた版である。

MiniCPM5-2Bは、OpenBMBの2.52BのDense推論モデルで、2026年9月上旬にApache 2.0の下でリリースされました。LFM3-1.7Bは、Liquid AIの1.73Bのテキストおよびエージェントモデルで、2026年10月27日にLFM Open License v1.0の下で公開されました。両者は同じパラメータ規模であり、同じオンデバイス枠を争っており、明らかに異なる用途のために作られています。

2つのベンダー、2つのハーネス、1つの表

23–4という数字が存在するのは、Liquidが競合他社を再実行したからにすぎない。ローンチ時にそうするのは正当であり、異例なほど厳密なことだ——ほとんどのベンダーは公開リーダーボードの数値と比較し、その足場は明示しない。しかし、自社のハーネスで競合他社を再実行しても中立的な結果にはならず、その証拠は同じベンチマークが両ベンダーのカードに現れる行にある。

BFCL V4を取り上げよう。LiquidはMiniCPM5-2Bを62.65と測定している。OpenBMB自身のモデルカードでは66.6と報告している。Humanity's Last Examを取り上げよう。LiquidはMiniCPM5で8.20を得ており、OpenBMBは8.9と主張している。これらの差は小さく、0～100スケールで4ポイント以内であり、標準化されたベンチマークではハーネスの違いは控えめであることを示唆している。次にSWE-bench Verifiedを取り上げよう。ここではOpenBMBがMiniCPM5-2Bで46.4を報告し、LiquidがLFM3-1.7Bで43.40を報告している。この2つの数値を並べるとMiniCPM5が勝つ。Liquid自身のMiniCPM5の行をLiquid自身のLFM3の行の隣に置くとLFM3が勝つ。同じベンチマーク、同じ2モデル、正反対の答え。なぜなら数値は異なるハーネスから来ているからだ。

これは一例にすぎませんが、問題の全体がここに表れています。どちらのベンダーも、ハーネスの設定、リトライポリシー、プロンプトのスキャフォールディングを公開していません。両方のモデルを、誰も管理していない単一のハーネスで実行して比較するまでは、この比較におけるベンダー横断の行はすべて、測定値の装いをしたコイントスにすぎません。

その差がハーネス・ノイズでは説明できないほど大きい場合

一部の行は説明で片付けられない。最も明らかなのはエージェント型ウェブナビゲーションだ：

• WebArena-Verified — Liquid のハーネス上で、LFM3-1.7B は 38.42、MiniCPM5-2B は 9.11

• AutomationBench — 41.29 対 4.71。

• RULER 128K — 65.56 対 37.96。

• BFCL V4 — 71.39 対 62.65。

4ポイントの差は足場にすぎない。WebArena-Verifiedでの29ポイント差やAutomationBenchでの37ポイント差はそうではない。それらは、モデルが多段階の計画をそもそも一貫して保持できるかどうかの違いであり、各ベンダーが自社について述べていることとも一致する。LiquidはLFM3を、ツール呼び出しトレースを用いたエージェント型の中間訓練を中心に構築し、OpenBMB自身のドキュメントは、MiniCPM5が長い多段階タスクを苦手とし、繰り返しに陥りやすいと指摘している。同じ弱点について、相反する方向から届いた2つの独立した記述は、この比較全体の中で最も強い証拠だ。

長文コンテキストの行は、誤読されやすい項目なので、別途注目する価値があります。MiniCPM5のRULER 128Kにおける37.96は、128Kでの検索スコアであり、モデルの上限が128Kだという意味ではありません。MiniCPM5-2Bは公式に131,072トークンをサポートしています。これは、その長さでは、MiniCPM5が指示された対象を見つける精度が低いことを意味します。LFM3は同じ長さで65.56を記録します。ワークロードが「長い文書を検索して回答する」ものであるなら、この差が判断のすべてです。

MiniCPM5が勝る4つの行 — そしてそれが重要な理由

Liquidの表では、MiniCPM5-2Bが4つの勝利を収めている。τ³-benchは69.44対68.01、GPQA Diamondは65.15対63.37、HLEは8.20対7.17、AA-Omniscienceは9.13対7.07だ。4つのうち3つは知識ベンチマークである。差は1～2ポイントで、これはほとんどの評価スイートのノイズフロア内にある。

しかし、このパターンはMiniCPM5の設計と一致している。OpenBMBは、明示的な思考モードを備えた推論モデルとしてこれを訓練しており、その一連の流れでは4000億トークンにわたる深い思考のSFTを実行し、その後、専門家教師による強化学習を行ってから、単一の密なチェックポイントへオンポリシー蒸留した。これは、パラメータあたりの蓄積された知識からより多くを引き出すことを狙ったレシピだ。LFM3の訓練は、ツール呼び出しと指示遵守を狙っている。GPQA DiamondでMiniCPM5が1.8ポイント上回るのは驚きではない。2つの訓練哲学が、予想される場所に表れているだけだ。

はるかに興味深い比較は、Liquidの表ではできない比較だ。MiniCPM5-2BのArtificial Analysis Intelligence Indexは12である。LFM3-1.7Bは、2026年10月28日時点でArtificial Analysisの項目が一切ない——指数も、独立に測定された速度も、中立的なレイテンシ値もない。つまり、27行のうち23行で負けるモデルこそが独立したデータ点を持ち、それらで勝つモデルこそが信用して受け入れることを求めている。この非対称性は、勝利数の重みよりも重く見るべきだ。

実際にきれいに比較できるスペック

どちらのベンダーも相手のベンチマークを実行していない場合、その数値は地味だが信頼できる：

• パラメータ — LFM3-1.7B は 1.73B の dense であるのに対し、MiniCPM5-2B は合計 2.52B、非埋め込みで 1.98B。

• レイヤー — 24ハイブリッド（13畳み込み、5スライディングウィンドウ、6グローバル）対、16クエリヘッドと2 KVヘッドのGrouped-Query Attentionを備えた42標準Transformerレイヤー。

• コンテキスト — 256K 対 131,072。

• 128KでのKVキャッシュ — 1.6 GB 対 5.6 GB（Liquidによる両方の測定値）

• 4ビット時のフットプリント — 実使用報告では約1 GB 対 約1.1 GB。

• 語彙 — 128K 対 130,560。

• ライセンス — {{1}}LFM Open License v1.0{{/1}}、売上1,000万ドル未満は無料、一方Apache 2.0は閾値なし。

KVキャッシュの行こそがハードウェアを決める要素です。同じコンテキスト長での3.5倍の差は、スマートフォンに収まる長コンテキストエージェントと、そうでないものとの違いです。また、LFM3が256Kを提供でき、MiniCPM5が131Kにとどまる理由も説明します。トライハイブリッド層の組み合わせはコンテキストのトークンあたりのコストが低く、それこそがこの構成を構築する狙いそのものです。

一部のチームにとっては、メモリの違いよりもライセンスの違いの方が重要です。Apache 2.0には売上高の基準がなく、交渉すべき商用契約もなく、再配布に関する曖昧さもありません。LFM Open Licenseは年間売上高1,000万ドル未満なら無料で、それを超えると話し合いが必要になります。その基準未満のスタートアップは、どちらも無償で利用できます。基準を超える企業は、一方を無償で、もう一方を電話一本の後のやり取りを経て利用でき、どちらのモデルが高いスコアを出しても、それは実際の調達コストになります。

エコシステムのサポートこそ、MiniCPM5が依然としてリードしている分野です

両ファミリーは初日から幅広いランタイムサポートを提供したため、この差は1年前より縮まっています。LFM3はvLLM、SGLang、Transformers、llama.cpp、MLX、ONNX、Ollama、LM Studioを挙げており、BF16、FP8、NVFP4、GGUF、MLX、ONNXビルドを備えています。MiniCPM5-2Bは同じランタイムに加えてGPTQとDSparkを挙げており、DSparkはメインのチェックポイントと組み合わせる投機的デコーディング用のドラフトモデルです。

実際の違いは、入手可否ではなく成熟度にあります。MiniCPM5-2Bは9月上旬からダウンロード可能で、これはコミュニティによるバグ報告、量子化の実験、フレームワークのパッチ適用が7週間分積み重ねられていることを意味しますが、LFM3にはそれがありません。昨日リリースされたばかりのモデルは、GGUFへの変換やOllamaのパッケージングに粗削りな部分が残ります。これはLiquidへの批判ではなく、初日とはそういうものだというだけのことです。今週中に本番環境でモデルを使う必要があるなら、他の人が先に問題を踏んでくれた7週間分には相応の価値があります。

どう判断するか、そしてルーターがその真価を発揮するのはどこか

どちらのモデルもOrcaRouterのカタログにはありません。どちらも自分で実行するオープンウェイトであり、そうでないかのように示唆するより、はっきりそう言うほうがよいと考えています。ルーターが重要になるのは境界においてです。この評価を正直に実施する方法は、両方のモデルを1つのエンドポイントの背後に置き、実際のトラフィックを送ることです。そして、どちらかを本番環境で正直に運用する方法は、2Bモデルだけが応答できる唯一のものにしないことです。

そのためにあるのが自動フェイルオーバーです。リクエストを LFM3-1.7B にルーティングし、そのモデルが学習済みのツール呼び出しや抽出を処理できるようにし、タスクが 2B モデルでは扱えないほど多くのステップを必要とすることが分かった場合は、ホスト型モデルへフォールスルーさせます。OrcaRouter はプロバイダーの定価を 0% のマークアップでそのまま通すため、高コストな経路にかかるのは、実際に使われたときにプロバイダーが請求する分だけです — 小規模なローカルモデルへのルーティングによる節約分がルーターに食われることはありません。 ルーティング DSLを使えば、それを書き換えではなくルールとして表現できます。まず専門モデル、失敗時または信頼度しきい値に達したときに汎用モデルです。

モデル融合は、ここではあまり活用されていない選択肢だ。2つの2Bモデルが分類について意見が分かれた場合、両方に答えさせて突き合わせる方が、27Bモデルへエスカレーションするより安く済むことが多く、不一致率自体がどの入力が難しいかを示す有用なシグナルにもなる。パイプラインの片側に検証されていないモデルがあるなら、その種のクロスチェックはベンダーの表を信頼するより安く済む。

何がそれを決着させるのか

30日後には、誰かがLFM3-1.7BとMiniCPM5-2Bを、結果とともに設定をコミットした状態で、単一のハーネスを通して公開すべきだ。もしLFM3がWebArena-Verifiedで38前後、RULER 128Kで65前後を維持するなら、23対4という数はおおよそ正しかったものの理由が間違っていたことになり、エージェント能力の差は実在することになる。もしMiniCPM5の数値の方へ落ち込むなら、ローンチ時の表はスキャフォールディングを測っていたことになる。

それまでは、擁護できる立場はどちらのベンダーのマーケティングよりも狭い。ワークロードが多段階、ツール呼び出し、長文ドキュメントなら、LFM3-1.7Bの方が有望であり、メモリ上の優位性によって、制約のあるハードウェアにも余裕をもって収まる2つのうち唯一のモデルになる。ワークロードが知識検索、単一ターンの推論、または明確なライセンスと独立したスコアが付いたモデルを必要とするなら、MiniCPM5-2Bの方が安全な選択であり、それが勝つ4行はまさにその方向を指している。23対4という数は間違いというより、勝ち取ったものではない——そしてローンチ表のモデル数は結果と同じものではない。