Le rack AI centré sur la mémoire de SK hynix défie le serveur pensé d’abord pour les GPU

SK hynix a dévoilé un rack AI centré sur la mémoire lors de l’OCP Global Summit 2026, remettant en question la conception axée sur les processeurs qui a façonné les serveurs AI modernes. Son architecture MARS dissocie la mémoire des CPU et GPU individuels, puis rend cette capacité partageable à l’échelle d’un rack. La proposition vise un conflit croissant : ajouter des accélérateurs ne résout pas automatiquement les problèmes de déplacement, de duplication et de stockage des données d’inférence.

L’entreprise a présenté MARS, abréviation de Memory-Centric AI Rack System, à San Jose lors du sommet organisé du 12 au 15 octobre. Ses démonstrations combinaient de la mémoire CXL, de la DRAM, des SSD, de la mémoire computationnelle et des logiciels de plusieurs partenaires. L’idée centrale est simple, même si sa mise en œuvre ne l’est pas. La mémoire doit devenir une ressource partagée à l’échelle du rack, plutôt que de rester enfermée dans des serveurs individuels.

Cette position oppose SK hynix au modèle établi de serveur centré sur les GPU, et non à un fabricant de puces ou fournisseur de mémoire en particulier. NVIDIA, AMD et d’autres fournisseurs de processeurs construisent déjà des plateformes de rack de plus en plus intégrées. SK hynix soutient que l’infrastructure d’inférence a aussi besoin d’une couche mémoire gérée indépendamment, en particulier à mesure que les charges de travail agentiques accumulent de grands caches et des contextes plus longs.

Le rack AI centré sur la mémoire de SK hynix passe des composants aux systèmes

Le changement important n’est pas un nouveau module mémoire. SK hynix propose désormais une nouvelle manière d’organiser la mémoire de l’ensemble du rack AI.

SK hynix fournit traditionnellement des composants que les concepteurs de serveurs placent autour des processeurs. Lors de l’OCP Global Summit 2026, l’entreprise a présenté une position architecturale plus large au travers du système MARS. La conception intègre du matériel et des logiciels partenaires dans un même rack, avec une mémoire partagée placée en son centre.

Un rack est la structure physique qui accueille les serveurs, les équipements réseau, le stockage, les systèmes d’alimentation et d’autres infrastructures. Aujourd’hui, chaque serveur possède généralement une quantité fixe de mémoire locale. Un serveur peut épuiser sa capacité alors que de la mémoire inutilisée reste inaccessible ailleurs dans le même rack.

MARS cherche à modifier ce modèle d’allocation. Il utilise Compute Express Link, ou CXL, pour relier processeurs et mémoire au moyen d’une interface cohérente en cache fondée sur PCI Express. La mutualisation CXL permet à plusieurs hôtes d’accéder à la capacité d’un ensemble partagé de périphériques mémoire.

L’entreprise a présenté trois démonstrations MARS avec des partenaires, plutôt qu’un simple schéma conceptuel. Arcee, Liqid et Marvell ont participé à une démonstration reliant plusieurs serveurs et GPU à de la mémoire mutualisée. SK hynix a indiqué que le système transférait et réutilisait des caches clé-valeur sans dépendre entièrement des communications réseau conventionnelles.

Un cache clé-valeur, couramment appelé cache KV, stocke les données intermédiaires qu’un modèle de langage a déjà calculées. Réutiliser ces données évite au modèle de recalculer le même contexte pour chaque token généré. Le cache grossit à mesure que les conversations, les documents et les tâches agentiques en plusieurs étapes s’allongent.

Une autre démonstration combinait des technologies d’AMD, Penguin Solutions, XCENA et Arcee. Elle plaçait de la capacité DRAM et SSD derrière une couche de mémoire hybride basée sur CXL. Le système prédisait les données mises en cache nécessaires, les chargeait dans la DRAM et conservait le cache complet sur des SSD.

