Le pari AMD Blocks de VAST Data défie l’emprise de Nvidia sur l’infrastructure d’IA

VAST Data a étendu son partenariat avec AMD à six couches d’infrastructure, faisant de l’offre amd blocks un défi direct aux systèmes d’IA centrés sur Nvidia.

L’accord relie l’AI Operating System de VAST aux processeurs AMD EPYC de sixième génération, aux GPU Instinct, aux racks Helios, au réseau Pensando, au logiciel ROCm et au stockage partagé pour l’inférence. VAST utilisera également des puces EPYC dans ses futurs équipements CBox et EBox.

Cette portée compte davantage qu’une simple annonce de compatibilité. VAST entretient déjà des liens étroits avec Nvidia et les fournisseurs de cloud qui déploient des accélérateurs Nvidia. L’entreprise construit désormais une voie AMD qui s’étend des données stockées aux tokens générés.

Ce virage reflète une évolution plus large des dépenses consacrées à l’IA. L’entraînement reste important, mais les entreprises ont de plus en plus besoin d’infrastructures dédiées à l’inférence continue, aux agents de raisonnement et aux applications fondées sur la récupération d’information. Ces charges de travail déplacent de manière répétée des modèles, des prompts et du contexte réutilisable entre le stockage, la mémoire, les CPU et les GPU.

AMD fournit les composants de calcul. VAST veut orchestrer les données qui les entourent. Si leur architecture tient sous des charges de production, les acheteurs disposeront d’une alternative plus complète au modèle d’infrastructure intégrée de Nvidia.

La question centrale n’est pas de savoir si AMD peut livrer un accélérateur rapide. Il s’agit de déterminer si AMD et ses partenaires peuvent faire en sorte qu’un système d’IA entier se comporte comme un seul produit.

Le partenariat AMD Blocks va au-delà de la prise en charge des GPU

VAST considère AMD comme une base d’infrastructure, et non comme une option d’accélérateur ajoutée à la fin d’un cycle commercial.

La collaboration élargie a été dévoilée autour de l’événement Advancing AI 2026 d’AMD, organisé à San Francisco les 22 et 23 juillet. Les entreprises ont décrit une plateforme commune pour l’entraînement, l’inférence, l’apprentissage par renforcement et l’IA agentique.

Le premier engagement concerne les propres appliances de VAST. Les processeurs EPYC de sixième génération, auparavant connus sous le nom de code Venice, équiperont la sixième génération des systèmes VAST CBox et la troisième génération des systèmes EBox.

Les systèmes CBox exécutent les services de données et les opérations de métadonnées au sein de l’architecture VAST. Les systèmes EBox fournissent la capacité de stockage sous-jacente et les chemins de données. L’intégration des processeurs EPYC dans les deux gammes de produits donne à AMD un rôle au sein de la plateforme VAST, même lorsque les clients utilisent d’autres accélérateurs.

La nouvelle génération EPYC prend en charge PCI Express 6.0. Cette interconnexion offre deux fois la bande passante théorique de PCI Express 5.0, ce qui peut améliorer les échanges entre processeurs, stockage, équipements réseau et accélérateurs connectés.

VAST indique que cette bande passante supplémentaire devrait aider ses services de fichiers, d’objets, de bases de données, d’entrepôts de données et de streaming d’événements. Toutefois, les performances applicatives dépendront encore du comportement des logiciels, de la profondeur des files d’attente, de la conception réseau et de la concurrence des charges de travail.

La collaboration couvre également une architecture de référence pour l’infrastructure d’IA développée avec DriveNets. Cette conception associe VAST AI OS, les systèmes AMD Helios à l’échelle du rack et le réseau DriveNets AI Fabric.

Une architecture de référence est un modèle de déploiement documenté, avec des choix de composants, des recommandations de dimensionnement et des connexions validées. Elle réduit le travail de conception, mais ne prouve pas que la charge de travail de chaque client atteindra le même objectif de performance.

Les recommandations prévues couvrent l’entraînement de modèles, l’inférence, l’apprentissage par renforcement et les charges de travail de cache clé-valeur. Un cache clé-valeur, généralement abrégé en cache KV, stocke des données d’attention qu’un modèle de langage peut réutiliser lors de la génération de tokens ultérieurs.

TensorMesh et EmbeddedLLM participent à des travaux supplémentaires sur l’inférence. Leur implication étend le projet au-delà de la qualification des processeurs, jusqu’au déploiement logiciel pour les applications d’agents en production.

