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 l'impact du nombre de tokens d'entrée sur la latence des outils de chat basés sur des LLM. Dans cet article, nous explorerons comment la mise en cache KV (clé-valeur) influe sur la latence du temps jusqu'au premier token (TTFT) et sur le débit des appels LLM.
L'impact des caches KV sur le TTFT
Les LLM sont des modèles autorégressifs, où la génération du i-ème token dépend de tous les tokens générés auparavant. Cela signifie que le calcul des scores d'attention pour le i-ème token implique toutes les mêmes opérations que celles effectuées pour le (i-1)-ème token, auxquelles s'ajoutent les calculs supplémentaires pour ce dernier token. C'est une excellente occasion de mise en cache.
La mise en cache de ces valeurs a les implications suivantes :
- La phase d'initiation, dont nous avons appris dans l'article précédent qu'elle correspond à la génération du premier token, n'est pas affectée par la stratégie de mise en cache KV puisqu'il n'y a pas d'étapes précédentes. Cette phase remplit désormais le cache KV pour les étapes suivantes.
- Pour la phase de décodage, nous n'utilisons plus toute la séquence comme entrée, mais uniquement le dernier token généré et le cache KV.
Alors, comment le calcul de l'attention évolue-t-il désormais ? Comme nous l'avons évoqué dans le dernier article, le calcul des scores d'attention au sein d'un Transformer implique des multiplications matricielles, et multiplier une matrice de forme (n, p) par une autre matrice (p, m) implique 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 signifie que le coût de cette opération devient 2*p*w^2 — une relation quadratique. Cependant, puisque la requête pour les générations suivantes est désormais un seul token, le calcul est linéaire (2*p*1^2).
Cela explique comment les complétions au sein d'un seul appel LLM bénéficient de la mise en cache, mais si ce cache est conservé, il peut être utilisé entre différents appels LLM. Deux manières possibles d'en tirer parti sont :
1. La mise en cache dans les cas d'usage multi-tours au sein d'une seule conversation
2. La mise en cache entre des workflows qui ont des préfixes similaires
Pouvoir 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
Heureusement pour nous, le cache KV d'Azure peut conserver ces calculs entre différents appels LLM. Leur documentation indique que « le débit que vous pouvez atteindre sur le point de terminaison dépend de la taille d'entrée, de la taille de sortie, du taux d'appels et du taux de correspondance du cache ». En fait, ils suggèrent que « mélanger les appels peut réduire votre taux de succès du cache car ils se disputent tous deux le même espace. Dans la mesure du possible, il est recommandé d'avoir des déploiements distincts pour chaque charge de travail ».
Les données relatives à l'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 utilisant les unités de débit provisionné (PTU) d'Azure. Les appels mis en cache avaient exactement le même prompt sur les 25 appels. En revanche, les exécutions sans cache comportaient l'heure de la requête en cours comme préfixe dans chaque prompt, ce qui invalidait le cache de préfixe.
À noter de nouveau ici, au cas où vous auriez manqué notre premier article sur la latence, nous avons utilisé les déploiements de modèles PTU d'Azure pour exécuter ces tests. Les PTU sont un moyen d'obtenir une capacité de traitement réservée rien que pour vous — débloquant des performances prévisibles et atténuant les variations de latence observées via leurs services à la demande. Cela garantit que nos données ne sont pas faussées par les charges des centres de données.
Le graphique ci-dessous zoome sur le coin inférieur gauche pour une meilleure lisibilité.
Cela nous montre que chaque token d'entrée mis en cache économise environ 0,15 ms, soit la différence entre les deux pentes. J'aimerais souligner que 0,15 ms peut sembler une quantité négligeable, mais les données illustrent que la mise en cache de 1000 tokens entre les appels entraîne une réduction du TTFT de 100 ms !
Faire de Glean une meilleure expérience
En matière d'expérience utilisateur, nous savons que quelques millisecondes peuvent suffire à faire la différence entre une session satisfaisante ou non. Nous garderons ces résultats à l'esprit à mesure que nous continuons à développer et à améliorer Glean Assistant pour offrir un service meilleur et plus rapide à nos utilisateurs.
Vous souhaitez en savoir plus sur Glean ? Obtenez une démo gratuite dès aujourd'hui — ou consultez notre page Carrières si vous souhaitez nous aider à construire vous-même l'avenir de l'IA d'entreprise !