Une troisième démonstration avec le fournisseur d’agents AI personnels Pickle se concentrait sur les transferts entre plusieurs modèles. Selon SK hynix, le streaming depuis la mémoire mutualisée a réduit le temps nécessaire au déplacement des données entre ces modèles. L’entreprise a présenté cette approche comme un moyen de réduire le délai avant qu’un agent ne renvoie son résultat final.

Ces démonstrations importent parce qu’elles font passer la proposition au-delà de benchmarks mémoire isolés. Elles montrent comment une capacité mutualisée pourrait prendre en charge de véritables tâches d’inférence, notamment le partage de cache, les pipelines multimodaux et les agents personnels. SK hynix n’a toutefois pas publié de résultats de performances complets et reproductibles de manière indépendante pour les démonstrations MARS.

L’événement lui-même a également renforcé l’orientation architecturale. L’Open Compute Project a présenté son thème 2026 comme l’extension de l’infrastructure pour l’ère de l’AI. Sa vision du sommet appelait à des changements couvrant les puces, les racks, le refroidissement, l’alimentation, les réseaux et les installations de centres de données.

Ce contexte explique pourquoi SK hynix a mis l’accent sur un système plutôt que sur une nouvelle feuille de route de composants. L’entreprise veut que les fournisseurs de mémoire participent aux décisions des opérateurs concernant le comportement d’un rack AI. Cela donnerait à l’architecture mémoire un rôle plus important avant que les serveurs n’atteignent leurs conceptions finales de production.

L’inférence transforme la capacité mémoire en problème à l’échelle du rack

L’inférence AI modifie le goulot d’étranglement, car le traitement de charges longues et persistantes exige à la fois un calcul rapide et une mémoire réutilisable de grande capacité.

L’entraînement AI a placé les accélérateurs et la mémoire à haute bande passante au centre de la planification des infrastructures. L’entraînement déplace à répétition de grands ensembles de paramètres de modèles à travers des processeurs parallèles. La HBM se situe près de ces processeurs et fournit la bande passante nécessaire pour les maintenir actifs.

L’inférence crée un ensemble de contraintes différent. Chaque requête peut inclure un long prompt, un historique de conversation stocké, des documents récupérés, des résultats d’outils, des images ou de l’audio. Les systèmes agentiques peuvent maintenir plusieurs charges de ce type tout en coordonnant de multiples modèles et services.

L’état qui en résulte ne tient pas aisément dans un seul accélérateur. Les caches KV consomment de la capacité à mesure que les contextes s’allongent, tandis que les poids de modèles et les embeddings créent une demande supplémentaire. Les opérateurs doivent décider quelles informations restent en HBM, lesquelles passent dans la mémoire système et lesquelles sont reléguées au stockage.

Ajouter un GPU peut fournir davantage de HBM attachée, mais cela ajoute aussi une ressource de calcul coûteuse. C’est inefficace lorsque la contrainte immédiate est la capacité plutôt que le débit de calcul. Cela peut également laisser de la mémoire inutilisée lorsque les charges de travail varient entre serveurs.

SK hynix soutient que la réponse est la désagrégation, qui sépare la capacité mémoire d’un processeur spécifique et l’alloue selon les besoins. Hosik Kim, responsable de la recherche sur les systèmes mémoire au sein de l’entreprise, a décrit les limites physiques et économiques entourant la mémoire GPU pendant sa présentation au sommet. Sa proposition à l’échelle du rack appelait à des systèmes construits autour de ressources mémoire désagrégées et de SSD.

L’évolution vers les agents renforce cet argument. Un chatbot conventionnel peut abandonner une grande partie de son état temporaire après une session. Un agent persistant peut devoir préserver le contexte, revenir sur des travaux antérieurs, coordonner des modèles spécialisés et servir de nombreux utilisateurs simultanés.

