El pooling de memoria CXL permite a los centros de datos tratar la RAM como un recurso compartido, no un silo por servidor

Durante cuarenta años, la memoria de servidor ha funcionado igual: compras DRAM, la instalas en una máquina, y si esa máquina no usa toda la capacidad, el excedente queda inactivo. Compute Express Link (CXL) 3.0 está rompiendo ese modelo. Los switches de fabric que soportan pooling de memoria CXL 3.0 multi-host ya funcionan en producción dentro de los principales entornos de colocation y servidores dedicados, y el efecto sobre cómo los centros de datos planifican su capacidad es mayor de lo que sugiere el nombre técnico de la especificación.

La tesis es simple: la utilización de memoria en una flota típica de servidores ronda entre el 40% y el 55%, porque la capacidad se aprovisiona para el pico de carga de cada máquina individual, no para la flota en conjunto. El pooling de CXL convierte esa capacidad aislada en un pool compartido del que cualquier host del fabric puede extraer dinámicamente. Las propias pruebas de Samsung sobre despliegues con pooling de CXL muestran que la utilización sube al 75-90% una vez que la memoria se desagrega de servidores individuales.

Qué cambió realmente en CXL 3.0

Las revisiones anteriores de CXL (1.1, 2.0) permitían a un único host conectar un expansor de memoria externo vía PCIe — útil para añadir capacidad a una máquina, pero no para compartirla. CXL 3.0 añade topología de fabric y coherencia multi-host, lo que significa que un switch puede situarse entre un pool de módulos de memoria y un rack de servidores, repartiendo capacidad bajo demanda y recuperándola cuando una carga de trabajo termina. Opera a velocidades de fabric PCIe 6.0, lo que mantiene la penalización de latencia al acceder a memoria agrupada lo bastante baja para ser útil en cargas de trabajo reales, no solo para almacenamiento en frío por niveles.

El switch Structera S 30260 de Marvell es uno de los primeros componentes comerciales que implementa esto a escala de rack. La plataforma Xeon 6 de Intel ya viene con soporte nativo para expansores de memoria CXL, y el kernel de Linux soporta dispositivos CXL de forma nativa desde la versión 6.1 — lo que significa que la infraestructura a nivel de sistema operativo para usar realmente memoria agrupada en producción ya no es el obstáculo que era hace dos años.

El ángulo de la IA: descarga de KV cache

La carga de trabajo que está sacando el pooling de CXL del laboratorio hacia presupuestos de producción no es la virtualización de propósito general — es la inferencia de modelos de lenguaje grandes. El servicio de LLM mantiene una caché de clave-valor (KV cache) creciente en memoria para cada conversación activa, y esa caché escala con la longitud de contexto y las sesiones concurrentes. La HBM de la GPU es demasiado cara y escasa para retener KV cache fría o de crecimiento lento, pero mantenerla en un nivel CXL agrupado ofrece una latencia cercana a la de DRAM a una fracción del costo por gigabyte. Samsung ha publicado benchmarks específicamente sobre la descarga de KV cache a su línea de productos CMM-D (CXL Memory Module–DRAM), y apunta a la producción en masa de un módulo CMM-D 3.0 compatible con CXL 3.2 para finales de 2026.

Esto importa porque el costo de inferencia, no el costo de entrenamiento, es lo que la mayoría de las empresas paga realmente una vez que un modelo está desplegado. Un nivel de memoria que permite a un clúster de inferencia atender más sesiones concurrentes de contexto largo sin comprar HBM adicional de forma proporcional reduce directamente el costo por consulta al ejecutar IA a escala.

Qué significa esto para los compradores

Micron ha declarado públicamente que la DRAM es ahora una restricción vinculante para sus propios clientes — la demanda de cargas de trabajo de IA ha superado el crecimiento de la oferta, y el pooling de CXL es una de las pocas palancas a corto plazo que aumenta la capacidad de memoria efectiva sin necesitar más DRAM físico. Para los compradores de infraestructura, esto tiene implicaciones concretas:

• La planificación de capacidad pasa de ser por servidor a ser por fabric. En lugar de sobreaprovisionar cada máquina para su propio pico, los equipos pueden aprovisionar el pool para el pico agregado de la flota, que casi siempre es menor que la suma de los picos individuales.
• Las matemáticas del TCO cambian. Las cifras de los proveedores afirman una reducción de más del 60% en el costo total de propiedad de memoria cuando el pooling se usa correctamente — impulsada principalmente por no comprar DRAM que permanece inactiva el 60% del tiempo.
• El switch de fabric se convierte en una partida presupuestaria real. Marvell, Astera Labs y otros están enviando silicio de switch CXL como un componente de rack distinto, no una función integrada en el servidor. Presupuesta espacio de rack y presupuesto en consecuencia.

El pooling de CXL no reemplazará la DRAM local para datos críticos en latencia — nada supera a la memoria físicamente conectada al zócalo de la CPU. Pero para la porción creciente de la huella de memoria que es fría, intermitente o compartida entre una clase de carga de trabajo (KV cache, cachés en memoria, pools de buffer), el pooling ahora es una opción lista para producción, no una demo de investigación. Los equipos que ejecutan inferencia a cualquier escala significativa deberían evaluar un nivel agrupado CXL 3.0 antes de su próxima orden de compra de DRAM, no después.