Qu’est-ce qui fait augmenter progressivement la mémoire d’un serveur de modèles local entre les requêtes ?

La mémoire d’un serveur de modèles local augmente généralement progressivement, car les caches et les allocateurs conservent des blocs réutilisables, même si des références illimitées ou des fuites natives peuvent entraîner une véritable croissance.

Après chaque requête adressée au serveur domestique, un tableau de bord peut afficher une hausse de la RAM ou de la VRAM sans retour au niveau de référence initial. Le runtime peut conserver des blocs KV, des entrées de préfixe, des noyaux, des graphes, des espaces de travail et des blocs de tenseurs libérés afin de les réutiliser. Des longueurs de prompt variables peuvent fragmenter les pools, tandis que les journaux, les sessions, les tampons d’images ou les extensions peuvent conserver indéfiniment certains objets. Ces mécanismes nécessitent donc des éléments de preuve et des limites différents.

Les allocateurs avec mise en cache réservent les blocs libérés pour les réutiliser

Les frameworks GPU évitent les allocations coûteuses sur le périphérique en conservant les blocs libérés dans un pool appartenant au processus. Les tenseurs de l’application peuvent avoir disparu alors que le pilote signale encore le pool réservé comme étant utilisé par le serveur de modèles. Cette distinction reste visible lors de tests domestiques ultérieurs.

Une analyse de l’allocateur explique comment les blocs de mémoire GPU mis en cache arrondissent, divisent, fusionnent et mettent en cache les blocs CUDA. La signature caractéristique est une baisse de la mémoire des tenseurs alloués après une requête, tandis que la mémoire réservée reste élevée et que les requêtes suivantes la réutilisent.

Ce plateau n’est pas automatiquement une fuite. Il devient problématique lorsque le pool empêche un autre service d’allouer de la mémoire ou continue de s’étendre lors de requêtes répétées de forme identique après la phase de démarrage. Le résultat intermédiaire doit rester inspectable avant toute automatisation.

Les caches de service et les formes de requêtes élargissent l’ensemble de travail prévu

Les caches KV augmentent avec le contexte actif, les caches de préfixes conservent les prompts réutilisables, et les graphes ou noyaux compilés couvrent les formes de lots observées. De nouvelles longueurs de contexte, modalités et configurations de concurrence peuvent ajouter des entrées entre les requêtes. Cette limite doit être mesurée séparément dans des conditions d’utilisation réalistes.

Les recherches sur la fragmentation de la mémoire des LLM identifient une fragmentation entre les espaces mémoire des activations et du cache KV dans le service de LLM. Cette observation explique pourquoi la capacité totale peut augmenter même lorsqu’aucune requête active n’est volumineuse. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.

Enregistrez le nombre d’entrées de cache et les classes de formes. Une croissance qui s’arrête lorsque la distribution de charge se stabilise correspond à une phase de démarrage bornée ; une croissance proportionnelle au nombre total de requêtes ou aux identifiants de session uniques suggère l’absence d’éviction. Cette dépendance doit rester explicite dans l’interface finale.

Les objets CPU conservés et les tampons natifs provoquent une véritable augmentation progressive

Les historiques de requêtes, les files d’attente de streaming, les libellés de métriques, les sorties des tokeniseurs, les images importées, les tampons hôte épinglés et les allocations des extensions peuvent rester référencés après leur achèvement. Les instantanés GPU peuvent sembler stables alors que le RSS du processus continue d’augmenter. Le résultat doit donc être comparé aux éléments de preuve initiaux.

Une étude pratique de la mémoire allouée par rapport à la mémoire réservée sépare les signaux de mémoire allouée, réservée et de mémoire du processus. Cette vue en couches évite de diagnostiquer à tort un problème de rétention côté CPU comme un comportement de l’allocateur GPU. Cette distinction reste visible lors de tests domestiques ultérieurs.

La limite caractéristique est une hausse unique suivie d’un niveau maximal stable. Ne parlez de fuite que lorsque des requêtes identiques et contrôlées produisent une croissance continue de la mémoire conservée après prise en compte des limites de cache, du ramasse-miettes et des pools attendus.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Construisez une courbe de rétention de la mémoire par requête

Rejouez des centaines de requêtes identiques, puis des requêtes de longueurs et de modalités mixtes, tout en enregistrant les octets GPU alloués et réservés, les entrées KV et de préfixe, le cache de graphes, la mémoire épinglée, le RSS du processus, le nombre d’objets, les sessions de requêtes, les redémarrages des workers et les instantanés de l’allocateur.

Utilisez la réservation de mémoire après une requête pour distinguer une réservation délibérée après la requête. Répétez l’opération en désactivant séparément chaque cache facultatif, extension, chemin d’importation et libellé de métrique, tout en maintenant le modèle et la concurrence fixes. Le résultat intermédiaire doit rester inspectable avant toute automatisation.

Acceptez une phase de démarrage bornée qui atteint un plateau dans les limites de mémoire déclarées. Ajoutez une éviction lorsque la cardinalité du cache augmente sans avantage, normalisez les formes de requêtes lorsque la fragmentation prédomine et isolez une véritable fuite uniquement lorsque les piles d’allocations conservées indiquent clairement un responsable.