長いプレフィックスのキャッシュ

長いプロンプトでは、生成前にトークンをエンコードするためのプリフィルコストが毎回発生します。システムプロンプト、ツール仕様、大規模な参照ドキュメントなど、同じ長いプレフィックスが多くの呼び出しで繰り返される場合、プロンプトキャッシュによって、プロバイダーはアテンション状態を再計算せず、すでに計算した状態を再利用できます。

• キャッシュヒットによって、レイテンシーと入力コストを大幅に削減できます。
• 節約効果は、プレフィックスのサイズと再利用頻度に応じて大きくなります。

キャッシュは、プロンプトの先頭から始まるトークンの完全一致するプレフィックスをキーにします。キャッシュされる範囲は先頭から最初に内容が分岐する地点までです。早い段階で何かを変更すると、それ以降のすべてがキャッシュミスになります。

つまり、ヒット率を最大化するレイアウトでは、最も安定した内容を先に置き、最も変動する内容を最後に置きます。

内容を安定性の高い順に並べます。変更されないシステムルールとツール定義、次に大規模で安定した参照資料、セッション中は安定したコンテキスト、その後にリクエストごとに変わる入力と質問を最後に置きます。

• 安定した内容 → 前方（キャッシュ可能）
• 変動する内容 → 後方（再計算されるのはこの部分だけ）

この1つの順序原則が、キャッシュによる効果の大半を生み出します。

プロバイダーによっては、明示的なキャッシュの区切り位置を指定できます。各安定セグメントの末尾に配置すると、システムはその位置までをキャッシュできます。最大の安定ブロック（参照コーパスや長いシステムプロンプトなど）をキャッシュ可能として指定します。

明示的なマーカーがない場合でも、構造を安定性の順にしておけば、暗黙的なプレフィックス一致の効果を得られます。

意図しない微細な変更によって、キャッシュが気づかないうちに壊れることがあります。たとえば、システムプロンプト内のタイムスタンプ、早い位置に挿入されるリクエストごとのID、並べ替えられたツール定義、JSONキーの非決定的な順序などです。これらはそれぞれプレフィックスをずらし、全体の再計算を強制します。

プレフィックスを監査し、呼び出し間で変化するものをすべて確認して、キャッシュ領域の後ろへ移します。

キャッシュは、プロバイダーが定めたTTL（有効期間）が経過すると期限切れになります。多くの場合、ヒットするたびに有効期間が更新されます。呼び出しの間隔が空きすぎると、コールドミスが再発します。バースト的で高頻度なワークロードではキャッシュが効果を発揮しますが、まれで散発的な呼び出しでは、利用する前にキャッシュの有効期限が切れてしまうことがあります。

トラフィックのパターンをTTLに合わせ、価値の高いプレフィックスについてはキープアライブのPingも検討してください。

通常、キャッシュではエントリを書き込む際に少額の割増料金がかかり、読み取る際には大幅な割引が適用されます。再利用するほど経済的です。1回の書き込みを多数の読み取りで償却できれば、大きな純削減になります。一度しか使わず、書き込みだけが発生する場合は、かえって少し高くつくことがあります。

• 再利用が多い場合 -> 積極的にキャッシュします。
• 一度しか使わないプレフィックス -> キャッシュしても元が取れない可能性があります。

システムプロンプトとツール仕様を決定的にし、バージョンを固定してください。ツール定義を標準的な順序で並べ、動的なデータの埋め込みを避け、意図的なリリース時にのみ変更します。安定したシステムブロックは、すべてのリクエストで共有される、長期間利用できてヒット率の高いキャッシュエントリになります。

キャッシュされたプレフィックスは、気軽に調整する文字列ではなく、バージョンを持つアーティファクトとして扱ってください。

エージェントループでは、増加していく会話が自然なキャッシュになります。各ターンでプレフィックスが拡張され、次のターンで再利用されるためです。新しいターンは末尾に追加し、以前のターンを書き換えないでください。そうすれば、既存のキャッシュを有効なまま保てます。

コンパクションが必要な場合は、古いプレフィックスを繰り返し変更するのではなく、後続のターンで使える新しい安定したプレフィックスを作成する方法で行ってください。

計測してください。ほとんどのプロバイダーは、呼び出しごとにキャッシュされた入力トークン数とキャッシュされていない入力トークン数を報告します。ヒット率を追跡し、低い場合はプレフィックスに変化が入り込んでいないか調べてください。ヒット率の低下は通常、プロンプトの前半に最近追加された動的な値があることを示します。

• cached_tokens / total_input_tokens を記録します。
• デプロイ後にヒット率が低下したらアラートを出します。

長いプレフィックスのコストを抑えるには、安定性の順にコンテンツを並べ、最も大きな安定ブロックをキャッシュブレークポイントとしてマークし、隠れた変化を排除し、システムブロックとツールブロックのバージョンを固定して管理し、エージェントループでは追記のみとし、ヒット率を監視します。目標は、再利用可能な大きなプレフィックスを1つ用意し、呼び出しごとに再計算する可変性の小さな末尾を持たせることです。

毎日数千件のクエリで10万トークンの参照コーパスを再利用していますが、キャッシュのヒット率がほぼゼロです。

プロンプトキャッシュは、完全に一致する安定したプレフィックスのプレフィルを再利用するため、再利用が頻繁な場合にレイテンシーと入力コストを大幅に削減します。最も安定したコンテンツを先に並べ、大きな安定ブロックをブレークポイントとしてマークし、変動する要素をすべて末尾に移します。隠れた変化を排除し、システムブロックとツールブロックのバージョンを固定して管理し、エージェントループでは追記のみとします。ヒット率を監視し、低下したら前半に新たな可変値が導入されたことを検知できるようにしてください。