2.6B で端末内エージェントはどこまで動く？ LFM2.5-2.6B の設計・学習・評価を読む

こんにちは、ローカルで動く AI エージェントの進化が気になっているアーキテクトのやまぱん！です。

2026 年 8 月 4 日、Liquid AI が LFM2.5-2.6B を公開しました。約 26 億パラメーターのモデルを端末内で動かし、計画、ツール呼び出し、複数ステップの作業まで担わせるという発表です。スマートフォンで 30 tokens/s、Apple M5 Max で 220 tokens/s という数字も並び、2.6B で 9B 級モデルを上回った評価まで出ています。

これは面白い。ただ、「小さいモデルが大きいモデルを超えた」「データが絶対に外へ出ない」「実行コストがゼロ」とだけ受け取ると、発表の大事な条件が抜け落ちます。

この記事では、公式ブログ、モデルカード、Liquid Docs、LFM2 Technical Report、ライセンス原文を突き合わせ、何が新しく、どこまでが端末内で、どの用途に向くのかを読み解きます。

この記事は 2026 年 8 月 5 日時点の一次情報を基にしています。私はまだ LFM2.5-2.6B をローカルで実測していません。性能値は Liquid AI の公表値として記載し、私の解釈と分けています。

TL;DR

LFM2.5-2.6B は、2.69B パラメーター、30 層、約 128K context、128K vocabulary の text-only dense model。日本語を含む 16 言語がモデルカードに明記されています。
30 層の内訳は 22 個の gated short convolution block と 8 個の Grouped-Query Attention。注意層を少数に絞り、CPU での速度と KV cache の削減を狙った構成です。
約 34 兆トークンの事前学習だけでなく、実際の agent harness 内で Agentic Reinforcement Learning を実施しています。ツールの形式だけでなく、複数ターンの仕事の進め方まで学習対象にした点が重要です。
ToolSandbox、Multi-IF、IFStruct の好成績は、それぞれツール利用、多言語・複数ターンの指示追従、構造化出力の強さを示します。一方、coding や一部の agent benchmark では 9B 級モデルが上です。
「端末内」はモデルだけで決まりません。推論 server、agent harness、tool、データ保存先をすべてローカルにして初めて、処理全体を端末内に閉じられます。
open-weight ですが無条件の商用利用ではありません。LFM Open License v1.0 には年商 threshold があり、支配・被支配・共通支配下を含む Legal Entity 単位で条件を確認する必要があります。

まず仕様を一枚で確認する

LFM2.5-2.6B の構造と学習工程を、公開情報から一枚に整理すると次のようになります。

モデルを軽くする構造と、エージェントとして動かす学習は別々の工夫です

項目	公開仕様
パラメーター	2.69B
形式	text-only、dense model
層数	30 層（22 short convolution + 8 GQA）
Context length	約 128K tokens（公開情報に 131,072 / 128,000 の差あり）
Vocabulary	128,000
学習量	約 34T tokens
言語	日本語、英語、中国語、韓国語など 16 言語
Tool use	chat template に native tool calling を実装
配布形式	native、GGUF、ONNX、MLX
推論環境	Transformers、llama.cpp、MLX、vLLM、SGLang、LM Studio など

モデルカードは、用途として agentic workload、tool use、data extraction、Retrieval-Augmented Generation（RAG）、long-context workflow を挙げています。その一方で、agentic coding と knowledge-heavy task には推奨しないとも明記しています。

Context length は、モデルカードと公式 guide で 131,072 tokens と記載されています。一方、配布 checkpoint の config.json は max_position_embeddings: 128000 です。この記事では両者をまとめて「約 128K」と表記し、実行時は利用する runtime と checkpoint の設定を確認する前提にします。

ここは発表の読み方を決める重要な一文です。LFM2.5-2.6B は、あらゆる問題を解く小型万能モデルという位置づけではありません。端末内で繰り返し動かす、手順が比較的明確な仕事へ焦点を合わせたモデルです。

