Mise en cache des réponses

La mise en cache des réponses exactes permet à une requête acheminée par projet de réutiliser la réponse que le proxy a déjà produite pour une requête identique. Lorsqu’une requête active cette option et qu’une réponse correspondante existe, le proxy renvoie cette réponse sans contacter le fournisseur. Vous réduisez ainsi les coûts facturés par le fournisseur ainsi que la latence pour les charges de travail qui envoient plusieurs fois la même requête, comme les suites d’évaluation, les tests de régression, les nouvelles tentatives et les boucles de développement. La mise en cache est désactivée par défaut et s’applique requête par requête. Une réponse mise en cache est restituée à l’identique, octet par octet. Un succès de cache renvoie donc la même réponse, même lorsque la requête utilise des paramètres d’échantillonnage tels qu’une température non nulle.

Activer la mise en cache pour une requête

Définissez l’en-tête de requête Forge-Cache-Mode sur l’un des modes suivants :

Valeur	Lire une réponse existante	Stocker une réponse réussie
`readWrite`	Oui	Oui
`readOnly`	Oui	Non
`writeOnly`	Non	Oui

Pour contourner le cache, omettez l’en-tête.

Python
JavaScript
cURL

import os

from openai import OpenAI

client = OpenAI(
    base_url="https://proxy.training.coreweave.com/v1",
    api_key=os.environ["WANDB_API_KEY"],
    project="your-team/ticket-classifier",  # envoyé en tant que OpenAI-Project
)

raw = client.chat.completions.with_raw_response.create(
    model="router",
    messages=[
        {"role": "user", "content": "My package arrived damaged. What should I do?"}
    ],
    extra_headers={"Forge-Cache-Mode": "readWrite"},
)

print(raw.headers.get("forge-cache-status"))  # "hit" ou "miss"
response = raw.parse()
print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://proxy.training.coreweave.com/v1",
  apiKey: process.env.WANDB_API_KEY,
  project: "your-team/ticket-classifier", // envoyé en tant que OpenAI-Project
});

const { data: response, response: raw } = await client.chat.completions
  .create(
    {
      model: "router",
      messages: [
        { role: "user", content: "My package arrived damaged. What should I do?" },
      ],
    },
    { headers: { "Forge-Cache-Mode": "readWrite" } },
  )
  .withResponse();

console.log(raw.headers.get("forge-cache-status")); // "hit" ou "miss"
console.log(response.choices[0].message.content);

curl -i https://proxy.training.coreweave.com/v1/chat/completions \
  -H "Authorization: Bearer $WANDB_API_KEY" \
  -H "Content-Type: application/json" \
  -H "OpenAI-Project: your-team/ticket-classifier" \
  -H "Forge-Cache-Mode: readWrite" \
  -d '{
    "model": "router",
    "messages": [
      {"role": "user", "content": "My package arrived damaged. What should I do?"}
    ]
  }'

Lorsque la requête active la lecture depuis le cache (readWrite ou readOnly), la réponse contient un en-tête Forge-Cache-Status dont la valeur est hit ou miss. La réponse à une requête writeOnly ne contient pas cet en-tête.

Ce qui rend deux requêtes identiques

Le proxy recherche une réponse en cache après avoir résolu la version du projet et la révision d’acheminement, et avant de sélectionner un fournisseur. Pour une redéfinition de modèle, la recherche a lieu après que le proxy a résolu le fournisseur de la redéfinition. La clé de cache combine les valeurs suivantes :

L’entity Weights & Biases, le projet et la version du projet que le proxy résout à partir de l’en-tête OpenAI-Project et des métadonnées forge.project_version.
La révision d’acheminement qui s’applique à la version au moment où la requête arrive.
Le chemin de la requête et la chaîne de requête.
Un hachage SHA-256 du corps de requête, sérialisé avec les clés d’objet triées et sans les valeurs indiquées ci-dessous.

Le proxy retire les valeurs suivantes du corps avant le hachage, afin qu’elles n’influent pas sur la clé :

