Les grands modèles de langage locaux semblent incroyablement rapides au début. Vous chargez un modèle de 7B ou 13B paramètres, lancez un prompt court, et les tokens défilent sur l'écran à un rythme confortable. Puis vous collez un long bloc de code, ou votre historique de chat s'étire sur une douzaine de tours, et le modèle commence à ramer. Le ralentissement est rarement progressif. C'est un précipice. Un instant, le GPU génère des tokens à pleine puissance ; l'instant d'après, votre moniteur système indique une montée de la pression mémoire et la génération commence à saccader. Vous ne pouvez pas prédire exactement quand cela arrivera avec une formule simple. Votre seul guide fiable est le matériel lui-même.

Le coût caché du contexte

Chaque token que vous générez ajoute un état au cache KV. Ce cache stocke les clés et les valeurs calculées pendant les phases de prefill et de génération, et il réside en mémoire aux côtés des poids de votre modèle, des tampons d'attention et de la surcharge d'exécution. Sur un GPU grand public typique doté de 12 Go ou 16 Go de VRAM, le cache KV finit par entrer en compétition pour l'espace avec tout le reste. Lorsque la mémoire vidéo dédiée est pleine, le système d'exploitation ne renvoie pas d'erreur pour s'arrêter. Il déverse discrètement le surplus dans la mémoire partagée, transférant les données entre le GPU et la RAM système via le bus PCIe. Ce bus est rapide pour les transferts de fichiers, mais il est d'une lenteur extrême comparé à la bande passante mémoire interne d'une carte graphique. Le résultat n'est pas une légère baisse de performance. C'est un effondrement.

Trois signaux indiquant que le précipice est atteint

Surveillez vos moniteurs matériels pendant que le modèle tourne. Vous verrez trois signaux clairs une fois que la chute de performance survient.

  • La VRAM partagée augmente. Il s'agit de la mémoire que le pilote du GPU a déplacée de la VRAM dédiée vers le pool géré par le système d'exploitation hôte. Dès que cette métrique dépasse zéro, vous avez franchi la limite.
  • L'utilisation de la RAM système gonfle. Le surplus doit bien atterrir quelque part, et cette destination est votre mémoire principale. Si l'utilisation de votre RAM augmente pendant que le modèle génère des tokens, c'est que des données sont déchargées du GPU.
  • La vitesse d'évaluation chute de moitié ou plus. Un ralentissement de 10 % peut signifier un bridage thermique ou des processus en arrière-plan. Une chute de 50 %, ou pire, signifie que le goulot d'étranglement s'est déplacé des cœurs tensoriels vers la bande passante mémoire et la latence PCIe. Lorsque vous voyez la génération passer de deux chiffres à un seul chiffre, vous avez déjà basculé dans le précipice.

Pourquoi votre test de performance rapide vous ment probablement

Un test rapide (smoke test) vous donnera une fausse impression de confiance. Si vous évaluez le modèle avec un prompt de cent tokens, que vous constatez un débit sain et que vous vous arrêtez là, vous n'avez mesuré que la phase de lune de miel. Le cache KV est presque vide. Les couches n'ont pas été sollicitées par un prefill long. L'empreinte réelle ne se révèle qu'après le traitement d'un prompt substantiel et une fois que le cache s'est rempli jusqu'à sa taille de travail réelle. Vous devez tester avec un prefill profond et de longues sessions de génération. Laissez le contexte s'accumuler réellement. Ce n'est qu'à ce moment-là que la pression mémoire se stabilisera et vous montrera la véritable limite.

Trouver votre limite avec llama.cpp

Si vous exécutez des modèles via llama.cpp, vous pouvez mesurer votre limite grâce à une simple arithmétique et un test patient.

1. Mesurez l'utilisation de la mémoire partagée.
Enregistrez votre VRAM dédiée de référence avec un prompt minimal, puis lancez une tâche à contexte long et notez le pic. Soustrayez la valeur de référence du pic. La différence correspond à ce qui a débordé de votre GPU vers la mémoire système partagée.

2. Calculez votre delta de RAM.
Effectuez la même soustraction pour la RAM système. Soustrayez votre RAM de référence du pic de RAM atteint pendant la session longue. Ce chiffre vous indique exactement quelle quantité de données a été transférée de la carte vidéo vers votre mémoire principale. Il quantifie la fuite à travers le bus.

3. Chronométrez l'effondrement de la vitesse d'évaluation.
Comparez votre taux de référence de tokens par seconde avec le taux obtenu après que le modèle a traité un document long. Vous pourriez voir un modèle naviguer à dix-sept tokens par seconde lorsque le contexte est frais, puis ne délivrer que deux tokens par seconde une fois que le cache a gonflé. Cette chute de quinze tokens est votre canari dans la mine de charbon.

Trianguler le point de rupture

To map the curve accurately, do not settle for one lonely data point. Run three distinct trials at 16,000 tokens, 32,000 tokens, and 65,000 tokens. Two points might suggest a line, but two dots are just a guess. The third point proves whether you are looking at measurement noise or a real memory wall. Subtract the results between runs to calculate how much extra memory each additional thousand tokens consumes on your specific combination of model, quantization layer, and GPU.

Once you have that slope, you can project forward. Take your per-token cost, multiply it by the target context length, divide by 1024 to move between units, and add the result to your base model VRAM load. The equation looks like this:

Model VRAM load + (tokens × memory per token ÷ 1024) = Theoretical VRAM usage

This projection is not prophecy. It is a guidepost derived from actual behavior. Use it to estimate your ceiling before you commit to a full production run.

Why Paper Formulas Fail, and What Quantization Can Fix

Textbook formulas ignore the messy reality of local inference. Different architectures allocate attention buffers differently. Your operating system reserves VRAM for the display driver, compositor, and CUDA context. Driver versions change how aggressively they use shared memory. A theoretical equation cannot know how much VRAM is actually free on your machine at 2:00 PM with a browser full of tabs open. You have to run the model on your specific hardware and watch the meters.

Quantization offers partial relief. Moving the KV cache from f16 to q8_0 halves its memory footprint while keeping precision high enough for nearly all practical tasks. That change buys you headroom. It does not grant immunity. The cache still grows linearly with every token you feed in. Eventually, even the reduced size overwhelms your available dedicated memory and the spillover to system RAM begins. The pressure only stops when the context window is capped or the data stops moving.

The Real Takeaway

Do not trust marketing slides, parameter counts, or back-of-the-envelope math. Load the model. Open your system monitor. Run a 65,000-token thread, watch the RAM climb, and count the tokens per second. The numbers that appear on your specific screen, on your specific GPU, are the only numbers that matter. Context always wins. Your job is to know exactly when it wins on your machine.