最も安い LLM のプロンプトキャッシュはどれか？ 5 プロバイダーを比較（2026 年版）

TL;DR — 主要 5 社の LLM プロンプトキャッシュは、Claude の明示的マーカー、GPT-5.x と DeepSeek-v4 の完全自動方式、Gemini と Qwen の暗黙的方式と明示的方式を併用するハイブリッド、DeepSeek の MLA によるディスク永続化など、仕組みが大きく異なります。この記事では機能を項目別に比較し、コスト、ヒット率の予測可能性、レイテンシ、TTL との相性、API の使いやすさという 5 つの評価軸で、実際のワークロードに合うプロバイダーを採点できるようにします。アーキテクチャの背景は第 1 部：キャッシュの原理、実測値と動作する Python コードは第 3 部：チュートリアルにまとめています。

シリーズ：全 5 部の第 2 部 · 前回：第 1 部 — キャッシュの原理 · 次回：第 3 部 — 動作するコードのチュートリアル · 第 4 部 — ユースケース別の最適な LLM · 第 5 部 — LangChain 連携

1. LLM キャッシュの分類

各プロバイダーを見る前に、4 つの設計軸を整理します。

1.1 制御方式：明示的、暗黙的、ハイブリッド

• 明示的 — 開発者がプロンプトのどの部分をキャッシュするか指定します。Anthropic Claude の cache_control が該当します。制御性は最も高い一方、コードの変更が必要です。
• 暗黙的または自動 — プロバイダーが一致する prefix を自動検出します。OpenAI GPT-5.x と DeepSeek-v4 が該当します。コード変更は不要ですが、ヒットを強制できません。
• ハイブリッド — 両方の方式を利用でき、呼び出しごとに選択します。Gemini と Qwen が該当します。

1.2 永続化方式：インメモリとディスク

これは API の仕様ではなく、プロバイダーの KV cache アーキテクチャで決まります。

• インメモリ（HBM） — キャッシュを GPU メモリに保持します。保持時間は数分と短く、最小単位も 1,024 token と大きめです。多くのプロバイダーがこの方式を採用しています。
• ディスク永続化 — キャッシュを SSD または NVMe に保存します。TTL が大幅に長く、粒度も細かくなります。DeepSeek はこの仕組みを大規模に運用しています。KV cache を約 4 分の 1 に圧縮する Multi-head Latent Attention（MLA）によって実現したものです（DeepSeek-AI、2024）。

1.3 粒度：一致判定の単位

どれほど短い prefix から割引対象になるかを示します。

• 64 token — DeepSeek。業界で最も細かい単位です。
• 128 token — OpenAI の一致判定単位です。
• 1,024 token — Claude、OpenAI、Gemini、Qwen でキャッシュ可能になる最小単位です。

粒度が細かいほど、prefix の一部だけが一致した場合も対象になります。プロンプトに小さな変更が入ってもキャッシュが効きやすくなります。

1.4 オブジェクトモデル：呼び出し単位のマーカーと名前付きキャッシュオブジェクト

• 呼び出し単位のマーカー — リクエストのたびにキャッシュ対象のコンテンツを埋め込み、プロバイダー側でハッシュ化します。Claude、OpenAI、DeepSeek、Qwen の暗黙的方式が該当します。
• 名前付きキャッシュオブジェクト — 開発者が別の API 呼び出しでキャッシュを作成し、cache_id を受け取って後続のリクエストから参照します。Gemini と Qwen の明示的方式が該当します。手順は増えますが、ライフサイクルを明示的に制御できます。

この 4 つの軸は互いに影響します。各プロバイダーのキャッシュは、これらの軸上の位置で説明できます。次のセクションでは、プロバイダーごとに詳しく見ていきます。

2. プロバイダー別の詳細

2.1 Anthropic Claude — 明示的、インメモリ、1,024 token 単位

主要モデル（2026-05）： claude-haiku-4-5、claude-sonnet-4-5 / 4-6、claude-opus-4-5 / 4-6 / 4-7。

GPT-5.6 の更新（2026-06）： GPT-5.6 ファミリーでは、以下のルールが変更されています。キャッシュ書き込みは入力料金の 1.25x となり、安定して一致させるには prompt_cache_key が必須になりました。また、TTL が 30 分の明示的な breakpoint も追加されています。この記事の表は GPT-5.5/5.4 の挙動を示しています。5.6 については GPT-5.6 のコストガイドと実測したキャッシュの最小単位を参照してください。

