Les débuts de NVIDIA Vera Rubin dans MLPerf donnent le ton, mais son statut de préversion compte

NVIDIA a fait son entrée dans MLPerf Inference v6.1 avec Vera Rubin NVL72, annonçant un débit jusqu’à 3,7 fois supérieur à celui de son prédécesseur, GB300 NVL72. Les débuts de NVIDIA Vera Rubin dans MLPerf offrent aux acheteurs d’infrastructures leur premier aperçu évalué par les pairs de la prochaine plateforme IA à l’échelle du rack de l’entreprise. Ils assortissent également ce titre d’une limite importante : Vera Rubin reste un système de préversion.

Cette distinction définit la véritable compétition. NVIDIA ne se contente pas de comparer une génération de GPU à une autre. L’entreprise soutient que des racks étroitement intégrés peuvent convertir de nouveaux composants, réseaux et logiciels de serving en une meilleure économie de l’inférence.

La soumission MLPerf la plus étendue d’AMD à ce jour montre pourquoi cet argument est désormais mis sous pression. AMD a publié des résultats compétitifs sur du matériel disponible, élargi sa couverture de charges de travail et mis en avant des déploiements atteignant 512 accélérateurs. NVIDIA est en tête dans les comparaisons sélectionnées avec Vera Rubin, mais les clients doivent déterminer si cet avantage de préversion se traduira par une valeur réellement déployable.

Les résultats MLPerf de NVIDIA Vera Rubin établissent une avance initiale

Ces débuts démontrent un important gain de performances générationnel sur deux modèles exigeants, même s’ils ne représentent pas encore une plateforme de production commercialisée.

Les résultats ont été publiés le 16 septembre 2026 dans le cadre de la publication MLPerf v6.1. MLPerf Inference mesure la manière dont les systèmes servent des modèles d’IA entraînés dans des conditions standardisées de précision et de latence.

MLCommons a signalé un record de 30 organisations participantes pour cette édition. Cinq nouveaux processeurs ou accélérateurs ont fait leur apparition, dont le MI350P disponible d’AMD et l’Arc Pro B70 d’Intel. NVIDIA Rubin et Vera Rubin NVL72 ont participé en préversion.

NVIDIA a soumis des résultats Vera Rubin pour DeepSeek-R1 et Qwen3-VL-235B. DeepSeek-R1 évalue le serving de modèles de raisonnement, tandis que Qwen3-VL combine des entrées linguistiques et visuelles pour des tâches telles que la classification de produits.

Les résultats Vera Rubin de l’entreprise affichent le gain relatif le plus important dans le scénario interactif de Qwen3-VL. Dans ce cas, un Vera Rubin NVL72 a livré 1 307 requêtes par seconde. Un résultat GB300 NVL72 comparable a atteint 349 requêtes par seconde.

Cela produit l’augmentation annoncée d’environ 3,7 fois. Le scénario interactif impose également une limite de latence de 1,5 seconde, ce qui rend ce résultat plus pertinent pour les applications réactives que le débit batch non contraint.

L’avantage était moindre, mais restait substantiel, dans les autres scénarios Qwen3-VL. Vera Rubin a atteint 2 393 échantillons par seconde hors ligne, contre 1 305 pour GB300. Son résultat serveur a atteint 2 323 requêtes par seconde, contre 1 210.

Ces résultats correspondent à un débit hors ligne environ 1,8 fois plus élevé et à un débit serveur 1,9 fois plus élevé. Cette différence montre pourquoi un seul multiplicateur maximal ne peut pas décrire l’ensemble du système.

Sur DeepSeek-R1, Vera Rubin a enregistré 652 750 tokens par seconde dans le scénario interactif. Un résultat GB300 NVL72 à 72 GPU a atteint 260 098 tokens par seconde sous les mêmes contraintes de latence publiées.

Cette comparaison étaye l’affirmation de NVIDIA d’un débit DeepSeek-R1 jusqu’à 2,5 fois supérieur. NVIDIA a utilisé TensorRT-LLM pour cette charge de travail, tandis que sa soumission Qwen3-VL utilisait vLLM avec NVIDIA Dynamo.

Le tableau de performances publié indique également les seuils de précision associés à chaque résultat. L’entrée Vera Rubin DeepSeek-R1 vise 99 pour cent de la précision FP16, avec un score d’exact-match de 81,9132 pour cent.

