プロンプトキャッシュはなぜ安い？KVキャッシュの仕組みとメモリ管理

プロンプトキャッシュで入力料金が安くなるのは、モデルがすでに済ませた処理を再利用できるからです。KVキャッシュ（KV cache）は、アテンションに使うキーとバリューという2組のデータを保持します。そのため、大規模言語モデルは過去のトークンの状態を毎回作り直さずに会話を続けられます。同じコンテキストを繰り返し処理するコストは下がりますが、会話が長くなればメモリの使用量は増え、新しいトークンが参照するコンテキストも多くなります。

再利用できるプレフィックスを保ち、履歴をどこまで残すかを管理する。 この2つは別の課題です。プレフィックスとは、リクエストの先頭から続く、内容の変わらない部分を指します。そこをキャッシュすれば入力処理を減らせますが、エージェントの残りの処理までなくなるわけではありません。

以下の各社の料金とキャッシュ仕様は、2026年10月15日に各社の公開料金ページとドキュメントで確認したものです。メモリ使用量の計算は、公開されているテンソルの形状から導いたものであり、特定のGPUでの実測値ではありません。

KVキャッシュとは？同じプロンプトの処理を再利用する仕組み

KVキャッシュとは、アテンションの計算で得た状態を保存したものです。 アテンションは、Transformerが過去の関連情報を現在の予測に取り込む仕組みです。テキストなどのモデル入力を構成する単位であるトークンは、各アテンション層の内部で数値表現に変換されます。キャッシュには、その層のキーとバリューが後から使えるように保持されます。この層ごとの保存については、Hugging Faceのキャッシュ解説で説明されています。

アテンションに登場する3つの役割は、資料を調べる図書館にたとえると理解しやすくなります。

• クエリは、現在の位置で何を探しているかを表します。
• キーは、過去の位置を照合できるようにします。
• バリューは、照合で見つかった位置から取り出す情報を提供します。

レポートを書く前に、調査メモを整理して索引を付けておく場面を考えてみてください。新しい文を書くたびに、用意したメモを参照できます。文を書くたびに索引もメモも作り直すのは無駄ですが、保存しておくには場所が必要です。ただし、実装までこのたとえが当てはまるわけではありません。モデルが保持するのは数値の配列であり、人が読める索引カードや文書の要約ではありません。

現在のクエリを過去のキーと比較し、そこから得たアテンションの重みでバリューを組み合わせます。因果的なTransformerでは、過去の位置から未来の位置は参照できません。そのため、後ろにトークンを追加しても、すでに計算した過去の位置の状態を変更する必要はありません。これが再利用できる理由です。PagedAttentionの原論文では、こうしたアテンションの計算と生成の流れが説明されています。

通常のキャッシュが過去のクエリをすべて保存せず、KとVを保存する理由もここにあります。次の予測に必要なのは、現在のクエリと蓄積されたキー、バリューです。過去のクエリは、すでに役割を終えています。

サポートエージェントであれば、保持される状態には、指示、ツール定義、ポリシー文書、それまでの会話が反映されます。この状態は、モデルとそれまでのコンテキストに依存します。モデルが学習した重みでも、顧客情報を永続的に記憶するデータベースでもありません。

プレフィックスのキャッシュと、回答のキャッシュも別物です。 モデルは、その都度新しい続きを生成します。同じ文書について別の質問をする場合、以前の回答を返すのではなく、文書を処理して得た状態を再利用できます。

プリフィルとデコードは何が違う？KVキャッシュが効く場面

プリフィルは入力の準備、デコードはそこから続きを生成する処理です。 この違いを押さえると、キャッシュにヒットして応答が始まるまでの時間が短くなっても、完了までは時間がかかる理由がわかります。

一般的な自己回帰型Transformerの流れを、言葉で図解すると次のようになります。

**プリフィル：**プロンプトのトークン → プロンプトを処理 → 各層のキーとバリューを保持 → 最初の出力トークンを予測。

**デコード：**直前に生成したトークン＋保持済みのキーとバリュー → そのトークンを処理し、コンテキストを参照 → 次のトークンを予測し、新たに計算したキーとバリューを追加。

**デコードを反復：**生成が終わるまで、大きくなっていくキャッシュを再利用。

