La commande AMD Helios de Vultr offre à HPE une ouverture de 1,2 milliard de dollars face à Nvidia

Vultr a passé une commande de 1,2 milliard de dollars pour les systèmes AMD Helios de HPE, offrant à cette plateforme à 72 GPU son premier client chez HPE. La commande AMD Helios de Vultr fait passer cette architecture d’une feuille de route publique à un déploiement commercial dans des centres de données aux États-Unis.

Cet accord n’est pas une simple acquisition supplémentaire d’accélérateurs IA. HPE fournira un rack intégré combinant la puissance de calcul d’AMD, des logiciels ouverts, un réseau scale-up basé sur Ethernet, un refroidissement liquide et des services de déploiement. L’accord teste la capacité d’un groupe de fournisseurs alternatifs à concurrencer Nvidia au niveau des systèmes complets.

Nvidia reste le point de référence, car Vera Rubin NVL72 relie également 72 GPU au sein d’un même domaine de calcul à l’échelle du rack. Nvidia contrôle toutefois une plus grande partie de sa pile technologique grâce à des technologies propriétaires telles que NVLink. AMD, HPE, Juniper et Broadcom présentent l’Ethernet fondé sur des standards comme une voie plus ouverte.

Cette distinction compte davantage que toute revendication isolée de performances maximales. Un système IA à l’échelle du rack doit fournir des résultats constants à travers les accélérateurs, la mémoire, le réseau, le refroidissement, l’orchestration et les logiciels. Vultr engage désormais des capitaux substantiels pour démontrer que l’approche ouverte peut fonctionner dans un cloud de production.

La commande AMD Helios de Vultr fait entrer HPE en production

La commande apporte à HPE sa première validation commerciale pour un système auparavant défini surtout par des spécifications et des annonces de partenariats.

HPE a annoncé l’accord le 30 septembre 2026. Selon son annonce de commande, Vultr déploiera des systèmes AMD Helios AI Rack by HPE dans ses centres de données cloud aux États-Unis.

L’entreprise a décrit cette transaction comme sa première commande pour la plateforme Helios intégrée. HPE a également signalé cette évolution dans un dépôt auprès de la SEC daté du 30 septembre, inscrivant cette annonce dans ses communications officielles aux investisseurs.

Chaque rack comprendra 72 GPU AMD Instinct MI455X. Il inclut également des processeurs AMD EPYC, connus sous le nom de code Venice, ainsi que des cartes d’interface réseau AMD Pensando Vulcano AI.

ROCm, la plateforme logicielle ouverte d’AMD pour le calcul sur GPU, fournit l’environnement de programmation. HPE apporte l’ingénierie du rack, le refroidissement liquide direct, les services de déploiement et six plateaux de commutateurs scale-up Juniper QFX5252 par rack.

Le réseau scale-up relie les accélérateurs au sein d’un même domaine de calcul. Il doit déplacer les données assez rapidement pour que de nombreux GPU puissent fonctionner sur un modèle partagé sans passer trop de temps à s’attendre les uns les autres.

Les commutateurs HPE utilisent UALink sur Ethernet, couramment abrégé en UALoE. Cette architecture transporte le trafic UALink via un réseau fondé sur Ethernet plutôt que de dépendre d’une interconnexion contrôlée verticalement.

HPE affirme que les six plateaux de commutateurs relient chaque GPU au moyen de liaisons à large bande passante et à faible latence. Cette affirmation devra être étayée par des preuves en production, car les performances réseau varient selon la structure des charges de travail, les schémas de communication et la configuration logicielle.

Les entreprises n’ont pas révélé le nombre de racks commandés par Vultr. Elles n’ont pas non plus fourni de calendrier de livraison complet ni séparé les composantes de calcul, de réseau, de refroidissement, de logiciels et de services de la commande.

Ces omissions limitent les calculs simples du coût par GPU ou par rack. Elles empêchent aussi les observateurs externes d’estimer quelle part du contrat correspond au matériel par rapport au support opérationnel à long terme.

L’accord établit néanmoins un client réel et un objectif de déploiement significatif. C’est le changement essentiel. HPE n’a plus besoin d’affirmer que Helios attirera un jour un acheteur.

