Quelles sont les causes des creux d’utilisation du GPU lors du traitement continu de lots de LLM ?
Les écarts d'utilisation du GPU apparaissent généralement lorsque le planificateur de traitement par lots continu ne parvient pas à assembler du travail exécutable ou à alimenter l'accélérateur sans blocage dû à une dépendance.
Un serveur LLM domestique peut afficher un débit élevé tout en présentant des creux périodiques d'utilisation du GPU entre les itérations de décodage. Le traitement par lots continu retire les séquences terminées et en admet de nouvelles, mais il ne peut pas créer de travail lorsque les arrivées sont peu fréquentes, que les blocs KV sont indisponibles, que de longs prefills bloquent le décodage ou que l'environnement d'exécution sur CPU prépare les lots trop lentement. La synchronisation et les transferts de mémoire peuvent également créer des écarts, même lorsque la file de requêtes est pleine.
L'approvisionnement en requêtes et le renouvellement des séquences peuvent vider un lot
Le traitement par lots continu remplace les séquences terminées aux limites des itérations. Si les arrivées sont irrégulières, que les sorties se terminent simultanément ou que les limites d'admission maintiennent les requêtes en dehors de la file exécutable, le nombre de tokens actifs peut passer sous la plage de fonctionnement efficace du GPU.
Les benchmarks de l'appartenance continue aux lots comparent l'appartenance statique et continue des requêtes avec différentes longueurs d'entrée, longueurs de sortie et heures d'arrivée. Le signal caractéristique est un faible nombre de tokens exécutables pendant les creux d'utilisation, malgré un accélérateur en bon état et l'absence d'erreur de mémoire.
Une file réellement vide n'est pas un défaut du planificateur. Comparez le taux d'arrivée, les séquences admises et les tokens planifiés par itération avant d'interpréter chaque période d'inactivité comme une capacité perdue. Cette distinction reste visible lors des tests domestiques ultérieurs.
Le prefill, le décodage et l'allocation KV créent des bulles dans le planificateur
Le prefill traite de nombreux tokens de prompt avec des noyaux gourmands en calcul, tandis que le décodage fait progresser chaque séquence d'un token et est souvent limité par la mémoire. Le mélange de ces phases peut retarder le décodage, et la réservation ou la récupération des blocs KV peut suspendre l'admission entre les itérations.
La conception de la planification du prefill par segments utilise un prefill segmenté pour empêcher les longs prompts de monopoliser les itérations de service. Son mécanisme identifie des écarts qui correspondent aux limites du prefill, à l'allocation KV ou à la préemption des requêtes, plutôt qu'à une demande insuffisante. Le résultat intermédiaire doit rester inspectable avant toute automatisation.
Si les écarts du GPU augmentent avec la longueur du prompt, mais pas avec celle de la sortie, la planification du prefill est la cause la plus probable. S'ils suivent la pression exercée sur le cache ou les expulsions, l'admission mémoire est responsable, même lorsque la file reste pleine. Cette limite doit être mesurée séparément dans des conditions d'utilisation réalistes.
L'alimentation par le CPU et la synchronisation entre appareils peuvent affamer les noyaux
La tokenisation, l'échantillonnage, les décisions du planificateur, les métadonnées des tenseurs, les copies de l'hôte vers l'appareil, les opérations collectives distribuées et la journalisation ont lieu en dehors des noyaux principaux. Un thread CPU saturé ou une synchronisation bloquante peut laisser le GPU en attente entre des lots pourtant valides. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.
Les recherches sur les interférences entre prefill et décodage séparent les ressources de prefill et de décodage afin de réduire les interférences et de respecter les objectifs de latence. Le résultat confirme qu'un seul graphique d'utilisation combine le comportement du planificateur, de l'hôte, des communications et de l'accélérateur. Cette dépendance doit rester explicite dans l'interface finale.
La limite de défaillance est un intervalle d'échantillonnage court qui signale des limites normales de noyaux comme une utilisation nulle. Confirmez les écarts avec une trace ou des compteurs matériels ; la moyenne du tableau de bord peut créer des creux apparents qui ne réduisent pas le nombre de tokens par seconde.
Alignez les chronologies de la file, du planificateur et des noyaux
Rejouez des arrivées contrôlées, régulières et en rafales, tout en enregistrant les requêtes en attente, admises et en cours d'exécution, les tokens de prompt et de décodage par itération, les blocs KV libres, les préemptions, le temps du planificateur CPU, la tokenisation, l'échantillonnage, les copies, les opérations collectives, les intervalles entre lancements de noyaux, les fréquences du GPU et le débit de sortie.
Comparez le schéma avec le comportement du traitement par lots continu, puis faites varier un par un le taux d'arrivée, la longueur du prompt, la taille du prefill segmenté, le budget du cache et l'affinité CPU. Conservez le même modèle, la même quantification et le même objectif de latence. Le résultat doit donc être vérifié par rapport aux éléments probants d'origine.
Classez chaque creux comme une absence de demande, un blocage d'admission, une interférence du prefill, une pression sur le cache, une saturation de l'hôte ou un problème de synchronisation avant tout réglage. Optimisez la limite responsable ; forcer un lot plus important ne peut pas résoudre une file vide ou un thread hôte bloqué.
Produits recommandés
Centre Tech & IA
Plus à lire
Qu’est-ce qui amène un planificateur d’agent IA à répéter des étapes déjà effectuées ?
Suivez les étapes répétées du planificateur à travers la persistance de l’état, les preuves d’achèvement, l’analyse des résultats des outils, la conservation du contexte,...
Qu’est-ce qui provoque des erreurs d’autorisation uniquement dans les sous-processus des agents d’IA ?
Comparez l’identité du processus parent et du processus enfant, la vue du système de fichiers, l’environnement, les capacités, la politique de sécurité et le...
Quelles sont les causes de la saturation du processeur lorsque le transcodage matériel et l’IA vidéo s’exécutent simultanément ?
Suivez la saturation du processeur au niveau du déchargement des codecs, de la conversion des pixels, des copies d’images, du prétraitement de l’IA, de...
