単位
1. LLM API の基礎: リクエスト、レスポンス、メッセージの役割 2. トークンと価格設定のロジック 3. ストリーミングと長い応答 4. システムプロンプトとモデルパラメータ 5. モデルの選択: 適切なジョブに適切なモデル 6. コストの最適化: 即時キャッシュ 7. バッチおよび非同期ワークロード 8. 速度制限と回復力のあるエラー管理 9. 安全なキー管理とプライバシー 10. 自動化統合: n8n、Zapier、Make 11. エンドツーエンドの生産: 検証、監視、倫理
ユニット 6 / 11

コストの最適化: 即時キャッシュ

利益:

  • プロンプト キャッシュのプレフィックス マッチング ロジックを説明する
  • 固定コンテキストを最初に配置し、変数コンテキストを後に配置することで、キャッシュ ヒットが増加します。
  • キャッシュの書き込み/読み取りの経済性と損益分岐点を計算できます

LLM 製品はプロトタイプでは安っぽく見えます。体重計に上がると、その請求額には驚かされます。ほとんどのワークロードでは、請求のほとんどは、長いシステム プロンプト、ルールブック、リファレンス ドキュメントなど、各リクエストで何度も送信される同じ固定コンテキストから発生します。即時キャッシュにより、まさにこの無駄が排除されます。この単元では、キャッシュがどのように機能するか、プロンプトがヒットするように調整する方法、およびキャッシュ エコノミーの損益分岐点を計算する方法を学習します。正しく設置されていれば、それだけで料金を半分以下に抑えることができます。

キャッシュはどのように機能しますか?不変の 1 つのルール

プロンプト キャッシュはプレフィックス マッチです。プロバイダーは、プロンプトの開始以降に処理したトークンを一時的に保管します。次のリクエストでプロンプトが同じプレフィックスで始まる場合、この共通部分は再計算されません。キャッシュよりも読み取りの方がはるかに安価です。

これから 1 つの不変ルールが導き出されます。プレフィックス内のどこかで 1 バイトが変更されると、その時点からキャッシュ全体が無効になります。つまり、固定コンテンツは先頭にあり、可変コンテンツは最後にある必要があります。システム プロンプトの先頭に、「今日の日付: 18.07.2026」など、リクエストごとに変更される行を入れると、その後ろにあるものはすべてキャッシュに入れることができなくなります。

通常、処理順序は、ツール → システム プロンプト → メッセージです。キャッシュ ポイント (ブレークポイント) は、固定セクションの最後に配置します。

キャッシュエコノミー

キャッシュには 3 つの価格帯があります。

  • キャッシュ書き込み：初めて保存します。通常の入力価格の ~1.25 倍 (5 分間の保管の場合)。
  • キャッシュ読み取り: 後続のリクエストで読み取ります。通常の投入価格の約 0.1 倍、つまり 10 分の 1 です。
  • 通常入力: キャッシュに入れられず、毎回フルコストで処理される部分。

損益分岐点: 最初のリクエストには書き込みプレミアム (1.25 倍) が支払われます。 2 番目のリクエストから、読み取り値 (0.1x) が機能します。おおよそ、2 つのリクエストでは互角になります。後は純貯蓄です。固定コンテキストが大きくなり、それが再利用されるリクエストが増えるほど、ゲインも大きくなります。

シナリオ

キャッシュは機能しますか?

大規模な固定システム プロンプト、数千のリクエスト

はい - 最高の収益

同じ参考ドキュメントに関する多くの質問

はい

リクエストごとに完全に異なる短いテキスト

いいえ - 書き込みボーナスは無駄になります

1回限りのリクエスト

いいえ — まったく読みません

システムプロンプトでのリクエストごとに変更される日付/ID

いいえ - プレフィックスが壊れており、ヒットはゼロです

