Combien de contexte tient vraiment dans 32 Go
Le contexte, c'est la mémoire de la conversation — tout ce que le modèle a sous les yeux quand il formule sa réponse. C'est le deuxième consommateur de mémoire de la carte après les poids du modèle, et c'est lui, en général, qui décide si une configuration démarre tout court. Nous avons cherché où passe la limite avec 32 Go. La réponse a surpris : le plus souvent, elle n'est pas du côté du matériel.
Neuf profils sur dix ne sont pas limités par la mémoire, mais par le modèle lui-même
Notre machine expose dix profils de travail prêts à l’emploi. Neuf d’entre eux tournent à 262 144 tokens de contexte — et ce n’est pas la limite des cartes, mais le maximum sur lequel ces modèles ont été entraînés. Au-delà de cette valeur, impossible de monter, quelle que soit la mémoire qu’on ajouterait.
C’est la conclusion la plus importante de toute la série de mesures : avec 32 Go, les modèles actuels de la classe 26–35 milliards de paramètres tiennent au contexte complet pour lequel ils ont été conçus. Plus de mémoire n’achèterait pas ici un seul token de plus.
Le seul profil limité par la mémoire est le modèle de 31 milliards avec prise en charge de l’image et de la vidéo — le module de vision et le fichier séparé du souffleur mangent de la place, si bien que le contexte s’arrête à 167 936 tokens. C’est la configuration la plus serrée de tout l’ensemble : à pleine charge, il reste 464 et 144 Mo libres sur les cartes. Le palier suivant ne se charge plus.
Ce que coûte le contexte
Le calcul est linéaire et facile à retenir : environ 200–320 Mo sur chaque carte pour chaque tranche de 8 192 tokens de contexte. L’écart tient à l’architecture du modèle — avec la prise en charge de l’image s’ajoute encore la mémoire du souffleur. Et pourquoi la mémoire se compte séparément sur chacune des deux cartes, nous l’expliquons dans l’article sur le partage du modèle entre les cartes.
L’amplitude entre modèles peut être grande. Un modèle à architecture d’attention hybride consomme environ 35 ko par token, un modèle classique — environ 51 ko. Ce dernier s’arrête pour cette raison à 208 000 tokens au lieu de 262 000, alors qu’il serait lui-même prêt à aller plus loin. L’architecture du modèle pèse donc sur la capacité de contexte autant que la quantité de mémoire.
Comment nous avons mesuré — et pourquoi la méthode évidente ment
Trois choses se sont révélées décisives, et chacune est un piège dans lequel il est facile de tomber.
La mémoire libre se relève après le travail, pas après le chargement. La bibliothèque de calcul réserve son tampon de travail paresseusement — seulement à la première vraie multiplication de matrices. Un modèle peut donc « se charger » avec une marge apparente et s’effondrer à la première question.
La mémoire libre se lit directement, elle ne se calcule pas. Le pilote de la carte garde pour lui environ 423 Mo impossibles à allouer. La soustraction populaire « total moins occupé » gonfle le résultat exactement de cette valeur — elle affiche 528 Mo libres là où il en reste réellement 106.
La réserve s’est révélée statique. Nous avons bombardé les configurations de longues requêtes — de mille à 227 000 tokens, avec rechargements du modèle et traitement répété du contexte complet. Un échantillon toutes les demi-secondes, 14 771 mesures. Variation de la mémoire libre : au plus 2 Mo, et sur deux configurations exactement zéro. La mémoire se réserve d’avance et ne bouge plus.
C’est pourquoi notre seuil d’admission est un modeste 100 Mo libres sur chaque carte. Si l’occupation sautait en cours de travail, il faudrait une marge comptée en gigaoctets. Elle ne saute pas.
Surprise : un contexte plus petit peut laisser moins de mémoire
Le résultat le plus contre-intuitif de toute la série. Sur l’un des modèles, nous avons mesuré la mémoire libre à trois réglages de contexte :
| Contexte | Libre sur la carte 1 | Libre sur la carte 2 |
|---|---|---|
| 262 144 | 1 372 Mo | 416 Mo |
| 212 992 | 536 Mo | 60 Mo |
| 180 224 | 1 026 Mo | 870 Mo |
Descendre en contexte a aggravé la situation. Explication : à certaines valeurs, les tampons de calcul ne tiennent pas et le serveur se replie vers un mode de travail plus simple, qui économise davantage que ne coûte la mémoire de conversation supplémentaire. Chacun de ces résultats se reproduit au mégaoctet près à chaque nouveau chargement.
Conclusion pratique : le contexte se choisit par la mesure sur une grille de valeurs, pas par extrapolation. La règle « moins, donc plus sûr » ne vaut pas ici.
Deux réglages qui ont rendu de la mémoire gratuitement
Un seul emplacement au lieu de quatre. Par défaut, le serveur se prépare à quatre utilisateurs simultanés et réserve des tampons en conséquence — même quand l’utilisateur est seul. La limitation à un seul emplacement a rendu 240–770 Mo par carte, sans changer le contexte ni la vitesse. Le prix : une file d’attente — la deuxième requête attend la première. À la maison, c’est un échange honnête.
Un stockage plus économe de la mémoire de conversation. Le contexte peut être conservé en pleine précision ou compressé. La compression coûte environ 12 % de précision de ce tampon et libère nettement plus de place — nous l’utilisons partout où nous nous battons pour le contexte. Une compression plus forte a été écartée : elle dégrade la qualité des réponses de façon sensible.
Que représentent 262 000 tokens
Difficile à se figurer, alors voici deux points de repère. Un tel contexte contient plusieurs centaines de pages de texte à la fois — toute la documentation d’un projet moyen, ou un jeu complet de contrats à comparer. Dans le test de programmation, où le modèle écrivait lui-même des projets multi-modules, le pic d’occupation du contexte atteignait en moyenne 107 000 à 175 000 tokens. Autrement dit : même en travail intensif, il restait de la marge.
Pour comparaison — le seul modèle polonais que nous ayons testé s’arrête à 32 768 tokens. Non pas à cause des cartes, mais parce qu’il a été conçu ainsi.
Mesures sur 2 × RTX 5070 Ti 16 Go. Mémoire libre relevée après pleine charge, seuil d’admission de 100 Mo par carte.