LLMプロンプトキャッシュ：トークンを二重計上せずに節約額を計算する

プロンプトキャッシュは、同じ指示やコンテキストをLLMに繰り返し送信するコストを削減できます。削減額は、実際のキャッシュヒット、プロバイダーの課金区分、キャッシュされた内容が有効期限前に再利用される頻度によって決まります。

キャッシュ読み取りの低価格は、計算の一部にすぎません。書き込みには別の価格が設定される場合があり、出力tokenには引き続き料金がかかり、報告された入力合計にキャッシュ済みtokenがすでに含まれていることもあります。このガイドでは、有用な見積もりを作成し、使用量の記録と照合する方法を説明します。掲載する計算例では、明示的に仮定した価格を使用しており、実測されたアプリケーションの結果やプロバイダーの提供内容ではありません。

プロバイダーが実際にキャッシュするものを特定する

プロンプトキャッシュは、一般に再利用可能な入力コンテキストを対象とします。モデルを呼び出さずに、アプリケーションが以前保存した回答を返すこととは混同しないでください。

DeepSeekのコンテキストキャッシュのドキュメントでは、永続化されたプロンプトプレフィックス単位のマッチングについて説明されています。デフォルトで有効ですが、ベストエフォートで動作します。似て見えるリクエストでもヒットは保証されず、キャッシュされた入力は、以前の回答がそのまま返されることを意味しません。

アプリケーションでは、3つの仕組みを区別してください。

• プロバイダーのプロンプトキャッシュ: 推論サービスが対象となる入力処理を再利用し、独自の使用量区分で報告します。
• アプリケーションのレスポンスキャッシュ: アプリケーションが保存済みの結果を返し、モデル呼び出しを完全に回避できる可能性があります。
• 検索またはドキュメントのキャッシュ: アプリケーションが抽出や検索の作業を繰り返さずに済みますが、結果のテキストをモデルに送信する場合があります。

それぞれを個別に測定してください。そうしないと、ドキュメント検索の変更を推論の割引と誤認したり、レスポンスキャッシュのヒットをプロバイダーのキャッシュヒットとして数えたりする可能性があります。

入力を重複しない区分に分ける

推測した計算式ではなく、選択したendpointの使用量スキーマから始めてください。DeepSeekはprompt_cache_hit_tokensとprompt_cache_miss_tokensを報告します。他のAPIでは、異なるフィールドやネストされた内訳が公開される場合があります。

レスポンスが合計入力token 10,000を報告し、そのうちキャッシュ済みtokenが8,000の場合、残りの未キャッシュ入力は2,000です。10,000すべてを未キャッシュの料金で計算し、さらに8,000をキャッシュ済みの料金で加算すると、リクエストの一部を二重に計上することになります。

ヒットとミスの料金が別々に設定されているサービスでは、モデルtokenの基本的な見積もりは次のとおりです。

cost = miss_tokens / 1M × miss_rate + hit_tokens / 1M × hit_rate + output_tokens / 1M × output_rate

この計算式は、プロバイダーの定義と一致する場合にのみ使用してください。キャッシュの作成や保存が別途報告される場合は、それらの区分の料金を加算する前に突き合わせてください。キャッシュ書き込みの価格が別の区分を置き換える場合もあれば、追加料金となる場合もあります。この区別は料金表で確認する必要があります。

通貨、単位、model ID、プロバイダー、日付を計算のそばに記録してください。1,000 tokenあたりで示された数値を、100万tokenあたりの計算式にそのまま当てはめることはできません。

最初の書き込みとライフタイムを含める

Kimiの推論課金ガイドでは、K3のキャッシュ書き込みを有効期間で区別し、5分と1時間の2つのカテゴリを設けています。キャッシュヒット時の入力はヒット価格で課金され、キャッシュ書き込みの追加課金はありません。これは直接プラットフォームのルールであり、ゲートウェイが同じ会計処理を行う証拠ではありません。

有用な問いは、キャッシュエントリが有効な間に、プレフィックスが何回再利用されるかです。100万トークンのプレフィックスに対する、次の仮想的な課金体系を考えてみます。

課金	想定価格
キャッシュせずにプレフィックスを処理	1回の使用につき$1.00
最初のキャッシュ書き込み（通常の入力課金を置き換え）	$1.25
以降の各キャッシュ読み取り	$0.10

キャッシュなしで5回使用すると$5.00です。1回の書き込みと4回の読み取りでは$1.65となり、そのプレフィックスで67%オフになります。使用が1回だけの場合は、キャッシュ経由のほうが高くなります。$1.00ではなく$1.25です。

書き込みが通常の入力課金を置き換えるという前提が重要です。実際のプロバイダーが書き込みを追加で課金する場合、計算式は変わります。これらの価格は方法を説明するためのものであり、現在のKimiやcheapaimodelの見積もりではありません。

この置き換え型の体系では、write_cost + (uses − 1) × read_costとuses × ordinary_costを比較します。次に、実際の有効期間内で想定される使用回数について計算を繰り返します。すべてのリクエストがエントリの有効期限切れ後に到着するなら、安い読み取りは役に立ちません。

リクエスト全体で節約額を計算する

入力の割引は、最終的な請求額に対する同じ割合の割引ではありません。キャッシュなしのワークロードで、入力課金が$10、出力課金が$20だとします。その入力の80%がキャッシュヒットになり、読み取りは通常の入力料金の10%で、追加の書き込み課金はないと仮定します。

新しい入力課金は、ミス分の$2とヒット分の$0.80を合わせて$2.80です。合計は$30ではなく$22.80となり、キャッシュ部分の料金が90%オフでも、全体では24%オフになります。

長い回答、推論の出力、ツール呼び出し、リトライ、ストレージによって、合計はさらに変わります。目に見える最終回答だけを数えるのではなく、endpointが報告する課金対象の使用量を使用してください。現在のモデル料金については、まず料金比較を確認し、そのうえで自分の使用量の構成を当てはめてください。

役立つ測定を設計する

同じ条件どうしで比較できるよう、十分な情報を収集します。

• モデルとプロバイダーのルート、リクエスト時刻、関連する設定。
• 報告される場合は、総入力、キャッシュヒット、キャッシュミス、キャッシュ作成、出力。
• 個別に課金されるサービスと、アカウントに記録された請求額。
• 結果がアプリケーションの受け入れ基準を満たしたかどうか。

トークンで重み付けしたヒット率を計算します。総ヒットトークンを、対象となる総入力トークンで割ります。小さなリクエストと大きなリクエストが同じ重みになると、リクエストごとの割合の平均は誤解を招くことがあります。

プロンプト構造を変更するときは、タスク固有の内容より先に、安定した指示と再利用可能なコンテキストを配置するとよい場合があります。ヒット率を上げるためだけにセキュリティ指示を並べ替えたり、必要なコンテキストを削除したりしないでください。プロンプト構造を変更した後は、出力品質を検証してください。

スケールする前に突き合わせる

使用量レコードの小さなサンプルを、プロバイダーの請求ビューと比較します。請求書が誤っていると判断する前に、欠落しているカテゴリ、丸め、料金計算の期間の違い、書き込み料金やツール料金を調査してください。

cheapaimodelは、入力、出力、キャッシュ読み取りの料金を料金ページで公開しています。3列の小計を完全な請求書とみなす前に、対象モデルの書き込み料金やその他の課金ルールを確認してください。K3固有の違いについては、Kimi APIガイドをご覧ください。

有用な成果は、承認された結果あたりのコストが下がることです。キャッシュされたtoken数が増えただけでは、アプリケーションが安くなったとも、より効果的になったとも言えません。