なぜ軽いのか：22 個の短畳み込みと 8 個の GQA

LFM2.5-2.6B は LFM2 の hybrid architecture を継承しています。

一般的な Transformer は、各 attention layer で過去 token の Key と Value を保持します。この KV cache は長い context ほど大きくなり、端末内推論ではメモリと転送量の負担になります。

LFM2 の 30 層は、次の 2 種類で構成されています。

22 個の gated short convolution block: 近い範囲の token を安価な 1 次元畳み込みで混ぜる
8 個の Grouped-Query Attention（GQA）block: 離れた情報を参照する global context を担当する

GQA は複数の query head で Key / Value を共有し、通常の multi-head attention より KV cache の転送量を抑える方式です。さらに、attention 自体を 8 層に絞っているため、30 層すべてで KV cache を持つ構成より端末側の負担を小さくできます。

LFM2 Technical Report によると、この比率は理論だけで決めたものではありません。Galaxy S24 Ultra や AMD Ryzen を対象に、品質、time-to-first-token、decode latency、peak memory を測る hardware-in-the-loop architecture search から選ばれています。

興味深いのは、Mamba 系の State Space Model や linear attention を重ねた複雑な hybrid より、短い畳み込みと少数の global attention という単純な組み合わせが、対象端末では良い Pareto frontier に残ったという報告です。

技術レポートは 2025 年公開の LFM2 backbone を説明した文書です。LFM2.5-2.6B の 34T tokens、128K context、後述する Agentic RL は 2026 年のモデルカードと公式発表で補っています。

34T tokens より気になった、4 段階の post-training

約 34 兆トークンという事前学習量は、小型モデルとしてかなり大きな数字です。ただ、今回の「エージェント向け」という性格を決めているのは、その後の post-training だと私は見ています。

公式発表は、base model を agentic model に変える工程を 4 段階で説明しています。

1. 2 段階の Supervised Fine-Tuning

最初は広い領域を対象にし、次に tool use、web search、software engineering、agent trace などを厚くしたデータで調整します。LFM2.5-8B-A1B と比べても約 7 倍の SFT mix を使ったとされています。

2. Domain ごとの teacher specialization

同じ SFT checkpoint から、instruction following、math、knowledge、code、tool use、long context などの専門 teacher を分岐させます。各 teacher は専用データと Reinforcement Learning with Verifiable Rewards（RLVR）で強化されます。

3. Multi-Domain On-Policy Distillation

Multi-Domain On-Policy Distillation（MOPD）は、専門 teacher の能力を 1 つの student model へ戻す工程です。

student 自身が生成した trajectory に対して、domain に対応する teacher が token-level feedback を返します。別モデルの完成回答だけを模倣する off-policy distillation より、student が実際に辿りやすい分布の近くで学ばせる狙いがあります。

4. 実 agent harness 内の Agentic RL

最後が今回の核です。Liquid AI は Hermes Agent、OpenClaw などの実 agent harness を sandbox 内で動かし、調査、文章作成、coding、データ分析、文書操作、tool use を含む複数ターンの仕事をモデルに経験させています。

報酬は LLM-as-a-judge、programmatic check、hard safety gate を組み合わせ、Group Relative Policy Optimization（GRPO）で最適化したと説明されています。

モデルは tool schema だけを見て学んだわけではありません。system prompt、tool description、tool result、失敗後のやり直しを含む harness 内の interaction pattern を学習しています。小型モデルは形式の違いで崩れやすいため、実際に使う「器」の中で学ばせる方法には納得感があります。

モデル単体がアプリを操作するわけではない

「エージェントモデル」という言葉から、model file を起動すれば自動的に端末を操作してくれるように見えるかもしれません。実際は、model と agent harness の組み合わせです。

推論がローカルでも、外部 API を呼ぶ tool を使えば、その入力は端末外へ送られます

