La mise en cache est une correspondance de préfixe, et ce seul fait décide de tout. Le premier octet qui change invalide tous ceux qui suivent : une ligne volatile — un horodatage, un identifiant de requête, la question de l'utilisateur — placée devant vingt-cinq mille tokens stables signifie qu'aucun d'eux n'est mis en cache. Le correctif a toujours la même forme : le stable d'abord, le volatile en dernier. Ce qui n'est pas évident, c'est le coût de l'erreur, et c'est pourquoi on lui met ici un chiffre. Saisissez les blocs de votre requête avec leur fréquence de changement : ils sont triés, le préfixe est mesuré et l'écart chiffré sur autant de requêtes que vous en faites.
Fonctionnalités
Blocs triés pour maximiser le préfixe
Nomme les blocs stables échoués derrière des blocs volatils
Mesure le préfixe cachable et la part payée à chaque fois
Avertit quand le préfixe passe sous le minimum et ne sera pas mis en cache
Chiffre l’écart sur une série de requêtes
Signale les blocs à changement occasionnel, qui invalident tout ce qui suit
Tarifs de lecture de cache par modèle, avec leur date de vérification
Tailles de blocs modifiables, pour coller à votre requête
Comment utiliser Planificateur de cache
Listez les blocs de votre requête avec leurs tailles
Indiquez la fréquence de changement de chacun
Lisez l’ordre recommandé et l’économie
Déplacez votre point de cache à la fin du préfixe stable
Exemple
Entrée
User question (300) sent first
Sortie
29,500 stable tokens cannot be cached
Un bloc volatile en tête invalide tout ce qui est derrière.
Erreurs courantes et dépannage
Mon taux de succès est nul. — Quelque chose de volatile est dans le préfixe. Un horodatage, un identifiant de requête ou une liste d’outils sans ordre stable suffisent chacun.
Le préfixe passe sous le minimum. — Les préfixes courts ne sont pas mis en cache du tout, et rien ne le dit. Soit vous agrandissez le préfixe, soit vous acceptez que la mise en cache ne s’applique pas.
Cela met en cache parfois seulement. — Souvent un bloc à changement occasionnel placé tôt. Chaque changement invalide tout ce qui suit : un changement occasionnel est une requête occasionnelle au plein tarif.
Réordonner changerait le sens. — Alors c’est un vrai compromis. Ce qui doit rester en place est une contrainte ; l’outil montre le coût pour que la décision soit informée.
Foire aux questions
Comment fonctionne réellement la mise en cache ?
La requête est comparée par préfixe à ce qui est en cache. Tout jusqu’à la première différence est servi depuis le cache à une fraction du prix ; tout le reste est facturé plein. D’où l’importance de l’ordre.
Qu’est-ce qui invalide un cache en silence ?
Tout ce qui change des octets tôt : un horodatage dans le prompt système, un identifiant de requête, une liste d’outils construite depuis une table non ordonnée, un champ par utilisateur. Aucun ne lève d’erreur : le taux de succès chute simplement.
Pourquoi un préfixe minimum ?
En dessous d’une taille dépendant du modèle, la mise en cache ne s’applique pas. Elle échoue en silence : un petit prompt système que vous croyiez en cache ne l’a peut-être jamais été.
Où placer le point de cache ?
À la fin du dernier bloc stable. Tout ce qui précède est réutilisé ; tout ce qui suit est neuf à chaque fois — exactement la coupure que produit le tri proposé ici.
La mise en cache vaut-elle toujours le coup ?
Quand un grand préfixe est réellement réutilisé, oui : le tarif de lecture est une fraction du tarif d’entrée. Il ne vaut pas la peine de tordre une requête sans préfixe stable — c’est ce que dit l’erreur ici.