Pour Qwen3-VL, l’objectif était de 99 pour cent de la qualité BF16. Le benchmark exigeait un score F1 hiérarchique par catégorie d’au moins 0,7824 à partir d’un jeu de données de catalogue de produits Shopify.

Ces seuils importent, car une inférence plus rapide a une valeur limitée si une compression numérique agressive dégrade les résultats du modèle. MLPerf impose aux soumissions d’atteindre des seuils de qualité définis avant que leurs chiffres de performance soient pris en compte.

Ces débuts ne couvrent toutefois que deux modèles de benchmark. Ils n’établissent pas une position de leader sur toutes les charges de travail de langage, de recommandation, de vidéo, de parole ou de recherche dans MLPerf Inference v6.1.

Ce périmètre plus restreint n’est pas inhabituel pour du matériel de préversion. Il signifie toutefois que les acheteurs devraient considérer ce résultat comme un premier signal système, et non comme un verdict universel.

Pourquoi un débit accru transforme l’économie de l’inférence IA

Les performances d’inférence ont une importance financière lorsqu’un débit supplémentaire permet de servir davantage de requêtes utiles sans augmenter proportionnellement le matériel, l’énergie ou la complexité opérationnelle.

L’entraînement produit un modèle, mais l’inférence s’exécute chaque fois que ce modèle répond à un utilisateur. Un assistant grand public, un agent de programmation, un service de recherche ou un système documentaire peut déclencher de nombreux appels d’inférence au cours d’une même tâche.

Les agents de raisonnement intensifient ce schéma. Ils génèrent des tokens intermédiaires, appellent des outils, examinent les résultats et révisent leurs plans. Une réponse visible peut nécessiter plusieurs passages du modèle en arrière-plan.

Ce comportement rend les tokens par seconde économiquement importants. Un système plus rapide peut servir davantage de requêtes simultanées, réduire les files d’attente ou fournir des traces de raisonnement plus longues dans la même fenêtre de temps.

Le débit maximal ne représente toutefois qu’une partie du calcul. Les acheteurs ont également besoin d’une latence de réponse acceptable, d’une précision constante, d’une forte utilisation, d’une demande électrique maîtrisable et de logiciels fiables.

MLPerf distingue pour cette raison plusieurs scénarios de déploiement. Le scénario hors ligne met l’accent sur le traitement en volume. Le scénario serveur modélise des requêtes entrantes variables, tandis que le scénario interactif impose des exigences de réactivité plus strictes.

La meilleure performance relative de Vera Rubin apparaît dans cet environnement interactif sensible à la latence. Cela suggère que ses améliorations architecturales deviennent particulièrement précieuses lorsqu’un système ne peut pas masquer les délais derrière de gros lots.

Le résultat compte pour les produits qui facturent l’accès, la consommation ou le travail accompli. Si un rack traite davantage de requêtes avec le niveau de service requis, l’opérateur tire plus de capacité de cette infrastructure.

Le débit ne se traduit toutefois pas automatiquement en revenus. La demande doit exister, les logiciels doivent maintenir les accélérateurs occupés et l’ensemble du service doit éviter les goulots d’étranglement en dehors du serveur de modèles.

Le stockage, les fabrics réseau, les bases de données, les filtres de sécurité et la logique applicative peuvent tous limiter les performances effectivement fournies. Un benchmark isole le système testé plus proprement que ne le permettent la plupart des environnements de production.

Le coût par token est également plus complexe que la division du coût de l’équipement par le débit de pointe. Il inclut l’électricité, le refroidissement, le réseau, la maintenance, le financement, l’ingénierie logicielle, les temps d’arrêt et l’amortissement.

NVIDIA affirme que Vera Rubin réduit les coûts par token, mais la publication v6.1 ne fournit pas de comparaison complète du coût total de possession en production. Le benchmark apporte des éléments de preuve sur les performances, et non un modèle d’achat complet.

Les équipes d’infrastructure devraient donc traduire ces résultats dans leurs propres profils de trafic. Un service visuel de recherche de produits peut accorder de l’importance au débit serveur de Qwen3-VL. Une plateforme de raisonnement peut privilégier la latence DeepSeek-R1 et la génération de tokens.

Le résultat devient plus précieux lorsque le benchmark ressemble à la charge de travail de l’acheteur. Il devient moins déterminant lorsque l’architecture du modèle, la longueur des requêtes, le comportement de batching ou les contraintes de service diffèrent sensiblement.

C’est la pression économique à laquelle les concurrents de NVIDIA sont confrontés. Ils n’ont pas besoin de remporter tous les graphiques, mais ils doivent offrir suffisamment de performances déployables, de maturité logicielle et de flexibilité pour présenter un meilleur argument commercial global.