Vultr exploite déjà une infrastructure cloud destinée aux charges de travail d’entreprise et d’IA. L’entreprise peut exposer le système à des clients concernés par l’entraînement de modèles, le fine-tuning et l’inférence à haut volume sans posséder un centre de données spécialisé.

HPE gagne également un client qui connaît les accélérateurs AMD. Vultr avait auparavant adopté des systèmes AMD Instinct, ce qui réduit les frictions organisationnelles liées à l’ajout d’une nouvelle génération AMD.

La commande pèse donc davantage qu’un benchmark de laboratoire ou qu’une conception de référence. Elle place Helios dans un cloud commercial où l’utilisation, la disponibilité et la demande des clients détermineront le succès de la plateforme.

Pourquoi HPE a besoin de plus qu’une vente de GPU

HPE utilise le rack AMD Helios AI pour concurrencer les infrastructures qui entourent l’accélérateur, et non seulement le châssis serveur.

Le marché de l’infrastructure IA récompense de plus en plus les fournisseurs qui livrent un rack fonctionnel plutôt qu’un ensemble de composants. Les clusters d’accélérateurs denses exigent une coordination de l’alimentation, du refroidissement, du réseau, du firmware, des logiciels, de la supervision et de la maintenance.

Un client peut acheter des puces très performantes tout en rencontrant une faible utilisation du cluster. Les retards proviennent souvent de la congestion réseau, de logiciels instables, de limites thermiques ou de pannes trop longues à diagnostiquer.

Le rôle de HPE consiste à regrouper ces éléments dans un système que Vultr peut déployer de manière répétée. Cela donne à l’entreprise l’occasion de capter des dépenses qui iraient autrement vers des fournisseurs distincts de serveurs, de commutateurs, de refroidissement et d’intégration.

La composante réseau est particulièrement importante. HPE a finalisé l’acquisition de Juniper Networks en 2025, ajoutant des technologies de commutation et des talents d’ingénierie à son portefeuille d’infrastructures.

Helios constitue un premier test de cette stratégie combinée. Six plateaux de commutateurs Juniper sont installés dans chaque système HPE, intégrant le réseau à la conception centrale du rack.

Les informations publiées à l’occasion de l’événement investisseurs de HPE ont présenté l’accord comme un exemple de l’arrivée de l’Ethernet fondé sur des standards dans la couche scale-up. La même analyse réseau a relevé que HPE n’avait pas divulgué la part du contrat consacrée au réseau.

HPE a indiqué à ses investisseurs qu’elle voyait plus d’un milliard de dollars d’opportunités réseau liées à Helios au cours des deux prochaines années. L’entreprise a également déclaré que les commandes de plateaux réseau avaient déjà dépassé 200 millions de dollars.

Ces chiffres sont des prévisions de l’entreprise, et non des preuves de déploiements clients achevés. Ils clarifient néanmoins pourquoi HPE considère Helios comme davantage qu’un produit serveur supplémentaire.

L’entreprise veut que ses équipements réseau prennent en charge le trafic d’accélérateur à accélérateur à l’intérieur du rack. Il s’agit d’une charge de travail exigeante, car les tâches d’IA distribuée échangent de grands tenseurs entre de nombreux appareils.

La latence ou la congestion à ce niveau peut laisser des accélérateurs coûteux inactifs. Une structure réseau insuffisante peut effacer les avantages promis par des GPU plus rapides ou des pools de mémoire plus vastes.

Le déploiement chez Vultr testera donc les capacités d’intégration de HPE autant que le silicium d’AMD. HPE doit démontrer que ses commutateurs, son système de refroidissement, ses services et la conception de son rack fonctionnent comme un produit fiable unique.

L’entreprise doit également rendre ce système gérable dans plusieurs installations cloud. Répéter une configuration à grande échelle exige une installation cohérente, de la télémétrie, une gestion des pannes et des procédures pour les pièces de rechange.

Le refroidissement liquide direct ajoute une autre exigence opérationnelle. Cette technologie transfère la chaleur par un liquide de refroidissement à proximité de composants à forte consommation, permettant des densités que le refroidissement par air conventionnel peine à prendre en charge.

Cependant, le refroidissement liquide affecte aussi la conception et la maintenance des installations. Les opérateurs ont besoin d’une plomberie compatible, de capacités de rejet de chaleur, d’une gestion des fuites, de techniciens formés et de procédures de remplacement des composants.

