Nvidia Vera sur OCI place les CPU autonomes en concurrence avec Xeon

Nvidia Vera sur OCI offre aux clients d’Oracle une option de CPU autonome, tandis que des tests distincts font état d’une bande passante mémoire plus de deux fois supérieure à celle d’un serveur double Xeon. Nvidia et Oracle ont annoncé la disponibilité générale le 27 octobre, ainsi que des projets d’extension de leur infrastructure IA à l’échelle de plusieurs gigawatts. La distinction est importante : les processeurs sont disponibles séparément, tandis que l’extension reste un projet.

Le benchmark provient de Tom’s Hardware, qui a testé un serveur Vera distinct, et non Oracle Cloud Infrastructure, ou OCI. Il apporte des éléments sur les capacités du processeur, sans établir les performances d’une instance Oracle. Cet article analyse ces éléments publiés ; il ne présente aucun test matériel original.

La question concurrentielle porte sur les tâches exécutées entre les réponses d’un modèle d’IA. Les processeurs Intel Xeon et AMD EPYC assurent déjà ces services dans les infrastructures d’entreprise. La décision d’Oracle ouvre à Nvidia une autre voie vers ce marché, où les transferts de mémoire et l’exécution des applications deviennent des critères d’achat aux côtés de la compatibilité des processeurs.

Nvidia Vera sur OCI dissocie la capacité CPU des achats de GPU

Oracle propose Vera comme capacité de calcul déployable indépendamment, donnant au processeur un rôle qui dépasse l’hébergement des accélérateurs Nvidia.

Un CPU, ou unité centrale de traitement, exécute les instructions des applications et gère les tâches informatiques générales. Un GPU, ou processeur graphique, exécute des charges de travail parallèles couramment utilisées pour entraîner et exploiter des modèles d’IA. Ces ressources prennent en charge différentes étapes d’une application IA, même lorsque les clients les achètent ensemble.

L’annonce des entreprises concernant le déploiement autonome de CPU indique explicitement que les clients peuvent faire évoluer indépendamment leurs ressources CPU et GPU. Cela crée un choix concret pour les organisations dont les logiciels requièrent davantage de traitement applicatif sans augmentation correspondante de la capacité des modèles.

Vera Rubin NVL72 est la configuration en rack plus vaste annoncée avec les CPU. Elle relie 72 GPU via NVLink, l’interconnexion de Nvidia destinée à la communication entre processeurs. Les services Vera autonomes répondent à une autre décision d’achat : où exécuter les logiciels qui entourent ces modèles.

Prenons l’exemple d’un assistant de programmation. Un modèle propose une modification, un service d’exécution la teste, puis l’application renvoie les résultats pour une autre réponse du modèle. Le service de test consomme des ressources CPU, même si le modèle lui-même s’exécute ailleurs.

Un client peut avoir besoin de capacité d’exécution supplémentaire pendant les périodes chargées, alors que son service de modèles conserve encore de la marge. Acheter ces ressources séparément permet de mieux adapter l’infrastructure à la demande. L’amélioration éventuelle de l’efficacité dépend toutefois de l’utilisation réelle des ressources par l’application.

L’annonce de disponibilité d’Oracle doit également être distinguée de l’extension physique prévue. L’échelle de plusieurs gigawatts décrit le développement d’infrastructure envisagé, plutôt qu’une mesure de la capacité Vera autonome actuellement en fonctionnement. Elle n’établit pas quelle quantité d’équipement les clients peuvent réserver immédiatement.

Cette distinction modifie la manière dont les acheteurs doivent interpréter l’annonce. La disponibilité générale établit une offre commerciale, tandis que l’échelle du déploiement concerne l’approvisionnement, la construction et l’adoption par les clients. Aucune de ces expressions ne suffit, à elle seule, à établir les performances applicatives.

L’offre autonome modifie également la relation de Nvidia avec ses clients potentiels. Une équipe peut évaluer son CPU pour un service sans devoir d’abord décider de déployer un système Rubin complet. Le processeur doit alors se justifier au regard des besoins propres au service.

Cela crée une comparaison plus exigeante qu’une décision d’ajout d’accélérateur. Les acheteurs peuvent se demander si Vera gère mieux leur application que l’infrastructure existante, y compris pour des charges de travail qui ne communiquent jamais directement avec les GPU Rubin.

La concurrence qui en résulte se concentre sur une question connue des entreprises : quelle configuration de serveur exécute le travail requis avec un effort opérationnel acceptable ? Le positionnement IA de Nvidia attire l’attention, mais le comportement ordinaire des applications déterminera la place du processeur.

