> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Mise en cache des réponses

> Réutilisez la réponse exacte à une requête répétée sans streaming au lieu d’appeler à nouveau le fournisseur.

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.

<h2 id="enable-caching-for-a-request">
  Activer la mise en cache pour une requête
</h2>

Définissez l’en-tête de requête `wandb-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.

Pour assurer la compatibilité avec les clients OpenPipe, le proxy accepte également l’en-tête obsolète `op-cache`. Celui-ci prend en charge les mêmes modes, ainsi que `true` comme alias de `readWrite` et `false` pour contourner le cache. Si une requête envoie les deux en-têtes, ceux-ci doivent indiquer le même mode. Dans le cas contraire, le proxy renvoie `400 Bad Request`.

<Tabs>
  <Tab title="Python">
    ```python theme={"system"}
    import os

    from openai import OpenAI

    client = OpenAI(
        base_url="https://proxy.training.wandb.ai/v1",
        api_key=os.environ["WANDB_API_KEY"],
    )

    raw = client.chat.completions.with_raw_response.create(
        model="ticket-classifier",
        messages=[
            {"role": "user", "content": "My package arrived damaged. What should I do?"}
        ],
        extra_body={"metadata": {"wandb.entity": "your-team"}},
        extra_headers={"wandb-cache-mode": "readWrite"},
    )

    print(raw.headers.get("wandb-cache-status"))  # "hit" ou "miss"
    response = raw.parse()
    print(response.choices[0].message.content)
    ```
  </Tab>

  <Tab title="JavaScript">
    ```javascript theme={"system"}
    import OpenAI from "openai";

    const client = new OpenAI({
      baseURL: "https://proxy.training.wandb.ai/v1",
      apiKey: process.env.WANDB_API_KEY,
    });

    const { data: response, response: raw } = await client.chat.completions
      .create(
        {
          model: "ticket-classifier",
          messages: [
            { role: "user", content: "My package arrived damaged. What should I do?" },
          ],
          metadata: { "wandb.entity": "your-team" },
        },
        { headers: { "wandb-cache-mode": "readWrite" } },
      )
      .withResponse();

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

  <Tab title="cURL">
    ```bash theme={"system"}
    curl -i https://proxy.training.wandb.ai/v1/chat/completions \
      -H "Authorization: Bearer $WANDB_API_KEY" \
      -H "Content-Type: application/json" \
      -H "wandb-cache-mode: readWrite" \
      -d '{
        "model": "ticket-classifier",
        "messages": [
          {"role": "user", "content": "My package arrived damaged. What should I do?"}
        ],
        "metadata": {"wandb.entity": "your-team"}
      }'
    ```
  </Tab>
</Tabs>

Lorsque la requête active la lecture du cache (`readWrite` ou `readOnly`), la réponse contient un en-tête `wandb-cache-status` dont la valeur est `hit` ou `miss`. Le proxy transmet également cette valeur dans l’en-tête de compatibilité `x-wandb-cache`. La réponse à une requête `writeOnly` ne contient aucun de ces deux en-têtes.

<h2 id="what-makes-two-requests-identical">
  Ce qui rend deux requêtes identiques
</h2>

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. La clé de cache combine les valeurs suivantes :

* L'entity W\&B, le projet et la version du projet que le proxy résout à partir de la valeur `model`.
* La [révision d'acheminement](/fr/model-distillation/studio/routing-and-versions#save-to-an-existing-or-new-version) 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. Le projet, la version et la révision d'acheminement résolus figurent déjà dans la clé : seules des références équivalentes partagent donc des entrées. Par exemple, `ticket-classifier` et `ticket-classifier@v1` sont toutes deux résolues en version 1. Des versions différentes ne partagent jamais d'entrées.
* Les clés de métadonnées qui commencent par `wandb.`, notamment `wandb.entity` et `wandb.thread_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 `wandb.`, comme `gen_ai.conversation.id` ou `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 W\&B. 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.

Les requêtes directes `provider/model` peuvent également définir un en-tête de cache. Le proxy indexe leurs entrées séparément, par entity, fournisseur, référence de modèle et identité W\&B de l'appelant. Ces entrées ne correspondent jamais aux entrées de projet.

<h2 id="limits">
  Limites
</h2>

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 `wandb-cache-mode` autre que celles répertoriées, ou toute combinaison de modes contradictoires dans `wandb-cache-mode` et `op-cache`, 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.

<h2 id="traces-and-analytics">
  Traces et analytique
</h2>

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.

<h2 id="browser-clients">
  Clients navigateur
</h2>

Le proxy autorise les en-têtes de requête `wandb-cache-mode` et `op-cache` dans les requêtes cross-origin, et expose `wandb-cache-status`, `x-wandb-cache` et `x-proxy-request-id` au code exécuté dans le navigateur.

<Card title="Complétions de chat" href="/fr/model-distillation/proxy/chat-completions" arrow="true">
  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.
</Card>