LLM local à court de VRAM ? Voyez poids vs cache KV avec gputaskman

Votre modèle local s'est chargé sans problème hier, aujourd'hui il plante au chargement ou rame, et la seule chose que vous avez modifiée est la longueur de contexte. Un coupable courant est le cache KV, et un outil de terminal gratuit appelé gputaskman peut vous le montrer au lieu de vous laisser deviner.

Un moniteur GPU classique vous indique à quel point la VRAM est pleine. C'est le « quoi », pas le « pourquoi ». Le README de gputaskman (vérifié le 5 novembre 2026) se décrit comme « Un htop pour ce qu'il y a à l'intérieur de votre GPU, pas seulement à quel point il est plein. » C'est un projet expérimental et précoce, sous licence MIT, alors traitez-le comme une loupe pratique, pas comme un verdict.

Ce qui remplit réellement votre VRAM#

Voyez la VRAM comme une valise. Trois choses y entrent :

• Les poids : le modèle lui-même. Taille fixe pour un modèle et une quantification donnés.
• Le cache KV : la mémoire à court terme du modèle de votre conversation. Il grandit à mesure que le contexte grandit.
• Les tampons de calcul : l'espace de travail dont le runtime a besoin pendant qu'il travaille.

Quand les gens disent « le modèle ne rentre pas », ils veulent souvent dire que les poids rentrent mais que le cache demandé en plus ne rentre pas. Cette distinction décide du correctif, et c'est exactement ce qu'un moniteur ordinaire masque.

Installez gputaskman et regardez par processus#

Le README liste trois façons d'y accéder : un ZIP Windows portable, un clone lancé avec uv run --locked gputaskman, ou pip dans un environnement virtuel Python 3.11+. Les plateformes, telles que le README les décrit :

