CXL et memory pooling — partager la mémoire entre serveurs

En bref

Quand un serveur manque de mémoire pour faire tourner un gros modèle de langage, la première réflexe est d’acheter plus de barrettes DRAM. Mais le nombre de slots est limité, et au-delà d’un certain seuil, la seule solution est d’ajouter un serveur entier. CXL (Compute Express Link) propose une troisième voie : brancher des modules de mémoire supplémentaires sur le port PCIe du serveur, comme on branche un disque, mais avec des performances proches de la DRAM locale. Plusieurs serveurs peuvent même partager un même pool de mémoire CXL via un switch. En 2025-2026, cette technologie passe du stade laboratoire aux premières instances cloud, portée par un cas d’usage précis : stocker le KV cache de l’inférence LLM sur contexte long.

Le problème : le serveur CPU déborde avant le GPU

Pour comprendre pourquoi CXL existe, il faut regarder du côté des serveurs CPU qui orchestrent l’inférence LLM — pas seulement des accélérateurs GPU.

Un serveur x86 moderne (Intel Xeon, AMD EPYC) dispose de 8 à 12 canaux mémoire DDR5, ce qui représente 8 à 24 slots DIMM physiques selon la plateforme. C’est le plafond mécanique. En remplissant tous les slots avec des barrettes 64 Go, on atteint au mieux 1,5 TB de DRAM par socket. Au-delà, impossible sans ajouter un serveur complet.

Pour l’inférence LLM, ce plafond crée un déséquilibre structurel : les poids d’un modèle 70B en demi-précision pèsent 140 Go, et le KV cache (les clés et valeurs d’attention calculées pour chaque token du contexte) s’ajoute à ces poids. Pour un contexte de 128 000 tokens sur un modèle de cette taille, le KV cache peut dépasser 50 Go par requête. Multiplié par plusieurs requêtes simultanées, cela déborde rapidement même une DRAM bien dimensionnée.

La réponse traditionnelle — ajouter un serveur — duplique tout le coût : CPU, boîtier, alimentation, licences. CXL propose un découplage : garder le compute sur le serveur principal, déplacer la capacité mémoire vers des modules externes branchés en PCIe.

Vocabulaire

• KV cache : structure mémoire qui stocke les résultats intermédiaires de l’attention pour chaque token déjà lu. Sa taille croît linéairement avec la longueur du contexte.
• DRAM : mémoire vive standard des serveurs (barrettes DDR4 ou DDR5). Latence ~80 ns, bande passante ~50 GB/s par canal.
• PCIe : bus d’interconnexion standard entre le CPU et les périphériques (GPU, SSD, cartes réseau). Ubiquitaire dans tous les serveurs x86.
• Memory pooling : partager un pool de mémoire entre plusieurs hôtes, chaque hôte recevant une partition dédiée (ou partagée en CXL 3.0).

Ce que CXL change — et ce qu’il n’est pas

Avant d’entrer dans les mécanismes, une clarification fondamentale : CXL est souvent confondu avec d’autres technologies mémoire parce qu’elles adressent toutes des problèmes de mémoire dans les systèmes IA. Les trois acteurs sont différents.

La HBM (High Bandwidth Memory) est une mémoire stacked 3D collée directement sur le die GPU, reliée par un bus de 1024 bits. Elle est intra-puce, ultra-rapide (jusqu’à 5,3 TB/s sur le MI300X), mais limitée en capacité (192 Go maximum en 2024) et réservée aux accélérateurs de calcul. HBM n’est pas accessible depuis un autre serveur. Son article dédié détaille ce fonctionnement.

NVLink et InfiniBand sont des interconnects compute inter-GPU ou inter-nœuds. Ils synchronisent les gradients d’entraînement, orchestrent le parallélisme tensoriel. Leur rôle est de faire circuler des données de calcul entre processeurs, pas de partager de la mémoire au sens d’un espace d’adressage cohérent.

CXL opère différemment : c’est un protocole de cohérence mémoire construit sur PCIe. Il permet au CPU d’adresser de la mémoire externe (un module branché en PCIe) exactement comme s’il s’agissait de DRAM locale — avec la même sémantique load/store, sans couche réseau intermédiaire. La différence est fondamentale : accéder à de la mémoire CXL ne nécessite pas de NIC, pas de pile réseau, pas de verrou logiciel — juste une instruction de lecture ou d’écriture ordinaire.

En clair : HBM = mémoire ultra-rapide collée sur le GPU. NVLink/InfiniBand = autoroutes entre GPUs. CXL = extension de la DRAM d’un serveur via le port PCIe, avec partage possible entre serveurs.

Les versions de CXL — une montée en puissance en six étapes

CXL 1.0 / 1.1 (2019–2020) — l’expansion simple