Tool Use の公式ガイドによると、処理は 4 段階です。

harness が利用可能な tool definition を model へ渡す
model が <|tool_call_start|> と <|tool_call_end|> の間に function call を生成する
harness が function を実行し、結果を tool role で model へ返す
model が tool result を読んで次の行動か最終回答を生成する

ファイルを読む、ブラウザを操作する、API を呼ぶといった実処理は harness 側の仕事です。LFM2.5-2.6B は、何を呼ぶか、引数をどう組むか、結果を受けて次に何をするかを担当します。

ローカル agent の公式手順も、次の 2 層に分かれています。

llama.cpp、LM Studio、MLX、vLLM、SGLang のいずれかで OpenAI-compatible endpoint をローカルに立てる
Hermes Agent、OpenClaw、Pi などの harness をその endpoint へ向ける

この境界が分かると、「data never leaves the device」の条件も見えてきます。

「データが端末から出ない」が成立する条件

処理全体をローカルに閉じるには、少なくとも次の 4 層を確認する必要があります。

層	ローカルに閉じる条件
推論 endpoint	model weight と推論 backend が端末内で動く
Agent harness	conversation history、計画、trace をローカルへ保存する
Tool	ローカルファイルやローカル DB だけを操作する
データ保存	log、cache、telemetry の送信先も確認する

たとえば web_search、クラウドストレージ、外部 SaaS API を tool として使えば、検索語や tool argument は外へ送られます。これは model の欠陥ではなく、構成した tool の通信です。

したがって、LFM2.5-2.6B は クラウド推論 API を使わずに構成できるモデルです。「このモデルを使えば、どの agent application でも自動的に完全ローカルになる」とまでは言えません。

「1 回ごとの限界費用がほぼゼロ」という表現も、クラウド API の token 課金がないという意味で捉えるのが正確です。端末購入、電力、storage、開発、監視、更新のコストは残ります。それでも、background agent を大量に反復させる用途で token 単価を気にしなくてよいのは、大きな設計変更になり得ます。

3 つの好成績は、何を測っているのか

X の投稿で目を引いたのは次の 3 項目です。

Benchmark	LFM2.5-2.6B	比較対象	比較対象の score
ToolSandbox	77.83	Qwen3.5-9B	76.44
Multi-IF	80.07	Gemma 4 E4B IT	77.35
IFStruct	85.49	Qwen3.5-9B	78.50

数字だけ見ると「9B を超えた」と言えます。ただし、3 つは別の能力を測っています。

ToolSandbox：状態を持つ tool use

Apple の ToolSandbox は、端末の設定、連絡先、message、reminder などの world state を持つ対話環境です。単発の function call だけでなく、現在状態の確認、前提となる設定変更、複数 tool の順序、情報不足時の確認を評価します。

Liquid AI 公表の 77.83 は、ToolSandbox の状態依存シナリオで一定の性能を示した参考値です。Apple の公開 repository には LFM2.5-2.6B の結果 artifact はなく、第三者による再現結果は確認できません。

Multi-IF：3 ターン、8 言語の指示追従

Multi-IF は、4,501 件の会話を 3 ターン、英語と翻訳先 7 言語で評価します。会話が進んでも、それまでに追加された制約を維持できるかを見る benchmark です。

agent は長い作業ほど「最初の条件を忘れる」ため、80.07 という値は複数ターンの安定性を見る材料になります。

IFStruct：JSON / YAML の schema compliance

IFStruct は Liquid AI 自身が作成した benchmark です。JSON または YAML で、指定 field、type、enum、数値範囲、item 数、code fence、余計な field の禁止をすべて守れるかを binary に採点します。

これは reasoning の正しさや生成内容の品質を測る指標ではありません。公式説明も、構造だけを評価し、content correctness は評価しないと明記しています。また、frontier model では飽和しやすい設計です。

