LLM Prompt Cachingの経済性：GPUを購入する前に測定する

LLM prompt cachingは、繰り返し利用するコンテキストにおいて、プレミアムAPIを、十分に使われていないローカルGPUより安くできる場合があります。一方で、まったく節約にならないこともあります。決定要因はモデルの定価ではありません。プレフィックスの再利用、キャッシュ書き込みコスト、読み取り割引、期限切れ、エビクション、利用率、そして失敗した作業のコストです。

対象読者： LLMプラットフォームのコスト、レイテンシ、またはインフラストラクチャの意思決定を担う上級実務者。

実務上のルールは次のとおりです：GPU容量を購入する前に、実際のワークロードでキャッシュ読み取りと無効化を測定すること。 新しいエンタープライズ向けコーディングエージェントのケーススタディは、99.3%という印象的なキャッシュヒット結果によってこの点を示しています。しかし著者らが調査したのは、1人の開発者、連続した2つの28日間、異なるモデルファミリー、そして1つの本番コードベースです。この論文は、クラウド対ローカルの結論ではなく、測定を始めるきっかけとして扱ってください。

LLM prompt cachingが変えるもの

LLMは、入力を大きく2つの段階で処理します：

サービング層では、prefix cachingによって、プロンプトのプレフィックスに対する再利用可能なattentionまたはkey-value stateを保存できます。同じ対象プレフィックスを持つ後続リクエストは、繰り返し発生するprefill処理の一部をスキップできます。変化するサフィックスは引き続き処理する必要があり、モデルは新しい回答をdecodeします。

この区別は重要です。Prompt cachingはresponse cachingではありません。保存済みの回答を返すものでも、出力を短くするものでも、弱いプロンプトを修正するものでも、エンドツーエンドのレイテンシ低下を保証するものでもありません。主な対象は、繰り返される入力計算であり、多くの場合、time to first tokenを改善します。

元のPrompt Cache論文は、再利用可能なプロンプトモジュールを定式化し、プロトタイプにおけるtime-to-first-tokenの改善幅として、GPUで8倍、CPUで60倍を報告しました。これは論文でテストされたモデル、ハードウェア、プロンプト、実装における結果であり、現在の商用APIの予測ではありません。

99.3%のケーススタディ：有用な証拠だが、適用範囲は狭い

2026年7月のプレプリント、*Inference Economics of Enterprise Coding Agents*は、1つの本番monorepoにおける連続した2つの28日間を比較しました：

著者らはLLMのテレメトリとGit履歴を分析しました。API期間について、99.3%のprompt-cache hit rate、処理済みトークン100万個あたり0.573ドルの実効APIコスト、共有オンプレミス割り当てについて、償却後の単位コスト2.83ドルを報告しました。APIは16.9倍多くのトークンを処理しましたが、ローカルハードウェアの利用率は低かったため、これらの正規化されたトークン価格だけではインフラストラクチャの問題は決まりません。

総コストの結果は、割り当てによって異なる方向を示しています。論文の台湾市場および人件費の前提では、共有ローカル容量によって推定total cost of ownershipが40.1%削減されました。一方、専用ローカル予約は、キャッシュされたAPIより43.8%高くなりました。ローカル期間では、修正コミット比率も高く、74.9%対45.9%でした。

著者らが測定したもの

著者らが推論したこと

この研究で確立できないこと

設計は無作為化されておらず、連続的に実施されました。期間の間に、コードベース、開発者、タスク構成、作業方法が変化した可能性があります。モデルの能力、サービングスタック、ハーネス、量子化が同時に変わっています。第一著者は仮説を知っていました。fix-commitラベルは代理指標であり、独立した欠陥監査ではありません。本番の生テレメトリと完全なリプレイ環境は公開されていません。

持続的な結論は、見出しの数値よりも限定的です：プロンプトの再利用とGPU利用率は定価比較を左右し得る一方、修正作業はトークン節約を上回る可能性があります。

ヒット率を計算する前に測定契約を定義する