La co-conception à l’échelle du rack est le mécanisme de performance

L’avantage de Vera Rubin vient du traitement de 72 GPU, CPU, mémoire, réseau et logiciels d’inférence comme un seul système coordonné.

Un rack NVL72 connecte 72 accélérateurs au sein d’un domaine scale-up à large bande passante. Le réseau scale-up permet à ces accélérateurs de coopérer comme les éléments d’un vaste système plutôt que de se comporter comme des serveurs isolés.

NVIDIA affirme que NVLink de sixième génération et NVLink Switch offrent des débits de paquets 10 fois supérieurs à ceux de l’Ethernet standard. L’entreprise revendique également une latence trois fois plus faible dans la comparaison concernée.

Ces affirmations sur l’interconnexion proviennent de NVIDIA et ne doivent pas être considérées comme des benchmarks réseau indépendants. Elles expliquent néanmoins le choix de conception du système soumis.

Les grands modèles de raisonnement et de vision-langage déplacent des volumes considérables de données durant l’inférence. Les poids du modèle, les activations, les états d’attention et les décisions de routage doivent rapidement parvenir aux bonnes ressources de calcul.

Vera Rubin utilise HBM4, une génération de mémoire à large bande passante placée près du GPU. La configuration de rack de NVIDIA comprend 72 GPU Rubin et 36 CPU Vera, selon son architecture publiée.

Le logiciel répartit ensuite le travail entre ces ressources. Le serving désagrégé sépare le prefill du decode, permettant à différentes ressources de se spécialiser dans des phases distinctes de la génération de texte.

Le prefill traite l’entrée utilisateur et construit l’état d’attention interne du modèle. Le decode génère la réponse token par token, souvent sous des contraintes différentes de mémoire et de latence.

La séparation de ces phases peut améliorer l’utilisation lorsque le logiciel attribue chacune à des ressources adaptées. Elle peut aussi créer une surcharge de coordination, ce qui rend les interconnexions rapides et une planification efficace critiques.

Les soumissions de NVIDIA ont utilisé un parallélisme d’experts à grande échelle pour les modèles mixture-of-experts. Cette conception de modèle n’active que certaines couches expertes pour chaque token, au lieu d’exécuter l’ensemble du réseau à chaque fois.

Cette approche peut réduire le calcul, mais elle crée des communications irrégulières. Les tokens doivent être acheminés vers les experts appropriés, traités puis renvoyés sans que les délais réseau n’annulent les gains.

L’arithmétique à précision réduite constitue un autre élément du mécanisme. NVIDIA a utilisé NVFP4, un format numérique quatre bits destiné à réduire l’utilisation mémoire et à augmenter le débit de calcul.

Le système a appliqué une précision réduite aux poids, aux opérations d’attention et au cache clé-valeur. Un cache clé-valeur stocke des informations d’attention antérieures afin que le modèle ne recalcule pas l’intégralité de la conversation pour chaque nouveau token.

Une précision plus faible permet de stocker davantage de données en mémoire et de réduire les transferts entre unités de calcul. Les seuils de précision de MLPerf servent de garde-fou contre une perte de qualité inacceptable.

Le chiffre final de performance n’est donc pas une mesure pure du silicium Rubin. Il reflète les processeurs, la mémoire, le réseau, les formats numériques, les kernels, les frameworks de serving et l’optimisation propre au benchmark.

C’est au cœur de la stratégie de NVIDIA. L’entreprise souhaite que les clients évaluent l’ensemble de la plateforme, car son avantage concurrentiel dépasse les spécifications des accélérateurs individuels.

Cette stratégie peut offrir des avantages aux opérateurs recherchant une pile intégrée et prise en charge. Elle peut aussi accroître la dépendance envers l’environnement matériel et logiciel étroitement connecté de NVIDIA.

Pour les acheteurs, cette dépendance n’est pas automatiquement négative. Une plateforme coordonnée peut réduire le travail d’intégration et produire des performances prévisibles sur des systèmes qualifiés.

Le compromis apparaît lorsque les clients souhaitent davantage de choix matériel, des logiciels portables ou un contrôle indépendant des composants individuels. C’est là que l’approche concurrente d’AMD devient pertinente.

AMD met sous pression le récit de la plateforme avec du matériel disponible

La performance d’AMD dans v6.1 n’efface pas les avances ciblées de Vera Rubin, mais elle empêche NVIDIA de s’approprier sans contestation le récit plus large de l’inférence.