• Windows 10/11 64 bits avec un GPU NVIDIA ou AMD (ZIP x64 et ARM64 sur la page Releases) ;
• Linux et WSL avec un GPU NVIDIA (glibc 2.35+ ; WSL peut lire les compteurs de l'hôte Windows) ;
• macOS sur Apple Silicon uniquement depuis un clone des sources, pas de build portable.

Les ZIP Windows ne sont pas signés. Téléchargez-les uniquement depuis la page Releases du dépôt officiel, github.com/shanselman/gputaskman. Copiez les commandes exactes du README : le projet est jeune et les options peuvent changer.

Une fois lancé, deux vues comptent pour ce problème :

1. Vue appareil : utilisation de la VRAM, activité du GPU, PCIe, température, alimentation, fréquences et graphiques d'historique. Utile pour « quelque chose a-t-il fait un pic ? »
2. Vue processus : mémoire GPU locale par processus, RAM système accessible au GPU, activité du moteur et runtime détecté (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

Dans la vue processus, trouvez votre serveur de modèle (pour Ollama, son runner intégré). Puis vérifiez le reste de la liste. Si un navigateur ou un jeu occupe quelques gigaoctets, vous avez votre réponse sans toucher au modèle.

Poids, cache KV, tampons : d'où viennent les chiffres#

L'inspecteur de modèle affiche l'architecture, la quantification et les tailles de tampons lorsqu'elles sont disponibles. Une mise en garde compte : selon le README, les poids, le cache KV et les tampons de calcul proviennent des journaux de chargement du runtime lorsque la journalisation compatible est activée. Pour llama.cpp, lancez votre propre llama-server avec journalisation (--log-file server.log -lv 4 ; le README indique que le niveau 4 est nécessaire pour les tailles de tampons). Pour Ollama, gputaskman utilise server.log d'Ollama s'il est disponible. Sinon, ce sont des estimations à partir des métadonnées GGUF et de la taille du contexte, en supposant un placement de type llama.cpp. La comptabilité KV par modèle au sein d'un même processus n'est pas encore prise en charge.

Lisez donc une répartition estimée comme « approximativement », et une répartition issue des logs comme « ce que le runtime a rapporté ». Pour Ollama, le README indique que les runners intégrés sont détectés, que les blobs GGUF sont nommés d'après les manifestes d'Ollama, et que server.log est utilisé lorsqu'il est disponible. La prise en charge de LM Studio est partielle : les modèles sont nommés d'après son dossier et interrogés via son API locale, mais cela a été testé avec des réponses de fixture, pas de bout en bout.

Vous pouvez aussi enregistrer deux instantanés en JSON et les comparer avec la commande diff. C'est une façon propre de répondre à « qu'est-ce qui a changé quand je suis passé d'un contexte de 4K à 16K ? » : prenez un instantané, changez le réglage, rechargez, prenez-en un autre.

Quel levier actionner#

Lire la répartition vous donne une décision, pas seulement une image.

Les poids sont la grosse part. Passez à une quantification plus petite ou à un modèle plus petit. C'est le seul levier qui réduit les poids. Si vous voulez les calculs de mémoire derrière tout ça, voir Un modèle 125B peut-il tourner sur un GPU de 16 Go ?

Le cache KV est la grosse part. Raccourcissez le contexte. Dans Ollama, vous pouvez l'essayer directement dans la session :

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 n'est qu'une valeur d'exemple ; choisissez ce dont votre tâche a réellement besoin (commande selon la documentation d'Ollama, vérifiée le 5 novembre 2026).

Si vous constatez plus tard une lenteur étrange sur le traitement du prompt avec un cache quantifié dans llama.cpp, ce correctif pour le cache KV q5_1 est l'étape suivante. Pour savoir ce que contient une fenêtre de contexte au départ, lisez Qu'est-ce qu'une fenêtre de contexte ?

Un autre processus est la grosse part. Fermez-le, ou exécutez-le sur le GPU intégré. Rien dans le modèle n'a besoin de changer.

Si ça ne fonctionne pas#

• La répartition semble fausse. Vérifiez s'il s'agit d'une estimation (pas de logs de chargement compatibles). Avec llama.cpp, lancez votre llama-server avec --log-file server.log -lv 4 et rechargez le modèle. Avec Ollama, gputaskman utilise server.log s'il existe ; une étiquette d'estimation y est normale.
• LM Studio affiche moins de détails. La prise en charge est partielle, comme indiqué ci-dessus.
• Pas de GPU NVIDIA ou AMD. L'outil ne couvre que les charges de travail GPU locales ; les charges CPU uniquement, NPU uniquement et cloud sont hors périmètre.
• macOS. Lancez depuis un clone des sources ; il n'y a pas de build portable.

Quand un modèle hébergé est la solution la plus simple#

Supposez que vous ayez besoin d'un long contexte pour une tâche, comme résumer un gros document, et que votre GPU ne fasse tenir le modèle qu'avec un contexte court. Vous pouvez continuer à régler, ou sortir la VRAM de l'équation. Pour des tâches comme celle-là, CheapTokens propose DeepSeek-V4-Flash : contexte de 380K, jusqu'à 32 768 jetons de sortie par réponse, un prix unique à toute heure du jour, via une API compatible OpenAI. GLM-5.3-Flash a un contexte de 390K et jusqu'à 8 192 jetons de sortie.

L'appel est au format OpenAI habituel (mettez votre clé dans une variable d'environnement) :

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

Les détails de configuration sont dans la documentation. Une règle empirique pour décider : si une tâche a continuellement besoin de plus de contexte ou d'un modèle plus gros que ce que votre carte contient, et que la vue processus montre que votre VRAM est déjà bien utilisée, envoyez cette tâche à l'API et gardez les petites tâches rapides en local. Exécuter DeepSeek en local ou utiliser une API ? approfondit le compromis.

Supposez que vous résumiez 100 gros documents, chacun de 60 000 jetons d'entrée et 1 000 jetons de sortie (bien dans la fenêtre de 380K). Voici ce que cela coûte aujourd'hui :

Sur ces chiffres, $0.001 par document est le prix en vigueur pour un tel appel, et au total, entrée et sortie comptées ensemble, cela reste en dessous d'OpenRouter.