Oossa

TsinghuaのAKV、キャッシュでLLMエージェントのメモリーを管理

AKVは会話履歴を書き換えずに、保存したコンテキストの一部を破棄し、残りを並べ替えられる。開発者らは、テストでコスト低減と処理の高速化を確認したと報告している。

著者: Oossa公開日: 2 分で読める

Steve A Johnson · Unsplash

Tsinghuaの研究者らは、LLMエージェント向けのキャッシュ管理システム「AKV」を、GitHubでオープンソースとして公開した。エージェントの会話が長くなった際に短縮したり要約したりする代わりに、AKVでは保存情報の一部を破棄し、残りを並べ替えられる。言語モデル実行ソフトウェアのSGLangを基盤としており、キャッシュ操作を選ぶコンポーネントと、その操作を実行するサービングシステムの両方を備える。

この違いが重要なのは、エージェントの履歴に多数の観察結果、ツール呼び出し、その結果が含まれる場合があるためだ。これらすべてをモデルのアクティブなコンテキストに保持すると、ストレージと処理能力を消費する。一方、過去のメッセージを編集すると、それ以降のコンテキストを再計算する必要が生じる。この処理は「再プリフィル」と呼ばれる。AKVの論文によると、再プリフィルにはコストがかかる一方、履歴を削りすぎるとタスクの精度が低下するおそれがある。AKVは会話履歴そのものは維持し、モデルが参照する保存済みのキー・バリューキャッシュの範囲を変更する。

AKVの仕組み

AKVはエージェントに2種類のキャッシュ操作を提供する。「Drop」は選んだ情報を以後の参照対象から外し、「reposition」は保持する情報の位置を詰める。プロジェクトの例では、最新のツール結果を残し、新しい結果が届いた後に古い結果を破棄してから、残ったキャッシュの位置を詰める。元のメッセージはリクエスト内に残し、AKVサーバーがキャッシュへの指示を適用する。論文によれば、これにより保持したコンテキストの再プリフィルを避けられる。

また、システムはキャッシュに加えた変更を把握する必要がある。論文によると、会話のトークン列が同じでも、エージェントが異なる操作を使えばキャッシュの状態は異なりうる。そのため、サーバーは会話の先頭部分が一致するというだけで、キャッシュ情報を安全に再利用できるとは限らない。AKVはエージェント側のポリシーと、キャッシュの再利用、削除、復元を管理するSGLangベースのサーバーを組み合わせている。プロジェクトによると、サーバーは既存のサービングAPIと互換性のあるステートレスなインターフェースを使いながら、内部でキャッシュ状態を管理する。

テストで分かったこと

開発者らの実験では、ツールの応答にローリング方式のDropポリシーを適用すると、しきい値に達した時点で要約する方式と比べ、ベンチマークの平均スコアが1.7ポイント上昇し、平均コストが27.7%低下した。論文はさらに、出力スループットが最大1.2倍になり、リクエスト遅延の95パーセンタイルが1.5倍高速化したと報告している。キャッシュポリシーを改善する別の手法では、専門家が設計したポリシーに比べてコストが再帰的に7.1%低下した。これらは論文の著者らによる報告値であり、提供された資料には独立した追試の結果は記載されていない。

GitHubの手順では、Rust、Cargo、Python 3.12を使ってAKVをインストールする。クイックスタートの例では、AKV経由でGPT-OSS-120Bをサービングし、OpenAI互換のチャット補完形式でリクエストを送る。また、既存のエージェント実行基盤にポリシーを組み込み、サーバーに送る前にリクエストを処理する方法も紹介している。報告された結果は4つのエージェントベンチマークを対象としているが、提供された資料ではベンチマーク名が明かされておらず、他のモデルやワークロードでどの程度の削減につながるかを判断できるだけの詳細も示されていない。

なぜ重要か

ツールを繰り返し呼び出すエージェントを開発するチームにとって、AKVは会話履歴を書き換えずに古いツール結果を破棄する方法となる。開発者らはテストでコストが下がったと報告しているが、各チームで同様の削減が得られるかは、使用するモデルやワークロードによって異なる。

この記事は役に立ちましたか?
共有

次に読む

Oossa · ニュースレター

今週のAIを、わかりやすく

毎週月曜日、知っておきたいニュースをやさしい言葉で。無料・スパムなし。