プリフィルでは、内容がすでにわかっているプロンプト内の各位置をまとめて処理できます。一方、デコードで生成する続きは、後のトークンがまだ決まっていません。この違いは、PagedAttentionの論文にある生成・実行フローでも説明されています。

KVキャッシュを使うと、プレフィックス全体を計算し直す場合と比べて、次のトークンの処理コストが下がります。ただし、コンテキスト長の影響がなくなるわけではありません。通常のフルアテンションでは、新しいクエリは保持済みのキーとバリューを参照します。コンテキストを多く残すほど、処理対象となるアテンションのデータも増えます。Hugging Faceは、各ステップに残るこの処理を解説しています。

ここで、再利用を2種類に分けて考えます。応答の生成中に使うKVキャッシュは、生成の途中で同じ計算を繰り返すのを防ぎます。リクエストをまたぐプレフィックスキャッシュは、ホステッドAPIではプロンプトキャッシュ（プロンプトキャッシング）とも呼ばれ、条件を満たす状態を保持して、後の呼び出しでプリフィルの一部を省略します。会話IDがあるだけで、その状態を再利用できるとは限りません。

たとえば、エージェントがポリシー文書を読み、ツールを呼び出した後、その結果をどう扱うかモデルに判断させるとします。次のリクエストでは、それまでの指示と文書を共通のプレフィックスとして保ち、その後ろにツールの結果を追加できます。キャッシュが利用条件を満たし、実際に利用できる状態なら、プロバイダーはこの共通部分をもう一度処理する必要がありません。

APIを使って開発するなら、最初のトークンが返るまでの待ち時間と、応答の生成にかかる時間をそれぞれ確認しましょう。最初のトークンが早く返っても、デコードまで速くなったとは限りません。vLLMのAutomatic Prefix Cachingのドキュメントでも、プリフィルの削減効果とデコード時間は明確に区別されています。

プロンプトキャッシュで入力料金が下がる仕組み

割引の対象は、各プロバイダーの課金ルールに沿って再利用された入力処理です。 割引率は共通ではなく、ヒットしたリクエストの全トークンが割引になるわけでもありません。

通常の入力、キャッシュへの書き込み、キャッシュからの読み取りを区別するAPIでは、入力分の料金は次のように表せます。

入力料金 = (U × p_input + W × p_write + R × p_read) / 1,000,000

Uは通常の入力トークン数、Wはキャッシュ書き込みとして課金されるトークン数、Rはキャッシュ読み取りとして課金されるトークン数です。各pは、その区分の100万トークンあたりの単価を表します。区分は重複させません。書き込みとして数えたトークンに、通常の入力料金を重ねて課金しないようにします。この式は、OpenAIとAnthropicの料金区分を、単位がそろう形で式にしたものです。

その後に、出力料金、該当するツール料金、別途課金されるキャッシュ保存料金を加えます。Googleの明示的キャッシュには保持時間による料金もあるため、書き込みと読み取りだけの式では足りません。以下は課金ルールの例であり、モデルの優劣を示すものではありません。

Anthropic：再利用するプレフィックスの終端を指定する

Anthropicでは、cache_controlでプロンプトキャッシュを指定します。 リクエストのトップレベルに設定してブレークポイントの管理を自動化する方法と、個々のコンテンツブロックに設定する方法があります。ブレークポイントは、保持するプレフィックスの終端を示します。両方の方法が料金ドキュメントで説明されています。

料金例：標準のClaude API。 Claude Sonnet 5.5は、入力が**$2**、キャッシュ読み取りが**$0.10**、保持期間5分の書き込みが**$2.50**、保持期間1時間の書き込みが**$4**です。いずれも100万トークンあたりの米ドル料金です。Anthropicの料金。

このモデルでキャッシュできるプレフィックスの最小長は512トークンです。キャッシュ境界までの内容が完全に一致する必要があります。読み取り時には、再度の書き込み料金なしで保持期間が更新されます。ただし、起算点はリクエスト開始時なので、応答を生成している間にも保持期間は消費されます。ほかのClaudeモデルでは、最小長や読み取りの割引率が異なります。Anthropicのプロンプトキャッシュ仕様。

