Ces derniers temps, les grandes entreprises spécialisées dans les LLM se livrent une course pour créer des LLM dotés de fenêtres de contexte de plus en plus larges. Après tout, si l'utilisateur peut insérer davantage d'informations dans la fenêtre d'entrée, c'est encore mieux, non ? Et si c'est le cas, des outils comme Glean Assistant ne devraient-ils pas exploiter l'intégralité de ces fenêtres pour offrir une expérience plus puissante et plus complète ?
Curieux de connaître la réponse, nous avons mené quelques tests pour découvrir précisément comment le nombre de tokens d'entrée influence des indicateurs tels que le temps jusqu'au premier token (TTFT) et la latence des échanges, ainsi que leur impact sur l'expérience globale de nos utilisateurs.
Quelle est la corrélation entre le nombre de tokens d'entrée et le TTFT ?
La première corrélation que nous souhaitions étudier était celle entre le volume de tokens d'entrée et le temps jusqu'au premier token. Avant de plonger dans les données empiriques, voici une explication rapide de ce à quoi nous nous attendions.
Générer le premier token de complétion à partir d'un LLM consiste, à un haut niveau, à tokeniser le prompt entrant et à faire passer le tenseur de tokens dans le réseau Transformer — ce que l'on appelle généralement la phase d'initiation. Pour générer les tokens suivants, le dernier token est ajouté au prompt et le processus est répété — c'est ce que l'on appelle couramment la phase de décodage. La tokenisation est généralement une opération à temps linéaire, mais faire passer le prompt initial dans le Transformer ne l'est pas. En fait, il s'agit d'une opération à temps quadratique.
Pourquoi en est-il ainsi ? La réponse courte est que le calcul des scores d'attention au sein d'un Transformer implique de réaliser 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. La subtilité ici est que la relation porte sur la taille de la fenêtre de contexte, et non sur le nombre de tokens entrants.
Tester la corrélation
Ci-dessous, nous pouvons voir les données empiriques issues d'une telle expérience. Ici, nous traçons le TTFT P95 de GPT-4 Turbo en fonction du nombre de tokens du prompt. Pour chaque point de données, 25 appels LLM ont été effectués.
Petite parenthèse, mais importante : ces tests ont été réalisés à l'aide des déploiements de modèles sur les unités de débit provisionné (PTU) d'Azure. Les PTU sont un moyen d'obtenir une capacité de traitement réservée rien que pour vous — offrant 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 la charge des centres de données.
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 observations clés ici sont :
- Nous remarquons immédiatement une relation linéaire entre ces deux variables – avec un nombre de tokens de prompt allant de 50 à 100 000.
- Nous constatons 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 à se poser est : pourquoi la corrélation était-elle linéaire ? Cela est probablement lié au fait que les Transformers masquent avec des zéros toutes les valeurs non renseignées dans le vecteur de la fenêtre de contexte, ce qui permet aux GPU d'ignorer de larges portions de la multiplication matricielle. Notez ici que la relation mentionnée précédemment portait sur la taille de la fenêtre de contexte.
De nombreuses sources en ligne affirment que réduire le nombre de tokens d'entrée permet effectivement de diminuer la latence, mais ce n'est généralement pas un facteur déterminant. En fait, Open AI indique que « réduire de 50 % votre prompt ne peut entraîner qu'une amélioration de la latence de 1 à 5 % ». Je soupçonne que les améliorations de latence mentionnées ici et ailleurs concernent la latence de bout en bout et non le TTFT. Cela semble d'ailleurs concorder avec les chiffres.
Enfin, je tiens à souligner que 0,24 ms peut sembler négligeable, mais les données montrent que diviser 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 considérable de la latence perçue par l'utilisateur.
Améliorer Glean pour le mieux
Nous garderons ces résultats à l'esprit à mesure que nous continuons à construire et à améliorer Glean Assistant afin d'offrir un service meilleur et plus rapide à nos utilisateurs. Si vous souhaitez en savoir plus sur des sujets tels que l'accélération des appels d'embedding ou la corrélation entre la latence et les tokens de sortie, restez à l'affût de nouveaux articles de blog à venir prochainement !
Vous souhaitez en savoir plus sur Glean ? Demandez une démo gratuite dès aujourd'hui — ou consultez notre page carrières si vous êtes intéressé à nous aider à construire vous-même l'avenir de l'IA d'entreprise !