Cela modifie la valeur de la réutilisation de la mémoire. Si plusieurs serveurs d’inférence peuvent accéder à un même prompt mis en cache ou à un préfixe partagé, ils ont besoin de moins de copies dupliquées. Si un serveur défaillant ou surchargé peut transférer le travail ailleurs sans déplacer tout l’état sur le réseau, les temps de réponse pourraient s’améliorer.

La mémoire mutualisée CXL est conçue pour rendre ce partage plus direct. Elle peut exposer une capacité à l’échelle du rack via une sémantique mémoire, au lieu de traiter chaque transfert comme une opération de stockage ou réseau conventionnelle. Le partage sans copie vise à permettre aux processeurs d’accéder aux mêmes données sans créer une autre copie complète.

La charge de travail détermine néanmoins si cette approche est utile. Certaines opérations d’inférence dépendent d’une latence extrêmement faible et exigent une HBM située à côté de l’accélérateur. D’autres données peuvent tolérer une latence plus élevée si le système gagne beaucoup plus de capacité ou évite les duplications.

C’est pourquoi MARS ne propose pas de remplacer la HBM. SK hynix a présenté HBM4, HBM4E, de la DRAM serveur, des SSD d’entreprise et High Bandwidth Flash aux côtés de ses systèmes CXL. Sa stratégie repose sur une hiérarchie dans laquelle le logiciel place chaque type de données sur le niveau approprié.

Le calendrier reflète également une transition à l’échelle de l’industrie. OCP prévoit que la prochaine vague d’inférence se répandra au-delà des sites hyperscale centralisés. Les centres de données régionaux, les installations d’entreprise, les sites de télécommunications et les sites industriels auront besoin de systèmes présentant des contraintes d’alimentation et de capacité différentes.

Ces environnements ne peuvent pas résoudre chaque pénurie de mémoire en achetant davantage de racks d’accélérateurs. Un pool partagé pourrait améliorer l’utilisation sur des charges inégales. Il pourrait aussi rendre l’extension de capacité plus indépendante d’une génération spécifique de processeurs.

Pour les acheteurs en entreprise, la question clé évolue donc. Le choix ne porte plus seulement sur l’accélérateur qui fournit le meilleur score de benchmark. Les acheteurs doivent aussi savoir comment le rack gère l’état du modèle, la croissance du cache, le déplacement des données et la mémoire inutilisée.

La mémoire mutualisée CXL est le mécanisme derrière MARS

Le système MARS de SK hynix repose sur CXL pour transformer la mémoire en infrastructure composable, tandis que le logiciel décide de ce qui appartient à chaque niveau.

SK hynix a présenté un module CMM-DDR5 de deuxième génération de 256GB basé sur CXL 3.2. CMM signifie CXL Memory Module, un périphérique qui étend ou partage la mémoire via l’interface CXL. L’entreprise affirme que le module atteint 80GB par seconde de bande passante.

Ce chiffre représente plus du double de la bande passante de la génération précédente de SK hynix. L’entreprise revendique également une amélioration de l’efficacité énergétique d’environ 30 pour cent. Ces chiffres décrivent la comparaison de produits de SK hynix et n’ont pas fait l’objet d’une vérification étendue par des tiers.

Le module prend en charge la mutualisation CXL, permettant aux hôtes de tirer de la capacité d’une ressource commune. L’allocation dynamique peut donner davantage de mémoire à un serveur occupé sans lui attribuer cette capacité de manière permanente. Un hôte moins sollicité peut restituer sa capacité inutilisée à une autre charge de travail.

Ce mécanisme s’attaque à la mémoire inutilisée, mais modifie aussi le modèle de défaillance et de gestion. Les opérateurs ont besoin de contrôles pour l’isolation, les autorisations d’accès, la qualité de service, la télémétrie et la reprise. Les erreurs mémoire ou la congestion du fabric peuvent affecter un groupe plus large de machines lorsque la capacité devient partagée.

