LBS-27B vs LFM2.5 24B A2B：アクティブパラメータに関する疑問

で最も重要な数値はLFM2.5 24B A2B24ではない。2.45だ — モデルがトークンごとに実際に読み込むパラメータ数の十億単位である。だからこそLiquid AIは、モデルが240億パラメータ分の知識を保持しながら、Apple M5 Max上で毎秒184出力トークンを主張できるのであり、同社がこれをデータセンターの主力ではなくオンデバイスエージェントとして位置づけているのだ。同じ数値が欠けているのはLBS-27Bであり、その不在こそが、この比較がまだ決着できない理由だ。アクティブパラメータ数がなければ、inclusionAIのモデルをLFM2.5が定義する効率曲線上に位置づける方法はない。

LFM2.5 24B A2B は2026年10月13日からダウンロード可能で、モデルカード、16行のベンチマーク、そしてほとんどの企業が注意深く読む必要があるライセンスを備えています。LBS-27B は2026年10月26日に作成されたリポジトリで、標準的な .gitattributes ファイルと Apache-2.0 を宣言する28バイトの README が含まれています。重みも設定もカードも発表もありません。したがって、以下は完全に仕様が示された効率重視の取り組みと、まだどの種類のモデルなのかを明かしていない名前との比較です。

Liquid が最適化している対象

LFM2.5 24B A2Bは、64個のエキスパートとtop-4ルーティングを備えたMixture-of-Expertsデコーダーで、40層、隠れ層サイズ2,048、語彙数128,000トークンです。アクティブパラメータ数は24.5億です。131,072トークンのコンテキストを受け入れ、これは前世代の32Kから拡大されています。また、33兆トークンで事前学習されており、これはLFM2で使用された17兆トークンのおよそ2倍です。

語彙の変更は注目に値する細部だ。65Kから128Kトークンへの移行は高コストで、埋め込み層と出力層の再学習を意味する。そして通常、その理由は非ラテン文字のテキストだ。カードには16言語が列挙されている。英語、アラビア語、中国語、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語、スペイン語、ベトナム語、タイ語、インドネシア語、ヒンディー語、ロシア語、ポーランド語。語彙を大きくすると、これらの言語は単語あたりのコストが下がり、通常はテール部分の性能も良くなる。

また、推論専用モデルでもある。Liquidのポストトレーニングパイプラインは、教師あり微調整、ティーチャーの特化、非エージェント蒸留とエージェント蒸留を実行し、その後、OpenClaw、Hermes Agent、Pi、OpenCodeなどのハーネス内でエージェント強化学習を行う。このモデルは回答前に思考の連鎖を生成する。モデルカードには、別個の「高速で思考しない」モードについての記載はない。

意図的に尖らせたベンチマークプロファイル

Liquid自身の数値は、当社が再現したものではありませんが、オンデバイスエージェントが行うことには優れ、ナレッジワーカーが必要とするものには弱いモデルを描写しています。その形は偶然ではなく、設計そのものです。

• 指示追従 — IFEval 96.75、IFBench 74.69、Multi-IF 84.38。これはカード上で最も強力なクラスタであり、ツールスキーマに従う必要があるエージェントにとって最も重要なものです。

• ツール使用 — ToolSandbox 80.71、PinchBench 83.18、BFCL v4 65.01、AutomationBench 27.69。良好だが、ハーネス間でばらつきがある。

• エージェント型ブラウジングとコンピュータ操作 — LiveClaw 48.09、WebArena Verified 26.75、tau3-Bench Banking 8.04。バンキングの結果は外れ値だ。他のエージェント型モデルがはるかにうまくこなすタスクスイートでの1桁台のスコアである。これは「エージェント型」が単一の能力ではないことを思い出させる。

• ソフトウェアエンジニアリング — OpenCode での SWE-Bench Verified は 51.00、SciCode は 32.71。中位。

• 数学 — MATH-500 96.04。この規模としては高性能。

