LLM の推論リクエストにおいて、KV キャッシュやプレフィックスキャッシュが再利用された割合。ヒット率が高いほど Prefill 処理がスキップされ、レイテンシとコストが削減される。
LLM キャッシュヒット率は、LLM の推論システムに送信されたリクエストのうち、既存のキャッシュ（KV キャッシュ、プレフィックスキャッシュ）を再利用できた割合を示す指標です。キャッシュヒット率が高いほど、計算コストの大きい Prefill フェーズをスキップできるリクエストが多くなり、全体の推論レイテンシとコストが低下します。
キャッシュヒット率は以下の 2 つのレベルで測定されます。
全リクエスト中、キャッシュがヒットしたリクエストの割合です。
リクエストヒット率 = キャッシュヒットしたリクエスト数 / 総リクエスト数 × 100%
全入力トークン中、キャッシュから再利用されたトークンの割合です。より詳細な効率性を示します。
トークンヒット率 = キャッシュから再利用されたトークン数 / 総入力トークン数 × 100%
| 指標 | 計算対象 | 用途 |
|---|---|---|
| リクエストヒット率 | リクエスト単位 | 全体的なキャッシュ効果の概観 |
| トークンヒット率 | トークン単位 | コスト削減効果の正確な算出 |
| コスト削減率 | 料金単位 | ROI の計算 |
実際のアプリケーションにおけるキャッシュヒット率とコスト削減効果は、ユースケースによって大きく異なります。
| ユースケース | 典型的なヒット率 | コスト削減 | 理由 |
|---|---|---|---|
| チャットボット（単一プロンプト） | 85-95% | 70-90% | 全リクエストで同一システムプロンプト |
| RAG（固定ドキュメント） | 60-80% | 40-70% | ドキュメントの再利用頻度に依存 |
| RAG（動的ドキュメント） | 20-40% | 10-30% | クエリごとにドキュメントが変化 |
| コード補完 | 70-90% | 50-80% | ファイルコンテキストが安定 |
| バッチ翻訳 | 90-98% | 80-95% | 同一 Few-shot 例を全文で共有 |
プロンプト構造の標準化: システムプロンプトのバージョンを管理し、変更頻度を最小化します。プロンプトのマイナーな修正（改行の追加、スペースの変更等）でもキャッシュミスが発生するため、プロンプトテンプレートは厳密に管理します。
プレフィックスの最大化: 変化しない部分をプロンプトの先頭に集約します。システムプロンプト → 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 切れ、推論ノードの再起動などを示唆します。
必ずしもそうではありません。ヒット率 100% はすべてのリクエストが同一プレフィックスであることを意味し、逆にキャッシュに投入するメモリが過剰な可能性があります。一般的には 70-90% のヒット率が健全な範囲で、残りの 10-30% のミスは新規プレフィックスやキャッシュ更新によるものです。
まずプロンプト構造を確認します。変化する部分がプロンプトの途中に挿入されていないか、不要な動的要素（タイムスタンプ等）がプレフィックスに含まれていないかをチェックします。次にキャッシュ TTL とリクエスト頻度の関係を確認し、TTL 内にリクエストが発生しているか確認します。
おおよそ線形ですが、完全ではありません。キャッシュヒット時はプレフィックスの Prefill がスキップされますが、サフィックス部分の Prefill と Decode フェーズは残るため、ヒット率 100% でもレイテンシはゼロにはなりません。プレフィックスが全入力の 90% を占めるケースでは、ヒット率がレイテンシに直結します。