CXL réécrit l’architecture mémoire des serveurs — et les workloads IA en sont la raison
Pendant la majeure partie de l’histoire de l’informatique, la mémoire a été physiquement attachée au processeur qui l’utilise. Les CPUs ont leurs DIMMs, les GPUs ont leurs stacks HBM, et les deux pools ne communiquent pas efficacement. Cette architecture fonctionnait bien lorsque les workloads tenaient confortablement dans le budget mémoire d’un seul serveur. L’IA a changé cela. L’inférence de grands modèles de langage nécessite des téraoctets de mémoire rien que pour la KV cache, et la DRAM attachée d’un seul serveur est loin d’être suffisante. Compute Express Link (CXL) est la réponse de l’industrie à ce décalage — et son adoption s’accélère assez vite pour être importante pour quiconque construit ou achète une infrastructure de centre de données dans les deux prochaines années.
CXL n’est pas un produit. C’est un protocole — spécifiquement, un standard d’interconnexion ouvert construit sur la couche physique PCIe 5.0 qui permet aux processeurs d’accéder à la mémoire sur des périphériques externes avec la même faible latence et la même cohérence de cache qu’ils attendent d’une DRAM directement attachée. L’implication pratique est grande : la mémoire peut être installée dans un module mémoire CXL de l’autre côté d’un slot PCIe, ou mutualisée sur un rack entier via un switch CXL, et le CPU la traite comme s’il s’agissait de mémoire locale.
Trois sous‑protocoles, un seul cas d’usage moteur de l’adoption
CXL définit trois sous‑protocoles qui remplissent différentes fonctions. CXL.io gère les E/S de base du périphérique — à peu près équivalent à PCIe. CXL.cache permet à un périphérique de mettre en cache des parties de la mémoire hôte, permettant à des accélérateurs comme les GPUs d’accéder efficacement aux données côté CPU sans copies explicites. CXL.mem est celui qui reçoit le plus d’investissements : il permet à un CPU hôte de lire et d’écrire dans la mémoire installée sur un périphérique CXL externe, étendant la capacité mémoire effective disponible pour tout processeur bien au‑delà de ce que les slots DIMM de la carte mère autorisent.
CXL 1.0 est apparu en 2019. CXL 2.0 (2020) a ajouté le memory pooling — la capacité pour plusieurs processeurs hôtes de partager un pool mémoire CXL commun — et la commutation, de sorte qu’un seul pool puisse être accédé par plusieurs serveurs. CXL 3.0 (2022) a étendu cela aux topologies de fabric : accès multi‑hôte où n’importe quel nœud de calcul dans un rack peut atteindre n’importe quel module mémoire, avec une cohérence peer‑to‑peer. Le plafond de bande passante a atteint 256 Go/s par port dans CXL 3.0, approchant ce que HBM fournit pour la mémoire attachée aux GPUs.
Pourquoi l’inférence IA est la fonction de forçage
L’inférence LLM a un problème mémoire spécifique que CXL est bien positionné pour résoudre. Lorsqu’un modèle génère du texte, il maintient une KV cache qui stocke l’état d’attention pour chaque token dans la fenêtre de contexte. Pour un modèle avec une fenêtre de contexte de 128K tokens fonctionnant sur un serveur d’inférence multi‑locataire, la seule KV cache peut consommer des centaines de gigaoctets — dynamiquement, en fonction des sessions actives.
Gérer cela avec la HBM du GPU est coûteux et limité en capacité. Les modules HBM4 plafonnent à environ 48 Go par stack ; même un serveur à 8 GPUs plafonne à environ 384 Go de mémoire GPU. L’extension mémoire CXL offre un débordement rentable : les données de KV cache qui n’ont pas besoin de la bande passante brute de HBM peuvent résider dans de la DRAM attachée en CXL pour environ 10 à 20 % du coût par gigaoctet, avec une latence d’environ 100 à 200 nanosecondes contre 20 à 30 ns pour HBM. La pénalité de latence est réelle mais acceptable pour les données rarement accédées pendant l’inférence.
L’inférence à mémoire désagrégée (memory‑disaggregated inference) — où un pool de mémoire CXL est partagé entre plusieurs serveurs GPU — va plus loin. Au lieu que chaque serveur GPU maintienne son propre buffer DRAM surdimensionné, un fabric CXL permet à 10 serveurs d’inférence de partager un seul pool mémoire de 4 To qui est alloué dynamiquement en fonction de la charge. L’utilisation s’améliore, la capacité immobilisée diminue et le coût par inférence baisse.
Qui construit le matériel
Le module mémoire CXL DRAM (CMM‑D) de Samsung offre jusqu’à 128 Go par module à 256 Go/s de bande passante et est déjà en qualification chez les hyperscalers. SK Hynix a sa propre gamme de DRAM CXL, avec un module de 128 Go ciblant les serveurs d’inférence IA. Micron est entré en production de DRAM CXL en 2024. Les trois grands fabricants de DRAM expédient ou qualifient désormais des produits CXL — l’offre se mature.
Côté connectivité, Astera Labs est entré en bourse en 2024 spécifiquement grâce à la force de ses puces de connectivité CXL et PCIe. Ses retimers Aries se trouvent dans la plupart des serveurs compatibles CXL expédiés aujourd’hui, et ses circuits intégrés de connectivité mémoire CXL Leo permettent des fabrics de pooling mémoire à l’échelle du rack. Marvell et Synopsys fournissent également de l’IP de contrôleur CXL pour les processeurs serveurs.
Les processeurs Intel Xeon Scalable supportent CXL depuis la génération Sapphire Rapids. Les processeurs AMD EPYC ont ajouté le support CXL dans la génération Genoa. Les processeurs serveurs basés sur Arm d’Ampere et le CPU Grace de Nvidia incluent le support CXL. L’écosystème est suffisamment large pour que CXL ne soit plus une option exotique — c’est une case à cocher standard sur les SKUs de serveurs d’entreprise.
Ce qui est disponible aujourd’hui vs ce qui arrive
L’extension mémoire CXL de type 3 (extension mono‑hôte de la mémoire d’un serveur au‑delà des limites des slots DIMM) est le cas d’usage le plus mature et est disponible en production aujourd’hui. Un serveur avec 12 slots DIMM plafonnant à 3 To de DDR5 peut ajouter 4 To supplémentaires via une carte d’extension mémoire CXL — utile pour les bases de données en mémoire, les gros workloads analytiques et les KV caches de LLM.
Le memory pooling CXL (plusieurs hôtes partageant une ressource mémoire CXL commune) est en essais clients chez les hyperscalers à partir de 2025‑2026 mais n’est pas encore en production large. La stack logicielle — support du système d’exploitation pour les niveaux de mémoire CXL, intégration hyperviseur, politiques de gestion mémoire — est encore en maturation. Le support du noyau Linux pour CXL s’améliore rapidement (la série Linux 6.x a un support CXL progressivement plus fort), mais les outils d’orchestration sont en retard.
Le fabric CXL complet (désagrégation mémoire à l’échelle du rack avec accès cohérent multi‑hôte) reste largement au stade de preuve de concept chez les hyperscalers. Google, Microsoft et AWS testent tous en interne des architectures fabric CXL, mais les déploiements clients sont à 18‑24 mois.
Ce que cela signifie pour les acheteurs d’infrastructure
Pour les organisations qui achètent des serveurs aujourd’hui, l’extension mémoire CXL de type 3 vaut la peine d’être évaluée pour des workloads spécifiques : les bases de données en mémoire comme SAP HANA ou Redis qui nécessitent de grandes empreintes mémoire, les workloads analytiques qui ne tiennent pas dans la DRAM standard, et l’infrastructure de serving LLM où la gestion de la KV cache est un goulot d’étranglement.
L’économie n’a de sens que lorsque le coût de la DRAM attachée en CXL (environ 10 à 20 dollars par Go dans les modules actuels, contre 3 à 5 dollars par Go pour des DIMMs DDR5 standard) est mis en balance avec l’alternative, qui est d’acheter plus de serveurs avec plus de slots DIMM. Pour les workloads gourmands en mémoire, les économies de consolidation remboursent généralement la prime CXL en 12 à 18 mois.
Pour les acheteurs cloud, la question la plus pertinente est de savoir quand les hyperscalers exposeront les niveaux de mémoire adossés au CXL comme des options de tarification distinctes — permettant aux clients de spécifier de la mémoire CXL moins chère et de plus grande capacité pour les données tolérantes à la latence, aux côtés de HBM rapide ou de DDR5 pour les chemins critiques en latence. AWS et Google ont tous deux des programmes CXL internes, et des fonctionnalités visibles par le client sont probables en 2027.
CXL n’est pas une technologie en quête d’un cas d’usage. Le cas d’usage — l’extension mémoire IA — est arrivé avant que le matériel ne soit complètement prêt. Le matériel rattrape maintenant son retard, et les deux prochaines années détermineront si la mémoire désagrégée devient une fonctionnalité standard de l’infrastructure IA ou reste un outil spécialisé pour les plus grands hyperscalers.