IFStruct の score は data extraction や system integration には興味深い一方、評価の作成者とモデルの提供者が同じです。open-source の test set と validator は公開されていますが、今回のモデル score を第三者が独立再現した事例は、2026 年 8 月 5 日時点では確認できませんでした。

勝っていない指標も一緒に見る

公式表には、LFM2.5-2.6B が大型モデルへ届かない項目も載っています。

Benchmark	LFM2.5-2.6B	Qwen3.5-9B	読めること
LiveCodeBench v6	59.41	69.86	coding では大型モデルが優位
BFCL v4	56.88	60.13	function calling 全般で常に首位ではない
Claw-Eval average（EN）	62.85	66.53	agent task 全体では Qwen が上
PinchBench	68.22	71.45	別の agent 評価でも差が残る
BrowseComp+（OpenClaw）	26.89	27.23	web research は僅差で Qwen が上

Liquid AI 自身も、coding が大きいモデルとの差が残る領域だと説明しています。ここまで見ると、LFM2.5-2.6B の輪郭はかなり明確です。

instruction following、structured output、tool-oriented workflow はサイズ比でかなり強い
coding-heavy、knowledge-heavy、複雑な open-ended task では大型モデルを置き換えない
高頻度の定型 agent task をローカルへ移す用途が本命

なお、これらはすべて Liquid AI が vLLM で実行した評価値です。ToolSandbox は temperature 0、BFCL v4 は 0.001、その他の多くは 0.6 など、benchmark と model の推奨設定に応じて generation parameter が異なります。同じ表にあるからといって、全項目が完全に同じ decoding 条件というわけではありません。

220 tokens/s、113 tokens/s、phone で 30 tokens/s の読み方

Liquid AI は CPU decode speed として、次の値を公表しています。

Apple M5 Max: 220 tokens/s
AMD Ryzen AI Max+ 395: 113 tokens/s
phone: 30 tokens/s
memory: 2.5 GB 未満（公表された CPU decode 測定時）

これは Liquid AI の測定値で、私の実測ではありません。「2.5 GB 未満」について、公式発表本文には量子化、context length、prompt length、thread 数、測定対象 memory の詳細条件が示されていません。128K context での一般的な memory 保証とは読まず、CPU decode 測定に添えられたベンダー公表値として扱います。

さらに、model file のサイズと実行時 memory は分けて見る必要があります。

GGUF 配布ページでは、Q4_K_M が 1.67 GB、Q6_K が 2.22 GB、Q8_0 が 2.87 GB、BF16 が 5.4 GB です。これは主に weight file のサイズです。実行時には context、KV cache、runtime buffer、agent history などが追加されます。

128K context を支える仕様があっても、常に 128K で serve するのが最適とは限りません。公式の agent harness guide も、memory が限られる場合は 32K など小さい window を選ぶよう案内しています。

私なら最初は次のように考えます。

Q4_K_M + 32K: 動作確認と軽量な個人 agent
Q8_0 + 必要な context: tool call の精度を優先する運用
BF16 GGUF: 最大忠実度での推論・比較評価。Fine-tuning には native checkpoint を使う

この選択はまだ私の実測結果ではありません。公式 guide の推奨を基にした開始点です。

Open-weight だが、商用条件は確認が必要

モデルは LFM Open License v1.0 で公開されています。

ライセンスは、利用、複製、派生物の作成、再配布に広い権利を与えています。一方、商用条件の境界は原文どおりに確認する必要があります。

原文は Threshold を annual revenue of 10 million United States dollars ($10,000,000) or more と定義しています。Section 5 は、Commercial Use の権利について、You または Your Legal Entity が Threshold を超えないことを条件とし、Threshold を超える Legal Entity の商用利用は本契約では許諾されないと定めています。

ここでいう Legal Entity は単体法人だけではなく、支配・被支配・共通支配下にある組織を含みます。Threshold のちょうど境界を含む適用判断や、別ライセンスの可否は、原文と Liquid AI への確認が必要です。