人の操作を長く待ってから再開する文書エージェントでは、保持期間によって、次の呼び出しが既存のプレフィックスを読み取れるか、書き直すことになるかが決まります。使用量のcache_creation_input_tokensとcache_read_input_tokensを確認してください。同じ文書を再送したというだけでは、割引対象の読み取りが発生した証拠にはなりません。使用量フィールド。

OpenAI：モデルごとの書き込みルールを確認する

OpenAIでは、対応モデルでプロンプトキャッシュが標準で有効になっています。 新しいモデルは暗黙的・明示的の両方のブレークポイントに対応していますが、挙動はモデルによって異なります。OpenAIのプロンプトキャッシュ。

料金例：Standardの短いコンテキスト向け料金区分。 GPT-6.1 Solは、100万トークンあたり入力が**$2.00**、キャッシュ済み入力が**$0.10**、キャッシュ書き込みが**$2.50です。入力が272Kトークン**を超えると、そのリクエスト全体の入力とキャッシュの単価が2倍になります。OpenAIの料金、モデルのしきい値。

GPT-5.6以降では、可視入力トークンの最小数は1,024で、ドキュメント上のキャッシュ保持期間は、最後の書き込みまたは再利用から少なくとも30分です。キャッシュ書き込みの対象トークンには、通常の入力単価に代えて書き込み単価が適用されます。入力料金全体に同じ料金を上乗せするわけではありません。それ以前のモデルでは、書き込みと保持のルールが異なります。現行のキャッシュ仕様。

Responses APIでは、usage.input_tokens_details.cached_tokensとcache_write_tokensを確認します。セッションを維持しても、ヒットが保証されるわけではありません。リクエストの構成や返された使用量を調べる際は、当サイトのGPT-6プロンプトキャッシュ診断ガイドも参照してください。

Google Gemini：自動的な再利用と明示的な保存を区別する

GoogleのGeminiは、暗黙的キャッシュを自動で利用し、ヒットすると料金の削減分が反映されます。 Gemini 3.8 Flashを例にすると、ドキュメントに記載された最小入力長は4,096トークンです。共通の内容を先頭に置き、間隔を空けずにリクエストを送ると、再利用される可能性が高まります。Googleのコンテキストキャッシュガイド。

料金例：有料のStandard Gemini Developer API。 Gemini 3.8 Flashは、100万トークンあたり入力が**$0.75**、キャッシュ済み入力が**$0.075です。明示的キャッシュの保存料金は、100万トークン・1時間あたり$0.50です。これらは2026年12月31日**までの料金です。Googleの料金。

明示的キャッシュでは、有効期限を設定した名前付きのキャッシュ済みコンテンツリソースを作り、後続のgenerateContentリクエストから参照します。保存料金がかかるため、使っていない文書を保持しているだけでも費用が発生する場合があります。GoogleのキャッシュAPIリファレンス。

どのAPIを使うかも重要です。Interactions APIが対応するのは暗黙的キャッシュのみです。 また、Googleの現行ガイドでは、Gemini 4 Argon以降は明示的キャッシュの対象外とされています。対応するGemini 3および2.5モデルでは、明示的キャッシュにgenerateContentを使います。Interactions APIでは、ガイドにあるとおりusage.total_cached_tokensを確認してください。GoogleのAPI別の仕様。

APIを運用するうえでの違いは、自動で起きたヒットを観測するのか、料金を払ってリソースを意図的に保持するのかにあります。複数のプロバイダーに対応するキャッシュの共通化層を作るなら、この2つのライフサイクルを同じものとして扱わないようにしましょう。

KVキャッシュのメモリ使用量は保持するコンテキストに比例する

通常のフルアテンション層では、KVキャッシュ本体のメモリ使用量は、保持するトークン数に比例して増えます。 会話の先頭部分が料金の割引対象になっていても、会話が長くなれば、処理のために保持するデータは増え続けます。

各シーケンスの長さが等しく、各アテンション層の構造も同じ場合、次の式で表せます。

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2：キー配列とバリュー配列の分です。
• B：同時に処理するシーケンス数です。シーケンス間でキャッシュのデータを共有しないと仮定します。
• T：各シーケンスで保持する処理済みトークン数です。プロンプトと生成済みのトークンを含みます。
• L：この種のキャッシュを保持するアテンション層の数です。
• H_kv：各層のキー／バリューヘッド数です。
• D：各ヘッドのスカラー値の数です。
• S：各スカラー値の保存に使うバイト数です。

