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 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.

Python
JavaScript
cURL

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)

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);

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"}
  }'

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.

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. 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 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.

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 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.

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 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.

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