MARS ajoute un niveau hybride sous la DRAM mutualisée. La mémoire hybride CXL combine la DRAM avec la capacité SSD, permettant aux données fréquemment consultées de rester dans une mémoire plus rapide. Les données moins actives peuvent rester sur un stockage de plus grande capacité jusqu’à ce que le système prédise qu’elles seront bientôt nécessaires.

SK hynix a montré ce comportement avec de grands caches KV. La démonstration aurait prédit des entrées de cache utiles à partir de conversations antérieures et d’historiques de tâches. Elle chargeait ensuite ces entrées dans la DRAM avant que la charge de travail ne les demande.

Ce processus ressemble à la mise en cache ailleurs en informatique, mais l’inférence AI ajoute une échelle et des schémas d’accès inhabituels. Une décision de cache peut influencer le temps jusqu’au premier token, la génération soutenue de tokens et le nombre d’utilisateurs servis simultanément. Une mauvaise prédiction peut aussi ajouter des déplacements et des délais supplémentaires.

Des chercheurs affiliés à SK hynix ont étudié cette approche hiérarchisée dans un article de 2026 intitulé ITME. Le système proposé combine de la mémoire CXL de niveau production avec des SSD PCIe Gen5 pour de grands états d’inférence. Ses auteurs ont rapporté un débit jusqu’à 35,7 pour cent supérieur à l’offloading CPU conventionnel dans leur évaluation.

Ce chiffre ne doit pas être considéré comme un benchmark MARS général. L’étude a évalué une architecture, une configuration et une charge de travail spécifiques. Elle fournit néanmoins des éléments techniques indiquant que la mémoire hiérarchisée peut améliorer l’inférence lorsque l’empreinte des caches dépasse la capacité locale de l’hôte.

La mémoire computationnelle constitue une autre partie du mécanisme. Au lieu de déplacer chaque jeu de données vers un CPU ou un GPU, certaines opérations sélectionnées s’exécutent près de la mémoire qui stocke ces données. SK hynix appelle son module doté de capacités de calcul CMM-Ax.

Au sommet, CMM-Ax a pris en charge une démonstration efficace de modèle de langage à long contexte. Le long contexte signifie que le modèle peut traiter davantage de texte ou d’autres entrées dans une même requête. Cette capacité exige plus de mémoire et entraîne des mouvements supplémentaires entre les niveaux de traitement et de capacité.

Rapprocher des calculs limités de la mémoire peut réduire le trafic, la consommation électrique et la surcharge des processeurs. Cela ne transforme pas un module mémoire en substitut général à un GPU. Les opérations utiles doivent convenir aux ressources de calcul spécialisées et au modèle de programmation du module.

Une démonstration indépendante de XCENA illustre à la fois l’opportunité et les éléments de preuve manquants. Son contrôleur MX1 a pris en charge des caches KV partagés et la recherche vectorielle au sein d’un dispositif mémoire CXL. La démonstration de mémoire computationnelle utilisait des milliers de petits cœurs RISC-V et prenait en charge d’importantes configurations DRAM.

Cependant, XCENA n’a pas publié les détails de latence, de débit ou de configuration complète des serveurs pour ces démonstrations du sommet. Cette omission rend les comparaisons directes difficiles. Elle montre également pourquoi les acheteurs doivent distinguer les démonstrations fonctionnelles des promesses de performances prêtes pour la production.

Le mécanisme plus large est donc une hiérarchie mémoire coordonnée. La HBM traite les données les plus sensibles à la bande passante, à proximité des accélérateurs. La DRAM partagée étend la capacité accessible, la mémoire computationnelle exécute certaines opérations, et les SSD conservent des jeux de données plus volumineux ou moins sollicités.

Le logiciel doit rendre cette hiérarchie cohérente. Il doit identifier les données importantes, anticiper les accès futurs, déplacer les informations avant qu’elles ne deviennent urgentes et se rétablir lorsque les prédictions échouent. Sans ces contrôles, des niveaux de mémoire supplémentaires peuvent créer de la complexité plutôt qu’une capacité utile.

