LFM2.5-2.6Bはローカルエージェント向き？ CPU・WebGPU・Q4で動かす判断ポイント

このモデルは何か

LFM2.5-2.6Bは、Liquid AIがオンデバイス用途を強く意識して公開している2.69Bパラメータのテキストモデルだ。単に小さいチャットモデルというより、ツール利用、指示追従、複数段階 エージェント向けタスクを手元の端末で回すことを主眼にしている。

公式Modelカードではコンテキスト長さは131,072トークン。GGUF、ONNX、MLXも公式に用意されており、GPUを積んだデスクトップだけでなく、CPU中心のPC、Apple Silicon、WebGPUが使えるブラウザ環境まで実行経路が広い。

ローカルAIでこのモデルを見るときに重要なのは、最高性能の汎用LLMとして評価することではない。むしろ、

• クラウドAPIへ毎回送らずにツール呼び出しを回したい
• 常駐エージェントの軽い判断部分だけローカル化したい
• ノートPCや小型端末でも動くモデルが欲しい
• ブラウザ内WebGPUで処理を完結させたい

といった用途に合うかを見るべきモデルだ。

まず押さえたい仕様

項目	公式情報
パラメータ	2.69B
コンテキスト	131,072トークン
モダリティ	テキストのみ
主用途	エージェント型処理 / ツール利用 / データ抽出 / RAG / 長いコンテキスト
公式形式	Safetensors / GGUF / ONNX / MLX
対応言語	日本語を含む16言語

Liquid AIは、LFM2.5-2.6Bをエージェント向け処理向けに追加学習したモデルとして説明している。一方で、エージェント向けコーディングや知識依存度の高いタスクには推奨していない。

小型モデルだから何でもローカルで置き換えられるわけではない。コードベース全体を読ませて難しい改修を任せる用途より、決まったツールを選ぶ、データを抽出する、RAGの結果から次の処理を決める、といった比較的制約されたエージェント処理の方が狙いやすい。

このモデルでできること・どんなPCで動かせるか

メモリ面ではかなり扱いやすい

LFM2.5-2.6Bの強みは、実行形式の選択肢が多いことだ。

公式ONNX版では、WebGPU向けの推奨構成として次のサイズが案内されている。

ONNX構成	公式サイズ目安	主な用途
Q4	約1.9GB	WebGPU / サーバー
Q4F16	約1.5GB	WebGPU
FP16	約2.1GB	WebGPU / サーバー
Q8	約2.1GB	サーバー

これはモデルファイルのサイズであり、そのまま実行時の総メモリ使用量ではない。コンテキスト、KVキャッシュ、実行時バッファなどは別に必要になる。

ただ、それでも数十GB級のモデルとは性格が違う。大容量GPUを前提にせず、手元の一般的なPCで試しやすいのは明確な利点だ。

16GB・24GB・32GBといったGPU容量ごとの考え方は、ローカルAI向けGPUのVRAM比較でも整理しているが、LFM2.5-2.6Bは「大容量VRAMをどう確保するか」よりどの実行環境・形式で軽く常駐させるかの方が重要になりやすい。

CPUだけでも候補になる

Liquid AIは公式Modelカードで、AMD Ryzen CPU上の提供元ベンチマークとして113トークン/s、Apple M5 Maxでは220トークン/sという値を掲載している。

ただし、これはLiquid AI自身の測定値であり、独立実測ではない。CPU型番、量子化、入力長、生成条件が違えば速度は変わる。

ここで見るべきなのは絶対値より、CPU実行を公式が主要な配布経路として想定している点だ。

GGUFも用意されているため、llama.cpp系実行環境でCPU推論を組みやすい。GUIを含めた実行環境選びはLM Studio・Ollama・llama.cpp比較を基準にするとよい。

常駐エージェントでは、巨大モデルを最高速で回すよりも、

小さいモデルを常時ロード
↓
軽い分類・tool selectionを担当
↓
難しい処理だけ大きなローカルモデルやクラウドへ渡す

という構成の方が合理的な場合がある。LFM2.5-2.6Bは、この前段に置く候補として面白い。

WebGPUでブラウザ内実行もできる

LFM2.5-2.6Bには公式ONNX版があり、Transformers.js + WebGPUの実行例も用意されている。

つまり、専用のPythonサーバーを立てずに、対応ブラウザのGPU機能を使ってモデルを動かす構成も取れる。

ローカルAIサイトや社内ツールの観点では、これは単なるデモ以上の意味がある。