分母を明示しない「cache hit rate」は曖昧です。あるダッシュボードは、キャッシュされたトークンを対象プレフィックスのトークンで割るかもしれません。別のダッシュボードは、何らかのcache readがあったリクエストを全リクエストで割るかもしれません。さらに別のものは、キャッシュされていないサフィックスを含む入力全体に対するキャッシュ済みトークンの割合を報告するかもしれません。

次の指標を分けて使用してください：

現在のAPIとself-hostedの挙動は一様ではない

以下のスナップショットは2026年7月30日に確認したものです。調達や請求に使用する前に、リンク先のドキュメントを再確認してください。

OpenAIの現在のモデルガイダンスは、explicit writeがキャッシュされていない入力より高価であるため、GPT-5.6のユーザーにcache writeとreadを監視するよう伝えています。Anthropicのprompt-cachingドキュメントは、5分間のwriteが基本入力の1.25倍、1時間のwriteが2倍、cache readが0.1倍であることを説明しています。Googleのcontext-cachingガイドは、Interactions APIではimplicit cachingが自動的に行われ、使用量にキャッシュ済みトークンが報告されると説明しています。vLLMのAutomatic Prefix Cachingの例は、self-hosted engineにおける同じ共有プレフィックスの考え方を示しています。

これらの実装は原則を共有していますが、移植可能な請求契約を共有しているわけではありません。プレフィックスの最小長、キャッシュのスコープ、保持期間、ストレージ料金、使用量フィールド、分離方法は異なる可能性があります。

*インフラストラクチャを変更する前にキャッシュを測定しましょう：プレフィックスを安定させ、coldとwarmのテストを実行し、強制的に無効化したうえで、総コストを比較します。*

再利用可能なプレフィックスの損益分岐式

次のように定義します：

ストレージ料金を無視すると、リクエスト1件あたりの再利用可能なプレフィックス料金の平均は次のとおりです：

`(W + (N - 1) × R) / N`

キャッシュを利用する方が、そのプレフィックスをキャッシュなしで処理するより安くなる条件は次のとおりです：

`N > (W - R) / (U - R)`

この式は、再利用可能なプレフィックスを分離します。変化するサフィックス、出力トークン、キャッシュ可能な最小長、ストレージ料金、エビクションによるミス、同時実行の影響、エンジニアリング工数、失敗タスクは含みません。

日付を付けた一例として、2026年7月30日時点のAnthropicの5分間の倍率は`U = 1`、`W = 1.25`、`R = 0.1`でした。入力のみを考えた閾値は`N > 1.28`であり、対象プレフィックスについては、キャッシュの有効期間内での2回目の利用によって高い書き込み料金が償却されます。ただし、APIを合計2回呼び出せばキャッシュが利益を生むという意味ではありません。短いプレフィックス、長いキャッシュされないサフィックス、キャッシュミス、高価な出力によって、節約分が消える可能性があります。

この式をコストモデルの単体テストとして使用してください。すべての変数を、現在のプロバイダー契約と測定したワークロードの値に置き換えます。

一見安定しているプロンプトがキャッシュミスになる理由

ほとんどのミスはモデルではなく、プロンプト構築から始まります。

変動データが早すぎる位置にある

タイムスタンプ、リクエストID、ランダムなnonce、ユーザー名、新しい検索結果が先頭付近にあると、その後に続くすべてのトークンが変わります。安定したtools、ポリシー、テンプレート、再利用可能なドキュメントを先に置いてください。リクエスト固有のデータは、再利用可能なプレフィックスまたはexplicit breakpointの後に移動します。

リクエスト間でシリアライズが変わる

JSONのキー順、空白、toolの順序、ドキュメントの順序によって、意味的には同等のプレフィックスが変わることがあります。決定論的なシリアライズを使用してください。意味上許される場合は、tool定義と取得したドキュメントを安定した識別子でソートします。

コンテキストマネージャーがプレフィックスの連続性を壊す

積極的なpruningは入力トークンを節約できますが、キャッシュされたプレフィックスを無効化する可能性があります。2026年6月の作業中プレプリントであるTokenPilotは、これを共同最適化問題として扱っています。著者らは、コンテキストがタスク上の価値を失うまで取り込みを安定させ、エビクションを遅らせています。2つのベンチマークと2つの実行モードで、競争力のあるタスク性能を維持しながら、56%〜87%のコスト削減を報告しています。これらの結果には、論文のワークロードとLightMem2統合を超えた再現が必要です。

