NVIDIA Vera Rubin NVL72 revendique des performances par dollar 67 fois supérieures, mais le point de fonctionnement compte
NVIDIA Vera Rubin NVL72 a affiché un avantage revendiqué de 67x en performances par dollar face à GB300 NVL72 dans un premier test d’inférence agentique. Ce chiffre est réel dans le cadre de la comparaison de benchmark retenue, mais il ne constitue pas un multiplicateur universel. À des vitesses de service plus courantes, l’avantage mesuré était bien moindre.
Les résultats du 14 septembre offrent aux acheteurs d’infrastructure leur premier regard indépendant sur Rubin dans une charge de travail longue en contexte et multi-tours. Ils donnent également à penser que les précédentes prévisions de performances du CEO de NVIDIA, Jensen Huang, étaient prudentes. Toutefois, le multiplicateur le plus élevé dépend d’un point de fonctionnement exigeant, où la configuration Blackwell comparée s’approche de sa limite de performances.
L’enjeu central n’est donc pas simplement Rubin contre Blackwell. Il porte sur l’écart entre l’affirmation phare et les performances que les opérateurs peuvent reproduire selon les modèles, les moteurs de service, les objectifs de latence et le trafic de production. NVIDIA semble avoir déplacé l’ensemble de cette courbe de performances, mais l’écart varie fortement selon le point considéré.
NVIDIA Vera Rubin NVL72 passe des prévisions au travail agentique mesuré
Le changement important est que Rubin dispose désormais de résultats mesurés d’inférence agentique, et non plus seulement de spécifications architecturales ou de projections de NVIDIA.
SemiAnalysis a publié les premiers résultats Rubin examinés issus d’AgentX, son benchmark de trafic d’agents de codage à contexte long. Les tests ont utilisé des sessions proches de la production, avec contexte accumulé, pauses liées aux outils, réutilisation de préfixes et rafales de sous-agents parallèles.
Ce trafic diffère d’un benchmark de chatbot classique. Une requête de chat élémentaire contient souvent une invite et une réponse. Un agent peut mener des centaines de tours en appelant des outils, en consultant des sous-agents et en renvoyant à plusieurs reprises un historique de conversation qui s’allonge.
Ces schémas imposent des exigences différentes à un système d’inférence. Les longs historiques consomment la capacité du cache clé-valeur, qui stocke des données d’attention déjà calculées. Les préfixes réutilisés récompensent une mise en cache efficace, tandis que les rafales de sous-agents mettent à l’épreuve l’ordonnancement et la concurrence.
La méthodologie AgentX publique repose sur 393 sessions de codage avec participation volontaire, contenant 135 282 requêtes. Sa requête reconstruite médiane comprend 142 016 tokens en entrée et 444 tokens en sortie.
AgentX supprime les invites, le code, les arguments des outils et les résultats des outils. Il préserve les longueurs des requêtes, leur chronologie, les relations entre préfixes partagés et la structure des sous-agents, puis les remplace par des tokens synthétiques déterministes.
Cette conception offre des formes de trafic plus réalistes sans exposer le contenu original. Cependant, AgentX ne teste pas si un modèle produit du code correct ou accomplit avec succès la tâche d’un agent. Il mesure le système de service, et non l’intelligence du modèle.
Les nouveaux résultats ont utilisé DeepSeek V4 Pro et une première pile TensorRT-LLM. TensorRT-LLM est le runtime d’inférence de NVIDIA destiné à optimiser l’exécution des modèles sur ses accélérateurs.
Selon l’analyse du benchmark Rubin, Vera Rubin NVL72 a produit environ 67 fois plus de débit total par coût de possession modélisé que GB300 NVL72 à 170 tokens par seconde.
Cette comparaison utilisait TensorRT-LLM et NVFP4, le format numérique quatre bits de NVIDIA pour les calculs d’IA à plus faible précision. Elle mesurait également la configuration matérielle et logicielle complète plutôt que de comparer des spécifications théoriques de puces.
Au même point de fonctionnement, Rubin a obtenu un avantage saisissant parce que la courbe GB300 TensorRT-LLM sélectionnée se trouvait près de son point d’extrémité le plus rapide mesuré. SemiAnalysis a signalé un avantage Rubin bien plus faible face à GB300 exécutant SGLang, un autre framework de service.
Le résultat reste important. Rubin ne l’a pas emporté uniquement parce que le benchmark avait choisi une génération dépassée ou un serveur basique à un seul GPU. Il a surpassé le système Blackwell Ultra de NVIDIA à l’échelle du rack tout en servant le même grand modèle et en maintenant un objectif de vitesse de réponse équivalent.
Cependant, le chiffre de 67x décrit un point sur une courbe de performances. Il ne signifie pas que chaque déploiement Rubin génère 67 fois plus de tokens pour le même coût total.
Dans la plage de 60 à 100 tokens par seconde, que SemiAnalysis décrit comme plus représentative des fournisseurs servant cette charge de travail, Rubin a délivré environ 1,4 à trois fois plus de débit par coût total.
C’est moins spectaculaire que 67x, mais commercialement significatif. Un gain durable d’un facteur deux peut remodeler la planification des capacités lorsque l’énergie, le réseau, le refroidissement et l’espace disponible en centre de données limitent déjà l’expansion.
Les résultats montrent également une interactivité maximale plus élevée. Rubin a atteint environ 276 P90 tokens par seconde, contre environ 172 pour GB300 avec la configuration TensorRT-LLM sélectionnée.
L’interactivité P90 mesure la vitesse de diffusion atteinte par 90 % des réponses. Elle aide les opérateurs à déterminer si un résultat de débit offre également une expérience utilisateur acceptable.
L’avantage de Rubin n’était pas identique selon les piles logicielles. SemiAnalysis a constaté que GB300 exécutant SGLang pouvait atteindre une interactivité similaire à celle de Rubin, même si Rubin conservait d’autres avantages en matière de débit et de latence.
Cette variation établit la tension principale de l’article. NVIDIA Vera Rubin NVL72 semble nettement plus rapide, mais son avantage le plus élevé signalé découle d’une combinaison précise de modèle, de runtime, de précision et d’objectif de niveau de service.
Pourquoi l’inférence agentique transforme l’énergie en ressource rare
Le gain le plus déterminant de Rubin n’est pas sa performance arithmétique maximale, mais la quantité de trafic agentique utile qu’il peut servir dans une enveloppe énergétique fixe.
Un agent consomme davantage de tokens qu’une interaction de chat simple, car chaque étape peut devenir du contexte pour la suivante. Les agents de recherche, de codage et d’assistance peuvent interroger des bases de données, exécuter des outils, examiner des résultats et déléguer du travail avant de répondre.
NVIDIA affirme que les requêtes agentiques consomment environ 15 fois plus de tokens que les requêtes de chat simples, sur la base de données OpenRouter. Ce chiffre variera selon l’application, mais la tendance sous-jacente est claire.
À mesure que le contexte augmente, le système traite ou récupère à répétition des informations issues des tours antérieurs. Plusieurs sous-agents peuvent également créer de courtes et intenses rafales de requêtes simultanées.
Ces caractéristiques font de la capacité mémoire, de la bande passante mémoire, de la latence d’interconnexion, de la gestion du cache et de la coordination CPU des contraintes de premier ordre. Les performances brutes des tenseurs restent importantes, mais elles n’expliquent plus à elles seules le résultat global du service.
L’accès à l’électricité ajoute une autre limite. Un opérateur peut être en mesure d’acheter des accélérateurs supplémentaires sans disposer de suffisamment de capacité réseau pour les alimenter. Les nouvelles sous-stations, connexions de transport, systèmes de refroidissement et salles de données prennent plus de temps à construire que les serveurs.
Le débit par mégawatt mesure donc davantage que l’efficacité énergétique. Il estime la quantité de travail facturable qu’un opérateur peut extraire d’une ressource d’installation rare.
À 100 tokens par seconde, SemiAnalysis a mesuré Rubin à environ 59,4 millions de tokens totaux par seconde par mégawatt de réseau électrique. La configuration GB300 la plus performante mesurée a atteint 28,5 millions au même objectif.
Cela rend Rubin environ 2,09 fois plus rapide que le meilleur moteur GB300 au point de fonctionnement pratique considéré. GB300 exécutant TensorRT-LLM a atteint 21,1 millions de tokens par seconde par mégawatt.
L’ampleur de l’avance a changé à mesure que l’exigence de vitesse augmentait. À 150 tokens par seconde, Rubin conservait près de 37 millions de tokens par seconde par mégawatt, soit environ 7,2 fois le résultat GB300 SGLang mesuré.
À 170 tokens par seconde, l’avance de Rubin en débit par mégawatt était de 62,9 fois face à GB300 TensorRT-LLM. Face à GB300 SGLang, toutefois, le multiplicateur était de 5,56 fois.
Cette différence explique pourquoi toute grande affirmation de performances doit préciser son moteur. Un acheteur qui ne comparerait que les noms des accélérateurs manquerait l’ampleur de l’effet du runtime sur le résultat.
Les chiffres antérieurs de NVIDIA montraient une autre lecture de la même tendance. L’entreprise a rapporté un débit par mégawatt jusqu’à 30 fois supérieur à celui de GB300 à 160 tokens par seconde.
NVIDIA a indiqué que ces tests utilisaient la charge de travail AgentX DeepSeek V4 Pro. Au moment de la publication, l’entreprise a également précisé que les résultats étaient en attente d’examen par SemiAnalysis et n’incluaient pas les performances des CPU Vera pour les appels d’outils.
L’examen ultérieur confirme un avantage Rubin substantiel, mais pas un multiplicateur fixe. Les données de performances agentiques de NVIDIA montrent que l’avantage passe d’environ un facteur deux à 110 tokens par seconde à 30 fois à 160.
Cette courbe compte davantage qu’un graphique à barres isolé. Un fournisseur d’inférence choisit un équilibre entre concurrence, vitesse de réponse, délai avant le premier token, latence totale et coût.
Une configuration optimisée pour le débit agrégé maximal peut faire attendre chaque utilisateur trop longtemps. Un système optimisé pour une interactivité extrême peut laisser une capacité coûteuse sous-utilisée.
Les produits agentiques ajoutent une autre complication. L’exécution d’outils, la compilation de code, la récupération d’informations et les appels à des API externes peuvent laisser les GPU en attente des CPU ou de services distants.
Rubin répond à ce problème avec 36 CPU Vera aux côtés de 72 GPU Rubin dans chaque rack NVL72. NVIDIA a conçu ces CPU pour gérer l’orchestration des agents, les appels d’outils, le traitement des données et l’exécution en environnement isolé.
L’argument économique devient plus solide si ces composants réduisent le temps d’inactivité sur l’ensemble d’un flux de travail. Il s’affaiblit si les outils externes, les appels réseau ou la logique applicative restent le goulot d’étranglement dominant.
Pour les fournisseurs cloud et les laboratoires de modèles, la pression est immédiate. Un important avantage Rubin rendrait plus difficile de justifier la poursuite de l’expansion de Blackwell pour de nouvelles capacités d’inférence contraintes par l’énergie.
Les déploiements Blackwell existants ne deviendront pas soudainement non rentables. Leur matériel est déjà installé, leurs logiciels sont matures et de nombreuses charges de travail n’ont pas besoin de la plage d’interactivité la plus élevée de Rubin.
La réponse imposée est plus sélective. Les opérateurs doivent décider quelles charges de travail méritent Rubin en priorité, lesquelles doivent rester sur Blackwell et lesquelles peuvent migrer vers des accélérateurs concurrents.
L’extrême co-conception est le mécanisme derrière le gain de Rubin
Le résultat de NVIDIA provient de la coordination du GPU, du CPU, de la mémoire, de l’interconnexion, du runtime et de l’installation, et non d’une seule puce plus rapide fonctionnant isolément.
NVIDIA appelle cette stratégie l’extrême co-conception. Vera Rubin NVL72 intègre 72 GPU Rubin et 36 CPU Vera via la sixième génération de NVLink au sein d’un domaine unique à l’échelle du rack.
Le GPU Rubin comprend 288 GB de mémoire HBM4 avec 22 TB par seconde de bande passante mémoire. La mémoire à haute bande passante est placée près du processeur et fournit les données du modèle plus rapidement que la mémoire de serveur conventionnelle.
NVLink fournit 3,6 TB par seconde de bande passante pour chaque GPU et 260 TB par seconde à l’échelle du rack. Cette structure permet aux 72 GPU de se comporter davantage comme une grande ressource informatique unique.
Cette architecture bénéficie aux modèles mixture-of-experts. Ces modèles activent des réseaux experts sélectionnés pour chaque token au lieu d’utiliser chaque paramètre à chaque opération.
Les servir efficacement exige un routage rapide entre processeurs. Les retards dans le déplacement des activations entre experts peuvent gaspiller la capacité arithmétique qui paraît impressionnante sur une fiche technique.
Rubin améliore également les opérations de synchronisation utilisées pendant l’inférence distribuée. Moins de surcoût de communication signifie que les processeurs passent plus de temps à calculer et moins à attendre la coordination.
L’architecture de rack de NVIDIA associe Rubin au réseau ConnectX-9, aux unités de traitement des données BlueField-4, aux commutateurs NVLink et à la plateforme Ethernet Spectrum-6.
L’entreprise décrit désormais le système élargi comme une architecture à sept puces après l’ajout du Groq 3 LPU. Un LPU est un processeur conçu pour l’exécution prévisible et à faible latence des modèles de langage.
Rubin prend en charge le traitement du contexte, gourmand en calcul, également appelé prefill. Les racks LPX construits avec des processeurs Groq 3 peuvent se concentrer sur la génération de tokens sensible à la latence, appelée decode.
Cette séparation est connue sous le nom de serving désagrégé. Elle permet aux opérateurs de faire évoluer indépendamment les ressources de prefill et de decode, au lieu d’imposer les deux phases sur un matériel identique.
Les charges de travail d’agents rendent cette séparation attrayante, car leurs requêtes contiennent de longs historiques d’entrée tout en pouvant exiger une sortie interactive rapide. Le prefill nécessite de la capacité mémoire et du calcul parallèle, tandis que le decode bénéficie d’une faible latence.
L’ajustement des débits équilibre ensuite la vitesse à laquelle les deux pools échangent du travail. Un mauvais ajustement peut laisser un groupe inactif tandis que l’autre est surchargé.
Le logiciel de serving relie ces composants. TensorRT-LLM fournit des noyaux optimisés, tandis que NVIDIA Dynamo coordonne l’inférence sur des ressources distribuées.
Les résultats d’AgentX montrent pourquoi le logiciel doit être considéré comme faisant partie du produit. L’écart entre GB300 utilisant TensorRT-LLM et GB300 utilisant SGLang a atteint plusieurs dizaines de fois à un point donné.
Cela ne signifie pas qu’un moteur est universellement supérieur. Le meilleur moteur GB300 variait selon la plage de vitesse testée, TensorRT-LLM dominant à un objectif et SGLang à des objectifs plus élevés.
Le résultat précoce de Rubin est arrivé avant que sa pile logicielle n’atteigne sa pleine maturité. Cela laisse une marge d’amélioration, mais introduit également de l’incertitude pour les déploiements.
NVIDIA indique que la plateforme est en pleine production et devrait être expédiée au cours du second semestre 2026. L’affirmation précédente de l’entreprise concernant la plateforme évoquait jusqu’à dix fois de meilleures performances d’inférence par watt que Blackwell.
SemiAnalysis a constaté jusqu’à sept fois plus de débit par mégawatt autour de la zone de fonctionnement, par rapport à l’illustration GTC antérieure de Huang qui évoquait un facteur trois. À certains points comparables, le multiple mesuré a été nettement plus élevé.
Cela étaye l’interprétation du « sandbagging », mais seulement dans un sens étroit. La présentation de Huang couvrait une attente générale pour la plateforme, tandis que le nouveau résultat porte sur une charge de travail agentique et des configurations particulières.
La conception de Rubin s’attaque également à l’approvisionnement électrique. Les centres de données dimensionnent couramment leurs systèmes électriques pour la consommation maximale possible d’un rack, même lorsque les charges d’inférence atteignent rarement ce maximum de manière continue.
NVIDIA DSX MaxLPS utilise une allocation dynamique de puissance afin de récupérer la marge inutilisée entre les GPU et les racks. Il cherche à placer davantage de calcul dans la même limite de site sans dépasser l’enveloppe énergétique de l’installation.
La documentation MaxLPS décrit un déploiement d’inférence illustratif d’un mégawatt avec 400 GPU. Dans cet exemple, la gestion dynamique porte le débit de tokens à 1,35 fois la référence statique à puissance maximale.
NVIDIA affirme que la combinaison de la planification des installations et du contrôle de la puissance peut permettre de prendre en charge jusqu’à 40 % de GPU supplémentaires dans une enveloppe fixe. Il s’agit d’une affirmation de planification, et non d’un résultat garanti pour chaque site.
Les opérateurs doivent valider le profil réel de consommation de leur charge de travail, la capacité de refroidissement, la marge de sécurité et l’impact sur la latence. Une flotte atteignant fréquemment sa consommation de pointe offrira moins de marge récupérable.
Le mécanisme est donc multiplicatif. Des GPU plus rapides, une mémoire plus large, des liaisons à plus faible latence, une meilleure planification, des CPU spécialisés et la gestion dynamique de la puissance éliminent chacun des goulets d’étranglement différents.
Si ces couches fonctionnent ensemble, Rubin peut générer davantage de tokens utiles dans le même bâtiment. Si l’une d’elles ne passe pas à l’échelle, le gain théorique diminue avant d’atteindre les clients.
L’affirmation de 67x se réduit hors de son point de fonctionnement sélectionné
Le benchmark confirme l’avance de Rubin, mais montre également pourquoi un chiffre maximal de performance par dollar ne doit pas devenir une hypothèse de planification pour l’ensemble d’une flotte.
La première limite réside dans le point sélectionné. À 170 tokens par seconde, la configuration GB300 TensorRT-LLM comparée était proche de son plafond d’interactivité mesuré.
De faibles hausses de l’objectif de vitesse peuvent réduire fortement le volume de trafic qu’un système traite près de cette limite. Rubin disposait encore d’une marge de performance inutilisée, créant ce ratio inhabituellement élevé.
La comparaison de Rubin avec GB300 SGLang au même objectif a réduit l’avantage de débit par mégawatt de 62,9 fois à 5,56 fois. Cela reste important, mais raconte une histoire d’achat différente.
La deuxième limite concerne le modèle de coût total. SemiAnalysis calcule le coût de possession à partir du matériel, du réseau, de l’énergie, du financement, de la colocation, de la durée de vie utile et des conditions d’achat supposées des hyperscalers.
Un fournisseur plus petit sera confronté à des conditions différentes de financement, d’utilisation et d’infrastructure. Un locataire cloud observera également une relation différente entre les performances du matériel et la capacité contractuelle.
La performance par dollar dépend du maintien de l’équipement à un niveau d’utilisation élevé. Un accélérateur aux excellentes performances économiques de pointe peut décevoir si la demande est irrégulière ou si le logiciel empêche une forte utilisation.
La troisième limite est le périmètre de la charge de travail. Le résultat Rubin publié se concentre sur DeepSeek V4 Pro sous la forme de trafic d’agent de codage d’AgentX.
Un client servant des prompts plus courts, de la génération d’images, de la récupération d’informations, de la vidéo, des modèles denses ou des tâches batch hors ligne rencontrera d’autres goulets d’étranglement. SemiAnalysis note lui-même que les gains comparatifs de Rubin sont plus faibles pour l’inférence batch hors ligne et l’entraînement.
AgentX utilise également des charges utiles synthétiques. Il préserve les longueurs, les préfixes partagés, le rythme et les embranchements, mais ne peut pas conserver le contenu sémantique des sessions privées.
Le décodage spéculatif présente un défi particulier. Cette technique utilise un modèle brouillon plus petit ou plus rapide pour proposer plusieurs futurs tokens, puis demande au modèle principal de les accepter ou de les rejeter.
Un texte synthétique peut produire un comportement d’acceptation irréaliste. AgentX répond à ce problème en utilisant des longueurs d’acceptation mesurées sur un jeu de données de codage distinct et en enregistrant ces paramètres.
Ce contrôle améliore la comparabilité, mais demeure une approximation. Le benchmark ne peut pas reproduire les modèles propriétaires des fournisseurs, le raisonnement caché, les outils côté serveur, les images ou chaque transformation de tokenizer.
L’exécution en boucle fermée introduit une autre nuance. Les systèmes plus rapides progressent davantage dans les sessions échantillonnées pendant la fenêtre de test, et peuvent donc rencontrer un mélange de requêtes quelque peu différent.
Aucun de ces éléments n’invalide le résultat. Ils définissent ce que le résultat mesure et les domaines dans lesquels les acheteurs devraient exiger des preuves supplémentaires.
La quatrième limite est le logiciel précoce. SemiAnalysis a utilisé une version préliminaire de TensorRT-LLM, et les versions ultérieures devraient améliorer l’efficacité de Rubin.
Les logiciels précoces peuvent également contenir des régressions, des fonctionnalités incomplètes et des comportements opérationnels qui n’apparaissent pas dans un benchmark contrôlé. Les piles Blackwell matures ont bénéficié de davantage de temps pour intégrer les correctifs de production.
La fiabilité compte à l’échelle d’un rack. Selon NVIDIA, un rack NVL72 complet contient 1,3 million de composants et près de 1 300 puces.
Un opérateur de centre de données a besoin d’un débit utile soutenu, c’est-à-dire une sortie utile après prise en compte des pannes, de la maintenance, des nouvelles tentatives et du matériel indisponible. Le débit de pointe d’un benchmark ne mesure pas l’ensemble de ce bilan opérationnel.
La cinquième limite est la réponse concurrentielle. AMD a lancé son accélérateur Instinct MI455X en juillet 2026 pour la plateforme Helios à l’échelle du rack.
Les spécifications officielles du MI455X indiquent 40,3 pétaflops de performances MXFP4 de pointe et une architecture CDNA5. Les chiffres arithmétiques de pointe ne peuvent pas être comparés directement aux résultats d’AgentX.
SemiAnalysis a inclus le précédent MI355X dans ses nouvelles mesures. À 100 tokens par seconde, la configuration MI355X testée la plus performante a atteint environ 2,01 millions de tokens par seconde par mégawatt.
Rubin a atteint 59,4 millions à ce point, soit une avance rapportée de 29,5 fois. Selon SemiAnalysis, AMD s’est engagé à collaborer à de futurs tests AgentX du MI455X.
Cette future comparaison sera bien plus pertinente que celle entre Rubin et MI355X. Elle testera deux plateformes actuelles à l’échelle du rack sur la même charge de travail, le même modèle, la même forme de trafic et le même objectif de niveau de service.
Le TPU7x Ironwood de Google cible également les grands modèles denses et les modèles mixture-of-experts. Sa disponibilité via Google Cloud offre aux clients une autre voie associant silicium personnalisé et plateforme logicielle verticalement intégrée.
NVIDIA conserve un avantage en profondeur d’écosystème. CUDA, TensorRT-LLM, Dynamo, NVLink et son réseau de partenaires donnent à l’entreprise le contrôle d’une plus grande partie du parcours de déploiement.
Ce contrôle peut améliorer l’optimisation, mais aussi renforcer la dépendance des clients envers un seul fournisseur. Une co-conception extrême fonctionne au mieux lorsque les acheteurs acceptent l’ensemble de la pile.
L’interprétation crédible n’est pas que Rubin est 67 fois meilleur partout. C’est que Rubin repousse la frontière utilisable de l’inférence, en particulier pour les grandes charges de travail agentiques soumises à des exigences strictes d’interactivité.
Plus de tokens par gigawatt ne signifient pas automatiquement plus de profit
Rubin peut améliorer l’économie des centres de données, mais le profit dépend de l’utilisation, de la demande, de la fiabilité et des prix de vente que le benchmark ne peut pas établir.
SemiAnalysis estime que Rubin peut générer plus de deux fois le profit annuel par gigawatt de Blackwell. Le cabinet prévoit que cet écart s’élargira à mesure que les noyaux et les logiciels de serving mûriront.
Cette estimation repose sur un mécanisme raisonnable. Si un mégawatt produit davantage de tokens facturables, la capacité de revenus augmente tandis que l’allocation réseau de l’installation reste fixe.
Un coût unitaire plus bas peut également accroître les marges ou soutenir des tarifs clients plus faibles. Les fournisseurs peuvent choisir entre conserver le gain d’efficacité et l’utiliser pour capter davantage de demande.
Cependant, le débit représente une capacité, non des ventes. Un fournisseur ne gagne davantage que si les clients consomment cette capacité supplémentaire à des niveaux durables.
Le profil de demande doit correspondre au matériel. Les avantages les plus importants de Rubin apparaissent dans les charges de travail d’agents interactifs à long contexte, plutôt que dans toutes les formes de calcul d’IA.
Cela crée un problème d’allocation. Les fournisseurs ont besoin d’un volume suffisant de trafic agentique pour maintenir les nouveaux racks occupés sans détourner des charges de travail qui s’exécutent plus économiquement ailleurs.
L’efficacité des modèles peut également réduire la demande d’infrastructure par tâche. De meilleures architectures, des traces de raisonnement plus courtes, une mise en cache améliorée et des modèles spécialisés plus petits peuvent réduire la consommation de tokens.
L’effet inverse est tout aussi plausible. Des tokens moins chers peuvent encourager les développeurs à construire des agents plus durables, à utiliser davantage de sous-agents et à automatiser des tâches auparavant non rentables.
C’est l’effet rebond bien connu de l’informatique. L’efficacité réduit le coût d’une opération, puis le logiciel s’étend pour consommer la nouvelle capacité.
NVIDIA parie fortement sur ce résultat. Son cadrage considère les centres de données comme des usines d’IA dont la production est constituée de tokens plutôt que de services informatiques conventionnels.
La métaphore a ses limites. La valeur des tokens varie fortement. Un token contribuant à une tâche de codage achevée vaut davantage qu’un token généré durant une boucle de raisonnement échouée.
Les benchmarks d’agents peinent encore à relier l’efficacité de l’infrastructure au travail achevé. AgentX maintient intentionnellement le comportement du modèle hors de son périmètre et n’évalue pas la qualité des résultats.
Un test économique complet mesurerait le coût par tâche réussie, et non uniquement le coût par million de tokens. Il inclurait la précision du modèle, les nouvelles tentatives, les défaillances des outils et l’effort humain nécessaire pour examiner les résultats.
La latence affecte également indirectement les revenus. Un agent plus rapide peut terminer davantage de tâches et maintenir l’engagement des utilisateurs, mais seulement si l’application et les outils externes répondent à une vitesse comparable.
Les résultats de latence de bout en bout rapportés pour Rubin sont encourageants. À un niveau comparable d’efficacité de possession, SemiAnalysis a mesuré environ 20 secondes pour Rubin, contre 60 secondes pour B200 ou B300.
À un niveau plus élevé de débit par coût, le cabinet a rapporté environ 20 secondes pour Rubin et 120 secondes pour les systèmes Blackwell comparés.
Ces mesures renforcent les arguments en faveur de Rubin, car elles associent un débit supérieur à des temps d’exécution plus courts. Elles restent néanmoins des résultats de benchmark propres à une configuration donnée.
La rentabilité dépend aussi de la vitesse de déploiement. Un rack retardé ne produit aucun token, quelle que soit son efficacité théorique.
NVIDIA a conçu Rubin autour du format de rack MGX de troisième génération afin de faciliter l’installation et la maintenance. Le tiroir de calcul adopte une conception interne sans câbles, sans tuyaux et sans ventilateurs.
L’entreprise affirme que le temps d’assemblage et de maintenance d’un tiroir est passé de près de deux heures à cinq minutes. L’expérience sur le terrain devra confirmer si ces changements améliorent la disponibilité des flottes.
Le refroidissement et la densité de puissance restent des considérations importantes pour les installations. Rubin concentre une demande électrique considérable dans un seul rack, ce qui exige un refroidissement liquide et une distribution électrique compatibles.
Les opérateurs disposant d’installations anciennes ne peuvent pas bénéficier de ce gain en remplaçant uniquement leurs serveurs. Ils peuvent avoir besoin de nouveaux équipements électriques, de systèmes de distribution du liquide de refroidissement, de réseaux et de procédures d’exploitation.
Rubin est donc particulièrement attractif pour les hyperscalers, les laboratoires de modèles et les fournisseurs cloud spécialisés qui construisent déjà de nouveaux campus d’IA. Les acheteurs plus modestes pourront y accéder plus efficacement par l’intermédiaire de services cloud.
« Plus vous achetez, plus vous gagnez » résume de manière mémorable l’argument commercial de NVIDIA. Ce n’est pas une loi économique.
La formulation plus exacte est conditionnelle. Plus un opérateur déploie, remplit, alimente et maintient disponible une capacité efficace, plus ce site fixe peut soutenir de revenus.
Ce que les acheteurs devraient surveiller après le résultat NVIDIA Vera Rubin NVL72
Trois signaux détermineront si l’avance initiale de Rubin dans les benchmarks devient un avantage durable en production.
Le premier signal concerne des données AgentX reproductibles de manière indépendante sur plusieurs moteurs d’inférence. Rubin doit fournir des résultats publics issus de TensorRT-LLM, SGLang et vLLM avec des modèles et des objectifs de niveau de service identiques.
Cette comparaison montrera quelle part de l’avance actuelle provient du matériel Rubin et quelle part découle d’un couplage logiciel particulièrement favorable.
Les résultats historiques devraient rester visibles à mesure que les runtimes s’améliorent. Sinon, les acheteurs ne pourront pas distinguer les véritables gains matériels des évolutions logicielles qui profitent aussi aux systèmes plus anciens.
Une reproduction par les fournisseurs cloud renforcerait encore les arguments. Leurs déploiements intègrent des contraintes d’ordonnancement, de réseau, de supervision, de mutualisation et de fiabilité absentes des environnements de test contrôlés.
Si Rubin conserve un avantage important d’un moteur et d’un opérateur à l’autre, le point extrême de 67x apparaîtra comme un exemple spectaculaire d’un changement plus large. Si l’écart se réduit fortement, le choix du logiciel aura été le facteur dominant.
Le deuxième signal est la performance de MI455X et TPU7x sur la même charge de travail AgentX. Les comparaisons actuelles mélangent Rubin avec des accélérateurs issus de cycles produits ou de méthodologies de benchmark différents.
La plateforme Helios d’AMD est le concurrent le plus direct, car elle combine des GPU, CPU, réseaux et une intégration à l’échelle du rack actuels. Un test équivalent révélera si la pile logicielle de NVIDIA demeure son avantage décisif.
TPU7x propose une voie concurrentielle différente. Google contrôle l’accélérateur, le compilateur, le service cloud et certaines parties de la pile de modèles, ce qui lui confère sa propre forme de co-conception.
Si l’un ou l’autre concurrent se rapproche des performances de Rubin par mégawatt tout en conservant une interactivité utile, les acheteurs gagneront en pouvoir de négociation et en choix architecturaux. Une large avance de Rubin renforcerait le contrôle de NVIDIA sur l’infrastructure agentique.
Le troisième signal concerne l’économie de production après prise en compte de l’utilisation et de la fiabilité. Les acheteurs devraient suivre le goodput soutenu, le délai jusqu’au premier token, la latence de bout en bout, la consommation électrique, les taux de défaillance et le coût par tâche achevée.
Ils devraient également distinguer l’interactivité de pointe de la plage réellement utilisée par les clients. La région de 60 à 100 tokens par seconde peut avoir davantage d’importance commerciale qu’un point extrême impressionnant.
DSX MaxLPS mérite une attention similaire. Faire fonctionner davantage de GPU dans une enveloppe de puissance fixe n’a de valeur que si le système respecte les limites du site sans nuire à la latence ni à la durée de vie des équipements.
Un gain de densité vérifié de 40 % multiplierait l’avantage matériel de Rubin. Un résultat inférieur sur le terrain réduirait l’amélioration projetée du bénéfice par gigawatt.
Les développeurs devraient s’y intéresser, car l’économie de l’infrastructure finit par façonner la conception des produits. Des coûts de service d’agents plus faibles peuvent prendre en charge des sessions plus longues, davantage de récupération d’informations et plus de sous-agents parallèles.
Les travailleurs du savoir ressentiront ce changement indirectement. Des agents plus rapides et moins coûteux peuvent traiter des historiques de projet plus volumineux, mais une production utile dépend toujours de sources fiables.
Une base de connaissances personnelle bien entretenue peut fournir ce contexte sans considérer davantage de tokens générés comme un substitut à de meilleures preuves.
Le verdict initial est clair, mais nuancé. NVIDIA Vera Rubin NVL72 a démontré une avance substantielle en inférence agentique, et la prévision antérieure de Jensen Huang semble prudente.
Le chiffre de 67x représente l’extrémité de la courbe, et non sa moyenne. Le gain pratique se situe plus près d’un facteur deux ou trois dans les plages d’exploitation courantes, avec des avantages plus importants sous des objectifs d’interactivité plus stricts.
Cela suffit néanmoins à mettre sous pression tous les grands fournisseurs d’infrastructure d’IA. La question suivante est de savoir si Rubin peut préserver ces gains économiques lorsque les benchmarks deviennent des déploiements et que les tokens doivent se transformer en travail achevé.