HPE affirme que son organisation de services réduira ces risques de déploiement et d’exploitation. Le déploiement effectif de Vultr montrera si cette promesse résiste à la réalité de différentes installations et de calendriers de production.

Pour HPE, le succès validerait la logique consistant à combiner le calcul et le réseau Juniper. Un échec suggérerait que l’acquisition d’actifs réseau ne crée pas automatiquement une plateforme IA compétitive à l’échelle du rack.

L’Ethernet ouvert est le véritable pari contre Nvidia

Le principal affrontement oppose une pile Ethernet ouverte et multi-fournisseurs à l’architecture étroitement intégrée de Nvidia à l’échelle du rack.

Nvidia a construit sa position dans l’infrastructure IA grâce à plus que les performances de ses accélérateurs. Les logiciels CUDA, les interconnexions NVLink, les produits réseau, les conceptions de référence et la familiarité des développeurs se renforcent mutuellement.

Vera Rubin NVL72 étend ce modèle à un rack de 72 GPU. Les spécifications NVL72 publiées par Nvidia associent 72 GPU Rubin à 36 CPU Vera et à la sixième génération de NVLink.

AMD Helios vise la même catégorie à l’échelle du rack avec une structure de fournisseurs différente. AMD fournit les accélérateurs, les processeurs hôtes, la technologie d’interface réseau et ROCm. HPE assure l’intégration, les services, le refroidissement et la commutation Juniper.

Broadcom apporte la technologie de commutation utilisée dans la conception scale-up de HPE. Les spécifications de rack de l’Open Compute Project, UALink et les standards Ethernet créent des interfaces que d’autres fournisseurs peuvent adopter.

L’argument qui en résulte n’est pas que Helios manque d’intégration. Il est que l’intégration n’exige pas qu’un seul fournisseur contrôle chaque couche critique.

Les spécifications Helios publiées par AMD indiquent 72 GPU MI455X, 31 téraoctets de mémoire HBM4 et 260 téraoctets par seconde de bande passante scale-up agrégée. La HBM4 est une mémoire à large bande passante placée près du GPU pour un accès rapide aux données des modèles.

AMD indique également 2,9 exaflops de calcul FP4 de pointe et 1,4 exaflops en FP8. FP4 et FP8 sont des formats numériques à faible précision conçus pour augmenter le débit IA tout en utilisant moins de mémoire et d’énergie.

Les chiffres de pointe ne se traduisent pas directement en performances applicatives. Différents fournisseurs peuvent utiliser des formats de données, des hypothèses de sparsité, des paramètres logiciels et des conditions de charge de travail distincts.

Cela rend les comparaisons entre MI455X et Vera Rubin moins directes que la simple mise en regard de deux nombres. Les acheteurs ont besoin de résultats issus de modèles réels, de tailles de lots, de longueurs de contexte, de schémas réseau et d’exigences de niveau de service.

La capacité mémoire donne à AMD un argument marketing clair. Helios est conçu avec 31 téraoctets de HBM4 à l’échelle du rack, prenant en charge de grands modèles et l’inférence à contexte long sans fractionner les données aussi agressivement.

Nvidia réplique avec la maturité de ses logiciels et son réseau intégré. Son écosystème CUDA reste profondément ancré dans les frameworks d’IA, les bibliothèques optimisées, les systèmes de déploiement et les pratiques d’ingénierie.

ROCm s’est considérablement amélioré, mais son adoption implique davantage que la compilation d’un modèle. Les équipes de production ont besoin de noyaux stables, de supervision, d’orchestration, de contrôles de sécurité et de performances prévisibles au fil des fréquentes mises à jour de frameworks.

C’est là que Vultr devient stratégiquement utile. Un fournisseur cloud peut absorber une partie de la complexité d’intégration et proposer aux clients une infrastructure gérée plutôt que des composants bruts.

Les clients pourraient moins se préoccuper de la structure réseau sous-jacente si Vultr fournit des instances fiables ou des clusters réservés. Cette approche peut rendre le matériel AMD accessible aux équipes qui ne disposent pas de spécialistes de ROCm et des systèmes distribués.

