cache de prompt

En profondeur

Le mécanisme découle de l’architecture. Pour produire une réponse, le modèle calcule d’abord une représentation interne de toute l’entrée, et ce calcul dépend uniquement de ce qui précède chaque position. Si deux requêtes commencent par le même millier de tokens, ce travail est identique : on peut le garder et repartir de là. La conséquence pratique est une réduction du prix et du délai de première réponse, souvent très importante pour les systèmes qui répètent une longue instruction à chaque appel.

Cela impose une règle de composition qui va à l’encontre des habitudes : mettre le stable devant et le variable derrière. Instructions permanentes, définitions d’outils, documents de référence, exemples : tout cela en tête, identique au caractère près. La question de l’utilisateur, l’horodatage, son identifiant : à la fin. Une seule variation en tête, une date insérée dans la première ligne par exemple, suffit à invalider tout le cache et à ramener le coût à son niveau initial, sans qu’aucune erreur ne se manifeste.

Deux effets méritent d’être surveillés. Le premier est temporel : ces caches expirent en quelques minutes, si bien que le gain dépend du rythme des requêtes et qu’un service peu sollicité en profite peu. Le second touche à la confidentialité : le cache est propre à un compte et n’est pas partagé entre clients, mais il implique qu’une portion de vos entrées reste stockée quelques minutes chez le fournisseur, ce qui figure dans les questions à poser lors d’une analyse de traitement de données.