La puissance de calcul des GPU progresse, mais les applications d’intelligence artificielle se heurtent souvent à une autre limite. Il faut avoir assez de mémoire au bon endroit et au bon moment.
Avec Compute Express Link (CXL), constructeurs et opérateurs de datacenters cherchent à étendre, répartir et parfois partager la RAM entre plusieurs hôtes. La spécification CXL 4.0, publiée en novembre 2025, renforce cette ambition. En 2026, des contrôleurs, commutateurs et prototypes rendent la technologie plus concrète. La question est de savoir si une mémoire mutualisée peut accélérer les modèles d’IA sans créer un nouveau goulet d’étranglement ? Pour répondre, il faut séparer les promesses d’architecture des déploiements réellement documentés.
Les trois points clés
- CXL ajoute une couche mémoire accessible via une interconnexion cohérente ; extension, pooling et partage désignent trois architectures différentes.
- CXL 4.0 spécifie 128 GT/s, mais cette vitesse de lien ne garantit ni le débit utile d’une application ni un GPU plus rapide.
- L’inférence IA et le cache KV sont des usages prometteurs ; coût, latence, logiciels et isolation déterminent les gains réels.
Pourquoi les GPU puissants se retrouvent à court de mémoire ?
Un accélérateur peut effectuer des milliards d’opérations et pourtant attendre les données nécessaires à son prochain calcul. Ce paradoxe se voit dans les grands modèles de langage. Il faut conserver les poids du modèle, mais aussi les informations associées aux requêtes en cours. Les longues conversations et les traitements simultanés font grossir cette empreinte. Ajouter seulement des unités de calcul n’efface donc pas le problème.
La mémoire HBM embarquée près des accélérateurs offre une bande passante exceptionnelle, mais sa capacité est limitée et son coût élevé. La DRAM des serveurs contient davantage de données à un autre niveau de la hiérarchie. Entre les deux, les transferts ont un prix dont la latence, la bande passante et la consommation énergétique. Les opérateurs doivent arbitrer entre des GPU surdimensionnés, des déplacements de données et la recomputation.
Le problème est aussi organisationnel. Dans une flotte, un serveur peut manquer de mémoire pendant qu’un autre conserve des giga octets inutilisés. Sans architecture adaptée, déplacer une charge ou récupérer cette réserve suppose une orchestration complexe. CXL dissocie en partie l’endroit où se trouve la capacité mémoire de l’endroit où le processeur la consomme.
CXL, c’est quoi exactement ?
Compute Express Link est une interconnexion ouverte destinée aux processeurs, accélérateurs et périphériques mémoire. Elle s’appuie sur l’infrastructure physique PCI Express, tout en ajoutant des mécanismes spécifiques pour les accès mémoire et la cohérence des caches. Il ne s’agit ni d’un disque distant, ni d’un simple protocole réseau. Les opérations peuvent être exprimées comme des accès mémoire, selon les capacités des équipements concernés.
Le standard distingue CXL.io, pour les fonctions de découverte et d’administration proches de PCIe. D’un autre côté, il y a CXL.cache, qui permet à certains périphériques de mettre en cache des données de l’hôte ; et CXL.mem, utilisé pour accéder à la mémoire d’un périphérique. Les appareils de type 3, généralement des extensions de mémoire, sont essentiels dans de nombreux scénarios. Un accélérateur de type 2 peut intégrer d’autres fonctions, mais cela ne signifie pas que tous les GPU commercialisés disposent du même support CXL.
Le mot « cohérent » mérite une précision. Il décrit des règles qui permettent de conserver une vision consistante de données mises en cache dans des configurations déterminées. Il ne promet pas que deux serveurs quelconque peuvent écrire sur les mêmes octets de manière simultanée sans coordination logicielle. Cohérence matérielle, propriété des zones mémoire, synchronisation et permissions restent des sujets distincts.
Extension, pooling, partage : trois usages à ne pas confondre
L’extension augmente la RAM visible par un serveur
Dans le cas le plus simple, un module CXL apporte de la capacité à un hôte. Le système peut l’exposer comme une mémoire supplémentaire, souvent moins rapide que la DRAM locale pour certaines opérations. Cette approche convient à des charges dont la taille dépasse la mémoire installée, à condition de placer intelligemment les données fréquemment consultées.
Le pooling répartit une réserve entre plusieurs hôtes
Un pool regroupe des modules accessibles par une infrastructure de commutation et de gestion. Un orchestrateur peut attribuer davantage de capacité au serveur A et en retirer au serveur B selon les besoins. Cette allocation peut rester exclusive où plusieurs serveurs utilisent la même infrastructure physique, sans avoir le même contenu mémoire au même instant. La différence est importante pour la sécurité et la comptabilité des ressources.
Le partage expose une région commune dans des conditions précises
Une architecture de partage autorise plusieurs hôtes à accéder à une région commune. Elle réclame des règles de protection et de synchronisation adaptées. Toutes les générations CXL ne proposent pas les mêmes capacités de fabric, de routage ou de cohérence. Une annonce de « memory pooling » ne suffit donc pas à démontrer la présence d’une mémoire véritablement partagée en lecture-écriture.
De CXL 2.0 à CXL 4.0, que permet réellement le standard ?
CXL 2.0 a structuré les usages de commutation et de pooling. CXL 3.0 a étendu l’architecture vers le partage mémoire, les fabrics plus ambitieux et les mécanismes de cohérence nécessaires à certains usages multi-hôtes. Les versions 3.1 et 3.2 ont approfondi différents aspects de gestion, de sécurité et d’interopérabilité. Cette progression décrit des possibilités normatives ; elle ne remplace jamais la liste des fonctions prises en charge par un processeur, un switch et un système d’exploitation précis.
Le 18 novembre 2025, le CXL Consortium a publié CXL 4.0. Sa principale évolution de débit est le passage de 64 à 128 GT/s, avec un appui sur les caractéristiques de PCIe 7.0. Le standard introduit également l’agrégation logique de ports, une largeur native x2 et des améliorations de fiabilité, disponibilité et maintenance. Le consortium annonce une rétrocompatibilité avec les générations précédentes.
Toutefois, il faut faire attention à la lecture du chiffre. 128 GT/s désigne un taux de transfert sur le lien, et non 128 Go/s de données utiles par application. Le débit dépend de la largeur de liaison, des protocoles, des équipements, de la topologie et du trafic. De même, la publication d’une spécification ne prouve pas la disponibilité immédiate de cartes mères ou de fabrics complets pour toutes les fonctions CXL 4.0.
Le cache KV, candidat sérieux à la mémoire CXL dans l’IA
Pendant la génération d’une réponse, les modèles de type Transformer conservent des représentations intermédiaires appelées « clés » et « valeurs ». Ce cache KV évite de recalculer systématiquement l’ensemble des informations précédentes. Sa taille augmente avec la longueur des séquences, le nombre de requêtes et l’architecture du modèle. En service multi-utilisateur, il finit par concurrencer les poids du modèle pour la précieuse HBM.
Une stratégie consiste à garder les données brûlantes dans la mémoire du GPU et à déplacer les éléments moins utilisés vers une autre couche. La DRAM locale, un SSD ou une mémoire reliée via CXL n’offrent pas les mêmes compromis. CXL peut apporter davantage de capacité avec un accès de type mémoire. Cependant, le cache déplacé devra parfois revenir vers l’accélérateur. Ce mouvement peut gommer les gains attendus si le modèle réclame constamment les données externalisées.
Une étude parue dans IEEE Computer Architecture Letters le 6 août 2026 a comparé plusieurs architectures d’extension et de pooling CXL pour le déchargement du cache KV, en utilisant vLLM et LMCache. Ses auteurs décrivent des avantages de performance et d’évolutivité dans leurs configurations testées. C’est une preuve d’intérêt technique, pas une garantie universelle : taille des contextes, matériel, orchestration et stratégie de préchargement changent fortement les résultats.
Un autre travail présenté à HiPCW 2025 et indexé par IEEE en avril 2026 recourt à un modèle analytique pour étudier les longues séquences. Il suggère qu’un pool CXL peut soutenir un meilleur débit lorsque le cache dépasse l’espace HBM disponible. Un résultat de modélisation ne doit pas être présenté comme une mesure reproductible sur tous les datacenters.
Quels équipements existent en 2026 ?
Samsung présente son CMM-B comme une appliance de pooling intégrant un gestionnaire de fabric, dans un châssis rackable 4U compatible avec des modules mémoire CXL. C’est une illustration d’un système complet, au-delà de la simple barrette. Il reste nécessaire de vérifier, pour chaque intégration, la disponibilité commerciale, les hôtes compatibles et les fonctions activées. Un schéma de produit ne suffit pas pour inférer un déploiement à grande échelle.
Astera Labs a annoncé le 15 septembre 2026 l’extension de sa famille de contrôleurs Leo. Les références Leo 2 E et P visent l’extension et le pooling sur des architectures compatibles CXL 3.2. Le Leo X-Series cible pour sa part une mémoire attachée au fabric destinée, entre autres, au cache KV, mais s’appuie sur des interfaces PCIe ou spécifiques aux plateformes. Il serait trompeur de ranger indistinctement toute cette gamme sous une unique fonction CXL GPU.
Dans son communiqué, Astera avance jusqu’à 62 % d’amélioration du temps avant le premier token et jusqu’à 22 % de tokens supplémentaires par seconde pour certains scénarios. Ce sont des résultats revendiqués par le fournisseur, dépendants des conditions citées, et non des moyennes sectorielles. De son côté, Marvell a annoncé en mars 2026 un commutateur Structera S destiné au pooling à l’échelle du rack. L’écosystème avance, mais la maturité des déploiements varie selon la chaîne matérielle et logicielle.
La latence et le logiciel peuvent annuler les économies espérées
Déporter une portion de mémoire ajoute des traversées de liaison et parfois de commutateur. La HBM reste privilégiée pour les accès très intensifs. L’extension CXL est surtout intéressante lorsque le gain de capacité ou de mutualisation compense le surcoût d’accès. Les performances doivent être mesurées au niveau de l’application, pas uniquement avec un microbenchmark du lien. Un modèle sensible à la latence peut ralentir malgré une réserve de mémoire abondante.
La hiérarchisation des données devient une décision logicielle. Quelles pages laissées en DRAM locale ? Lesquelles migrent vers CXL ? Faut-il réserver le pool au cache KV, aux poids d’experts de modèles MoE ou à des charges analytiques ? De mauvais placements peuvent saturer le fabricant. Les stratégies de préchargement, de migration et de limitation de débit sont aussi importantes que la fiche technique des contrôleurs.
Linux fournit déjà des mécanismes pour exposer des régions CXL comme périphériques DAX ou, après conversion, comme mémoire système gérée par l’allocateur de pages. Cela ne veut pas dire qu’un pooling multi-hôte dynamique s’administre partout sans intervention. La documentation du noyau souligne des différences selon les types de périphériques, l’initialisation du firmware et les fonctions de gestion effectivement supportées. Un projet industriel doit vérifier chaque version du système et chaque combinaison de matériels.
- Partager l'article :
