キャッシュキーはラベルではなくルーティングのヒント

なぜキーを推測ではなくサイジングするのか

一意キーの反射は、特異性はタダだと仮定します——細かいキーはリクエストを区別 する助けにしかならない、と。それを受け入れる前に、二つのことを並べておく価値が あります。一つ目は Microsoft Learn が文書化していることです。プロンプト キャッシュはキャッシュの対象になるために同一の早期プレフィックスを必要とし、 prompt_cache_key はプレフィックスのハッシュと組み合わされて、 繰り返しの処理がどこに着地するかを誘導します。同じドキュメントは、ある目安—— 一つのプレフィックス＋キーの組み合わせで 1 分あたり約 15 リクエスト——を示し、 それを超えるとトラフィックが追加のマシンへあふれ、キャッシュの有効性が下がり うるとしています。二つ目は、本リポジトリのソース実行から取った疎なサニタイズ 済みの公開集計で、同じプレフィックスをより多くのバケットに分けたときにキャッシュ ヒット率と初回トークンのレイテンシが実際にどう動いたかを記述的に示すために 含めています。

立ち止まる価値があるのは、その対の部分です。ヒット率だけを見ると安心材料に 読めますが、その下では体験が動いています。この測定区間では、バケットのカーディナ リティが上がってもヒット率は高くおおむね横ばいのままだったので、それだけを 読めば分割はコストゼロに見えてしまいます。初回トークンのレイテンシの裾が、 もう半分の物語を語ります——一つの熱いバケットが非常に大きな p95 を抱え、 トラフィックがより多くのバケットに広がると急に下がりました。だから運用上の 問いは「キャッシュはヒットしたか」ではなく、「各バケットは、一つのバケットが 熱くなりすぎることなくプレフィックスが局所性を保てるサイズか」です。プレフィックス ハッシュによるルーティングと約 15 リクエスト毎分のおおよそのオーバーフロー 地点は Microsoft Learn が文書化しているものです。バケット数の計算と、レイテンシの 隣に置いた公開のヒット率の測定データは、本リポジトリが擁護する運用上の推論とソース 実行の根拠であって、普遍的なキャッシュヒット曲線ではありません。下のチャートが その対を明示します。

公式の挙動 · キーが変えるもの

キャッシュは同一のプレフィックスから始まる

Microsoft Learn によれば、プロンプトキャッシュには少なくとも 1,024 入力トークンが 必要で、最初の 1,024 トークンが同一でなければなりません。最初のプレフィックスは ルーティングのためにハッシュ化され、最初の 1,024 トークン以降は 128 トークン刻みで 追加のキャッシュ一致が発生します。最初の 1,024 トークン内に 1 文字でも違いがあると、 キャッシュヒットがミスに変わる可能性があります。

サイジング · バケットをリスクゾーンより低く保つ

バケットが 1 つでは熱くなりすぎ、多すぎると冷たくなりすぎる

Microsoft Learn はおおよそのオーバーフロー地点を説明しています。同じプレフィックスと prompt_cache_key の組み合わせが 1 分あたり約 15 リクエストを超えると、 一部のリクエストが追加のマシンにルーティングされ、キャッシュの有効性が低下する 可能性があります。実用的なサイジングのルールは、共有プレフィックスを、各バケットが 余裕をもってそのリスクゾーンより下にとどまるだけの安定したバケットに分割することです。

観測された根拠 · 疎な公開測定区間

ヒット率と遅延を一緒に測定する

キー設計 · 安定したワークロードバケット

呼び出し単位ではなく、ワークロード単位でバケットを分ける

良いキーは、同じワークロードに対して決定的であるべきです。悪いキーは呼び出しごとの エントロピーを含みます。タイムスタンプ、UUID、ランダムなサフィックス、一意の呼び出し トークンがキーに入ると、キャッシュキー空間が爆発し、プレフィックスは再利用を蓄積 できなくなります。

出典と根拠の境界

Tier 1 — サービス契約（Microsoft Learn）。 プロンプト キャッシュのプレフィックス規則、プレフィックスハッシュによるルーティング、 128 トークン単位の一致ステップ、1 文字のミス、prompt_cache_key の ルーティングヒント、そして 1 分あたり約 15 リクエストのオーバーフロー地点が、 ここに文書化されています。

• [1] Prompt caching with Azure OpenAI — 1,024 トークンの 最小要件と同一プレフィックスの要求、初期プレフィックスのハッシュによる ルーティング、最初の 1,024 トークン以降の追加で同一な 128 トークンごとの キャッシュ一致、1 文字のキャッシュミス、プレフィックスハッシュと結合して ルーティングに影響する prompt_cache_key ヒント、そして同じ プレフィックスとキーのリクエストが追加のマシンへあふれてキャッシュ効率が 下がる 1 分あたり約 15 リクエスト地点を定義しています。出典：Microsoft Learn ドキュメント（2026-06-04 アクセス）· アーカイブ。

Tier 2 — 運用上の推論（本リポジトリ）。 バケット数の 計算と公開のヒット率の測定データは、Learn の仕様ではなく、本リポジトリの運用上の 推論でありソース実行の根拠です。

• [2] 本リポジトリ、docs/12-prompt-cache-key-policy.md — バケットサイジングの運用手順書。文書化された約 15-RPM の数値から minimum_buckets = ceil(common_prefix_rpm / 15) を導きます。 一方、recommended_buckets の式と既定のバケットあたり 10-RPM の 目標は、Learn の仕様ではなく本リポジトリの運用上の推論です。出典。
• [3] 本リポジトリ、results/cache-key-bucketing/cache_hit_ratio_vs_cardinality.csv — ヒット率と初回トークンレイテンシの表の背後にある、疎な公開集計の測定区間。 普遍的な曲線ではなくソース実行の根拠です。出典。

このトピックが証明するものとしないもの。 アクセス日時点で Microsoft Learn が明示するプロンプトキャッシュの契約——1,024 トークンの プレフィックス規則、プレフィックスハッシュによるルーティング、 prompt_cache_key ヒント、1 分あたり約 15 リクエストのオーバー フロー地点——と、共有プレフィックスを、各バケットが余裕をもってその地点の 下にとどまるだけの安定したバケットに分割する、という本リポジトリのサイジングの 経験則を文書化します。バケット数の式と公開のヒット率の測定データは運用上の推論と ソース実行の根拠であって、保証されたキャッシュヒット曲線ではありません。 すべてのモデル・リージョン・トラフィック形状で同一に成り立つ普遍的なしきい値は 証明しません。