LLM プロンプトキャッシュ #1：KV キャッシュと TTL の仕組み

TL;DR — LLM プロンプトキャッシュは後付けの最適化ではありません。それは Transformer アーキテクチャが実際にアテンションを計算する仕組みから自然に導かれるものです。安定したプレフィックスの Key/Value ベクトルがなぜ数学的に再利用可能なのかを理解すると、本当の驚きはその二重の恩恵にあると分かります。すなわち、劇的なコスト削減（50〜90%）そして劇的な最初のトークンまでの時間（TTFT）の短縮（5〜20×）です。本記事は全 4 部シリーズの第 1 部で、キャッシュが存在する architectural な理由、キャッシュが採算に合うかどうかを決めるメモリ対計算のトレードオフ、そしてすべての開発者が理解すべき TTL の挙動を扱います。第 2 部では各プロバイダー固有の実装に踏み込みます。

シリーズ：全 4 部の第 1 部 — キャッシュの原理 · 次：第 2 部 — プロバイダー比較と評価 · 第 3 部 — 動作するコードチュートリアル · 第 4 部 — ユースケース別ベスト LLM

なぜあなたの AI アプリのトークン請求はユーザーより速く増えるのか

チャットボット、RAG アプリ、AI エージェントを開発しているなら、おそらく同じ壁にぶつかったことがあるはずです。利用量は増えていないのに請求額は倍になる。リクエストログを開けば、同じ数千トークンのシステムプロンプト、同じツール説明、同じナレッジベースの断片が、呼び出しのたびに再送信されているのが見つかります。

これが LLM 推論の中心的な経済問題です：モデルはステートレスである。すべてのリクエストはコンテキスト全体をゼロから再処理します。8K トークンのシステムプロンプトを 1,000 回呼び出せば、800 万トークン分の重複作業に等しくなります。あなたはそのすべてに料金を払い——ユーザーはそのすべてを待たされます。

プロンプトキャッシュはこれを解決します。しかしほとんどの性能テクニックとは異なり、これはアーキテクチャに追加されたものではありません——Transformer アテンションの定義のされ方から生じる自然な帰結です。それが見えれば、記事の残りの部分（料金、TTL、プロバイダーの違い）はすっきりと整理されます。

1. なぜ LLM にそもそもキャッシュがあるのか：Transformer 推論のウォークスルー

このセクションは、ほぼすべての「プロンプトキャッシュ」チュートリアルが飛ばす部分です。そもそもなぜキャッシュが存在するのか——そしてプロバイダーが提示する割引が恣意的なマーケティングの数字ではなく、実際の GPU 経済を反映している理由を説明します。

1.1 セルフアテンションを 1 つの方程式で

デコーダー専用（decoder-only）の Transformer（GPT-4、Claude、Gemini、DeepSeek、Qwen はすべてこのファミリーに属します）は、セルフアテンションを繰り返し適用することでトークンを処理します。N 個のトークンからなる系列に対して、各トークン i のアテンション出力は次のとおりです：

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

ここで Q、K、V は形状 [N × d] の行列で、入力埋め込みから 3 つの学習済み線形射影（層ごと・ヘッドごとに 1 つ）によって得られます。元の定義は Attention Is All You Need（Vaswani ら、2017）によるものです。

この方程式の 2 つの性質がキャッシュにとって非常に重要です：

性質 1 —— 因果マスキング（causal masking）。 生成中、トークン i は位置 ≤ i のトークンにしかアテンションできません。アテンション行列は下三角です：初期トークンの K と V ベクトルは後続のすべてのトークンに使われますが、後続のトークンがそれらを変更することは決してありません。

性質 2 —— K と V はプレフィックスにのみ依存する。 これらは位置 1…i の入力埋め込みから固定の重み行列を介して計算されるため、位置 i の K と V ベクトルは位置 1…i のトークンの決定論的関数です——そしてそれらのトークンにのみ依存します。位置 i+1 に関するいかなる情報も K_i や V_i を変えることはできません。

ここから直ちに次の結論が得られます：2 つのリクエストが長さ P の同一プレフィックスを共有するなら、K と V の最初の P 行はビット単位で完全に同一である。

これがプロンプトキャッシュの理論的基盤のすべてです。残りはすべてエンジニアリングです。

1.2 推論の 2 つのフェーズ

現代の LLM 推論は、GPU 時間の消費の仕方が大きく異なる 2 つの明確なフェーズで動きます。この分割は Efficiently Scaling Transformer Inference（Pope ら、2022）に詳しく記載されています。