La couverture originale cite également sept fournisseurs de cloud d’IA utilisant des services liés à AMD : 5C, Core42, Crusoe, EmbeddedLLM, Phanos.AI, TensorWave et Vultr.

Cette liste de clients montre une activité de déploiement existante, mais elle ne révèle pas quelle capacité exploite chaque fournisseur. Elle n’établit pas non plus si les clients utilisent la conception complète VAST, AMD et DriveNets.

Néanmoins, l’éventail des engagements va bien au-delà d’un badge de certification. AMD intègre la feuille de route produit de VAST, son architecture de référence, ses logiciels d’inférence et son discours de déploiement client.

Le partenariat crée donc un test mesurable. Les acheteurs peuvent l’évaluer à travers des systèmes commercialisés, des conceptions documentées, des benchmarks publics et des références de production, plutôt qu’à partir de déclarations générales sur l’ouverture.

L’inférence transforme le contexte stocké en problème de calcul

Le partenariat intervient maintenant, car l’inférence fait du déplacement des données une partie du chemin critique de chaque réponse.

L’entraînement traditionnel des modèles concentre une puissance de calcul immense dans des exécutions planifiées. L’inférence en production se comporte différemment. Elle traite de nombreuses requêtes simultanées, maintient le contexte utilisateur, récupère des informations externes et génère souvent de longues séquences de raisonnement.

Cette configuration peut laisser des accélérateurs coûteux en attente. Un GPU peut disposer d’une capacité de calcul arithmétique suffisante, tout en restant bloqué pendant que le système charge les poids du modèle, récupère des documents ou reconstruit un contexte précédemment généré.

VAST soutient que l’inférence est fondamentalement un problème de données. Cette affirmation paraît globalement crédible, même si le calcul, le réseau et l’ordonnancement logiciel restent tout aussi importants dans de nombreux déploiements.

Les prompts longs et les conversations à plusieurs tours augmentent le cache KV associé à chaque requête active. Conserver chaque entrée de cache dans la mémoire GPU offre une faible latence, mais la mémoire des accélérateurs est limitée et coûteuse.

Supprimer le cache économise de l’espace, mais oblige le modèle à recalculer les états d’attention antérieurs. Déplacer certaines entrées vers la mémoire hôte ou un stockage partagé crée une autre possibilité, à condition que le système puisse les récupérer assez rapidement.

VAST et AMD testent cette troisième voie. Leur intégration associe les GPU Instinct, AMD Infinity Context, le logiciel ROCm et le stockage VAST afin de décharger les entrées de cache KV réutilisables.

Le chemin de données utilise la carte d’interface réseau Pensando Pollara 400 d’AMD. Elle transfère des informations entre la mémoire GPU et le stockage NVMe de VAST via NFS, en utilisant TCP ou l’accès direct à la mémoire à distance.

L’accès direct à la mémoire à distance, ou RDMA, permet à un système d’accéder à la mémoire d’un autre système avec une implication limitée du CPU. Dans le bon réseau, il peut réduire la latence et la charge processeur lors de transferts répétés.

VAST prévoit également des contrôles automatisés du cycle de vie du cache. Les administrateurs pourraient appliquer des politiques qui expirent et suppriment le contexte stocké contenant des informations personnelles, confidentielles ou réglementées.

Cette fonctionnalité traite une conséquence moins visible du déchargement du cache. Une fois que l’état transitoire du modèle passe dans un stockage partagé, il devient une donnée gouvernée plutôt qu’une mémoire GPU temporaire.

Les entreprises doivent savoir quel utilisateur ou quelle application a créé le cache, combien de temps il reste disponible et si un autre locataire peut y accéder. Elles ont aussi besoin de contrôles de suppression fonctionnant sur les réplicas et les systèmes de reprise.

Le contexte partagé pourrait améliorer l’utilisation dans plusieurs situations. Un agent de support client pourrait réutiliser un long manuel produit dans des milliers de conversations. Un assistant de programmation pourrait conserver le contexte d’un dépôt de code entre des tâches connexes.

Un système de recherche pourrait préserver les documents traités pendant que plusieurs agents examinent les mêmes éléments de preuve. Un service de raisonnement pourrait déplacer les conversations inactives hors de la mémoire des accélérateurs, puis les restaurer lorsque les utilisateurs reviennent.