この式は、公開されている各層のキャッシュ形状と、vLLMのキー／バリューヘッドの配置から、要素数を数えて導いたものです。見積もるのはテンソル本体のサイズであり、デバイス全体のメモリ使用量ではありません。

ヘッド数の選び方にも注意が必要です。複数のクエリヘッドでキー／バリューヘッドを共有するGrouped-query attentionでは、この式に入れるのはKVヘッド数です。それより多いクエリヘッド数を代入すると、キャッシュのサイズを過大に見積もってしまいます。

モデルと保存精度を固定したままTを2倍にすると、密な配列として保持するキャッシュ本体のサイズも2倍になります。Tと、互いに独立した同時処理シーケンス数の両方を2倍にすると、4倍になります。これは式から得られる結果であり、特定のGPUの収容能力や実測スループットを示すものではありません。

サポートサービスを自前でホストするなら、「顧客全体で、同時に何トークン分の状態を保持するのか」が容量設計の目安になります。モデルがメモリに収まるだけでは十分ではありません。サーバーには、顧客ごとに変化する推論状態を収める余裕も必要です。

ウィンドウを使う層の上限はHugging Faceのキャッシュ戦略ドキュメントに、再利用できる物理ブロックはvLLMのプレフィックスキャッシュの設計に説明があります。通常の密なキー／バリュー配列とは異なる構造では、そのアーキテクチャが公開している状態の配置に従って計算してください。

ホステッドAPIを使う側には、同じ増加が別の形で現れます。ヒット率が安定していても、ターンごとに読み取りとして課金されるトークン数が増える可能性があります。単価が安くても、入力が増え続ければ料金は増えます。出力の生成中もコンテキストへのアテンション処理は続き、料金区分のしきい値が入力全体の長さで決まる場合もあります。

vLLMでKVキャッシュを最適化するには

オープンソースのLLM推論サーバーであるvLLMには、メモリの割り当て、状態の再利用、データ表現を調整する機能があります。 デプロイ設定を変更する前に、どの機能が現在のボトルネックに効くのかを見極めましょう。

PagedAttention：会話の成長に合わせてブロックを割り当てる

PagedAttentionは、物理的に分かれたブロックに保存されたKVデータを使ってアテンションを計算します。論理上のシーケンスごとに、将来取りうる最大長を見越して、大きな連続領域を予約する必要がありません。元の設計は、割り当ての無駄を減らし、共有を可能にします。PagedAttentionの論文。

ここでも図書館のたとえが使えます。資料が増えていく調査プロジェクトに、空いている棚を順次割り当て、並び順を記録しておくイメージです。どれほど資料が増えるかわからない段階で、巨大な書架の列を丸ごと空けておく必要はありません。

ページングだけで、トークンごとに保存する情報が減るわけではありません。限られたメモリへの収め方を改善する仕組みです。また、vLLMはPaged Attentionカーネルのページを過去の実装に関する資料と位置づけています。考え方は参考になりますが、その古いカーネルの説明を現在の実装と同一視しないでください。

プレフィックスキャッシュ：以前のリクエストと共通する処理を省く

Automatic Prefix Cachingは、一致するプレフィックスのKV状態を再利用します。vLLMではenable_prefix_caching=Trueという設定が公開されています。同じ文書への質問を繰り返す場合や、エージェントの各ターンで先頭に同じ内容を送る場合に対応する機能です。Automatic Prefix Caching。

キャッシュを識別する情報には、単独のブロックのテキストだけでなく、その前にあるプレフィックスも含まれます。そのため、同じ段落でも、その前にある指示が異なれば、単純に使い回せるとは限りません。この依存関係は、vLLMのハッシュベースのキャッシュ設計で明示されています。

効果を左右するのはワークロードです。関連のないプロンプト同士では共有できる処理が少なく、長い回答を生成する処理では、依然としてデコードが時間の大半を占めることがあります。推論エンジン自体を選ぶ段階なら、vLLMとSGLangの比較で、より広い観点から選択肢を検討できます。