La chaîne model brute d’une requête acheminée. Le projet, la version et la révision d’acheminement résolus figurent déjà dans la clé : "router", une valeur model vide et une valeur model omise partagent donc des entrées. Des versions différentes ne partagent jamais d’entrées.
Les clés de métadonnées qui commencent par forge. ou wandb., notamment forge.project_version.
L’identifiant de conversation dans gen_ai.conversation.id.
stream: false, que le proxy traite comme si stream était omis.
Un objet metadata vide, que le proxy traite comme si metadata était omis.

Le nom d’hôte du proxy et l’ordre des paramètres de requête n’influent pas non plus sur la clé. Chaque fois que vous enregistrez l’acheminement d’une version, Model Distillation publie une nouvelle révision d’acheminement, ce qui modifie la clé. Les entrées existantes ne correspondent plus, mais sont conservées jusqu’à leur expiration. Le proxy ne hache pas les redéfinitions de paramètres d’une cible d’acheminement. Toutefois, modifier une redéfinition constitue un changement d’acheminement comme un autre et modifie donc également la clé. Tous les autres champs du corps sont pris en compte dans le hachage, que le fournisseur les utilise ou non. Il s’agit notamment de messages, tools, tool_choice, response_format, temperature, top_p, max_tokens, seed, n, stop, user, de tous les champs propres au fournisseur, ainsi que des clés de métadonnées qui ne commencent pas par forge. ou wandb., comme user.id. L’ordre des clés au sein d’un objet n’a pas d’importance. En revanche, l’ordre des éléments d’un tableau, comme messages, en a. Les entrées sont limitées à votre entity et à votre projet Weights & Biases. Une requête identique provenant d’une autre entity, ou destinée à un autre projet de votre entity, ne correspond jamais à vos entrées. Une réponse en cache conserve la cible d’acheminement qui l’a produite. Le proxy sert un succès de cache depuis cette cible, sans acheminement pondéré ni persistant. Une redéfinition de modèle envoie une valeur provider/model dans model, accompagnée de l’en-tête OpenAI-Project. Le proxy la met en cache dans la version de projet sélectionnée, comme le trafic acheminé. Sa clé inclut également le fournisseur, la référence du modèle et la configuration du fournisseur : une redéfinition ne correspond donc jamais aux entrées acheminées ni aux entrées d’un autre modèle.

Limites

Le cache présente les limites suivantes :

Requêtes sans streaming uniquement. Les requêtes avec stream: true qui définissent un en-tête de cache renvoient 400 Bad Request.
Réponses réussies uniquement. Le proxy ne stocke que les réponses 2xx d’une taille maximale de 8 Mio.
Conservation de 7 jours. Les entrées sont supprimées 7 jours après leur écriture. Les succès de cache ne prolongent pas leur durée de vie.
Les modes non valides sont rejetés. Toute valeur de Forge-Cache-Mode autre que celles répertoriées renvoie 400 Bad Request.

Les défaillances du cache sont non bloquantes (fail open) : si le cache ne peut pas être lu ou écrit, le proxy transmet la requête au fournisseur comme d’habitude. Le proxy ne regroupe pas les requêtes simultanées. Si des requêtes identiques arrivent avant que le proxy ait stocké la première réponse, chacune d’elles est transmise au fournisseur, et le proxy conserve la dernière réponse écrite.

Traces et analytique

Le proxy enregistre tout de même un succès de cache comme trace du projet. La trace conserve la réponse d’origine et son utilisation des jetons, porte la mention cache_hit=true et ne présente aucune latence du fournisseur. Une requête qui active la lecture du cache mais qui est transmise au fournisseur porte la mention cache_hit=false. L’analytique comptabilise à zéro les dépenses du fournisseur pour un succès de cache, puisqu’aucune inférence n’a été exécutée, mais les totaux de jetons incluent toujours l’utilisation rejouée. La création de datasets déduplique les entrées identiques : les réponses rejouées n’ajoutent donc pas de lignes d’entraînement en double.

Clients navigateur

Le proxy autorise les en-têtes de requête OpenAI-Project et Forge-Cache-Mode dans les requêtes cross-origin, et expose Forge-Cache-Status et x-proxy-request-id au code exécuté dans le navigateur.

Complétions de chat

Découvrez comment le proxy construit la requête destinée au fournisseur, gère le streaming et transmet les outils ainsi que la sortie structurée.

​Activer la mise en cache pour une requête

​Ce qui rend deux requêtes identiques

​Limites

​Traces et analytique

​Clients navigateur