Ces scénarios expliquent pourquoi les fournisseurs de stockage se rapprochent des logiciels d’inférence. Leur rôle ne s’arrête plus lorsqu’un point de contrôle de modèle atteint un cluster de GPU.

L’architecture de VAST, appelée Disaggregated Shared Everything, sépare les ressources de calcul et de stockage tout en présentant un espace de données commun. L’entreprise affirme que ce modèle prend en charge plusieurs protocoles, des locataires isolés et un espace de noms global.

Cette conception convient aux clouds d’IA qui doivent servir de nombreux clients à partir d’une infrastructure commune. Elle crée également davantage de dépendances entre les couches de stockage, de réseau, d’exécution et d’accélération.

VAST a rapporté des tests initiaux utilisant un GPU Instinct MI355X. L’entreprise affirme que le déchargement du cache à distance a permis une amélioration par neuf du délai jusqu’au premier token et un débit de tokens 9,7 fois supérieur.

Le délai jusqu’au premier token mesure le temps d’attente avant qu’un modèle commence à répondre. Le débit de tokens mesure la quantité de sortie générée par le système au fil du temps, surtout sous une demande simultanée.

Ces chiffres proviennent d’une comparaison spécifique entre le déchargement du cache vers la mémoire hôte locale et une partition VAST distante via NFS avec RDMA. Ils ne constituent pas des résultats face à du matériel Nvidia ni dans un environnement de production complet.

Cette distinction est importante. Les chiffres étayent un mécanisme de stockage dans des conditions testées. Ils n’établissent pas que chaque déploiement VAST et AMD produira une amélioration par neuf.

Malgré tout, l’expérience identifie le mécanisme à l’origine du partenariat. Les entreprises ne prétendent pas que le stockage rend un GPU intrinsèquement plus rapide. Elles cherchent à réduire le travail répétitif et à maintenir les accélérateurs occupés.

AMD a besoin de partenaires pour contrer la pile intégrée de Nvidia

La compétition principale oppose un système AMD ouvert, construit avec des partenaires, à la pile d’infrastructure étroitement coordonnée de Nvidia.

L’avantage de Nvidia dépasse les performances des accélérateurs. CUDA, le réseau, les systèmes, les bibliothèques, les outils de déploiement et l’expertise opérationnelle établie réduisent tous les frictions pour les acheteurs.

Cette base installée façonne les décisions d’achat. Une entreprise qui choisit Nvidia peut souvent trouver des ingénieurs expérimentés, des frameworks éprouvés, de la capacité cloud gérée et des modèles de déploiement existants.

AMD s’attaque au même problème en construisant davantage d’éléments de la plateforme environnante. Sa stratégie combine les CPU EPYC, les GPU Instinct, le réseau Pensando, les racks Helios et le logiciel ROCm.

VAST comble une lacune notable dans cet ensemble. L’entreprise fournit des services de données capables d’alimenter les accélérateurs, d’héberger les actifs des modèles, de gérer le contexte d’inférence et de prendre en charge les applications autour des modèles.

La logique concurrentielle est claire. AMD n’a pas besoin de posséder chaque couche si ses partenaires peuvent intégrer ces couches dans un système cohérent.

Cette approche peut préserver le choix des acheteurs. Un cloud d’IA pourrait combiner aujourd’hui les services de données VAST avec des accélérateurs AMD, tout en conservant une partie de sa capacité Nvidia pour les charges de travail liées à CUDA.

VAST bénéficie également du fait d’éviter une dépendance à un seul fournisseur de GPU. Ses clients souhaitent de plus en plus accéder à plusieurs types d’accélérateurs, car la disponibilité, l’adéquation aux charges de travail et les exigences logicielles varient.

L’entreprise n’abandonne pas Nvidia. Son travail plus approfondi avec AMD positionne plutôt VAST comme une infrastructure de données commune au sein de flottes d’IA hétérogènes.

Cela fait de la stratégie amd blocks une forme de concurrence modulaire. Chaque bloc a un rôle défini, mais le système complet dépend des standards et du travail d’ingénierie entre fournisseurs.

AMD reproduit ce schéma ailleurs. Son partenariat avec Nutanix associe EPYC, Instinct, ROCm, l’orchestration cloud et la gestion du cycle de vie en entreprise.

AMD a engagé un investissement en capital et un financement de l’ingénierie dans cet accord. La structure commerciale diffère de l’annonce de VAST, mais les deux visent les entreprises cherchant une alternative aux plateformes d’IA verticalement intégrées.

