Dernièrement, les entreprises qui développent des LLMs fondamentaux se livrent une véritable course à l’agrandissement des fenêtres de contexte. Après tout, plus l’utilisateur peut faire tenir d’informations dans la fenêtre d’entrée, mieux c’est, non ? Et si c’est vrai, des outils comme Glean Assistant ne devraient-ils pas exploiter ces fenêtres dans leur intégralité pour offrir une expérience plus puissante et plus complète ? ;
Curieux d’en connaître la réponse, nous avons mené quelques tests pour comprendre précisément comment le nombre de tokens en entrée affecte des métriques telles que le time to first token (TTFT) et la latence de chat, ainsi que l’expérience globale de nos utilisateurs.
Quelle est la corrélation entre le nombre de tokens en entrée et le TTFT ?
La première corrélation que nous voulions étudier était celle entre le volume de tokens en entrée et le time to first token. Avant de plonger dans les données empiriques, voici une brève explication de ce que nous nous attendions à observer. ;
À haut niveau, générer le premier token de complétion d’un LLM consiste à tokeniser le prompt entrant, puis à faire passer le tenseur de tokens dans le réseau Transformer — une étape généralement appelée phase d’initialisation. Pour générer les tokens suivants, le dernier token est ajouté au prompt et le processus est répété — on parle alors couramment de phase de décodage. La tokenisation est généralement une opération en temps linéaire, mais l’exécution du prompt initial dans le Transformer ne l’est pas. En réalité, c’est une opération en temps quadratique. ;
Pourquoi ? La réponse courte : le calcul des scores d’attention dans un Transformer implique des multiplications de matrices, et multiplier une matrice de forme (n, p) par une autre matrice (p, m) nécessite 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. La subtilité ici est que la relation est en fonction de la taille de la fenêtre de contexte, et non du nombre de tokens entrants. ;
Tester la corrélation
Ci-dessous, nous présentons les données empiriques issues de cette expérimentation. Nous traçons ici le TTFT P95 pour GPT-4 Turbo en fonction du nombre de tokens du prompt. Pour chaque point de données, 25 appels au LLM ont été effectués. ;
Petit aparté, mais important : ces tests ont été réalisés à l’aide des déploiements de modèle Azure basés sur les provisioned throughput unit (PTU). Les PTU sont une façon d’obtenir une capacité de calcul réservée rien que pour vous — ce qui permet de garantir des performances prévisibles et de limiter les variations de latence observées avec les services pay-as-you-go. Cela évite que nos données soient brouillées par la charge des data centers.
Le graphique ci-dessous zoome sur le coin inférieur gauche pour une meilleure lisibilité. ;
.webp)
Enfin, voici un graphique du TTFT moyen en fonction du nombre de tokens du prompt.
.webp)
Les principales observations sont les suivantes :
- Nous constatons immédiatement une relation linéaire entre ces deux variables — avec un nombre de tokens de prompt allant de 50 à 100 000.
- Nous observons que, pour chaque token d’entrée supplémentaire, le TTFT P95 augmente d’environ 0,24 ms et le TTFT moyen augmente d’environ 0,20 ms.
La question suivante est : pourquoi la corrélation est-elle linéaire ? Cela est probablement lié au fait que les Transformers masquent toutes les valeurs non renseignées dans le vecteur de la fenêtre de contexte avec des zéros, ce qui permet aux GPU d’ignorer de larges portions de la multiplication de matrices. Notez que la relation mentionnée plus haut portait sur la taille de la fenêtre de contexte. ;
De nombreuses sources en ligne indiquent que réduire le nombre de tokens en entrée entraîne bien une baisse de la latence, mais que ce n’est généralement pas un facteur déterminant. D’ailleurs, Open AI indique que « réduire votre prompt de 50 % peut n’apporter qu’une amélioration de latence de 1 à 5 % ». Je soupçonne que les gains de latence mentionnés ici et ailleurs concernent la latence E2E et non le TTFT. Cela semble également cohérent avec les chiffres. ;
Enfin, je tiens à souligner que 0,24 ms peut sembler négligeable, mais les données montrent que scinder un prompt complexe de 3 000 tokens en trois prompts parallèles de 1 000 tokens entraîne une réduction du TTFT de 480 ms — une baisse significative de la latence perçue par l’utilisateur. ;
Améliorer Glean, pour faire encore mieux
Nous garderons ces résultats en tête tandis que nous continuons à développer et à améliorer Glean Assistant afin d’offrir à nos utilisateurs un service plus performant et plus rapide. Si vous souhaitez en savoir plus sur des sujets comme l’accélération des appels d’embedding, ou la corrélation entre latence et tokens en sortie, restez à l’écoute : de nouveaux articles arrivent très bientôt ! ;
Vous souhaitez en savoir plus sur Glean ? Demandez une démo gratuite dès aujourd’hui — ou consultez notre page careers si vous voulez nous aider à construire l’avenir de l’IA en entreprise !