キャッシュ API。 system または messages 配列内の任意の位置に、最大 4 つの cache_control breakpoint を指定できます。キャッシュヒット時の料金は通常入力料金の約 10% です。書き込みは 125% で、25% の上乗せがあります。デフォルト TTL はスライディング方式の 5 分で、ヒットするたびに延長されます。1 時間も選択できます。

料金体系。 Anthropic はモデルごとの 100 万 token あたりの料金を料金ページで公開しています。キャッシュ割引率はファミリー全体で共通です。claude-sonnet-4-5 で 8,000 token の system prompt を 1 日 100K 回呼び出す場合、prefix が warm になった後の 1 回あたりのコストは約 8 分の 1 から 10 分の 1 になります。1 回ヒットすれば損益分岐点を超えます。

TTL の挙動。 デフォルトはスライディング方式の 5 分です。ヒットするたびに有効期限がさらに 5 分延びます。1 時間 TTL では書き込みコストが 2 倍になりますが、アイドル時間が 5 分を超えるワークロードでは欠かせません。

粒度。 最小 1,024 token です。完全に同一の token 列に対してハッシュを計算するため、先頭の 1 文字が変わるだけでも prefix 全体が無効になります。

API の使いやすさ。 最も優れています。複数の breakpoint を使い、変更されない部分、変更頻度が低い部分、タスクごとに変わる部分を個別にキャッシュできます。プロンプト内の各セクションが異なる周期で変わる agent や RAG ワークロードでは、特に有効です。

注意点。

• cache_control を付け忘れると、キャッシュは一切使われません。GPT や DeepSeek と異なり、暗黙的な fallback はありません。
• tool または function 配列内でも、キャッシュのハッシュは順序に依存します。順序が常に一定になるよう sort してください。
• デフォルト TTL が 5 分のため、明示的な keep-alive がない断続的な batch job には不向きです。
• gateway 経由で Claude を呼び出す場合は、cache_control マーカーを扱える Anthropic ネイティブの /v1/messages path に gateway が対応しているか確認してください。OpenAI 互換の /chat/completions path では通常、マーカーが転送されません。gateway の base URL を指定した Anthropic SDK を使用してください。

適した用途。 長いコンテキストを使う agent、安定した system prompt を持つ multi-turn chat、階層化キャッシュを使う構造化 RAG。

2.2 OpenAI GPT-5.x — 自動、インメモリ、1,024 token 単位

主要モデル（2026-05）： gpt-5.4-nano、gpt-5.4-mini、gpt-5.2、gpt-5.4-pro、gpt-5.5-pro。コード向けの Codex バリアントは gpt-5.2-codex、gpt-5.3-codex です。

キャッシュ API。 何もする必要はありません。1,024 token 以上のすべてのリクエストで自動的に有効になります。キャッシュヒット時の料金は入力料金の 50% で、書き込みの上乗せはありません。一致判定は 128 token 単位です。

料金体系。 OpenAI は 100 万 token あたりの料金を料金ページで公開しています。キャッシュされた入力は 50% 割引で、出力料金は変わりません。

実測値（2026-05-25、system prompt は約 6,900 token）：

* gpt-5.4-mini では、hit 測定時の completion が miss 測定時より大幅に短くなりました。このコスト差には、キャッシュ割引と completion 長の変動が混在しています。レイテンシが 5 分の 1 になった点（3.63 → 0.73 s）のほうが、キャッシュ効果を明確に示しています。

TTL の挙動。 正確な値は公開されていません。現場からの報告では、負荷と prefix の利用頻度に応じて 5 分から 60 分程度とされています。多くのリクエストで共有される prefix は、LRU で優先されるため長く残ります。

API の使いやすさ。 非常に簡単です。既存コードをそのまま使えます。ヒット率を測るには prompt_tokens_details.cached_tokens をログに記録します。

注意点。

• ヒットを強制する方法はありません。トラフィック内の prefix が毎回異なる場合、キャッシュの効果はありません。
• 50% の割引率は、Claude の 90% や DeepSeek の 75% より小さくなります。Gemini の暗黙的方式は約 25% です。
• streaming では、最後の chunk でのみキャッシュヒットが報告される場合があります。計測時は注意し、stream_options={"include_usage": True} を指定してください。

適した用途。 追加実装のコストがわずかな節約額を上回る、既存の GPT コードベース。prefix の繰り返しが自然に多くなる burst 型トラフィック。

2.3 Google Gemini — ハイブリッド、インメモリ、名前付きキャッシュオブジェクト

主要モデル（2026-05）： gemini-2.5-flash、gemini-2.5-pro、gemini-3-flash-preview、gemini-3.1-pro-preview、gemini-3.1-flash-lite-preview。

