キャッシュ戦略の比較

キャッシングは、LLMワークロードに対して最もレバレッジの高いコスト削減戦術の一つです。考え方は単純です：キャッシュされた結果を返せる場合は、推論に支払わないことです。しかし、「キャッシング」は1つの技術ではなく、コスト削減、レイテンシ、精度、実装の複雑さにおいて異なるトレードオフを持つ4つの異なる戦略です。誤った選択はエンジニアリング労力を無駄にし、正しい選択は請求額を30〜70%削減できます。

戦略比較

戦略	仕組み	コスト削減	レイテンシへの影響	実装の手間	最適な用途	プロバイダー
プロンプトキャッシュ（プロバイダー側）	プロバイダーが繰り返されるプロンプトプレフィックスのKV計算をキャッシュします。同じプレフィックスを持つ後続のリクエストは再処理をスキップします。	キャッシュされた入力トークンで50%	最初のトークンレイテンシが60-80%高速化	ゼロ〜低 - ほとんどのプロバイダーで自動	長いシステムプロンプト、共有コンテキストのRAG、エージェントループ	OpenAI、Anthropic、Google
セマンティックキャッシュ（埋め込みベース）	ユーザークエリを埋め込み、ベクトルストアで類似した過去のクエリを検索します。類似度がしきい値を超えた場合、LLMを呼び出さずにキャッシュされた応答を返します。	クエリの繰り返しに応じて20-50%	50-90%高速化（LLM呼び出しなし）	中 - 埋め込みモデル、ベクトルストア、類似度しきい値の調整が必要	FAQボット、カスタマーサポート、繰り返しのクエリ	任意（GPTCache経由でセルフホスト、ベクトル検索付きRedis）
コンテキストキャッシュ（Googleスタイル）	大きなコンテキストドキュメント（PDF、コードベース）をサーバー側にキャッシュします。コンテキスト処理に一度支払い、多くのクエリで削減されたコストで再利用します。	コンテキストが重いクエリで70-90%	コンテキスト処理の中程度の改善	低〜中 - コンテキストのアップロード、TTL管理	ドキュメントQ&A、大きなリポジトリのコードレビュー、静的コンテキストでのマルチターン	Google（Gemini）、Anthropic（拡張思考コンテキスト）
アプリケーションレベルキャッシュ（Redis/CDN）	リクエスト全体（プロンプト + パラメーター）の決定論的ハッシュ。応答をRedisまたはCDNに保存します。完全一致の場合、キャッシュされた応答を返します。	キャッシュヒット時に最大100%	90-99%高速化（LLM呼び出しなし）	低 - 標準的なキャッシュインフラストラクチャ	決定論的クエリ、分類、固定プロンプトでの抽出	任意（制御するインフラストラクチャ）

プロンプトキャッシュの詳細

プロンプトキャッシュは最も簡単な勝利です。OpenAIは1,024トークンを超えるプロンプトを自動的にキャッシュします。Anthropicは2,048+トークンのプレフィックスをキャッシュします。キャッシュは正確なプレフィックスでキーされます - 同じシステムプロンプト、同じfew-shotサンプル、同じドキュメントコンテキスト。キャッシュヒットが発生すると、入力トークンのキャッシュされた部分に対して50%少なく支払います。

注意点：キャッシュの無効化はプロバイダーが制御します。プロンプトがわずかに変更されても - システムメッセージが異なる、プレフィックス内の変数が異なる - キャッシュはミスします。安定したコンテンツをプロンプトの先頭に配置し、動的コンテンツをプロンプトの末尾にプッシュするよう設計してください。

セマンティックキャッシュの詳細

セマンティックキャッシュは、以前に類似した質問がされた場合、LLMを完全にスキップします。フロー：クエリを埋め込み、ベクトルストア（Pinecone、Qdrant、ベクトル検索付きRedis）を検索、トップ結果が類似度しきい値（通常0.92〜0.97）を超えているかを確認、超えている場合はキャッシュされた回答を返します。

リスクは、古いか slightly 間違った回答を返すことです。しきい値が低すぎると間違った結果が返され、高すぎるとキャッシュヒットがほぼなくなります。ユースケースごとに調整してください。FAQの事実検索では0.95以上が安全です。創造的な生成には、セマンティックキャッシュは rarely 適切です - 新規性がすべてです。

コンテキストキャッシュの詳細

Googleのコンテキストキャッシュでは、大きなドキュメントを1回アップロードし、それに対する後続のクエリに削減された料金を支払うことができます。これは、同じ200ページのPDFを何百回も処理するドキュメントQ&Aに強力です。コストモデル：キャッシュ書き込みに対して入力トークンの完全料金を1回支払い、その後各キャッシュ読み取りに対して削減された料金（通常通常の25%）を支払います。

トレードオフはTTLです。キャッシュされたコンテキストは期限切れになります。ワークロードがバースティなアクセスポターンを持つ場合 - 1時間に500クエリ、その後1週間何もなし - バースト間でキャッシュが期限切れになる可能性があります。アクセスポターンに合わせてTTLをサイズ設定してください。

アプリケーションレベルキャッシュの詳細

決定論的キャッシングは最も積極的な戦略です。リクエストペイロード全体（プロンプト、temperature、最大トークン、モデル、ツール）をハッシュし、応答を保存します。完全一致の場合、キャッシュされた応答を即座に返します - LLM呼び出しなし、レイテンシなし、コストなし。

これは、同じ入力が常に同じ出力を生成する場合にのみ機能します。分類、エンティティ抽出、構造化データ解析、テンプレートベースの生成が良い候補です。会話型や創造的なタスクには適していません - ユーザーは varied 応答を期待します。

戦略の組み合わせ

最良の実装は複数の戦略をレイヤーします。典型的なスタック：アプリケーションレベルキャッシュを最初のチェックとして（最安、最速）、セマンティックキャッシュを2番目のチェックとして（重複を捕捉）、その後LLM呼び出しをプロバイダー側のプロンプトキャッシュ有効で（キャッシュミスでもコスト削減）。この階層型アプローチは、繰り返しの程度があるワークロードでLLM支出を40〜70%削減できます。

各レイヤーのキャッシュヒット率を個別に追跡してください。セマンティックキャッシュのヒット率が10%を下回った場合、ベクトルストアのオーバーヘッドが見合わない可能性があります。アプリケーションキャッシュのヒット率が40%を超えた場合、プロンプトレベルで最適化すべき決定論的タスクがある可能性があります。