La pression porte sur les services entre les appels aux modèles

Vera autonome exerce une pression concurrentielle sur les services CPU qui déterminent la rapidité avec laquelle une application IA peut poursuivre son travail.

Un agent IA est un logiciel qui utilise les résultats d’un modèle pour sélectionner et exécuter des actions. Son application peut récupérer des informations, exécuter des programmes, examiner les résultats et demander une nouvelle réponse au modèle. Chaque action introduit des dépendances qu’un modèle plus rapide ne peut éliminer à lui seul.

Supposons qu’un assistant doive rechercher des documents internes avant de répondre à une question technique. Sa réponse dépend de la fin de la récupération, de la vérification des autorisations et de la transmission des résultats au modèle. Une capacité de modèle supplémentaire ne réduit guère un retard au sein de ce service de récupération.

Le même raisonnement s’applique à l’exécution de code. Un modèle peut générer rapidement un test pendant que l’application attend un environnement d’exécution occupé. Améliorer cet environnement devient utile lorsque les retards d’exécution représentent une part significative de l’ensemble de la tâche.

Oracle identifie ces services périphériques parmi ses charges de travail CPU agentiques. Ses exemples incluent l’exécution d’outils, la récupération, l’analytique et les applications opérationnelles. Il s’agit d’adéquations proposées pour certaines charges de travail, et non de garanties que chaque déploiement en bénéficiera.

La pression immédiate porte sur les équipes d’infrastructure qui choisissent la prochaine plateforme pour ces services. Elles doivent déterminer si leurs applications passent leur temps à calculer, transférer des données en mémoire, accéder au stockage ou attendre un autre système. Chaque goulot d’étranglement oriente vers un investissement différent.

Intel et AMD restent pertinents, car les acheteurs disposent déjà de logiciels, de procédures de déploiement et d’une expérience opérationnelle construits autour de leurs processeurs. Cet investissement existant a une valeur pratique. Un processeur concurrent doit apporter suffisamment d’avantages pour justifier l’introduction d’un environnement supplémentaire pris en charge.

La comparaison dépasse donc le classement d’un benchmark. Un service plus rapide qui exige d’importantes modifications applicatives pose une décision d’adoption différente de celle d’un service qui exécute les logiciels existants avec un minimum d’ajustements.

Oracle a également intérêt à distinguer soigneusement les services. Les clients ont besoin d’une infrastructure adaptée à leur combinaison de charges de travail, plutôt que d’une recommandation de processeur unique appliquée à chaque application. Un catalogue plus large offre davantage de choix, mais aussi davantage de travail d’évaluation.

Pour les développeurs, cela change le point de départ des discussions sur l’optimisation. Avant de choisir du matériel, une équipe a besoin d’éléments montrant quelle partie de son application retarde les résultats utiles. Sans cela, un CPU prometteur devient la réponse à un problème non identifié.

Pour les acheteurs en entreprise, la conséquence est similaire. Une proposition d’infrastructure IA doit tenir compte de l’exécution des applications en plus du service des modèles. N’évaluer que le modèle risque de négliger les systèmes qui déterminent si les utilisateurs reçoivent des résultats complets en temps utile.

La pression est la plus forte là où ces services périphériques peinent déjà sous l’effet de la concurrence, c’est-à-dire lorsque de nombreuses tâches s’exécutent simultanément. C’est là que le comportement du processeur sous charge soutenue devient plus pertinent qu’une démonstration isolée.

La bande passante mémoire de Vera CPU cible un goulot d’étranglement précis

L’argument architectural de Vera commence par l’alimentation de ses cœurs CPU en données, plutôt que par le traitement du nombre de cœurs comme preuve suffisante de performance.

La bande passante mémoire mesure la quantité de données qu’un système peut transférer depuis la mémoire au fil du temps. Les applications qui traitent à répétition de grands jeux de données peuvent atteindre cette limite avant d’épuiser leur capacité arithmétique. Ajouter des ressources de traitement offre alors une aide limitée si l’acheminement des données ne s’améliore pas.

La description de l’architecture mémoire Vera de Nvidia indique 88 cœurs, 176 threads et jusqu’à 1,2 téraoctet par seconde de bande passante mémoire. Les threads sont des chemins d’exécution qui permettent aux logiciels de répartir le travail entre les ressources de traitement disponibles.

La puce utilise la LPDDR5X, une technologie de mémoire basse consommation. Nvidia décrit également un fabric de cohérence de deuxième génération, l’interconnexion interne qui maintient des données partagées cohérentes au sein du processeur. Sa bande passante de bissection annoncée est de 3,4 téraoctets par seconde.

