プロンプトキャッシュとは
Prompt Caching / Context Caching
プロンプトの共通部分をサーバー側でキャッシュし、繰り返し送信時のレイテンシとコストを削減する仕組み
ひとことで言うと
AIに何度も送る同じ前置き部分を覚えておいてもらい、次回以降は計算し直さず済ませて速く安くする仕組み。
概要
プロンプトキャッシュは、システムプロンプトや長い参考文書など複数回のAPI呼び出しで繰り返し使われるプロンプトの共通部分について、モデル側の内部計算結果(KVキャッシュ)をサーバー側に一定時間保持しておく仕組み。 次回以降の呼び出しでは、その部分の再計算を省略することでレイテンシとコストを削減できる。 通常、LLMはリクエストのたびにプロンプト全体をゼロから処理してAttentionを計算するが、プロンプトキャッシュを使うと変化しない共通部分の計算結果を使い回せるため、実質的に処理が必要なのは新しく追加された差分部分だけになる。 同じプレフィックスを持つリクエストをキャッシュ有効時間内に送ると、通常より低いコストかつ短いレイテンシで応答を得られることが多い。料金体系上もキャッシュヒット分の入力トークンは割安に設定されていることが一般的。 長い社内文書を毎回コンテキストとして与えるRAGシステムや、同じシステムプロンプトを使い続けるチャットボットなど、同一の前提を繰り返し使う用途で特に効果を発揮する。
背景
長いシステムプロンプトや参考文書を毎回コンテキストに含めるアプリケーションでは、リクエストのたびに同じ内容をゼロから処理することになり、レイテンシとコストの両面で無駄が生じていた。 プロンプトキャッシュは、変化しない共通部分の計算結果を再利用できるようにすることで、この無駄を解消する目的で提供されている。
歴史
2024年: AnthropicがClaude APIにプロンプトキャッシュ機能を導入。 2024年: GoogleがGemini APIにContext Cachingとして同様の機能を提供。 2024年: OpenAIも同等の機能をAPIへ追加し、主要なLLM提供元で標準的な機能として定着。
ワークフロー
アプリケーションは、システムプロンプトや参考文書などキャッシュしたい共通部分をリクエストの先頭に固定した形で送信する。 API提供側は、その部分の内部計算結果(KVキャッシュ)を一定時間サーバー側に保持する。 同じ共通部分を持つ後続のリクエストが来た場合、保持されたキャッシュを再利用し、新規に追加された差分部分のみを計算して応答を生成する。
利点
欠点
- キャッシュにはプレフィックス(先頭からの共通部分)の完全一致が必要で、途中の文言を少し変えるだけでキャッシュが無効になる
- キャッシュの保持時間には上限があり、リクエストの間隔が空くとキャッシュが失効する
- 提供元ごとにキャッシュの仕組みや料金体系が異なり、設計時に確認が必要
比較
- KVキャッシュ — プロンプトキャッシュは、1回の生成内で使うKVキャッシュの考え方を、複数回のAPI呼び出しをまたいで再利用できるよう拡張したもの
- コンテキストウィンドウ — プロンプトキャッシュは、大きなコンテキストウィンドウを繰り返し使う際のコストとレイテンシの課題を軽減する
- システムプロンプト — 変化しないシステムプロンプトは、プロンプトキャッシュの効果を得やすい代表的な対象
関連用語
よくある質問
プロンプトキャッシュはどんな場面で効果が大きい？
長いシステムプロンプトや参考文書を毎回同じ内容で送信するRAGシステムやチャットボットなど、リクエストの先頭部分が変わらないケースで特に効果が大きい。
プロンプトの一部を書き換えるとキャッシュはどうなる？
キャッシュはプレフィックスの完全一致を前提とするため、キャッシュ対象部分より前方の文言を変更すると、それ以降の内容も含めてキャッシュが無効になる。
参考文献
- DocumentationAnthropic Prompt Caching