Memory pooling de CXL

CXL 4.0 en 2026: cómo el memory pooling y los 128 GT/s están cambiando los servidores para IA y la nube

La memoria se ha convertido en una de las principales limitaciones de la infraestructura moderna para inteligencia artificial y computación en la nube. Los procesadores y aceleradores continúan aumentando su rendimiento, pero proporcionar suficiente memoria para alimentarlos de manera eficiente resulta cada vez más complejo y costoso. Compute Express Link, más conocido como CXL, aborda este problema mediante una conexión coherente entre procesadores, aceleradores y memoria externa. CXL 4.0, publicado por el CXL Consortium en noviembre de 2025, eleva la velocidad máxima de transferencia de 64 GT/s a 128 GT/s, manteniendo al mismo tiempo las funciones de agrupación y uso compartido de memoria desarrolladas en generaciones anteriores de CXL. En 2026, esta combinación resulta especialmente relevante para la inferencia de IA, los grandes servidores en la nube y la computación a escala de rack. No sustituye a la memoria DDR convencional ni a la memoria de alto ancho de banda, y tampoco convierte automáticamente un rack completo en un único sistema de memoria. Lo que sí ofrece es una vía práctica para tratar la memoria como un recurso más flexible, en lugar de como una cantidad fija asignada permanentemente a un procesador.

Por qué CXL 4.0 es importante para los servidores de IA y la nube en 2026

CXL se creó porque la relación tradicional entre procesadores y memoria comenzaba a resultar demasiado restrictiva para las cargas de trabajo de los centros de datos. Un servidor convencional dispone de una cantidad fija de memoria local conectada a través de los canales de memoria de la CPU. Este modelo funciona bien cuando las cargas son previsibles, pero los sistemas de IA y los servicios en la nube rara vez mantienen un comportamiento estable durante mucho tiempo. Una máquina puede necesitar varios terabytes de memoria para una tarea temporal mientras que otro servidor del mismo rack mantiene una gran cantidad de DRAM sin utilizar. Instalar suficiente memoria local en cada servidor para cubrir su posible demanda máxima provoca que una parte considerable de esa capacidad permanezca inactiva durante largos periodos. CXL modifica esta relación al permitir que dispositivos de memoria compatibles se sitúen fuera de la configuración tradicional de módulos DIMM del procesador y sigan siendo accesibles mediante operaciones de lectura y escritura similares a las utilizadas con la memoria convencional. Las versiones anteriores de CXL introdujeron expansión, conmutación, agrupación y uso compartido de memoria. CXL 4.0 se centra principalmente en aumentar la cantidad de datos que puede circular por estas conexiones.

La principal novedad es el aumento hasta 128 GT/s, el doble de la velocidad máxima de 64 GT/s disponible en CXL 3.x. CXL 4.0 consigue este rendimiento basándose en la señalización física definida para PCI Express 7.0, cuya especificación final 1.0 se publicó en junio de 2025. GT/s significa gigatransferencias por segundo y no debe confundirse con gigabytes por segundo. Esta cifra describe la velocidad de señalización de cada carril, mientras que el ancho de banda realmente utilizable depende de factores como el número de carriles, la sobrecarga del protocolo y la configuración del dispositivo. PCI Express 7.0, por ejemplo, puede proporcionar hasta 512 GB/s de ancho de banda bidireccional mediante una conexión de dieciséis carriles. CXL utiliza la misma base física de alta velocidad, pero añade la coherencia y el comportamiento de memoria necesarios para que procesadores, aceleradores y dispositivos de memoria puedan trabajar de forma coordinada. El resultado es una capacidad de enlace considerablemente mayor sin obligar al software a tratar la memoria conectada como almacenamiento convencional o como un recurso de red tradicional.

Esta mayor velocidad de transferencia es importante porque la expansión de memoria solo resulta útil cuando la conexión con esa memoria es suficientemente rápida para la carga de trabajo. La DRAM local sigue siendo la opción preferida para los datos sensibles a la latencia, mientras que HBM continúa siendo fundamental cuando las GPU y otros aceleradores necesitan un ancho de banda extremadamente elevado cerca de sus unidades de cálculo. La memoria CXL ocupa una posición distinta dentro de esta jerarquía. Puede ofrecer mucha más capacidad de la que resulta económicamente viable instalar junto a cada procesador o acelerador, con características de acceso mejores que las obtenidas al trasladar los mismos datos a almacenamiento SSD. Para la infraestructura de IA, esto crea un nivel adicional de memoria entre la limitada y costosa memoria local de alta velocidad y el almacenamiento mucho más lento. Para los operadores de servicios en la nube, también ofrece una forma de ajustar mejor la capacidad de memoria a las variaciones de las cargas de trabajo, en lugar de dimensionar cada servidor para su peor escenario posible. Por tanto, el valor de CXL 4.0 depende tanto de su flexibilidad como de su velocidad de transferencia.