• 知識 — GPQA Diamond 74.42、HLE 7.40、AA-Omniscience −24.90。ここで正直な指標となるのは、Omniscience の負のスコアです。自信を持った誤答にペナルティを与えるベンチマークでは、このモデルは得るものより失うもののほうが多くなります。Liquid 自身の位置づけもこれを認めています — このモデルは検索と組み合わせて使うことを前提としており、百科事典として信頼されるものではありません。

これらの行をまとめて読むと、そのモデルは指示追従とツール呼び出しは得意だが、知識基盤が薄いことを示している。あなたのファイルを読み、あなたのAPIを呼び出すローカルエージェントにとっては、それは適切なトレードオフだ。研究アシスタントにとっては、間違ったトレードオフだ。

効率性の主張と、それに付随する留保

Liquidは、Apple M5 Max上で約15GBのメモリを使用して毎秒184トークン、Ryzen AI Max+ 395上で毎秒114トークンを報告している。これらは特定のハードウェアに関するベンダー公表値であり、一般的なベンチマークではなく、量子化やバッチサイズによって変動する。それでも方向性には意味がある。2.45Bがアクティブな24Bモデルは、デンスな24Bモデルにはできない形でラップトップ上で動作できる。

トレードオフになるのはメモリ帯域幅だ。スパースモデルでも240億パラメータすべてをメモリに保持する必要がある——節約できるのはストレージではなく、トークンあたりの計算量だ。だからこそ15GBという数字はスループットと同じくらい重要だ。それは全重みセットをおよそ4ビット量子化したものに相当し、ハードウェアの下限を決める。

LBS-27B をどこに設置する必要があるか

この対決のすべては、LBS-27Bリポジトリにまだ存在しない2つのフィールド、すなわちエキスパート数とアクティブパラメータ数にかかっています。

LBS-27Bがスパースで、アクティブパラメータが2B〜4B程度なら、それはLFM2.5の領域に直接食い込む——小規模モデルの計算量で27Bクラスの知識ベースを実現する——そして比較は、アクティブパラメータあたりの品質をめぐる真っ向勝負になる。もしデンスなら、それはまったく別の製品だ。計算量が予測しやすく、メモリフットプリントがほとんどのラップトップを排除するサーバーサイドモデルである。スパースでアクティブ数が大きい場合は、両者の中間に位置し、効率ではなく品質で競うことになる。

リポジトリからどちらなのかを推測する方法はありません。名前には27Bとあり、READMEにはApache-2.0とあり、ファイルツリーにはそれ以上何も書かれていません。inclusionAIは、私たちが探した限り、カードもブログ記事も論文も公開していません。

可能な限りにおける比較

• 総パラメータ数 — LFM2.5 24B A2B は 24.0B、LBS-27B は未検証の 27B。

• アクティブパラメータ — LFM2.5は2.45B、LBS-27Bは不明であり、これが決定的な不明点です。

• アーキテクチャ — LFM2.5 は 64 エキスパート、top-4 ルーティング、40 層。LBS-27B は不明。

• コンテキスト — LFM2.5 は 131,072 トークン、LBS-27B は不明。

• モダリティ — LFM2.5 はテキストのみ、LBS-27B は不明。

• 言語 — LFM2.5では16言語が記載されています。LBS-27Bについては不明です。

• 推論 — LFM2.5ではデフォルトで思考の連鎖（chain of thought）を使用し、思考なしモードに関する文書化された記載はない。LBS-27Bについては不明。

• ライセンス — LFM2.5 には、年間収益が1,000万ドルを超える場合に商用ライセンスを要求する LFM 1.0 ライセンス。LBS-27B には Apache-2.0 を宣言。

• 公開済みの評価 — LFM2.5についてはベンダー報告による16行、LBS-27Bについてはなし。

ライセンスは脚注ではなく、調達上の問題である

これが、空のリポジトリがすでにLBS-27Bに優位性を与えている唯一の側面だ。LFM 1.0ライセンスはOSIの意味でのオープンソースではない。年間収益が1000万ドルを超える企業は、導入前に別途商用ライセンスが必要になる。個人開発者や基準未満のスタートアップにとっては、それは問題ではない。中規模企業にとっては、法務レビュー、交渉、そして費用項目の一つとなる。