Le rack centré sur les GPU ne reste pas immobile

SK hynix remet en question la conception centrée sur les processeurs, mais les fournisseurs d’accélérateurs considèrent déjà le réseau, la mémoire et les logiciels comme les composants d’un même ordinateur à l’échelle du rack.

Les racks d’IA modernes deviennent des systèmes étroitement intégrés. Les plateformes NVIDIA associent GPU, CPU, interconnexions à haut débit, réseau, refroidissement et logiciels. AMD construit également des plateformes à l’échelle du rack autour des accélérateurs et de standards d’infrastructure ouverts.

Cette intégration confère aux fournisseurs de processeurs un avantage important. Ils contrôlent les chemins logiciels utilisés par les frameworks d’IA, les moteurs de service des modèles, les bibliothèques de communication et les outils d’orchestration. Une structure mémoire doit s’intégrer à ces chemins sans créer d’intégrations personnalisées fragiles.

SK hynix ne cherche pas à retirer le processeur du centre des calculs. Son argument porte sur la propriété des ressources et le placement des données. L’entreprise veut que la capacité mémoire fonctionne comme un service à l’échelle du rack plutôt que de rester subordonnée à chaque serveur.

Cette distinction rend le conflit principal architectural, et non corporatif. Un rack centré sur les GPU évolue en ajoutant des nœuds de calcul étroitement couplés et leur mémoire associée. Un rack centré sur la mémoire traite la capacité comme un pool distinct accessible par plusieurs unités de calcul.

Chaque approche présente des compromis. La mémoire locale des accélérateurs offre une latence prévisible et une bande passante élevée. La mémoire partagée peut fournir davantage de capacité et une meilleure utilisation, mais l’accès traverse des liens, commutateurs, contrôleurs et couches logicielles supplémentaires.

Les deux conceptions peuvent coexister au sein d’une même plateforme. Un GPU peut conserver les tenseurs actifs et les entrées de cache immédiates dans la HBM, tandis qu’un contexte plus ancien réside dans une DRAM mutualisée. Une capacité soutenue par SSD peut préserver un état bien plus important qui ne requiert pas la latence de la HBM.

Samsung a présenté ses propres travaux de mutualisation CXL à l’OCP Global Summit 2026, y compris une charge de travail d’agent utilisant de la mémoire allouée dynamiquement. Cet effort parallèle suggère que la mutualisation de la mémoire devient une exigence concurrentielle plutôt qu’un projet isolé de SK hynix.

La concurrence impliquera également les fournisseurs de contrôleurs, les fabricants de serveurs, les opérateurs cloud et les développeurs de logiciels. Marvell, Liqid, XCENA, Penguin Solutions, Arcee, NAVER Cloud et AMD figuraient parmi les démonstrations de SK hynix. Aucun fournisseur unique ne contrôle toutes les couches nécessaires au déploiement.

Cette dépendance envers les partenaires peut renforcer l’architecture si les interfaces restent ouvertes. Elle peut aussi ralentir l’adoption lorsque les firmwares, pilotes, logiciels d’orchestration et outils d’observabilité évoluent à des vitesses différentes. Les opérateurs rejetteront les gains de capacité si le dépannage devient imprévisible.

La standardisation fait donc partie de la compétition. Youngpyo Joo, dirigeant de SK hynix, a participé à un panel OCP sur l’alignement des frameworks logiciels et des API entre fournisseurs. La discussion portait sur les logiciels nécessaires pour connecter des produits dans un marché mêlant coopération et concurrence.

CXL fournit une base matérielle commune, mais une spécification ne garantit pas un comportement identique entre les produits. Les politiques d’allocation mémoire, la gestion de la topologie, la sécurité et le placement des charges de travail nécessitent encore des logiciels cohérents. L’optimisation des performances varie aussi selon les CPU, GPU, commutateurs et dispositifs mémoire.