Ces chiffres de bande passante décrivent différentes parties du système. Le trafic de mémoire externe et la communication interne remplissent des fonctions liées, mais leurs valeurs ne peuvent pas être substituées l’une à l’autre. Aucune de ces spécifications n’indique directement la rapidité avec laquelle une application termine son travail.

La bande passante mémoire de Vera CPU devient pertinente lorsque le travail utile dépend d’accès répétés à des données au-delà des petits caches rapides du processeur. Un cache conserve les informations fréquemment utilisées près des ressources d’exécution, réduisant le besoin de les récupérer depuis la mémoire principale.

Un service analytique illustratif pourrait analyser à répétition un jeu de données de travail tout en répondant à des requêtes concurrentes. Si ces analyses saturent les transferts mémoire, une bande passante supplémentaire offre une voie plausible vers un débit plus élevé. Le débit mesure le travail achevé au fil du temps.

Une autre application pourrait passer l’essentiel de son temps à attendre un stockage distant. La même amélioration de mémoire ne traiterait qu’une part moindre de son retard. C’est pourquoi les caractéristiques de la charge de travail importent davantage que l’étiquette attribuée au logiciel.

La compatibilité Arm doit également faire partie de cette évaluation. Arm est l’architecture d’instructions de processeur prise en charge par Vera, qui définit les instructions que les logiciels peuvent exécuter. Les applications existantes et leurs dépendances nécessitent des versions compatibles avant que leurs performances puissent faire l’objet d’une comparaison utile.

Un service écrit dans un langage portable peut néanmoins dépendre de composants spécifiques à une architecture. Les extensions de base de données, les logiciels de sécurité et les bibliothèques compilées méritent une attention particulière. Le lancement réussi d’une application n’établit pas que chaque dépendance suit le même chemin optimisé.

C’est le mécanisme central de l’opportunité de Nvidia : proposer un processeur dont les caractéristiques d’acheminement des données et d’exécution correspondent à des services de valeur. C’est une proposition plus ciblée que le remplacement de tous les CPU d’entreprise.

L’argument architectural établit une raison de tester Vera. Il ne règle pas la décision d’achat, car le comportement des logiciels, la configuration de déploiement et l’utilisation soutenue déterminent la part de cette capacité qui atteint les utilisateurs.

Les benchmarks Vera vs Xeon établissent une avance aux limites claires

Le résultat de Tom’s Hardware étaye un avantage de bande passante mémoire dans la configuration testée, tout en laissant les performances applicatives sur OCI non mesurées.

Les benchmarks mémoire de serveurs de la publication comparent Vera à un système double Intel Xeon 6980P. Ils font état d’une bande passante plus de deux fois supérieure dans STREAM triad, un benchmark qui mesure les transferts mémoire soutenus au moyen d’opérations sur des tableaux.

Le système Vera testé utilisait de la mémoire LPDDR5X-9600. La comparaison avec Xeon utilisait des MRDIMM, des modules mémoire conçus pour des débits de transfert plus élevés, fonctionnant à 8 800 mégatransferts par seconde. Ces détails de configuration aident à définir la portée du résultat.

Tom’s Hardware rapporte également que le placement des threads a considérablement affecté la bande passante de Vera. Le test utilisait une politique de répartition OpenMP, un paramètre qui distribue les threads d’exécution parallèles entre les ressources de traitement. La publication a indiqué que des détails plus complets sur la configuration des tests accompagneraient son prochain article.

Ces conclusions sont importantes, car elles montrent un avantage mesuré au-delà d’une spécification constructeur. Toutefois, cette mesure répond à une question plus restreinte que celle de savoir si Vera accélère l’ensemble d’une application par deux.

Un service peut combiner le traitement en mémoire avec l’accès au stockage, la communication réseau et l’exécution sérielle. L’exécution sérielle désigne les tâches qui doivent être effectuées séquentiellement. Améliorer un composant laisse les autres inchangés.

Cette distinction est particulièrement pertinente pour les agents. Un workflow peut exécuter brièvement une opération intensive en mémoire, puis attendre bien plus longtemps un outil externe. Son temps total d’exécution refléterait les deux étapes, indépendamment de la position du processeur dans les benchmarks.

La comparaison Vera vs Xeon implique également des configurations complètes. Le résultat mesuré reflète le fonctionnement conjoint des processeurs, de la mémoire, des logiciels et des réglages. Les acheteurs devraient éviter d’attribuer l’intégralité de l’écart à une seule caractéristique architecturale.

