LLM のプロンプトキャッシュの仕組み：KV キャッシュと TTL を解説

TL;DR — LLM のプロンプトキャッシュは、後付けの最適化ではありません。Transformer アーキテクチャによる attention の計算方法から自然に導かれる仕組みです。固定 prefix の Key／Value ベクトルを数学的に再利用できる理由が分かると、本当の利点が 2 つあることも見えてきます。コストを大幅に削減できる（50–90%）だけでなく、最初の token が返るまでの時間も大幅に短縮できます（5–20×）。全 5 回シリーズの Part 1 となる本記事では、キャッシュが成立するアーキテクチャ上の理由、キャッシュの採算を左右するメモリと計算量のトレードオフ、すべての開発者が把握しておくべき TTL の挙動を説明します。Part 2 では、provider ごとの実装を詳しく比較します。

シリーズ：全 5 回の Part 1 — キャッシュの原則 · 次の記事：Part 2 — Provider の比較と評価 · Part 3 — 実際に動くコードのチュートリアル · Part 4 — ユースケース別の最適な LLM · Part 5 — LangChain との統合 · 1 ページ版：プロンプトキャッシュ完全ガイド

AI アプリの token コストがユーザー数以上のペースで増える理由

チャットボット、RAG アプリ、AI agent のどれを開発していても、利用量は変わらないのに請求額だけが倍増する問題に直面しがちです。リクエストログを開くと、数千 token の同じ system prompt、同じ tool 定義、同じナレッジベースの chunk が、呼び出すたびに繰り返し送信されています。

これが LLM inference におけるコスト面の根本的な問題です。モデルは状態を保持しません。リクエストのたびに、context 全体を最初から処理し直します。8K token の system prompt を 1,000 回呼び出せば、同じ処理を 800 万 token 分繰り返すことになります。その全 token に料金がかかり、ユーザーも処理が終わるまで毎回待たされます。

この問題を解決するのが、プロンプトキャッシュです。ただし、一般的なパフォーマンス改善とは違い、アーキテクチャに追加された機能ではありません。Transformer の attention の定義から自然に成立する仕組みです。ここを理解すれば、料金、TTL、provider ごとの差も整理して理解できます。

1. LLM にキャッシュが存在する理由：Transformer inference の流れ

ほとんどのプロンプトキャッシュ解説では、この部分が省略されています。しかし、そもそもキャッシュがなぜ存在できるのかを理解するうえで重要です。また、provider の割引率が単なるマーケティング上の数字ではなく、実際の GPU コストを反映している理由も分かります。

1.1 1 つの式で見る Self-Attention

decoder-only Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen が属するモデル群）は、self-attention を繰り返し適用して token を処理します。N token の sequence に対し、各 token i の attention 出力は次の式で表されます。

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q、K、V は、入力 embedding に対して学習済みの 3 つの線形射影を適用して得られる、shape [N × d] の matrix です。射影は layer、head ごとに 1 組あります。この定義は、Attention Is All You Need（Vaswani et al., 2017）で提案されました。

この式には、キャッシュにとって極めて重要な性質が 2 つあります。

性質 1 — Causal masking。 生成時に token i が参照できるのは、位置 ≤ i の token だけです。attention matrix は下三角行列になります。先頭側の token の K／V ベクトルは、それ以降のすべての token から使われますが、後続の token によって変更されることはありません。

性質 2 — K と V は prefix だけで決まる。 K と V は、位置 1…i の入力 embedding に固定の weight matrix を適用して計算されます。したがって、位置 i の K／V ベクトルは、位置 1…i の token だけで一意に決まります。位置 i+1 以降の内容によって、K_i や V_i が変わることはありません。

ここから、2 つのリクエストが長さ P の完全に同一な prefix を共有していれば、K と V の先頭 P 行は bit 単位で一致することが分かります。

これがプロンプトキャッシュの理論的な根拠です。残りはすべて実装上の話です。

1.2 Inference の 2 つのフェーズ