Première version, bâtie sur PCIe 5.0 (32 GT/s par lane). CXL définit trois sous-protocoles qui peuvent s’activer selon le type de device :

• CXL.io : transactions I/O classiques, inspirées de PCIe.
• CXL.cache : le device peut lire et mettre en cache de la mémoire hôte (cohérence device→host).
• CXL.mem : l’hôte peut lire et écrire dans la mémoire du device (expansion mémoire).

En 1.1, seuls les appareils de Type 1 (accélérateurs sans mémoire propre) et Type 2 (accélérateurs avec mémoire partageable) sont supportés. Intel Xeon Sapphire Rapids (janvier 2023) est le premier CPU grand public à implémenter CXL 1.1, mais avec une contrainte majeure : pas de support Type 3 (modules mémoire purs). AMD EPYC Genoa (2022) intègre le support Type 3 complet, prenant un an d’avance sur Intel.

CXL 2.0 (2020) — le pooling arrive

C’est la version qui rend le memory pooling possible : plusieurs hôtes CPU peuvent se connecter à un switch CXL, lui-même connecté à un pool de modules mémoire. Chaque hôte reçoit une partition dédiée du pool (pas de mémoire partagée simultanément, mais redistribuable dynamiquement).

Astera Labs lance Leo, le premier ASIC switch CXL commercial, capable de redimensionner les partitions sans redémarrer les CPUs hôtes — critique pour les environnements multi-tenant cloud. L’introduction des Type 3 devices (modules mémoire purs, sans calcul) ouvre la voie aux premiers memory expanders commerciaux.

CXL 3.0 (2022) et 3.1 (novembre 2023) — le partage vrai

Passage à PCIe 6.0 (64 GT/s par lane, encodage PAM-4). Doublement de la bande passante. L’innovation fondamentale : le memory sharing — plusieurs hôtes accèdent simultanément aux mêmes octets de mémoire avec cohérence matérielle. En 3.0, le fabric supporte des topologies multi-niveaux (rack-scale), plus seulement switch unique.

CXL 3.1 (novembre 2023) étend les capacités de pooling et de sharing, introduit les trusted compute environments pour l’isolation sécurisée des partitions, et optimise la gestion des ressources dans les environnements multi-locataires.

CXL 3.2 (décembre 2024) et 4.0 (novembre 2025)

CXL 3.2 améliore le monitoring et la gestion des memory devices, ajoute le Trusted Security Protocol (TSP) pour l’isolation cryptographique des partitions. CXL 4.0, basé sur PCIe 7.0, double à nouveau la bande passante (128 GT/s) et améliore la fiabilité (RAS — Reliability, Availability, Serviceability).

Sources : CXL Consortium — BusinessWire, nov. 2025 et déc. 2024.

En clair : CXL 1.x = ajouter de la mémoire à un serveur. CXL 2.0 = partager un pool entre plusieurs serveurs (partitions dédiées). CXL 3.0 = plusieurs serveurs lisent les mêmes octets simultanément. Chaque génération construit sur la précédente sans rupture.

Les trois types de devices CXL

CXL définit une taxonomie de devices selon les sous-protocoles qu’ils activent. C’est cette taxonomie qui détermine le cas d’usage et l’adoption réelle.

Type 1 — Accélérateurs sans mémoire propre

Ces devices activent CXL.cache + CXL.io uniquement. Exemples typiques : SmartNICs, cartes réseau intelligentes. Le device peut lire et cacher de la mémoire hôte de façon cohérente, sans exposer sa propre mémoire. Cas d’usage : accélération réseau avec accès direct à la DRAM hôte, zéro-copy.

Type 2 — Accélérateurs avec mémoire partageable

Ces devices activent les trois sous-protocoles : CXL.io + CXL.cache + CXL.mem. Ils disposent d’une mémoire dite HDM (Host-managed Device Memory) : le CPU peut lire la mémoire du device, et le device peut lire la DRAM hôte — dans un domaine de cohérence partagé. GPUs, FPGAs et ASICs de calcul entrent dans cette catégorie théoriquement.

En pratique, les GPU haute performance actuels (H100, MI300X) n’utilisent pas CXL — ils privilegient leurs interconnects propriétaires (NVLink) et leur HBM intégrée pour le débit brut. Le débat sur l’adoption GPU Type 2 en production reste ouvert [NON VÉRIFIÉ — position SemiAnalysis, source partiellement payante].

Type 3 — Memory expanders (les modules purs)

Ces devices n’activent que CXL.mem + CXL.io. Pas de calcul : ce sont des boîtiers de DRAM connectés via PCIe. Le CPU les adresse exactement comme des barrettes ordinaires. C’est le type le plus déployé commercialement en 2024–2025, et le plus pertinent pour le KV cache LLM.

Exemples produits disponibles :

