論文の概要: EfficientAgent: What Makes KV Cache Offloading Work for Concurrent Agents?

• arxiv url: http://arxiv.org/abs/2609.33762v1
• Date: Sun, 27 Sep 2026 17:01:29 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-10-04 16:58:32.509659
• Title: EfficientAgent: What Makes KV Cache Offloading Work for Concurrent Agents?
• Title（参考訳）: EfficientAgent: 並行エージェントのKVキャッシュのオフロード作業には何があるのか?
• Abstract要約: LLMエージェントはすべてのターンで会話全体を再送し、そのほとんどが既に前のターンで処理されていた。 同じワークロードでは、ひとつのデプロイメントをスピードアップし、別のデプロイを遅くし、3分の1で何も変更しない。 この作業セットによってホスト層のサイズと管理を行うEfficientAgentを提案する。
• 参考スコア（独自算出の注目度）: 31.538628189836828
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: LLM agents resend their whole conversation on every turn, and most of it was already processed on the previous turn. Serving systems avoid recomputing it by caching its key-value (KV) state and, when GPU memory runs out, by offloading that state to host memory. For agents, offloading gives inconsistent results: on the same coding-agent workload it speeds up one deployment, slows down another, and changes nothing on a third, even where loading a token back is several times cheaper than recomputing it. The reason is that cached state must survive until it is used again. While one agent waits for its tool, the server processes the contexts of all other agents, so an agent's prefix is reused only if the host tier holds the reusable context of the whole agent pool, which we call the reuse working set. A smaller tier keeps writing state that is evicted before anyone reads it. We present EfficientAgent, which sizes and manages the host tier by this working set. A stack-distance model estimates the working set from agent histories to size the host tier; its predictions, made before the experiments, located the capacity at which offloading starts to pay. When the tier is too small, a runtime policy stops writing large refills of evicted context and keeps extending prefixes that are still cached; when the tier is large enough, it writes everything. On SWE-bench Verified coding agents, a host tier sized to the estimated working set cuts recomputed prompt tokens by 93% and end-to-end time by 39%. With a small fixed tier, the policy cuts recomputation by 35%; with a large tier, it avoids the 4.3-fold increase caused by always filtering writes. Across three GPU types and two models, offloading pays off when the GPU has little compute per byte of host bandwidth and the host tier holds the working set. Code is available at https://github.com/KunmingSHAO/efficientagent_release.
• Abstract（参考訳）: LLMエージェントはすべてのターンで会話全体を再送し、そのほとんどが既に前のターンで処理されていた。 サービングシステムは、キー値(KV)状態をキャッシュし、GPUメモリが切れた時に、その状態をホストメモリにオフロードすることで、再計算を避ける。 同じコーディングエージェントのワークロードでは、ひとつのデプロイメントをスピードアップし、別のデプロイを遅くし、トークンのロードが再計算するよりも数倍安い場合であっても、3分の1で何も変更しない。 その理由は、キャッシュされた状態が再び使用されるまで生き残らなければならないからである。 あるエージェントがそのツールを待つ間、サーバは他のエージェントのコンテキストを処理するので、エージェントのプレフィックスは、ホスト層がエージェントプール全体の再利用可能なコンテキストを保持する場合にのみ再利用されます。 小さな階層は、誰かがそれを読む前に取り除かれた状態を書き続けます。 この作業セットによってホスト層のサイズと管理を行うEfficientAgentを提案する。 スタック距離モデルは、エージェント履歴から処理セットを推定し、ホスト層のサイズを推定する。 ティアが小さすぎると、ランタイムポリシーは、削除されたコンテキストの大規模なリフィルを書くのをやめ、まだキャッシュされているプレフィックスを拡張します。 SWE-bench Verified コーディングエージェントでは、推定作業セットに相当するホスト層がプロンプトトークンを93%削減し、エンドツーエンドの時間を39%削減した。 小さな固定層では再計算を35%削減し、大きな層では書き込みを常にフィルタリングすることで引き起こされる4.3倍の増加を避ける。 3つのGPUタイプと2つのモデルにまたがって、GPUがホスト帯域当たりの計算量がほとんどなく、ホスト層がワーキングセットを保持すると、オフロードが報われる。 コードはhttps://github.com/KunmingSHAO/efficientagent_release.comから入手できる。

関連論文リスト

