Le 18 octobre 2026, vLLM a publié la v0.32.0. Le serveur d’inférence open source encaisse 814 commits venus de 363 contributeurs, dont 121 nouveaux — un rythme de projet qui porte les stacks RAG auto-hébergées.

Deux axes : faire tenir plus de contexte et de requêtes dans le même GPU via la quantification du cache KV, et verrouiller des valeurs par défaut trop permissives.

Le cache KV passe en basse précision partout

Le cache KV en NVFP4 couvre désormais SM8x et SM12x, SM90, le décodage XQA sur SM12x, et l’attention sparse de MiniMax-M3 en SM100. On stocke les états d’attention en 4 bits au lieu de 16 : moins de mémoire par requête, donc plus de séquences simultanées par carte.

Les chiffres des notes de version, issus des benchmarks des PR :

  • GLM-5.x bascule par défaut sur un cache KV FP8 en SM100 : mémoire KV divisée par deux par rank, +2,3 à 5,5 % de débit, au prix de 7 à 11 % de TTFT ;
  • fp8_ds_mla en SM90 donne jusqu’à +31 % de débit de sortie sur GLM-5.3-Flash ;
  • côté ROCm, le cache KV ultraquant_4bit annonce environ 2× la densité du FP8.

À lire comme des chiffres de PR, pas un benchmark indépendant : le compromis débit/latence dépend du ratio prefill/decode. Sur un chatbot conversationnel, les 7 à 11 % de TTFT se sentent ; sur du batch, non.

Un endpoint pour les décisions structurées

Nouveauté plus discrète : POST /v1/systemone répond à des questions choice, noul et score sur un état structuré, servi par défaut, et tourne aussi sur Cloudflare/clef-omni, LiquidAI/d1-3B et DiffusionGemma. De quoi sortir le routage d’agent et la classification de votre prompt système bricolé en JSON mode.

Même logique côté parsing : les nouveaux --tool-call-parser hf et --reasoning-parser hf lisent le response_template du checkpoint. Plus besoin de parser maison, en frontend Python comme Rust.

Le débit, sans changer de modèle

Trois réglages sans toucher aux poids :

  • --api-server-count supérieur à 1 route chaque connexion vers le worker API le moins chargé : 43 à 85 % de req/s en plus sur des requêtes courtes (Qwen3-0.6B, 32 tokens d’entrée / 1 de sortie) ;
  • vllm download-kernels installe les kernels FlashInfer précompilés, et vllm preload --preload-autotune garde la table d’autotune chaude entre deux redémarrages ;
  • HiSparse avec cache de résidence par requête : jusqu’à +58 % de débit sur GLM-5.3-NVFP4 en B200 sur des contextes longs qui tiennent en GPU.

Ce qui casse à la montée de version

Trois correctifs de sécurité justifient la montée de version à eux seuls : GHSA-4hhp-h66f-j5j7 (épuisement de ressources via chat template), GHSA-q97c-p368-75c4 (max_token_id du tokenizer) et GHSA-frvg-qw88-hww9 (épuisement de sockets ZMQ en P2P). Et surtout : les CORS n’autorisent plus toutes les origines par défaut. Si votre front appelait le serveur vLLM en direct depuis un autre domaine, il faut maintenant passer --allowed-origins. C’est le genre de changement qui casse la prod un vendredi soir, pas au build.

Le reste de la checklist :

  • Python 3.10 supprimé ;
  • transformers>=5.16.1,<5.20.0 et tokenizers>=0.23.2 ;
  • cascade attention et mamba_cache_mode="all" retirés, passes torch.compile sequence parallelism et AsyncTP supprimées ;
  • max_tokens n’est plus réservé dans la fenêtre de contexte : les budgets calculés côté client vont dériver ;
  • les événements de stream de raisonnement de la Responses API sont renommés.

Pourquoi c’est important

Parce que le coût par token d’un modèle ouvert ne se joue plus seulement sur le prix du GPU, mais sur le nombre de requêtes qu’on empile dessus. Un cache KV divisé par deux, c’est deux fois plus de contexte servi pour la même facture — et un argument de plus pour le self-host.

Source