プレフィル（Prefill）フェーズ。 モデルはプロンプト全体を一度に取り込みます。各層について、すべての入力トークンの Q、K、V を計算しセルフアテンションを実行します。プレフィルは**計算律速（compute-bound）**です：GPU の行列乗算ユニットを飽和させます。アテンション行列のため、コストはプロンプト長に対して O(N²) でスケールします。

デコード（Decode）フェーズ。 モデルは自己回帰的に一度に 1 つの出力トークンを生成します。ステップ t では、新しいトークンの Q のみが計算され、それまでのすべてのトークンの K/V に対してアテンションします。デコードは**メモリ帯域律速（memory-bandwidth-bound）**です——時間のほとんどは乗算ではなく GPU メモリからの K/V の読み出しに費やされます。コストはトークンあたり O(N)（現在のコンテキスト長に対して線形）でスケールします。

典型的なチャットボットのワークロード（8K トークンのシステムプロンプト + 100 トークンのユーザークエリ + 300 トークンの応答）では、プレフィルが実時間と金銭的コストの両方をおよそ 4:1 の比率で支配します。それがキャッシュで節約される部分です。

1 回の呼び出しの内訳（8K プロンプト、300 出力トークン、Claude 級モデル）：

  ████████████████████████████████░░░░░░░░  Prefill：計算の約 80%
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode： 計算の約 20%

1.3 KV キャッシュ：プレフィルの成果をデコードに残す

「KV キャッシュ」は元々、リクエスト内部の最適化を指していました。デコード中、新しく生成される各トークンは、それまでのすべてのトークンの K と V にアテンションする必要があります。それらを毎ステップ再計算すれば、O(N) のデコードが O(N²) のデコードになってしまいます。そこですべての推論エンジンは、プレフィルで得た K と V を GPU メモリに保存し、デコードフェーズ全体で再利用します。これは普遍的です——あらゆる商用 LLM がこれを行っています。それこそが生成を計算的に成立させているものです。

プロバイダーが「プロンプトキャッシュ」として公開しているのは、さらに次の一般化です：リクエスト終了後も KV キャッシュを保持し、同じプレフィックスを共有する次のリクエストで再利用する。

1.4 メモリ・計算のトレードオフ（TTL が存在する理由）

ではなぜプロバイダーはすべてを永久にキャッシュしないのでしょうか。KV キャッシュが巨大だからです。

L 個の Transformer 層、H 個のアテンションヘッド、ヘッド次元 D、値あたり B バイト（fp16 では通常 2）のモデルでは、N トークンの KV キャッシュサイズは次のとおりです：

KV キャッシュサイズ  =  2 × L × H × D × B × N
                       ↑   ↑   ↑   ↑   ↑   ↑
                       K&V 層  ヘッド ヘッド次元 バイト トークン

80 層、8 個の KV ヘッド（グループ化クエリアテンション GQA 適用後）、ヘッド次元 128、fp16 重みの 70B 級モデルでは、おおよそトークンあたり 320 KB になります。32K トークンのコンテキスト = 約 10 GB の KV キャッシュ、たった 1 つのリクエストのためにです。現代の H100 GPU は 80 GB を備えていますが、こうしたものを同時に収められるのはせいぜい数個です。

これこそ PagedAttention（Kwon ら、2023、vLLM の元論文）がバッチレベルで解決するよう設計された中心的制約です——そして同じ制約がリクエスト横断レベルでプロンプトキャッシュを縛ります：

つまりプロバイダーのキャッシュ TTL は本質的にメモリ追い出しポリシーです：ある時点で GPU はそのメモリを他ユーザーのアクティブなワークロードに必要とし、キャッシュされたプレフィックスは追い出されます。HBM 常駐キャッシュでは 5 分、DRAM へのページングキャッシュでは最大 1 時間、ディスクバックドキャッシュでは数時間。

DeepSeek の妙技。 DeepSeek-V2 はマルチヘッド潜在アテンション（Multi-head Latent Attention、MLA）を導入し、標準的なグループ化クエリアテンションと比べて KV キャッシュをおよそ 4 倍圧縮しました（DeepSeek-AI、2024）。まさにその圧縮こそが、KV キャッシュを HBM ではなくディスクに永続化することを可能にし——それがさらに、はるかに小さい最小キャッシュ単位（HBM 常駐キャッシュの 1,024 トークンに対し 64 トークン）とはるかに長い実効 TTL を実現します。

