Prefix Caching（プレフィックスキャッシング）
LLMの推論においてプロンプトの前半（プレフィックス）のKVキャッシュを保存・再利用することで、同じシステムプロンプトを繰り返し使うコストとレイテンシを削減する最適化技術。
Prefix Caching とは
Prefix Caching（プレフィックスキャッシング）とは、LLMの推論時にプロンプトの先頭部分（プレフィックス）の計算結果（Key-Valueキャッシュ）を保存し、後続のリクエストで再利用する技術だ。
Transformerアーキテクチャでは、全てのトークンの注意計算（Attention）のために大量のKey・Valueベクトルを計算する。同じシステムプロンプトやコンテキストを毎回再計算するのは無駄であり、これを一度計算してメモリに保存しておく仕組みがPrefix Caching。
なぜPrefix Cachingが重要か
典型的なLLMアプリケーションの構造：
[システムプロンプト（固定・数千トークン）]
+ [ユーザーコンテキスト（RAGで取得した文書など）]
+ [会話履歴（前のターン）]
+ [ユーザーの最新メッセージ]
このうちシステムプロンプトとユーザーコンテキストは多くのリクエストで共通している。これらを毎回計算するのは：
- 計算リソースの無駄（コスト増）
- 応答レイテンシの増大
Prefix Cachingにより、共通部分を一度だけ計算してキャッシュし、以降は再利用する。
主要プロバイダーの実装
Anthropic Prompt Caching（Claude）
2024年8月にリリース。最も積極的にコスト削減を謳う実装。
| 項目 | 詳細 |
|---|---|
| 対応モデル | Claude 3.5 Sonnet/Haiku、Claude 3 Haiku/Opus、Claude 3.7以降 |
| 最小キャッシュ長 | 1,024トークン（Haikuは2,048） |
| キャッシュTTL | 5分（明示的キャッシュは1時間） |
| コスト削減率 | 入力トークン最大90%削減 |
| レイテンシ削減 | 約85%削減（キャッシュヒット時） |
APIでの使用方法：
# Anthropic SDK（Python）
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "あなたは法律専門家です。...", # 長いシステムプロンプト
"cache_control": {"type": "ephemeral"} # ← キャッシュマーク
}
],
messages=[{"role": "user", "content": "契約書を確認してください"}]
)
OpenAI Prompt Caching
2024年10月実装。自動的にキャッシュされ、APIユーザーは意識不要。
| 項目 | 詳細 |
|---|---|
| 対応モデル | GPT-4o、GPT-4o mini、o1シリーズ |
| キャッシュTTL | 約1時間（APIサーバー側で自動） |
| コスト削減率 | 入力トークン50%割引 |
| 最小キャッシュ長 | 1,024トークン |
Google Context Caching（Gemini）
Gemini APIで「Context Caching」として提供。特に長文コンテキストでの効果が顕著。
| 項目 | 詳細 |
|---|---|
| 対応モデル | Gemini 1.5 Pro/Flash |
| キャッシュTTL | 最短1分、最大60分（調整可能） |
| コスト削減率 | 入力トークン75%割引 |
| 最小キャッシュ長 | 32,768トークン（32K+） |
| 最大キャッシュ長 | 10,000,000トークン（1,000万） |
KVキャッシュの仕組み（技術詳細）
LLM推論の計算ボトルネックはAttention計算。各トークンのKey（K）とValue（V）ベクトルを全ての先行トークンに対して計算する必要がある。
新規計算: [P1 P2 P3 ... P_n U1 U2] → 全トークン分KV計算
←システムプロンプト→←ユーザー→
Prefix Caching適用後:
キャッシュ: [P1 P2 P3 ... P_n] のKV → 保存済み（再計算不要）
新規計算: [U1 U2] のKV → これだけ計算
実装のポイント：
- プレフィックスが完全一致する必要がある（トークン列として）
- ランダムなseedやtemperatureはキャッシュに影響しない（KVは決定論的）
- バッチ処理では共通プレフィックスを持つリクエストをまとめるとキャッシュ効率が上がる
ローカルLLMでのPrefix Caching
クラウドAPIだけでなく、ローカル実行環境でも利用可能。
llama.cpp:
# --prompt-cacheオプションでキャッシュファイルを指定
./llama-cli -m model.gguf \
--prompt-cache /tmp/system_prompt.cache \
--prompt-cache-all \
-p "システムプロンプト..."
Ollama: 自動的にプレフィックスキャッシュを実施。同じ会話コンテキストを持つ連続リクエストは自動高速化。
vLLM: --enable-prefix-cachingオプションで有効化。複数ユーザーが同じシステムプロンプトを使うサービングシナリオで特に有効。
コスト削減の実例計算
シナリオ: 法律相談チャットボット
- システムプロンプト: 5,000トークン（法律専門知識）
- RAGコンテキスト: 10,000トークン（参照条文）
- 1日1,000会話、各会話5ターン
Prefix Cachingなし（Claude 3.7 Sonnet）:
- 入力: (15,000 + 平均500) × 5,000 = 7,750万トークン
- コスト: 7,750万 × $3/100万 = $232.5/日（約35,000円）
Prefix Caching適用後:
- キャッシュHIT分（90%削減）: 15,000 × 5,000 × 0.1 = 750万トークン相当
- 新規ユーザー入力分: 500 × 5,000 = 250万トークン（削減なし）
- コスト: (750万 × $0.30 + 250万 × $3.00) / 100万 = $9.75/日（約1,460円）
削減効果: 約96%のコスト削減（1ヶ月: 約105万円 → 4.4万円）
適用すべき/すべきでないケース
Prefix Cachingが効果的な場合:
- 大きなシステムプロンプト（1,024トークン以上）を多数リクエストで共有
- RAGで同じドキュメントを繰り返し参照
- マルチターン会話で長い会話履歴が蓄積
- コードアシスタントで同じコードベースを繰り返し参照
Prefix Cachingが効果的でない場合:
- シングルターンの単純な質問回答
- 毎回異なるシステムプロンプトを使用
- プロンプトが1,024トークン未満
- TTL（5分）を超える間隔でリクエストが来る（キャッシュが失効）
よくある質問（FAQ）
Q: キャッシュが古い情報を返すリスクはあるのか？ A: KVキャッシュは計算結果のキャッシュであり、モデルの重みや回答内容は変わらない。キャッシュがヒットしても、ユーザー入力部分は毎回新鮮に処理される。「古い情報」の問題はキャッシュ起因でなくモデルの知識カットオフ起因。
Q: マルチユーザー環境でキャッシュは共有されるのか？ A: Anthropic・OpenAIはアカウントレベルでキャッシュを分離しているため、他ユーザーのキャッシュは参照されない。ただしOpenAIの自動キャッシュは同一組織内で共有される場合がある（セキュリティポリシー要確認）。
Q: ストリーミング応答でもキャッシュは有効か？ A: はい。KVキャッシュはプロンプト処理フェーズのキャッシュであり、出力のストリーミングとは独立している。ストリーミング有効時でもキャッシュの恩恵を受けられる。