Comment la longueur du contexte affecte-t-elle le débit des LLM locaux ?

Un contexte plus long réduit généralement le débit des LLM locaux en augmentant le calcul de préremplissage, la mémoire du cache KV, le travail de décodage et la concurrence pour la capacité des séquences simultanées.

L’effet ne suit pas une courbe universelle de tokens par seconde. La longueur du prompt augmente principalement la phase de préremplissage, tandis que le contexte actif croissant oblige les étapes de décodage ultérieures à parcourir davantage de clés et de valeurs mises en cache. Si la mémoire est saturée, le serveur peut accepter moins de requêtes, préempter des séquences, déporter le cache ou refuser des tâches ; le débit dépend donc du modèle, du noyau d’attention, du matériel, de l’ordonnanceur et de la combinaison de charges.

La longueur du prompt augmente le travail de préremplissage avant le premier token

Pendant le préremplissage, le modèle traite tous les tokens du prompt afin de créer les états cachés et le cache initial de clés-valeurs. Le travail d’attention standard augmente fortement avec la longueur de la séquence, même si les noyaux optimisés réduisent le trafic mémoire et les facteurs constants sans rendre l’entrée gratuite.

L’article sur l’attention optimisée pour les E/S présente un algorithme d’attention exacte tenant compte des E/S, qui réduit les transferts entre les niveaux de mémoire du GPU. Ses gains de vitesse montrent pourquoi le choix du noyau modifie la courbe, tandis que le contexte sous-jacent nécessite toujours du calcul et des mouvements de données.

Un serveur qui ne communique que le nombre de tokens décodés par seconde peut masquer ce coût. Pour la RAG et les longues conversations, le délai avant le premier token et le nombre de prompts traités par seconde sont nécessaires en complément du débit de sortie. Cette distinction reste visible lors des tests ultérieurs en conditions domestiques.

Le cache KV augmente avec chaque token de contexte actif

Le décodage autorégressif stocke les clés et les valeurs des tokens précédents afin de ne pas les recalculer. La mémoire du cache évolue avec la longueur de la séquence active, le nombre de couches, les dimensions, la précision et le nombre de séquences simultanées ; les contextes plus longs réduisent donc le nombre de requêtes pouvant tenir simultanément.

L’article de vLLM sur PagedAttention présente PagedAttention afin de réduire la fragmentation du cache KV et de permettre un partage flexible. Une meilleure allocation augmente la capacité utilisable, mais ne supprime pas les octets nécessaires au contexte conservé lui-même. Le résultat intermédiaire doit rester inspectable avant toute automatisation.

Lorsque la capacité est épuisée, les systèmes peuvent mettre en file les nouvelles requêtes, expulser ou recalculer le cache, l’échanger avec la mémoire hôte ou réduire la taille du lot. Ces politiques peuvent transformer un benchmark fluide à un seul utilisateur en un bon débit instable avec plusieurs utilisateurs. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

Les étapes de décodage parcourent davantage l’historique à mesure que le contexte augmente

Chaque token généré interroge le cache accumulé, de sorte que les lectures mémoire et le travail d’attention augmentent avec la longueur de la séquence. Le modèle peut rester limité par la bande passante mémoire, tandis que la compression du contexte ou la quantification du cache échangent des économies de mémoire contre la précision et la prise en charge par le noyau.

L’article sur la quantification du cache KV quantifie le cache KV afin de permettre des contextes bien plus longs et identifie explicitement la capacité du cache comme un goulot d’étranglement des longs contextes. Cela montre que la longueur de contexte maximale annoncée et le débit soutenu efficace sont deux propriétés différentes. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

La limite d’échec consiste à comparer deux contextes tout en modifiant la composition du prompt, la longueur de sortie, la concurrence ou la précision du cache. La qualité de la récupération peut s’améliorer grâce à des éléments supplémentaires, même lorsque le débit du système diminue ; les performances et l’utilité des réponses doivent donc être évaluées sur des axes distincts.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Évaluez le débit selon plusieurs catégories de longueur de prompt

Créez des catégories de prompts fixes, par exemple 512, 2 048, 8 192 et 16 384 tokens, avec des longueurs de sortie contrôlées. Exécutez chaque test avec un seul utilisateur, puis avec une concurrence croissante, en enregistrant le nombre de tokens du prompt par seconde, le nombre de tokens de sortie par seconde, le délai avant le premier token, la latence entre les tokens, l’utilisation du cache, le temps d’attente en file, les préemptions et les échecs.

Comparez la courbe avec le ralentissement des longues conversations décrit dans le ralentissement de la fenêtre de contexte. Gardez le modèle, la quantification, l’échantillonnage, l’ordonnanceur et le matériel constants, puis répétez les tests avec la mise en cache des préfixes ou la quantification du cache uniquement dans le cadre d’expériences distinctes. Cette dépendance doit rester explicite dans l’interface finale.

Définissez un budget de contexte opérationnel à partir du bon débit correspondant à l’objectif de latence requis, et non à partir de la longueur maximale acceptée par le modèle. Ne récupérez ou ne résumez du contenu que lorsque le gain de qualité qui en résulte justifie le coût mesuré du préremplissage et du cache.