KVキャッシュの量子化：保存する値あたりのバイト数を減らす

KVキャッシュの量子化は、キャッシュする数値の精度を下げる手法です。vLLMはkv_cache_dtype="fp8"によるFP8のキャッシュ保存に対応しており、品質を確保するために、データセットを使ったスケールのキャリブレーションを推奨しています。利用できる方式はアテンションのバックエンドによって異なります。vLLMのキャッシュ量子化ドキュメント。

16ビットから8ビットに変えると、先ほどの式におけるスカラー値本体のデータ量は半分になります。ただし、これはスケールのメタデータやメモリ割り当てのオーバーヘッドを加える前の値です。サーバーの全メモリ使用量が半分になるわけではなく、実測での高速化を示すものでもありません。モデルの重みを量子化するかどうかは、アテンションの状態を量子化するかどうかとは別の判断です。

本番のエージェントでは、制約を保持する、適切なツールを選ぶ、前のメッセージから詳細を取り出すといった、実際に重要な長いタスクで評価してください。状態を小さくする価値があるのは、タスクを引き続き遂行できる場合です。サーバーが起動しただけで、品質も変わらないと判断してはいけません。

KVキャッシュの圧縮：数値の精度と保持する内容を分けて考える

数値の精度を下げることと、保持する位置を減らすことでは、失うものが異なります。 量子化が変えるのは値の表現方法です。一方、範囲を限定したアテンションウィンドウが変えるのは、その層から参照できる位置です。問題の起き方が異なるため、どちらも単に「圧縮」として一括りにするべきではありません。Hugging Faceのキャッシュ戦略。

まず取り組みやすいのは、無関係なツール出力を送らないことです。これにより、後続のコンテキストが増える原因を減らせます。ただし、これはアプリケーション側の判断です。保持する状態を最適化する前に、エージェントが必要とする根拠を残してください。

KVキャッシュのオフロード：転送と引き換えに、より多くの状態を保持する

オフロードは、再利用できる状態を別のメモリ階層に移す仕組みです。 vLLMのOffloadingConnectorは、完成したブロックをCPU側のホストメモリや対応する別の階層に保持し、ヒットした際に必要に応じてGPUへ戻せます。vLLMのオフロードガイド。

有用なプレフィックスを、GPUに置いておける期間より長く残したい場合に役立ちます。ただし、データの移動が発生します。再計算を避ける利点と転送の負荷を、自分のワークロードで比較してください。どの環境にも当てはまる遅延の改善幅はありません。

使用中のKVキャッシュでメモリが逼迫すると、vLLMはリクエストの処理を一時的に中断し、後で再計算することがあります。最適化ガイドでは、このプリエンプションが頻発する場合、同時実行数とメモリ割り当てを確認するよう勧めています。運用上は、GPUメモリが埋まって見えるという事実よりも、プリエンプション回数の増加のほうが、対処につながる指標です。

キャッシュヒット率だけでは判断できないこと

ヒット率が高くても、効率のよいエージェントとは限りません。 ヒット率が測るのは再利用です。業務で必要なのは、許容できる時間と予算でタスクを成功させることです。

会話では、それまでの入力のほぼすべてを再利用していても、ターンごとに入力が増えることがあります。不要な資料を、割引料金で何度も読み直しているだけかもしれません。また、プレフィックスの再利用では直接短縮できない出力生成に、時間の大半を費やしている場合もあります。

キャッシュの指標を守るためだけに、肥大化した会話履歴を残さないでください。過去の内容が役に立たなくなったら、履歴を圧縮するか会話を再開し、プレフィックスの変更で再処理が必要になることを受け入れましょう。判断の基準は、タスクの品質と処理全体の量です。作業用のコンテキストに何を含めるべきかは、当サイトのコンテキストエンジニアリングガイドで解説しています。

APIを利用する開発者なら、リクエスト間でまとまった量の内容が繰り返される場合は、まずプロンプトの配置を最適化しましょう。共通のプレフィックスがほとんど出てこないワークロードなら、複雑なキャッシュ管理は後回しで構いません。自前でホストする運用者は、モデルにもっと計算資源が必要だと判断する前に、メモリ割り当ての逼迫とプリエンプションを調べてください。短く、互いに関連のない単発リクエストでは、リクエストをまたいで再利用できる処理はわずかです。

