Le prompt caching dans Strom

Deux niveaux de cache entrent en jeu pour une requête envoyée à Strom :

1. Le cache au sein d’une requête : le cache entre les différentes parties d’une même requête API
2. Le cache entre requêtes : quand des requêtes successives partagent un même début

1. Le cache au sein d’une requête

Une requête de cette forme :

State + Question 1 + Question 2 + ...

s’exécute en interne comme un appel au modèle par question (en parallèle) :

State + Question 1
State + Question 2
...

Le state peut évidemment être mis en cache, puisque c’est un début commun. Nous effectuons une étape explicite de « priming » pour mettre le state en cache, puis chaque question repart de ce state en cache. Le priming coûte un appel supplémentaire, nous ne le faisons donc que lorsqu’il est rentable : quand suffisamment de questions partagent un state assez long. Les requêtes avec des images ne passent pas par le priming.

2. Le cache entre requêtes

C’est le cas le plus simple. Si une requête partage un même début (le state et, éventuellement, les questions) avec une requête précédente, Strom réutilise automatiquement cette partie commune, ce qui réduit la latence.

Conseils pour tirer le meilleur parti du cache

• Posez plusieurs questions dans une seule requête plutôt qu’une requête par question.
• Gardez le state identique à l’octet près entre les requêtes qui doivent le partager. Les règles habituelles du cache des LLM s’appliquent, comme placer la partie variable du state (par ex. le contexte ou la date du jour) à la fin.
• La part de cache réutilisée dépend aussi de la charge de nos serveurs.
• Le cache n’agit que sur la latence. Le nombre de tokens facturés ne dépend que de la taille de la requête.
• Chaque réponse indique dans usage.cached_input_tokens combien de tokens d’entrée proviennent du cache.