L’approche centrée sur les GPU bénéficie d’habitudes de développement éprouvées. Les équipes analysent déjà l’utilisation des accélérateurs, planifient les tâches selon la disponibilité des GPU et optimisent les noyaux pour des plateformes spécifiques. Une architecture centrée sur la mémoire leur demande d’observer de nouveaux goulets d’étranglement et d’ajuster de nouveaux niveaux de ressources.

Son meilleur chemin vers l’adoption masquera probablement une grande partie de cette complexité. Les serveurs de modèles devraient demander de la capacité ou un état partagé via des interfaces logicielles stables. Les développeurs ne devraient pas avoir à gérer manuellement chaque dispositif mémoire physique.

Pour les hyperscalers, les gains économiques pourraient justifier ce travail. Même des améliorations modestes de l’utilisation de la mémoire peuvent compter à l’échelle de grandes flottes. Pour les petites entreprises, les coûts d’intégration peuvent dépasser les économies jusqu’à ce que les fournisseurs proposent des systèmes testés avec des limites de support clairement définies.

MARS exerce donc une pression sur les deux camps. Les fournisseurs de plateformes d’accélérateurs doivent mieux répondre aux besoins d’extension de capacité et de partage de cache. SK hynix et ses partenaires doivent montrer que la mémoire composable fonctionne de manière fiable dans les environnements logiciels que les clients utilisent déjà.

Les résultats de preuve de concept laissent les questions difficiles ouvertes

Le sommet a établi la faisabilité technique, mais il n’a pas établi MARS comme choix par défaut pour les infrastructures d’IA en production.

SK hynix a décrit plusieurs démonstrations comme des validations de preuve de concept. Une preuve de concept vérifie qu’une approche peut fonctionner dans certaines conditions choisies. Elle n’établit ni la fiabilité à l’échelle d’une flotte, ni les performances générales, ni la simplicité opérationnelle, ni la disponibilité commerciale.

L’entreprise a utilisé un langage affirmé sur les améliorations de performances dans son annonce. Pourtant, elle n’a pas fourni de résultats complets pour la démonstration d’agent à mémoire mutualisée. Les détails publics omettent les tailles des modèles, les schémas de requêtes, le nombre de serveurs, les distributions de latence, les mesures de consommation et les configurations de référence.

Ces détails déterminent si la mémoire mutualisée CXL l’emporte en pratique. Un système peut améliorer le débit global tout en augmentant la latence de queue, qui mesure les requêtes les plus lentes. Il peut réduire la duplication tout en introduisant une contention dans la structure de communication pendant les pics de demande.

L’accès CXL est également plus lent que la HBM directement attachée. Cet écart n’invalide pas la mutualisation, car chaque octet ne requiert pas les performances de la HBM. Il exige toutefois un placement soigneux afin que les données fréquemment consultées ne passent pas trop de temps sur un niveau distant.

Le profil de charge de travail compte autant que le matériel. Les préfixes partagés et les conversations répétées créent des opportunités de réutilisation du cache. Des prompts imprévisibles ou des contextes évoluant rapidement peuvent réduire cette réutilisation et affaiblir le bénéfice d’un cache partagé.

La prédiction introduit un autre risque. Les démonstrations MARS préchargeaient les entrées de cache probables dans la DRAM. Des prédictions correctes peuvent masquer un accès au stockage plus lent. Des prédictions incorrectes gaspillent de la bande passante et occupent un espace dont une autre charge de travail pourrait avoir besoin.

Les limites de sécurité exigent également un examen attentif. Plusieurs serveurs partageant de la mémoire ne doivent pas exposer les prompts, embeddings ou états mis en cache d’un locataire à un autre. L’isolation doit couvrir le matériel, le firmware, les logiciels d’orchestration et la récupération après défaillance.

L’évolution vers des agents persistants augmente les enjeux. Un cache KV peut refléter les conversations des utilisateurs et l’historique des tâches. Les opérateurs ont besoin de règles claires de suppression, de conservation, de chiffrement et d’audit lorsque cet état circule entre mémoire mutualisée et niveaux SSD.