再配布時はライセンスを渡す
modified file には変更したことを明記する
copyright、patent、trademark、attribution notice を維持する
条件違反時はライセンスが自動終了し、利用停止と copy の削除が必要になる

個人利用や研究利用に扱いやすい open-weight model であることと、あらゆる企業が無条件に商用利用できることは別です。特に組織で PoC から production へ進める場合、年商 threshold、Legal Entity の範囲、別契約の要否を法務担当者と確認する必要があります。

ここでの説明はライセンス原文の要約で、法的助言ではありません。実際の利用判断では原文と自組織の条件を確認してください。

向く用途、向かない用途

公開情報を踏まえると、LFM2.5-2.6B が向きそうなのは次の用途です。

個人情報や業務文書を端末内に保ちたい data extraction
JSON / YAML を返す local automation
ローカル document を対象にした RAG
offline 環境の assistant
同じ手順を大量に繰り返す background agent
外部 cloud API が使えない端末や robot の制御補助

一方、次の用途は大型モデルとの比較が必要です。

repository 全体を変更する coding agent
最新知識や幅広い専門知識を model weight だけに求める task
長い探索と高度な判断が続く open-ended research
失敗コストが高く、人間の確認なしで完結させる操作

小型で速いモデルは、1 回の正答率だけでなく、検証を挟みながら安価に何度も回せることに価値があります。LFM2.5-2.6B は、frontier model の縮小版としてより、端末内に置く実務 worker として見る方がしっくりきます。

試す入口

最も軽く試すなら、WebGPU の research agent demo があります。

ローカルでは、公式 guide が llama.cpp、LM Studio、MLX、vLLM、SGLang から OpenAI-compatible endpoint を作る手順を案内しています。公式 guide の llama.cpp 例を、memory を抑えた 32K context の CPU 向け開始例に調整すると次の形です。

# GGUF を取得し、tool calling を有効にしてローカル endpoint を起動する
llama-server -hf LiquidAI/LFM2.5-2.6B-GGUF:Q4_K_M `
  --jinja `
  --port 8080 `
  -c 32768 `
  --temp 0.1 `
  --top-k 50 `
  --repeat-penalty 1.1

--jinja は model の chat template を使って tool calling を有効にするための指定です。起動後、agent harness の base URL を http://localhost:8080/v1 に向けます。

初回は file read など副作用の小さい tool だけに絞り、tool call の形式、失敗時の再試行、history が context に収まるかを確認するのがよさそうです。

参考

LFM2.5-2.6B: Deploy Agents Everywhere - Liquid AI（発表、学習工程、評価、推論性能）
LFM2.5-2.6B Model Card - Hugging Face（仕様、用途、制限、配布形式）
LFM2.5-2.6B - Liquid Docs（quick start と推論設定）
Run local agents with LFMs - Liquid Docs（local endpoint と harness の接続）
LFM2 Technical Report（architecture search と LFM2 backbone）
LFM Open License v1.0（利用・再配布・商用条件）
ToolSandbox - Apple（stateful tool use benchmark）
Multi-IF（multi-turn / multilingual instruction following）
IFStruct（structured-output compliance benchmark）

まとめ

LFM2.5-2.6B で最も面白かったのは、2.6B という小ささだけではありません。22 個の短畳み込みと 8 個の GQA で端末側の速度を作り、34T tokens の事前学習と実 agent harness 内の Agentic RL で、tool-oriented workflow に性能を寄せている点です。

評価値を見る限り、instruction following、structured output、stateful tool use はサイズ比でかなり強い。一方、coding や knowledge-heavy task まで大型モデルを置き換えるものではありません。この得意・不得意がはっきりしているところは、むしろ使い方を考えやすいと感じました。

そして、privacy は model name ではなく構成で決まります。推論 endpoint、harness、tool、storage をすべて確認して、初めて「端末内 agent」と呼べる。この境界を押さえた上で、まずは小さな local automation から試してみたいモデルです。