Qué cambia realmente con 128 GT/s

Duplicar la velocidad de un enlace de 64 GT/s a 128 GT/s no significa que una aplicación vaya a funcionar automáticamente el doble de rápido. Muchas aplicaciones están limitadas por el rendimiento del procesador, la capacidad de los aceleradores, el comportamiento del software o la latencia de la memoria, y no necesariamente por el propio enlace CXL. El ancho de banda adicional adquiere importancia cuando grandes cantidades de datos deben desplazarse simultáneamente entre procesadores, aceleradores y memoria ampliada. Un servidor dedicado a inferencia de modelos de gran tamaño, análisis de datos o bases de datos en memoria puede tener numerosos procesos leyendo y escribiendo información al mismo tiempo. En estas situaciones, una interconexión más lenta puede convertirse en un cuello de botella compartido incluso cuando existe suficiente capacidad de memoria detrás de ella. CXL 4.0 ofrece un margen mayor para este tipo de tráfico. El CXL Consortium también ha mantenido la estructura de transferencias de tamaño fijo y los mecanismos de protección frente a errores desarrollados para la generación de 64 GT/s, lo que permite introducir una mayor velocidad sin aceptar simplemente un aumento proporcional de la latencia del protocolo.

CXL 4.0 también incorpora puertos agrupados. En términos sencillos, varias conexiones físicas CXL pueden funcionar como una única conexión lógica cuando el dispositivo y el sistema anfitrión son compatibles con esta función. Esto resulta útil cuando un solo enlace no ofrece suficiente ancho de banda para un acelerador de alto rendimiento u otro componente exigente. En lugar de obligar al resto del sistema a tratar cada conexión como una ruta totalmente independiente, los puertos agrupados proporcionan un método definido para combinarlas. La especificación también admite de forma nativa enlaces x2, lo que puede facilitar la conexión de un mayor número de dispositivos cuando no todos requieren el máximo ancho de banda, y permite utilizar hasta cuatro retimers para ampliar el alcance del canal. Estas mejoras son relevantes para servidores densos y diseños a escala de rack, donde los componentes no siempre pueden situarse inmediatamente junto al procesador. Los diseñadores disponen así de más opciones para equilibrar el ancho del enlace, el número de dispositivos, la distancia física y el ancho de banda.

La fiabilidad es igualmente importante cuando la memoria deja de estar limitada a la placa base. El fallo de un módulo DIMM convencional suele afectar a un único servidor, mientras que la memoria agrupada o compartida puede prestar servicio a varias máquinas o cargas de trabajo importantes. Por este motivo, CXL 4.0 incorpora funciones adicionales de fiabilidad, disponibilidad y mantenimiento de memoria destinadas a mejorar la visibilidad de los errores y facilitar las tareas de servicio. Esto no elimina los fallos, y los operadores siguen necesitando redundancia, supervisión y una distribución adecuada de las cargas de trabajo. Sin embargo, facilita la gestión de memoria CXL de gran capacidad como parte de la infraestructura habitual, en lugar de tratarla como un periférico poco común. La compatibilidad con versiones anteriores es otro aspecto práctico. Los sistemas CXL 4.0 están diseñados para funcionar con generaciones anteriores de CXL cuando el hardware lo permite, por lo que las organizaciones no necesitan sustituir toda su infraestructura CXL de una sola vez. Esto es especialmente importante en 2026, ya que el sector continúa desplegando equipos CXL 2.0 y 3.x mientras comienza el diseño y la validación de hardware CXL 4.0 capaz de alcanzar 128 GT/s.

Memory pooling: de la memoria fija del servidor a una capacidad compartida

