LLM キャッシュヒット率（エルエルエム キャッシュヒットリツ）

LLM キャッシュヒット率とは

LLM キャッシュヒット率は、LLM の推論システムに送信されたリクエストのうち、既存のキャッシュ（KV キャッシュ、プレフィックスキャッシュ）を再利用できた割合を示す指標です。キャッシュヒット率が高いほど、計算コストの大きい Prefill フェーズをスキップできるリクエストが多くなり、全体の推論レイテンシとコストが低下します。

計算方法

キャッシュヒット率は以下の 2 つのレベルで測定されます。

リクエストレベルヒット率

全リクエスト中、キャッシュがヒットしたリクエストの割合です。

リクエストヒット率 = キャッシュヒットしたリクエスト数 / 総リクエスト数 × 100%

トークンレベルヒット率

全入力トークン中、キャッシュから再利用されたトークンの割合です。より詳細な効率性を示します。

トークンヒット率 = キャッシュから再利用されたトークン数 / 総入力トークン数 × 100%

典型的なヒット率とコスト効果

実際のアプリケーションにおけるキャッシュヒット率とコスト削減効果は、ユースケースによって大きく異なります。

ヒット率を向上させる設計パターン

プロンプト構造の標準化: システムプロンプトのバージョンを管理し、変更頻度を最小化します。プロンプトのマイナーな修正（改行の追加、スペースの変更等）でもキャッシュミスが発生するため、プロンプトテンプレートは厳密に管理します。

プレフィックスの最大化: 変化しない部分をプロンプトの先頭に集約します。システムプロンプト → Few-shot 例 → ドキュメントコンテキスト → ユーザー入力の順序が最適です。

キャッシュ TTL の最適化: キャッシュの有効期間が短すぎるとヒット率が下がり、長すぎるとメモリ消費が増えます。アプリケーションのリクエスト頻度に合わせて TTL を調整します。高頻度アプリケーション（秒間 10+ リクエスト）では短い TTL（5 分）でも高いヒット率を維持できますが、低頻度アプリケーション（時間に数回）では長い TTL（1 時間以上）が必要です。

リクエストのバッチ化: 複数のユーザーリクエストを短時間に集中させることで、キャッシュが有効な期間内にヒットする確率を高めます。キューイングシステムを導入し、同一プレフィックスのリクエストをバッチ処理する設計が効果的です。

モニタリングと可視化

キャッシュヒット率は推論システムの健全性を示す重要な KPI です。

API レスポンスヘッダ: Anthropic API はレスポンスの usage フィールドに cache_creation_input_tokens と cache_read_input_tokens を返します。OpenAI API は cached_tokens を返します。

推論エンジンのメトリクス: vLLM は Prometheus エンドポイント (/metrics) で vllm:prefix_cache_hit_rate メトリクスを公開しています。Grafana ダッシュボードでリアルタイム監視が可能です。

アラート設計: キャッシュヒット率が想定値を下回った場合（例: 50% 以下）にアラートを発火させます。ヒット率の急激な低下は、プロンプト変更、キャッシュ TTL 切れ、推論ノードの再起動などを示唆します。

FAQ

Q: キャッシュヒット率 100% を目指すべきですか？

必ずしもそうではありません。ヒット率 100% はすべてのリクエストが同一プレフィックスであることを意味し、逆にキャッシュに投入するメモリが過剰な可能性があります。一般的には 70-90% のヒット率が健全な範囲で、残りの 10-30% のミスは新規プレフィックスやキャッシュ更新によるものです。

Q: ヒット率が低い場合、何を確認すべきですか？

まずプロンプト構造を確認します。変化する部分がプロンプトの途中に挿入されていないか、不要な動的要素（タイムスタンプ等）がプレフィックスに含まれていないかをチェックします。次にキャッシュ TTL とリクエスト頻度の関係を確認し、TTL 内にリクエストが発生しているか確認します。

Q: キャッシュヒット率とレイテンシの関係は線形ですか？

おおよそ線形ですが、完全ではありません。キャッシュヒット時はプレフィックスの Prefill がスキップされますが、サフィックス部分の Prefill と Decode フェーズは残るため、ヒット率 100% でもレイテンシはゼロにはなりません。プレフィックスが全入力の 90% を占めるケースでは、ヒット率がレイテンシに直結します。