実際の負荷でキャッシュが期限切れまたはエビクションされる

モデルまたはテンプレートが変わる

モデルバージョン、tokenizer、chat template、画像のdetail設定、tool schema、安全性のpreambleが変わると、新しいプレフィックスが生成される可能性があります。リリースとプロンプト移行を、キャッシュ無効化イベントとして扱ってください。

現在のvLLMのエンジニアリング議論は、この圧力を示しています。context-aware retentionの提案は、同時実行されるagentワークロードが価値のあるプレフィックスをエビクションする可能性があると主張しています。一方、semantic KV-cacheの提案は、完全一致を超えた再利用を検討しています。これらはオープンな設計議論であり、本番環境での保証や導入測定ではありません。

再現可能なprompt-cacheテスト

1. 代表的なワークロードを固定する

本番トラフィックまたはプライバシーに配慮したリプレイセットから、30〜100個のタスクを選びます。プレフィックス長、サフィックス長、出力長、tools、ドキュメント、同時実行数の実際の分布を維持してください。テストを実行する前に、タスクの成功条件を定義します。

1つの長いデモ用プロンプトで最適化しないでください。キャッシュに適したサポートワークフローと、キャッシュに適さないリサーチワークフローでは、経済性が正反対になる可能性があります。

2. 安定したコンテンツと変動するコンテンツを分ける

各プロンプトセグメントにラベルを付けます：

決定論的なプロンプトアセンブラーを構築します。各リクエストが再利用を試みたプレフィックスを識別できるよう、opaqueなプレフィックスバージョンまたはkeyed hashを記録します。ログに秘密情報や顧客の生コンテンツを入れないでください。

3. 制御されたマトリクスを実行する

各タスククラスについて、次を測定します：

1つのレイテンシ値ではなく、分布を報告できるだけの反復回数を実行します。time to first tokenのp50とp95を、エンドツーエンドレイテンシから分けてください。

4. 請求と品質を同時に記録する

次を取得します：

完全一致するプレフィックスのstate再利用は、繰り返しのprefill計算を避けるはずですが、品質チェックを省略してよい理由にはなりません。モデル、量子化レベル、ルーティングポリシー、サービングスタックの変更は、キャッシュ機構自体が正しくても、出力品質を変える可能性があります。

5. 3つのコスト視点を計算する

ローカルの選択肢が継続的な利用率に依存するなら、その利用率の前提をテストしてください。スプレッドシートがアイドル時間をすべて将来需要に割り当てたからといって、GPU購入が経済的になるわけではありません。

Cloud API、ローカルGPU、それともhybrid routing？

この判断は、二者択一になることはほとんどありません。

キャッシュされたAPIを優先する場合

共有ローカル容量を優先する場合

hybrid routingを使用する場合

Prompt-cacheのセキュリティには独自のテストが必要

キャッシュはデータ依存のタイミングを生みます。再利用されたプレフィックスは、ミスの場合より速く最初のトークンを返す可能性があります。ICML 2025の監査は、タイミング測定を使って実際のAPIをテストし、調査期間中に7つのプロバイダーでユーザー間のキャッシュ共有を示す証拠を報告しました。

この結果は、過去のプロバイダー固有の証拠です。現在、各サービスがどのようにキャッシュを分離しているかを示すものではありません。

現在のプロバイダーと社内プラットフォームの責任者に、次を確認してください：

self-hostedシステムでは、tenant間のタイミングとエビクションのテストを含めてください。キャッシュをデバッグするためだけに、再利用可能な機密プレフィックスをログに記録しないでください。ハッシュ、トークン数、バージョン識別子、ポリシーに適合したメタデータを保存します。

意思決定チェックリスト

定価だけを根拠に、GPU購入やAPI移行を承認しないでください。次を必須にします：

Prompt cachingは、繰り返されるコンテキストが一般的であるため価値があります。しかし、再利用はワークロード固有であるため、調達の近道として使うのは危険です。プレフィックスを測定し、ミスを測定してから、総コストを比較してください。

Claim checks

Sources