Ce qu'un contexte de 1M coûte vraiment à une machine

La limite du contexte long n'est presque jamais la capacité du modèle. C'est la mémoire et la bande passante du serveur qui l'exécute.

Un modèle qui annonce 1M de tokens de contexte le supporte vraiment — GLM 5.2, celui qu'on sert, le fait nativement. Mais « supporter » veut dire qu'une requête isolée passe. Ça ne dit rien du nombre de sessions longues qu'une machine peut tenir en même temps, et c'est là que tout se joue.

À chaque pas de décodage, le GPU doit relire le cache KV de chaque séquence active. Les poids du modèle sont amortis sur tout le lot; le cache KV, lui, ne l'est jamais — chaque session paie le sien. La bande passante mémoire du serveur se divise donc par le nombre de sessions actives multiplié par la longueur de leur contexte.

Sur une architecture d'attention dense, l'effet est brutal : passer de 64K à 1M de contexte multiplie par seize le coût mémoire par session, et divise d'autant le nombre de sessions que la machine peut héberger. Ce n'est pas que chaque session devienne lente — c'est que la machine en tient seize fois moins.

Les architectures à attention sparse changent la donne. GLM 5.2 utilise un mécanisme qui réutilise le même indexeur sur chaque groupe de quatre couches, ce qui réduit fortement le calcul par token à contexte long. Le stockage du cache reste à peu près linéaire — il faut bien tout garder pour pouvoir y sélectionner — mais la lecture à chaque pas ne l'est plus.

La leçon pour quiconque dimensionne de l'infrastructure d'inférence : ne dérivez pas ce chiffre à la main. Les serveurs modernes le calculent au démarrage et l'affichent. Chez nous, c'est cette mesure — et non une extrapolation — qui fixe ce qu'on garantit à nos clients.