ステップバイステップ: ヒットプロンプトを設定するには?

  1. 定数と変数を分離します。決して変更されないコンテンツ (システム プロンプト、ルールブック、ドキュメント) は何ですか?リクエストごとにどれが変わりますか (ユーザーの質問、日付、ID)?
  2. 先頭に定数を置きます。処理中、最初に行われる部分 (ツール、システム) が安定している必要があります。
  3. 変数を最後に置きます。ユーザーの現在の質問、最後です。
  4. 境界線の端に標識を配置します。キャッシュポイントを固定部分の最後のブロックに置きます。
  5. ヒットを確認します。応答の使用法フィールドで、cache_read_input_tokens がゼロより大きいかどうかを確認します。ゼロの場合、プレフィックスに隠れた破壊者が存在します。

{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}

ヒント: キャッシュ ヒットを推測するのではなく、実際に測定してください。連続したリクエストで use.cache_read_input_tokens が依然として 0 の場合、サイレント ブレーカー (システム プロンプトでの datetime.now()、順序付けされていない JSON、リクエストごとに変更されるツールのリスト) が実行されています。 2 つのリクエストの生のプロンプトをバイトごとに比較し、違いを見つけます。

サイレント・ディスラプター

知らず知らずのうちにキャッシュを破壊する典型的なパターン:

# BREAKER: リクエストごとに変わるシステムプロンプトの埋め込み情報 "今日の日付: {{now}}。あなたはアシスタントです..." ← リクエストごとにプレフィックスが変わり、ヒットはゼロです# TRUE: 変数をメッセージシステムに移動します: "あなたはアシスタント..." ← 定数がキャッシュに入りますmessages: [{role: user, content: "Today is {{now}}. Question: ..."}] ← 最後に変数

その他のブレーカー: JSON はリクエストごとに異なる方法でソートされます (キーを固定の順序で保持します)、ユーザーごとに異なるツールのリスト (ツールは最初に処理され、変更されてもキャッシュには何も入りません)、会話中のモデルの変更 (キャッシュはモデル固有です)。

弱いプロンプト / 強いプロンプト (キャッシュフレンドリーな構造)

# WEAK (キャッシュ無効化ビルド) システム: 「日付: 18.07.2026 14:32。ユーザー: Ahmet (id 8842)。あなたはサポート ボットです。ルール: ...(2000 トークン)...」

# STRONG (キャッシュに優しい構造)system: "あなたはサポート ボットです。ルール: ...(2000 トークン、変更されません)..." [キャッシュ サイン]メッセージ: [ { 役割: ユーザー、コンテンツ: "日付: 18.07.2026 14:32。ユーザー ID: 8842。質問: 返金を開始するにはどうすればよいですか?" }]

弱いバージョンでは、2000 トークンのルール ブロックがリクエストごとにフルコストで処理されます。強力なバージョンでは、同じブロックが 1 回書き込まれ、その後のすべてのリクエストで 10 分の 1 の料金で読み取られます。

ミニケース3個

ケース 1 — ルールブックをキャッシュする。会計自動化により、各請求書に 12,000 トークンのルールブックが追加されました。 1 日あたり 5,000 件のリクエスト。キャッシュレス入力のコストは 1 日あたり約 180 ドルです。彼らはルールブックを一定に保ち、それをキャッシュしました。最初のリクエストには書き込みプレミアムが支払われ、その後の読み取りは 0.1 倍でした。投入コストは最大 90% 低下し、1 日あたり最大 18 ドルになりました。

ケース 2 — 非表示の日付変更線のコスト。あるチームはキャッシュを設定しましたが、ヒットが得られませんでした。 cache_read_input_tokens は常に 0 でした。理由: システム プロンプトの最初の行に datetime.now() があり、プレフィックスがリクエストごとに変化していました。日付をユーザー メッセージに移動すると、ヒット率が 0% から 94% に突然増加しました。

ケース 3 — キャッシュの場所が間違っている。検索アプリケーションは、リクエストごとにまったく異なる短いクエリを送信していました。彼らは熱心にキャッシュサインを追加しました。共通のプレフィックスがないため、各リクエストには書き込みプレミアムのみが支払われ、読み取りは発生せず、コストが増加しました。彼らは看板を撤去した。教訓: キャッシュは、再利用される大きくて一定のプレフィックスがある場合にのみ効果を発揮します。

