プロンプトキャッシング基盤：LLMのコストとレイテンシの削減
2025年12月11日更新
2025年12月アップデート： Anthropicのプレフィックスキャッシングにより、長いプロンプトでコスト90%削減、レイテンシ85%削減を実現。OpenAIの自動キャッシングはデフォルトで有効（50%のコスト削減）。LLMクエリの31%が以前のリクエストと意味的類似性を示しており、キャッシング基盤なしでは膨大な非効率性が発生。キャッシュ読み取りは$0.30/Mトークン、新規処理は$3.00/Mトークン（Anthropic）。マルチティアキャッシングアーキテクチャ（セマンティック→プレフィックス→推論）により節約を最大化。
Anthropicのプロンプトキャッシングは、長いプロンプトでコストを最大90%、レイテンシを最大85%削減します。¹ OpenAIはデフォルトで有効な自動キャッシングにより50%のコスト削減を実現しています。研究によると、LLMクエリの31%が以前のリクエストと意味的類似性を示しており、適切なキャッシング基盤のないデプロイメントでは膨大な非効率性が生じています。² 本番AIアプリケーションを運用する組織は、適切なキャッシング戦略なしでは多額のコストを無駄にしています。
プロンプトキャッシングは複数のレベルで動作します。KVキャッシュの計算を再利用するプロバイダー側のプレフィックスキャッシングから、類似クエリに対して以前の応答を返すアプリケーションレベルのセマンティックキャッシングまで。各レイヤーとその適用タイミングを理解することで、組織は特定のワークロードパターンに対してコストとレイテンシの両方を最適化できます。
キャッシングの基礎
LLM推論コストは2つの要素から発生します：入力トークンの処理と出力トークンの生成。キャッシング戦略は両方をターゲットにします：
入力トークンキャッシング（プレフィックスキャッシング）
すべてのLLMリクエストは、モデルのアテンションメカニズムを通じて入力トークンを処理し、KVキャッシュに格納されるキーバリューペアを生成します。複数のリクエストが同一のプレフィックス（システムプロンプト、Few-shotの例、ドキュメントコンテキスト）を共有する場合、KVキャッシュの計算が不必要に繰り返されます。
プレフィックスキャッシングの解決策： 一般的なプレフィックスの計算済みKV値を保存。一致するプレフィックスを持つ後続のリクエストは再計算をスキップし、キャッシュされた状態から開始します。
コストへの影響： - Anthropic：キャッシュ読み取りは$0.30/Mトークン、新規処理は$3.00/M（90%削減） - OpenAI：キャッシュされたトークンは50%割引 - Google：コンテキストウィンドウに基づく変動価格
レイテンシへの影響： プレフィックス計算のスキップにより、最初のトークンまでの時間がプレフィックスの長さに応じて50〜85%短縮されます。
出力キャッシング（セマンティックキャッシング）
一部のリクエストは同一の応答に値します—繰り返しの質問、決定論的なクエリ、再生成を必要としないルックアップなど。
セマンティックキャッシングの解決策： 意味的に類似した入力をキーとして応答出力を保存。一致するクエリに対してLLM呼び出しなしでキャッシュされた応答を返します。
コストへの影響： キャッシュされた応答はAPI呼び出しを完全に排除—キャッシュヒット時100%の節約。
レイテンシへの影響： 応答はLLM推論の数秒ではなくミリ秒で返されます。
キャッシング階層
本番システムは通常、複数のキャッシングレイヤーを実装します：
リクエスト → セマンティックキャッシュ（100%節約） → プレフィックスキャッシュ（50-90%節約） → フル推論
↓ ↓ ↓
キャッシュ応答 キャッシュKV状態 新規計算
各レイヤーは、リクエストの類似性パターンに基づいて異なる最適化機会を捕捉します。
プロバイダーレベルのプロンプトキャッシング
Anthropic Claude
Anthropicは最も設定可能なプロンプトキャッシングを提供しています：³
価格設定： - キャッシュ書き込み：基本入力価格の25%プレミアム - キャッシュ読み取り：90%割引（基本価格の10%） - 損益分岐点：キャッシュされたプレフィックスあたり2回以上のキャッシュヒット
要件： - キャッシュチェックポイントあたり最小1,024トークン - リクエストあたり最大4つのキャッシュチェックポイント - キャッシュ有効期間：最後のアクセスから5分（定期的なヒットで1時間に延長） - 最大5つの会話ターンがキャッシュ可能
実装：
import anthropic
client = anthropic.Anthropic()
# cache_controlでキャッシング対象のコンテンツをマーク
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are an expert assistant for our enterprise software...",
"cache_control": {"type": "ephemeral"} # キャッシング対象としてマーク
}
],
messages=[{"role": "user", "content": "How do I configure user permissions?"}]
)
ベストプラクティス： - 静的コンテンツ（システムプロンプト、ドキュメント）をプロンプトの先頭に配置 - 動的コンテンツ（ユーザー入力、会話）を末尾に配置 - 自然な境界でキャッシュチェックポイントを使用 - キャッシュヒット率を監視して最適化を検証
OpenAI
OpenAIはコード変更なしで自動キャッシングを実装しています：⁴
価格設定： - キャッシュされたトークン：基本入力価格の50% - キャッシュ書き込みプレミアムなし
要件： - キャッシング対象となるには最小1,024トークン - キャッシュヒットは128トークン単位で発生 - キャッシュ有効期間：非アクティブ状態5〜10分
自動動作： - 1,024トークンを超えるプロンプトは自動的にキャッシュ - システムがリクエスト間で一致するプレフィックスを検出 - API変更は不要
監視：
response = client.chat.completions.create(
model="gpt-4-turbo",
messages=[...],
)
# キャッシュヒットの使用状況を確認
print(f"Cached tokens: {response.usage.prompt_tokens_details.cached_tokens}")
print(f"Total input tokens: {response.usage.prompt_tokens}")
Google Gemini
GoogleはGeminiモデル向けにコンテキストキャッシングを提供しています：⁵
価格設定： - キャッシュされたコンテキストのサイズと期間に基づく変動 - キャッシュコンテンツのストレージ料金
機能： - 明示的なキャッシュの作成と管理 - 設定可能なTTL（有効期限） - リクエスト間のキャッシュ共有
実装：
from google.generativeai import caching
# キャッシュコンテンツを作成
cache = caching.CachedContent.create(
model='models/gemini-1.5-pro-001',
display_name='product-documentation',
system_instruction="You are a product expert...",
contents=[product_docs],
ttl=datetime.timedelta(hours=1)
)
# リクエストでキャッシュコンテンツを使用
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("How do I configure feature X?")
Amazon Bedrock
AWSはサポートされているモデル向けにプロンプトキャッシングをプレビューで提供しています：⁶
要件： - Claude 3.5 Sonnetはチェックポイントあたり最小1,024トークンが必要 - 2番目のチェックポイントには2,048トークンが必要
実装パターンはBedrock APIの構造内でAnthropicのcache_controlアプローチと一致します。
vLLMプレフィックスキャッシング
vLLMでのセルフホスト推論には自動プレフィックスキャッシングが含まれています：⁷
アーキテクチャ
vLLMの自動プレフィックスキャッシング（APC）はKVブロックをハッシュテーブルに格納し、ツリー構造なしでキャッシュの再利用を可能にします：
主要な設計： - すべてのKVブロックは初期化時にブロックプールに格納 - プレフィックスマッチングのためのハッシュベースのルックアップ - ブロック管理のO(1)操作 - PagedAttentionのメモリ効率を維持
設定
from vllm import LLM
llm = LLM(
model="meta-llama/Llama-3.1-8B-Instruct",
enable_prefix_caching=True, # APCを有効化
gpu_memory_utilization=0.90,
)
パフォーマンスへの影響
PagedAttentionを備えたvLLMは、ナイーブな実装と比較して14〜24倍高いスループットを示します。⁸ プレフィックスキャッシングは以下を追加：
- キャッシュされたトークンとキャッシュされていないトークン間で10倍のコスト差
- 一致するプレフィックスに対して桁違いのレイテンシ削減
- 共有KVブロックによるメモリ効率
セキュリティの考慮事項
vLLMは共有環境でのキャッシュ分離をサポートしています：
# リクエストごとのキャッシュソルトでテナント間のキャッシュアクセスを防止
response = llm.generate(
prompt="...",
sampling_params=SamplingParams(...),
cache_salt="tenant-123" # テナントごとにキャッシュを分離
)
ブロックハッシュへのキャッシュソルト注入により、攻撃者がレイテンシ観察を通じてキャッシュされたコンテンツを推測するタイミング攻撃を防止します。
LMCache拡張
LMCacheは高度なキャッシング機能でvLLMを拡張します：⁹
機能： - エンジンインスタンス間でのKVキャッシュ再利用 - マルチティアストレージ（GPU → CPU RAM → ディスク） - 非プレフィックスコンテンツのキャッシング - ベンチマークで3〜10倍のレイテンシ削減
アーキテクチャ：
vLLM Engine → LMCache → GPU VRAM (ホット)
→ CPU RAM (ウォーム)
→ ローカルディスク (コールド)
セマンティックキャッシング
セマンティックキャッシングは、意味的に類似した（同一だけでなく）クエリに対して以前の応答を返します：
GPTCache
GPTCacheはLLMアプリケーション向けのオープンソースセマンティックキャッシングを提供します：¹⁰
アーキテクチャ：
クエリ → 埋め込み → ベクトル検索 → 類似性チェック → 応答/API呼び出し
↓ ↓ ↓
BERT/OpenAI Milvus/FAISS しきい値 (0.8)
コンポーネント： - LLMアダプター： 様々なLLMプロバイダーとの統合 - 埋め込みジェネレーター： クエリのベクトル化 - ベクトルストア： 類似性検索（Milvus、FAISS、Zilliz） - キャッシュマネージャー： 保存と取得 - 類似性評価器： しきい値ベースのマッチング
実装：
from gptcache import cache
from gptcache.adapter import openai
# セマンティックキャッシュを初期化
cache.init(
pre_embedding_func=get_text_embedding,
data_manager=manager,
)
# キャッシュされたOpenAI呼び出しを使用
response = openai.ChatCompletion.create(
model='gpt-4',
messages=[{"role": "user", "content": "What is machine learning?"}]
)
# 意味的に類似したクエリ（"Explain ML"、"Define machine learning"）は
# キャッシュされた応答を返す
パフォーマンス
GPTCacheは大幅な効率向上を実現します：¹¹
- API呼び出し削減： クエリカテゴリ全体で最大68.8%
- キャッシュヒット率： 61.6%〜68.8%
- 精度： 97%以上の正のヒット率
- レイテンシ削減： キャッシュヒット時40〜50%、完全ヒット時最大100倍
高度なテクニック
VectorQ適応しきい値：¹²
静的な類似性しきい値（例：0.8）は多様なクエリに対してパフォーマンスが低下します。VectorQは、クエリの複雑さに適応する埋め込み固有のしきい値領域を学習します：
- 単純な事実クエリ：高いしきい値（厳密なマッチング）
- オープンエンドのクエリ：低いしきい値（より多くの再利用）
- 曖昧なクエリ：動的調整
SCALMパターン検出：
SCALMはパターン検出と頻度分析によりGPTCacheを改善します： - キャッシュヒット率63%向上 - トークン使用量77%削減 - 高頻度のキャッシュエントリパターンを識別
セマンティックキャッシングを使用するタイミング
適した候補： - 限定的な回答空間を持つFAQスタイルのクエリ - ルックアップクエリ（製品情報、ドキュメント） - 決定論的な応答（計算、フォーマット） - クエリの繰り返しが多い高トラフィックアプリケーション
不向きな候補： - 一意性が必要なクリエイティブな生成 - パーソナライズされた応答（ユーザー固有のコンテキスト） - 時間に敏感な情報 - 低い繰り返しのクエリパターン
実装パターン
チャットアプリケーション
チャットシステムはプレフィックスキャッシングとセマンティックキャッシングの両方から恩恵を受けます：
システムプロンプトキャッシング：
# 静的システムプロンプトはリクエストの先頭でキャッシュ
system_prompt = """
You are a customer support agent for Acme Corp...
[2000+トークンのガイドラインと知識]
"""
# 動的な会話はキャッシュされたプレフィックスの後に追加
messages = [
{"role": "system", "content": system_prompt, "cache_control": {...}},
{"role": "user", "content": user_message}
]
会話履歴キャッシング： Anthropicは最大5つの会話ターンのキャッシングをサポートし、複数ターンの会話のコストを削減します。
RAGアプリケーション
検索拡張生成（RAG）は取得されたコンテキストをキャッシュします：
# RAG用のキャッシュ構造
cached_context = {
"system": system_prompt, # 常にキャッシュ
"documents": retrieved_chunks, # クエリクラスタごとにキャッシュ
"examples": few_shot_examples # リクエスト間で安定
}
# ユーザークエリのみが変化
dynamic_content = {
"query": user_question
}
ドキュメントチャンクキャッシング： 複数のクエリが同じドキュメントを取得する場合、プレフィックスキャッシングにより共有コンテキストの冗長な処理が排除されます。
エージェントワークフロー
ツール呼び出しを伴うエージェントシステムはプレフィックスキャッシングから恩恵を受けます：
システムプロンプト → ツール定義 → 会話履歴 → 現在のクエリ
(キャッシュ) (キャッシュ) (部分的にキャッシュ)
[翻訳のためコンテンツを省略]