LLMのKVキャッシュに関するよくある質問

ChatGPTはKVキャッシュを使っていますか？

OpenAIは、API向けにKVを使ったプロンプトキャッシュを公開しています。これでわかるのは公開APIの機能の仕組みであり、ChatGPT内部の推論基盤の詳細がすべてわかるわけではありません。開発時には、選択したAPIモデルが公開しているキャッシュ仕様と使用量フィールドを基準にしてください。OpenAIのドキュメント。

KVキャッシュはGPUメモリにオフロードするべきですか？

GPUでの推論では、処理中のアテンション状態をGPU上で使います。vLLMのオフロード機能は、再利用できるブロックをホストメモリなどの対応する階層へ移し、必要に応じて戻します。転送の負荷をかけても、より多くのプレフィックスを保持する価値がある場合に検討してください。vLLMのオフロード。

KVキャッシュがいっぱいになるとどうなりますか？

vLLMは、使われていないキャッシュブロックを追い出せます。また、処理中のリクエストによってメモリが逼迫すると、処理を一時中断し、後で再計算する場合があります。これは遅延に影響しますが、モデルのコンテキストウィンドウの上限を超えることとは別の問題です。キャッシュ管理、プリエンプション。

KVキャッシュの使用量を減らすにはどうすればよいですか？

保持するコンテキストや同時処理するシーケンスを減らす、条件を満たす共通プレフィックスを再利用する、保存精度を下げるといった方法があります。オフロードは状態の置き場所を変えるもので、全体のサイズが小さくなるとは限りません。メモリだけでなく、タスクの品質と観測した遅延も含めて効果を判断してください。キャッシュ戦略。

エージェントのキャッシュヒット率を保つ3つの習慣

タスクの実行中は先頭部分を固定し、変更は末尾への追加で行います。 プレフィックスの完全一致による再利用には、構成の安定したリクエストが有利です。ただし、プロバイダーが定める最小長、保持期間、利用可能性の条件は満たす必要があります。

1. 1

   固定のシステムプロンプトを先頭に置く

   APIが指定するメッセージ構造の範囲内で、長く使う指示、ツール定義、再利用する参考資料を、変化するタスクデータより前に置きます。文言、ツールの順序、シリアライズの形式を安定させてください。Anthropicでは、ツール、システム、メッセージの順に階層化されているため、ツール構成を変えると、その後ろを再利用できなくなることがあります。Anthropicのキャッシュ構造。

2. 2

   履歴を書き換えず、末尾に追加する

   過去のメッセージを保ち、新しいユーザーの発言、アシスタントのツール呼び出し、ツールの結果を末尾に追加します。呼び出しのたびに要約や書式を変えて、以前のターンを組み直すのは避けましょう。履歴の圧縮が必要になったら、意図的に区切りを設け、その後に新しい固定のプレフィックスを作ります。これは、各ブロックがそれ以前のトークンに依存するという性質に沿った運用です。vLLMにおけるプレフィックスの識別。

3. 3

   タイムスタンプを先頭に置かない

   現在時刻、リクエストIDなどの変化するメタデータは、再利用する内容の後ろに置きます。先頭にタイムスタンプがあると、その後ろのコンテキストを再利用できなくなることがあります。明示的なブレークポイントを使う場合は、変化する末尾部分の手前、つまり固定のプレフィックスの終端に設定します。Anthropicのブレークポイント設定ガイド。

次の仕事日に、代表的なエージェントの会話を選び、リクエスト単位で確認してみてください。連続する呼び出しのプレフィックスが完全に一致しているかを比較し、プロバイダーが返すキャッシュの書き込み量と読み取り量を、入力・出力の総量や遅延と併せて見ます。プロバイダーを変える前に、まず不安定なプレフィックスを直しましょう。ヒット状況に問題がないのにエージェントが遅いなら、次は保持するコンテキスト、出力長、サーバーのリソース競合を調べてください。

AIエージェントを支える仕組みの実践的な解説を、ニュースレターで受け取る。