Le placement des threads constitue une raison supplémentaire d’examiner l’environnement. Une politique de placement favorable en laboratoire peut exiger une configuration explicite en production. Les machines virtuelles, qui divisent les serveurs physiques en environnements logiciels isolés, ajoutent une autre couche de déploiement à évaluer.

Une comparaison équitable devrait permettre un réglage raisonnable sur chaque plateforme. Laisser un concurrent avec des paramètres inadaptés mesurerait les choix de configuration autant que les différences matérielles. À l’inverse, exiger une maintenance inhabituelle pour préserver un résultat introduit une charge opérationnelle qui mérite d’être documentée.

Le benchmark publié n’établit pas de classement en matière d’efficacité énergétique. Cela exige de mesurer la consommation électrique pendant que les systèmes réalisent un travail comparable. Un résultat de bande passante seul ne peut pas révéler l’énergie consommée par une tâche applicative terminée.

Il n’établit pas non plus un vainqueur universel pour les bases de données, la compilation ou les serveurs applicatifs. Les différentes charges de travail sollicitent différentes ressources, même lorsqu’elles partagent un langage ou un framework de déploiement.

La bande passante mémoire du CPU Vera mérite donc l’attention comme force démontrée dans la configuration rapportée. La prochaine étape probante consiste à traduire cette force en résultats applicatifs reproductibles sur le service réel que les acheteurs peuvent déployer.

Le déploiement d’Oracle laisse une place à Intel et exige des vérifications de déploiement

Oracle ajoute Vera tout en conservant une voie fondée sur Intel pour les systèmes Rubin, ce qui rend le choix selon la charge de travail plus crédible qu’un discours de remplacement généralisé.

La configuration HGX Rubin NVL8 prévue associe huit GPU Rubin à deux processeurs Intel Xeon 6 de 64 cœurs et à 4 téraoctets de mémoire DDR5. La DDR5 est une génération largement utilisée de technologie de mémoire serveur. Cette offre prévue préserve une voie applicative x86 aux côtés de Vera.

X86 est l’architecture d’instructions utilisée par les processeurs serveur Intel et AMD évoqués ici. Maintenir cette option est important pour les applications ayant des exigences logicielles existantes, même lorsqu’un autre processeur obtient de meilleurs résultats dans certains tests.

La feuille de route d’infrastructure plus large d’Oracle mentionne également la poursuite du travail avec AMD et Intel. Elle répertorie des instances AMD EPYC E7 prévues et des offres X14 basées sur Intel Diamond Rapids. Il s’agit encore d’éléments de feuille de route, et non d’alternatives livrées établies par cette annonce.

Le contexte concurrentiel est donc plus complexe que l’entrée de Nvidia et la sortie des CPU historiques. Oracle élargit les combinaisons disponibles de processeurs et d’accélérateurs. Les acheteurs peuvent dissocier la compatibilité applicative de leur choix de matériel pour servir les modèles.

La disponibilité elle-même exige une lecture attentive. Les spécifications détaillées des instances Vera d’Oracle décrivent à la fois des offres bare metal et des machines virtuelles Flex. Le bare metal donne à un client l’usage direct d’un serveur physique, plutôt que d’une portion virtualisée.

La configuration bi-processeur décrite fournit 176 cœurs, 352 threads et 1 téraoctet de mémoire système. Ces détails d’instance doivent être distingués des spécifications d’un processeur individuel.

La publication d’Oracle sur les CPU annonce une disponibilité générale, mais indique aussi que les instances atteindront certaines régions ce trimestre. Cette formulation laisse ouverte une question pratique : à quel moment un client particulier pourra-t-il obtenir une capacité adaptée à l’emplacement requis ?

Un engagement régional importe pour les organisations soumises à des exigences de résidence des données. Un processeur disponible ailleurs ne résout pas un déploiement limité à une juridiction particulière. La capacité doit aussi être suffisante pour le service visé, plutôt que simplement accessible pour une évaluation.

Oracle indique également qu’une première tranche de 150 000 CPU sera mise à disposition dans ses régions. L’annonce ne fournit ni répartition région par région ni preuve que chaque unité répertoriée exécute déjà des charges de travail clientes.

Ses affirmations de performance exigent une séparation similaire. Oracle cite l’affirmation de Nvidia d’une performance CPU agentique jusqu’à 80 % plus rapide, tout en identifiant ces résultats comme des benchmarks de plateforme. Il ne s’agit pas de mesures au niveau des instances OCI.

Cette divulgation limite la confiance avec laquelle les acheteurs peuvent convertir cette affirmation en prévision de service. La réponse appropriée consiste à tester ensemble l’instance visée, la build applicative et les paramètres opérationnels.