現在の LLM inference は、GPU 時間の使い方が大きく異なる 2 つのフェーズに分かれます。この区分は、Efficiently Scaling Transformer Inference（Pope et al., 2022）で詳しく説明されています。

Prefill フェーズ。 モデルは prompt 全体を一度に読み込みます。各 layer で全 input token の Q、K、V を計算し、self-attention を実行します。Prefill は compute-bound です。GPU の行列演算ユニットを使い切ります。attention matrix があるため、コストは prompt 長に対して O(N²) で増加します。

Decode フェーズ。 モデルは autoregressive に output token を 1 つずつ生成します。step t では、新しい token の Q だけを計算し、過去のすべての token の K／V を参照します。Decode は memory-bandwidth-bound です。時間の大半は乗算ではなく、GPU メモリからの K／V の読み出しに使われます。token ごとのコストは、現在の context 長に対して O(N) で増加します。

一般的なチャットボットの workload（8K token の system prompt ＋ 100 token の user query ＋ 300 token の response）では、実行時間と料金のどちらも prefill が約 4:1 の割合で支配します。キャッシュによって省けるのは、この処理です。

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 KV キャッシュ：Decode で Prefill の計算結果を再利用する

「KV キャッシュ」は、もともと 1 回のリクエスト内で使う最適化を指していました。Decode 中に新しく生成される各 token は、過去の全 token の K と V を参照する必要があります。step ごとに再計算すると、decode の計算量は O(N) から O(N²) になってしまいます。そのため、すべての inference engine は prefill で計算した K と V を GPU メモリに保存し、decode フェーズ全体で再利用します。これは例外のない仕組みで、すべての商用 LLM が採用しています。現実的な時間で生成できるのは、この仕組みがあるからです。

provider が「プロンプトキャッシュ」として提供しているのは、その仕組みをさらに拡張したものです。リクエスト終了後も KV キャッシュを保持し、同じ prefix を共有する次のリクエストで再利用します。

1.4 メモリと計算量のトレードオフ（TTL が必要な理由）

では、なぜすべての provider が全データを永久にキャッシュしないのでしょうか。理由は、KV キャッシュのサイズが非常に大きいからです。

Transformer layer 数が L、attention head 数が H、head の次元数が D、値あたりの byte 数が B（通常 fp16 では 2）のモデルで、N token 分の KV キャッシュサイズは次のとおりです。

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

80 layer、8 KV head（grouped-query-attention 適用後）、head-dim 128、fp16 weight の 70B クラスモデルでは、token あたり約 320 KB です。32K token の context なら、1 リクエストだけで 約 10 GB の KV キャッシュを消費します。現在の H100 GPU は 80 GB なので、同時に保持できるのは数件程度です。

この制約を batch 単位で解決するために設計されたのが、PagedAttention（Kwon et al., 2023、vLLM の基礎となった論文）です。同じ制約が、リクエストをまたぐプロンプトキャッシュにも上限を与えます。

つまり、provider の cache TTL は実質的にメモリの eviction policyです。いずれ GPU が他ユーザーの稼働中 workload にメモリを必要とし、キャッシュされた prefix が eviction されます。HBM 上のキャッシュでは 5 分、DRAM に page out するキャッシュでは最大 1 時間、disk-backed cache では数時間です。

DeepSeek の工夫。 DeepSeek-V2 は Multi-head Latent Attention（MLA）を導入し、標準的な grouped-query attention と比べて KV キャッシュを約 4× 圧縮しました（DeepSeek-AI, 2024）。この圧縮により、KV キャッシュを HBM ではなく disk に保持できます。その結果、最小キャッシュ単位を大幅に小さくでき（HBM 上のキャッシュでは 1,024 token なのに対して 64 token）、実効 TTL も大幅に長くできます。

リクエストをまたいでキャッシュを使うには、token 単位で完全に同一な prefix が必要です。キャッシュは token ID の hash を key として参照されます。1 文字でも異なり、tokenize の結果が変われば、その位置以降の K と V は別物になります。この layer に「曖昧一致」はありません。それを行うのは semantic caching ですが、gateway 内では別の仕組みです。