AMD a également travaillé avec Red Hat, Oracle, Microsoft, de grands développeurs de modèles et des projets de logiciels d’inférence. Son écosystème logiciel comprend des frameworks et des fournisseurs de modèles capables de réduire les écarts de compatibilité au niveau des applications.

VAST intervient à un autre niveau. L’entreprise se concentre sur le chemin qui mène des informations stockées au contexte actif du modèle, où des déplacements inefficaces peuvent annuler les gains apportés par des processeurs plus rapides.

La conception Helios d’AMD renforce encore les enjeux. Helios regroupe processeurs, GPU, réseau et logiciels dans un système à l’échelle d’une baie, plutôt que de demander aux clients d’assembler eux-mêmes des serveurs accélérés.

L’analyste indépendant Steve McDowell a décrit la configuration Helios de 2026 comme réunissant 72 GPU MI455X et 18 CPU Venice dans une baie refroidie par liquide. Son analyse de Helios présente le défi d’AMD comme la conversion de ses avancées matérielles en capacité déployée comparable à l’échelle de Nvidia.

L’architecture de référence de VAST et DriveNets entoure cette baie de stockage de données et de réseau évolutif. Ensemble, ces composants rapprochent AMD d’un système achetable plutôt que d’un simple catalogue de puces.

Toutefois, la modularité introduit des coûts de coordination. Les clients ont besoin de firmware, pilotes, paramètres réseau, politiques de stockage, versions d’exécution, outils d’observabilité et procédures d’escalade du support alignés.

Nvidia peut résoudre une plus grande partie de ces problèmes au sein d’une même structure d’entreprise. Une conception basée sur AMD répartit les responsabilités entre plusieurs sociétés.

Cette différence constitue le compromis central. Une pile construite par des partenaires offre flexibilité et pouvoir de négociation, mais son expérience opérationnelle doit approcher la cohérence d’une plateforme étroitement intégrée.

VAST peut réduire cette charge grâce à des conceptions de référence documentées et des configurations testées. Elle ne peut pas supprimer le besoin d’un support conjoint entre fournisseurs indépendants.

La pression du marché s’exerce d’abord sur les fournisseurs de cloud IA centrés sur Nvidia et les entreprises qui planifient leur prochain cycle de capacité. Ils disposent désormais d’une autre architecture à évaluer avant d’étendre une empreinte mono-fournisseur.

Elle exerce aussi une pression sur AMD. Les partenariats publics font monter les attentes concernant la disponibilité des systèmes, la reproductibilité des benchmarks et la volonté des clients d’exécuter des charges de travail précieuses en dehors de l’environnement Nvidia.

Le résultat de 9,7x doit être confronté à la réalité de la production

Le benchmark de cache de VAST est encourageant, mais sa base de comparaison étroite ne peut pas trancher la viabilité économique de l’architecture combinée.

Le gain de débit annoncé de 9,7 fois compare deux méthodes de placement de cache dans un test basé sur AMD. Il ne compare pas des systèmes AMD et Nvidia complets, et ne divulgue pas non plus de benchmark standard du secteur.

De nombreux détails peuvent modifier le résultat. La taille du cache, la longueur des prompts, la concurrence des requêtes, l’architecture du modèle, la mémoire hôte disponible, la distance du stockage, la congestion réseau et le taux de succès du cache influent tous sur les performances.

Le choix de la base de comparaison compte tout particulièrement. La mémoire hôte locale semble plus rapide que le stockage distant, mais la pression sur la capacité et les schémas d’accès peuvent inverser cette attente sous forte concurrence.

Une partition VAST distante peut mutualiser la capacité entre les serveurs et préserver davantage de contexte réutilisable. Si la base en mémoire locale évince fréquemment des entrées utiles, le stockage distant peut éviter une recomputation substantielle.

Il s’agit d’un avantage système valable. Les acheteurs doivent néanmoins comprendre précisément dans quelles conditions il se manifeste.

VAST reconnaît que les accélérations relatives dépendent du matériel sous-jacent. Un système doté d’une capacité de calcul ou d’une latence de stockage différente peut produire un ratio différent.

Les charges de production mélangent aussi les types de requêtes. Certaines conversations sont courtes et tirent peu parti d’un cache persistant. D’autres contiennent de grands contextes, mais reviennent trop rarement pour justifier la conservation de leur état.

