プレフィックスキャッシュはホームAIサーバーで繰り返し行うプロンプト処理をどのように削減するのか？

プレフィックスキャッシュは、同一の先頭トークン列ですでに計算されたキー・バリュー状態を再利用することで、繰り返し発生するプロンプト処理を削減します。

ホームAIサーバーでは、共有されるプレフィックスにシステムポリシー、ツールスキーマ、長いドキュメント、家庭用の指示セット、繰り返されるチャット履歴などを含められます。最初のリクエストでは完全なプレフィルコストが発生しますが、その後の一致するリクエストでは、その大部分をスキップできます。主なメリットはプレフィル処理の短縮と最初のトークンの高速化であり、生成処理が無料になるわけではありません。

キャッシュがない場合、繰り返しプロンプトは同じプレフィルを再計算する

応答を生成する前に、自己回帰モデルは入力トークンを処理し、その後のデコードで使用するキー・バリュー状態を構築します。そのため、長いシステムプロンプト、ツールスキーマ、ドキュメントヘッダー、共有指示ブロックは、リクエストごとに同じプレフィル処理を消費する可能性があります。

Prompt Cacheは、この機会を重複するプロンプトセグメントのアテンション状態を再利用することで実現します。ホームAIサーバーでは、ユーザーが新たに入力するのは1文だけでも、繰り返される部分が数千トークンに及ぶことがあります。

再利用しなければ、GPUまたはCPUは同じプレフィックスに対して同じ行列演算を再び実行し、同じモデルウェイトを読み取ります。出力が同一でも、サーバーは計算準備のコストを支払う必要があります。

プレフィックスキャッシュは、処理済みプレフィックスのKV状態を保存する

互換性のある最初のリクエストの後、ランタイムは共有プレフィックスに関連付けられたKV状態を保持できます。後続のリクエストでは、先頭のトークン列がキャッシュ済みブロックと一致するかを確認して処理を開始します。

vLLMの自動プレフィックスキャッシュは、ブロック内のトークンと、その直前のプレフィックスによってブロックを識別します。一致するリクエストは、重複した状態を割り当てて計算する代わりに、同じ物理キャッシュブロックを参照できます。

再利用されるオブジェクトは最終回答でも、汎用的な意味要約でもありません。正確に一致する互換性のあるプレフィックスに対応した、モデル固有のアテンション状態です。

キャッシュヒット時は共有プレフィルをスキップするが、新しいサフィックスは計算する

プレフィックスが一致すると、ランタイムは保存されたアテンション状態から処理を開始し、キャッシュ境界より後にある新しいトークンだけを評価できます。安定したシステムプロンプトを使用する家庭用アシスタントなら、短いコマンドを処理するたびに発生する前処理を避けられます。

LMCacheは、LLMリクエスト間でのKVキャッシュ再利用を、モデルウェイトを変更するのではなく、サービング層で行う最適化として説明しています。

新しいユーザーメッセージには依然としてプレフィルが必要であり、生成されるすべての出力トークンにはデコード計算が必要です。プレフィックスキャッシュは主に、生成開始前の重複処理を削減します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

長く安定したプレフィックスほど、最初のトークンまでの時間を大きく短縮する

キャッシュによって節約できる処理量は、本来なら再計算される部分の大きさに比例します。2,000トークンの指示とドキュメントのプレフィックスを再利用する方が、10トークンの挨拶を再利用するよりも効果が大きくなります。

SGLangのサービング設計では、構造化されたKV再利用を利用して、共有プレフィックスを使用するワークロードを高速化します。ホームサーバーでの同等の例として、繰り返し使用するエージェントポリシー、ツールカタログ、家庭用ナレッジパケット、ドキュメントテンプレートなどがあります。

そのため、プレフィックスキャッシュは生成中の1秒あたりのトークン数だけでなく、最初のトークンまでの時間とプレフィルスループットで評価すべきです。デコードフェーズはほぼ変わらなくても、応答の開始を早められます。

小さなプロンプト変更でも、ブロック境界で再利用が途切れることがある

キャッシュは通常、トークンとモデル状態に対して厳密です。ツール定義の並べ替え、冒頭付近への変化するタイムスタンプの挿入、アダプターの切り替え、システムプロンプトの変更などによって、後続のブロックが再利用対象外になることがあります。

Hugging Faceのサービングガイダンスでは、プレフィルとデコードのスケジューリングを区別しています。プロンプトの前方に安定した内容を配置すると、そのプレフィルのより大きな割合を再利用できるようになります。

したがってアプリケーションでは、同じ情報を後方に配置できる場合、全体として安定したプレフィックスの先頭に変動するデータを挿入しないようにすべきです。

キャッシュ容量と追い出しが、ホームサーバーでの限界を決める

KVブロックはメモリを消費するため、サーバーがすべてのプレフィックスを永久に保持することはできません。同時進行する会話、長いコンテキスト、複数のモデルが同じメモリプールを奪い合い、古い再利用可能な状態が追い出されることがあります。

ZimaSpaceによるモデルキャッシュとウォーム応答のレイテンシーの解説では、より広範なキャッシュ階層を紹介しています。プレフィックスキャッシュはその一層にすぎず、モデルウェイトをメモリ上に常駐させることと混同しないでください。

実際の家庭内同時利用レベルで、キャッシュヒット率、再利用トークン数、最初のトークンまでの時間、プレフィルスループット、KVメモリ使用量、追い出し率を測定してください。

NVIDIAのTensorRT-LLMドキュメントでは、KVキャッシュの再利用をサービング最適化として説明しており、同じ基本的な制限があります。つまり、再利用可能な状態が利用可能な間だけ、その状態は役立ちます。