• Receiver-Conditioned Latent Communication gives 94% CacheBack [5.675007684604366]
  最近の潜時通信は代わりにKVキャッシュを転送する。 完全なKVキャッシュは、個々のエージェントプロセスのコンテキストと、協調するエージェントの数の両方で線形に増加する。 私たちのキーとなる観察は、エージェントは受信エージェントがローカルタスクに必要とするもののみを送信する必要があるということです。
  論文  参考訳（メタデータ） (2026-09-25T22:20:08Z)
• Learning Agent Execution for KV-Cache Management in Agentic Serving [25.021363822677515]
  マルチエージェントLLMサービスのためのエージェント対応KV-cacheランタイム層であるCacheScoutを提案する。 鍵となる洞察は、将来のKV-cacheの再利用は、キャッシュのレイテンシ単独ではなく、エージェントの実行セマンティクスによって管理されることである。 CacheScout は KV-cache のヒット率を 10-18 ポイント改善し,平均 TTFT を 18-45% 削減し,平均 TTFT を 29-38% 削減し,ピークスループットを 57% 向上させることを示した。
  論文  参考訳（メタデータ） (2026-07-16T22:28:19Z)
• AgentCheck: A Reproduce-Intervene-Mitigate Workbench for LLM Agents over MCP [0.0]
  AgentCheckは、実際のツールに対してエージェントを実行し、すべてのツール応答を記録し、その後、障害(12タイプ)インジェクタによって妨害されたレスポンスでエージェントを再実行します。 マッチングツールコールはキャッシュからリプレイされ、その後、エージェントが分岐した後にツールコールがライブになる。 開発者は緩和をトグルし、同じ障害に対して再実行し、障害が消滅するかどうかを確認する。
  論文  参考訳（メタデータ） (2026-07-13T05:14:12Z)
• Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity? [54.701199583505144]
  アプリケーション間アクセスは、ほとんど見落とされたプライバシーリスクを生み出す。 我々はAgentCIBenchを紹介します。これは、このリスクを決定論的に評価されたシナリオに変換する評価ハーネスです。 我々は15のフロンティアエージェントを評価し、驚くほど高い失敗率を見出す。
  論文  参考訳（メタデータ） (2026-06-22T11:36:58Z)
• Multi-Agent Computer Use [72.79887808312706]
  我々はマルチエージェント・コンピュータ・ユース(MACU)システムの評価・構築に向けて進むべきであると論じる。 本稿では、マネージャモデルがコンピュータ使用タスクを有向非巡回グラフ(DAG)として分解する汎用マルチエージェント構成を提案する。 各イテレーションで、マネージャは並列CUAサブエージェントをディスパッチし、DAGの準備ができているフロンティアでノードを実行する。
  論文  参考訳（メタデータ） (2026-06-01T01:29:36Z)
• A Policy-Driven Runtime Layer for Agentic LLM Serving [6.975319765760388]
  マルチエージェント LLM システムはプロダクションワークロードの主流となっているが、サービススタックは構築されなかった。 このシームは、ポイント修正よりもアーキテクチャの変更によって対処されるのが最善である、と私たちは主張する。 5つの実マルチエージェントワークロードの予備的な結果は、+13から+37ppキャッシュヒットレートリフト、12%から29%低い平均TTFT、6%から14%高いスループットを示す。
  論文  参考訳（メタデータ） (2026-05-26T22:38:34Z)
• AgentSys: Secure and Dynamic LLM Agents Through Explicit Hierarchical Memory Management [47.49917373646469]
  既存の防御は肥大した記憶を与えられたまま扱い、回復力を維持することに集中する。 我々は、明示的なメモリ管理を通じて間接的なインジェクションを防御するフレームワークであるAgentSysを紹介する。
  論文  参考訳（メタデータ） (2026-02-07T06:28:51Z)
• BackdoorAgent: A Unified Framework for Backdoor Attacks on LLM-based Agents [58.83028403414688]
  大規模言語モデル(LLM)エージェントは、計画、メモリ、ツールの使用を組み合わせた多段階ワークフローを通じてタスクを実行する。 エージェントワークフローの特定のステージに注入されたバックドアトリガーは、複数の中間状態を通して持続し、下流出力に悪影響を及ぼす可能性がある。 LLMエージェントにおけるバックドア脅威を統一したエージェント中心のビューを提供するモジュールおよびステージアウェアフレームワークである textbfBackdoorAgent を提案する。
  論文  参考訳（メタデータ） (2026-01-08T03:49:39Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。