よくある間違い

  • 定数と変数の混合: 変数の内容がプレフィックスにある場合、ヒットはリセットされます。
  • システム プロンプトへの日付/ID の埋め込み: 最も一般的なサイレント ディスラプター。
  • ヒットを測定しない:cache_read_input_tokens がチェックされていない場合、無駄は認識されません。
  • パブリック プレフィックスがない場合のキャッシュの追加: 書き込みプレミアムのみを支払い、コストが増加します。
  • 車両リストまたはモデルの変更: プレフィックスは最初から壊れています。すべてが書き換えられます。
  • 最小キャッシュ サイズを忘れる: 非常に短いキャッシュ (モデルに応じて ~1 ～ 4,000 トークン未満) は、サイレントにキャッシュに入りません。

さらに詳しく: ワークロード タイプ別のキャッシュの設計

キャッシュの実際の利益は、ワークロードの性質によって異なります。したがって、まずトラフィックを把握してください。 3 つの典型的なパターンと正しい取り付け:

共通のシステム プロンプト、さまざまな質問。最も一般的な企業パターン: 何百もの異なるユーザーの質問を含む大規模なシステム プロンプト (役割、ルール、おそらく参照ドキュメント)。ここでは、固定部分 (システム) が最初にキャッシュされます。新しい質問はそれぞれ、その小さな部分に対してのみ全額を支払います。大きな部分を10分の1の価格で繰り返し朗読できるため、得られる利益は非常に大きい。

マルチラウンドのモノローグ。会話が長引くにつれて、新しいラウンドはすべて、これまでの歴史の上に構築されます。最後のラウンドの最後にキャッシュ フラグを設定すると、各リクエストは前の会話プレフィックスを再利用します。会話が進むにつれてヒットが蓄積されます。これにより、長時間のアシスタント セッションのコストが大幅に抑制されます。

共有プレフィックスは最後に変更する部分です。複数のリクエストは、固定事前分布の大規模なセット (サンプル セット、指示) を共有しますが、最後に 1 つの質問で区切られます。キャッシュ ポインタを共有部分の最後に置きます。そうしないと、各リクエストが独自の個別のキャッシュを書き込み、キャッシュが読み取られなくなります。

注意点が 1 つあります。キャッシュはモデルと特定の最小サイズによって異なります。非常に小さなプレフィックス (モデルによっては数千トークン未満) は、フラグを立てても黙ってキャッシュに入りません。cache_creation_input_tokens はゼロのままです。また、会話中にモデルを変更すると、キャッシュ全体が無効になります。別のタスクに安価なモデルが必要な場合は、メイン フローを 1 つのモデルに保持し、サイド ジョブを別の呼び出しに置きます。

要約すると

プロンプト キャッシュはプレフィックス マッチです。固定コンテンツは先頭にあり、可変コンテンツは最後にある必要があります。大規模な再利用コンテキストの場合、読み取りコストは通常​​の価格の 10 分の 1 であり、2 回のリクエストでほぼ均衡します。最も一般的な間違いは、システム プロンプトに変数データを埋め込んでプレフィックスを破損することです。使用状況フィールドでヒットを測定することでヒットを確認します。

アプリケーションタスク

ワークロードを選択します。 (1) 内容を「まったく変更しない」と「リクエストごとに変更する」の 2 つの列に分割します。 (2) プロンプト構造を再描画し、定数部分を先頭に、変数部分を最後に配置します。 (3) 固定部分のトークンサイズを見積もり、キャッシュあり/なしの月額コストを比較します。 (4) どのフィールド (cache_read_input_tokens) からヒットを検証するかをメモします。

チェックリスト

  • [ ] キャッシュはプレフィックス マッチングであり、唯一の不変ルールであると説明できます。
  • [ ] 固定コンテンツを先頭に、変数を最後に置くことで精度を高めることができます。
  • [ ] 私は書き込み/読み取りの経済学と 2 リクエストの損益分岐点を知っています。
  • [ ] サイレント・ディスラプター（日付、順序付けされていない JSON、変化する車両リスト）を認識できます。
  • [ ] use.cache_read_input_tokens でヒットを確認できます。
前へ 次へ