Lorsque votre moteur de localisation traduit du texte, une partie du prompt envoyé au LLM reste identique à chaque requête, tandis qu’une autre varie d’une requête à l’autre. La mise en cache du prompt permet au moteur de réutiliser cette partie stable au lieu de payer pour la retraiter à chaque fois. Ces jetons réutilisés apparaissent dans votre utilisation sous la forme de jetons de cache, facturés à une fraction du prix des jetons d’entrée classiques.
Comment un prompt de traduction est construit#
Chaque requête envoyée par le moteur à un modèle est assemblée par couches. Certaines restent stables pour toutes les requêtes d’un même moteur et d’une même langue ; une autre est dynamique et change à chaque requête.
| Couche | Stable ou dynamique | Mis en cache |
|---|---|---|
| Prompt système - identité du moteur, règles de localisation, grammaire | Stable pour tous les moteurs | Oui |
| Vos règles et votre voix de marque, pour chaque langue | Stable tant que vous ne les modifiez pas | Oui |
| Termes du glossaire récupérés pour cette requête précise | Dynamique - varie selon la requête | Non |
| Le texte à traduire | Dynamique | Non |
Les couches stables forment un préfixe continu au début du prompt. Le moteur marque la fin de ce préfixe comme un point de rupture du cache : tout ce qui le précède peut être mis en cache et réutilisé, et tout ce qui le suit - le glossaire propre à la requête, les exemples et votre texte d’entrée - est envoyé de nouveau à chaque requête.
Pourquoi le glossaire n’est pas mis en cache
Le glossaire est récupéré à chaque requête en fonction du texte exact à traduire ; il varie donc d’une requête à l’autre. Le placer après le point de rupture du cache permet au reste du prompt de rester réutilisable, quels que soient les termes de glossaire remontés pour une requête donnée.
Pourquoi les entrées mises en cache coûtent moins cher#
La première requête pour un moteur et une langue donnés écrit le préfixe stable dans le cache du fournisseur. Chaque requête suivante qui réutilise ce préfixe le lit depuis ce cache au lieu de le retraiter depuis zéro. Les fournisseurs facturent les lectures de cache à une fraction du tarif normal des jetons d’entrée. Résultat : la majeure partie de votre prompt - celle qui ne change jamais - n’est plus refacturée au plein tarif à chaque requête.
Le cache a une durée de vie courte et est géré par le fournisseur du modèle, pas par votre moteur. Le bénéfice est donc maximal lorsque vous traduisez beaucoup avec le même moteur et la même langue sur une courte période : les requêtes arrivent pendant que le préfixe est encore chaud et sont lues directement depuis le cache.
Modifier un jeu de règles ou une voix de marque change le préfixe. La requête suivante en crée donc un nouveau. Comme les deux appartiennent à l’organisation et sont partagés, une seule modification invalide le préfixe de chaque moteur qui les utilise.
La mise en cache est automatique
Vous n’avez rien à configurer. L’utilisation du cache dépend du modèle qui traite la requête : les modèles Anthropic et Google utilisent des points de rupture de cache explicites, les modèles OpenAI mettent automatiquement en cache les longs préfixes, et certains fournisseurs ne proposent pas de cache du tout. Le moteur applique le bon comportement pour chaque modèle.
Les bénéfices#
- Coût réduit - le préfixe stable est payé une première fois au plein tarif, puis au tarif réduit de lecture du cache pour chaque requête répétée.
- Latence réduite - les jetons mis en cache n’ont pas besoin d’être retraités, donc les requêtes avec un cache chaud reviennent plus vite.
- Aucune configuration - la mise en cache est activée par défaut ; il n’y a rien à activer dans la configuration de votre moteur.
Les gains se cumulent avec un trafic régulier sur le même moteur et la même langue - exactement le profil d’un pipeline de localisation en production, où la même configuration traite requête après requête.
Comprendre les jetons de cache dans votre utilisation#
Chaque réponse de traduction inclut un détail d’utilisation qui distingue les jetons de cache des nouveaux jetons d’entrée :
{
"usage": {
"inputTokens": 1200,
"outputTokens": 800,
"cacheReadTokens": 950,
"cacheWriteTokens": 0
}
}| Champ | Signification |
|---|---|
inputTokens | Jetons du prompt traités comme nouveaux pour cette requête |
outputTokens | Jetons générés par le modèle |
cacheReadTokens | Jetons du prompt servis depuis le cache du fournisseur. 0 lorsqu’aucun élément n’a été mis en cache. |
cacheWriteTokens | Jetons du prompt écrits dans le cache pour cette requête - cache manqué / premier appel. |
Une première requête pour un moteur et une langue affiche généralement une valeur positive pour cacheWriteTokens (le préfixe est en cours d’écriture) et cacheReadTokens à 0. Les requêtes suivantes, tant que le cache est encore chaud, inversent la tendance : cacheReadTokens augmente et cacheWriteTokens retombe à 0. Suivez l’utilisation agrégée des jetons sur l’ensemble de vos moteurs dans Rapports.