El memory pooling es anterior a CXL 4.0. Esta función apareció con CXL 2.0 junto con la conmutación y un modelo estandarizado de Fabric Manager. CXL 3.0 amplió posteriormente el concepto mediante fabrics de mayor tamaño, conmutación multinivel y uso compartido coherente de memoria. Es importante distinguir estos conceptos. El memory pooling permite que una cantidad de memoria conectada mediante CXL pueda asignarse a distintos sistemas anfitriones a medida que cambia la demanda. Una parte utilizada por un servidor puede liberarse posteriormente y asignarse a otro. El uso compartido de memoria va un paso más allá, ya que permite que determinadas regiones compatibles estén disponibles para más de un sistema anfitrión mientras los mecanismos de coherencia mantienen una visión consistente de los datos. CXL 4.0 conserva estas posibilidades y proporciona a la fabric un ancho de banda considerablemente mayor. El resultado práctico no es una nueva forma de pooling creada en 2026, sino una interconexión más rápida que hace que los modelos existentes de agrupación y uso compartido resulten más atractivos para sistemas más grandes y cargas más exigentes.

Un ejemplo sencillo permite entender por qué esto es importante. Imaginemos varios servidores en la nube, cada uno con suficiente DRAM local para su funcionamiento habitual, conectados además a un conjunto adicional de memoria CXL. Uno de los servidores puede necesitar de repente varios cientos de gigabytes adicionales para análisis, un servicio de inferencia de IA o una gran base de datos. En lugar de requerir que esa capacidad haya sido instalada de forma permanente dentro de esa máquina concreta, puede asignársele una parte del pool de memoria CXL. Cuando disminuye la demanda, esa capacidad puede liberarse y quedar disponible para otros sistemas. Un Fabric Manager coordina los recursos correspondientes, mientras que el sistema operativo y el software de orquestación determinan cómo debe utilizarse la memoria adicional. La implementación concreta varía según el fabricante y sigue existiendo una penalización de latencia frente a la DRAM local, pero el principio económico es sencillo: una memoria que de otro modo permanecería sin utilizar detrás de una CPU puede convertirse en capacidad disponible para otras cargas de trabajo.

Este enfoque pretende solucionar el problema conocido como memoria infrautilizada o stranded memory. Los servidores en la nube suelen configurarse teniendo en cuenta los requisitos máximos y no los requisitos medios, porque quedarse sin memoria puede reducir drásticamente el rendimiento de una carga o impedir que se ejecute. Como resultado, un servidor puede disponer de DRAM libre mientras que una máquina vecina carece de capacidad suficiente. El pooling reduce la necesidad de que cada sistema mantenga el mismo gran margen de seguridad. También puede facilitar las ampliaciones, ya que es posible instalar memoria adicional en un subsistema CXL compartido en lugar de depender exclusivamente de los canales de memoria locales del procesador. La rentabilidad sigue dependiendo del comportamiento de las cargas, del coste de los switches, del consumo energético, de la compatibilidad del software y de la diferencia de rendimiento entre la memoria local y la memoria conectada mediante CXL. Por tanto, CXL debe considerarse como otro nivel de la jerarquía de memoria y no como una señal de que la DRAM local haya dejado de ser necesaria. Los diseños más eficientes suelen combinar distintos tipos de memoria para diferentes tareas.

Por qué la inferencia de IA se beneficia de la memoria agrupada y por niveles

La inferencia de IA es una de las razones más claras del creciente interés por la memoria CXL en 2026. Ejecutar grandes modelos de lenguaje implica mucho más que almacenar los pesos del modelo. Cada solicitud activa también puede necesitar un estado temporal, incluida la caché de claves y valores utilizada por los modelos transformer para evitar volver a calcular información de atención ya procesada. A medida que las ventanas de contexto se hacen más largas y los servidores atienden a un mayor número de usuarios o agentes de IA de manera simultánea, esta caché puede ocupar una cantidad considerable de memoria. Mantener todos esos datos en la costosa memoria HBM del acelerador puede limitar el número de sesiones que un servidor es capaz de gestionar incluso cuando la GPU todavía dispone de capacidad de cálculo sin utilizar. Trasladar todos los datos sobrantes a unidades SSD, en cambio, puede introducir retardos de acceso mucho mayores. La memoria CXL ofrece un nivel intermedio donde determinada información puede seguir siendo direccionable como memoria sin consumir la capacidad local más valiosa del acelerador.