これがまた、リクエスト横断のキャッシュがトークン単位で完全に同一のプレフィックスを必要とする理由でもあります。キャッシュはトークン ID のハッシュでインデックスされ、いかなる相違——再トークナイズが異なる結果になる 1 文字でさえ——もその時点以降に異なる K と V を生み出します。この層には「あいまい一致」はありません（それはセマンティックキャッシュが行うことですが、それはゲートウェイ内の別の仕組みです）。

1.5 2 つの層のキャッシュ

┌──────────────────────────────────────────────────────────────┐
│  第 1 層：リクエスト内 KV キャッシュ（常時オン、全プロバイダー）│
│  → デコードを O(N²) ではなく O(N) に保つ                     │
│  → あなたが気にする必要はない。プロバイダーが勝手にやる       │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  第 2 層：リクエスト横断プロンプトキャッシュ（本シリーズが    │
│           扱うコストと時間の節約装置）                        │
│  → プレフィックスが一致するリクエスト間でプレフィル K/V を再利用│
│  → 公開形態：明示的 / 完全自動 / ハイブリッド                │
│  → TTL によって制約される（メモリ追い出し駆動）              │
└──────────────────────────────────────────────────────────────┘

シリーズの残り——そして開発者として調整する内容のほとんど——は第 2 層にあります。

2. 2 つの勝利：コストとレイテンシ

ほとんどの記事はキャッシュをコスト最適化として位置づけます。それは過小評価です。レイテンシの恩恵は、特にユーザー向けのチャットにおいて、本番チームがキャッシュを採用するより大きな理由であることがよくあります。

2.1 コストの計算

料金ページは見出しの数字を示しますが、それを現実的なワークロードに適用した姿はめったに見せません。8,000 トークンのシステムプロンプト、1 日 10 万クエリ、200 トークンのユーザーメッセージを持つカスタマーサポートボットを考えてみましょう。Anthropic が公表した 2026 年のレート（キャッシュ入力 10%、キャッシュ書き込みプレミアム 125%）で claude-sonnet-4-5 を使って料金を見積もります：

キャッシュなし

• 呼び出しあたりの入力：8,200 トークン × 基本入力レート
• 呼び出しあたりのコスト（単発実測）：約 $0.022
• 月間コスト：100K × 30 × $0.022 = 約 $66,000

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

• 一度きりのキャッシュ書き込み：8,000 トークン × 125% プレミアム（月間ボリュームに対して無視できる）
• 以降の呼び出しごと：8,000 トークン × 10% 基本 + 200 トークン × 基本 + 出力
• 実効的な呼び出しあたりコスト：約 $0.003
• 月間コスト：約 $9,000

約 86% の節約。 この数字は、Anthropic が公表した割引を現実的な入力形態に適用したものです。続く記事（第 3 部 — チュートリアル）では、残りのプロバイダー全体にわたる実測値を示します。

2.2 レイテンシの勝利（しばしばこちらが本命）

プレフィルは高価なだけではありません——数百トークンを超えるあらゆるプロンプトにとって、最初のトークンまでの時間（TTFT）への最大の単独寄与要因です。キャッシュヒットは、そのほぼすべてをスキップさせてくれます。

公開 Synthorai ゲートウェイに対して実測したストリーミング TTFT、2026-05-25、約 7,300 トークンの安定したシステムプロンプト：

単一実行、シングルテナント。TTFT の恩恵は長いプロンプト（>5K トークン）で最も顕著です。短いプロンプトではプレフィル部分が小さすぎてレイテンシを支配しません。Claude の実測上の最大の恩恵はコストです（キャッシュ読み出し時に入力が約 88〜89% 減）——100K+ 規模のプロンプトサイズでは、Anthropic の公表値によれば TTFT の恩恵が大きく積み上がります。

チャット UI では、ユーザーが意識的に遅延を感じ取る閾値は、TTFT で約 1 秒、最初の有用なテキストで約 2 秒です。キャッシュなしの 10K トークンの RAG プロンプトは、その線をはるかに超えています。キャッシュがあれば、同じワークロードが瞬時に感じられます。

15 ステップ以上のエージェントループでは、コストの話も良好（50% 節約）ですが、製品を実際に出荷可能にするのはレイテンシの話です：15 ステップ × 5s プレフィル = タスクあたり 75 秒の無駄な時間 → キャッシュがあれば、15 × 0.5s = 7.5 秒。

2.3 なぜこれがプロダクト戦略にとって重要なのか