La fiabilité devient plus complexe lorsqu’un rack dépend d’une structure partagée. Un module défaillant ne devrait pas bloquer des hôtes non concernés. Les contrôleurs doivent assurer un basculement prévisible, tandis que les systèmes de supervision doivent déterminer si les retards proviennent du calcul, de la mémoire locale, de la mémoire mutualisée, du stockage ou du réseau.

Les affirmations sur l’énergie nécessitent aussi des mesures à l’échelle du système. Un module mémoire peut utiliser l’énergie plus efficacement tandis que l’architecture globale ajoute des commutateurs, des contrôleurs ou des mouvements de données supplémentaires. Les acheteurs ont besoin de résultats à l’échelle du rack, et non de simples comparaisons de composants.

L’économie de production reste incertaine. SK hynix n’a pas annoncé de disponibilité générale, de prix clients ou de volumes de déploiement pour MARS. L’entreprise n’a pas non plus indiqué si NAVER Cloud prévoit d’exploiter l’architecture dans un service de production destiné aux clients.

Le module CXL de deuxième génération de l’entreprise offre des spécifications plus concrètes. Une couverture indépendante a confirmé que SK hynix a présenté le produit CXL 3.2 de 256GB et l’amélioration d’efficacité annoncée. Le résumé du portefeuille mémoire repose néanmoins principalement sur des informations fournies par l’entreprise.

Les preuves les plus solides viendront d’opérateurs publiant des résultats reproductibles. Les mesures pertinentes comprennent le temps jusqu’au premier token, les tokens par seconde, les sessions simultanées, les taux de succès du cache, la consommation du rack et l’utilisation de la mémoire. Les résultats devraient comparer des objectifs de qualité de service équivalents, et non seulement le débit maximal.

La portabilité logicielle représente un autre test. Une charge de travail optimisée pour un contrôleur ou une structure de communication ne devrait pas nécessiter une réécriture complète lorsque l’opérateur change de fournisseur de serveurs. Les API ouvertes et une télémétrie commune détermineront si CXL devient une infrastructure ou reste une collection de démonstrations.

MARS doit donc être compris comme une proposition architecturale crédible, assortie d’une validation système précoce. Ce n’est pas encore la preuve que les racks centrés sur la mémoire remplaceront les conceptions conventionnelles. La proposition mérite l’attention parce qu’elle identifie un véritable goulet d’étranglement et offre une réponse techniquement cohérente.

Trois signaux montreront si les racks d’IA centrés sur la mémoire représentent l’avenir

La prochaine étape dépend de preuves de production, de logiciels interopérables et d’une réponse claire des fournisseurs de plateformes à l’échelle du rack.

Le premier signal est un déploiement client divulgué. SK hynix travaille avec NAVER Cloud depuis septembre 2025 sur des solutions mémoire basées sur CXL pour les charges de travail cloud d’IA. À l’OCP, les entreprises ont présenté des travaux de preuve de concept impliquant le partage de cache KV et un service de partage d’embeddings.

Une annonce de production devrait identifier la charge de travail, l’échelle du déploiement et un résultat mesurable. Elle devrait également montrer si la mémoire mutualisée réduit les achats d’accélérateurs, augmente la capacité de sessions ou améliore le temps de réponse. Sans ces détails, le nom d’un client reste un élément de soutien plutôt qu’une validation.

Un déploiement NAVER Cloud avec des gains reproductibles renforcerait le dossier de SK hynix. La poursuite d’un discours de preuve de concept sans jalons de production affaiblirait l’affirmation à court terme. Cela suggérerait que l’intégration reste plus difficile que ne le laisse entendre la démonstration matérielle.

Le deuxième signal est l’alignement logiciel entre fournisseurs. Les groupes de travail OCP et les participants à CXL ont besoin de frameworks communs pour découvrir les pools, allouer la capacité, surveiller les performances et faire respecter l’isolation. Les plateformes de service de modèles doivent aussi savoir quand placer les données de cache dans la HBM, la DRAM ou une mémoire soutenue par SSD.