Esto no significa que un operador de IA deba trasladar simplemente un modelo completo desde HBM a memoria CXL. Los datos utilizados con mayor frecuencia siguen beneficiándose de estar lo más cerca posible del acelerador, y el ancho de banda disponible en HBM es considerablemente superior al de una capa de memoria CXL externa. Un diseño más realista mantiene los datos del modelo sensibles a la latencia en HBM, conserva los datos de trabajo adecuados en la DRAM local del sistema y utiliza capacidad CXL para información que debe seguir estando disponible rápidamente, pero que no necesita el máximo ancho de banda local en todo momento. La organización por niveles y la descarga de la caché KV son ejemplos destacados analizados por el sector CXL en 2026. Cuando el software puede identificar qué datos deben almacenarse en cada nivel, el servidor puede admitir contextos más largos o un mayor número de solicitudes de inferencia simultáneas sin necesidad de añadir una cantidad equivalente de costosa memoria de acelerador. La principal ventaja es, por tanto, una mayor eficiencia de capacidad y no la afirmación de que CXL sea más rápido que HBM.

El mismo principio se aplica a otros ámbitos además de los grandes modelos de lenguaje. Los sistemas de recomendación pueden manejar tablas de embeddings de gran tamaño, las tareas de procesamiento de datos pueden trabajar con conjuntos de información superiores a la capacidad de la DRAM local y la inferencia basada en CPU puede necesitar más memoria de la que resulta económicamente razonable instalar en una configuración convencional de servidor. CXL puede ampliar la cantidad de memoria utilizable para estas cargas manteniendo la semántica estándar de acceso a memoria. El pooling añade otro nivel de flexibilidad, ya que la capacidad puede seguir la demanda en lugar de quedar dedicada permanentemente a una única máquina. Esta característica resulta especialmente atractiva en infraestructuras de IA compartidas donde diferentes servicios alcanzan sus picos de uso en distintos momentos. Una tarea por lotes puede necesitar mucha memoria durante la noche, mientras que un servicio de inferencia podría necesitar esa misma capacidad durante el horario laboral. La asignación dinámica no elimina todas las limitaciones operativas y el traslado de capacidad entre distintos sistemas anfitriones sigue requiriendo la intervención del sistema operativo y del software de infraestructura, pero ofrece más posibilidades que un diseño de servidor con memoria fija.

Memory pooling de CXL

Cómo CXL 4.0 está cambiando el diseño de servidores y la economía de la nube

El cambio a largo plazo que introduce CXL es más arquitectónico que puramente numérico. Los servidores tradicionales se diseñan alrededor de recursos que pertenecen a una sola máquina: sus procesadores, módulos DIMM y aceleradores se instalan para ese servidor y permanecen allí incluso cuando apenas se utilizan. CXL permite tratar algunos de esos recursos, especialmente la memoria, de forma más independiente. Un rack puede incluir servidores convencionales junto con switches CXL, dispositivos de expansión de memoria y sistemas de memoria agrupada, asignando la capacidad en función de las necesidades de cada carga. CXL 3.x ya proporciona gran parte del comportamiento de fabric necesario para este modelo. CXL 4.0 añade un ancho de banda de enlace mucho mayor y nuevas opciones de conectividad, elementos que adquieren importancia a medida que aumenta el número de dispositivos y el volumen de tráfico. Esto no convierte un rack en un solo ordenador, pero reduce la dependencia de la idea tradicional de que cada byte de memoria útil debe estar físicamente instalado junto a la CPU que lo utilizará.

Para los proveedores de servicios en la nube, la ventaja económica más evidente es la posibilidad de aprovechar mejor la memoria disponible. La DRAM representa una parte importante tanto del coste como del consumo energético de los servidores con grandes cantidades de memoria. Si cada servidor se configura para afrontar picos de demanda poco frecuentes, una parte considerable de esa inversión puede realizar poco trabajo útil durante el funcionamiento normal. Un pool de memoria compartida puede permitir a los operadores adquirir capacidad teniendo en cuenta la demanda conjunta en lugar de proporcionar a cada máquina memoria suficiente para su máximo teórico individual. El ahorro no es automático. Los switches CXL, controladores, sistemas de memoria y software de gestión también tienen un coste y consumen energía, mientras que las cargas que necesitan de manera constante una latencia de memoria muy baja pueden seguir justificando grandes cantidades de DRAM local. Por este motivo, el mejor argumento económico aparece en entornos donde la demanda de memoria varía considerablemente entre distintos sistemas, donde la capacidad es más importante que alcanzar la latencia mínima o donde disponer de memoria adicional permite que procesadores y aceleradores costosos continúen trabajando en lugar de esperar a que los datos lleguen desde el almacenamiento.

