Pourquoi les réponses des LLM locaux deviennent-elles plus courtes sous une charge simultanée ?

Les réponses des LLM locaux raccourcissent sous charge lorsque la couche de service échange une partie du budget de génération contre davantage de concurrence au moyen de plafonds, d'échéances, de préemptions ou de requêtes ayant échoué.

Le modèle ne décide pas intrinsèquement d'être plus concis parce qu'un autre utilisateur est arrivé. Avec un prompt et un état d'échantillonnage fixes, la concurrence devrait principalement modifier le temps d'attente et le rythme de génération des tokens. Des réponses plus courtes indiquent que l'environnement d'exécution, la passerelle, le client ou le gestionnaire de mémoire a modifié une condition d'arrêt effective, annulé le traitement ou renvoyé un flux partiel après le franchissement d'un seuil de pression.

La concurrence augmente la mémoire KV et active les limites de service

Chaque séquence active conserve des blocs de cache KV qui augmentent avec le contexte conservé et les tokens générés. Lorsque plusieurs requêtes partagent un même accélérateur, l'environnement d'exécution peut réduire la sortie maximale, refuser l'admission, préempter une séquence ou déplacer des blocs vers le stockage afin de maintenir le lot dans les limites de mémoire.

Une architecture de service fondée sur l'allocation paginée du cache KV utilise des blocs KV paginés pour réduire la fragmentation et permettre une concurrence accrue. Son mécanisme améliore la capacité, mais il montre également que chaque séquence active consomme une allocation mémoire croissante jusqu'à son achèvement ou son éviction.

Une passerelle peut imposer un budget de tokens distinct par requête ou global. Si ce budget est calculé à partir de la capacité disponible, de la priorité ou de la profondeur de la file d'attente, des prompts identiques reçoivent une sortie maximale différente, même si les poids du modèle et les paramètres d'échantillonnage semblent inchangés.

Les échéances et la préemption peuvent renvoyer une réponse partielle d'apparence valide

Les systèmes interactifs appliquent souvent des échéances en temps réel, des délais d'inactivité du flux ou une annulation par le client. Lorsque la livraison des tokens entre deux étapes ralentit sous charge, ces limites sont atteintes plus tôt dans la réponse sémantique, et certaines API renvoient les tokens déjà émis au lieu d'afficher une erreur manifeste.

La méthode de préremplissage par morceaux divise le traitement du prompt en segments plus petits afin d'empêcher les préremplissages longs de bloquer le décodage. Ce travail montre comment les changements de planification influencent le délai avant le premier token et la latence entre les tokens sous une pression composée de requêtes mixtes. Cette distinction reste observable lors des tests ultérieurs à domicile.

Selon le moteur, la préemption peut conserver une requête pour la reprendre ultérieurement, la redémarrer ou l'abandonner. Si le client se déconnecte pendant la pause, le serveur peut enregistrer une annulation tandis que l'interface affiche comme réponse terminée un préfixe grammatical, mais incomplet.

L'échantillonnage seul ne devrait pas être systématiquement corrélé à la charge

Le décodage stochastique produit naturellement des longueurs variables lorsque la température et la graine aléatoire diffèrent. Cette variation peut coïncider avec la charge sur de petits échantillons, mais la concurrence ne fournit aucun signal sémantique direct, sauf si un état partagé, une stratégie adaptative ou un défaut logiciel modifie le chemin de décodage.

Les recherches sur la planification tenant compte des SLO modélisent le routage et la planification tout en protégeant les objectifs de temps entre les tokens. La séparation entre le débit, le TTFT et les échéances de décodage montre pourquoi la politique de capacité doit être mesurée indépendamment de la qualité de sortie du modèle. Le résultat intermédiaire doit rester inspectable avant toute automatisation.

La limite d'analyse consiste à accuser le planificateur avant de vérifier les métadonnées d'arrêt. Les tokens de fin de séquence, les plafonds de longueur explicites, les annulations du client, les échéances du serveur, les erreurs de mémoire insuffisante et les déconnexions du transport sont des causes différentes. Seuls des raccourcissements répétés et contrôlés, accompagnés de raisons d'arrêt correspondantes, permettent d'étayer un mécanisme lié à la charge.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Comparez la longueur et la raison d'arrêt à des niveaux de concurrence fixes

Rejouez des prompts et des graines fixes avec une, deux, quatre et huit requêtes concurrentes. Enregistrez le nombre maximal de tokens demandé, le nombre réel de tokens de sortie, la raison de fin, le temps d'attente en file, le TTFT, la latence entre les tokens, l'échéance en temps réel, la déconnexion du client, le nombre de préemptions, les octets KV, la VRAM libre et l'erreur du serveur.

Reliez le comportement de la mémoire aux limites de charge concurrente, puis répétez sans délais d'expiration de la passerelle et avec une limite d'admission fixe. Conservez les prompts, les modèles de prompt, l'échantillonnage et le code client afin que la seule modification prévue soit la concurrence. Cette limite doit être mesurée séparément dans des conditions d'exploitation réalistes.

Considérez une sortie plus courte comme un défaut de service lorsque le taux d'achèvement ou la couverture sémantique baisse avant le budget annoncé. Si seule la latence augmente tandis que les raisons de fin restent EOS, recueillez davantage d'essais avec graine fixe ; si les délais d'expiration ou les plafonds dominent, rendez ces politiques explicites et dimensionnez-les correctement.