La réutilisation du cache crée une autre incertitude. Le déport ne produit de valeur que lorsqu’une requête ultérieure peut réutiliser les informations stockées à moindre coût que leur recomputation.

Les administrateurs ont donc besoin de politiques d’admission et d’éviction. Le système doit décider quelles entrées méritent d’être stockées, lesquelles doivent rester dans la mémoire de l’accélérateur et lesquelles doivent disparaître.

Les contrôles de sécurité exigent la même attention. Un cache KV stocké peut encoder des informations sensibles issues des prompts, des documents récupérés et des sorties précédentes du modèle.

Les politiques de suppression automatisées sont utiles, mais les acheteurs auront besoin d’éléments probants concernant l’isolation des locataires, le chiffrement, les journaux d’accès, la réplication, le comportement des sauvegardes et l’effacement vérifiable.

La qualité de l’inférence entre également en jeu. Un cache obsolète ou associé de manière incorrecte pourrait produire des sorties invalides, une contamination entre utilisateurs ou des échecs difficiles à diagnostiquer.

L’annonce de collaboration décrit la gestion du cycle de vie, mais ne publie pas de modèle de menace complet. Elle n’explique pas non plus comment l’application des politiques fonctionne dans chaque environnement d’inférence pris en charge.

La responsabilité opérationnelle reste non résolue. Un problème de latence peut provenir de ROCm, du serveur de modèles, du réseau Pollara, de la fabric DriveNets, des paramètres NFS, du logiciel VAST ou de l’application elle-même.

Les architectures de référence peuvent définir les versions prises en charge et les procédures de diagnostic. Les retours clients révéleront si ces procédures fonctionnent lors d’incidents réels.

La même prudence s’applique aux déclarations plus larges d’AMD sur les performances. Les tests internes peuvent guider l’évaluation, mais les acheteurs devraient reproduire les résultats avec leurs modèles, leurs prompts, leur niveau de concurrence et leurs objectifs de niveau de service.

Une entreprise devrait comparer le comportement du système dans son ensemble plutôt que les seules spécifications des accélérateurs. Les mesures importantes incluent les requêtes terminées par baie, la latence du premier token, la latence des tokens de sortie, la consommation d’énergie, les taux de succès du cache, la reprise après défaillance et le temps d’ingénierie.

La collaboration élargie évoque une efficacité et des performances améliorées. Elle ne divulgue ni les prix clients, ni la durée des déploiements, ni des économies de production auditées.

Cette absence est normale pour une annonce d’architecture précoce. Elle signifie aussi que la conclusion commerciale reste ouverte.

L’approche des blocs AMD sera crédible lorsque plusieurs clients feront état de résultats prévisibles en matière de déploiement et d’exploitation. Une démonstration de grande ampleur lors d’un événement fournisseur est utile, mais c’est la reproductibilité qui crée la confiance.

VAST et AMD font également face à une cible mouvante. Nvidia continue d’améliorer le réseau, les logiciels d’inférence, l’intégration du stockage et les systèmes à l’échelle d’une baie.

D’autres entreprises de stockage poursuivent la même opportunité consistant à alimenter les GPU. Weka, DDN, Dell, HPE, Pure Storage et les plateformes de données cloud-native souhaitent tous jouer un rôle plus important dans l’infrastructure IA.

Les clients disposent donc de plus de deux choix. Ils peuvent utiliser une pile Nvidia intégrée, assembler des systèmes basés sur AMD ou exploiter des clusters mixtes avec une infrastructure de données distincte.

La voie gagnante variera selon la charge de travail. Une entreprise liée à des logiciels spécifiques à CUDA peut accepter moins de choix matériels afin de réduire le travail de migration.

Un cloud IA servant des modèles ouverts avec une forte concurrence peut davantage valoriser la diversité des accélérateurs et la capacité de cache partagée. Les grandes entreprises peuvent privilégier la responsabilité du support et les contrôles de conformité plutôt que les ratios de benchmark maximaux.

Ces distinctions empêchent l’annonce de devenir un simple tableau de score AMD contre Nvidia. Il s’agit d’une option architecturale qui doit gagner sa place grâce à des preuves spécifiques aux charges de travail.

Trois signaux montreront si la stratégie fonctionne

La prochaine phase dépend de la livraison de systèmes de référence, de la publication de résultats reproductibles et de la démonstration d’une adoption au-delà des partenariats nommés.