1.5 2 層のキャッシュ

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

シリーズの残りで扱う内容も、開発者が調整する項目の大半も Layer 2 に関するものです。

2. 2 つの効果：コストとレイテンシ

多くの記事は、キャッシュをコスト最適化として説明します。しかし、それだけでは利点を十分に捉えられません。本番環境のチームがキャッシュを導入する理由としては、特にユーザー向けチャットにおいて、レイテンシの改善のほうが大きいこともあります。

2.1 コストの計算

料金ページには主要な数字が載っていますが、現実的な workload に当てはめた計算はほとんど示されていません。8,000 token の system prompt を使い、1 日 100K 件の query を処理し、user message が 200 token のカスタマーサポート bot を例にします。Anthropic が公開した 2026 年の料金（cached input は 10%、cache write は 125% の割増）を使い、claude-sonnet-4-5 のコストを計算します。

キャッシュなし

• 1 回あたりの input：8,200 token × 通常の input rate
• 1 回あたりのコスト（単発呼び出しの実測値）：約 $0.022
• 月間コスト：100K × 30 × $0.022 ＝ 約 $66,000

プロンプトキャッシュあり

• 初回の cache write：8,000 token × 125% の割増（月間 volume に対しては無視できる水準）
• 2 回目以降：8,000 token × 通常料金の 10% ＋ 200 token × 通常料金 ＋ output
• 実効的な 1 回あたりのコスト：約 $0.003
• 月間コスト：約 $9,000

約 86% の削減です。 Anthropic が公開している割引率を、現実的な input 構成に当てはめた数字です。続く記事（Part 3 — チュートリアル）では、他の provider も含めた実測値を紹介します。

2.2 レイテンシの改善（こちらのほうが重要な場合もある）

Prefill はコストが高いだけではありません。数百 token を超える prompt では、最初の token が返るまでの時間を最も大きく左右する処理です。cache hit すれば、そのほとんどを省略できます。

公開 Synthorai gateway で測定した streaming TTFT。測定日は 2026-05-25、固定 system prompt は約 7,300 token です。

single-run、single-tenant での測定です。TTFT の改善が明確に現れるのは、長い prompt（>5K token）の場合です。短い prompt では prefill の割合が小さいため、レイテンシを支配するほどではありません。Claude で最も大きく測定された効果はコストです。cache read の input 料金は約 88–89% 下がります。Anthropic の公開値によれば、prompt が 100K token 以上になると、TTFT の改善も大幅に積み上がります。

チャット UI では、ユーザーが遅延を明確に感じ始める境界は、TTFT で約 1 s、意味のある最初のテキストが表示されるまでで約 2 s です。キャッシュなしの 10K token の RAG prompt は、確実にこの境界を超えます。キャッシュすれば、同じ workload でも即座に応答したように感じられます。

15 step 以上の agent loop では、コスト面の効果（50% 削減）もありますが、製品としてリリース可能にするのはレイテンシの改善です。15 step × 5s の prefill なら task ごとに 75 s 待たされますが、キャッシュすれば 15 × 0.5s ＝ 7.5 s になります。

2.3 プロダクト戦略にも関わる理由

キャッシュを「運用チームが行うコスト最適化」と考え、リリース後に追加するのはよくある間違いです。レイテンシも改善されるため、キャッシュは UX の一部でもあります。

• TTFT が 1 s 未満のチャットボットは軽快に感じられます。同じ bot でも 3 s かかれば、壊れているように見えます。
• retrieval と prefill に 4 s かかる RAG 製品は、同じ処理を 1 s で終える製品に負けます。
• task を 20 s で完了する agent は、90 s かかる agent より優位です。

キャッシュ戦略は、モデルや prompt 構成を決めるのと同じタイミングで設計するべきです。リリースから 3 sprint 後に検討するものではありません。

3. キャッシュの freshness、TTL、運用モデル

TTL は、プロンプトキャッシュについて特によく聞かれる一方、十分に説明されていない項目です。理解すべき点は 2 つあります。