よくある誤りは、キャッシュを「運用チームがやるコスト最適化」——ローンチ後に後付けするもの——として扱うことです。しかしレイテンシの恩恵は、キャッシュが UX 表面の一部でもあることを意味します：

• TTFT が 1 秒未満のチャットボットは生きているように感じられます。同じボットが 3 秒だと壊れているように感じられます。
• 検索+プレフィルに 4 秒かかる RAG 製品は、それが 1 秒で済む同じ製品に負けます。
• タスクを 20 秒で完了するエージェントは、90 秒かかるものに勝ちます。

キャッシュ戦略は、モデルとプロンプト構造を決めるのと同時に決めるべきです——ローンチ 3 スプリント後ではなく。

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

TTL の問題は、プロンプトキャッシュの中で最もよく質問され、最も説明されていない部分の 1 つです。理解すべきことが 2 つあります：

3.1 鮮度には 2 つの意味がある——混同しないこと

キャッシュの鮮度 ≠ 応答の鮮度。 しばしば混同される 2 つの異なる概念があります：

言い換えれば：キャッシュされた応答は、モデル品質の意味では決して「古く」なりません。それらは数学的にキャッシュなしのものと同一です。しかし「現在時刻は 14:32:05」をシステムプロンプトに入れてキャッシュヒットに頼ると、あなたの「現在時刻」は TTL 失効まで 14:32:05 のままになり、モデルはそれについてユーザーに自信満々で嘘をつくことになります。

3.2 プロバイダー間の TTL の挙動

5 分というデフォルトは恣意的ではありません——ピーク負荷時の人気モデルにおける GPU メモリ圧迫のおおよその時間的見通しです。§1.4 で計算したように、1 つの大きなコンテキストの KV キャッシュは数十 GB になり得ます。プロバイダーはそれらを無期限に保持する余裕がありません。

3.3 TTL を見据えた設計

本番で機能する 3 つのパターン：

パターン A —— セッションをウォームに保つ。 チャットでは、自然なリクエストの間隔（ターン間で数秒から数分）だけでキャッシュが自力で生き続けます。TTL を気にする必要はありません。動的データをプレフィックスに入れないことだけ守ってください。

パターン B —— バッチにはハートビート。 数時間にわたるバッチジョブでは、TTL/2 ごとに最小限のリクエストを送ってキャッシュをウォームに保ちます。コストは実質ゼロ（わずかな入力トークン）で、キャッシュ追い出しの嵐を防ぎます。

パターン C —— コールドストレージには長 TTL のプロバイダーを。 まれにしかクエリされない 50K トークンの文書（例：1 週間にわたり 1 時間に 1 回）があるなら、ストレージ料金がかかっても、Gemini の明示的キャッシュ（24 時間 TTL）や DeepSeek のディスクキャッシュが短 TTL の選択肢を上回ります。

4. すべての開発者が知っておくべき普遍的原則

プロバイダーはキャッシュを 5 つの非常に異なる形態で公開します——明示的マーカー、完全自動、ハイブリッド、アーキテクチャレベルのディスクバッキング、あるいはまったくなし。その比較には次の記事を丸ごと割きます（第 2 部 — プロバイダー比較と評価）。しかし、どのプロバイダーであっても当てはまり、今ウォークスルーしたアーキテクチャから直接導かれる 4 つの原則があります：

4.1 キャッシュはプレフィックスベース——順序が重要

位置 i の K/V は位置 1…i のトークンに依存するため、プロバイダーはトークン 0 から始まる連続したプレフィックスしか一致させられません。位置 0 の 1 文字を変えれば、プレフィックス全体が無効化されます。安定した内容を先頭に、揮発性の内容を末尾に。 これはヒューリスティックではありません——セルフアテンションの因果構造（§1.1）の直接的な帰結です。

4.2 キャッシュが保存するのは K/V であって答えではない

キャッシュヒットは以前に生成された答えを返すのではありません——以前に計算された K と V ベクトルを返し、モデルはそれを使って現在の質問に対する新しい応答を生成します。これは次のことを意味します：

• 出力品質はキャッシュなしの呼び出しと同一（§1.1）。
• 出力は通常の意味で非決定論的——temperature、top-p などは依然として適用されます。
• キャッシュされた応答はモデル品質の意味で決して「古く」ならない——古くなり得るのはプロンプトの内容（タイムスタンプ、価格）だけです。もう一度 §3.1 を参照してください。

4.3 キャッシュ書き込みは投資であり、無料ではない