AMD est passé de trois familles de modèles dans MLPerf Inference v6.0 à six dans la v6.1. Ses résultats couvraient des charges de travail de langage, de raisonnement, de recommandation et de texte vers vidéo sur des accélérateurs MI355X, MI350X et MI350P.

La soumission MLPerf de l’entreprise met en avant des performances compétitives sur huit GPU avec GPT-OSS-120B. AMD affirme que le MI355X a devancé certaines entrées NVIDIA B200 et B300 dans les scénarios offline et serveur.

AMD a également signalé des gains issus de travaux logiciels sur un matériel MI355X inchangé. Le débit serveur GPT-OSS-120B à huit GPU a progressé de 38 % par rapport à la précédente campagne.

Le débit offline a augmenté de 28 %, tandis que les performances single-stream de Wan 2.2 se sont améliorées de 70 %. Il s’agit des comparaisons d’AMD entre ses résultats soumis en v6.1 et en v6.0.

Ce même schéma soutient l’un des principaux arguments de NVIDIA. Le matériel ne détermine pas, à lui seul, la valeur sur toute la durée de vie d’un système d’inférence. Les améliorations logicielles peuvent débloquer davantage de travail utile après le déploiement.

AMD a atteint 95 % d’efficacité de mise à l’échelle avec 72 MI355X sur GPT-OSS-120B. L’efficacité de mise à l’échelle mesure dans quelle mesure la croissance du débit suit l’ajout d’accélérateurs.

Crusoe a ensuite soumis un système AMD de 512 GPU. Il a produit 5,75 millions de tokens offline par seconde sur GPT-OSS-120B et 2,90 millions sur DeepSeek-R1, selon AMD.

Il s’agissait alors du plus grand nombre d’accélérateurs soumis à MLPerf Inference. Cela illustre également une voie concurrente vers la mise à l’échelle, fondée sur de grands clusters et un environnement logiciel ouvert.

La comparaison avec Vera Rubin n’est pas directe. Différentes soumissions peuvent utiliser des modèles, tailles de systèmes, scénarios et optimisations approuvées différents.

Un résultat agrégé sur 512 accélérateurs ne démontre pas une meilleure économie par rack qu’un système Vera Rubin à 72 GPU. De même, l’avance de Vera Rubin sur Qwen3-VL ne tranche pas la compétitivité d’AMD sur GPT-OSS-120B.

C’est une difficulté fréquente lors de la lecture de MLPerf. Chaque fournisseur peut mettre l’accent sur les charges de travail, scénarios et tailles de systèmes qui présentent son meilleur cas.

MLCommons limite cette liberté par des règles standardisées, des seuils de précision, une revue des résultats et des détails de configuration publiés. Il ne peut pas rendre identiques des systèmes différents.

Les comparaisons les plus utiles maintiennent constants le modèle, le scénario, la cible de latence, l’exigence de précision, le nombre d’accélérateurs et la division. Les différences en dehors de ces variables doivent rester visibles.

La concurrence ne se limite pas à NVIDIA et AMD. Google a participé à la v6.1, Intel a présenté des résultats Arc Pro B70, et plusieurs fournisseurs cloud ont soumis des systèmes partenaires.

Les résultats d’inférence de Lambda montrent comment les constructeurs de systèmes peuvent générer des gains supplémentaires avec la même génération d’accélérateurs. Son système Blackwell Ultra à quatre GPU s’est amélioré de près de 9 % par rapport à la v6.0.

Lambda a également utilisé une soumission en division ouverte pour exécuter une charge de travail edge-agentic avec Kimi K2.6 sur du matériel de datacenter. Le modèle contient plus d’un trillion de paramètres, selon Lambda.

Ces entrées renforcent un constat plus large. L’unité de compétition se déplace d’un processeur vers une pile de services configurée comprenant des modèles, des frameworks, de l’orchestration et de l’infrastructure.

NVIDIA propose actuellement la version la plus intégrée de cette pile. AMD cherche à affaiblir l’hypothèse selon laquelle l’intégration exige une plateforme réservée à NVIDIA.

La pression sur NVIDIA ne consiste donc pas simplement à rester le plus rapide. L’entreprise doit montrer que son avance en performances génère suffisamment de valeur opérationnelle pour justifier l’engagement envers son architecture.

Ce que les résultats Preview n’établissent pas