Surveillez les intégrations prises en charge avec des frameworks d’inférence largement utilisés plutôt que du code de démonstration ponctuel. Des API stables, une prise en charge de l’orchestration et une télémétrie partagée réduiraient le risque de déploiement. Des outils de gestion fragmentés favoriseraient les racks étroitement intégrés et pilotés par les processeurs.

Le troisième signal est la réaction des fournisseurs de GPU et de plateformes de racks. Ils peuvent adopter des niveaux de mémoire externes, améliorer leurs propres systèmes de mutualisation ou conserver davantage de mémoire directement attachée aux accélérateurs. Leurs feuilles de route révéleront si la mémoire composable devient une norme ou reste spécifique à certaines charges de travail.

Un fournisseur de processeurs prenant en charge des pools CXL communs renforcerait la thèse centrée sur la mémoire, même si son rack reste orienté calcul. Une alternative propriétaire pourrait fragmenter le marché. Des configurations de mémoire locale plus importantes pourraient également retarder la mutualisation pour les clients qui privilégient une latence prévisible.

SK hynix a déjà montré que le débat dépasse la DRAM CXL. Son portefeuille associe HBM, mémoire serveur conventionnelle, mémoire computationnelle, SSD et High Bandwidth Flash. HBF vise à offrir une capacité bien supérieure à celle de la HBM tout en fournissant davantage de bande passante que le stockage conventionnel.

L’entreprise a présenté HBF comme un niveau destiné aux environnements d’inférence au service de nombreux utilisateurs. Les comparaisons présentées lors de son sommet reposaient sur des simulations internes ; le matériel commercial doit donc encore démontrer ses performances réelles. La disponibilité, l’endurance, l’intégration logicielle et le comportement énergétique détermineront sa place dans la hiérarchie.

Pour les développeurs, cette architecture importe, car les contextes plus longs et les agents persistants ne sont pas de simples fonctionnalités logicielles gratuites. Chaque décision produit crée un état physique qui doit résider quelque part. Les politiques de cache, les schémas de récupération et le routage des modèles influent de plus en plus sur le coût de l’infrastructure et le temps de réponse.

Pour les acheteurs en entreprise, les demandes matérielles devraient gagner en précision. Demandez aux fournisseurs comment ils mesurent la mémoire inutilisée, gèrent la capacité partagée, isolent les locataires et se remettent de défaillances du fabric. Exigez des résultats utilisant des modèles et des longueurs de contexte proches des déploiements prévus.

Demandez également si le système expose une télémétrie utile. Les équipes doivent pouvoir observer les taux d’accès au cache, les migrations entre niveaux, la congestion CXL, les lectures de stockage et la latence de queue. Une ressource mutualisée impossible à diagnostiquer devient un passif opérationnel.

Le rack d’IA centré sur la mémoire de SK hynix ne renverse pas du jour au lendemain le serveur dominé par les GPU. Il démontre toutefois de manière convaincante que l’infrastructure d’inférence ne peut pas traiter la mémoire comme un simple composant passif. La question plus difficile est de savoir si les fournisseurs peuvent transformer cette idée en systèmes reproductibles et faciles à prendre en charge.

Au cours des prochains mois, surveillez l’annonce d’un déploiement en production identifié, d’interfaces logicielles communes et d’une intégration directe dans des plateformes de racks commerciales. Ces trois évolutions feraient passer MARS d’une vision présentée lors d’un sommet à un modèle d’infrastructure.

Si elles ne se concrétisent pas, la conception centrée sur la mémoire pourrait rester une technique utile pour certaines charges de travail plutôt qu’une nouvelle norme. Dans les deux cas, les acheteurs en tireront une leçon importante : les performances futures de l’IA dépendent de l’emplacement des données, et pas seulement de celui où les calculs sont exécutés.