• Samsung CMM-D : 512 Go de DDR5, interface PCIe 5.0 x8, ASIC CXL propriétaire. Capacité cumulée jusqu’à 16 TB par CPU annoncée (chiffre marketing Samsung, performance réelle à valider). Version CMM-D 2.0 ciblant CXL 3.1 en cours d’échantillonnage fin 2025.
• SK Hynix CMM-D : 96 Go DDR5, format EDSFF ES.3, PCIe Gen 5 x8, CXL 2.0. Validation client complétée en avril 2024 ; version 128 Go en développement.
• Micron : modules CXL annoncés, positionnement enterprise.

Sources : Tom’s Hardware — Samsung CMM-D 512 GB ; ServeTheHome — SK Hynix CXL 2.0.

En clair : Type 1 = carte réseau intelligente. Type 2 = GPU avec mémoire partageable (théorique pour AI haut de gamme). Type 3 = boîtier DRAM branché en PCIe — c’est celui qui existe en vrai, en 2025.

Cas d’usage LLM — le KV cache sur contexte long

C’est ici que CXL trouve sa justification la plus forte pour les charges IA en 2025–2026.

Le goulot : le KV cache déborde la mémoire disponible

Quand un LLM génère du texte sur un contexte long, il doit mémoriser les représentations intermédiaires d’attention pour chaque token déjà lu. Cette structure s’appelle le KV cache — clés (K) et valeurs (V) de chaque couche d’attention, pour chaque token. Elle croît linéairement avec la longueur du contexte et le nombre de couches.

Pour un modèle 70B avec 80 couches, en précision BF16, sur un contexte de 128 000 tokens : le KV cache seul approche 80 Go par requête. Sur un H100 (80 Go de HBM totaux), cela ne laisse aucun espace pour les poids du modèle (qui sont eux-mêmes répartis sur plusieurs GPU). La solution dominante actuelle, vLLM avec PagedAttention (Kwon et al., SOSP 2023), gère le KV cache en pages dans la VRAM GPU. Mais la VRAM reste la contrainte dure.

L’idée du KV cache offload sur CXL : stocker le KV cache dans un pool de DRAM externe (cheap, capacité illimitée) et garder en HBM seulement les tokens actifs du contexte courant. L’hôte CPU accède à la mémoire CXL en load/store natif, sans NIC, sans pile réseau.

Avantage sur RDMA : RDMA (accès direct à la mémoire d’un serveur distant via InfiniBand) requiert des primitives de synchronisation explicites, implique la pile réseau (NIC + pilote + OS), et ajoute plusieurs micro-secondes de latence. CXL offre une latence inférieure et une sémantique d’accès identique à la DRAM locale.

Résultats de recherche récents [early research]

Beluga (arXiv 2511.20172, accepté SIGMOD 2026, novembre 2025) : premier système permettant aux GPUs d’accéder directement à des pools de mémoire larges via switches CXL. Résultats annoncés : réduction de 89,6 % du TTFT (Time-To-First-Token), gain de débit de 7,35x dans vLLM par rapport à une baseline RDMA. [early research]

TraCT (arXiv 2512.18194, décembre 2025) : inférence LLM désagrégée rack-scale avec KV cache partagé via CXL. Le système sépare les phases prefill (calcul intensif, GPU) et decode (latence critique) et les répartit sur des nœuds distincts partageant leur KV cache via un pool CXL. Pour gérer la cohérence avec CXL non-cohérent entre nœuds, TraCT implémente un mécanisme de synchronisation à deux tiers. Résultats annoncés : TTFT réduit jusqu’à 9,8x, latence P99 améliorée de 6,2x, débit pic amélioré de 1,6x par rapport aux baselines RDMA/DRAM. [early research]

NeurIPS 2024 ML for Systems Workshop (Tang et al.) : exploration du KV cache sur stockage CXL. L’article documente que CXL offre un support hardware natif pour les primitives load/store, garantissant un accès bas-latence à grain fin adapté aux patterns d’accès sparse du KV cache. [early research — atelier, non répliqué]

Démo hardware XConn + MemVerge (Supercomputing 2025) : démonstration de KV cache offload dynamique sur pool CXL via switch XConn SC50256. Résultat annoncé : gain supérieur à 5x par rapport au SSD ou RDMA. Première démonstration hardware commercial à l’échelle. [Source : communiqué Introl 2025, triangulé]

Microsoft Azure (novembre 2025) : lancement des premières instances cloud équipées de mémoire CXL, marquant la transition du stade recherche vers le déploiement cloud réel. Chiffres de performance non publiés.

En clair : au lieu de limiter le contexte LLM à ce qui tient dans la VRAM GPU, CXL permet de déporter le KV cache dans un pool de DRAM externe bon marché, accessible comme de la mémoire locale. Les résultats de recherche de fin 2025 montrent des gains importants en latence et débit — mais ces chiffres sont issus de prototypes laboratoire, pas de déploiements production.