LBS-27B は README で Apache-2.0 を宣言している。これは明示的な特許許諾を伴い、収益しきい値のない寛容型ライセンスであり、重みのリリースまで存続すれば調達工程を丸ごと一つ削減できる。現時点で LBS-27B がこの比較において持つ唯一の具体的な優位性であり、実際に存在するものだからこそ明確に述べておく価値がある — リポジトリ作成時に行われたライセンス宣言は弱い証拠ではあるが、決して無意味ではない。

オンデバイス vs API：2つの異なる製品

LFM2.5 24B A2B は、データがある場所で動作するように作られています。訴求点はプライバシーとレイテンシです。ノートPCやワークステーション上で動作し、第三者にリクエストを一切送らないモデルであり、ローカル自動化を動かせるだけのツール呼び出し能力を備えています。4ビットのメモリフットプリントと131Kコンテキストは、その用途に合わせて設計されています。

LBS-27Bは何のためのものかを明言していない。inclusionAIがサーバーサイドでの提供を想定したモデルを投入するなら、オンデバイスという論拠は当てはまらず、両モデルは代替ではなく補完関係になる。ローカル展開を想定した小さなアクティブMoEを投入するなら、比較は直接的なものとなり、オンデバイス向けツール群——llama.cpp、MLX、ONNX、vLLM対応に加え、文書化されたエージェントハーネス——におけるLiquidの2世代分の先行優位が決め手となる。

フレームワーク対応は、この点で過小評価されがちな要素だ。初日から llama.cpp や MLX に対応していないモデルは、アクティブパラメータ数がいくらであっても、実用上オンデバイスモデルとは言えない。

未実証のモデルに賭けずにテストする

LBS-27B も LFM2.5 24B A2B も現在 OrcaRouter には掲載されていないため、どちらにもホスト型エンドポイントは存在せず、そうであるかのような提案は行いません。ここでこのプラットフォームに言及する理由は、それに続く評価上の問題です。新しい小規模アクティブモデルが現在のモデルを置き換えられるかどうかを知りたい場合は、リーダーボード上ではなく、自社のトラフィックで両方を実行する必要があります。

OrcaRouterのルーティングDSLを使えば、現行モデルをデフォルトのままにしておき、リクエストの一定割合を候補モデルへ送ることができます。さらに自動フェイルオーバーにより、タイムアウトやエラーが発生した候補は既知のモデルへ縮退するため、リクエストが失敗することはありません。1つのモデルでは足りない難しいケースでは、モデルフュージョンによって複数のモデルがパネルとして共に回答し、統合された結果を返します。これは、知識を多く要するタスクで、安価なモデルの弱点がまさに検証したいポイントである場合に有用です。200以上のモデルカタログやマークアップ0%といった点は、ここでは別途の統合なしに自前の入力で比較できる能力ほど重要ではありません。

それは、このページに欠けている証拠を生成する方法です。モデルが存在することの代用にはなりません。

3人の読者、3つの答え

オンデバイスエージェントを構築中で、今日ラップトップ上で動くものが必要なら、LFM2.5 24B A2B は有力候補だ。指示追従性が高く、複数のハーネスでツール呼び出しが良好で、131Kコンテキストを備え、一般的なローカルランタイムへの導入手順も文書化されている。まずライセンスのしきい値を確認し、検索なしで事実を把握していることを期待してはいけない。

サーバーサイドの27Bを選んでいて、寛容なライセンスが必要なら、LBS-27BはApache-2.0がすでに宣言されているというまさにその理由で注目に値します。しかし、評価できるものは何もなく、ライセンスの宣言はモデルではありません。

売上高が1,000万ドルを超え、厳格な調達プロセスを備えた企業であれば、ライセンスの違いは、この記事のどのベンチマーク行よりも重要になる可能性があります。LFM2.5のカスタムライセンスは実際のコストであり、LBS-27BのApache-2.0は実際の利点ですが、それはリリースまで存続する場合に限ります。

三つの答えすべてを変える数字は、アクティブパラメータ数だ。それが存在するまでは、正直な立場としては、一方のモデルには効率性のストーリーがあり、もう一方にはリポジトリがある、ということになる。