L’affirmation la plus solide concerne le débit vérifié du benchmark, tandis que les affirmations sur le coût, les revenus, la disponibilité et la domination sur un large éventail de charges de travail exigent des preuves supplémentaires.

MLCommons identifie Vera Rubin et Vera Rubin NVL72 comme des entrées preview. Cette étiquette indique aux lecteurs que la plateforme n’est pas présentée comme le MI350P d’AMD disponible dans cette campagne de résultats.

Le statut preview ne rend pas un résultat invalide. MLPerf publie toujours la configuration et applique son processus de benchmark. Il limite toutefois ce que les acheteurs peuvent déduire des systèmes commercialement déployés.

Le matériel de production peut être soumis à des contraintes qui n’apparaissent pas dans une soumission d’ingénierie. La maturité du firmware, les taux de défaillance, l’approvisionnement en composants, le refroidissement, le temps d’installation et la gestion de flotte influencent tous la capacité réelle.

La soumission Vera Rubin provenait aussi de NVIDIA et de son partenaire Nebius. Une reproduction plus large auprès de constructeurs de systèmes indépendants fournirait des preuves plus solides que les performances se transfèrent entre les déploiements.

L’écosystème de la génération précédente de NVIDIA offre un précédent favorable. Dix-neuf partenaires ont participé avec des plateformes NVIDIA dans la v6.1, dont huit utilisant des systèmes Blackwell NVL72 multi-nœuds.

Cette ampleur suggère que NVIDIA sait diffuser des conceptions optimisées au sein d’un vaste réseau de fournisseurs. Elle ne garantit pas que la configuration preview de Vera Rubin arrivera partout, inchangée et dans les délais.

La couverture des charges de travail crée une autre incertitude. La plateforme a fait ses débuts sur DeepSeek-R1 et Qwen3-VL, deux charges de travail adaptées à sa conception à l’échelle du rack et à sa pile logicielle.

Elle n’a pas publié de résultats Vera Rubin sur GPT-OSS-120B, la recommandation, la parole, la génération d’images, le RAG ou Wan 2.2 dans la division fermée. Les prochaines campagnes devraient montrer si l’avance se généralise.

NVIDIA a également cité des améliorations de performances postérieures à la date limite sur GPT-OSS-120B et DLRMv3. L’entreprise a explicitement indiqué que MLCommons n’avait pas vérifié ces résultats ultérieurs.

Ces chiffres doivent rester en dehors des conclusions directes du benchmark tant qu’ils n’ont pas passé le même processus de revue. Les tests des fournisseurs peuvent indiquer une direction, mais ils n’ont pas le même poids probant.

Les données de consommation électrique constituent une autre pièce manquante dans la comparaison principale. Le débit par rack est important, mais les opérateurs se heurtent souvent à une capacité électrique fixe avant d’épuiser l’espace au sol.

Un rack plus rapide peut tout de même compliquer les déploiements s’il exige une alimentation électrique plus dense ou un refroidissement liquide plus contraignant. Les performances par watt détermineront la quantité de travail utile qui tient dans les limites d’une installation.

NVIDIA soutient qu’un débit supérieur réduit le coût par token. Cette conclusion est plausible lorsque les autres facteurs restent stables, mais le résultat publié ne fournit pas une comptabilité complète des coûts.

Les conditions d’achat, l’utilisation, l’électricité, la maintenance, le financement et le travail logiciel peuvent faire varier le chiffre final. Les acheteurs ont besoin de données de production mesurées sur leurs propres charges de travail.

Le benchmark ne peut pas non plus garantir la réactivité pour l’utilisateur final. Le serving de modèles peut être rapide tandis que la récupération, les appels d’outils, les bases de données ou les API externes créent l’essentiel du délai.

MLPerf v6.1 commence à combler cette lacune avec de nouveaux tests de génération augmentée par récupération et edge-agentic. Plus de la moitié des soumissionnaires ont utilisé son harness centré sur les API, qui applique une architecture client-serveur.

MLCommons indique que ce harness accompagnera une transition vers MLPerf Endpoints pour les tests de datacenter. Ce changement devrait rapprocher les mesures de services déployables plutôt que de moteurs de modèles isolés.

Cette évolution pourrait renforcer ou affaiblir l’argument de NVIDIA en faveur de sa plateforme. Une pile étroitement intégrée devrait bénéficier de mesures de service complètes, mais les dépendances externes peuvent diluer les avantages bruts des accélérateurs.

