vLLM tourne sur Vera Rubin NVL72 : un débit par GPU multiplié par 7,8

Le projet vLLM, le moteur open source d'inférence de grands modèles de langage le plus populaire, annonce la prise en charge du système en rack NVIDIA Vera Rubin NVL72. D'après le blog du projet, le débit par GPU sur la charge AgentX est 7,8 fois supérieur à celui de la génération précédente, le GB200 NVL72. La version comprend la prise en charge des modèles dès le jour 0, des noyaux FlashInfer réglés pour l'architecture Rubin et un routage MoE tenant compte de la localité.

Le chiffre est spectaculaire, mais il faut d'abord comprendre ce qui a été mesuré.

Ce qui est annoncé

La comparaison se fait à l'échelle d'un GPU, et non d'un rack entier. Les deux plateformes appartiennent à la classe NVL72 : 72 accélérateurs réunis dans un même domaine NVLink. La comparaison est donc formellement équitable : rack contre rack, accélérateur contre accélérateur.

La charge retenue est AgentX. À en juger par son nom et son contexte, il s'agit d'un scénario d'inférence agentique : contextes longs, nombreux appels successifs au modèle, usage intensif du cache. L'annonce initiale ne donne pas de détails, et c'est la principale lacune. La configuration des modèles, la précision de calcul (FP8, FP4 ou mixte), la taille des batchs et les contraintes de latence déterminent directement dans quelle mesure ce chiffre est transposable à votre production.

Paramètres clés de la version :

• Plateforme : NVIDIA Vera Rubin NVL72 contre GB200 NVL72.
• Moteur : vLLM avec prise en charge de Rubin dès le premier jour.
• Noyaux : FlashInfer, réglés pour Rubin.
• MoE : placement des experts tenant compte de la localité (locality-aware).
• Métrique : débit par GPU.
• Résultat : 7,8x sur la charge AgentX.

D'où vient l'accélération

Les auteurs avancent trois facteurs. Le premier est le matériel Rubin lui-même. L'annonce ne distingue pas la part du gain qui lui revient de celle du logiciel, et c'est un point important. Si une part notable du gain tient aux optimisations des noyaux et du routage, une partie de ce progrès pourrait aussi finir par arriver sur Blackwell. L'écart réel entre les générations serait alors inférieur à 7,8x.

Le deuxième est FlashInfer. Cette bibliothèque implémente l'attention et les opérations associées, et c'est la qualité de ces noyaux qui détermine quelle part de la puissance théorique de la puce se convertit en tokens. Les noyaux écrits pour une architecture précise apportent généralement le gain le plus sensible sur du nouveau matériel.

Le troisième est le MoE tenant compte de la localité. Dans les modèles à mélange d'experts, les tokens se dispersent entre différents GPU, et les échanges entre cartes deviennent souvent le goulot d'étranglement. Si l'on place et route les experts de sorte que l'essentiel du trafic reste entre proches voisins dans la topologie, la charge sur l'interconnexion diminue. Dans les scénarios agentiques à longues sessions, cette optimisation se remarque tout particulièrement.

Où lire les petits caractères

La source du chiffre est le blog de vLLM lui-même : le benchmark a donc été préparé par les développeurs du moteur, et non par un laboratoire indépendant. Il n'existe pas de données sur la latence par token ni sur le coût par million de tokens, alors que ce sont elles qui déterminent l'économie en exploitation. Une hausse du débit par GPU n'entraîne pas forcément une baisse proportionnelle du prix : un rack de nouvelle génération coûte plus cher, consomme davantage d'énergie et exige un refroidissement plus complexe.

Le fait même d'une prise en charge dès le jour 0 n'en est pas moins significatif. Auparavant, le nouveau matériel attendait des mois un logiciel mature, et la performance réelle restait sensiblement inférieure à la performance annoncée durant cette période. Ici, la pile logicielle est prête à l'arrivée des racks.

Que faire pour les équipes

Si vous envisagez d'acheter ou de louer du Rubin, n'inscrivez pas 7,8x dans votre business plan. Demandez au fournisseur un test sur votre modèle et votre profil de requêtes, avec les mêmes contraintes de latence qu'en production. Comparez le coût du token, et non les tokens par seconde et par carte.

Si vous travaillez sur Blackwell, mettez à jour vLLM et FlashInfer et refaites votre mesure de référence : une partie des améliorations logicielles peut s'y appliquer aussi. Pour les modèles MoE, vérifiez en particulier comment les experts sont placés sur votre topologie. Pour les autres équipes, la conclusion utile est plus simple : la pile d'inférence rattrape le matériel plus vite qu'avant, et il ne semble plus nécessaire d'attendre des mois de maturité logicielle après la sortie des puces.