vLLM v0.32.0 est sorti le 18 octobre 2026, le projet vLLM publiant sur GitHub une version qui rassemble 814 commits de 363 contributeurs, dont 121 nouveaux. Pour les équipes qui servent des modèles ouverts sur leur propre matériel, l'essentiel n'est pas la liste des nouveaux modèles : le cache KV en basse précision couvre désormais des GPU plus anciens, et plusieurs comportements par défaut familiers ont changé, au point qu'une mise à jour sans lecture des notes peut casser un déploiement qui fonctionnait.
Un nouvel endpoint pour juger, pas pour générer
Le nouvel endpoint POST /v1/systemone, activé par défaut, répond à des questions de jugement structuré sur un état donné : quelle option choisir, si une affirmation tient, et quelle note attribuer à un résultat. Jusqu'ici, les équipes obtenaient ces réponses en guidant le format de sortie par prompt puis en les analysant elles-mêmes ; la couche de service les traite désormais comme une interface à part entière. Un parseur hf générique lit en outre la response_template livrée dans le checkpoint du modèle, si bien que les modèles dotés de leur propre gabarit n'exigent plus de parseurs sur mesure pour les appels d'outils et le raisonnement, ce qui supprime la partie la plus fastidieuse de l'intégration d'un nouveau modèle.
Le calcul du cache KV : moitié moins de mémoire, payée en latence du premier token
La mémoire est le premier mur que rencontrent les contextes longs et la forte concurrence, et l'essentiel de l'effort de cette version est allé là. Le cache KV au format NVFP4 fonctionne désormais sur SM8x, SM12x et SM90, permettant aux cartes plus anciennes de libérer de la mémoire grâce au cache basse précision. GLM-5.x passe par défaut au cache KV FP8 sur SM100 : la mémoire KV par carte est divisée par deux, le débit gagne 2,3 à 5,5 %, tandis que le délai avant le premier token augmente de 7 à 11 % ; sur SM90, fp8_ds_mla relève le débit de sortie de GLM-5.3-Flash jusqu'à 31 %. L'échange est énoncé clairement : la mémoire revient, et l'utilisateur attend un peu plus le premier token. L'optimisation de bas niveau est un fil conducteur de l'année, comme l'optimisation vLLM qui avait permis à Kimi K3 de devancer une B300 sur du matériel AMD.
Nouveaux modèles, débit sur requêtes courtes et correctifs de sécurité
Les modèles nouvellement pris en charge comprennent le modèle d'embedding multimodal de Google, EmbeddingGemma 2, MiniCPM-V 4.7 et le modèle de reconnaissance vocale en streaming de NVIDIA, Nemotron 3.5 ASR. Côté service, les requêtes réparties entre plusieurs processus API partent désormais vers le processus le moins chargé, ce que le benchmark du projet crédite de 43 à 85 % de requêtes par seconde en plus sur les requêtes courtes — dans une charge extrême de 32 tokens en entrée et 1 en sortie, donc un trafic de production ne doit pas attendre le même chiffre. La version corrige aussi trois vulnérabilités répertoriées touchant l'épuisement de ressources via les gabarits de chat, un paramètre du tokenizer et la communication pair à pair, restreint par défaut l'accès cross-origin au lieu d'autoriser toutes les origines, et limite les images non fiables aux formats raster.
Trois changements cassants à vérifier avant la mise à jour
Les changements incompatibles risquent de mordre avant que les nouveautés ne servent. Python 3.10 n'est plus pris en charge : les déploiements encore dessus échoueront à la mise à jour elle-même. Le défaut cross-origin plus strict coupera les frontaux navigateur qui appellent directement l'API d'inférence, jusqu'à configuration explicite des origines autorisées. L'attention en cascade est supprimée, et la plage de transformers prise en charge se resserre entre 5.16.1 et 5.20.0. Pour la production, l'ordre le plus sûr consiste à vérifier ces trois points en environnement de test, puis à mesurer si les nouveaux défauts du cache KV aident réellement sous votre propre charge, car le coût en latence du premier token ne révèle sa vraie ampleur que sous votre propre distribution de requêtes.