La flexibilidad operativa puede resultar tan importante como el propio coste del hardware. Un servicio en la nube puede cambiar considerablemente durante la vida útil de un servidor. Los modelos de IA aumentan de tamaño, las bases de datos crecen y los clientes cambian entre diferentes tipos de instancias. Con una máquina de memoria fija, ampliar la capacidad puede exigir trasladar la carga de trabajo o sustituir hardware. La expansión y el pooling mediante CXL crean la posibilidad de modificar la memoria disponible sin reconstruir el nodo de cálculo. También pueden favorecer configuraciones de servidor más especializadas: algunas máquinas pueden disponer de una gran cantidad de memoria local, mientras que otras pueden depender en mayor medida de capacidad compartida para cargas que toleran una latencia adicional. La fiabilidad y la seguridad siguen siendo esenciales dentro de este modelo. La memoria debe reasignarse de forma segura, los fallos deben quedar aislados y la información perteneciente a una carga no puede quedar expuesta a otra. A medida que CXL evoluciona hacia entornos con múltiples hosts y arquitecturas a escala de rack, estos requisitos de gestión pasan a ser una parte integral del diseño.

Qué esperar de las implementaciones de CXL después de 2026

La realidad más importante en 2026 es que la publicación de la especificación CXL 4.0 no significa que el hardware CXL capaz de alcanzar 128 GT/s se haya generalizado ya en los centros de datos de producción. Los sistemas comerciales y de demostración actuales abarcan varias generaciones. El módulo de memoria CXL MD220 de Samsung, por ejemplo, utiliza CXL 2.0 sobre PCIe 5.0 y está disponible en capacidades de 128 GB y 256 GB, mientras que el sistema de memory pooling CMM-B de Samsung orientado a racks también utiliza tecnología CXL 1.1 y 2.0. SK hynix seguía mostrando durante 2026 soluciones CMM-DDR5 de la generación CXL 2.0, y los eventos del CXL Consortium celebrados durante el año incluían enlaces y controladores CXL 3.2 en funcionamiento. Al mismo tiempo, proveedores de diseño de semiconductores ya ofrecen tecnologías de controladores, seguridad y verificación para CXL 4.0 destinadas a chips que funcionarán a 128 GT/s. Es decir, la transición ya está en marcha, pero los productos maduros actuales y los futuros diseños CXL 4.0 siguen coexistiendo.

Esta adopción gradual es normal para una interconexión destinada a servidores. Después de publicar una especificación deben aparecer diseños de controladores, switches, retimers, procesadores, dispositivos de memoria, firmware, compatibilidad con sistemas operativos, pruebas de conformidad y mecanismos de interoperabilidad entre varios fabricantes antes de que los grandes operadores puedan desplegarla con confianza. CXL 4.0 parte con ventaja porque mantiene la arquitectura de versiones anteriores de CXL y conserva la compatibilidad con generaciones previas, lo que permite a los fabricantes aprovechar la experiencia acumulada tanto en software como en diseño. La primera razón para adoptarlo no será necesariamente alcanzar la cifra de 128 GT/s por sí sola. Los operadores probablemente se centrarán en determinar si el ancho de banda adicional permite utilizar más dispositivos de memoria, gestionar más tráfico simultáneo o incrementar la actividad de los aceleradores sin crear un nuevo cuello de botella. A medida que las fabrics CXL evolucionan desde una simple expansión de memoria hacia recursos agrupados y compartidos a escala de rack, el ancho de banda adicional adquiere cada vez más valor porque un mayor número de cargas compite por la capacidad de la misma interconexión.

Para la infraestructura de IA y los servicios en la nube, CXL 4.0 debe considerarse como parte de una transformación más amplia del diseño de memoria y no simplemente como una actualización de velocidad de una generación concreta. La memoria DDR local seguirá proporcionando un acceso relativamente rápido para las CPU, HBM continuará atendiendo a los aceleradores que necesitan un ancho de banda extremo y las unidades SSD seguirán ofreciendo capacidad persistente a un coste razonable. CXL añade una capa flexible entre estos recursos, permitiendo que los servidores accedan a conjuntos de memoria coherente de mayor tamaño y que la capacidad se asigne con menos restricciones físicas. La generación de 128 GT/s proporciona más margen para ampliar esta capa. A corto plazo, muchos sistemas de producción continuarán utilizando CXL 2.0 o 3.x mientras el nuevo silicio avanza hacia CXL 4.0. Durante las siguientes generaciones de servidores, el cambio más significativo probablemente será dejar de preguntar cuánta memoria hay instalada dentro de una máquina concreta y comenzar a valorar cuánta memoria adecuada puede ponerse a disposición de una carga de trabajo exactamente cuando la necesita.