Le travail de migration fait partie de cette évaluation. Une équipe a besoin de dépendances compatibles, d’images de déploiement, de supervision et de procédures de reprise avant de déplacer un service important. Ces exigences ne discréditent pas le matériel ; elles définissent le travail requis pour l’utiliser de manière fiable.

Le cas d’adoption le plus solide associe des gains applicatifs à des changements opérationnels gérables. Un avantage processeur qui résiste à ces vérifications mérite davantage de poids qu’un avantage visible uniquement dans des conditions que le client ne peut pas reproduire.

Trois signaux montreront si Vera autonome gagne une adoption plus large

Les prochaines preuves devraient établir une capacité accessible, des performances applicatives reproductibles et un usage durable au-delà des premières évaluations.

Le premier signal est une disponibilité régionale plus claire. Au cours des prochains mois, les acheteurs devraient rechercher un accès aux instances documenté dans les emplacements requis par leurs applications. Un déploiement qui prend en charge des installations reproductibles renforcerait l’argument en faveur de Vera comme option d’infrastructure pratique.

Les informations de capacité devraient décrire ce que les clients peuvent obtenir, et non seulement ce qu’Oracle prévoit de déployer. L’accès aux réservations, les limites de service et la documentation de configuration aident à relier une annonce de lancement à une décision opérationnelle.

Le deuxième signal est un test applicatif OCI reproductible de manière indépendante. Il devrait comparer des services réalisant un travail équivalent, avec des builds logicielles compatibles et des paramètres clairement documentés. Les résultats les plus utiles montreraient à la fois le travail achevé et les temps de réponse sous concurrence soutenue.

Le temps de réponse mérite une attention particulière près de la saturation. Un serveur peut afficher un débit moyen attrayant alors qu’une minorité de requêtes attend nettement plus longtemps. Ces délais peuvent affecter les utilisateurs dont les workflows dépendent de l’achèvement de chaque appel d’outil.

Pour la question Vera vs Xeon, un travail équivalent importe davantage que des catégories marketing identiques. Les tests devraient expliquer la configuration mémoire, le réglage logiciel et l’allocation des ressources. Sans cela, les lecteurs ne peuvent pas déterminer si un résultat s’étend au-delà de la configuration testée.

La preuve que l’avantage de bande passante rapporté améliore les services intensifs en mémoire renforcerait l’argument architectural. Des résultats dominés par des goulots d’étranglement sans rapport réduiraient l’ensemble des applications auxquelles cet argument s’applique.

Le troisième signal est une adoption durable en production avec des résultats de charge de travail divulgués. La participation de clients est utile, mais un déploiement nommé à lui seul fournit des preuves limitées sur la performance ou l’effort opérationnel. Des descriptions de l’application et de son comportement mesuré seraient plus informatives.

Des retours utiles expliqueraient pourquoi un service a été déplacé, ce qui a changé après le déploiement et quelles limites subsistaient. Ils devraient également distinguer les effets du processeur des changements simultanés apportés au logiciel, au stockage ou à la conception de l’application.

Une adoption plus large parmi des services adaptés soutiendrait l’argument de Nvidia en faveur d’une activité CPU indépendante au sein de l’infrastructure cloud. Une concentration dans un ensemble limité de déploiements spécialisés indiquerait un rôle plus restreint. Ces deux résultats peuvent coexister avec de solides résultats de benchmark mémoire.

Pour les développeurs, l’action immédiate consiste à mesurer les étapes dépendantes du CPU déjà présentes dans leurs applications. Identifiez les points où l’exécution ralentit, préservez une charge de travail représentative et documentez l’environnement. Cela crée une référence utile avant d’évaluer un autre processeur.

Les équipes peuvent organiser ces constats dans une base de connaissances consultable, en maintenant les notes de configuration liées aux résultats applicatifs. L’objectif est de préserver le contexte lorsque des comparaisons ultérieures produisent des résultats différents.

Nvidia Vera sur OCI mérite une évaluation lorsque le trafic mémoire ou l’exécution CPU contraint déjà le travail utile. Commencez par un service dont le goulot d’étranglement est mesuré, puis comparez des déploiements complets sous une charge représentative. Gardez explicites les versions applicatives, les choix de réglage et les allocations de ressources. Demandez-vous si un gain persiste durant les périodes chargées et si l’équipe peut exploiter le service de manière fiable. Demandez des preuves de capacité régionale avant de considérer la disponibilité comme établie. Distinguez les affirmations du constructeur des mesures indépendantes, et préservez les limites de chaque résultat. La question d’achat utile est concrète : ce processeur améliore-t-il le travail que votre application effectue réellement, dans des conditions que votre équipe peut reproduire ?