Limites et maturité — ce que les benchmarks disent

La latence CXL est plus élevée que la DRAM locale

C’est la limite technique fondamentale de CXL, et elle est documentée précisément. L’étude ASPLOS 2025 (Jiang et al., “Dissecting CXL Memory Performance at Scale”, arXiv 2409.14317) a testé 4 devices CXL 1.1 réels sur 265 workloads :

Cela représente un facteur 2,6 à 4,9x de latence supplémentaire par rapport à la DRAM locale. En bande passante, les devices testés délivraient 18–52 GB/s, contre 52–246 GB/s pour la DRAM locale selon les plateformes.

L’étude OSDI 2024 (“Managing Memory Tiers with CXL”) mesure 2,02x la latence load-to-use sur Intel Xeon Gen 5 avec un device CXL réel, confirmant l’ordre de grandeur.

Impact sur le KV cache : le pattern d’accès du KV cache est sparse et souvent non séquentiel (accès aux tokens distants dans le contexte). La latence CXL est donc plus pénalisante que pour un accès séquentiel. Toutefois, CXL reste bien plus rapide que le SSD NVMe (latence ~100 µs) et que RDMA (latence ~2–5 µs mais avec overhead protocole). CXL se positionne entre DRAM locale et NVMe — un tier intermédiaire.

Le sharing CXL 3.0 exige une synchronisation logicielle

CXL 3.0 promet un memory sharing matériel (plusieurs hôtes lisent les mêmes octets), mais la cohérence entre nœuds distants n’est pas garantie sans protocole logiciel additionnel. TraCT (arXiv 2512.18194) documente la complexité d’un mécanisme à deux tiers pour assurer la consistance du KV cache partagé entre nœuds de prefill et decode.

L’adoption hyperscalers vs le reste du marché

Les données ABI Research citées par certaines sources (10% des serveurs 2024, 50% des AI racks 2025) n’ont pas pu être vérifiées depuis leur source primaire [NON VÉRIFIÉ].

En clair : CXL est plus lent que la DRAM locale d’un facteur 2,6 à 5x selon la génération et la topologie. Ce ralentissement est acceptable pour le KV cache (workload tolérant à la latence sur les tokens éloignés), mais pénalisant pour les workloads bandwidth-bound qui n’ont pas d’autre choix. Microsoft Azure marque en novembre 2025 la première adoption cloud réelle.

La controverse SemiAnalysis — “CXL est mort pour l’IA GPU”

Un argument circule depuis 2024 dans l’industrie : CXL serait structurellement inadapté pour les accélérateurs IA haut de gamme. L’analyse SemiAnalysis, souvent citée, argumente que les interfaces PCIe consomment du shoreline (la surface de bord de die silicium disponible pour les connexions externes), qui serait 3x moins efficace en bande passante par mm² que les SerDes propriétaires style NVLink ou les interconnects intégrés Google. Les GPU H100 et MI300X allouent donc leur shoreline aux liens HBM et NVLink — pas à PCIe/CXL.

La nuance essentielle : cet argument s’applique aux accélérateurs GPU de calcul (Type 2) et au modèle de connexion GPU-mémoire scale-up. Il ne s’applique pas aux serveurs CPU avec memory expanders Type 3, où CXL est déjà déployé et utile pour l’expansion de capacité DRAM.

Le marché CXL se structure donc sur deux segments distincts et non concurrents :

• CPU memory expansion (Type 3) : viable commercialement depuis 2024, croissant.
• GPU AI accelerators (Type 2) : quasi-absent en production haute performance, remplacé par HBM/NVLink propriétaires.

L’argument “CXL est mort” décrit correctement le second segment. Il ne décrit pas le premier.

Source : SemiAnalysis, “CXL is Dead in the AI Era” (newsletter payante, ~2024).

Matrice de décision — quand utiliser CXL

Règles heuristiques :

1. Commencer par la DRAM locale : CXL est un tier additionnel, pas un remplacement. Remplir les slots DIMM avant d’envisager l’expansion CXL.
2. Mesurer la sensibilité à la latence : si le workload est bandwidth-bound avec accès séquentiels denses, le facteur 2–5x de latence CXL se traduit directement en ralentissement. Si les accès sont sparse ou que la latence est masquable (prefetch, async), CXL est viable.
3. Attendre 2027 pour la production edge : le software stack (drivers Linux tiered memory, gestion NUMA avec CXL) atteindra sa maturité production après 2026 selon les estimations industrielles.
4. Distinguer pooling et sharing : pooling (CXL 2.0 — partitions dédiées) est stable et déployé. Sharing vrai (CXL 3.0 — mêmes octets entre hôtes) requiert une synchronisation logicielle additionnelle et reste [early research] pour les workloads LLM.