CXL 4.0 en 2026 : comment le memory pooling et les 128 GT/s transforment les serveurs IA et cloud
La mémoire est devenue l’une des principales contraintes des infrastructures modernes dédiées à l’intelligence artificielle et au cloud. Les processeurs et les accélérateurs continuent de gagner en performances, mais leur fournir une quantité suffisante de mémoire de manière efficace et économiquement viable devient de plus en plus difficile. Compute Express Link, plus connu sous le nom de CXL, répond à ce problème en proposant une connexion cohérente entre les processeurs, les accélérateurs et la mémoire externe. CXL 4.0, publié par le CXL Consortium en novembre 2025, porte le débit maximal de 64 GT/s à 128 GT/s tout en conservant les fonctions de mise en commun et de partage de mémoire développées dans les générations précédentes de CXL. En 2026, cette combinaison est particulièrement pertinente pour l’inférence IA, les grands serveurs cloud et l’informatique à l’échelle du rack. Elle ne rend ni la mémoire DDR classique ni la mémoire à large bande passante obsolètes, et ne transforme pas instantanément chaque rack en un immense système de mémoire unique. Elle offre toutefois une solution concrète pour considérer la mémoire comme une ressource plus flexible, plutôt que comme une capacité fixe attribuée en permanence à un seul processeur.
Pourquoi CXL 4.0 est important pour les serveurs IA et cloud en 2026
CXL a été conçu parce que la relation traditionnelle entre les processeurs et la mémoire devenait trop restrictive pour les charges de travail des centres de données. Un serveur classique dispose d’une quantité fixe de mémoire locale accessible par les canaux mémoire du processeur. Cette organisation fonctionne correctement lorsque les charges de travail sont prévisibles, mais les systèmes cloud et IA le sont rarement sur de longues périodes. Une machine peut temporairement avoir besoin de plusieurs téraoctets de mémoire alors qu’un autre serveur situé dans le même rack dispose d’une grande quantité de DRAM inutilisée. Installer suffisamment de mémoire locale dans chaque serveur pour couvrir son pic de demande potentiel laisse donc une capacité coûteuse inutilisée pendant une grande partie du temps. CXL modifie cette relation en permettant à des dispositifs mémoire compatibles d’être installés en dehors de l’organisation DIMM habituelle du processeur tout en restant accessibles à l’aide d’opérations de lecture et d’écriture de type mémoire. Les versions précédentes de CXL ont établi les bases de l’extension, de la commutation, de la mutualisation et du partage. CXL 4.0 se concentre notamment sur l’augmentation du volume de données pouvant circuler à travers ces connexions.
La principale évolution est le passage à 128 GT/s, soit deux fois le débit maximal de 64 GT/s proposé par CXL 3.x. CXL 4.0 y parvient en s’appuyant sur la signalisation physique définie pour PCI Express 7.0, dont la spécification finale 1.0 a été publiée en juin 2025. GT/s signifie gigatransferts par seconde et ne doit pas être confondu avec les gigaoctets par seconde. Cette valeur décrit la fréquence de transfert du signal sur chaque ligne, tandis que la bande passante réellement disponible dépend notamment du nombre de lignes, des surcharges liées au protocole et de la configuration du dispositif. PCI Express 7.0 peut, par exemple, fournir jusqu’à 512 Go/s de bande passante bidirectionnelle avec une connexion à seize lignes. CXL repose sur la même base physique à haut débit, mais y ajoute les mécanismes de cohérence et de gestion mémoire nécessaires pour faire fonctionner ensemble processeurs, accélérateurs et dispositifs mémoire. Le résultat est une capacité de liaison nettement supérieure, sans obliger les logiciels à traiter la mémoire connectée comme un stockage classique ou une ressource réseau conventionnelle.
Cette augmentation du débit est importante, car l’extension de mémoire n’est réellement utile que si le chemin permettant d’y accéder est suffisamment rapide pour la charge de travail concernée. La DRAM locale reste l’emplacement privilégié pour les données sensibles à la latence, tandis que la HBM demeure essentielle lorsque les GPU et autres accélérateurs ont besoin d’une bande passante extrêmement élevée à proximité immédiate de leurs unités de calcul. La mémoire CXL occupe une position différente dans cette hiérarchie. Elle peut offrir une capacité considérablement supérieure à celle qu’il serait économiquement raisonnable d’installer directement à côté de chaque processeur ou accélérateur, tout en assurant de meilleures caractéristiques d’accès que le transfert des mêmes informations vers un stockage SSD. Pour les infrastructures IA, cela crée un niveau de mémoire supplémentaire entre la mémoire locale rapide mais limitée et le stockage nettement plus lent. Pour les opérateurs cloud, cela permet également d’adapter plus précisément la capacité mémoire aux variations des charges de travail, plutôt que d’équiper chaque serveur en fonction de son scénario de pointe théorique. La valeur de CXL 4.0 repose donc autant sur la flexibilité que sur son débit brut.
Ce que change réellement le passage à 128 GT/s
Le doublement d’une liaison de 64 GT/s à 128 GT/s ne signifie pas qu’une application fonctionne automatiquement deux fois plus vite. De nombreuses applications sont limitées par les performances du processeur, la puissance des accélérateurs, le comportement des logiciels ou la latence mémoire plutôt que par la liaison CXL elle-même. La bande passante supplémentaire devient importante lorsque de grandes quantités de données doivent circuler simultanément entre les processeurs, les accélérateurs et la mémoire étendue. Un serveur exécutant de l’inférence sur de grands modèles, de l’analyse de données ou une base de données en mémoire peut disposer de nombreux processus lisant et écrivant des données en parallèle. Dans de telles situations, une interconnexion plus lente peut devenir un goulot d’étranglement partagé même lorsqu’une capacité mémoire importante est disponible derrière elle. CXL 4.0 offre davantage de marge pour gérer ce trafic. Le CXL Consortium a également conservé la structure de transfert à taille fixe et les protections contre les erreurs mises au point pour la génération à 64 GT/s, ce qui permet d’augmenter le débit sans accepter simplement une hausse proportionnelle de la latence du protocole.
CXL 4.0 introduit également les ports groupés. En termes simples, plusieurs connexions CXL physiques peuvent être considérées comme une seule connexion logique lorsque la conception de l’appareil et de l’hôte le permet. Cette possibilité est utile lorsqu’une seule liaison ne fournit pas suffisamment de bande passante pour un accélérateur hautes performances ou un autre composant exigeant. Plutôt que d’obliger le reste du système à considérer chaque connexion comme un chemin entièrement séparé, les ports groupés fournissent une méthode définie permettant de les agréger. La spécification prend également en charge les liaisons x2 natives, qui peuvent aider les concepteurs à connecter un plus grand nombre de dispositifs lorsque la bande passante maximale n’est pas nécessaire sur chaque connexion. Elle permet aussi l’utilisation de jusqu’à quatre retimers afin d’augmenter la portée du canal. Ces évolutions sont importantes pour les serveurs denses et les configurations à l’échelle du rack, où les composants ne peuvent pas toujours être installés juste à côté du processeur. Elles donnent davantage de possibilités pour équilibrer largeur de liaison, nombre de dispositifs, distance et bande passante.
La fiabilité devient tout aussi importante lorsque la mémoire n’est plus limitée à la carte mère. Une panne d’un module DIMM conventionnel affecte généralement un seul serveur, tandis qu’une mémoire mutualisée ou partagée peut prendre en charge plusieurs machines ou des charges de travail importantes. CXL 4.0 comprend donc des fonctions supplémentaires de fiabilité, de disponibilité et de maintenance de la mémoire destinées à améliorer la visibilité des erreurs et les opérations de maintenance. Ces mécanismes n’éliminent pas les pannes et les opérateurs doivent toujours prévoir de la redondance, de la surveillance et une répartition raisonnable des charges de travail. Ils facilitent toutefois la gestion de grandes capacités de mémoire CXL comme un élément d’infrastructure plutôt que comme un périphérique inhabituel. La rétrocompatibilité complète constitue un autre aspect pratique important. Les systèmes CXL 4.0 sont conçus pour fonctionner avec les générations CXL précédentes lorsque cela est pris en charge. Les entreprises ne sont donc pas obligées de remplacer l’intégralité de leur environnement CXL en une seule fois. C’est particulièrement important en 2026, alors que l’industrie déploie encore des équipements CXL 2.0 et 3.x tout en commençant la conception et la validation de matériels CXL 4.0 à 128 GT/s.
Memory pooling : passer d’une mémoire fixe à une capacité partagée
La mise en commun de mémoire est antérieure à CXL 4.0. Cette fonction a été introduite avec CXL 2.0, en même temps que la commutation et un modèle standardisé de Fabric Manager. CXL 3.0 a ensuite étendu ce principe avec des fabrics plus vastes, la commutation à plusieurs niveaux et le partage cohérent de mémoire. Cette distinction est importante. Le memory pooling signifie qu’une quantité de mémoire connectée via CXL peut être attribuée à différents hôtes en fonction de l’évolution de leurs besoins. Une partie attribuée à un serveur peut ensuite être libérée et affectée ailleurs. Le partage de mémoire va plus loin en permettant à des régions mémoire compatibles d’être accessibles à plusieurs hôtes tout en utilisant des mécanismes de cohérence afin de maintenir une vision cohérente des données. CXL 4.0 conserve ces possibilités tout en offrant une bande passante nettement supérieure au fabric. Le résultat n’est donc pas une nouvelle forme de mutualisation inventée en 2026, mais une interconnexion plus rapide qui rend les modèles existants de pooling et de partage plus intéressants pour les grands systèmes et les charges de travail exigeantes.
Un exemple simple permet de comprendre l’intérêt de cette approche. Imaginons plusieurs serveurs cloud, chacun disposant de suffisamment de DRAM locale pour son fonctionnement habituel, reliés à une banque supplémentaire de mémoire CXL. L’un de ces serveurs peut soudainement avoir besoin de plusieurs centaines de gigaoctets supplémentaires pour effectuer des analyses, faire fonctionner un service d’inférence IA ou gérer une grande base de données. Au lieu d’exiger que cette capacité soit installée en permanence à l’intérieur de cette machine particulière, une partie du pool CXL peut lui être attribuée. Lorsque la demande diminue, cette capacité peut être libérée puis utilisée ailleurs. Un Fabric Manager coordonne les ressources concernées, tandis que le système d’exploitation et les logiciels d’orchestration déterminent comment exploiter la mémoire supplémentaire. La mise en œuvre exacte varie selon les fabricants, et la latence reste supérieure à celle de la DRAM locale, mais le principe économique est simple : une mémoire qui resterait autrement inutilisée derrière un processeur peut devenir une capacité accessible à d’autres charges de travail.
Cette approche vise notamment le problème de la mémoire immobilisée. Les serveurs cloud sont souvent configurés pour répondre aux besoins de pointe plutôt qu’aux besoins moyens, car un manque de mémoire peut fortement dégrader les performances d’une charge de travail ou empêcher son exécution. Un serveur peut ainsi disposer de DRAM libre au même moment où un système voisin manque de capacité. La mutualisation réduit la nécessité de fournir à chaque machine la même importante marge de sécurité. Elle peut également rendre les mises à niveau moins perturbatrices, puisque de la mémoire supplémentaire peut être ajoutée à un sous-système CXL partagé plutôt qu’en utilisant uniquement les canaux mémoire locaux du processeur. La pertinence économique dépend cependant du comportement des charges de travail, du coût des commutateurs, de la consommation électrique, de la prise en charge logicielle et de l’écart de performances entre la mémoire locale et la mémoire accessible via CXL. CXL doit donc être considéré comme un niveau supplémentaire dans la hiérarchie mémoire et non comme la preuve que la DRAM locale n’est plus nécessaire. Les configurations les plus efficaces utilisent généralement plusieurs types de mémoire pour répondre à des besoins différents.
Pourquoi l’inférence IA bénéficie de la mémoire mutualisée et hiérarchisée
L’inférence IA constitue en 2026 l’une des raisons les plus évidentes de l’intérêt porté à la mémoire CXL. Faire fonctionner de grands modèles de langage ne consiste pas uniquement à conserver les poids du modèle. Chaque requête active peut également nécessiter un état temporaire, notamment le cache clé-valeur utilisé par les modèles Transformer afin d’éviter de recalculer les informations d’attention précédentes. Avec l’allongement des fenêtres de contexte et l’augmentation du nombre d’utilisateurs ou d’agents IA servis simultanément, ce cache peut occuper une quantité considérable de mémoire. Conserver chaque octet dans la coûteuse mémoire HBM de l’accélérateur peut limiter le nombre de sessions gérées par un serveur, même lorsque le GPU dispose encore de puissance de calcul inutilisée. Déplacer toutes les données excédentaires vers des SSD peut, à l’inverse, provoquer des délais d’accès beaucoup plus importants. La mémoire CXL constitue un niveau intermédiaire dans lequel certaines informations peuvent rester directement adressables comme de la mémoire sans occuper la capacité locale la plus précieuse de l’accélérateur.
Cela ne signifie pas qu’un opérateur IA devrait simplement déplacer un modèle entier de la HBM vers la mémoire CXL. Les données les plus fréquemment utilisées ont toujours intérêt à rester aussi proches que possible de l’accélérateur, et la bande passante fournie par la HBM reste nettement supérieure à celle d’un niveau de mémoire CXL externe. Une conception plus réaliste conserve les données du modèle les plus sensibles à la latence dans la HBM, maintient les données de travail appropriées dans la DRAM locale du système et utilise la capacité CXL pour les informations qui doivent rester rapidement accessibles sans nécessiter en permanence la bande passante locale maximale. La hiérarchisation et le déchargement du cache KV figurent parmi les exemples les plus souvent évoqués par l’industrie CXL en 2026. Lorsqu’un logiciel peut déterminer quelles données doivent se trouver dans chaque niveau, le serveur peut prendre en charge des contextes plus longs ou davantage de requêtes d’inférence simultanées sans devoir ajouter une quantité équivalente de mémoire d’accélérateur coûteuse. L’avantage concerne donc principalement l’efficacité de la capacité et non une supposée supériorité de CXL sur la HBM en matière de vitesse.
Le même principe s’applique au-delà des grands modèles de langage. Les systèmes de recommandation peuvent conserver de très grandes tables d’embeddings, les traitements de données peuvent exploiter des ensembles dépassant la capacité de la DRAM locale, et l’inférence reposant sur le CPU peut nécessiter davantage de mémoire que ce qu’une configuration de serveur conventionnelle peut fournir de manière économique. CXL peut augmenter l’espace mémoire utilisable pour ces charges de travail tout en conservant les mécanismes d’accès mémoire standards. La mutualisation ajoute un niveau supplémentaire de flexibilité puisque la capacité peut suivre la demande au lieu d’être définitivement attribuée à une seule machine. Cette approche est particulièrement intéressante dans les infrastructures IA partagées où différents services atteignent leur pic d’activité à des moments différents. Un traitement par lots peut nécessiter une capacité mémoire importante pendant la nuit, tandis qu’un service d’inférence peut utiliser cette même capacité pendant les heures de bureau. L’allocation dynamique ne supprime pas toutes les contraintes opérationnelles et le déplacement des ressources entre les hôtes nécessite toujours une gestion par le système d’exploitation et les logiciels d’infrastructure, mais elle offre davantage de possibilités qu’une architecture de serveur à mémoire fixe.
Comment CXL 4.0 modifie la conception des serveurs et l’économie du cloud
L’évolution à long terme apportée par CXL est davantage architecturale que simplement numérique. Les serveurs traditionnels sont conçus autour de ressources appartenant à une seule machine : leurs processeurs, modules DIMM et accélérateurs sont installés pour ce serveur et y restent même lorsqu’ils sont peu utilisés. CXL permet de gérer certaines de ces ressources, en particulier la mémoire, de manière plus indépendante. Un rack peut contenir des serveurs conventionnels ainsi que des commutateurs CXL, des dispositifs d’extension mémoire et des systèmes de mémoire mutualisée, avec une capacité attribuée selon les besoins des charges de travail. CXL 3.x fournit déjà une grande partie du comportement de fabric nécessaire à ce modèle. CXL 4.0 ajoute une bande passante de liaison nettement supérieure ainsi que de nouvelles possibilités de connexion, qui deviennent importantes à mesure que le nombre de dispositifs et le volume de trafic augmentent. Cela ne transforme pas un rack en un ordinateur unique, mais réduit l’importance de l’idée selon laquelle chaque octet de mémoire utile doit être installé physiquement à côté du processeur qui finira par l’utiliser.
Pour les fournisseurs de services cloud, l’avantage financier le plus évident est la possibilité d’améliorer l’utilisation de la mémoire. La DRAM représente une part importante du coût et de la consommation énergétique des serveurs disposant de grandes capacités mémoire. Si chaque serveur est équipé pour absorber des pointes de demande rares, une grande partie de cet investissement peut rester sous-utilisée pendant le fonctionnement normal. Un pool mémoire partagé peut permettre aux opérateurs d’acheter de la capacité en fonction de la demande globale plutôt que de fournir à chaque machine suffisamment de mémoire pour couvrir son maximum théorique individuel. Les économies ne sont cependant pas automatiques. Les commutateurs CXL, les contrôleurs, les boîtiers mémoire et les logiciels de gestion ont également un coût et consomment de l’énergie, tandis que les charges de travail exigeant constamment une faible latence mémoire peuvent toujours justifier d’importantes quantités de DRAM locale. Les cas les plus intéressants apparaissent donc lorsque la demande mémoire varie fortement entre les hôtes, lorsque les limites de capacité sont plus importantes que la latence minimale ou lorsqu’une mémoire supplémentaire permet de maintenir des processeurs et des accélérateurs coûteux en activité au lieu de les laisser attendre des données provenant du stockage.
La flexibilité opérationnelle pourrait s’avérer tout aussi importante que le coût du matériel. Un service cloud peut évoluer considérablement au cours de la durée de vie d’un serveur. Les modèles IA deviennent plus volumineux, les bases de données s’agrandissent et les clients passent d’un type d’instance à un autre. Avec une machine disposant d’une quantité de mémoire fixe, une hausse des besoins peut nécessiter le déplacement de la charge de travail ou le remplacement du matériel. L’extension et la mutualisation via CXL permettent d’envisager une modification de la quantité de mémoire disponible sans reconstruire le nœud de calcul. Elles peuvent également favoriser des configurations de serveurs plus spécialisées : certaines machines peuvent disposer d’une grande capacité mémoire locale, tandis que d’autres peuvent dépendre davantage d’une capacité partagée pour les charges de travail tolérant une latence supplémentaire. La fiabilité et la sécurité restent essentielles dans ce modèle. La mémoire doit pouvoir être réattribuée en toute sécurité, les pannes doivent être isolées et les informations appartenant à une charge de travail ne doivent pas devenir accessibles à une autre. À mesure que CXL évolue vers des usages multi-hôtes et à l’échelle du rack, ces exigences de gestion deviennent des éléments fondamentaux de la conception.
À quoi s’attendre pour les déploiements CXL après 2026
La réalité la plus importante en 2026 est que la publication de la spécification CXL 4.0 ne signifie pas que le matériel CXL à 128 GT/s soit déjà généralisé dans les centres de données de production. Les systèmes commerciaux et les démonstrations actuels couvrent plusieurs générations. Le module mémoire CXL MD220 de Samsung, par exemple, utilise CXL 2.0 sur PCIe 5.0 et existe avec des capacités de 128 Go et 256 Go, tandis que le système de mutualisation mémoire CMM-B de Samsung destiné aux racks repose également sur des technologies CXL 1.1 et 2.0. SK hynix présentait encore en 2026 des solutions CMM-DDR5 appartenant à la génération CXL 2.0, tandis que les événements organisés par le CXL Consortium au cours de l’année comprenaient des démonstrations de liaisons et de contrôleurs CXL 3.2 fonctionnels. Parallèlement, les fournisseurs de technologies de conception de semi-conducteurs proposent déjà des contrôleurs, des mécanismes de sécurité et des solutions de vérification CXL 4.0 destinés aux puces prévues pour fonctionner à 128 GT/s. Autrement dit, la transition est en cours, mais les produits matures actuels coexistent avec les futures conceptions CXL 4.0.
Cette adoption progressive est normale pour une interconnexion destinée aux serveurs. Après la publication d’une spécification doivent venir les contrôleurs, les commutateurs, les retimers, les processeurs, les dispositifs mémoire, les firmwares, la prise en charge par les systèmes d’exploitation, les tests de conformité et la validation de l’interopérabilité entre plusieurs fabricants avant que les grands opérateurs puissent la déployer en toute confiance. CXL 4.0 bénéficie du fait qu’il prolonge l’architecture des versions précédentes et reste rétrocompatible, permettant ainsi aux fabricants de s’appuyer sur leur expérience existante en matière de logiciels et de conception. La première raison de l’adopter ne sera pas nécessairement le besoin d’atteindre précisément 128 GT/s. Les opérateurs chercheront davantage à savoir si cette bande passante supplémentaire permet de connecter plus de mémoire, de gérer davantage de trafic simultané ou d’augmenter l’activité des accélérateurs sans créer de goulot d’étranglement. À mesure que les fabrics CXL évoluent d’une simple extension mémoire vers des ressources mutualisées et partagées à l’échelle du rack, cette bande passante supplémentaire devient de plus en plus utile, car un nombre croissant de charges de travail doivent utiliser la même capacité d’interconnexion.
Pour les infrastructures IA et cloud, CXL 4.0 doit donc être considéré comme une étape d’une évolution plus large de l’architecture mémoire plutôt que comme une simple hausse de vitesse d’une génération à l’autre. La mémoire DDR locale continuera à fournir une mémoire CPU relativement rapide, la HBM continuera à alimenter les accélérateurs exigeant une bande passante extrême et les SSD resteront une solution économique pour le stockage persistant. CXL ajoute une couche flexible entre ces différentes ressources, permettant aux serveurs d’accéder à de plus grands pools de mémoire cohérente et d’attribuer la capacité avec moins de contraintes physiques. La génération à 128 GT/s offre à cette couche davantage de possibilités de montée en charge. À court terme, de nombreux systèmes de production continueront d’utiliser CXL 2.0 ou 3.x tandis que les nouvelles générations de silicium évolueront progressivement vers CXL 4.0. Au cours des prochaines générations de serveurs, le changement le plus significatif sera probablement le passage d’une question centrée sur la quantité de mémoire installée dans un serveur à une question plus large : quelle quantité de mémoire adaptée peut être mise à la disposition d’une charge de travail au moment précis où elle en a besoin ?
