vLLM sert GLM-5.3 en contexte 1M sur 16 H200

Ce qui se passe

Un agent de code allonge son contexte à chaque tour : sorties d'outils, contenus de fichiers. Sur des H200, les poids de GLM-5.3 occupent l'essentiel de la mémoire de chaque GPU et laissent peu de place au cache KV de ces longs contextes. Le prefill, lui, devient le goulot de tout le déploiement sous charge. L'équipe vLLM (Red Hat et Mistral) publie la deuxième partie de sa méthode : 16 H200, répartis en un nœud de prefill et un nœud de decode. Ce sont les mesures de l'équipe elle-même, pas une vérification indépendante.

Le mécanisme

Deux façons classiques de faire le prefill sur un nœud de 8 GPU :

Schéma	Ce qu'il répartit	Défaut pour GLM-5.3
DP8	un prompt entier par GPU	l'attention d'un prompt n'utilise qu'un GPU ; son KV doit tenir sur celui-ci
TP8	les têtes d'attention	chaque GPU garde tout le KV latent, et l'indexeur est refait sur chacun

La solution combine deux découpages :

PCP (Prefill Context Parallelism) : le prompt est coupé par jetons, pas par têtes. Pour que les GPU aient la même charge malgré l'attention causale, le prompt est découpé en 16 morceaux, et chaque GPU prend un morceau du début et un de la fin. Chaque GPU indexe ses propres jetons, donc l'indexeur n'est plus répété : son coût dépasse celui de l'attention creuse vers 32 000 jetons avec TP8, vers 256 000 avec PCP8.
DCP (Decode Context Parallelism) : le cache KV est réparti par jetons entre les GPU. Un contexte de 1 M de jetons pèse 53,4 GiB de KV en FP8, alors que chaque GPU n'a qu'environ 15 GiB de libres ; réparti par huit, il en prend 6,7 GiB par GPU. Contrepartie : à chaque couche, les fragments sont rassemblés, ce qui ajoute environ 6 % par étape jusqu'à 64 000 jetons de contexte, 15 % à 248 000.
Hybrid HiSparse (côté decode, voir la partie 1) : le KV peut vivre en mémoire de l'hôte, ce qui lève la limite de la mémoire GPU.

Les résultats

Banc : AgentX (SemiAnalysis), des traces Claude Code rejouées avec réutilisation du préfixe, une heure par mesure, décodage spéculatif MTP3 avec une longueur d'acceptation fixée à 2,99 pour que toutes les configurations en profitent pareil.

Jusqu'à 32 requêtes simultanées, le déploiement est limité par le prefill : PCP8 × DCP8 donne 1,7 à 3,2 fois la vitesse par utilisateur de DP8, au même débit, et fait passer le TTFT médian de 1,5-5,2 s à 0,8-0,9 s.
À 64, le decode domine : HiSparse presque double le débit, à 8 340 jetons/s logiques par GPU et 29,6 jetons/s par utilisateur, quand les autres configurations tombent à 1-2 jetons/s par utilisateur.
À 1 M de jetons, c'est la seule configuration testée qui sert la requête : un rang DP8 de prefill ne peut pas la contenir, ni un rang de decode avec simple délestage sur le CPU.

Comment s'y prendre

Il faut vLLM 0.32.0 ou plus (image vllm/vllm-openai:v0.32.0). Les mesures ont été prises sur la branche principale au commit 9e38b4111a ; le gist de reproduction épingle 2537629eb2. Options clés du moteur de prefill :

Terminal

vllm serve <modèle> \
  --prefill-context-parallel-size 8 \
  --decode-context-parallel-size 8 \
  --dcp-comm-backend ag_rs \
  --enable-expert-parallel \
  --attention-config '{"sparse_mla_force_mqa":true}'

Sans sparse_mla_force_mqa, les lots dont les prompts tiennent dans les 2 048 jetons sélectionnés prennent le chemin dense MHA ; l'option les garde sur le noyau d'attention creuse.

Limite à garder en tête : la configuration suppose deux nœuds de 8 H200, hors de portée d'un poste de développeur. Le transfert du KV entre nœuds passe par le connecteur NIXL, derrière un routeur llm-d.

Source : vLLM, « GLM-5.3 Optimizations, Part 2 », 23 octobre 2026. Source en anglais.