Skip to main content
完全一致応答キャッシュを使用すると、project 経由でルーティングされたリクエストに対して、同一のリクエストでプロキシがすでに生成した応答を再利用できます。リクエストでキャッシュを有効にしていて、一致する応答が存在する場合、プロキシはプロバイダーに問い合わせずにその応答を返します。評価スイート、回帰テスト、リトライ、開発ループなど、同じリクエストを複数回送信するワークロードでは、プロバイダーの利用料金とレイテンシーを削減できます。 キャッシュはデフォルトで無効で、リクエスト単位で適用されます。キャッシュされた応答はバイト単位でそのまま返されるため、0 以外の temperature などのサンプリングパラメーターを指定したリクエストでも、キャッシュヒット時には同じ回答が返されます。

リクエストでキャッシュを有効にする

Forge-Cache-Mode リクエストヘッダーに、次のいずれかのモードを設定します。 キャッシュを使用しない場合は、このヘッダーを省略します。
キャッシュの読み取りを有効にしたリクエスト (readWrite または readOnly) では、応答に Forge-Cache-Status ヘッダーが含まれ、その値は hit または miss になります。writeOnly リクエストの応答には、このヘッダーは含まれません。

2 つのリクエストが同一と見なされる条件

プロキシは、project のバージョンとルーティングリビジョンを解決した後、プロバイダーを選択する前に、キャッシュされた応答を検索します。モデルオーバーライドの場合、検索はプロキシがオーバーライドのプロバイダーを解決した後に行われます。キャッシュキーは次の値を組み合わせたものです。
  • プロキシが OpenAI-Project ヘッダーと forge.project_version メタデータから解決する Weights & Biases の entity、project、および project のバージョン。
  • リクエストの到着時にそのバージョンに適用されているルーティングリビジョン。
  • リクエストのパスとクエリ文字列。
  • オブジェクトキーをソートしてシリアライズし、次に示す値を除外したリクエストボディの SHA-256 ハッシュ。
プロキシはハッシュ化の前にボディから次の値を削除するため、これらの値はキーに影響しません。
  • ルーティングされるリクエストの生の model 文字列。解決後の project、バージョン、ルーティングリビジョンはすでにキーに含まれているため、model に "router" を指定した場合、model を空にした場合、model を省略した場合は、いずれも同じエントリを共有します。異なるバージョン間でエントリが共有されることはありません。
  • forge. または wandb. で始まるメタデータキー (forge.project_version など)。
  • gen_ai.conversation.id 内の会話識別子。
  • stream: false。プロキシはこれを stream を省略した場合と同じように扱います。
  • 空の metadata オブジェクト。プロキシはこれを metadata を省略した場合と同じように扱います。
プロキシのホスト名やクエリパラメーターの順序も、キーには影響しません。 バージョンのルーティングを保存するたびに、Model Distillation は新しいルーティングリビジョンをパブリッシュするため、キーが変わります。既存のエントリは一致しなくなりますが、有効期限が切れるまで残ります。プロキシは、ルーティングターゲットに設定されたパラメーターのオーバーライドをハッシュ化しません。ただし、オーバーライドの変更も他のルーティング変更と同じ扱いになるため、やはりキーが変わります。 ボディ内のその他のフィールドは、プロバイダーが使用するかどうかにかかわらず、すべてハッシュの対象になります。対象となるフィールドには、messages、tools、tool_choice、response_format、temperature、top_p、max_tokens、seed、n、stop、user、プロバイダー固有のフィールド、および user.id など forge. または wandb. で始まらないメタデータキーがあります。オブジェクト内のキーの順序は影響しませんが、messages などの配列内の項目の順序は影響します。 エントリのスコープは、お使いの Weights & Biases の entity と project に限定されます。別の entity からの同一リクエストや、同じ entity 内の別の project に対するリクエストが、お使いのエントリと一致することはありません。 キャッシュされた応答には、その応答を生成したルーティングターゲットが記録されます。キャッシュヒット時、プロキシは重み付けルーティングやスティッキールーティングを適用せず、そのターゲットの応答を返します。 モデルオーバーライドでは、model に provider/model の値を指定し、OpenAI-Project ヘッダーとともに送信します。プロキシは、ルーティングされるトラフィックと同様に、選択された project のバージョン内でこれをキャッシュします。そのキーにはプロバイダー、モデル参照、およびプロバイダーの設定も含まれるため、オーバーライドがルーティングされたエントリや別のモデルのエントリと一致することはありません。

制限

キャッシュには次の制限があります。
  • 非ストリーミングリクエストのみが対象です。 stream: true を指定したリクエストでキャッシュヘッダーを設定すると、400 Bad Request が返されます。
  • 成功した応答のみが対象です。 プロキシが保存するのは、8 MiB までの 2xx 応答のみです。
  • 保持期間は 7 日間です。 エントリは書き込まれてから 7 日後に削除されます。キャッシュヒットしても保持期間は延長されません。
  • 無効なモードは拒否されます。 Forge-Cache-Mode に記載以外の値を指定した場合は、400 Bad Request が返されます。
キャッシュの障害時はフェイルオープンで動作します。キャッシュの読み取りまたは書き込みができない場合、プロキシは通常どおりリクエストをプロバイダーに転送します。 プロキシは同時リクエストを統合しません。プロキシが最初の応答を保存する前に同一のリクエストが複数届いた場合、それぞれがプロバイダーに送信され、最後に書き込まれた応答が保存されます。

トレースと Analytics

キャッシュヒットの場合も、プロキシはそれを project のトレースとして記録します。このトレースには元の応答とそのトークン使用量が保持され、cache_hit=true が付与されます。プロバイダーのレイテンシーは記録されません。キャッシュ読み取りを有効にしていても、リクエストがプロバイダーに転送された場合は cache_hit=false が付与されます。 キャッシュヒットでは推論が実行されないため、Analytics ではプロバイダーの利用料金がゼロとして計上されます。一方、トークンの合計には再利用された使用量も含まれます。データセットの作成時には同一の入力が重複排除されるため、再利用された応答によってトレーニング用の行が重複して追加されることはありません。

ブラウザークライアント

プロキシは、クロスオリジンリクエストで OpenAI-Project および Forge-Cache-Mode リクエストヘッダーを許可し、Forge-Cache-Status と x-proxy-request-id をブラウザー側のコードに公開します。

チャット補完

プロキシによるプロバイダーへのリクエストの構築、ストリーミングの処理、ツールと構造化出力の転送の仕組みについて説明します。
最終更新日 2026年10月27日