キャッシュ API。 2 つの方式があります。

• 暗黙的方式：GPT と同じ自動方式です。キャッシュされた token は入力料金の約 25% です。ストレージ料金も事前設定もありません。
• 明示的方式：別の API 呼び出しで cachedContent オブジェクトを作成します。後続のリクエストでは、その名前を指定します。キャッシュされた token の料金は約 10% と安くなりますが、100 万 token あたりの時間単位のストレージ料金が発生します。

料金体系。 Gemini の強みは長いコンテキストです。料金はコンテキスト長の区分に応じて変わり、200K 未満と 200K 超では後者の token 単価が高くなります。

実測値（2026-05-25）：

TTL の挙動。 暗黙的方式は数分ですが、正確な値は公開されていません。明示的方式は開発者が指定でき、デフォルトは 1 時間、最長 24 時間です。

API の使いやすさ。 明示的キャッシュでは、作成してから参照する 2 段階のフローが必要です。cachedContent の作成、TTL の更新、削除といったライフサイクルは、自分で管理します。

注意点。

• リクエスト量が少ない明示的キャッシュでは、ストレージ料金が大きな負担になります。 必ず呼び出し頻度に応じた損益分岐点を計算してください。
• 暗黙的キャッシュのヒット率は変動します。コスト見積もりの前提にはできません。
• キャッシュオブジェクトは region に固定されます。multi-region アプリでは region ごとにキャッシュを作る必要があります。
• gemini-*-pro は reasoning model です。max_tokens が小さいと、completion の枠を内部の thinking で使い切り、completion_tokens=0 になる場合があります。ユーザー向けの path では max_tokens を 256 以上に設定してください。

適した用途。 1 時間に 10 回以上問い合わせる 20K token 超の大きな文書。動画 Q&A。企業の PDF を対象とした multi-modal RAG。

2.4 DeepSeek-v4 — 自動、ディスク永続化、64 token 単位

主要モデル（2026-05）： deepseek-v4-flash（汎用）。この世代では coder ワークロードにも deepseek-v4-flash を使用します。

キャッシュ API。 GPT と同様に自動です。ただし、MLA 圧縮によってキャッシュを十分に小さくし、ディスクへ永続化しています。キャッシュヒット時の料金は入力料金の約 25% で、書き込みの上乗せはありません。最小一致単位は 64 token です。

料金体系。 DeepSeek の料金ページでは人民元建ての料金が公開されています。ヒットした入力コストは約 75% 削減されます。

実測値（2026-05-25）：

TTL の挙動。 数時間です。利用頻度の高い prefix では、さらに長く残る場合があります。ディスクに永続化するため、他社のインメモリキャッシュなら eviction されるような GPU メモリ負荷でも、キャッシュが維持されます。

粒度。 最小単位の 64 token は業界で最も細かい値です。プロンプトを少し編集しても prefix の大部分は一致したままです。最小単位が 1,024 token のプロバイダーのように、全体が無効になることはありません。

API の使いやすさ。 OpenAI 形式の API なので、base URL を差し替えるだけです。標準の prompt_tokens_details.cached_tokens field を使用します。

注意点。

• 利用できるのは DeepSeek ファミリーのモデルだけです。このキャッシュを他のモデルファミリーでは使えません。
• 英語の品質は優れていますが、最難関の reasoning benchmark では Claude や GPT-5.x に及びません。

適した用途。 コストを重視する中国語ワークロード。粒度が重要になる、同じ prefix を高頻度で使うワークロード。たとえば retrieval 順序が安定しない RAG が該当します。コスト重視の batch job にも適しています。

2.5 Alibaba Qwen3 — ハイブリッド、インメモリ、名前付きキャッシュオブジェクトと暗黙的方式

主要モデル（2026-05）： qwen3-max、qwen3.5-plus、qwen3.5-flash。vision バリアントは qwen3-vl-plus、qwen3-vl-flash です。

キャッシュ API。 2 つの方式があります。

• 暗黙的方式：GPT と同様に常時有効です。キャッシュされた部分の料金は入力料金の約 20% です。
• 明示的方式：任意の TTL を指定し、API でキャッシュを作成します。ヒット時の料金は約 10%、書き込みは 125% です。

実測値（2026-05-25）：

TTL の挙動。 デフォルトは 5 分で、キャッシュオブジェクトごとに設定できます。明示的方式はスライディング方式、暗黙的方式は短い固定 TTL です。

API の使いやすさ。 暗黙的方式は GPT 形式で、追加作業はありません。明示的方式では 2 段階のフローとキャッシュのライフサイクル管理が必要です。

