Stratégies de cache comparées
Le cache est l'une des tactiques de réduction des coûts à plus fort impact pour les charges de travail LLM. L'idée est directe : ne payez pas pour l'inférence si vous pouvez retourner un résultat en cache. Mais le « cache » n'est pas une seule technique — ce sont quatre stratégies distinctes avec des compromis différents en matière d'économies de coûts, de latence, de précision et de complexité de mise en œuvre. Choisir la mauvaise gaspille l'effort d'ingénierie ; choisir la bonne peut réduire votre facture de 30 à 70 %.
Comparaison des stratégies
| Stratégie | Fonctionnement | Économies de coûts | Impact sur la latence | Effort de mise en œuvre | Idéal pour | Fournisseurs |
|---|---|---|---|---|---|---|
| Cache de prompts (côté fournisseur) | Le fournisseur met en cache le calcul KV pour les préfixes de prompts répétés. Les demandes ultérieures avec le même préfixe ignorent le retraitement. | 50 % sur les tokens d'entrée en cache | 60-80 % plus rapide en latence du premier token | Zéro à faible — automatique chez la plupart des fournisseurs | Prompts système longs, RAG avec contexte partagé, boucles d'agents | OpenAI, Anthropic, Google |
| Cache sémantique (basé sur les embeddings) | Génère les embeddings de la requête utilisateur, recherche dans un magasin vectoriel des requêtes passées similaires. Si la similitude dépasse un seuil, retourne la réponse en cache sans appeler le LLM. | 20-50 % selon la répétition des requêtes | 50-90 % plus rapide (pas d'appel LLM) | Moyen — nécessite un modèle d'embeddings, un magasin vectoriel, un ajustement du seuil de similitude | Bots FAQ, support client, requêtes répétitives | Quelconque (auto-hébergé via GPTCache, Redis avec recherche vectorielle) |
| Cache de contexte (style Google) | Met en cache les documents de contexte volumineux (PDF, référentiels de code) côté serveur. Paye une fois pour le traitement du contexte, réutilise sur plusieurs requêtes à un coût réduit par requête. | 70-90 % sur les requêtes riches en contexte | Amélioration modérée du traitement du contexte | Faible à moyen — charge le contexte, gère le TTL | Questions-réponses sur documents, révision de code sur grands référentiels, tours multiples avec contexte statique | Google (Gemini), Anthropic (contexte de réflexion étendue) |
| Cache au niveau applicatif (Redis/CDN) | Hachage déterministe de la demande complète (prompt + paramètres). Stocke la réponse dans Redis ou un CDN. Retourne la réponse en cache en cas de correspondance exacte. | Jusqu'à 100 % en cas de succès du cache | 90-99 % plus rapide (pas d'appel LLM) | Faible — infrastructure de cache standard | Requêtes déterministes, classification, extraction avec prompts fixes | Quelconque (infrastructure que vous contrôlez) |
Cache de prompts en détail
Le cache de prompts est le gain le plus facile. OpenAI met automatiquement en cache les prompts de plus de 1 024 tokens. Anthropic met en cache les préfixes de 2 048+ tokens. Le cache est indexé par le préfixe exact — même prompt système, mêmes exemples few-shot, même contexte de document. Lorsqu'il y a un succès du cache, vous payez 50 % moins pour la partie en cache des tokens d'entrée.
L'inconvénient : l'invalidation du cache est contrôlée par le fournisseur. Si le prompt change, même légèrement — message système différent, variable différente dans le préfixe — le cache échoue. Concevez vos prompts pour placer le contenu stable au début et le contenu dynamique à la fin du prompt.
Cache sémantique en détail
Le cache sémantique ignore complètement le LLM lorsqu'une question similaire a déjà été posée. Le flux : générez les embeddings de la requête, recherchez dans un magasin vectoriel (Pinecone, Qdrant, Redis avec recherche vectorielle), vérifiez si le résultat principal dépasse un seuil de similitude (généralement 0,92-0,97) et retournez la réponse en cache si c'est le cas.
Le risque est de retourner des réponses obsolètes ou légèrement incorrectes. Un seuil trop bas retourne des résultats incorrects ; un seuil trop haut signifie presque aucun succès du cache. Ajustez-le selon le cas d'usage. Pour la récupération factuelle de FAQ, 0,95+ est sûr. Pour la génération créative, le cache sémantique est rarement approprié — l'objectif est la nouveauté.
Cache de contexte en détail
Le cache de contexte de Google vous permet de télécharger un document volumineux une fois et de payer un tarif réduit pour les requêtes ultérieures le concernant. C'est puissant pour les questions-réponses sur documents où vous traitez le même PDF de 200 pages des centaines de fois. Le modèle de coûts : vous payez le tarif complet des tokens d'entrée une fois pour l'écriture du cache, puis un tarif réduit (souvent 25 % de la normale) pour chaque lecture du cache.
Le compromis est le TTL. Les contextes en cache expirent. Si votre charge de travail a des modèles d'accès par rafales — 500 requêtes en une heure, puis rien pendant une semaine — le cache peut expirer entre les rafales. Dimensionnez votre TTL pour correspondre à votre modèle d'accès.
Cache au niveau applicatif en détail
Le cache déterministe est la stratégie la plus agressive. Hachez la charge complète de la demande (prompt, température, tokens maximaux, modèle, outils) et stockez la réponse. En cas de correspondance exacte, retournez la réponse en cache instantanément — pas d'appel LLM, pas de latence, pas de coût.
Cela ne fonctionne que lorsque la même entrée doit toujours produire la même sortie. La classification, l'extraction d'entités, l'analyse de données structurées et la génération basée sur des modèles sont de bons candidats. Les tâches conversationnelles ou créatives ne le sont pas — les utilisateurs s'attendent à des réponses variées.
Combinaison de stratégies
Les meilleures implémentations superposent plusieurs stratégies. Une pile typique : cache au niveau applicatif comme première vérification (moins cher, plus rapide), cache sémantique comme deuxième vérification (capture les quasi-doublons), puis l'appel LLM avec cache de prompts côté fournisseur activé (réduit le coût même en cas d'échec du cache). Cette approche en couches peut réduire la dépense LLM totale de 40 à 70 % sur les charges de travail avec un certain degré de répétition.
Suivez les taux de succès du cache séparément pour chaque couche. Si votre taux de succès du cache sémantique tombe en dessous de 10 %, la surcharge du magasin vectoriel peut ne pas en valoir la peine. Si votre taux de succès du cache applicatif est supérieur à 40 %, vous avez probablement des tâches déterministes qui devraient être optimisées au niveau du prompt.
Associé
- Cache de prompts expliqué — approfondissement du cache côté fournisseur.
- Économie du cache sémantique — analyse du ROI du cache sémantique.
- Optimisation des coûts de l'IA — stratégies d'optimisation plus larges.
Vous voulez appliquer cela à vos propres dépenses LLM ? FinOps LLM effectue un audit gratuit de vos coûts d'IA et montre où se trouvent les économies. Réserver audit gratuit →