LLMキャッシュ（エルエルエムキャッシュ）
LLM推論の結果やモデルの中間状態を保存・再利用する技術の総称。完全一致キャッシュ、セマンティックキャッシュ、KVキャッシュ、プロンプトキャッシュなど複数の手法を包含し、推論コスト削減・レイテンシ改善・スループット向上を目的とする。
LLMキャッシュとは
LLMキャッシュは、大規模言語モデルの推論に関連するデータを保存・再利用し、パフォーマンスとコスト効率を改善する技術群の総称である。単一の技術ではなく、キャッシュの対象・粒度・判定方式によって複数の手法に分類される。
LLMの推論はGPUリソースを大量に消費し、GPT-4oクラスのモデルでは1回のリクエストに$0.005〜$0.06のAPI費用と500ms〜5sの応答時間を要する。キャッシュ技術はこれらのボトルネックを軽減する根本的なアプローチとして、プロダクション環境で不可欠な要素となっている。
キャッシュ手法の分類
| 手法 | キャッシュ対象 | 判定方式 | 適用レイヤー | コスト削減率 |
|---|---|---|---|---|
| 完全一致キャッシュ | 最終応答 | 文字列一致 | アプリケーション | 低〜中 |
| セマンティックキャッシュ | 最終応答 | ベクトル類似度 | アプリケーション | 中〜高 |
| KVキャッシュ | Attention KV | トークン列一致 | モデル推論 | 高（prefix共有時） |
| プロンプトキャッシュ | プレフィックス処理結果 | プレフィックス一致 | APIプロバイダ | 中（50%〜90%割引） |
| ディスクキャッシュ | モデル重みのページ | アクセスパターン | インフラ | 起動時間削減 |
各手法は排他的ではなく、複数を組み合わせて使用することが一般的である。例えばAnthropicのAPIではプロンプトキャッシュが自動適用され、アプリケーション層でセマンティックキャッシュを追加することで二重のコスト削減が可能となる。
アプリケーション層キャッシュの実装
アプリケーション開発者が最も直接的に制御できるのが、リクエスト/レスポンスレベルのキャッシュである。
完全一致キャッシュ: 最もシンプルな方式で、リクエストのハッシュ値をキーとしてレスポンスを保存する。Redisやmemcachedで容易に実装できるが、1文字でも異なるとキャッシュミスとなるため、実用上のヒット率は限定的である。
セマンティックキャッシュ: テキスト埋め込みによるベクトル類似検索を用い、意味的に類似したクエリにヒットさせる。GPTCache、LangChain CacheBackedEmbeddings、LiteLLM Cachingなどの実装がある。ヒット率は大幅に向上するが、embedding計算のオーバーヘッドと誤ヒットのリスクが伴う。
ハイブリッドキャッシュ: 完全一致を先に判定し（O(1)）、ミスした場合にセマンティック検索にフォールバックする二段構成。両方の長所を活かし、計算コストを最小化する。
LLMプロバイダのキャッシュ機能
主要LLMプロバイダは独自のキャッシュ機能を提供している。
| プロバイダ | キャッシュ機能 | 割引率 | 最小プレフィックス | 有効期間 |
|---|---|---|---|---|
| Anthropic | Prompt Caching | 入力90%割引 | 1,024トークン | 5分（自動延長） |
| OpenAI | Automatic Caching | 入力50%割引 | 1,024トークン | 最大1時間 |
| Context Caching | 入力75%割引 | 32,768トークン | 設定可能 | |
| DeepSeek | Disk Caching | 入力90%割引 | なし | セッション内 |
Anthropicのプロンプトキャッシュは、同一プレフィックスを含むリクエストの2回目以降で入力トークン費用を90%削減する。RAGパイプラインでシステムプロンプトと検索結果を固定し、ユーザー質問のみを変更する構成で特に効果的である。
キャッシュ設計のベストプラクティス
プロダクション環境でのLLMキャッシュ設計では以下の点を考慮する。
キャッシュキーの設計: モデル名、temperature、max_tokens などのパラメータをキャッシュキーに含める。同じプロンプトでもパラメータが異なれば出力が変わるため、パラメータを無視するとキャッシュ汚染が発生する。
TTL（Time-To-Live）の設定: 時事的なコンテンツを含む可能性がある場合は短いTTL（数時間〜1日）を設定する。FAQのように変化が少ないコンテンツは長いTTL（数日〜数週間）が適切である。
キャッシュ無効化: モデルのアップデートやシステムプロンプトの変更時に、関連するキャッシュを一括無効化する仕組みが必要である。バージョンタグをキャッシュキーに含めることで、自然な無効化を実現できる。
コスト最適化の実例
あるカスタマーサポートチャットボットでの実測値:
- 月間リクエスト数: 100万件
- GPT-4o使用時の月額API費用: 約$30,000
- セマンティックキャッシュ導入後のヒット率: 45%
- キャッシュ導入後の月額API費用: 約$17,000（43%削減）
- embedding計算+ベクトルDB費用: 約$500/月
- 純削減額: 約$12,500/月
ヒット率はドメインのクエリ多様性に大きく依存し、FAQに近い用途では60〜70%、自由記述チャットでは20〜30%が一般的な範囲である。
よくある質問
Q1: LLMキャッシュはストリーミング応答に対応できますか？
対応可能だが実装に工夫が必要である。キャッシュヒット時はストリーミング風にチャンクを分割して返却するか、即座に全文を返す選択がある。GPTCacheはストリーミング応答のキャッシュに対応しており、保存時に全文を結合して格納し、再生時にチャンク分割して返す方式を採用している。
Q2: マルチモーダルLLM（画像+テキスト）のキャッシュは可能ですか？
テキスト部分のセマンティックキャッシュは通常通り適用可能だが、画像を含むクエリの類似判定は複雑である。画像のハッシュ値とテキストembeddingを組み合わせた複合キーを使う方法が一般的である。CLIPなどのマルチモーダルembeddingを使えば画像とテキストを統合したベクトルで類似判定が可能だが、計算コストが増加する。
Q3: キャッシュの導入はどの段階で検討すべきですか？
プロトタイプ段階では不要だが、月間1万リクエストを超えたあたりからコスト効果が出始める。完全一致キャッシュは実装が容易なので早期に導入し、セマンティックキャッシュはクエリパターンの分析結果を見てから導入判断するのが合理的である。プロバイダ提供のプロンプトキャッシュ（Anthropic/OpenAI等）は設定変更のみで利用可能なので即座に有効化すべきである。