注意点。

• 現時点で明示的キャッシュに対応しているのは qwen3-max と qwen3.5-plus だけです。
• Singapore と US への multi-region 展開は進行中です。中国国外のデータで利用する場合は、事前に region を確認してください。
• Anthropic や OpenAI と比べてドキュメントに不足があります。実測による確認を推奨します。

適した用途。 キャッシュを細かく制御したい中国企業のワークロード。すでに Alibaba Cloud を利用している顧客。

3. 横並び比較

3.1 割引体系（各社のドキュメント、2026-05）

3.2 TTL、粒度、永続化

3.3 7K token の prefix における実測レイテンシ（2026-05-25）

† Claude の行は、Anthropic ネイティブの /v1/messages endpoint で cache_control マーカーを使って測定しています。詳しくは第 3 部 §2を参照してください。Claude の最大の利点はコストで、入力料金が約 88〜89% 安くなります。完全なコスト表は第 3 部 §2に掲載しています。Anthropic の公開値によると、100K token を超えるプロンプトでは TTFT の改善幅が大きく伸びます。

同時負荷のない、単一の逐次実行で測定しています。region、時間帯、他 tenant の負荷によって結果は変動します。

4. 5 つの評価軸

「Claude なら 90% 節約できる」といった数字だけでは、実際に何を選ぶべきか判断できません。以下の 5 項目について、自分のワークロードに合わせて各プロバイダーを採点し、重要度に応じて重み付けしてください。

4.1 ヒット率で加重した 100 万 token あたりの実効コスト

基本料金ではなく、実際のヒット率に基づく期待コストを比較してください。LLM コスト計算ツールに数値を入力するか、プロバイダー横断の最新の LLM 料金比較を確認できます。

effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate

prefix の繰り返し率が 70% の場合の計算例です。一般的な chatbot を想定しています。

• Claude：90% の割引 × 0.7 の hit ＋ 25% の write × 0.3 → 実効コスト ≈ 基本料金 × 0.45
• GPT-5.5：50% × 0.7 ＋ 0 → 実効コスト ≈ 基本料金 × 0.65
• Gemini の暗黙的方式：75% × 0.7 ＋ 0 → 実効コスト ≈ 基本料金 × 0.48
• DeepSeek-v4：75% × 0.7 ＋ 0 → 実効コスト ≈ 基本料金 × 0.48

比較可能な金額を出すには、各社で異なる実際の基本料金を掛けます。評価方法は、自分のワークロードで effective_cost を計算し、低いほど高評価とします。

4.2 ヒット率の予測可能性

• 明示的キャッシュ（Claude、Qwen の明示的方式、Gemini の明示的方式）— 予測可能性が高い方式です。指定した部分は、TTL 内ならヒットします。
• 自動キャッシュ（GPT-5.x、DeepSeek-v4、Gemini の暗黙的方式、Qwen の暗黙的方式）— prefix の類似度とプロバイダー側の負荷による LRU eviction の両方に左右されます。

コストに連動する SLA があるなら、明示的方式を選びます。best-effort の最適化で十分なら、自動方式でも問題ありません。

4.3 TTL とトラフィック間隔の相性

4.4 キャッシュ miss 時のレイテンシ

hit 時は速くても、miss 時に遅いプロバイダーは、ヒット率が高くなければ問題になります。§3.3 の両方の値を比較し、想定ヒット率で重み付けしてください。

4.5 API の使いやすさと移行コスト

• 移行コストが最も低い：GPT-5.x ↔ DeepSeek-v4。どちらも OpenAI 形式で、自動キャッシュです。
• 中程度：GPT-5.x → Gemini の暗黙的方式。SDK は異なりますが、キャッシュ用コードの書き換えは不要です。
• 高い：GPT-5.x → Claude。cache_control を追加し、プロンプトを階層化する必要があります。
• 最も高い：gateway を使わず、単一プロバイダー構成から multi-provider 構成へ移行する場合。複数のキャッシュ API を扱う必要があります。

5. ワークロード別の簡易評価

6. 移行時の考慮事項

採点の結果、切り替えることになった場合は、次の 3 点を計画してください。

データ移行。 キャッシュされた prefix はプロバイダー間で移行できません。切り替え直後は必ず cold start になります。warm-up 中の数時間は、通常よりコストが高くなる前提で予算を組んでください。

プロンプトの再設計。 Anthropic の複数 breakpoint を前提とした設計では、プロンプトを階層化します。この構造は他のプロバイダーにも有効です。一度リファクタリングすれば、Claude 以外の path にも効果があります。

