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