3.1 Freshness には 2 つの意味がある

キャッシュの freshness と response の freshness は別物です。 次の 2 つはよく混同されます。

キャッシュを使った response が、モデル品質の意味で「古くなる」ことはありません。キャッシュなしの場合と数学的に同一です。ただし、「現在時刻は 14:32:05」と system prompt に書いたまま cache hit に頼ると、「現在時刻」は TTL が切れるまで 14:32:05 のままです。モデルは誤った時刻を自信を持ってユーザーに伝えます。

3.2 Provider ごとの TTL の挙動

デフォルトが 5 分なのは偶然ではありません。人気モデルの peak load 時に GPU メモリへかかる圧力を考えると、おおむね妥当な保持時間です。§1.4 で計算したとおり、長い context 1 つの KV キャッシュだけで数十 GB に達する場合があります。provider が無期限に保持するのは現実的ではありません。

3.3 TTL を考慮した設計

本番環境で有効な pattern は 3 つあります。

Pattern A — Session を warm に保つ。 チャットでは、turn 間の自然なリクエスト間隔が数秒から数分なので、それだけでキャッシュが維持されます。TTL を過度に気にする必要はありません。ただし、動的なデータを prefix に置かないでください。

Pattern B — Batch では heartbeat を送る。 数時間に及ぶ batch job では、TTL/2 ごとに最小限のリクエストを送ってキャッシュを warm に保ちます。コストは実質ゼロ（数 input token）で、cache eviction が一斉に発生するのを防げます。

Pattern C — Cold storage には長い TTL の provider を使う。 50K token の document に低頻度で query する場合（たとえば 1 週間にわたって 1 時間に 1 回）、ストレージ料金を含めても、Gemini の explicit cache（TTL 24 時間）や DeepSeek の disk cache のほうが、短い TTL の選択肢より有利です。

4. すべての開発者が知っておくべき共通原則

provider が提供するキャッシュの形態は大きく 5 つに分かれます。明示的な marker、完全自動、hybrid、disk-backed のアーキテクチャ、キャッシュなしです。次の記事（Part 2 — Provider の比較と評価）では、この違いを詳しく比較します。ただし、先ほど説明したアーキテクチャから直接導かれる 4 つの原則は、どの provider にも共通します。

4.1 キャッシュは Prefix ベースであり、順序が重要

位置 i の K／V は位置 1…i の token に依存するため、provider が一致判定できるのは token 0 から始まる連続した prefixだけです。位置 0 の 1 文字を変えるだけで、prefix 全体が無効になります。固定コンテンツを先頭に、変動するコンテンツを末尾に置いてください。 これは経験則ではありません。self-attention の causal structure から直接導かれます（§1.1）。

4.2 キャッシュに保存されるのは回答ではなく K／V

cache hit で以前に生成した回答が返るわけではありません。返されるのは以前に計算した K／V ベクトルで、モデルはそれを使って現在の質問に対する新しい response を生成します。そのため、次の性質があります。

• Output 品質はキャッシュなしの呼び出しと同一です（§1.1）。
• Output は通常どおり非決定論的です。temperature、top-p なども引き続き適用されます。
• キャッシュした response がモデル品質の意味で「古くなる」ことはありません。古くなり得るのは、timestamp や価格など prompt の内容だけです。§3.1 も参照してください。

4.3 Cache Write は無料ではなく、先行投資

write に割増料金がかかる provider（Anthropic は 125%、Gemini explicit は 125%）では、新しい prefix を使う最初の呼び出しは、キャッシュなしより高くなります。損益分岐点にはすぐ到達し、通常は 1 回 hit すれば回収できます。ただし、「固定」のはずの prefix がリクエストごとに変わると、効果がないまま write コストだけを何度も支払うことになります。retrieval した document を関連度順に並べ替える場合は注意してください。これは典型的な anti-pattern です。

4.4 Caching API は Provider 間で互換性がない

cache_control（Anthropic）≠ cached_content（Gemini）≠ cache_id（Qwen）です。複数の provider に対応するアプリでは、3 種類の統合を保守するか、手前に Token Gateway を置いて統一する必要があります。Part 2 で詳しく説明します。

