AIエージェントをスマートフォンやPCの中だけで動かせれば、個人情報をクラウドへ送らず、ネットワークがない場所でもタスクを実行できます。
しかし、端末上のLLM（大規模言語モデル）は計算能力とメモリ帯域が限られ、簡単な予定登録にも数十秒かかる場合があります。
本記事では、prefillとdecodeの両方をソフトウェアだけで高速化するAgent-Xを取り上げ、PromptWeaver、ExSpec、実機評価、導入上の注意点を論文ベースで解説します。
3文要約
Agent-Xは、オンデバイスAIエージェントの遅延を、入力を処理するprefillと出力を生成するdecodeの両面から削減するソフトウェアフレームワークです。
PromptWeaverはプロンプトを並べ替えてKV cache（過去トークンのAttention計算結果）の再利用を増やし、ExSpecはfew-shot例から作る軽量なtrigram表で、追加LLMなしの投機的デコーディングを行います。
論文では、M4 Pro搭載Mac miniとTinyAgent-7Bを用いた評価で、prefillを平均1.97倍、decodeを1.73倍、エージェント全体を1.61倍に高速化し、タスク精度を維持したと報告しています。
論文情報
| 項目 | 内容 |
|---|---|
| 論文タイトル | Agent-X: Full Pipeline Acceleration of On-device AI Agents |
| 著者 | Jinha Chung, Byeongjun Shin, Jiin Kim, Minsoo Rhu |
| 研究機関 | KAIST |
| 発表年 | 2026年 |
| arXiv提出 | 2026年5月11日、v1 |
| 採択 | MobiSys 2026 |
| 論文リンク | Agent-X: Full Pipeline Acceleration of On-device AI Agents |
| arXiv PDF |
本記事はv1を対象にします。
論文が報告する測定結果と、本記事による実運用への解釈は分けて記載します。
本記事の目的
オンデバイスLLMの高速化というと、量子化、小型モデル、NPU（ニューラルネットワーク向け演算器）など、モデルやハードウェアの改善を連想しがちです。
Agent-Xの特徴は、エージェントのプロンプトと出力が持つ規則性を利用し、既存モデルの精度を変えずに推論パイプラインを短縮する点です。
本記事では、次の順番で整理します。
- オンデバイスAIエージェントの処理フロー
- 通常のチャットLLMとは異なる遅延の内訳
- PromptWeaverによるprefill高速化
- ExSpecによるdecode高速化
- 実機で得られた効果とストレージ・メモリの代償
- スマートフォン、PC、カメラへ応用する際の課題
対象読者は、AIエージェントやローカルLLMに関心のある初学者から、端末推論を設計するMLエンジニアまでです。
背景：オンデバイスAIエージェントはどう動くのか
AIエージェントは、LLMが文章を返すだけでなく、カレンダー、連絡先、メールなどのtool（外部機能）を選び、引数を作り、実行結果を確認する仕組みです。
論文が扱うplan-out型では、処理は大きく次の3段階に分かれます。
| 段階 | 役割 | 主な入出力 |
|---|---|---|
| Planner | ユーザー要求から実行計画を作る | tool説明、few-shot例、ユーザー要求 → tool列と引数 |
| Execution unit | toolを依存関係に従って実行する | tool列 → call-observationの組 |
| Arbiter | 実行結果が要求を満たしたか判定する | ガイドライン、実行結果 → 完了または再試行 |
PlannerとArbiterは別々にLLMを呼び出します。
一方、ReAct型のように1手ずつ「考える→実行→観測」を繰り返す方式では、\(N\)ステップに対して最大\(2N\)回のLLM呼び出しが必要です。
plan-out型は全計画を先に作り、最後にまとめて検証するため、LLM呼び出しを2回に減らせます。
それでも端末上では、PlannerとArbiterの各推論が重く、体感待ち時間が長くなります。
従来技術の課題：prefillとdecodeの両方が遅い
LLM推論は、次の2段階に分かれます。
| 段階 | 処理 | 主な制約 |
|---|---|---|
| prefill | 入力トークンをまとめて処理し、KV cacheを作る | 行列演算量、計算性能 |
| decode | KV cacheを読みながら1トークンずつ生成する | モデル重みとKV cacheを運ぶメモリ帯域 |
クラウド上の一般的な対話LLMでは、入力より長い出力を生成することが多く、decodeが遅延の95%以上を占める例があります。
ところが、AIエージェントの入力には、system prompt、tool説明、ガイドライン、few-shot例が大量に含まれます。
Agent-X論文がTinyAgent-7BをM4 Pro搭載Mac miniで測定したところ、1タスクは平均35.4秒でした。
遅延の90.4%をPlannerとArbiterが占め、その内訳はdecodeが68.7%、prefillも21.7%でした。
つまり、decodeだけを高速化しても、prefillが次の壁として残ります。
prefix cachingが使いにくい理由
prefix cachingは、複数の入力が同じ先頭部分を持つとき、その部分のKV cacheを再利用する技術です。
入力列を\(x_{1:L}\)、最初に一致しない位置を\(m\)とすると、再利用できるのは原則として\(x_{1:m-1}\)までです。
後半に同じ文章が再登場しても、途中に1トークンの違いがあれば、その先のcacheはそのまま再利用できません。
Planner入力は平均1,739トークンあり、system promptだけで32.7%を占めます。
しかし、要求に応じて選ばれるtool説明が入力の早い位置に挿入されるため、最初の動的トークンは全体の1.6%地点に現れます。
静的文章が多いのに、並び順のためにほとんどcacheできないことが問題です。
通常の投機的デコーディングが重い理由
投機的デコーディングは、小さなdraft modelが複数の候補トークンを作り、大きなtarget modelがまとめて検証する手法です。
候補が多く採用されれば、大きなモデルを1トークンずつ呼ぶ回数を減らせます。
しかし端末では、draft LLM自体が数百MBから数GBのメモリと生成時間を必要とします。
さらに論文のMLX-LM環境では、TinyAgentの1トークン推論が131msなのに対し、2トークンの一括検証は244msでした。
論文はこの1.86倍の不利をmulti-token tax（複数トークン検証の追加負担）と呼んでいます。
Llama-3.2-1B-Instructをdraftにした場合も、tax込みの理論上限は1.20倍にとどまり、実測ではtokenizer差などの追加負担により遅くなりました。
論文解説：Agent-Xの全体像
Agent-Xは、2つの手法を組み合わせます。
| 構成要素 | 対象 | 利用する規則性 | 代償 |
|---|---|---|---|
| PromptWeaver | prefill | toolの共起と、静的prompt断片の組み合わせ | SSD上の事前計算KV cache、入力長増加 |
| ExSpec | decode | 出力がfew-shot例やユーザー入力と高く重複 | クエリごとの小さな\(n\)-gram表 |
ポイントは、モデルを再学習せず、量子化による近似も導入しないことです。
論文でいうaccuracy-preserving（精度維持）は、TinyAgentの評価データにおける実行計画DAGの一致精度を落とさなかったことを指します。
任意のモデル、任意のエージェント、任意の端末で精度が数学的に保証されるという意味ではありません。
PromptWeaver：cacheしやすい順序へプロンプトを編み直す
PromptWeaverは、早い位置にある動的断片を減らし、入力を次の順に再構成します。
- 全toolの説明とガイドラインからなる静的prefix
- 共起関係でcluster化した半静的なtool-use例
- ユーザー要求に合わせて選ぶ動的なtool-use例
一見すると、必要なtoolだけを入れるより、全toolの説明を入れる方が非効率に見えます。
しかし、全tool説明は毎回同じため、KV cacheをofflineで1回だけ計算し、SSDへ保存できます。
1 tool当たりの説明を平均120トークンとすると、\(t\)個のtoolでは静的部分は約\(120t\)トークンです。
論文の見積もりでは、100 toolでも追加のKV cacheはSSD上で約1.4GBです。
オンライン計算を、端末ストレージからのcache読み込みへ置き換える設計だと考えると分かりやすいでしょう。
PromptWeaver：tool共起をcluster化して組み合わせ爆発を避ける
\(t\)個のtoolに対して、すべての組み合わせをcacheすると候補数は次のように増えます。
\[ N_{\mathrm{comb}} = 2^t – 1 \]
TinyAgentの16 toolでも、すべてのtool-use例の組み合わせを保存すると、論文の試算では約800GBになります。
PromptWeaverは、学習データからtoolが同時に使われた回数を共起行列として作り、NMF（非負値行列因子分解）で8 clusterへまとめます。
さらに、メール、連絡先、地図などのthemeが近いclusterを隣接させます。
cache予算を\(N\)、学習データを\(\mathcal{D}\)、保存済みprefix集合を\(\mathcal{C}\)とすると、各段階でcoverageの増分が最大のprefixを選びます。
\[ \hat{p} = \operatorname*{arg\,max}_{p\in\mathrm{options}} \left[ \mathrm{coverage}(\mathcal{D},\mathcal{C}\cup\{p\}) – \mathrm{coverage}(\mathcal{D},\mathcal{C}) \right] \]
ここでcoverageは、各要求が使うcluster列について、保存済みcacheと一致する最長prefixの長さを合計した指標です。
論文では15 cluster分のcache、合計6.26GBでtool-use例の74.4%をcoverageしました。
精度を保つため、cluster例だけでなく、選択toolのsingle-tool例と、ToolRAGが取得する上位\(K=1\)件の動的な関連例を末尾へ加えます。
ExSpec：few-shot例からtrigram lookup tableを作る
論文の分析では、Planner出力の96%、Arbiter出力の87%が入力prompt中のトークンと重複しました。
tool名、JSON風の引数、実行順、完了判定などが、few-shot例の定型を強く反映するためです。
ExSpecはこの性質を利用し、few-shot例とユーザー要求から、その場で\(n\)-gram LUT（lookup table、対応表）を作ります。
\(n=3\)のtrigramでは、直前2トークン\((t_{i-2},t_{i-1})\)をkey、次のトークン\(t_i\)をvalueとして記録します。
\[ \mathrm{LUT}[t_{i-2},t_{i-1}] = \operatorname*{mode}\left(t_i\right) \]
同じkeyに複数の次トークンが現れた場合は、最頻値を使います。
生成中は直前2トークンでLUTを検索し、得られたトークンをdraftとしてtarget LLMへ渡します。
LUTは数KBで、生成はhash検索に近い軽い処理です。
論文ではLUT構築に1クエリ83msかかりましたが、全体遅延に対して小さいと評価しています。
ExSpec：当たりそうなときだけ投機する
\(n\)-gram表に現在の文脈がなければ、draftを推測しても採用されにくく、multi-token taxだけを支払うことになります。
ExSpecは最初のdraftを作る前にLUTを確認し、entryがなければ即座に通常のautoregressive decode（1トークンずつの生成）へ戻ります。
| 状態 | ExSpecの動作 | 狙い |
|---|---|---|
| LUT hit | 複数draftを作り、target LLMで検証 | 定型出力をまとめて生成 |
| LUT miss | 投機せず通常decode | 不採用draftの検証負担を回避 |
この選択は、別の信頼度モデルを動かさずに決定できます。
trigramは、bigramより文脈を使えてdraft精度が高く、quadgramよりhitしやすい中間点です。
論文ではbigramのdraft精度が0.10、trigramが0.25、quadgramが0.31でした。
ただしquadgramはdraft数がtrigramの72%に減り、合計decode遅延はtrigramより5.1%長くなりました。
実験結果：Agent-Xはどこまで高速化したか
評価環境は、M4 Pro、64GB unified memory、512GB SSDを搭載したMac miniです。
TinyAgent-7B、TinyAgentのテストデータ1,022件、MLX v0.25.2を用い、各タスク前にpage cacheをflushしてSSDからのKV cache読み込みを含めています。
| 評価対象 | 結果 | 補足 |
|---|---|---|
| Planner prefill | 1.57倍 | uncached tokenを49.6%削減 |
| Arbiter prefill | 4.35倍 | uncached tokenを88.9%削減 |
| prefill平均 | 1.97倍 | PlannerとArbiterを統合 |
| ExSpec decode | 1.73倍 | selective fallbackあり |
| PromptWeaverのみ、全体 | 1.16倍 | prefill側のみ改善 |
| ExSpecのみ、全体 | 1.43倍 | decode側のみ改善 |
| Agent-X全体 | 1.61倍 | PromptWeaverとExSpecを併用 |
PromptWeaverでは、\(K=1\)の動的関連例を追加したとき、Planner精度がbaselineの0.836に対して0.841となりました。
したがって論文は、評価上の精度低下なしとしています。
一方、入力長は平均1,739から3,790トークンへ増え、KV cacheのメモリ使用量が256MB増えました。
decodeのTime-Per-Output-Tokenも122msから125msへ2.2%悪化しています。
prefillの削減効果がこの負担を上回るため、全体では高速になります。
この結果は「入力を短くすれば必ず速い」のではなく、「再計算が必要な入力を短くする」ことが重要だと示しています。
実サービス・エッジデバイスへの応用
Agent-Xが適するのは、tool定義と出力形式が比較的安定し、似た種類の要求を繰り返すエージェントです。
| 応用例 | Agent-Xが活かせる点 | 導入上の課題 |
|---|---|---|
| スマートフォン秘書 | 連絡先、予定、メールtoolの共起が安定 | OS API変更、端末ストレージ制約 |
| オフライン業務PC | 社内データを外部送信せず処理 | tool権限管理、端末ごとの性能差 |
| 車載アシスタント | 通信断でもナビ・空調toolを操作 | 安全性、最悪遅延、誤操作対策 |
| カメラ内エージェント | 撮影設定、選別、編集toolを自然言語で連携 | 画像入力を含むVLMへの拡張、発熱 |
カメラへ応用する場合、Agent-X自体がdenoise、demosaic、super resolutionを高速化するわけではありません。
想定できるのは、「逆光画像を選び、denoiseをかけ、共有用に縮小する」といった複数の画像処理toolを、端末内エージェントが計画・実行する場面です。
画像特徴を入力するVLM（視覚言語モデル）では、vision encoderの計算や画像tokenが新たなボトルネックになります。
Agent-Xのテキスト中心の結果をそのまま適用できるかは、別途検証が必要です。
よくある誤解
| よくある誤解 | 正確な情報・解釈 |
|---|---|
| Agent-Xは新しいLLMである | 既存LLMの入力構成と推論を最適化するソフトウェアフレームワークです |
| promptを短くして高速化する | PromptWeaverは入力を長くする場合がありますが、事前計算cacheでonline計算を減らします |
| ExSpecは小型LLMを追加する | few-shot例から作る数KBの\(n\)-gram LUTをdraft modelとして使います |
| 1.61倍は全端末で保証される | M4 Pro、TinyAgent-7B、特定データセットでの平均実測値です |
| 精度維持は数学的に保証される | 評価データのPlanner DAG精度で低下がなかったという実験結果です |
| どんなエージェントにも効く | 静的prompt断片、tool共起、定型的出力が少ないworkloadでは効果が弱い可能性があります |
制約と今後の課題
Agent-Xの結果を読むときは、次の制約を押さえる必要があります。
- 主評価はmacOS、M4 Pro、TinyAgentに集中している
- toolの学習データを使い、offlineでclusterとcache候補を作る必要がある
- 15 cluster予算で6.26GBのSSDを使う
- tool分布が大きく変わるとcache coverageが下がる可能性がある
- multimodal agentやReAct型へのend-to-end効果は未検証である
- SSD読み込み、寿命、暗号化、cache更新の運用設計が必要になる
論文では、notes関連toolを無効化するdistribution drift（利用分布の変化）を試し、精度低下は0.8ポイント、coverageは75.7%でした。
一定の頑健性は示されていますが、新しいtool群の追加や利用傾向の長期変化では、clusterとcacheの再構築頻度を検討する必要があります。
また、ExSpecの効果は出力がfew-shot例に似るほど高まります。
自由形式の長文生成や複雑な推論では、LUT hitとdraft採用率が下がると予想されます。
これは論文結果からの推測であり、個別workloadでの計測が必要です。
関連技術
| 技術 | 主な対象 | Agent-Xとの違い・関係 |
|---|---|---|
| Prefix caching | 共通prefixのprefill | PromptWeaverはprompt再構成とoffline cache選択で適用範囲を広げる |
| Speculative decoding | decode | ExSpecは追加LLMを使わず、LUT miss時に投機を避ける |
| Prompt compression | prefill | 入力自体を短縮するのに対し、PromptWeaverは静的化して再利用する |
| Quantization | モデル重み・KV cache | 精度とのtrade-offがあり、Agent-Xとは併用可能 |
| ToolRAG | toolとfew-shot例の選択 | Agent-Xが前提とする動的promptを構築し、PromptWeaverが並べ直す |
| Constrained decoding | 構造化出力 | JSON grammarなどで候補を制約し、ExSpecとは異なる方向から定型出力を効率化する |
Agent-Xは、モデル圧縮や専用hardwareと競合するというより、上位のagent runtimeで補完する技術です。
例えば、量子化したLLMをNPUで動かしつつ、PromptWeaverでprefillを減らし、ExSpecで定型decodeをまとめる構成が考えられます。
ただし、複数最適化を組み合わせると、KV cache形式、一括検証性能、メモリ配置が変わるため、効果は単純な掛け算にはなりません。
まとめ
Agent-Xは、オンデバイスAIエージェント固有の入力と出力の規則性に注目し、prefillとdecodeを同時に最適化する手法です。
PromptWeaverは、動的なtool説明を含むpromptをcacheしやすい構造へ編み直し、tool共起clusterとSSD上のKV cacheでonline計算を減らします。
ExSpecは、few-shot例とユーザー要求からtrigram LUTを作り、当たりそうな文脈だけで投機的デコーディングを使います。
論文のM4 Pro実機評価では、精度を維持しながら全体を平均1.61倍に高速化しました。
一方で、6.26GBのcache保存、入力長の増加、TinyAgent中心の評価という制約があります。
実導入では、平均速度だけでなく、tool更新時のcache再構築、SSD使用量、worst-case latency、対象workloadの定型性を合わせて評価することが重要です。
次に読むべき記事
- KV Cacheとは？Transformer推論で再計算を減らす仕組み
- Prefix Cachingとは？共通promptを再利用する条件と設計
- 投機的デコーディングとは？draft modelと検証処理を解説
- オンデバイスLLMの量子化とNPU実行の基礎
- AIエージェントのTool CallingとMCPの仕組み
関連記事のURLは公開時に追加します。
コメント