GPU Taskman affiche la consommation de mémoire vidéo en Go par processus et aide à repérer les saturations

Vous lancez un LLM local, augmentez la taille du contexte, et la mémoire vidéo disponible s’épuise. Avant de choisir un modèle plus petit ou d’acheter une autre carte graphique, mieux vaut comprendre où sont passés les gigaoctets. GPU Taskman relève la consommation de mémoire par processus et aide à la rattacher à une charge précise : un modèle, un navigateur ou une autre tâche exécutée en parallèle.

Pour les développeurs, l’intérêt est concret : obtenir un état des lieux avant et après une modification des réglages. Si le problème apparaît après une augmentation de la taille du contexte, comparer les instantanés permet de vérifier quel processus s’est mis à consommer davantage de mémoire. L’estimation de la répartition de la mémoire du modèle donne ensuite une piste sur l’hypothèse à tester.

Ce qu’affiche le gestionnaire

GPU Taskman fonctionne dans le terminal. Il rassemble des informations sur la mémoire vidéo des processus, l’activité du GPU, les bibliothèques chargées et les fichiers des modèles. Dans les configurations prises en charge, il permet de voir quelle pile utilise l’application : CUDA, Vulkan ou Direct3D. Pour les LLM locaux, il propose la reconnaissance des modèles et une estimation de la mémoire consacrée aux poids, au cache KV et aux tampons de travail.

Ces informations n’ont pas toutes le même degré de fiabilité. Le compteur de mémoire indique une consommation mesurée. Le nom du modèle et la répartition supposée de cette consommation nécessitent des indices supplémentaires. La présence d’une bibliothèque CUDA ne suffit pas, à elle seule, à déterminer quel modèle est chargé ni ce qu’il est en train de faire. L’auteur souligne d’ailleurs le caractère expérimental du logiciel dans la documentation du projet.

Il est donc plus utile de lire l’écran en deux temps. D’abord, repérer le processus qui consomme beaucoup de mémoire. Ensuite, examiner les éléments d’explication que l’utilitaire a pu réunir à son sujet. Cette démarche évite de prendre une indication plausible pour le résultat d’une mesure directe.

Comment vérifier où part la mémoire

Prenons une situation courante : le modèle démarre, mais après une modification des réglages, l’application commence à signaler un manque de mémoire. Enregistrez un premier instantané, modifiez un seul paramètre, puis relevez à nouveau les mesures. GPU Taskman propose pour cela une sortie ponctuelle avec --once, un format exploitable par des programmes avec --json et une comparaison avec diff.

La longueur du contexte peut être le premier paramètre à tester. Le cache KV conserve des données que le modèle utilise pour traiter une séquence, et sa taille est liée au contexte. Le comportement précis dépend toutefois du moteur et des réglages : la mémoire peut être réservée à l’avance. Il est donc utile de comparer les mêmes étapes du fonctionnement de l’application, par exemple juste après le chargement du modèle ou après une requête identique.

Si vous changez simultanément le modèle, la taille du contexte et d’autres réglages, la hausse de consommation sera plus difficile à expliquer. L’intérêt pratique de cette comparaison est de resserrer la recherche de la cause. Elle permet aussi de repérer un autre processus qui continue à occuper de la mémoire après la fin de votre tâche. Le moniteur ne libère lui-même aucune mémoire et ne corrige pas les réglages du modèle.

Les limites à connaître

WSL demande une attention particulière. Les informations sur la mémoire y proviennent de Windows, et il faut reconstituer l’attribution des différentes valeurs aux processus Linux. Le programme distingue les correspondances fiables des suppositions et peut afficher n/a lorsque les données sont insuffisantes. Avant de tirer une conclusion sur un processus précis, il faut consulter cette indication.

Le projet annonce une prise en charge de Windows, Linux, WSL et Apple Silicon, mais la disponibilité des différents indicateurs dépend de la plateforme, du pilote et de la carte graphique. Une interface identique ne garantit pas le même niveau d’observation sur toutes les machines. La ventilation de la mémoire des LLM doit elle aussi servir de piste de diagnostic : l’utilitaire ne lit pas le contenu de la VRAM et ne fournit pas un inventaire complet des objets qui s’y trouvent.

L’installation s’effectue avec les commandes uv tool install gputaskman ou pipx install gputaskman ; vous pouvez ensuite lancer gputaskman ou gtm. Le mieux est de commencer par un test reproductible sur votre propre charge de travail. Si les instantanés aident à expliquer la consommation de mémoire, l’outil est déjà utile : vous disposez d’éléments pour modifier un réglage précis et vérifier le résultat avant de consacrer du temps et de l’argent au remplacement du matériel.