Cependant, la disponibilité dans le cloud ne neutralisera pas à elle seule les différences logicielles. Les clients compareront toujours la compatibilité des modèles, l’effort de développement, les performances par dollar et le temps nécessaire pour atteindre une production stable.

La commande AMD Helios de Vultr donne à l’approche ouverte un cadre sérieux pour cette évaluation. Elle ne désigne pas un vainqueur avant le déploiement et la mesure des systèmes.

Les spécifications ne tranchent pas la comparaison entre MI455X et Vera Rubin

Les deux fournisseurs publient des chiffres de pointe impressionnants, mais les acheteurs de cloud paient en définitive pour des charges de travail achevées, une capacité utilisable et des opérations prévisibles.

AMD affirme que Helios prend en charge l’entraînement de modèles comptant un trillion de paramètres et l’inférence à haut volume. Sa conception met l’accent sur la capacité mémoire, les standards ouverts et une connectivité basée sur Ethernet à l’intérieur des racks comme entre eux.

Nvidia positionne Vera Rubin autour de l’inférence agentique, de l’efficacité de l’entraînement et du débit de tokens. L’entreprise affirme que sa plateforme combine CPU, GPU, DPU, interfaces réseau et commutation au sein d’un système unique conçu conjointement.

Ces affirmations reposent sur des charges de travail et des méthodologies sélectionnées par les fournisseurs. Elles sont utiles pour comprendre les priorités produit, mais ne remplacent pas des benchmarks indépendants.

Une analyse technique indépendante a décrit MI455X comme la réponse d’AMD la plus crédible à Nvidia à l’échelle du rack. Elle a également souligné l’importance de Helios, qui réunit 72 GPU au sein d’un domaine cohérent.

La comparaison comporte encore d’importantes inconnues. L’une d’elles est le taux d’utilisation réel, qui mesure la régularité avec laquelle les applications exploitent la capacité de calcul théorique du système.

Une autre concerne les performances des communications collectives. Les tâches d’entraînement échangent fréquemment des résultats partiels entre GPU, et une synchronisation lente peut réduire le rendement de tout un cluster.

L’inférence crée des contraintes différentes. Les contextes longs, les grands modèles mixture-of-experts et de nombreuses requêtes simultanées sollicitent la capacité mémoire, la bande passante mémoire, le routage et l’ordonnancement.

Une troisième inconnue est l’effort de conversion logicielle. Les modèles développés sur des systèmes Nvidia peuvent dépendre de bibliothèques, de kernels ou d’outils opérationnels spécifiques à CUDA.

ROCm prend en charge les principaux frameworks, dont PyTorch, TensorFlow et JAX. La compatibilité au niveau du framework ne garantit pas un comportement identique pour chaque pipeline de production optimisé.

Les développeurs peuvent devoir modifier des kernels, ajuster les paramètres de communication ou remplacer des dépendances. Ces coûts peuvent dépasser les économies matérielles lorsqu’une équipe fait face à une échéance de déploiement serrée.

Vultr peut réduire cette charge en publiant des configurations validées, des conteneurs optimisés, des recettes de modèles et des performances mesurées. L’entreprise peut également fournir une assistance technique fondée sur l’exploitation directe des racks.

Le fournisseur de cloud a intérêt à effectuer ce travail. Étendre l’offre viable d’accélérateurs peut réduire la dépendance à un seul fournisseur et offrir aux clients davantage de choix de capacité.

Toutefois, la capacité doit être disponible dans les délais. HPE et Vultr n’ont pas communiqué de calendrier de déploiement détaillé, tandis qu’AMD a indiqué que les livraisons de Helios monteraient en puissance durant la fin de 2026 et en 2027.

Une importante commande peut couvrir des engagements d’achat, des fenêtres de livraison, des services et de futures capacités. Sa valeur annoncée ne prouve pas que tout le matériel est déjà installé ou accessible aux clients.

Les risques de fabrication et de déploiement restent considérables. Les accélérateurs MI455X nécessitent un packaging avancé et de la HBM4. Les racks Helios dépendent également de nouveaux CPU, de composants réseau, de plateaux de commutation, d’équipements de refroidissement et de la préparation des installations.

Un retard sur n’importe quel composant critique peut ralentir l’ensemble du système. Les produits à l’échelle du rack concentrent les dépendances, car l’acheteur a besoin de la configuration intégrée, et non d’une pièce de remplacement.

