Bienvenue dans la suite de notre série sur la latence des LLM ! Dans notre article précédent, nous avons examiné de près comment le nombre de tokens en entrée influe sur la latence des outils de chat basés sur les LLM. Dans cet article, nous allons voir comment le cache KV (key-value) influe sur la latence du temps jusqu’au premier token (TTFT) et sur le débit des appels aux LLM. ;
L’impact des caches KV sur le TTFT
Les LLM sont des modèles auto-régressifs : la génération du ie token dépend de tous les tokens générés auparavant. Cela signifie que le calcul des scores d’attention pour le ie token implique exactement les mêmes opérations que pour le (i-1)e token, auxquelles s’ajoutent les calculs supplémentaires pour ce nouveau token. C’est une excellente opportunité de mettre en cache.
Mettre ces valeurs en cache a les implications suivantes :
- La phase d’initialisation — qui, comme nous l’avons vu dans l’article précédent, correspond à la génération du premier token — n’est pas affectée par la stratégie de cache KV, puisqu’il n’y a aucune étape précédente. En revanche, cette phase alimente désormais le cache KV pour les étapes suivantes.
- Pendant la phase de décodage, nous n’utilisons plus la séquence entière en entrée, mais uniquement le dernier token généré et le cache KV.
Alors, comment le calcul de l’attention se comporte-t-il désormais à l’échelle ? Comme nous l’avons évoqué dans le dernier article, le calcul des scores d’attention dans un Transformer repose sur des multiplications matricielles. Multiplier une matrice de forme (n, p) par une autre matrice (p, m) représente environ 2*m*n*p opérations. Dans le cas de la couche d’attention, m et n sont tous deux égaux à la taille de la fenêtre de contexte, w, ce qui fait passer le coût de cette opération à 2*p*w^2 — une relation quadratique. En revanche, puisque la requête pour les générations suivantes n’est plus qu’un seul token, le calcul devient linéaire (2*p*1^2).
Cela explique comment les complétions au sein d’un unique appel LLM bénéficient de la mise en cache. Mais si ce cache est conservé, il peut être utilisé entre plusieurs appels LLM. Deux manières possibles d’en tirer parti :
1. La mise en cache dans des cas d’usage multi-tours au sein d’une même conversation
2. La mise en cache entre des workflows qui partagent des préfixes similaires
La possibilité de réutiliser le cache KV entre les requêtes devrait permettre des gains de latence TTFT ainsi que des améliorations de débit, grâce à l’empreinte mémoire des requêtes concurrentes partageant un préfixe commun.
Résultats de l’expérience
Bonne nouvelle : le cache KV d’Azure peut conserver ces calculs entre les appels LLM. Leur documentation indique que « le débit que vous pouvez atteindre sur l’endpoint dépend de la taille d’entrée, de la taille de sortie, de la fréquence d’appel et du taux de correspondance du cache ». Ils suggèrent même que « mélanger les appels peut réduire votre taux de hit du cache, car ils se disputent tous le même espace. Quand c’est possible, il est recommandé d’avoir des déploiements séparés pour chaque charge de travail ».
Les données d’utilisation de ce cache entre les requêtes sont présentées ci-dessous. Chaque point de données a été obtenu via 25 appels GPT4 Turbo en utilisant les unités de débit provisionné (PTU) d’Azure. Les appels mis en cache utilisaient exactement le même prompt sur les 25 appels. À l’inverse, pour les exécutions sans cache, l’heure de la requête en cours était ajoutée en préfixe à chaque prompt, invalidant ainsi le cache de préfixe. ;
À noter une nouvelle fois — au cas où vous auriez manqué notre premier article sur la latence — nous avons utilisé les déploiements de modèles Azure basés sur les PTU pour réaliser ces tests. Les PTU sont un moyen d’obtenir une capacité de calcul réservée rien que pour vous — ce qui permet des performances prévisibles et atténue les variations de latence observées avec leurs services en paiement à l’usage. Cela garantit que nos données ne sont pas perturbées par la charge des data centers.
Le graphique ci-dessous zoome sur l’angle inférieur gauche pour une meilleure lisibilité. ;
Cela montre que chaque token d’entrée mis en cache permet d’économiser ~0,15 ms — la différence entre les deux pentes. Je tiens à souligner que 0,15 ms peut sembler négligeable, mais les données montrent que mettre en cache 1 000 tokens entre les appels se traduit par une réduction du TTFT de 100 ms !
Améliorer l’expérience Glean ;
En matière d’expérience utilisateur, nous savons que même quelques millisecondes peuvent faire la différence entre une session satisfaisante et une session frustrante. Nous garderons ces résultats en tête à mesure que nous continuons à développer et améliorer Glean Assistant afin d’offrir à nos utilisateurs un service meilleur et plus rapide. ;
Vous voulez en savoir plus sur Glean ? Demandez une démo gratuite dès aujourd’hui — ou consultez notre page carrières si vous souhaitez nous aider à construire l’avenir de l’IA d’entreprise ! ;
