LLMを使ったアプリケーションが複雑になると、推論コストと応答遅延は深刻な問題になります。1回のリクエストにシステムプロンプト、会話履歴、取得ドキュメント、ツール定義、ユーザー入力が含まれ、トークン数は数千から数百万に及ぶこともあります。同じ内容を毎回ゼロから計算するのは、時間と計算資源の無駄です。LLMサービスにおけるキャッシュは単一の手法ではなく、サービスの各層で役割が異なります。ここでは4つのキャッシュ、KVキャッシュ、プレフィックスキャッシュ、プロンプトキャッシュ、セマンティックキャッシュを整理します。
まずKVキャッシュです。自回帰モデルは回答を一括生成せず、1トークンずつ生成します。新しいトークンを生成するたびに、attention機構はそれまでの全トークンとの関係を計算し、各トークンのK（Key）とV（Value）テンソルを生成します。KVキャッシュはこのK/V状態を保存し、デコードのたびに過去を再計算しない仕組みです。通常はGPUメモリ上に保持されます。prefillでプロンプトを処理したあと、キャッシュ状態を再利用しながら新しいトークンだけを追加できます。ただし、従来のKVキャッシュは基本的に現在のリクエストに紐づいており、リクエスト完了後に別のリクエストへ自動的に流用できるわけではありません。
プレフィックスキャッシュはKVキャッシュの考え方を別リクエストへ広げます。システムプロンプトやツール定義など共有される前置きが長いアプリケーションでは、2つのリクエストの冒頭が一致することがよくあります。キャッシュがなければ同じプレフィックスを再計算しますが、プレフィックスキャッシュは既に計算済みのKVブロックを再利用します。この方式では、プロンプトを固定サイズのトークンブロックに分割し、ブロックの内容と位置からハッシュを求めます。新しいリクエストではハッシュを使ってCACHE HITを判定し、ヒットしたブロックはモデル計算を経ずにKV状態を再利用し、ミスした部分だけを計算します。キャッシュが満杯になると、LRU方式で古いブロックから追い出されます。また、テキストが同じでも画像が異なるマルチモーダル入力では単純に再利用できない点に注意が必要です。vLLMではブロック単位の管理、ハッシュ、探索、追い出しを備えたプレフィックスキャッシュが実装されています。
プロンプトキャッシュは、モデルを自前でホストせずAPI経由で使う場合に重要です。アプリケーションは毎回ほぼ同じ巨大なシステムプロンプトを送信し、末尾のユーザークエリだけが変わることがあります。APIプロバイダはこの反復部分を自社インフラでキャッシュし、後続のリクエストで再処理を省けます。料金はプロバイダによって異なり、キャッシュヒットは通常の0.1倍程度に、キャッシュ書き込みは1.25倍などに設定されているケースが一般的です。自動でキャッシュされるプロバイダもあれば、別途ストレージ費用がかかるプロバイダもあります。これにより、大きな固定コンテキストを持つアプリの入力コストとレイテンシを抑えられます。
最後に、セマンティックキャッシュです。これはLLMを呼び出す必要がない場合に使います。新しい質問が過去の質問と意味的に類似していれば、モデルを起動せず、保存済みの回答をそのまま返します。通常はテキスト厳密一致ではなく、埋め込みベクトルによる類似度で判定します。モデル推論を完全にスキップするため、待ち時間とコストを最小限に抑えることができます。一方で、類似度のしきい値や回答の鮮度を管理しなければ、不適切な回答を返すリスクがあります。
この4つは相互に排他的ではなく、サービスアーキテクチャの異なる場所で共存できます。KVキャッシュは生成の高速化、プレフィックスキャッシュはprefillの削減、プロンプトキャッシュはプロバイダ層での固定コンテキスト削減、セマンティックキャッシュは推論そのものの回避を担います。コストとレイテンシを最適化するには、各キャッシュがどこで何を再利用するのかを押さえることが大切です。