La disponibilité électrique constitue une autre contrainte. Les racks IA à haute densité nécessitent une infrastructure électrique et de refroidissement substantielle, qui ne peut pas toujours être ajoutée rapidement à un centre de données existant.

Le véritable résultat de MI455X face à Vera Rubin émergera donc des déploiements, et non des diapositives de lancement. Des comparaisons utiles doivent indiquer le temps de disponibilité, la consommation électrique, le débit des modèles, la latence et le coût total d’exploitation dans des conditions équivalentes.

Vultr achète du levier autant que de la capacité

L’engagement de Vultr lui apporte une autre plateforme d’accélérateurs tout en renforçant sa position entre les fournisseurs de puces et les clients IA d’entreprise.

Les fournisseurs de cloud font face à un équilibre difficile. Ils doivent sécuriser tôt du matériel rare, mais risquent aussi d’immobiliser des capitaux dans des systèmes avant que la demande des clients ne devienne prévisible.

La commande de Vultr indique une confiance dans l’utilisation par les clients de capacités AMD pour l’entraînement et l’inférence. L’entreprise affirme que la demande en infrastructure IA haute performance continue de dépasser l’offre disponible.

Cette déclaration reflète le point de vue commercial de Vultr et n’a pas été validée de manière indépendante par des données d’utilisation publiées. L’entreprise ne publie pas suffisamment de détails pour mesurer la demande future de Helios par client ou par charge de travail.

La logique stratégique reste néanmoins claire. Prendre en charge Nvidia et AMD permet à Vultr d’offrir davantage de choix qu’un cloud construit autour d’une seule famille d’accélérateurs.

Cette flexibilité peut séduire les entreprises préoccupées par la disponibilité matérielle, la concentration des fournisseurs ou la portabilité logicielle. Elle peut aussi attirer les équipes dont les charges de travail bénéficient de pools mémoire plus importants.

Vultr gagne en pouvoir de négociation lorsque plusieurs plateformes d’accélérateurs peuvent répondre aux besoins des clients. L’entreprise est moins exposée au calendrier de production et aux conditions commerciales d’un fournisseur unique.

AMD obtient un canal cloud visible pour MI455X. HPE obtient son premier client Helios intégré. Les équipements Juniper trouvent leur place dans un réseau à l’échelle des accélérateurs.

L’accord offre aussi à Vultr un produit différencié. Les hyperscalers plus importants proposent de vastes portefeuilles, mais les clouds IA indépendants peuvent rivaliser grâce à un accès anticipé au matériel, une assistance ciblée et des options géographiques.

Cette opportunité s’accompagne d’un risque de concentration. La commande est importante par rapport à de nombreuses transactions d’infrastructure de cloud privé, et Vultr doit transformer le matériel installé en usage client durable.

Des engagements de capacité réservée renforceraient cet argument. Il en irait de même d’exemples publics montrant que des clients transfèrent des modèles substantiels depuis des systèmes Nvidia vers Helios sans phase de redéveloppement prolongée.

Un faible taux d’utilisation produirait l’effet inverse. Des racks coûteux immobilisent des capitaux même lorsque les tâches des clients ne les occupent pas.

Vultr doit également gérer les attentes des clients quant à la portabilité des performances. Un modèle qui fonctionne correctement sur les deux plateformes peut malgré tout présenter des caractéristiques différentes de débit, de latence et de coût.

Le fournisseur de cloud peut aider en présentant des preuves spécifiques aux charges de travail. Les comparaisons génériques d’accélérateurs sont moins utiles que des mesures portant sur l’entraînement de modèles, l’inférence à contexte long, le fine-tuning et les charges de travail agentiques.

Les clients devraient également surveiller la disponibilité du service. Quelques clusters spécialisés dans des installations sélectionnées auraient un poids concurrentiel moindre qu’une capacité Helios standardisée dans l’ensemble du cloud de Vultr.

Le déploiement géographique est important, car les acheteurs d’entreprise prennent en compte la latence, la résidence des données, la reprise après sinistre et la proximité des jeux de données stockés. HPE a seulement indiqué que les systèmes seraient déployés sur des sites aux États-Unis.

