キャッシュTTL（LLM推論）（キャッシュティーティーエル）
LLMのプロンプトキャッシュやKVキャッシュが有効に保持される期間（Time To Live）。TTL経過後はキャッシュが破棄され、次回リクエスト時に再計算が必要となる。
キャッシュTTL（LLM推論）とは
TTL（Time To Live）は、キャッシュされたデータが有効である期間を定義するパラメータである。LLM推論の文脈では、KVキャッシュやプレフィックスキャッシュが保持される時間を指す。TTLが短すぎるとキャッシュミスが頻発してコスト削減効果が薄れ、長すぎるとGPUメモリを圧迫して他のリクエスト処理に影響する。
商用LLM APIでは、プロバイダーがTTLを管理する。Anthropic Claudeのプロンプトキャッシュは約5分のTTL、OpenAI GPT-4oは5〜10分、Google Geminiの明示的キャッシュは1時間からユーザー指定可能である。自前でLLMを運用する場合は、推論フレームワーク（vLLM、SGLang等）のキャッシュ設定でTTLを制御する。
TTL設計の基本原則
メモリ予算とTTLのトレードオフ
KVキャッシュはGPUメモリ（VRAM）上に保持される。キャッシュエントリが増えるほど新規リクエストの処理に使えるメモリが減少し、最悪の場合OOM（Out of Memory）エラーが発生する。
| シナリオ | 推奨TTL | 理由 |
|---|---|---|
| チャットbot（高頻度） | 3〜10分 | ユーザーが会話を続ける間だけ保持 |
| バッチ処理 | 30秒〜2分 | 同一バッチ内の共有プレフィックスのみ |
| RAG文書QA | 10〜30分 | 同一文書への複数質問を想定 |
| コード補完 | 1〜5分 | ファイルコンテキストの再利用 |
| ワンショット翻訳 | TTLなし（即時破棄） | 再利用見込みが低い |
アクセスパターンによる動的TTL
全キャッシュエントリに同一TTLを適用するのではなく、アクセス頻度に応じて動的にTTLを調整する手法がある。
- LRU（Least Recently Used）: 最後にアクセスされてからの経過時間でEviction優先度を決定。最もシンプルで広く実装されている
- LFU（Least Frequently Used）: アクセス頻度が低いエントリを優先的に破棄。人気のあるシステムプロンプトのキャッシュが長期保持される
- ARC（Adaptive Replacement Cache）: LRUとLFUを適応的に組み合わせる。ワークロードの変動に強い
APIプロバイダー別のTTL仕様
Anthropic Claude
Claudeのプロンプトキャッシュは約5分のTTLを持つ。キャッシュにヒットするたびにTTLが5分間リフレッシュされるため、継続的にリクエストを送り続ける限りキャッシュは失効しない。これは会話型アプリケーションに最適化された設計である。
キャッシュの書き込みには入力トークン料金の25%が追加課金されるが、キャッシュ読み取りは通常料金の10%で済む。5分以内に同一プレフィックスへのリクエストが4回以上あれば、キャッシュ書き込みコストを回収できる損益分岐点となる。
OpenAI GPT-4o
自動プレフィックスキャッシュは5〜10分のTTLで動作し、開発者による明示的な制御はできない。オフピーク時にはTTLが延長される場合がある。料金はキャッシュヒット時に入力トークン50%割引。
Google Gemini
Context Caching APIでは開発者がTTLを明示的に指定できる（最小1分、デフォルト1時間）。長時間のTTLはキャッシュストレージ料金（1時間あたり$1/100万トークン）が発生するが、大量の参照文書を使うアプリケーションではファインチューニングより安価になる場合がある。
セルフホスト環境でのTTL制御
vLLMの設定
vLLMでは --block-manager と --swap-space パラメータでKVキャッシュの管理方針を設定する。プレフィックスキャッシュは --enable-prefix-caching フラグで有効化し、メモリ圧迫時にはLRUでEvictionされる。明示的なTTL設定はなく、メモリベースの管理となる。
SGLangの設定
SGLangのRadixAttentionはRadix Tree上でキャッシュを管理し、LRU方式でEvictionする。--mem-fraction-static パラメータでKVキャッシュに割り当てるGPUメモリの割合を指定できる（デフォルト0.88 = 88%）。
FAQ
Q1: TTLを長くすればするほどコスト効率は良くなりますか？
一概にそうとは言えない。TTLを長くするとキャッシュヒット率は向上するが、GPUメモリを占有するためバッチサイズ（同時処理リクエスト数）が減少する。スループットとキャッシュヒット率のバランスが最適な点がコスト効率の最大値となる。実測による調整が必要。
Q2: キャッシュのウォームアップは必要ですか？
高トラフィックなアプリケーションでは、デプロイ直後にダミーリクエストを送ってキャッシュをウォームアップする手法が有効。特にシステムプロンプトが大きい場合、最初のリクエストのレイテンシが後続と大きく異なるコールドスタート問題を緩和できる。
Q3: 異なるモデル間でキャッシュは共有できますか？
基本的に共有できない。KVキャッシュはモデルのアーキテクチャ（レイヤー数、ヘッド数、次元数）に依存するため、異なるモデル間での互換性はない。同一モデルの異なるバージョン（例: GPT-4o-2024-05-13とGPT-4o-2024-08-06）間でも共有されない場合がある。