La lecture prudente est précise. Vera Rubin a signé des débuts preview notables et examinés sur DeepSeek-R1 et Qwen3-VL. Elle n’a pas encore établi une domination universelle ni une économie de production complète.

Trois signaux détermineront si l’avance se maintient

L’avantage initial de Vera Rubin ne devient stratégiquement important que si les systèmes livrés le reproduisent sur davantage de charges de travail et sous des contraintes opérationnelles mesurables.

Le premier signal est une large disponibilité en production. Les clients devraient surveiller les instances cloud, les systèmes partenaires et les racks installés qui exposent des détails de configuration comparables à ceux de la soumission preview.

Un déploiement réussi montrerait que NVIDIA peut transformer un résultat d’ingénierie optimisé en infrastructure reproductible. Des retards ou des configurations sensiblement différentes affaibliraient cette conclusion.

La disponibilité doit inclure davantage que des annonces de livraisons. Les acheteurs ont besoin de versions logicielles stables, d’un réseau qualifié, de procédures de service et de preuves que les systèmes maintiennent leurs performances sur de longues périodes d’exploitation.

Le deuxième signal est la prochaine campagne de benchmark indépendante. Vera Rubin a besoin de résultats au-delà de DeepSeek-R1 et Qwen3-VL, en particulier sur la récupération, la recommandation, la vidéo et d’autres modèles de langage.

Une couverture plus large étayerait l’affirmation de NVIDIA selon laquelle une seule plateforme peut gérer des charges de travail d’inférence variées. Une couverture étroite laisserait davantage de place aux accélérateurs spécialisés et aux clusters concurrents.

Les futurs résultats MLPerf Endpoints seront particulièrement révélateurs. Ils devraient mesurer des systèmes exposés par API qui ressemblent davantage aux services achetés et exploités par les entreprises.

Observez si le débit brut de Vera Rubin résiste à l’ajout de l’orchestration des requêtes, de composants de récupération et de frontières de service réalistes. Une avance plus faible suggérerait que les goulets d’étranglement se sont déplacés ailleurs.

Le troisième signal est le progrès logiciel concurrentiel. Les améliorations d’AMD en v6.1 montrent que les accélérateurs installés peuvent gagner considérablement en performances sans nouvelle génération matérielle.

Si ROCm, les frameworks de serving ouverts et les systèmes partenaires continuent de progresser rapidement, les acheteurs pourront accepter des performances de pointe plus faibles en échange de flexibilité ou de compatibilité avec l’infrastructure existante.

Si le logiciel de NVIDIA progresse au même rythme, l’avance initiale de Vera Rubin pourrait se cumuler. L’entreprise a déjà signalé un gain de 1,6 fois sur Qwen3-VL avec GB300 entre la v6.0 et la v6.1.

La vélocité logicielle compte donc deux fois. Elle améliore les performances actuelles et modifie la manière dont les clients estiment la durée de vie utile d’un système coûteux.

Les équipes d’approvisionnement devraient demander des résultats pour leurs modèles exacts, longueurs de contexte, schémas de lots et cibles de latence. Elles devraient aussi tester les défaillances, les mises à niveau et les changements de charge de travail.

Les développeurs devraient observer quelles optimisations atteignent les frameworks courants sans travail personnalisé important. Une technique optimisée pour un benchmark crée une valeur limitée si les équipes ordinaires ne peuvent pas la déployer ou la maintenir.

Les responsables de produits IA devraient relier les métriques d’infrastructure aux résultats pour les utilisateurs. Une inférence plus rapide peut permettre une latence plus faible, davantage d’étapes de raisonnement, une concurrence plus élevée ou des requêtes multimodales plus longues.

Le résultat MLPerf de NVIDIA Vera Rubin constitue un argument d’ouverture crédible en faveur de la co-conception à l’échelle du rack. Sa comparaison de pointe de 3,7 fois est significative, mais elle appartient à un scénario défini.

La prochaine décision ne consiste pas à déterminer si le benchmark preview semble rapide. Il l’est clairement. La décision consiste à savoir si les systèmes livrés conservent cet avantage une fois que l’électricité, le logiciel, la disponibilité et les charges de travail réelles entrent dans l’équation.

Demandez aux fournisseurs de reproduire votre objectif de niveau de service le plus exigeant avant de choisir une plateforme. Comparez ensuite ensemble le débit soutenu, la latence, la précision, l’utilisation et l’effort opérationnel. Cette évaluation révélera si l’avance de Vera Rubin dans les benchmarks devient une économie d’inférence durable ou reste un résultat preview impressionnant.