NVIDIA affirme que Vera Rubin NVL72 délivre jusqu’à 30 fois plus de travail d’agents par mégawatt
NVIDIA indique que Vera Rubin NVL72 peut fournir jusqu’à 30 fois plus de débit d’IA agentique par mégawatt que GB300, en visant les coûts d’inférence à long contexte.
NVIDIA affirme que sa prochaine plateforme Vera Rubin NVL72 peut offrir jusqu’à 30 fois plus de débit d’IA agentique par mégawatt que les systèmes GB300 NVL72 de l’entreprise, ce qui représente un gain potentiel d’efficacité pour les centres de données exécutant des flux de travail d’IA de plus en plus longs et utilisant des outils.
Cette affirmation provient de premières mesures NVIDIA utilisant la charge de travail SemiAnalysis AgentX, qui préserve des sessions de codage enregistrées, en étendant le contexte, les appels d’outils et l’activité des sous-agents. NVIDIA indique que ces résultats sont particulièrement pertinents à mesure que les agents IA dépassent le simple chat en une seule réponse et commencent à effectuer des tâches de recherche, de codage, de service client et d’aide à la décision en plusieurs étapes.
Les chiffres sont communiqués par le fournisseur et n’ont pas encore été validés indépendamment. NVIDIA précise que les résultats Vera Rubin attendent toujours l’examen de SemiAnalysis, et que les tests n’incluent pas les performances du CPU Vera pour les appels d’outils.
Le benchmark derrière l’affirmation de NVIDIA
La comparaison de NVIDIA porte sur le débit par mégawatt plutôt que sur les pics de tokens par seconde d’une requête d’inférence isolée. Cette distinction est importante pour les systèmes agentiques, où un modèle peut relire à plusieurs reprises le contexte accumulé, appeler des outils externes, déléguer des sous-tâches et synthétiser les résultats.
Selon NVIDIA, AgentX représente ces comportements à travers de véritables trajectoires de codage agentique. L’entreprise indique que le benchmark inclut des modèles tels que Kimi K3, MiniMax M3, GLM5.3, Qwen3.5 et DeepSeek V4 Pro, ce qui permet d’évaluer les performances sur différentes architectures de modèles et différents workloads.
Sur DeepSeek V4 Pro, NVIDIA rapporte que GB300 NVL72 fournit jusqu’à 15 fois le débit par mégawatt de son architecture Hopper. Vera Rubin est ensuite présenté comme faisant monter ce chiffre jusqu’à 30 fois supplémentaires par rapport à GB300 NVL72. Il s’agit de résultats maximaux sur la charge de travail et le modèle cités, et non d’une garantie que chaque déploiement verra la même amélioration.
NVIDIA indique également des coûts jusqu’à 35 fois plus faibles par million de tokens par rapport à GB300 NVL72. L’entreprise relie cette mesure à l’économie des usines d’IA, où la capacité électrique limite le nombre de GPU pouvant fonctionner et où le coût par token affecte la marge des services d’inférence.
Pourquoi les workloads d’agents changent l’équation d’infrastructure
Une requête de chat classique peut comporter une entrée et une sortie relativement courtes. NVIDIA décrit des séquences typiques de chat ou de résumé de documents allant d’environ 1 000 à 8 000 tokens. Les sessions d’agents peuvent accumuler des centaines de milliers de tokens d’entrée, car les étapes précédentes, les résultats d’outils et les sorties de sous-agents restent disponibles pour les phases ultérieures.
Cela crée un problème système différent. L’infrastructure doit traiter de grandes quantités de contexte tout en maintenant la vitesse de réponse sur de nombreuses requêtes irrégulières. Un workload peut aussi alterner entre le traitement du contexte, appelé prefill, et la génération de réponse, ou decode. Traiter ces deux étapes de manière identique peut laisser certains GPU sous-utilisés tandis que d’autres deviennent des goulets d’étranglement.
La réponse de NVIDIA combine des techniques matérielles et logicielles. Le serving désagrégé permet de faire évoluer séparément les ressources de prefill et de decode, tandis que le rate matching vise à synchroniser les deux étapes. Les systèmes de cache KV distribués conservent le contexte déjà traité disponible à travers le domaine GPU, et un routage sensible au KV peut envoyer une requête vers le matériel qui détient déjà les données mises en cache pertinentes.
La plateforme s’appuie également sur un parallélisme d’experts à grande échelle pour les modèles mixture-of-experts, sur des kernels CUDA conçus pour fusionner calcul et communication, et sur la quantification NVFP4 afin de réduire la mémoire requise pour les poids du modèle. NVIDIA affirme que les Tensor Cores de cinquième génération et son Transformer Engine prennent en charge les deux principales phases de l’inférence.
Preuves, réserves et ce qui est confirmé
Les affirmations de performance les plus fortes de cet article proviennent des propres blogs infrastructure et développeurs de NVIDIA, et non d’un rapport de benchmark indépendant. L’entreprise attribue la conception du workload à SemiAnalysis AgentX, mais précise que les résultats Vera Rubin attendent encore l’examen de SemiAnalysis. Cela fait de ces chiffres un premier indicateur de la performance cible de NVIDIA, et non une comparaison sectorielle établie.
La comparaison est aussi limitée à plusieurs égards. NVIDIA rapporte des gains maximaux, de sorte que les résultats peuvent dépendre du choix du modèle, de la longueur du contexte, du mélange des requêtes, du batching, des versions logicielles et des paramètres de gestion de l’énergie. Les mesures Vera Rubin citées omettent le travail CPU pour les appels d’outils, une partie importante des agents de production. Les applications réelles peuvent aussi passer beaucoup de temps à attendre des bases de données, des API ou des systèmes d’entreprise plutôt qu’à générer des tokens.
NVIDIA indique que sa technologie DSX MaxLPS peut gérer l’alimentation au niveau du GPU, du rack et du workload, et déployer jusqu’à 40 % de GPU supplémentaires dans le même budget mégawatt. Il s’agit là encore d’une affirmation de l’entreprise, et sa valeur pratique dépendra du refroidissement, de la conception des racks, de l’utilisation et du comportement des workloads déployés.
L’économie de l’architecture est liée à la pile logicielle plus large de NVIDIA, notamment TensorRT LLM et NVIDIA Dynamo. L’entreprise soutient que le domaine de mise à l’échelle NVL72 et les technologies NVLink de sixième génération fournissent la bande passante de communication nécessaire au cache distribué et au parallélisme d’experts. Ces choix de conception pourraient améliorer les performances, mais ils renforcent aussi la dépendance à l’écosystème matériel, réseau et logiciel de NVIDIA.
Ce que le résultat signifie pour les créateurs et acheteurs d’IA
Pour les équipes d’applications IA, cette annonce rappelle que le coût des agents ne peut pas être évalué uniquement en mesurant le prix d’une seule réponse du modèle. Un agent de recherche qui réutilise à plusieurs reprises un contexte croissant peut générer bien plus de travail d’inférence qu’un assistant de chat, même lorsque l’utilisateur ne voit qu’une seule réponse finale.
Les équipes infrastructure devront donc suivre des métriques telles que le coût par tâche accomplie, l’énergie par workflow et le débit dans des conditions de croissance réaliste du contexte. Une plateforme performante sur des prompts courts peut ne pas être efficace lorsque les agents invoquent des outils, créent des sous-agents ou revisitent de longs historiques.
Pour les acheteurs d’entreprise, la question immédiate n’est pas simplement de savoir si Vera Rubin est plus rapide que GB300. Il s’agit de savoir si une organisation dispose d’un trafic agentique suffisamment soutenu pour justifier une nouvelle plateforme, et si ses applications peuvent exploiter des fonctions telles que le cache, la séparation prefill-decode et la quantification des modèles. Les équipes ayant des workloads modestes ou imprévisibles peuvent encore privilégier l’inférence cloud mutualisée, tandis que les grands fournisseurs de services IA et les centres de données contraints en énergie ont de plus fortes incitations à optimiser le travail par mégawatt.
L’annonce soulève aussi un problème de portabilité logicielle. Les gains rapportés par NVIDIA dépendent d’une co-conception entre GPU, NVLink, CUDA, TensorRT LLM et NVIDIA Dynamo. Les développeurs utilisant cette pile peuvent accéder à davantage d’optimisations, mais ils peuvent aussi faire face à des efforts de migration supplémentaires s’ils déplacent plus tard des modèles ou des workloads de service vers d’autres plateformes d’accélérateurs.
Ce qu’il faut surveiller ensuite
Le premier signal sera l’examen indépendant des résultats SemiAnalysis AgentX. Il devrait préciser comment les tests ont été configurés, quelles mesures ont produit les gains les plus élevés et comment Vera Rubin se compare à GB300 sur plusieurs modèles et longueurs de contexte.
Les acheteurs devraient aussi surveiller la disponibilité en production, les mesures d’énergie au niveau du système et les résultats incluant l’orchestration d’outils basée sur CPU. Ces détails aideront à distinguer l’efficacité de génération de tokens de l’efficacité agentique de bout en bout.
Enfin, le marché aura besoin de preuves de déploiement. Les comparaisons les plus pertinentes mesureront les tâches d’agents achevées, la latence, la fiabilité, l’utilisation et le coût opérationnel total sur des workloads réels, plutôt que le seul débit mis en avant.
Perspective Creati.ai
L’annonce de NVIDIA identifie un vrai goulot d’étranglement dans le déploiement des agents : l’inférence à long contexte et en plusieurs étapes peut multiplier la demande de calcul plus vite que ne le suggèrent les volumes de requêtes visibles par l’utilisateur. Mesurer le travail par mégawatt est donc plus pertinent pour les agents à grande échelle que de s’appuyer sur des benchmarks de chat conventionnels.
Mais le chiffre de 30x doit être considéré comme une première affirmation de performance contrôlée par le fournisseur. Son importance dépendra de la réplication indépendante et de la capacité de l’amélioration à résister aux aspects complexes des agents de production : latence des outils, orchestration, appels échoués, trafic irrégulier et coût de bout en bout. Pour les créateurs, la leçon pratique est de benchmarker maintenant les workflows complets, avant de choisir une infrastructure sur la seule base des taux de tokens en contexte court.