gateway を使った hedging。 判断がつかない場合は、Token Gateway 経由で routing します。特定の vendor に固定されずに選択肢を残せます。代わりに hop が 1 つ増え、gateway によっては vendor 固有のキャッシュ制御を使えなくなる可能性があります。Synthorai gateway が実際に行う処理と、慎重に判断すべき主張については第 3 部 §9を参照してください。

7. 時間とともに変わる点

この比較の数値は、今後変わります。キャッシュは価格競争の対象になっており、各プロバイダーは数か月おきにサービス内容を更新しています。注目すべき点は 2 つあります。

• TTL の延長。 Anthropic の 1 時間オプションは GA です。Gemini は数日まで延長される可能性があります。TTL の短さは徐々に問題にならなくなるでしょう。
• 粒度。 OpenAI と Anthropic は、将来的に 1,024 token という最小単位を引き下げる可能性があります。DeepSeek の 64 token が新しい基準になりました。

割引率が横並びになれば、差がつくのは API の使いやすさとレイテンシです。公称の割引率ではありません。

次回：第 3 部 — プロンプトキャッシュのチュートリアル：動作する Pythonでは、上記のアーキテクチャを実行可能なコードに落とし込みます。§3.3 のレイテンシ表も、自分で実行できる benchmark として再現します。

FAQ

総合的に見て、プロンプトキャッシュが最も安い LLM プロバイダーはどこですか？ ヒット率が同じ約 75% なら、2026-05 の実測では、中国語ワークロードは deepseek-v4-flash、英語ワークロードは暗黙的キャッシュを使う gemini-2.5-flash が、100 万 token あたりの実効コストで最安です。claude-sonnet-4-5 は 1 回の呼び出しに対する割引率が約 90% と最も大きい一方、基本料金も高めです。ヒット率が 85% を超える場合に有利になります。自分のヒット率を §4.1 の式に代入してください。

リクエスト量が少ないワークロードで、Gemini の料金が高くなるのはなぜですか？ 明示的キャッシュには時間単位のストレージ料金がかかります。キャッシュへの問い合わせ頻度が低いと、割引分をストレージ料金が上回ります。リクエスト量が少ない場合は、ストレージ料金がなく約 25% 割引される Gemini の暗黙的キャッシュを使ってください。

Claude の cache_control を OpenAI で使えますか？ 直接は使えません。別々のキャッシュ実装です。OpenAI 互換の /chat/completions endpoint では、Anthropic 以外のモデルに対してこの field を指定しても、通常は何も起きません。それらのモデルは自動的にキャッシュします。Claude では、マーカーを付けて Anthropic ネイティブの /v1/messages endpoint を使用してください。

DeepSeek の MLA アーキテクチャは独自技術ですか？ 論文（DeepSeek-AI 2024）は公開されています。他のプロバイダーも MLA 方式の KV 圧縮を採用できますが、base model の再学習が必要です。runtime で切り替えられる機能ではありません。2026-05 時点では、本番環境で提供している大手プロバイダーは DeepSeek だけです。

オープンソースの self-hosted モデルはどうですか？ vLLM、SGLang などの inference engine は、prefix caching をネイティブにサポートしています。その基礎になったのが PagedAttention の論文です。H100 または H200 で self-host する場合、LMCache などを使ってディスク永続化キャッシュを実装できます。この記事の料金分析は managed service だけを対象としています。self-hosted のコスト構造はまったく異なります。router を自前で運用せずに multi-provider routing を使うなら、managed 型 LiteLLM の代替サービスを利用すると、キャッシュを維持したまま同じプロバイダーを 1 つの API で扱えます。どの open-weight model がどこでキャッシュに対応し、どの host が製品として提供しているかは、open-weight LLM のプロンプトキャッシュにまとめています。

この比較に Mistral、Cohere、Llama API プロバイダーが含まれていないのはなぜですか？ 2026-05 時点では、キャッシュ機能が十分に成熟していないためです。Mistral のキャッシュは early access、Cohere は明示的キャッシュを公開していません。Llama API プロバイダーの Groq、Together、Replicate はサービスごとの差が大きい状態です。機能が安定した時点で再評価します。

出典：Anthropic のプロンプトキャッシュ · OpenAI のプロンプトキャッシュ · Google Gemini のコンテキストキャッシュ · DeepSeek の KV cache · Alibaba Bailian のコンテキストキャッシュ · DeepSeek-V2 / MLA 論文 · PagedAttention / vLLM（Kwon et al. 2023）。実測値は 2026-05-25 に https://synthorai.io/v1 で取得。

← ブログに戻る