Optimiser le cache

Le cache, facteur clé de performance

Les hits de cache sont le facteur principal de la vitesse d’inférence de grok-code-fast-1. Quand le début de votre requête (le préfixe) est identique à une requête précédente, le modèle récupère les calculs déjà effectués depuis le cache. Résultat : la réponse arrive beaucoup plus vite.

Comprendre ce mécanisme vous permet d’optimiser vos interactions pour obtenir des réponses quasi-instantanées.

Comment fonctionne le cache

Le cache fonctionne sur le principe du préfixe commun :

1. Vous envoyez un prompt avec un historique de conversation
2. Le modèle calcule les tokens du début (prompt système + historique)
3. Si ce préfixe a déjà été calculé récemment, il est récupéré du cache
4. Seuls les nouveaux tokens (votre dernier message) nécessitent un calcul complet

Plus le préfixe commun est long, plus le gain est important. Dans un scénario de pair-programming où vous échangez plusieurs messages, chaque requête réutilise tout l’historique précédent.

La règle d’or : ne pas modifier l’historique

C’est le point le plus important de cette leçon. Évitez de modifier l’historique du prompt entre deux requêtes. Toute modification du début de la conversation invalide le cache.

Ce qui casse le cache

• Réordonner les messages dans l’historique
• Modifier un message précédent (même un caractère)
• Supprimer des messages de l’historique
• Insérer un message au milieu de la conversation
• Changer le prompt système en cours de conversation

Ce qui préserve le cache

• Ajouter un nouveau message à la fin de la conversation (comportement normal)
• Garder le prompt système identique tout au long de la session
• Conserver l’historique intact sans modification

Le préfixe stable

Pour maximiser les hits de cache, structurez vos requêtes avec un préfixe stable :

[Prompt système (fixe)]
[Message 1 utilisateur (fixe)]
[Réponse 1 modèle (fixe)]
[Message 2 utilisateur (fixe)]
[Réponse 2 modèle (fixe)]
...
[Nouveau message utilisateur] ← seule partie calculée

Le prompt système est particulièrement important. Il doit être défini une fois au début de la session et ne plus changer. Si vous développez un agent API avec grok-code-fast-1, écrivez un prompt système complet et stable.

Impact concret

Dans un scénario typique de pair-programming avec 10 échanges :

• Sans optimisation cache : chaque requête recalcule tout l’historique. La latence augmente à chaque échange
• Avec cache optimisé : seul le dernier message est calculé. La latence reste constante, quelle que soit la longueur de la conversation

La différence peut être de l’ordre de quelques secondes à chaque interaction. Sur une session de développement d’une heure avec des centaines d’échanges, le gain cumulé est considérable.

Pour les développeurs d’agents

Si vous construisez un agent API qui utilise grok-code-fast-1 dans des scénarios séquentiels d’utilisation d’outils :

• Le préfixe reste identique entre chaque appel d’outil, ce qui est récupéré du cache automatiquement
• Ne reformatez pas les résultats d’outils avant de les renvoyer au modèle
• Évitez les transformations d’historique (résumé, compression) qui casseraient le cache
• Gardez le même ordre de messages à chaque appel

Points clés à retenir

• Les hits de cache sont le facteur principal de vitesse de grok-code-fast-1
• Ne jamais modifier l’historique du prompt entre deux requêtes
• Le prompt système doit être stable tout au long de la session
• Ajouter à la fin, ne jamais modifier le début
• Dans les agents séquentiels, le cache fonctionne naturellement si l’historique est préservé