OpenAI révolutionne l'efficacité avec la mise en cache des prompts

La mise en cache des prompts : un atout pour l'API OpenAI

Comprendre la mise en cache des prompts

La mise en cache des prompts est une fonctionnalité avancée proposée par des services d'API de modèles de langage, tels que l'API OpenAI. Elle permet de stocker et de réutiliser certaines parties de l'entrée du modèle de langage (LLM) qui sont souvent répétées. Ces parties incluent généralement des instructions système ou des requêtes récurrentes envoyées au modèle chaque fois qu'une application d'intelligence artificielle est exécutée. Pour que la mise en cache soit effective, ces segments répétés doivent être placés au début du prompt, formant ainsi un préfixe de prompt. De plus, ce préfixe doit dépasser un certain seuil de longueur, par exemple, plus de 1 024 tokens pour OpenAI.

La mise en cache des prompts opère au niveau des tokens, dans les processus internes du LLM. Le fonctionnement de l'inférence du LLM se divise en deux phases distinctes :

• Pré-remplissage : le modèle de langage utilise le prompt de l'utilisateur pour générer le premier token.
• Décodage : le modèle génère ensuite les tokens de sortie de manière récursive, un par un.

En résumé, la mise en cache des prompts consiste à stocker les calculs effectués lors de la phase de pré-remplissage, de sorte que le modèle n'ait pas à les recalculer lorsque le même préfixe est utilisé à nouveau.

L'implémentation dans l'API OpenAI

L'API d'OpenAI a introduit la mise en cache des prompts à partir du 1er octobre 2024. Initialement, cette fonctionnalité offrait une réduction de 50 % sur les tokens mis en cache, mais cette réduction peut désormais atteindre 90 %. En outre, l'utilisation de la mise en cache des prompts permet de réaliser des économies supplémentaires sur la latence, pouvant aller jusqu'à 80 %.

Lorsqu'un prompt est soumis avec la mise en cache activée, le service API tente d'accéder au cache en dirigeant le prompt vers une machine appropriée où le cache est censé exister. Ce processus est connu sous le nom de routage de cache, et pour ce faire, l'API utilise généralement un hash des 256 premiers tokens du prompt.

L'API d'OpenAI offre également la possibilité de définir explicitement un paramètre prompt_cache_key dans la requête API au modèle. Ce paramètre détermine quel cache est utilisé, augmentant ainsi les chances que le prompt soit dirigé vers la machine correcte et atteigne le cache.

De plus, l'API propose deux types de mise en cache selon la durée, définis par le paramètre prompt_cache_retention :

• Mise en cache en mémoire : c'est le type de mise en cache par défaut, disponible pour tous les modèles. Les données mises en cache restent actives pendant 5 à 10 minutes entre les requêtes.
• Mise en cache prolongée : disponible pour certains modèles spécifiques, elle permet de conserver les données en cache plus longtemps, jusqu'à un maximum de 24 heures.

Concernant les coûts, OpenAI facture le même prix par token d'entrée, qu'il soit mis en cache ou non. Cependant, si le cache est accessible, les tokens mis en cache bénéficient d'une réduction tarifaire significative, pouvant atteindre 90 %.

Mise en œuvre pratique de la mise en cache des prompts

Pour illustrer comment fonctionne la mise en cache des prompts, prenons un exemple simple en Python utilisant l'API d'OpenAI. Imaginons un scénario où un long prompt système (préfixe) est réutilisé dans plusieurs requêtes. Assurez-vous de disposer de votre clé API OpenAI et d'avoir installé les bibliothèques nécessaires.

La première étape consiste à importer la bibliothèque OpenAI et à initialiser une instance du client OpenAI :

from openai import OpenAI
client = OpenAI(api_key="your_api_key_here")

Ensuite, nous définissons notre préfixe, c'est-à-dire les tokens que nous souhaitons mettre en cache car ils seront répétés :

long_prefix = """
Vous êtes un assistant très compétent spécialisé en apprentissage automatique.
Répondez aux questions avec des explications détaillées et structurées, en incluant des exemples lorsque cela est pertinent.
"""

Nous augmentons artificiellement la longueur pour nous assurer que le seuil de 1 024 tokens est atteint, puis nous configurons un chronomètre pour mesurer nos économies de latence :

start = time.time()
response1 = client.responses.create(
model="gpt-4.1-mini",
input=long_prefix + "Qu'est-ce que le surapprentissage en apprentissage automatique ?"
)
end = time.time()
print("Temps de réponse initial :", round(end - start, 2), "secondes")
print(response1.output[0].content[0].text)

Pour les modèles à partir de gpt-4o, la mise en cache des prompts est activée par défaut. Comme nos 4 616 tokens d'entrée dépassent largement le seuil de 1 024 tokens, nous sommes en bonne voie. La première requête vérifie si l'entrée est un accès au cache (ce qui n'est pas le cas ici, car c'est la première fois que nous faisons une requête avec ce préfixe), et comme ce n'est pas le cas, elle traite l'entrée complète et la met en cache. La prochaine fois que nous envoyons une entrée qui correspond en partie aux tokens initiaux de l'entrée mise en cache, nous obtiendrons un accès au cache.

Vérifions cela en effectuant une deuxième requête avec le même préfixe :

start = time.time()
response2 = client.responses.create(
model="gpt-4.1-mini",
input=long_prefix + "Qu'est-ce que la régularisation ?"
)
end = time.time()
print("Temps de réponse secondaire :", round(end - start, 2), "secondes")
print(response2.output[0].content[0].text)

En effet ! La deuxième requête s'exécute beaucoup plus rapidement (23,31 secondes contre 15,37 secondes). Cela est dû au fait que le modèle a déjà effectué les calculs pour le préfixe mis en cache et n'a besoin que de traiter la nouvelle partie, "Qu'est-ce que la régularisation ?". En conséquence, grâce à la mise en cache des prompts, nous obtenons une latence considérablement réduite et des coûts moindres, puisque les tokens mis en cache bénéficient d'une remise.

Les pièges potentiels de la mise en cache

Bien que l'activation de la mise en cache des prompts semble simple, plusieurs facteurs peuvent entraîner un échec d'accès au cache. Voici quelques points à considérer :

• Un préfixe de moins de 1 024 tokens ne pourra pas activer la mise en cache. Cela peut être facilement résolu en augmentant artificiellement le nombre de tokens du préfixe.

• Il est crucial de ne pas rompre le préfixe. Même en utilisant des instructions et des prompts système de taille appropriée, il faut veiller à ne pas ajouter de contenu variable au début de l'entrée du modèle. Cela rompra le cache, peu importe la longueur du préfixe suivant. Les données dynamiques, comme l'ajout d'un identifiant utilisateur ou d'horodatages au début du prompt, en sont des exemples typiques.

• La mise en cache ne concerne que la phase de pré-remplissage ; le décodage n'est jamais mis en cache. Cela signifie que même si nous demandons au modèle de générer des réponses suivant un modèle spécifique, les tokens initiaux ne seront pas mis en cache.

Dans certains cas d'utilisation, il n'est pas judicieux d'utiliser la mise en cache des prompts, comme pour des prompts très dynamiques, des requêtes uniques ou des systèmes personnalisés en temps réel.

La mise en cache des prompts peut considérablement améliorer les performances des applications d'IA.