5. プロンプトキャッシュは使うだけで得をするのか

ほぼそうです。次の条件を満たせば、効果が出ます。

• prompt に 固定 prefix がある。system prompt、ナレッジベース、tool schema など
• 呼び出しが頻繁、または連続している。同一 session、batch workload、実行中の agent run など
• 固定コンテンツを先頭に置くよう prompt を構成できる

この 3 つを満たせば、通常はモデルを変えなくても、コストを 50–90% 削減し、TTFT を 3–20× 高速化できます。

次回：Part 2 — Provider のキャッシュ比較と評価フレームワーク では、ここまでのアーキテクチャを踏まえ、Claude、OpenAI、Gemini、DeepSeek、Qwen を機能ごとに比較します。workload に適した provider を選ぶための評価基準も紹介します。

Quickstart：OpenAI SDK ですべての Provider を使う

Synthorai は OpenAI-compatible endpoint を提供しています。公式の openai SDK の接続先を変更するだけで、すべてのモデル（Claude、GPT、Gemini、DeepSeek、Qwen）を model の 1 行だけで切り替えられます。gateway が cache_control を各 provider 固有のキャッシュ構文へ変換します。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

同じ呼び出しを gpt-5.4-mini、gemini-2.5-pro、deepseek-v4-flash、qwen3-max にも使えます。変更するのは model field だけです。gateway は prompt cache hit の metadata を、標準の OpenAI prompt_tokens_details.cached_tokens field で返します。さらに USD 単位の cost field も返すため、vendor ごとの料金 matrix をローカルで管理する必要はありません。

FAQ

LLM のプロンプトキャッシュと semantic caching は同じですか？ いいえ。プロンプトキャッシュは prefix ベースです。prompt の先頭が token 単位で完全一致した場合に、K／V の値を再利用します。Semantic caching は embedding を使って意味の単位で一致させ、以前の response を返します。どちらも有用で、優れた Token Gateway は両方を layer として組み合わせます。

プロンプトキャッシュによってモデルの output は変わりますか？ いいえ。K と V は input token から決定論的に求まります（§1.1）。キャッシュした K／V からモデルが生成する logit は、再計算した K／V から生成するものと数学的に同一です。キャッシュは効率だけを改善し、品質には影響しません。

Cache TTL が短いのはなぜですか？永久に保持できないのでしょうか？ KV キャッシュが非常に大きいためです（§1.4：70B モデルでは 32K context あたり約 10 GB）。ボトルネックは GPU メモリです。server が稼働中の workload にメモリを必要とすれば、キャッシュは eviction されます。disk-backed cache（DeepSeek）は数時間保持できますが、in-memory cache では通常不可能です。

KV キャッシュとプロンプトキャッシュの違いは何ですか？ KV キャッシュは inference 中に使われる in-memory data structure です。「プロンプトキャッシュ」は、その KV キャッシュをリクエスト間で再利用する仕組みです。上の §1.5 で説明した Layer 1 と Layer 2 の違いです。

キャッシュされた prompt が古くなり、品質が低下することはありますか？ モデルの観点ではありません。ただし、prompt に時間依存の情報が含まれていれば、コンテンツの観点では古くなる可能性があります。キャッシュが保存するのは K／V ベクトルであり、現実世界の事実ではありません。§3.1 を参照してください。

Cache hit rate はどう測定しますか？ すべての provider が response の usage object で返します。cache_read_input_tokens（Anthropic）、cached_tokens（OpenAI）、cached_content_token_count（Gemini）、prompt_cache_hit_tokens（DeepSeek）です。logging pipeline で記録してください。

参考文献と出典： Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — MLA アーキテクチャ · Anthropic のプロンプトキャッシュドキュメント · OpenAI のプロンプトキャッシュドキュメント · Google Gemini の Context Caching ドキュメント · DeepSeek の KV キャッシュガイド · Alibaba Bailian の Context Cache

← ブログに戻る