OpenAI、Anthropic、Gemini にわたるキャッシュ対応 LLM プロンプトを設計する方法
安定したプロンプト プレフィックス、プロバイダー アダプター、キャッシュ テレメトリ、lint ルール、ROI チェックを使用して、プロバイダー全体でキャッシュ対応 LLM リクエスト レイアウトを設計するための実践的なガイド。
プロンプト キャッシュは、同じトークンが適切な場所で十分な期間、実際に呼び出しているプロバイダー セマンティクスに基づいて再利用される場合にのみ役立ちます。チームは、キャッシュをリクエスト アーキテクチャの問題ではなくモデル機能として扱うため、利点を逃してしまうことがよくあります。各プロンプトの先頭近くにタイムスタンプを配置したり、リクエスト固有の取得結果を再利用可能なツール スキーマでインターリーブしたり、あるプロバイダ向けに最適化しながら別のプロバイダのコストを黙って増加させたりします。
実際的な解決策は、プロンプト キャッシュをゲートウェイ リクエスト コンパイラの一部にすることです。ゲートウェイは、安定したプロンプト マテリアルを揮発性のリクエスト マテリアルから分離し、プロバイダー固有のキャッシュ命令をコンパイルし、キャッシュ可能なプレフィックスによってコストと遅延を測定する必要があります。これは、OpenAI、Anthropic、Gemini によってさまざまなキャッシュ動作、アカウンティング フィールド、TTL、セットアップ コストが公開されるマルチモデル環境では最も重要です。
プロバイダーではなくキャッシュ可能なユニットから始める
通常、再利用可能なユニットはプロンプト全体ではありません。これは、多くのリクエストが共有するプロンプト素材から作成されたプレフィックスまたはコンテキスト オブジェクトです。実稼働環境 エンタープライズ LLM API では、そのマテリアルにはプラットフォーム ポリシー、組織ポリシー、アプリケーション手順、ツール定義、応答形式ルール、コーディング エージェント手順、または静的コーパス ガイダンスが含まれることがよくあります。
揮発性部分は、リクエストごとに変更されるマテリアルです。つまり、ユーザーの現在のタスク、リクエスト ID、タイムスタンプ、会話の末尾、新しく取得した RAG パッセージ、アカウント固有のデータ、一回限りのツールの結果。安定したコンテンツの前に揮発性のコンテンツが表示されると、プレフィックスの再利用が中断されたり、プロバイダが大きなプロンプトを新しいものとして扱うよう強制されたりする可能性があります。
事実: プロバイダの実装は異なります。 OpenAI ドキュメントは、キャッシュされたトークン アカウンティングを使用して、共有プレフィックスの再利用としてキャッシュを要求します。その公開プロンプトキャッシュに関する記事によると、自動キャッシュは 1,024 トークンのプレフィックスから始まり、128 トークンずつ増加し、キャッシュ エントリは通常、非アクティブ状態が 5 ～ 10 分間続いた後、および最後の使用から 1 時間以内にクリアされると述べています。 Anthropic は明示的なキャッシュ ブレークポイントを文書化し、システム プロンプトやツール定義などの最後の共有ブロックに cache_control を配置することを推奨します。 Gemini は、キャッシュ操作およびキャッシュを使用する生成呼び出しの使用状況メタデータで返されるキャッシュされたトークン数を含む、有料機能としてのコンテキスト キャッシュについて説明します。
推奨事項: プロバイダー API に何かをマッピングする前に、安定したブロックと揮発性ブロックを中心とした内部プロンプト表現を設計します。
リクエストを最も安定したものから最も不安定なものまでコンパイルします
Aキャッシュ対応リクエスト コンパイラは、最大の再利用可能なセクションがリクエスト固有のセクションの前に表示されるようにマテリアルを順序付ける必要があります。実際のデフォルトの順序は次のとおりです。
- プラットフォームの安全性とコンプライアンスのポリシー。
- 組織またはテナントのポリシー。
- アプリケーションの役割とタスクの手順。
- ツールのスキーマとツールの使用ルール。
- 静的な知識または長期にわたる参照マテリアル。
- ターン間で再利用される会話履歴。
- 取得されたパッセージまたはその他のリクエスト固有のコンテキスト。
- 現在のユーザー タスク。
- この通話にのみ必要な一時的なメタデータ。
この順序は普遍的な真実ではありません。一部のプロバイダーまたはモデルでは、命令が移動したときの応答が異なる場合があります。政策の優先順位と行動の質は依然として重要です。キャッシュを意識した順序付けを制御された変更として扱います。レイアウトを変更する前後にプロンプト回帰テストを実行します。
内部プロンプト ブロックの例
{
"blocks": [
{"id": "platform_policy:v7", "stability": "global", "kind": "system"},
{"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
{"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
{"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
{"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
{"id": "conversation_tail", "stability": "session", "kind": "history"},
{"id": "retrieved_docs", "stability": "request", "kind": "rag"},
{"id": "user_task", "stability": "request", "kind": "user"}
]
}コンパイラは、レンダリング後に安定したプレフィックスをハッシュできます。このハッシュは、モデル、テナント、アプリケーション、キャッシュ可能なプレフィックス ハッシュ、プロンプト バージョン、TTL の選択、キャッシュされていない入力トークン、キャッシュされた入力トークン、キャッシュ書き込みトークン (利用可能な場合)、出力トークン、レイテンシー、最終コストなどのキャッシュ分析の結合キーになります。
1 つのキャッシュを前提とする代わりにプロバイダー アダプターを使用する
単一の「キャッシュを有効にする」フラグでは、あまりにも曖昧すぎます。マルチプロバイダーの操作。ゲートウェイは 1 つの内部キャッシュ ポリシーを公開し、それをプロバイダ固有の動作にコンパイルする必要があります。
OpenAI アダプター
OpenAI については、繰り返される共有プレフィックスと使用状況のアカウンティングを最適化します。リクエスト コンパイラは、安定したマテリアルを先頭に保持し、最初のキャッシュ可能なスパン内の小さな差異を回避する必要があります。プロバイダーの使用状況フィールドからキャッシュされた入力トークンを追跡します。可能な場合は、キャッシュ書き込みトークンも追跡して、コスト台帳でキャッシュの作成と再利用を比較できるようにします。
キャッシュはプレフィックス指向であるため、重要な運用タスクはプレフィックスのドリフトを防ぐことです。人間には同じように見える 2 つのプロンプトが、タイムスタンプ、ビルド ID、ランダム化されたツールの順序、またはテナントのパーソナライゼーションが上部近くに表示されるため、異なる場合があります。
Anthropic アダプター
Anthropic については、明示的なキャッシュ ブレークポイントをコンパイルします。フォローアップ リクエストと共有する必要がある最後のブロックに cache_control を配置します。適切な候補は、大規模なシステム命令、ツール定義、または安定した参照コンテキストです。不適切な候補は、1 回限りのユーザー メッセージ、現在のタスク ペイロード、またはリクエスト固有の RAG スニペットです。
事実: Anthropic には、デフォルトの 5 分間のキャッシュ期間と、追加料金で利用可能な 1 時間のキャッシュ期間が記載されています。そのため、TTL の選択は経済的な決定となります。長いキャッシュは、インタラクティブなコーディング エージェント、複数ステップのドキュメント レビュー、またはターン間に一時停止のある副操縦士のサポートにとって意味があります。繰り返しの少ないワンショット タスクでは無駄になる可能性があります。
Gemini アダプター
Gemini の場合は、コンテキスト キャッシュをリソースの決定として扱います。予想される再利用によってセットアップとストレージのコストが正当化される場合は、キャッシュされたコンテンツを作成し、生成呼び出しからそのキャッシュを参照します。これは、自動プレフィックス キャッシュのみに依存することとは異なります。アダプターは、キャッシュのライフサイクル、TTL、メタデータ、およびクリーンアップ ポリシーを所有する必要があります。
Gemini スタイルのコンテキスト キャッシュは、多くのリクエストで再利用される大規模で安定したコンテキスト (長いポリシー マニュアル、静的な製品カタログの抜粋、固定コーディング エージェント ツール環境、または同じドキュメント セットに対して繰り返し質問するレビュー ワークフローなど) に最適です。
ただヒットするだけでなく、キャッシュの経済性を測定するRate
キャッシュ ヒット率は便利ですが、それだけでは十分ではありません。小さなプレフィックスでのヒット率が高いと、ほとんど節約できない可能性があります。非常に大規模なポリシーとツールのプレフィックスのヒット率が低い場合、より重要になる可能性があります。一部のプロバイダはキャッシュ書き込みコストやセットアップ コストを公開しており、再利用が少ない場合はこれらのコストで節約が失われる可能性があります。
プロバイダがフィールドを公開する場合、またはゲートウェイが推定できる場合は、リクエストごとにこれらのフィールドをキャプチャします:
- プロバイダとモデル。
- テナント、アプリケーション、環境、および API キー ID。
- プロンプト テンプレートのバージョンとキャッシュ可能なプレフィックスハッシュ。
- TTL ポリシーまたはキャッシュ期間。
- キャッシュされていない入力トークン。
- キャッシュされた入力トークン。
- キャッシュ書き込みトークンまたはキャッシュ作成トークン（利用可能な場合）。
- 出力トークン。
- 最初のトークンまでの時間と合計latency.
- コスト計算に使用されるプロバイダーの定価バージョン。
- リクエストが対話型セッション、バッチ ジョブ、エージェント ループ、またはワンショット コールの一部であるかどうか。
次に、グローバルではなくワークロードごとにキャッシュ値を計算します。サポート副操縦士、コーディング エージェント、ドキュメント レビュアー、および 1 回限りのサマライザーには、さまざまな再利用パターンがあります。ロールアップには、節約された金額、キャッシュ書き込みに費やされた金額、レイテンシーの変化、プレフィックス ハッシュごとのヒット率が表示されます。
開始するには単純な ROI モデルで十分です。
expected_savings =
expected_reuses
* cacheable_tokens
* (uncached_input_price - cached_input_price)
net_value =
expected_savings
- cache_write_or_setup_cost
- operational_overhead
このモデルは意図的に単純になっています。これは、本番環境の測定の代わりとしてではなく、長期キャッシュまたは明示的なキャッシュを有効にする前のゲートとして使用する必要があります。
キャッシュ ブレーカー用の Lint ルールの追加
キャッシュの失敗のほとんどは、プロバイダーのバグではなく、プロンプト構築の習慣に起因します。リクエストがプロバイダーに到達する前に実行されるゲートウェイ lint ルールを追加します。
プロンプトの上部付近にタイムスタンプを付けます。モデルに現在時刻が必要な場合は、再利用可能なプレフィックスの後に置くか、遅延リクエスト ブロックとして渡します。
システム メッセージでランダム化された ID にフラグを立てます。相関 ID は、安定したプロンプト プレフィックスではなく、メタデータまたはログに属します。
動的に順序付けされたツール スキーマにフラグを立てます。レンダリング前にツールとスキーマのプロパティを決定的に並べ替えます。リクエストごとに順序を変更するツール リストは、ツール セットが論理的に同一であっても再利用を破壊する可能性があります。
安定したツールの前にリクエスト固有の RAG にフラグを立てます。取得した文章は不安定なことがよくあります。プロンプト テストで別の注文が必要であることが証明されない限り、最初に安定した命令とツール スキーマを配置し、次に取得したパッセージを配置します。
共有ポリシーでユーザー固有のパーソナライゼーションにフラグを立てます。テナント ポリシーはテナント全体でキャッシュできる場合がありますが、ユーザー設定や現在のアカウントの状態は通常はキャッシュできません。
テンプレート バージョンのチャーンにフラグを立てます。デプロイごとに空白、コメント、または未使用の命令テキストが変更されると、キャッシュ可能なプレフィックス ハッシュが変更されます。テンプレートのバージョンを意図的にプロンプトし、大規模な安定したブロックに対する不必要な編集を回避します。
RAG ワークロードを慎重に処理する
RAG は、チームが過剰にキャッシュすることが多い場所です。安定した検索命令、引用ルール、ツール スキーマ、およびコーパス記述は再利用可能である場合があります。取得されたパッセージ自体は通常、リクエスト固有のものです。取得したパッセージを安定した命令の前に配置すると、再利用が減ります。パッセージが繰り返される可能性が低いときにコンテキスト全体をキャッシュすると、今後十分なヒットが得られずに書き込みコストやセットアップ コストが支払われる可能性があります。
例外があります。法的レビュー フロー、サポート ワークフロー、または製品ドキュメント アシスタントは、1 つのセッションで同じドキュメント バンドルに対して繰り返しクエリを実行する場合があります。その場合、ドキュメント コンテキストの有効期間が長いキャッシュが役立つことがあります。決定は、予想される再利用回数、キャッシュ期間、ドキュメント コンテキストのサイズ、およびユーザーが同じ内容について複数の質問をする傾向があるかどうかによって異なります。
推奨: RAG コンテキストを、静的コーパス ガイダンス、再利用可能なセッション コンテキスト、または 1 回限り取得されたスニペットの 3 つのタイプのいずれかに分類します。デフォルトでは、最初の 2 つだけをキャッシュします。
コストを最適化する前に動作を検証する
プロンプト内のコンテンツを後で移動すると、キャッシュの再利用が向上しますが、モデルの動作が変わる可能性もあります。たとえば、会話履歴の後にツール ルールを移動すると、その影響が減少する可能性があります。ポリシーを取得したコンテンツの下に移動すると、命令の優先順位が弱くなる可能性があります。スキーマの正規化は、説明が変更された場合にツールの選択に影響を与える可能性があります。
キャッシュ対応レイアウトを展開する前に回帰テストを使用してください。少なくとも次のテストを行ってください。
- 安全性とコンプライアンス ポリシーに関する命令の優先順位。
- 既知のタスクに関するツールの選択。
- スキーマが関係する構造化された出力の妥当性。
- 代表的な RAG 例についての応答品質。
- 繰り返しのレイテンシとコスト
- プロバイダー固有の使用量アカウンティング。
高リスクのワークフローの場合は、シャドー比較を実行します。元のプロンプト レイアウトとキャッシュ対応レイアウト、同じモデル、同じ入力で、許容できない出力変更がないか人間または自動チェックを行います。チームが承認しない方法でリクエスト コンパイラがビジネス動作を変更する場合、コスト削減は役に立ちません。
ワークロードを選択的に選択する
プロンプト キャッシュは、プロンプトが長く繰り返される場合に最も効果的です。適切な出発点としては、大規模なツール スキーマを備えたコーディング エージェント、ポリシー重視の指示を伴うサポート副操縦士、同じ内容について繰り返し質問するドキュメント レビュー フロー、ツール重視のエージェント、大きなガバナンス ブロックを備えたエンタープライズ アシスタントなどが挙げられます。
弱い候補には、短いワンショット プロンプト、リクエストの先頭が毎回変わる高度にパーソナライズされたプロンプト、頻度の低い管理タスク、出力トークンが総コストの大半を占めるワークフローなどが含まれます。このような場合、プロンプトの短縮、取得の改善、モデルのルーティング、バッチ処理、または出力制限の厳格化など、他の最適化の方が重要になる可能性があります。
予測: プロバイダーのキャッシュ セマンティクスは引き続き分岐します。自動プレフィックス キャッシュ、明示的なブレークポイント、有料コンテキスト リソース、キャッシュ書き込みアカウンティング、TTL 価格設定は、プラットフォーム間で不均一なままになる可能性があります。ゲートウェイでリクエストのコンパイルとテレメトリを一元管理するチームは、アプリケーション コード全体にプロバイダ固有のキャッシュ ロジックを埋め込むチームよりも早く適応できます。
実装チェックリスト
- 安定性ラベル (グローバル、テナント、アプリケーション、ワークフロー、セッション、リクエスト) を持つ内部プロンプト ブロック モデルを作成します。
- ツールの順序やスキーマ プロパティを含め、ブロックを決定的にレンダリングします。 order.
- 安定したプレフィックスから揮発性フィールドを移動します。
- レンダリング後にキャッシュ可能なプレフィックス ハッシュを計算します。
- OpenAI プレフィックスの再利用、Anthropic キャッシュ ブレークポイント、および Gemini コンテキスト キャッシュ リソース用のプロバイダ アダプタを追加します。
- キャッシュされていない入力トークン、キャッシュされた入力トークンを記録します。キャッシュ書き込みトークン (利用可能な場合)、出力トークン、レイテンシ、モデル、テナント、アプリケーション、プレフィックス ハッシュ、TTL。
- 節約された純額、書き込み/セットアップ コスト、ヒット率、ワークロード別のレイテンシを確認するためのダッシュボードを構築します。
- タイムスタンプ、ランダム ID、揮発性 RAG の配置、動的なツールの順序、共有のパーソナライゼーションのための lint ルールを追加します。
- 実稼働レイアウトを変更する前に、プロンプトの動作回帰テストを実行します。
- 繰り返しの多いワークロードに対して最初にキャッシュを有効にし、測定された ROI に基づいて拡張します。
結論
キャッシュを意識したプロンプトの設計は、プロンプトの書式設定だけではありません。これはゲートウェイ機能です: 決定論的レンダリング、安定したプレフィックス設計、プロバイダー固有のコンパイル、リンティング、コスト テレメトリ。最も利益を得るチームは、すべてのワークロードについて 3 つの質問に答えることができるチームです。つまり、リクエストのどの部分が本当に再利用可能なのか、このプロバイダは再利用に対してどのように料金を請求するのか、キャッシュにより動作を変えることなくエンドツーエンドのコストやレイテンシーが改善されましたか?
繰り返しの多い 1 つのワークフローから始めます。安定したブロックを揮発性ブロックから分離し、プロバイダー固有のキャッシュ処理を追加し、経済性を測定してから一般化します。このパスにより、よくある失敗モード、つまりコストを節約しているのか、レイテンシーを追加しているのか、あるいは単にコストを別の会計フィールドに移動しているのかがわからないままキャッシュ機能をオンにするという事態が回避されます。