Un contexte d'un million sur huit H200

Ce qui se passe

Servir un modèle à contexte long bute toujours au même endroit : le cache clé-valeur. Le pool de blocs de la carte est fixe, une charge agentique multiplie les requêtes simultanées dont le contexte grandit sans cesse, et la mémoire finit par manquer.

Deux réponses existaient, mauvaises toutes les deux :

• La préemption choisit une requête, jette son cache KV et la re-préremplit plus tard. Elle repaie l'intégralité de son temps jusqu'au premier jeton, à chaque éviction.
• Le déchargement déplace les blocs vers la mémoire hôte. Le cache survit, mais l'attention dense exige que chaque jeton soit résident sur le GPU pour être lu : le nombre de requêtes simultanées reste plafonné par la mémoire de la carte.

L'équipe vLLM exploite une propriété du modèle. GLM 5.3 utilise une attention creuse à MLA : un indexeur sélectionne les top-K jetons et n'attend que ceux-là. HiSparse décharge donc tout le cache KV sauf les jetons sélectionnés, ce qui donne enfin une borne supérieure à la mémoire GPU nécessaire par requête. Le cache de l'indexeur reste résident et croît avec le contexte, mais il est bien plus petit — l'IndexShare de GLM 5.3 ne prévoit qu'une couche d'indexeur pour quatre couches sparse-MLA.

Hybrid HiSparse ajoute la nuance qui compte : le cache reste sur le GPU tant qu'il y a de la place, et le mécanisme de déchargement ne s'applique qu'en cas de pression réelle. On ne paie les transferts hôte-carte qu'au moment où la concurrence l'impose.

Les trois états de résidence

En pleine résidence, tout le cache sparse-MLA est sur la carte, et les pages de préfixe achevées sont recopiées d'avance vers l'hôte — de sorte qu'elles pourront libérer leur emplacement plus tard sans nouvelle copie.

En résidence mixte, la queue de la requête reste sur le GPU et n'est jamais évincée ; les pages plus anciennes ne vivent qu'en mémoire hôte, et les lignes que l'indexeur réclame sont placées dans des hot buffers. Un noyau fusionné résout les top-K : les jetons résidents sont lus sur place, les jetons chauds rafraîchissent leur entrée LRU, et un défaut recopie une seule ligne depuis la mémoire hôte épinglée. Rien sur le chemin de décodage n'attend une décision du CPU, ce qui préserve la capture en graphe CUDA.

En absence de résidence, une nouvelle requête qui réutilise un préfixe présent seulement côté hôte démarre sur des emplacements vides : les lignes arrivent au fur et à mesure que l'indexeur les demande. On paie ce que le modèle regarde, pas tout l'historique.

La clé de voûte est que les hot buffers ne sont pas une allocation séparée : ce sont des blocs ordinaires du même pool, loués via le Hybrid Memory Allocator de vLLM. Un bloc libéré par une requête peut devenir capacité chaude pour une autre.

Les chiffres

Le banc d'essai porte sur 8× H200, avec une charge agentique OpenHands : conversations de 13 tours, premier tour de 74 160 jetons, tours suivants de 753, sorties fixées à 220 jetons.

Les deux déploiements comparés sont en TP8, MTP3, cache KV en FP8, limite d'admission à 142K, max_num_batched_tokens=32768, max_num_seqs=256, gpu_memory_utilization=0.92.

Le budget hôte est identique de part et d'autre, réparti autrement : 512 Gio de pool de déchargement pour la référence, contre 384 Gio de pool HiSparse plus 128 Gio de déchargement pour Hybrid HiSparse.

Résultat annoncé : le contexte plein d'un million de jetons devient exécutable sur ce matériel, ce qui ne l'était pas, avec une concurrence sensiblement supérieure à toutes les longueurs de contexte.

Ce qu'il faut en retenir

• Les hot buffers valent par défaut deux fois le nombre de lignes top-K par requête, ce qui suffit à un bon taux de succès sans gonfler le tampon.
• Le gain n'est pas universel : à contexte court, la résidence ordinaire loge davantage de requêtes, puisque les tampons chauds coûtent un montant fixe par requête. L'intérêt apparaît quand les contextes s'allongent.
• Le MTP contraint le dimensionnement — chaque tampon doit accueillir (num_speculative_tokens + 2) × top-K — et les auteurs annoncent vouloir relâcher cette contrainte.
• C'est encore une branche (hisparse-glm). La disponibilité générale est annoncée pour vLLM v0.30, et un calculateur de concurrence accompagne le billet pour estimer le gain sur votre configuration.

Source : vLLM