• 入力を外部APIへ送らない
• サーバー側の推論費用を持たない
• ユーザー端末側で処理を完結できる
• 小さな分類器や補助エージェントをWebアプリへ組み込みやすい

といった設計が可能になるためだ。

ただし、WebGPUはブラウザ・OS・GPU・ドライバーの組み合わせで挙動差が出る。公式に動作経路があることと、すべての端末で同じ速度・安定性になることは分けて考える必要がある。

QAD Q4_0が普通のQ4と少し違う

2026年8月19日、Liquid AIはLFM2.5系列向けに量子化を考慮した蒸留（Quantization-Aware Distillation）（QAD）を使ったQ4_0チェックポイントを公開した。

一般的な学習後量子化では、完成した高精度モデルを後から4bit化する。その過程で精度が落ちることがある。

QAD版では、高精度モデルを教師モデルとして量子化済み生徒モデルへ知識を蒸留する方法を取り、Liquid AIは自社ベンチマークで、通常のQ4_0化によって失われたBF16平均精度の97%を回復したと報告している。

この97%も提供元ベンチマークなので、あらゆる用途でBF16と同等という意味ではない。ただ、ローカルエージェント用途でQ4を選びたい人に、公式の低bitチェックポイントが用意されたこと自体は実用上大きい。

小型モデルはもともと量子化による能力低下の影響を受けやすい。速度やメモリだけを見て最小bitへ落とすより、ツール呼び出し成功率や指示追従を自分のタスクで確認した方がよい。

選ぶときの判断

どんな用途なら試す価値が高いか

LFM2.5-2.6Bは次のような用途と相性がよい。

ローカルエージェントのツール選択

ユーザー入力を見て、検索、ファイル操作、計算、特定APIなど、どのツールを使うべきか選ぶ役割だ。

大規模な知識をモデル内部に期待せず、外部ツールで情報を取得する構成なら、小型モデルでも役割を限定しやすい。

RAGの前後処理

文書検索そのものではなく、クエリ書き換え、結果の整形、分類、抽出といった処理をローカル化する用途だ。

データ抽出

決まった形式の文章からJSONへ変換する、項目を抜き出す、といった処理は大規模なエージェント処理より評価しやすい。

ブラウザ内AI

ONNX/WebGPU版があるため、サーバー費用や外部送信を避けたいWebアプリの補助AIとしても候補になる。

逆に、これを主力コーディングエージェントにするのは慎重に

Liquid AI自身が、LFM2.5-2.6Bをエージェント向けコーディングには推奨していない。

2.6B級でツール利用が強いという説明を見て、Claude Codeや大型Coderモデルの完全代替と考えるのは早い。

リポジトリ全体を理解して設計判断する、複数ファイルを大きく書き換える、未知のライブラリを調査しながら修正する、といった仕事では、モデルサイズによる知識・推論余力の差が出やすい。

現実的には、

LFM2.5-2.6B
  ↓
軽い判断 / tool routing / extraction
  ↓
難しいtaskを検出
  ↓
大型ローカルLLM or cloud model

のような階層構成の方が使いやすい。

どの形式を選べばいいか

目的別には次のように考えられる。

環境	最初の候補
Windows / Linuxでllama.cpp系	GGUF、特にQAD Q4_0を比較
Apple Silicon	MLX
ブラウザ内	ONNX Q4 / Q4F16
Pythonで標準チェックポイントを使う	Transformers
GPUサーバー	vLLM / SGLang

最初から131Kコンテキストを確保する必要はない。長いコンテキストは追加メモリを使うため、まず自分のタスクに必要な長さで測る方がよい。

結論：巨大モデルの代替ではなく「常駐できる小型エージェント」として面白い

LFM2.5-2.6Bの価値は、2.6B級で大型モデルと正面からベンチマーク競争することではない。

GGUF、MLX、ONNX/WebGPUまで公式配布が揃い、Q4_0にもエージェント性能を意識した専用チェックポイントがあることが重要だ。

そのため、

• PC起動中ずっと常駐させる補助エージェント
• ツール呼び出し専用モデル
• RAGやデータ処理の前後段
• ブラウザ内のローカルAI

といった用途では試す価値がある。

一方、難しいコーディングや知識依存タスクまで1モデルで処理したいなら、より大きなモデルとの比較が必要だ。

LFM2.5-2.6Bは「最強のローカルLLM」ではなく、ローカルAIを常時動かすための軽量部品として見ると位置づけが分かりやすい。