LLMキャッシング（エルエルエムキャッシング）
LLM推論の計算結果やレスポンスを保存・再利用することで、応答速度の向上とコスト削減を実現する技術群の総称。プロンプトキャッシュ、KVキャッシュ、セマンティックキャッシュなど複数の階層が存在する。
LLMキャッシングとは
LLMキャッシング（LLM Caching）は、大規模言語モデルの推論プロセスにおける計算結果やAPIレスポンスを保存し、同一または類似のリクエストに対して再計算なしに結果を返す技術群である。LLM推論は計算コストが高く（GPT-4oで$2.50/1M入力トークン、Claude Sonnet 4で$3/1M入力トークン）、レイテンシも数百ミリ秒〜数秒かかるため、キャッシュによるコスト・速度の最適化は本番運用において不可欠である。
キャッシュの階層構造
LLMキャッシングは、適用レベルに応じて複数の階層に分類される。
レベル1: Exactマッチキャッシュ
最もシンプルな方式で、プロンプト文字列の完全一致をキーとして結果をキャッシュする。ハッシュテーブルやRedisなどのKVストアで実装され、ルックアップは O(1) である。同一プロンプトの繰り返しリクエスト（テンプレート型チャットボット、FAQ応答など）で高いヒット率を実現する。
レベル2: セマンティックキャッシュ
プロンプトの意味的類似度に基づいてキャッシュヒットを判定する。入力テキストをEmbeddingモデルでベクトル化し、ベクトルDBに格納された過去のプロンプトとコサイン類似度を比較する。閾値（通常0.95以上）を超えれば同一とみなしてキャッシュ済みレスポンスを返す。GPTCache やLangChain のSemanticCacheがこの方式を採用している。
レベル3: KVキャッシュ（モデル内部）
Transformer推論時のKey-Valueテンソルをメモリに保持し、新しいトークン生成時に過去のアテンション計算を再利用する。モデル内部の最適化であり、APIユーザーからは透過的に動作する。vLLMのPagedAttentionやTensorRT-LLMのインフライトバッチングが代表的な実装である。
レベル4: プロンプトキャッシュ（プロバイダレベル）
Anthropic Prompt Caching やOpenAI Cached Input Tokens など、APIプロバイダが提供するプラットフォームレベルのキャッシュ機構。システムプロンプトや長大なコンテキストの共通プレフィックス部分をサーバー側でキャッシュし、2回目以降の処理コストを大幅に削減する。
主要キャッシュ技術の比較
| 方式 | ヒット条件 | レイテンシ削減 | コスト削減 | 実装難度 |
|---|---|---|---|---|
| Exactマッチ | 文字列完全一致 | 99%+ | 100% | 低 |
| セマンティック | 意味的類似度≥閾値 | 95%+ | 100% | 中 |
| KVキャッシュ | 同一プレフィックス | 40-80% | 0%（推論内部） | 高 |
| プロンプトキャッシュ | 共通プレフィックス | 60-85% | 50-90% | 低 |
実装パターンとツール
GPTCache
オープンソースのセマンティックキャッシュライブラリで、LLM APIの前段にキャッシュレイヤーを追加する。Embeddingモデル（OpenAI Ada、Sentence-BERT等）でプロンプトをベクトル化し、FAISS やMilvusでベクトル検索を行う。ヒット率はドメインとクエリパターンに依存するが、カスタマーサポートボットで50-70%のヒット率を達成した事例がある。
LangChain InMemoryCache / SQLiteCache
LangChain フレームワーク内蔵のキャッシュ機構で、ExactマッチベースのInMemoryCacheとSQLiteCacheを提供する。開発・テスト環境での反復実行コスト削減に特に有効である。
LiteLLM キャッシュ
LiteLLM プロキシサーバーに内蔵されたキャッシュ機能で、Redis・S3・ディスクをバックエンドとして使用できる。複数のLLMプロバイダを統合するゲートウェイでキャッシュを一元管理できる点が特徴である。
キャッシュ無効化戦略
キャッシュの鮮度管理はLLMキャッシングにおいて特に重要である。
- TTL（Time-To-Live）: 一定時間経過後にキャッシュを自動無効化。ニュースや天気などリアルタイム性が求められるドメインでは短いTTL（5-30分）を設定する
- 手動パージ: モデル更新やプロンプト変更時にキャッシュを明示的に削除する。バージョニングキー（model_id + prompt_hash + version）で管理するのが一般的
- LRU/LFU エビクション: メモリ容量制約下でのキャッシュ淘汰。LRU（最も使われていないエントリを破棄）が多くの実装で採用されている
コスト削減の実例
| ユースケース | キャッシュ方式 | ヒット率 | コスト削減率 |
|---|---|---|---|
| FAQチャットボット | Exact + セマンティック | 60-80% | 60-80% |
| コード生成アシスタント | プロンプトキャッシュ | N/A | 50%（共通プレフィックス） |
| RAGパイプライン | KVキャッシュ + Exact | 30-50% | 30-50% |
| バッチ処理 | Exact | 90%+ | 90%+ |
FAQ
セマンティックキャッシュの閾値はどう決めるべきですか？
閾値は精度とヒット率のトレードオフで決定する。0.98以上は安全だがヒット率が低く、0.90以下は誤ヒット（意味が異なるプロンプトに同じ回答を返す）のリスクが高まる。本番環境では0.95前後から始め、誤ヒット率をモニタリングしながら調整するのが推奨される。
キャッシュはtemperature > 0の場合も有効ですか？
temperature > 0 では同じプロンプトに対して異なる出力が生成されるため、厳密には毎回異なる「正解」が存在する。しかし実用上、FAQ応答や情報抽出のように出力の多様性が不要な用途では、キャッシュヒット時にtemperatureを0として扱うことで問題なく運用できる。創造的生成タスクではキャッシュを無効にするか、TTLを短く設定する。
プロンプトキャッシュとセマンティックキャッシュは併用できますか？
併用可能で、多くの本番システムでは多層キャッシュとして実装される。まずExactマッチ（Redis）でO(1)ルックアップ、ミスならセマンティックキャッシュ（ベクトルDB）で意味検索、さらにミスならプロバイダのプロンプトキャッシュが共通プレフィックス部分のコストを削減する。各層のヒット率を独立にモニタリングし、全体のコスト削減効果を測定する。