Le premier signal est la disponibilité des prochaines générations de CBox et EBox de VAST utilisant des processeurs EPYC de sixième génération. Des systèmes livrés transformeront un engagement de feuille de route en équipements que les clients peuvent qualifier.

Les acheteurs devraient surveiller les configurations prises en charge, les dates de disponibilité générale, les chemins de mise à niveau et les recommandations de déploiement. Une large disponibilité renforcerait l’affirmation selon laquelle AMD devient une plateforme VAST standard.

Des retards ou des configurations limitées affaibliraient cette conclusion. Ils suggéreraient que le partenariat est plus avancé en matière de marketing que d’opérations produit.

Le deuxième signal est l’extension des tests de cache KV. Des informations utiles incluraient les modèles, les longueurs de contexte, les niveaux de concurrence, les taux de succès du cache, la topologie réseau et les distributions de latence.

Les preuves les plus solides viendraient de tests exécutés par des clients ou d’instructions de benchmark reproductibles. Des résultats obtenus sur plusieurs modèles et moteurs d’inférence montreraient si le mécanisme se transpose au-delà d’une seule charge de travail contrôlée.

Une amélioration répétée renforcerait l’argument en faveur du stockage partagé comme infrastructure d’inférence active. Des gains plus faibles ou incohérents réduiraient les cas d’usage accessibles à cette technologie.

Le troisième signal est l’adoption en production de l’architecture de référence conjointe. Des clients nommés montrent déjà un intérêt pour la capacité AMD, mais les déploiements de la conception complète comptent davantage.

Surveillez les clients qui connectent des baies Helios, le réseau DriveNets, VAST AI OS et l’inférence basée sur ROCm dans un même environnement pris en charge. Leurs rapports opérationnels devraient inclure l’utilisation, la fiabilité et le temps de déploiement.

L’expansion chez les clients validerait la réponse d’AMD, menée par des partenaires, à l’avantage d’intégration de Nvidia. Des pilotes isolés montreraient que le choix technique ne suffit pas à surmonter la familiarité avec les logiciels et la complexité du support.

La propre feuille de route d’AMD ajoute un sentiment d’urgence. L’entreprise avait auparavant ciblé la disponibilité de Helios au cours de 2026 et signalé une adoption croissante de ROCm dans sa stratégie de centre de données.

VAST offre à cette stratégie une couche de données plus robuste. Elle crée également un test exigeant, car le stockage et la gestion du contexte se situent directement sur le chemin de latence visible par l’utilisateur.

Les développeurs devraient s’y intéresser, car les choix d’infrastructure déterminent quels modèles, environnements d’exécution et outils d’optimisation restent pratiques. Un meilleur support d’AMD peut réduire la dépendance aux logiciels conçus autour d’une seule plateforme d’accélérateurs.

Les opérateurs de cloud IA devraient s’y intéresser, car le temps GPU inutilisé réduit directement la capacité de service disponible. Le contexte partagé ne peut aider que si ses coûts de stockage et de réseau restent inférieurs à la recomputation qu’il remplace.

Les acheteurs en entreprise devraient s’y intéresser, car les données d’inférence sont soumises à des exigences de gouvernance. Déplacer le contexte mis en cache vers un stockage géré peut améliorer le contrôle, mais élargit également le périmètre de sécurité.

Les travailleurs du savoir en ressentiront le résultat indirectement. Si les systèmes préservent efficacement un contexte utile, les assistants peuvent gérer des projets plus longs sans reconstruire sans cesse le même arrière-plan.

Ce résultat dépend aussi de la manière dont les applications organisent les documents sources. Une base de connaissances IA bien entretenue peut améliorer la récupération avant même le début de toute optimisation de l’infrastructure.

La stratégie des blocs AMD n’est donc pas une déclaration selon laquelle AMD a évincé Nvidia. C’est un plan visant à rendre le calcul AMD plus facile à déployer dans le cadre d’un système d’inférence complet.

VAST a engagé du matériel, des logiciels, du réseau, de la gestion de cache et des conceptions de référence dans ce plan. Le travail restant consiste à obtenir une validation publique face à une demande client mixte et soutenue.

Au cours des prochains mois, ignorez les affirmations générales sur l’ouverture ou les usines d’IA. Recherchez des appliances VAST livrées, des résultats de cache reproductibles et des clients exploitant l’architecture complète.

Ces trois signaux montreront si le partenariat crée une deuxième voie crédible pour l’infrastructure IA, ou simplement une autre collection de composants compatibles.