140M の毎日の呼び出しからのデータは、セマンティック キャッシュによって冗長なリクエストが排除されていることを示しています。トラフィックに応じてヒット率がどのように変化するかを次に示します。
Starsg ゲートウェイ上の 140M の毎日の呼び出し全体で、プロンプトの 31% は、前の 24 時間に処理したリクエストとほぼ重複しています。完全一致キャッシュでは、そのうちのわずか 3 分の 1 しか検出されません。セマンティック キャッシュが残りを補います。これは、ほとんどのチームがモデルを変更せずに実現できる、単一項目の最大の削減です。
キャッシュ ヒットとしてカウントされるもの
各受信プロンプトを埋め込み、テナント独自のベクトル インデックスを検索し、コサイン類似度がルートごとのしきい値をクリアしたときに結果をヒットとして扱います。デフォルトは、事実検索の場合は 0.97 で、呼び出し元が生成としてマークするものは 0.99 です。しきい値を下回ると、リクエストは上流に送られ、レスポンスがインデックスに書き戻されます。
- サポートと FAQ のトラフィック: 52% のヒット率 - 同じ 20 の質問が大半を占めます
- 製品カタログの強化: 38% のヒット率 (SKU の説明の繰り返しによる)
- コード支援: 19% のヒット率。プロンプトには固有のファイルコンテキストが含まれます
- 自由形式のチャット: 6% のヒット率 — ここではキャッシュは手段ではありません
トラフィックに応じてヒット率がどのように変化するか
ヒット率は、生のボリュームではなく、プロンプト密度の関数です。 10k コール/日のワークロードと 10M コール/日のワークロードは、インデックスでおよそ 50k 個の個別のプロンプトが確認されると、同じレートに収束します。ボリュームの変化は、そのポイントに到達するまでの時間です。大規模なテナントは数時間でウォームアップしますが、小規模なテナントでは数週間かかります。
キャッシュが有効になっているすべてのテナントの平均を計算すると、セマンティック キャッシュにより、前四半期の請求対象アップストリーム トークンの 41% が削除されました。ヒット時の追加レイテンシの中央値: 11ms。
オンにする
client.chat.completions.create(
model="claude-sonnet-4-5",
messages=messages,
extra_body={
"amplink": {
"cache": {"mode": "semantic", "threshold": 0.97, "ttl": 86400}
}
},
)
しきい値を控えめに設定し、served-from-cache ヘッダーを 1 週間監視してから、ルートごとに緩めます。グローバルに着陸するのではなく、ルートごとに調整するチームは、同じ品質バーでのヒット率で 8 ～ 12 ポイントが高くなります。