L’annonce laisse aussi la structure contractuelle incertaine. Aucune des deux entreprises n’a communiqué les jalons de livraison, les clauses d’annulation, les achats minimums ou la part liée aux services.

Ces détails déterminent le niveau de risque supporté par chaque partie. Un achat ferme de matériel diffère d’un accord-cadre pluriannuel dépendant des besoins futurs en capacité.

La commande Vultr AMD Helios constitue donc un signal fort de demande, mais elle n’équivaut pas à un déploiement achevé. Cette distinction doit rester visible jusqu’à ce que les clients puissent accéder aux systèmes à grande échelle.

Trois signaux montreront si Helios peut s’imposer

Le calendrier de livraison, les résultats en charges de travail de production et une adoption plus large par les clients détermineront si cette commande modifie le marché concurrentiel.

Le premier signal est le déploiement physique. HPE et Vultr doivent indiquer à quel moment la capacité Helios devient opérationnelle et où les clients peuvent y accéder.

Un déploiement de production confirmé renforcerait l’affirmation selon laquelle AMD et HPE peuvent fabriquer, intégrer et installer dans les délais une nouvelle plateforme à l’échelle du rack. Des retards répétés l’affaibliraient.

La disponibilité devrait aller au-delà d’un communiqué de presse. Vultr devrait publier les régions de service, les options de réservation, les détails de configuration et la capacité attendue pour les clients qualifiés.

Le deuxième signal concerne les preuves issues des charges de travail. Des benchmarks indépendants ou vérifiés par des clients devraient comparer Helios à des systèmes Nvidia pertinents dans des conditions équivalentes.

Des résultats utiles incluraient les tokens par seconde, le temps d’achèvement de l’entraînement, la consommation électrique, la taille du modèle, la longueur du contexte, la taille de lot et les versions logicielles. Ils devraient également indiquer l’effort d’optimisation.

Ces éléments doivent couvrir à la fois l’entraînement et l’inférence. Une plateforme peut bien fonctionner dans une catégorie tout en rencontrant des difficultés liées aux communications, à la latence ou au support logiciel dans une autre.

Les données opérationnelles comptent également. Les clients ont besoin d’informations sur le temps de disponibilité, la récupération après défaillance de composants, l’ordonnancement des clusters et l’impact de la maintenance sur les performances.

De solides résultats conforteraient la position d’AMD selon laquelle les standards ouverts peuvent offrir des performances compétitives à l’échelle du rack. Des résultats faibles ou étroitement sélectionnés préserveraient l’avantage d’intégration de Nvidia.

Le troisième signal est l’adoption ultérieure. HPE a besoin de clients Helios supplémentaires, tandis qu’AMD a besoin de déploiements allant au-delà des partenaires déjà engagés.

Des commandes d’autres fournisseurs de cloud, entreprises, organismes de recherche ou programmes nationaux de calcul montreraient que l’architecture séduit plusieurs types d’acheteurs.

De nouveaux achats de Vultr seraient encore plus révélateurs. Une deuxième expansion après un usage en production indiquerait que la demande client et l’économie d’exploitation ont répondu aux attentes.

La réaction de Nvidia mérite également attention. L’entreprise peut défendre sa position grâce à des déploiements Rubin plus rapides, des logiciels améliorés, des partenariats cloud agressifs et des offres Ethernet plus solides.

HPE et AMD n’ont pas besoin de déloger Nvidia de l’ensemble du marché pour valider Helios. Ils doivent établir une alternative fiable pour les charges de travail où l’ouverture, la mémoire, la disponibilité ou la diversité des fournisseurs présentent une valeur suffisante.

Pour les développeurs et les acheteurs d’entreprise, l’action immédiate consiste à éviter de considérer les spécifications de pointe comme des conclusions d’achat. Demandez aux fournisseurs des mesures correspondant au modèle prévu et à l’environnement d’exploitation visé.

Demandez des précisions sur la migration logicielle, les frameworks validés, la disponibilité des clusters, les engagements de service et la récupération après défaillance. Comparez l’effort d’ingénierie nécessaire pour atteindre la production, et pas seulement le débit des accélérateurs.

La commande Vultr AMD Helios a créé un test commercial crédible. L’industrie a désormais besoin de preuves de déploiement distinguant une architecture ambitieuse d’une plateforme cloud fiable.