書き込みプレミアムを課すプロバイダー（Anthropic 125%、Gemini 明示的 125%）では、新しいプレフィックスでの最初の呼び出しはキャッシュなしより高くつきます。損益分岐は速い（通常ヒット 1 回）ですが、「安定した」プレフィックスがリクエストごとに変わるなら、見返りなしに書き込みコストを何度も払うことになります。検索した文書を関連度でソートしているなら要注意です——それは古典的なアンチパターンです。

4.4 キャッシュ API はプロバイダー間で移植できない

cache_control（Anthropic）≠ cached_content（Gemini）≠ cache_id（Qwen）。アプリケーションが複数のプロバイダーで動かなければならないなら、3 つの統合を維持するか、前段に Token ゲートウェイを置いてそれらを統一するかのどちらかです。第 2 部で詳しく扱います。

5. プロンプトキャッシュはタダで手に入る金か？

ほぼそうです。次の場合に元が取れます：

• プロンプトに安定したプレフィックスがある——システムプロンプト、ナレッジベース、ツールスキーマ
• 呼び出しが頻繁または連続している——同一セッション、バッチワークロード、進行中のエージェント実行
• 安定した内容が先頭に来るようにプロンプトを構成できる

この 3 つを満たせば、モデルを変えることなく、通常支出が 50〜90% 減、TTFT が 3〜20× 高速化します。

次回予告：第 2 部 — プロバイダーのプロンプトキャッシュ比較と評価フレームワークでは、上記のアーキテクチャの全体像を、Claude、OpenAI、Gemini、DeepSeek、Qwen の機能ごとの比較に落とし込み、あなたのワークロードに適したプロバイダーを選ぶための評価ルーブリックを提供します。

クイックスタート：OpenAI SDK ですべてのプロバイダーにアクセス

Synthorai は OpenAI 互換のエンドポイントを公開しています——公式の openai SDK をそこに向けるだけで、すべてのモデル（Claude、GPT、Gemini、DeepSeek、Qwen）が 1 行のモデル切り替えになります。ゲートウェイは cache_control を各プロバイダーのネイティブなキャッシュ構文に変換します。

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 フィールドだけです。ゲートウェイはプロンプトキャッシュヒットのメタデータを標準の OpenAI prompt_tokens_details.cached_tokens フィールドで返し、加えて USD での cost フィールドも返すので、ベンダーごとの料金表をローカルで維持する必要がありません。

FAQ

LLM プロンプトキャッシュはセマンティックキャッシュと同じですか？ いいえ。プロンプトキャッシュはプレフィックスベースです——プロンプト先頭の正確なトークンレベルの一致に対して K/V 値を再利用します。セマンティックキャッシュは意味レベルで（埋め込みを介して）一致させ、以前の応答を返します。どちらも有用で、優れた Token ゲートウェイはそれらを階層的に組み合わせます。

プロンプトキャッシュはモデルの出力を変えますか？ いいえ。K と V は入力トークンの決定論的関数です（§1.1）。モデルがキャッシュされた K/V から生成するロジットは、新規に再計算された K/V から生成するものと数学的に同一です。キャッシュは品質への影響がない純粋な効率最適化です。

なぜキャッシュ TTL はそんなに短いのか——ずっと保持できないのか？ KV キャッシュは巨大です（§1.4：70B モデルの 32K コンテキストで約 10 GB）。GPU メモリがボトルネックで、サーバーがそのメモリをアクティブなワークロードに必要とするたびにキャッシュは追い出されます。ディスクバックドキャッシュ（DeepSeek）は数時間生き延びられますが、インメモリキャッシュは通常それができません。

KV キャッシュとプロンプトキャッシュの違いは何ですか？ KV キャッシュは推論中に使われるインメモリのデータ構造です。「プロンプトキャッシュ」はその KV キャッシュのリクエスト横断での再利用です。上の §1.5 の第 1 層対第 2 層です。

キャッシュされたプロンプトが品質を劣化させる形で古くなることはありますか？ モデルの観点ではありません。あなたの内容の観点では、プロンプトが時間に敏感な情報をエンコードしているならあります。キャッシュは K/V ベクトルを保存するのであって、世界に関する事実を保存するのではありません。§3.1 を参照。

キャッシュヒット率はどう測定しますか？ すべてのプロバイダーが応答の usage オブジェクトでそれを返します——cache_read_input_tokens（Anthropic）、cached_tokens（OpenAI）、cached_content_token_count（Gemini）、prompt_cache_hit_tokens（DeepSeek）。これらをロギングパイプラインで追跡してください。

参考文献と出典： 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 architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← ブログに戻る