クラウドなしで「考えて動く」AIが、手元のデバイスに載る時代
AIに何かを頼むとき、処理はほぼ必ずクラウドサーバーで行われています。
つまり、使うたびにデータが外部に送られているということです。
そのあたり前を変えようとする動きが、静かに加速しています。
2025年8月、Liquid AIは「LFM2.5-2.6B」を公開しました。
クラウドに頼らず、端末だけで複数ステップのタスクを計画・実行できるエージェント型モデルです。
しかもオープンウェイト(重みを公開)で提供されています。
何が起きたのか
Liquid AIがリリースしたLFM2.5-2.6Bは、パラメータ数が約26.9億(2.69B)のモデルです。
小さなモデルでありながら、以下の特徴を持っています。
アーキテクチャの工夫
全30層の構成で、22ブロックの「ダブルゲート短畳み込み」と8ブロックのGQA(グループクエリアテンション)を組み合わせています。
GQAとは、Transformerの注意機構を効率化した手法で、メモリ使用量を抑えながら推論を速くする技術です。
この組み合わせが、モデルの「小ささ」と「処理能力」を両立させている核心部分です。
コンテキスト長131,072トークン
いわゆる「128K」と表現されるコンテキスト長です。
長い文書や会話履歴を丸ごと扱えるため、複数ステップにまたがるタスク処理に向いています。
動作速度とメモリ効率
AppleのM5 Maxチップ上で、毎秒220トークンのデコード速度を達成するとされています。
メモリ使用量は2.5GB未満で動作するとのことです。
スマートフォンやノートPCレベルのデバイスで動かせる現実的なサイズ感です。
対応フォーマット
GGUF、MLX、ONNXという3形式でウェイトが公開されています。
llama.cppやApple Silicon向けのMLXフレームワーク、あるいはWindows上でのONNX Runtimeなど、用途に応じて使い分けができます。
なぜ今、「オンデバイスのエージェント」なのか
「エージェント型AI」という言葉は最近よく聞きますが、これはAIが単に質問に答えるだけでなく、ツールを呼び出したり、複数のステップを自律的に実行したりする動作を指します。
たとえば「この資料を読んで、関連する情報をウェブで調べて、要約を作って」という一連の処理を自分で判断しながら進める、というイメージです。
これまでエージェント型AIはクラウド前提のものがほとんどでした。
GPT-4やClaudeのAPIを使った実装が主流で、処理のたびに外部サーバーとの通信が発生します。
オンデバイスでエージェント動作が完結するメリットは、大きく3つあります。
- プライバシー: データが端末の外に出ない
- レイテンシ(応答遅延): ネットワーク往復がないため応答が速い
- コスト: APIの従量課金が発生しない
Liquid AIがこのモデルを2.6B規模で実現した点は、技術的な挑戦として注目に値します。
パラメータ数が少ないほど、一般に能力は限られます。
それでもツール呼び出しと128Kコンテキストを詰め込んだのは、「端末で動かせる重さ」という制約のなかで何をどう実現するか、という設計判断の結果です。
開発者と一般ユーザー、それぞれへの意味
開発者・研究者にとって
オープンウェイトで公開されているため、自分のアプリやシステムに組み込んで試すことができます。
GGUFはローカル推論ツールで広く使われているフォーマットなので、すでに環境を持っている人はすぐに試せるはずです。
「社内文書を外部に送らずエージェント処理したい」というニーズには、検討に値するモデルです。
一般ユーザーにとって
現時点では、このモデルを直接使うには技術的な知識が必要です。
アプリとして整備されたものが登場するまでは、エンドユーザーが即座に恩恵を受ける段階ではないでしょう。
ただし、このようなモデルが今後スマートフォンアプリやPCソフトの「中身」として使われていく流れは、十分に考えられます。
まとめ
LFM2.5-2.6Bの公開は、「小型モデルでどこまでエージェントらしく動けるか」という問いへの、ひとつの実践的な回答です。
重要なのは、モデルの性能そのものよりも「設計の方向性」かもしれません。
クラウドに処理を預けることを前提としていた時代から、端末に処理を閉じ込めることを出発点にした設計へ——この転換は、AIの使われ方に対する根本的な問い直しを含んでいます。
プライバシーへの関心が高まるなかで、「どこで処理されるか」はこれからのAI選びの基準になっていく可能性があります。
技術を追いかける立場の人は、オンデバイスモデルの動向を引き続き注視しておく価値があるでしょう。